JRA4 F2F meeting Day 1 (9 May 2005) ================== ================== Discussions =========== Q1) Which north parameters require mapping, which ones require looking up and which ones require computing Average Bandwidth ----------------- The usage of ServiceClass is changed for usage of IP Premium&Co. BAR has to map the functionality (BT, VLL). Service Type (in BAR interface) will has to be mapped to NSAP-Metrics: Bandwidth (Now) Delay (December) Jitter (Next Year) Packet Loss (Next Year) Bandwidth calculation has to include a safety factor! Average Bandwidth = ((File Size)/(EndTime - StartTime)) *(SF) where "SF" is the Safety Factor SF = lookup from BAR config file This calculation is only relevant to BT service. For VLL, the required bandwidth is explicitly specified. **In scope for MJRA4.4: YES** Min/Max Bandwidth ----------------- BAR config needs to specify Min/Max Bandwidth. Will be needed to check if Service Request is valid or not. Additionally it can be used to calculate alternative parameters. **In scope for MJRA4.4: YES** Time for Average ---------------- Can be used to calculate alternative average bandwidth. The value has to be less than (Endtime - StartTime)). In cope for MJRA4.4: NO Availability ------------ Will be needed for connection oriented networks. Ignore it in the meanwhile. In scope for MJRA4.4: NO AS Number --------- Is a world-wide unique number for a network (e.g. CERN) In scope for MJRA4.4: NO Source/Destination AS --------------------- Currently not in use, just for GEANT2, will be used in EGEE2. Not used in EGEE1. In cope for MJRA4.4: NO Ingress Node ------------ This will be a parameter in the config file at a later date this can be in the GLUE DB - Ratna will lead the discussions with Elisabetta regarding this issue for both NPM and BAR. For BAR GV will participate and FS will follow up. Currently in the config file 1 BAR will have 1 corresponding NSAP and 1 ingress point Required **In scope for MJRA4.4: YES** Egress Node ----------- optional. The information should be retrieved from the *remote* BAR.This will require an additional BAR-BAR interface. To be kept as an open issue for consideration. Currrently assume symetric routing. In scope for MJRA4.4: NO Direction --------- Add new parameter to North Interface called "Direction". Default is bidirectional. Question is if not only direction should be specified as boolean, but it could be used to specify separate bandwidth per direction. [AP] Add optional "Direction" parameter to the "North Interface" in the interface document (the successor to DJRA4.1). Default: BiDirection i.e., if the request bandwidth will be reserved in both forward and reverse directions. Otherwise, value is "UniDirection" where ForwardBandwidth and/or BackwardBandwidth can be specified. **In scope for MJRA4.4: YES** Transaction ID -------------- Just for logging and book keeping. For future: Alternative Parameter negotiation. BAR should do it. NSAP can provide hints, but cannot provide an alternative option. Problem is that not all involved network parts can provide sufficient information to provide a guaranteed alternative for NSAP. So BAR needs to guess. DSCP Marked ----------- First router from the end site have to mark packets. The value of the "DSCP Marked" to be place in a config file. Default value is "false". [AP] Change name of the parameter from "Flow Identiifier" to "DSCP Marked" Request Id ---------- Not in the schema. Handle by the underlying infrastrure. In scope for MJRA4.4: NO Transaction ID -------------- Write responses with Transaction IDs to a file (for logging and book keping). **In scope for MJRA4.4: YES** Service ID ---------- NSAP will ensure that the service id it returns is unique within the domain (it will also try to make it globally unique) but to ensure global uniqueness BAR will add a prefix to the service id and return it to HLM. return an unique "BAR" service id. BAR service ID = : implementation suggestion: provide a method to return a BAR unique ID. for now pick this up from a config file. **In scope for MJRA4.4: YES** Configuration Parameters ======================== These should be provided in one or more BAR config files. Min/Max Bandwidth Safety Factor - 1.0 or above NSAP Address - for BAR instance (currently just one NSAP, but keep config flexible to specify NSAP per Endsite) Ingress Node - for BAR instance per NSAP (B1 - NSAP1 - Ingress1, B2 - NSAP2 - Ingress2) DSCP Marked (AKA "Flow Identifier" in DJRA4.1) - Default=false. When L-NSAP comes available, this information should be retrieved from it. BAR Unique Instance ID Q2) What state should BAR and NSAP preserve ? - per request - state recovery in the event of a failure Need to write current state of BAR regularly to ensure state recovery. But how to ensure that full state is written/stored before BAR/NSAP crashes? Service ID mapping Provide kind of journaling of requests. Three steps: Request received by BAR from HLM Request pending Request approved Request notified (to HLM) BAR could check on start-up or regularly for open requests. Anyway, HLM should be able to detect crash because session brakes up when BAR crashes. Other key decisions =================== Does every BAR within an end site has just exactly one NSAP? Agreement: The assumption is taken that there is only one NSAP per BAR. 1 BAR will have 1 NSAP 1 NSAP can have 1 or more BAR NSAP/BAR schema and WSDL ======================== [AP] to update NSAP schema/wsdl - Have a single response object instead of success and failure - Instead of having a single top level element for request have multiple operations in the wsdl with different top level objects. - Use the term 'bi-directional' instead of 'both' for enumeration of direction in NSAP schema. - Use version instead of date for revision control of NSAP wsdl/schema [AP/FS] to investigate on XML extension mechanism and report. [FS] to send WS-I basic profile 1.0 test guidelines to AP. NSAP Functional Spec ==================== [AP] to write func spec for dummy NSAP - this will contain a ref to interface doc DJRA4.1 and some logic about how NSAP will return results based upon some crietia (criteria TBD). Scope of NSAP - get all combinations of request and responses - give all proper responses - decide on a scheme of how success failure responses will be returned. suggestion based upon requested b/w. - do a basic security check on certificates and named servers BAR security ============ Implement a basic security framework for MJRA4.4 [AKP/FS] to discuss what is required for a basic security framework Open issues =========== 1) How to get remote BAR for a specific endsite? Open point for tomorrow. See minutes for 2nd day's (10 May 2005). 2) "Egress Node" should be retrieved from the *remote* BAR. This will require an additional BAR-BAR interface 3) Need to write current state of BAR regularly to ensure state recovery. But how to ensure that full state is written/stored before BAR/NSAP crashes? 4) Question is if there will be more BAR-BAR communication than currently (Request/Cancel). If so the HLM-BAR and BAR-BAR interface needs to be separated. E.g. it is intended to ask the remote BAR for its Ingress Node (which is the Egress Node of the asking BAR). Be prepared to split the interface. 5) Defining an *optional" parameter in W3C schema - is it sufficient to specify "minoccur=0" or does it need "nillable" attribute etc ? Summary of actions ------------------ [AP] Change values od "Service Class" parameter in DJRA4.1 - Change to "IP Premium" [AP] Add optional "Direction" parameter to the "North Interface" If it not specified, specify value "bi-dirrection" for the south interface. [AP] add parameter for "ForwardBandwidth" and "Backwardbandwidth" [AP] Change name of the parameter from "Flow Identiifier" to "DSCP Marked" [FS] Test the latest BAR WSDL/Schema is Basic Profile 1.0 compliant. [AP] merge success and failiure objects to a one response object. [AP] Split into multiple operations (new request, cancel request, etc.) [AP] Update parameters as per interface document changes [AP] Change schema "direction" -> "both" to "bidirection" [AKP/FS] to discuss what is required for a basic security framework [AP] to update NSAP schema/wsdl - Have a single response object instead of success and failure - Instead of having a single top level element for request have multiple operations in the wsdl with different top level objects. - Use the term 'bi-directional' instead of 'both' for enumeration of direction in NSAP schema. - Use version instead of date for revision control of NSAP wsdl/schema [AP/FS] to investigate on XML extension mechanism and report. [FS] to send WS-I basic profile 1.0 test guidelines to AP. [AP] to write func spec for dummy NSAP - this will contain a ref to interface doc DJRA4.1 and some logic about how NSAP will return results based upon some crietia (criteria TBD). Scope of NSAP - get all combinations of request and responses - give all proper responses - decide on a scheme of how success failure responses will be returned. suggestion based upon requested b/w. - do a basic security check on certificates and named servers [RA] Discuss with Elisabetta and Jenni Schopps regarding GLUE schema.