QoS NSLP draft-ietf-nsis-qos-nslp-06.txt Slides: nsis.srmr.co.uk/~adm/qos-nslp-ietf62

1. QoS NSLPdraft-ietf-nsis-qos-nslp-06.txtSlides: http://nsis.srmr.co.uk/~adm/qos-nslp-ietf62.ppt Sven van den Bosch, Georgios Karagiannis, Andrew McDonald IETF #62 – Minneapolis March 2005

2. Recent Changes • QoS / QSpec / QoS Model relationship clarifications • Removal of QSM/QSP terminology • Progress on security mechanisms • Reservation collision handling • Very useful review by Bob Braden • Not all comments dealt with in current draft

3. Technical Issues

4. NSLP / QoS Model split • Clarified scope • We’ve managed to avoid properly defining this for a long time • Believe that this is now aligned with the view in the QSpec draft • Core of the definition now: • NSLP = signalling protocol • QSpec = information for RMF • QoS Model = how QSpec is used and RMF behaves

5. QSpec • Some clarification still needed on QSpec/NSLP interactions • Things in the QSpec Template draft that ought to be in the NSLP • Hop counting • Revisit areas of the NSLP that haven’t been looked at recently • How does ‘stacking’ of QSpecs work? • Role of ‘QoS Model Identifiers’? Are they needed?

6. Sequence Numbers • Technical issues to address • Sequence number wrapping • Failure/restart handling • Also needs some clarification of purpose/scope • Does not assume in-order or guaranteed delivery from GIMPS • May use GIMPS reliable/sequenced delivery to improve performance

7. Reservation Collisions • Added clarifications • Two cases: • Different Session ID • Leave to endpoints to deal with • Same Session ID • Send error response back to sender of the second RESERVE

8. Authentication Mechanisms • Draft contains a proposal for mechanisms to provide the entity identification/authentication • Protocol components • Make use of GIMPS channel security • May be solution on its own, or part of a combined solution • Carry authorisation tokens • Tunnelling EAP (or something similar) • First two should be tackled. Not attempting to address the third for now – it is more complicated and it would need to be demonstrated that it really is needed first. Also, it is only applicable to the first hop. • Question: Is this the right approach?

9. Editorial Issues

10. GIMPS vs NTLP • Current text mostly refers to the lower layer signalling transport as GIMPS • (Will be) same standards maturity levels when RFCs • Abstract NTLP does not have well-defined functionality, but GIMPS does • Propose: Draft should use GIMPS and refer to GIMPS in terms of the service it provides defined by its API (but MUST NOT refer to GIMPS internals!). However, still use NTLP in some places where appropriate. • NB: GIMPS = <insert protocol name here>

11. Examples • Need enough, but not too many • Always the risk that implementors/users take examples as the definitive way to do it • Need to clarify the aims of the examples • Identify the significant differences between them • E.g. Bidirectional examples

12. Message Types and Flags • Flags in bit fields in QoS NSLP messages • Needs allocation policy • Trade off between more message types and use of flags (‘message sub-types’)

13. Other Editorial Issues • Now GIMPS has stabilised, change ‘requests on GIMPS’ to ‘use of GIMPS’ • Clarify how QoS NSLP uses the GIMPS mechanisms • Properly define ‘session’ concept • Summary refresh behaviour

14. Mobility Issues • Review problems identified by mobility draft • Some indicate issues requiring clarification in QoS NSLP • Not necessarily mobility specific issues

15. What Next? • Closing the remaining technical issues • In particular, continue fleshing out authentication mechanisms • Identification of any missing components/requirements • E.g. from RSVP updates/additions in TSVWG • Further editorial work • Consistency, clarity, precision, etc