QoS NSLP draft-ietf-nsis-qos-nslp-06.txt Slides: Sven van den Bosch, Georgios Karagiannis, Andrew McDonald IETF #62 – Minneapolis March 2005

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

Technical Issues

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

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?

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

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

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?

Editorial Issues

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 =

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

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’)

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

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

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