1. Draft-ietf-nsis-qos-nslp-05.txt G. Karagiannis, A. McDonald, S. Van den Bosch

2. Main changes in -05 Introduced explicit state acknowledgment (next slide) Introduced explicit feedback mechanism in case of route changes (see further) Changed section 7 to reflect the use of GIMPS service interface Introduced default value (30s) for REFRESH_PERIOD Resolved outstanding clarification comments Likelihood of transport type Bi-directional reservations Handling of RESERVE messages inside a domain in case of aggregation or reduced state operation) from the mailing list

3. State acknowledgement Mailing list discussion Local state acknowledgement Acknowledgement by default Implementation ACKNOWLEDGE (A) - when set, indicates that an explicit confirmation of the state installation action is REQUIRED This flag SHOULD be set on transmission in RESERVE by default Triggers RESPONSE with ‘reservation request accepted’ response value Does not replace end-to-end RESPONSE which is triggered by RII

4. Explicit feedback mechanism Allow sending RESPONSE message with ‘unknown SID’ upstream indicates a downstream route change to the upstream peer The upstream peer SHOULD send a complete RESERVE on the new path (new SII) It identifies the old signalling association (old SII) and MAY start sending complete RESERVE messages for other SESSION_IDs linked to this association. QNE 1. RESERVE(SII_1)1. RESERVE(SII_2) 2. route change 3. REFRESH(SII_1)5. RESERVE(SII_3) 4. RESPONSE(‘unknown SID’) 6. RESERVE(SII_1’)

5. Use of extensibility flags CPRAB RSN10000 RII01010 REFRESH_PERIOD10000 BOUND_SESSION_ID01111 POLICY_DATA100/01100/11 QSPEC10000 ERROR_SPEC100/00000/01

6. Extensibility issues Assumptions ‘C’: a node would know that 'processing' an object means identifying it, not necessarily require any action from it Are they extensibility bits or ‘criticality’ bits? Should compliant nodes recognise ‘optional’ objects? Are all objects in the base spec necessarily C/00? What do the extensibility bits apply to? Some problems with applying flags as part of type code Different behaviour in different messages may be desired (e.g. NOTIFY versus RESPONSE) Does it apply to the object type or the actual instance of the object (e.g. specific ERROR codes) Side discussion Can you send NOTIFY with ‘C’ marked objects in it?

7. AAA Useful authorisation scenarios Host-to-network Network-to-network Note: 2-party vs 3-party model does not seem to affect QoS NSLP Reuse GIMPS channel security is possible Connection mode is used Authorisation is peer-to-peer Main issue: GIMPS service interface General mechanisms Token-based: only transport&identification of token needed EAP-encapsulation: supported by appropriate error codes Challenge-Response in EAP framework

8. Next steps Try to move AAA discussion forward Clarify QSPEC/QSP concepts Review/comment on proposed state diagrams