120 likes | 143 Views
NSLP for Quality of Service. draft-ietf-nsis-qos-nslp-02.txt Slides: http://nsis.srmr.co.uk/~adm/qos-nslp-ietf59.ppt. Sven van den Bosch (ed) Georgios Karagiannis Andrew McDonald (et al.). ‘The Story’. Section 1 (& 2) give you the introduction What is this QoS NSLP thing?
E N D
NSLP for Quality of Service draft-ietf-nsis-qos-nslp-02.txt Slides: http://nsis.srmr.co.uk/~adm/qos-nslp-ietf59.ppt Sven van den Bosch (ed) Georgios Karagiannis Andrew McDonald (et al.)
‘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 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. RESERVE {QSpec1} RESERVE {QSpec2, QSpec1} RESERVE {QSpec2, QSpec1} RESERVE {QSpec1}
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?