QoS-NSLP: Signalling Quality of Service for IP Networks

1. An NSLP for Quality of Servicedraft-buchli-nsis-nslp-00.txtdraft-mcdonald-nsis-qos-nslp-00.txtdraft-westberg-proposal-for-rsvpv2-nslp-00.txtSlides: 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 IETF#57 – 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 wouldn’t 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 Req’s) • 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 <draft-tschofenig-nsis-aaa-issues-01.txt> • QoS NSLP Authorization Issues <draft-tschofenig-nsis-qos-authz-issues-00.txt> • 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 can’t find next hop (requires NTLP support) • Is last NTLP node, and doesn’t 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?