NSLP for Quality of Service Sven van den Bosch (ed) Georgios Karagiannis Andrew McDonald (et al.) draft-ietf-nsis-qos-nslp-02.txt Slides:

‘The Story’ Section 1 (& 2) give you the introduction What is this QoS NSLP thing? Section 3 gives an overview of the protocol What can I do with it? Why should I be interested in this protocol? Section 4 explains the protocol design What are the components? Why are they like that? Section 5 gives the detailed protocol definition How do I build one? How much you need to read depends on what you are interested in

Changes from -01 Message/object formats Messages Common Control Information (CCI) Layering Local QoS models Local control plane properties Aggregation Extensibility Priority State storage Re-routing AAA Additional NTLP requirements

Aggregation Change in flow-ID e.g. for aggregate tunnel 2 sessions analogous to RFC 3175 BOUND_SESSION_ID reference aggregate session from per-flow session Aggregate session can use different control plane properties and QoS model Requirement on NTLP Indication to bypass intermediate nodes Ref GIMPS section 8.4 Same techniques can be used to use different transport characteristics (e.g. connection / datagram mode) along parts of the path Does this cover the functionality that people have asked for?

Changing QoS Models RESERVE {QSpec1} RESERVE {QSpec2, QSpec1} RESERVE {QSpec2, QSpec1} RESERVE {QSpec1} As RESERVE enters the region, the end-to-end reservation is mapped into the local QoS Model, and put on top of QSpec stack. It is then popped off the stack at the egress.

Changing QoS Models – Error handling See discussion on list What happens if a QNE receives a message with a QSpec for a QoS model it does not understand? Main conclusions Should send error back to sender, and not attempt to recover itself Where no reverse-routing state is stored: could drop or forward GIMPS can only get an error message back one hop This means that the error handling is the same for the stacked case as for the single QSpec case

Using QoS Models New QoS models IANA registry of QoS model ID Standard, well-known, private use Extensions to existing QoS models No impact on QoS-NSLP IANA considerations To be done: validate QoS NSLP against some sample QoS Models May hear something tomorrow!

Reservation Priority Reservation priority E.g. Setup priority, Holding priority Supports preemption Can be provided as part of a QoS Model Should/can generic QoS NSLP functionality be provided?

Signalling Message Priority Would require NTLP support E.g. use of multiple connection mode associations Why? E.g. mobile scenario: signalling message loss during call set-up is less harmful then during handover (if GIMPS processing is congested part) When does it matter? Congestion control (at sending node) Flow control (from receiving node) Ref GIMPS section 8.5 (use of multiple signalling associations)

Scoping Ability to limit the scope of a message Similar, but different, to aggregation regions (or bound sessions with different NTLP transport requirements, etc) Is it useful? Can it be done? Where? NSLP or NTLP? Ref GIMPS section 8.9

Security/AAA Key components for the NSLP seem to be: Authorisation protection against theft of resources need to provide way for authentication of request and authorisation of resources to be performed Message protection protection against manipulation, replay, injection, etc the description of the resources required needs to be bound to the authorisation provided What do we get from NTLP?

?