An NSLP for Quality of Service draft-buchli-nsis-nslp-00.txt draft-mcdonald-nsis-qos-nslp-00.txt draft-westberg-proposal-for-rsvpv2-nslp-00.txt Slides: 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

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

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)

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

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

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

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?

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?

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 QoS NSLP Authorization Issues Is independent message protection needed at NSLP, or can NTLP do it? If so, what form should that message protection take?

What Next?

Backup Slides Yet more detail

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?

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

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?

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

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

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

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

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?