1
An NSLP for Quality of Servicedraft-buchli-nsis-
nslp-00.txtdraft-mcdonald-nsis-qos-nslp-00.txtdr
aft-westberg-proposal-for-rsvpv2-nslp-00.txtSlide
s http//sigcomp.srmr.co.uk/reh/qos-nslp.ppt

• Maarten Buchli, Eric Waegeman, Alberto Conte,
  Sven van den Bosch, Andrew McDonald, Robert
  Hancock, Hannes Tschofenig, Cornelia Kappler,
  Lars Westberg, Attila Bader, David Partain, Vlora
  Rexhepi, Georgios Karagiannis
• IETF57 Vienna
• July 2003

2
Background

• NSIS needs to specify a signalling layer protocol
  for signalling Quality of Service
• So far, there are 3 (independent) individual
  submissions
• The authors have worked together to identify
  points of commonality, open issues, questions of
  scope,
• Here are some of the results
• See backup slides at the end for more detail

3
QoS-NSLP Features

• Read the requirements document
• Roughly carry information which manipulates
  forwarding resources for IP flows
• Similar to RSVP model in the abstract
• Soft state by default but, no multicast
• Sender as well as receiver initiation, proxy
  operation
• Correct handling of re-routing/failure/mobility
  events
• Consideration of scaling (aggregation, reduced
  state operation)
• AAA interactions and other security issues
• Independence from other signalling applications
  (for now)

4
Highlighted Issues

• Split between protocol and resource management
  definition
• Where is it? How is it reflected in the message
  set?
• How are state management responsibilities split?
• Message routing (beyond what the NTLP gives you)
• Making sender and receiver orientation work
• Aggregation and support for reduced state
  operation
• Security issues (surprise!)
• Flow representation and NAT traversal
• Need to capture additional requirements on NTLP

5
NSLP/Resource Mgt split

• Where is the dividing line between protocol
  definition stuff and stuff specific to a
  particular resource management method?
• Points of Commonality
• QoS NSLP should be useful for a number of
  resource management models (e.g. IntServ,
  DiffServ)
• NSLP does not know about available resources,
  bandwidth requested, DiffServ PHBs, etc. since
  these are internal to the resource management
  model
• An NSLP message has a type (e.g. RESERVE), and
  carries model specific QoS object(s) and other
  Objects
• Open Issue
• Should the protocol reflect views about what
  different types of reservations there can be and
  what operations can be done?
• Cf. split between RSVP and IntServ

6
Message Routing

• Points of Commonality
• Can send message to next (downstream) NSLP peer
• Can send message to previous (upstream) NSLP peer
• Requires reverse routing state at NTLP
• Can be used for sending error messages and other
  responses
• Open Issues
• How are responses routed?
• Peer-to-peer by NTLP or directly to another NSLP
  node
• We could define a mode of operation where the
  NSLP sends messages only in the forwards
  direction
• Then the NTLP wouldnt have to maintain reverse
  routing state
• How robust should we try to make this

7
Sender / Receiver Orientation

• Points of Commonality
• Both S-mode and R-mode are supported
• In S-mode, reservation can be sent immediately
• In R-mode, needs reverse routing state and some
  flow information in advance
• Open Issues
• How is reverse routing state installed?
• By a specific NSLP message, or signal at NTLP
  level only?
• How does S know when to do this?
• Have an NSLP message to do this, or leave it to
  the application?
• How does R know the flow info for R-mode
  signalling?
• Carried in an NSLP message from S (e.g. PATH), or
  by some other end-to-end signalling
• Where should reservation collisions be arbitrated?

8
Aggregation

• Aggregation must be supported (from NSIS Reqs)
• E2E reservations only handled at edges of
  aggregation region
• Aggregation can be achieved by
• Layered reservations (a bit like RFC 3175)
• Tunnelling (a bit like RFC 2746)
• Open issues
• Is aggregation a special requirement to a QoS
  NSLP?
• Tells us whether some aspects should be handled
  at NTLP level
• How to realize aggregation within the protocol?
• Independent (and differently acting) protocol
  layers within NSLP?
• Multiple QoS objects with nested scope in one
  message?
• Separate NTLP/NSLP instances for
  per-flow/aggregate?
• Are both S-mode and R-mode needed for the
  aggregate?

9
Security

• Points of Commonality
• Security required at to be done at the NSLP layer
• Security functionality could be at the NSLP only
  (independent of the resource management model)
• Type of interaction depends on the authorization
  model
• Open Issues
• Working group input required two drafts have
  been written
• NSIS Authentication, Authorization and Accounting
  Issues ltdraft-tschofenig-nsis-aaa-issues-01.txtgt
• QoS NSLP Authorization Issues ltdraft-tschofenig-n
  sis-qos-authz-issues-00.txtgt
• Is independent message protection needed at NSLP,
  or can NTLP do it?
• If so, what form should that message protection
  take?

10
What Next?
11
Backup Slides

• Yet more detail

12
QoS Objects

• Contents of QoS object should be opaque to the
  NSLP
• This is how several of the following subtleties
  are captured
• Two phase (reserve/commit) reservation
• Reservation range (minumum/desirable QoS)
• Partial reservations
• allow for reservation even if some nodes rejected
  it
• Accumulation of end-to-end QoS parameters (e.g.
  delay)
• Pre-emption of resources for one flow by another
• Can use protocol features appropriate for
  resource management functionality (e.g. stateless
  NTLP operation for per-class resource
  management) this is left as implementation
  freedom
• Problem of having interoperable QoS models needs
  to be addressed by someone by who and when?

13
State Management

• Points of Commonality
• The following semantics are needed
• RESERVE/TEAR/REFRESH (full and summary)/ACK/NACK
• Open issues
• Do we need the following explicitly?
• PATH (setup path state to allow receiver
  initiation)
• For particular resource management models, COMMIT
  (commit resources previously reserved)
• MODIFY (modify existing reservation)
• Is the full/summary distinction more to do with
  the QoS object?
• How are the semantics reflected as message types
• two message types manipulate state, reponse,
  OR
• one to one mapping between message types and
  semantics

14
State Non-Management

• Points of Commonality
• Messages may exist that do not modify state in
  NEs
• Such messages are useful for querying network
  state / reduced state operation
• Open issues
• Is there an additional message type to query
  network state?
• Useful for reduced state operation
• Useful for determining resource availability
• Is there an additional message type for
  notifications that (as opposed to Ack/Nack) are
  not in-reply-to another message?
• How determine that a message does not modify
  state in NEs?
• Depends on Message type
• Depends on objects in the message (PDR / PHR
  objects)
• Do we want specific diagnostic messages?

15
Rerouting and Path Repair

• Points of Commonality
• Detection
• Trigger from NTLP (may need to be passed
  peer-to-peer at NTLP level if not detected at
  local NTLP)
• From NSLP peer change (like a PHOP change in
  RSVP)
• Repair
• Install new reservation and remove on old path
  (somehow)
• Open Issues
• What changes are significant (e.g. i/f change but
  same peer)?
• How is a change in NSLP peer identified (NTLP
  support?)
• What other methods of route change detection can
  be used (e.g. at NSLP level from data flow
  monitoring)?
• Should an explicit tear be sent, and if so how?
• Requires the ability to invoke the old path
  explicitly at the NTLP

16
Bi-directional Reservation

• Bi-directionality is where one node takes
  signaling application responsibility for paired
  inbound/outbound flows
• Points of Commonality
• Bi-directional reservation should be supported
• Two proposed solutions (complementary, not
  competing) up to now
• Remotely initiated S-mode reservation for inbound
  flow
• Locally bundled S/R-mode reservations
• Open issues
• Should both reservation method(s) supported?
• Both approaches depend on some degree of routing
  symmetry (but in different ways)

17
Finding the NR

• Finding the NR can be a problem in both S-mode
  and R-mode
• In S-mode either
• We reach a QoS NSLP node which knows it is the
  NR
• Is last NTLP node and last QoS NSLP node finds
  out it is the NR when cant find next hop
  (requires NTLP support)
• Is last NTLP node, and doesnt support QoS NSLP
  finds out it is the last NTLP node, and NTLP
  sends message back upstream (requires NTLP
  support)
• In R-mode, on reaching a node without routing
  state, either
• This node knows it is the NR
• An attempt is made to create reverse path state
  this may take a variety of forms and may be
  purely part of the NSIS protocol, or involve some
  application interaction

18
Reduced State Operation

• Points of Commonality
• Nodes may use reduced NSLP states, e.g. per
  traffic class states
• Makes most sense in conjunction with reduced
  state mode of NTLP
• Open issues
• NTLP states are not stored in interior nodes,
  where is it problem?
• NTLP hop-by-hop routing is not possible within
  the domain
• Refresh should be NSLP process
• Handle re-routing if also edge node is changing
• Reservation should be sender initiated.
  Bi-directional reservation can be done in remote
  initiated way
• Inappropriate bundling, segmentation/reassembly
  may cause problems

19
Flow Representation and NAT Traversal

• Flow information
• traffic selector
• 4/5-tuple
• destination address prefix
• DSCP
• Open issue do we allow for multiple traffic
  selectors?
• e.g. multiple source/destination port nrs.
• allow for adding/removing traffic selectors?
• In case we assume NATs is only NTLP aware
• Have no IP address/port information at NSLP layer
• NSLP should use flow information from the NTLP
• impact on NTLP/NSLP interface
• If NTLP does proper NAT processing on flow id,
  does NSLP need to do anything?