NSLP for Quality of Service

1
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.)

2
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

3
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

4
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?

5
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
6
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

7
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!

8
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?

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

10
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

11
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?

12
?