Internet Draft Proposal for RSVPv2-NSLP April 2003 Internet Engineering Task Force L. Westberg INTERNET-DRAFT A. Bader Expires October 2003 D. Partain V. Rexhepi Ericsson G. Karagiannis University of Twente April 2003 A Proposal for RSVPv2-NSLP draft-westberg-proposal-for-rsvpv2-nslp-00.txt Document Version: $Revision: 2.1 $ Status of this memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet- Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Distribution of this memo is unlimited. Copyright Notice Westberg, et al. Expires October 2003 [Page 1] Internet Draft Proposal for RSVPv2-NSLP April 2003 Copyright (C) The Internet Society (2002). All Rights Reserved. Abstract The Resource ReSerVation Protocol (RSVPv1) has been on the standards track within the IETF for a number of years. During that time, the level of vendor support and deployment has been relatively slow, despite the demand for technologies offering services with different levels of quality of service to their customers. This memo seeks to initiate a dialog about the design of a new version of RSVPv1, called RSVPv2, that meet the requirements formulated by IETF NSIS working group. It also outlines the motivation for using RSVP2 as "next step in signaling". The RSVPv2 framework uses the layer-split architecture separating signaling application and transport functions. This concept was adopted by NSIS WG and the two layers are called NSLP NSIS Signaling Layer Protocol (NSLP) and NSIS Transport Layer Protocol (NTLP). This draft provides design guidelines and specifications for the development of the RSVPv2 NSLP part. RSVP2-NSLP offers increased modularity and contains less mandatory objects compared to RSVPv1, which allow lightweight implementation and flexible application. The new protocol is extended with PHR and PDR objects that makes it possible to use the protocol in different part of multi-domain networks and use the protocol in DiffServ environment. Westberg, et al. Expires October 2003 [Page 2] Internet Draft Proposal for RSVPv2-NSLP April 2003 Table of Contents 1 Introduction ................................................. 5 1.1 Definitions/Terminology .................................... 6 2 Motivation for RSVPv2 ........................................ 10 2.1 Limitation of RSVPv1 design ................................ 11 2.1.1 Designed for Multicast Applications ...................... 11 2.1.2 Least Common Denominator Not Small Enough ................ 11 2.1.3 Sender-initiated versus Receiver-initiated Signalling ........................................................... 12 2.1.4 Designed for End-host to End-host Communication .......... 13 2.2 Different Network Signalling Requirements/Needs and RSVP ........................................................... 13 3 Design Goals and General Features for RSVPv2-NSLP ............ 14 3.1 Increased Layer Modularity and Extendibility ............... 14 3.2 Increased Object Modularity ................................ 15 3.3 Hierarchical Object Structure .............................. 15 3.4 Global and Local Objects ................................... 16 3.5 Local information exchange ................................. 16 3.6 Object Re-use .............................................. 17 3.7 Reduced Focus on Multicast ................................. 17 3.8 Primarily Sender-initiated Signalling ...................... 17 3.9 Low latency in setup ....................................... 17 3.10 Highest possible network utilization ...................... 18 3.11 Uni / bi-directional reservation .......................... 18 3.12 End-to-end ................................................ 18 3.13 Edge-to-edge .............................................. 18 3.14 End-to-edge ............................................... 19 4 Overview of the RSVPv2-NSLP Framework ........................ 19 4.1 RSVPv2 NSLP protocol features provided by the intra-do- main level ...................................................... 22 4.1.1 PDR protocol part functions .............................. 23 4.1.2 PHR protocol part functions .............................. 23 4.2 RSVPv2 NSLP protocol features provided by the e2e service level ..................................................... 25 5 RSVPv2 NSLP specification .................................... 26 5.1 RSVPv2 NSLP Object Classes structure ....................... 26 5.1.1 RSVPv2 NSLP Message Structure ............................ 29 5.2 RSVPv2-NSLP Objects in RSVPv2-NSLP Object_Classes .......... 29 5.2.1 Example of mapping of RSVPv1 [RFC2205] objects in ........ 30 5.2.2 PDR/PHR objects .......................................... 33 5.3 RSVPv2-NSLP functionality on nodes used for inter-domain signaling ................................................. 33 5.3.1 NI (NSIS Initiator) functionality ........................ 33 5.3.1.1 Unidirectional functionality ........................... 33 5.3.1.2 Bidirectional functionality ............................ 35 Westberg, et al. Expires October 2003 [Page 3] Internet Draft Proposal for RSVPv2-NSLP April 2003 5.3.2 NF (NSIS Forwarder) functionality ........................ 36 5.3.2.1 Unidirectional functionality ........................... 36 5.3.2.2 Bidirectional functionality ............................ 38 5.3.3 NR (NSIS Responder) functionality ........................ 39 5.3.3.1 Bidirectional functionality ............................ 40 5.4 RSVPv2-NSLP functionality on nodes used for intra-domain signaling ................................................. 41 5.4.1 NI (NSIS Initiator) functionality ........................ 41 5.4.1.1 Unidirectional functionality ........................... 42 5.4.1.2 Bidirectional functionality ............................ 42 5.4.2 Functionality of NF (NSIS Forwarder) located outside NSIS intra-domain ......................................... 42 5.4.2.1 Unidirectional functionality ........................... 42 5.4.2.2 Bidirectional functionality ............................ 42 5.4.3 NF (ingress) functionality ............................... 42 5.4.3.1 Unidirectional functionality ........................... 43 5.4.3.2 Bidirectional functionality ............................ 48 5.4.4 NF (interior) functionality .............................. 49 5.4.4.1 Unidirectional functionality ........................... 49 5.4.4.2 Bidirectional functionality ............................ 51 5.4.5 NF (egress) functionality ................................ 51 5.4.5.1 Unidirectional functionality ........................... 52 5.4.5.2 Bidirectional functionality ............................ 55 5.4.6 NR (NSIS Responder) functionality ........................ 56 5.4.6.1 Unidirectional functionality ........................... 56 5.4.6.2 Bidirectional functionality ............................ 56 6 Example of RSVPv2-NSLP Inter-domain signaling procedures ..... 57 6.1 Normal operation for uni-directional reservation ........... 57 6.2 Normal operation for bi-directional reservation ............ 62 7 Example of RSVPv2-NSLP Intra-domain signaling procedures ..... 65 7.1 Normal operation for uni-directional reservation ........... 65 7.2 Example of Fault Handling Operation ........................ 80 7.2.1 Loss of NTLP signalling messages ......................... 81 7.2.2 Severe Congestion Handling operation ..................... 81 7.2.2.1 Proportional marking ................................... 82 7.3 Example of Adaptation to load sharing operation ............ 84 7.4 Normal operation for bi-directional reservation ............ 84 8 Appendix - Examples of PHR and PDR object specifications ........................................................... 90 8.1 PHR objects ................................................ 90 8.2 PDR objects ................................................ 93 9 References ................................................... 98 10 Authors' Addresses .......................................... 101 Westberg, et al. Expires October 2003 [Page 4] Internet Draft Proposal for RSVPv2-NSLP April 2003 1. Introduction A number of different QoS solutions have been developed by the IETF, amongst them IntServ and its signaling protocol, RSVPv1, defined in [RFC2205]. RSVPv1 [RFC2205] is a resource reservation signaling protocol that was designed to be applied in an end-to-end communication path. It can be used by an application to make its QoS requirements known and reserve resources in all the network nodes in the path. RSVPv1 has not enjoyed the level of deployment that might have been expected. This is due to issues such as design constraints as it is optimized for multicast, etc. [RFC2475, RFC3175, etc]. This memo seeks to initiate a dialog about the design of a new version of RSVPv1, which we call RSVPv2. The goal of the RSVPv2 framework would be to rectify the issues that have been identified with RSVPv1 and provide an evolutionary path forward. The RSVPv2 framework uses the concept introduced in [BrLi01] that splits signaling protocol into two layers: (1) a common lower level protocol that performs transport-layer and soft-state functions. This common lower level is called CSTP ("Common Signaling Transport Protocol"). (2) a set of upper-level signaling functions that are specific to particular signaling applications. These upper-level signaling tasks and functions are accomplished by a set of ULSPs ("User Layer Signaling Protocols). The CSTP together with the set of ULSPs will implement the Internet Signaling Protocol Suite (ISPS). The NSIS working group adopted this concept denoting the two protocols as NSIS Transport Layer Protocol (NTLP) and NSIS Signaling Layer Protocol (NSLP), respectively [Hanc03]. This memo outlines the motivation for using RSVPv2-NSLP as NSIS Signaling Layer Protocol. It provides a design guideline and specification for RSVPv2-NSLP. Note that in order to be able to communicate with NTLP, RSVPv2-NSLP needs to use an NSLP Identifier that has to be assigned by the NSIS WG. RSVPv2-NSLP specified in this draft is able to interwork with NTLP specified in [WeKa03]. Westberg, et al. Expires October 2003 [Page 5] Internet Draft Proposal for RSVPv2-NSLP April 2003 1.1. Definitions/Terminology Interdomain traffic: Traffic that passes from one NSIS domain to another ([identical to [Hanc03]). Intra-domain NSIS signaling is where the NSIS signaling messages are originated, processed and terminated within the same NSIS domain. NSIS Domain (ND) (identical to [Hanc03]): Administrative domain where an NSIS protocol signals for a resource or set of resources. NSIS Entity (NE) (identical to [Hanc03]): the function within a node which implements an NSIS protocol. In the case of path-coupled signaling, the NE will always be on the data path. NSIS Forwarder (NF) (identical to [Hanc03]): NSIS Entity between a NI and NR which may interact with local resource management function (RMF). It also propagates NSIS signaling further through the network. NF Edge nodes: NF Nodes that are located at the boundary of an administrative domain, e.g., Diffserv. This node is a NTLP stateful node. NF Interior node: All the nodes that are part of an administrative domain, e.g., Diffserv, and are not NF edge nodes. An interior node can be either a NTLP stateful node or a NTLP stateless node. NF Ingress node: An NF edge node that handles the traffic as it enters the domain. This node is a NTLP stateful node. NF Egress node: Westberg, et al. Expires October 2003 [Page 6] Internet Draft Proposal for RSVPv2-NSLP April 2003 An NF edge node that handles the traffic as it leaves the domain. This node is a NTLP stateful node. NSIS Initiator (NI) (identical to [Hanc03]): NSIS Entity that initiates NSIS signaling for a network resource. NSIS Responder (NR) (identical to [Hanc03]): NSIS Entity that terminates NSIS signaling and can optionally interact with applications as well. NSIS Signaling Layer Protocol (NSLP) (identical to [Hanc03]): generic term for an NSIS protocol component that supports a specific signaling application. NSIS Transport Layer Protocol (NTLP) (identical to [Hanc03]): placeholder name for the NSIS protocol component that will support lower layer (signaling application independent) functions. NTLP aware node: a node that implements and supports the NTLP protocol. NTLP stateful node: a NTLP aware node that maintains a NTLP transport layer state. NTLP stateless node: a NTLP aware node that does not maintain a NTLP transport layer state. NE NTLP stateful NE entity that is NTLP stateful. NE NTLP stateless NE entity that is NTLP stateless. NF NTLP stateful Westberg, et al. Expires October 2003 [Page 7] Internet Draft Proposal for RSVPv2-NSLP April 2003 NF entity that is NTLP stateful. NF NTLP stateless NF entity that is NTLP stateless. Resource Management Function (RMF) (identical to [Hanc03]): an abstract concept, representing the management of resources in a domain or a node. End Host: QoS-aware end terminal, either fixed or mobile, i.e. running QoS-aware applications. This node is a NTLP stateful node and it can be considered as a NI or a NR. RSVPv2 NSLP: an NSLP type that can be a part of the RSVPv2 framework. NSLP intra-domain: a domain that supports NSIS intra-domain signaling. Classifier - an entity which selects packets based on the content of packet headers according to defined rules. DS behavior aggregate (identical to [RFC2475]): A collection of packets with the same DS codepoint crossing a link in a particular direction. DS-compliant (identical to [RFC2475]): Enabled to support differentiated services functions and behaviors as defined in [RFC2474], this document, and other differentiated services documents; usually used in reference to a node or device. Interdomain traffic - Traffic that passes from one NSIS domain to another Intra-domain NSIS signaling is where the NSIS signaling messages are originated, processed and terminated within the same NSIS domain. Westberg, et al. Expires October 2003 [Page 8] Internet Draft Proposal for RSVPv2-NSLP April 2003 NSIS Forwarder (NF) - NSIS Entity on the path between a NI and NR which may interact with local resource management function (RMF) The NSIS Forwarder also propagates NSIS signaling further through the network (identical to [Hanc03]). Note that NF can be also considered as a RSVPv2 forwarder. NSIS Initiator (NI) - NSIS Entity that initiates NSIS signaling for a network resource (identical to [Hanc03]). Note that NI can be also considered as a RSVPv2 initiator. NSIS Responder (NR) - NSIS Entity that terminates NSIS signaling and can optionally interact with applications as well (identical to [Hanc03]). Note that NR can be also considered as a RSVPv2 responder. Path-coupled signaling - a mode of signaling where the signaling messages follow a path that is tied to the data messages (see [Hanc03]). Path-decoupled signaling - signaling with independent data and signaling paths (see [Hanc03]). Per Hop Behavior (PHB) (identical to [RFC2475]): The externally observable forwarding behavior applied at a DS-compliant node to a DS behavior aggregate. Per Hop Reservation (PHR): The per-hop resource reservation in a Diffserv domain, extending the Diffserv PHB, e.g., the bandwidth allocated to an AF PHB (see RFC2597]), with resource reservation. It is implemented at both the interior nodes and the edge nodes. Per Hop Reservation (PHR) protocol: A type of protocol that is used to perform a per hop reservation. A PHR protocol part is used in all nodes in the Diffserv domain (both edge and interior nodes) on a hop by hop basis. Per Domain Behavior (PDB)(similar to [NiKa01]): Describes the behavior experienced by a particular set of packets as they cross a DS domain. A PDB is characterized Westberg, et al. Expires October 2003 [Page 9] Internet Draft Proposal for RSVPv2-NSLP April 2003 by specific metrics that quantify the treatment that a set of packets with a particular DSCP (or set of DSCPs) will receive as it crosses a DS domain. Per Domain Reservation (PDR): The resource reservation functionality in the complete Diffserv domain. Per Domain Reservation (PDR) protocol: A type of signaling protocol used to perform a per domain reservation signaling. A PDR protocol part is used by NF(edge) nodes (NF(ingress) and NF(egress)), but not by the NF(interior) nodes. Resource - something of value in a network infrastructure to which rules or policy criteria are first applied before access is granted. Examples of resources include the buffers in a router and bandwidth on an interface The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. 2. Motivation for RSVPv2 Embarking on the adventure of creating RSVPv2 is not to be done lightly. A great deal of effort was put into the design of the IntServ model and its signaling protocol, RSVPv1. As such, there must be a clear need for the evolution of the QoS signaling part of RSVPv1. This section tries to provide that motivation. We believe that this work can be accomplished by examining the design constraints placed upon the development of RSVPv1 and eliminate these constraints in RSVPv2 design. Westberg, et al. Expires October 2003 [Page 10] Internet Draft Proposal for RSVPv2-NSLP April 2003 2.1. Limitation of RSVPv1 design RSVPv1 is well-designed for the applications for which it was intended and worked hard to provide a modular protocol within the constraints of its intended use. We see value in questioning the applications chosen, thereby improving the protocol. This section outlines some of the design considerations that went into the design of RSVPv1, which in turn led to decisions that make it difficult to use RSVPv1 beyond its originally-intended scope. 2.1.1. Designed for Multicast Applications One of the most important design requirement for RSVPv1 was support for multicast applications. RFC 1633 [RFC1633] states, "There are a number of requirements to be met by the design of a reservation setup protocol. It should be fundamentally designed for a multicast environment...." Multicast support introduces a level of complexity into the protocol that is not needed in support of unicast applications. For example, RSVPv1's state maintenance is complex as it needs to support dynamic membership changes in the multicast groups, such as reservation state merging and maintenance. Our working assumption is that RSVPv2 should be optimized for unicast rather than multicast and that relaxing this design constraint will in turn greatly simplify the protocol. 2.1.2. Least Common Denominator Not Small Enough Rightfully so, RSVPv1 put a great deal of effort into creating a modular protocol with the ability to use those pieces that apply in a particular setting. However, this modularity was created with the backdrop of multicast applications. This means that, while modular to some degree, even the "least common denominator" of objects that must be carried is too heavy in some networking contexts. That is, while flexible, RSVPv1 does not allow for more lightweight implementations if fewer features are needed in certain parts of the network. Westberg, et al. Expires October 2003 [Page 11] Internet Draft Proposal for RSVPv2-NSLP April 2003 The fact that the least common denominator is too heavy means that: * Some objects are always carried in RSVPv1 messages that are not applicable in some settings. * There is an expectation of the same level of protocol functionality throughout the network(s). Clearly, different parts of the network need different levels of functionality, a differentiation not supported by RSVPv1. On May 20, 2002, Bob Braden, one of the creators of RSVPv1, wrote the following on the NSIS working group's mailing list [NSIS-ML1]: "...RSVP may have had the modularity wrong.... RSVP design and specification may have talked too much about int-serv specific things like Tspecs. We should instead have defined RSVP strictly in terms of transporting opaque QoS objects upstream and downstream...." Our working assumption is that RSVPv2 can be created with even more modularity to enable its use in most (if not all) networking contexts. In particular, we believe that RSVPv2 can be made more suitable for use in the different parts of the network where requirements on the signaling protocol differ greatly. 2.1.3. Sender-initiated versus Receiver-initiated Signalling RSVPv1 is receiver-oriented, which is to say that the receiver of a data flow initiates and maintains the resource reservation used for that flow. This choice was made despite the fact that sender- initiated reservations are "perhaps the most obvious choice" since sender-initiated reservations "scale poorly for large, dynamic multicast delivery trees and for heterogeneous receivers" (Section 5.1.3, RFC 1633 [RFC1633]). These two problems were solved by using receiver-initiated reservations. Our working assumption is that relaxation of the requirement for multicast support will also allow for sender-initiated reservations without introducing scalability problems. Westberg, et al. Expires October 2003 [Page 12] Internet Draft Proposal for RSVPv2-NSLP April 2003 2.1.4. Designed for End-host to End-host Communication RSVPv1 was primarily designed with signaling between end-host systems in mind. This communication implies a certain set of requirements on the entities involved and on the kinds of information that they need to signal. In recent work (particularly in NSIS), it has become clear that there are in fact several different kinds of signaling conversations that may be needed in different parts of the network. Each of these kinds of signaling implies a different -- and potentially conflicting -- set of requirements on the signaling protocol. For example, the signaling requirements for the conversation between the end-host and the network may indeed need more complexity than RSVPv1 whereas the signaling needs in a DiffServ-capable access network would require significantly less. Our working assumption is that RSVPv2 must be designed to allow an appropriate set of objects to be defined for the various "interfaces" (e.g., host-to-network, edge-to-edge, end-to-end) used in various parts of the network while not including any mandatory objects that are not applicable in all parts of the network. 2.2. Different Network Signalling Requirements/Needs and RSVP As previously mentioned, RSVPv1 put a great deal of effort into creating a modular protocol with the ability to use those pieces that apply in a particular setting. However, while flexible, RSVPv1 does not allow for more lightweight implementations if fewer features are needed in certain network scenarios. This section provides a (non-exhaustive) list of scenarios where there seems to be a need for new tools, either because the need for optimization is sufficiently strong or the scenario was not considered in the design of RSVPv1. * Networks with semi-permanent trunk aggregation: In such networks the transmission links are not expensive and semi-permanent trunk aggregation can be applied. * Networks with trusted end hosts: In these networks the security requirements are less important. Such networks are Westberg, et al. Expires October 2003 [Page 13] Internet Draft Proposal for RSVPv2-NSLP April 2003 the networks used between PSTN (Public Switched Telephone Networks) gateways and backbone routers [PAN-SSP]. * Networks with untrusted mobile end hosts: In these networks the security requirements between the first hop access router and the untrusted mobile end host are very significant. Such networks are the networks that use wireless LAN (WLAN) access [RFC2002]. * Networks that have to support fast and frequent mobility procedures (e.g., handover), where the transmission links are expensive, and the majority of the traffic is unicast. Cellular radio access networks are examples of such networks. [RAN-ISSUE]. 3. Design Goals and General Features for RSVPv2-NSLP This section briefly outlines some of the guiding principles behind the design of RSVPv2-NSLP. Moreover, the RSVPv2 NSLP general features are described. These design goals and features are in line with some of the NSIS requirements described in [Bru03] and [Hanc03]. 3.1. Increased Layer Modularity and Extendibility The essential design goal for RSVPv2 framework is to preserve the flexibility of RSVPv1 while at the same time further expanding its modularity. It can be fulfilled by using the NTLP-NSLP layer-split architecture. The RSVPv2-NSLP protocol can be considered as an NSLP that will use a subset of the transport layer functions provided by the NTLP (see for example [WeKa03]) such as: * Support of Path-Coupled (Path-Directed) Signaling; * Soft state support: This feature ensures that a state will be removed if it is not periodically refreshed or explicitly removed. * Adaptation to load sharing. Load sharing allows NF interior nodes to take advantage of multiple routes to the same Westberg, et al. Expires October 2003 [Page 14] Internet Draft Proposal for RSVPv2-NSLP April 2003 destination by sending via some or all of these available routes. The NTLP protocol level has to adapt to load sharing once it is used. * The NTLP signaling protocol should be able to exchange local information between NSIS Forwarders located within one single administrative domain. Local information might, for example, be IP addresses, severe congestion notification, notification of successful or erroneous processing of signaling messages. 3.2. Increased Object Modularity The purpose of the object modularity is to increase processing efficiency of RSVPv2 NTLP messages by only including those objects relevant in a particular part of the network. RSVPv1 uses flexible object definitions that are opaque to RSVPv1 for transporting and maintaining traffic and policy control parameters. This type of object definition has certain advantages in terms of flexibility, but one of its main disadvantages is that each RSVPv1 message may contain up to fourteen classes of attribute objects. Even if some of the RSVPv1 objects are not needed in a scenario they will have to be included in RSVPv1 messages and considered as mandatory objects. In order to achieve modularity, the RSVPv2-NSLP object structure will need to have less (possibly no) "mandatory" functionality and allow a more open object structure. This open object structure can be solved by enhancing the RSVPv1 object structure and by introducing a concept of "profiles". A profile is a specification of which RSVPv1 objects are needed for a certain network scenario (see Section 2.2 above). In this way, the RSVPv1 messages will only carry the RSVPv1 objects that are required and specified by each profile. The profile concept makes use of profile identifiers to separate different profiles used in RSVP aware nodes. 3.3. Hierarchical Object Structure RSVPv1, even in its simplest form, still uses objects and features that are not needed in all routers (nodes) used in a network Westberg, et al. Expires October 2003 [Page 15] Internet Draft Proposal for RSVPv2-NSLP April 2003 scenario. For example, in a network scenario with WLAN access, the QoS signaling protocol used between the access router and the untrusted mobile end host requires strong security procedures. However, the QoS signaling protocol used in the same network scenario between the same access router and another router will not require the same security procedures. Another example is a network with semi-permanent trunk aggregation, where the edges of such a network have to provide aggregator/deaggregator features, e.g., maintenance of both per micro-flow and per aggregated flow reservation states, while the interior nodes require only simpler functionality, e.g., maintenance of per aggregated flow reservation states. The RSVPv2 framework will endeavor to improve this by providing a hierarchical structure and positioning of the RSVPv2 NSLP objects within RSVPv2 messages for each networking scenario. Each profile used for a network scenario will have to specify how the objects are structured into the RSVPv2 NSLP message and how they should be processed by a router. The objects that will be processed by all routers used in a network scenario will be placed as the first ones in the object sequence of the RSVPv2 NSLP message. Objects that will be processed only in specific routers can be placed later in the sequence. 3.4. Global and Local Objects NSLP RSVPv2's object space will consist of globally-understood objects ("global objects") and locally-understood objects ("local objects"). The purpose of this division is to provide additional flexibility in defining the objects carried by the RSVPv2 protocol such that only those objects that are applicable in a particular setting are used. The appropriate fora for defining these objects and how to manage the object space is obviously still a very open question. 3.5. Local information exchange The signaling protocol MUST be able to exchange local information between NSIS Forwarders located within one single administrative domain. Local information might, for example, be IP addresses, severe congestion notification, notification of successful or erroneous processing of signaling messages. Westberg, et al. Expires October 2003 [Page 16] Internet Draft Proposal for RSVPv2-NSLP April 2003 In some cases, the NSIS signaling protocol MAY carry identification of the NSIS Forwarders located at the boundaries of a domain. However, the identification of edge should not be visible to the end host (NSIS Initiator) and only applies within one administrative domain. 3.6. Object Re-use Obviously, whenever it is appropriate, RSVPv2 will re-use objects that are defined for RSVPv1. 3.7. Reduced Focus on Multicast Given the complexity that multicast support introduces to QoS signalling and the fact that the vast majority of the traffic in typical IP networks is point-to-point unicast transport, RSVPv2 will be optimized to operate as a sender-initiated protocol for unicast data flows. This should not be interpreted to mean that multicast support is not important and should not be supported. Given the increased modularity of RSVPv2 framework, it is entirely possible that appropriate objects will be defined in support of multicast. 3.8. Primarily Sender-initiated Signalling Given a reduced focus on multicast, the "obvious" choice of sender- initiated signalling seems to be applicable to the NSLP RSVPv2. The receiver-initiated reservations will undoubtedly still be needed in some network scenarios, so the RSVPv2 framework will need to handle such reservations as well. However, this feature will be optional. 3.9. Low latency in setup The RSVPv2 framework SHOULD allow for low latency setup of reservations in scenarios, where reservations are in a short time scale (e.g. handover in mobile environments), or where human interaction is immediately concerned (e.g., voice communication setup delay). Westberg, et al. Expires October 2003 [Page 17] Internet Draft Proposal for RSVPv2-NSLP April 2003 3.10. Highest possible network utilization There are networking environments that require high network utilization for various reasons, and the signaling protocol SHOULD do its best ability support high resource utilization while maintaining appropriate QoS. In networks where resources are very expensive (as is the case for many wireless networks), efficient network utilization is of critical financial importance. On the other hand there are other parts of the network where high utilization is not required. 3.11. Uni / bi-directional reservation Both unidirectional as well as bi-direction reservations SHOULD be possible. With bi-directional reservations we mean here reservations having the same end-points. But the path in the two directions does not need to be the same. The goal of a bi-directional reservation is mainly an optimization in terms of setup delay. There is no requirements on constrains such as use the same data path etc. 3.12. End-to-end When used end-to-end (see also [Hanc03]), the RSVPv2 NSLP protocol is initiated by an end host and is terminated by another end host. In this context, RSVPv2 NSLP can be applied as needed within all of the RSVPv2 NSLP domains between the end hosts. In the end-to-end path, RSVPv2 NSLP may be used both for intra-domain RSVPv2 NSLP signaling, as well as for inter-domain signaling. 3.13. Edge-to-edge In this scenario (see also [Hanc03]) the RSVPv2 NSLP protocol is initiated by an edge node of a RSVPv2 NSLP domain and is terminated by another edge node of the same (or possibly different) RSVPv2 NSIS domain. RSVPv2 NSLP can be applied either within one single RSVPv2 NSLP domain, which is denoted as edge-to-edge in a single domain, or within a concatenated number of RSVPv2 NSLP domains, which is denoted as edge-to-edge in a multi-domain. When an appropriate security trust relation exists between two or more concatenated RSVPv2 NSLP domains, these concatenated RSVPv2 NSLP domains are considered, in terms of RSVPv2 NSLP, to be a single, larger RSVPv2 NSLP domain. Westberg, et al. Expires October 2003 [Page 18] Internet Draft Proposal for RSVPv2-NSLP April 2003 3.14. End-to-edge In this scenario (see also [Hanc03]) the RSVPv2 NSLP protocol is either initiated by an end host and is terminated by an edge node or is initiated by an edge node and is terminated by an end host. In the path-coupled case, the edge node may be a proxy that is located on a boundary node of a RSVPv2 NSLP domain. 4. Overview of the RSVPv2-NSLP Framework The RSVPv2 protocol can be considered as an NSLP that will use a subset of the transport layer functions provided by the NTLP protocol level (see for example, [WeKa03]). The RSVPv2 protocol can be used for End-to-End, Edge-to-Edge, and End-to-Edge scenarios. In the End- to-End scenario the both NSIS end nodes are functioning as NSIS Initiators (NI) and NSIS Responders (NR). In the Edge-to-Edge scenario, both NSIS edge nodes are functioning as NI, NR and NSIS Forwarders (NF). In the End-to-Edge scenario the NSIS end host is functioning as a NI or NR and the edge node is functioning as a NI, NR and NF. The NSLP can consist of one protocol level or it can be separated into more than one hierarchical levels. Figure 1 shows the NSIS protocol that consists of one NTLP level and one NSLP level. |-----| |-------| |-------| |-------| |-------| |-----| |NSLP |<->| NSLP |<->| NSLP |<->| NSLP |<->| NSLP |<->| NSLP| | |<->| |<->| |<->| |<->| |<->| | | | | | | | | | | | | | ----- ------- ------- ------- ------- ----- |NTLP |<->| NTLP |<->| NTLP |<->| NTLP |<->| NTLP |<->| NTLP| | |<->| |<->| |<->| |<->| |<->| | |-----| |-------| |-------| |-------| |-------| |-----| NI NF NF NF NF NR Figure 1: One level used for RSVPv2 NSLP signaling The NSLP depicted in Figure 1 includes a set of upper-level signaling functions that are specific to particular signaling applications. Westberg, et al. Expires October 2003 [Page 19] Internet Draft Proposal for RSVPv2-NSLP April 2003 Such functions could, for example, be end to end resource reservation signaling, security, policy, billing, etc. In Figure 2 the NSIS protocol is shown, which consists of one NTLP level and two NSLP hierarchical levels. However, the approach is quite general to more NSLP hierarchical levels: the important issue is the use of NSLP at more than one level at all. This type of hierarchical level separation can for example, be applied for intra-domain signaling in order to maximize the scalability in an NSIS intra-domain. The lowest hierarchical level in Figure 2 represents the NTLP level protocol. Note that in this the NF nodes are usually considered to be NTLP stateful nodes. This holds also for the NF nodes used at the boundary of a domain, i.e., the NF edge nodes. However, as described in [WeKa03], the NF interior nodes of a domain can be considered to be NF stateful nodes (see Figure 1) or, when processing optimization is required, the NF interior nodes can be NF stateless nodes (see Figure 2). The NF stateful nodes are NF NTLP aware nodes that maintain a NTLP state by using the NTLP soft state principle and are able to process and modify the application level information (NSLP) that is transported by the NTLP protocol. The NF NTLP stateless nodes are NF NTLP aware nodes that do not maintain a NTLP state, but they are able to process and modify the application level information (NSLP) that is transported by the NSLP protocol. The RSVPv2 NSLP framework depicted in Figure 2 is separated in two levels: * the intra-domain level (located above the NTLP level), that is composed by two protocol parts the Per Domain Reservation (PDR) protocol part and the Per Hop Reservation (PHR) level. Note that these two protocol parts are simialr to the two protocols (PDR and PHR) that are described in the Resource management in Diffserv (RMD) scheme [RMD-frame]. In order to maximize the scalability in the RSVPv2 intra-domain the complexity imposed by the combination of the RSVPv2 NSLP and NTLP has to be moved as much as possible away from the interior nodes. Therefore, the RSVPv2 NTLP separates the problem of a complex reservation within a domain from a simple reservation within a node. This is accomplished by specifying two types of resource reservation protocol parts into the RSVPv2 NSLP intra-doamin. The first resource reservation protocol part type is denoted as Per Westberg, et al. Expires October 2003 [Page 20] Internet Draft Proposal for RSVPv2-NSLP April 2003 Hop Reservation (PHR) that enables the signaling of the resources to be reserved per traffic class (e.g., Diffserv Per Hop Behavior (PHB) class) in each node within a domain. This protocol type is optimized to reduce the requirements placed on the functionality of the NF interior nodes of the domain. For example, the nodes that implement this protocol type do not have per flow responsibilities. This protocol can be either reservation-based or measurement-based. In the reservation-based PHR, each node keeps only one reservation state per each supported traffic class. In the measurement-based PHR no reservation states are installed and the resource availability is checked by measuring traffic (user) data load. In the NF interior nodes there is no NTLP state and there is no PDR functionality. Note that these NF interior nodes are NTLP stateless nodes. The second protocol type is denoted as Per Domain Reservation (PDR) and is responsible for the resource reservation signaling on the NF edge nodes. The PDR is used by NF edge nodes (ingress and egress) but not by the interior nodes. This protocol introduces strict and complex requirements on the functionality implemented on the edge nodes. An example of such functionality is the mapping of the "global" traffic parameters signalled by the e2e service level (see Figure 2) to "local" parameters that are useful to the intra-domain scheme. Note that in the NF edge nodes (NF ingress and NF egress) a NTLP state is maintained and both PDR and PHR functionalities are active. * the e2e service level is located above the PDR/PHR level and includes a set of upper-level signaling functions that are specific to particular signaling applications. Such functions could, for example, be end to end resource reservation signaling, security, policy, billing, etc. The interface between the RSVPv2 NSLP and NTLP can be based on an API (Application Program Interface) and for the time being, is out of scope of this memo. As shown in Figure 2, the two NSLP hierarchical levels might be applied on different NSIS entities. This architecture for NSIS (e.g., RSVPv2) signaling can be provided by using: Westberg, et al. Expires October 2003 [Page 21] Internet Draft Proposal for RSVPv2-NSLP April 2003 *) a single end-to-end NSIS (e.g., RSVPv2) protocol that supports both NLSP hierarchical levels *) two independent NSIS (e.g., RSVPv2) protocols: the e2e service level is supported by an end-to-end NSIS protocol, and the PDR/PHR level is supported by another edge-to-edge NSIS (e.g., RSVPv2) protocol. |------| |-------| |-------| |------| | e2e |<--| e2e |<------------------------->| e2e |<->| e2e | service|<->|service| |service|<->|service | | |-------| |-------| |------| | | | | | | | | | | |-------| |-------| |-------| |-------| | | | | |PDR/PHR|<->| PHR |<->| PHR |<->|PDR/PHR| | |NSLP | | | | | | | | | | | | ^ | | |-------| |-------| |-------| |-------| | | | --------------------------------------------------------------------- | | | | | | | | | |------| |-------| |-------| |-------| |-------| |------| V | level|<->| level |<->| level |<->| level |<->| level |<->|level |NTLP | NTLP |<->| NTLP |<->| NTLP |<->| NTLP |<->| NTLP |<->|NTLP | |st.ful| |st.ful | |st.less| |st.less| |st.full| |st.ful| |------| |-------| |-------| |-------| |-------| |------| NI NF NF NF NF NR (edge) (interior) (interior) (edge) NTLP st.ful : NTLP stateful NTLP st.less : NTLP stateless Figure 2: Two levels used for the RSVPv2 NSLP The hierarchical level separation can be provided by supporting a hierarchical object structure. In other words, the NSIS protocol objects should be structured and positioned within the NSIS messages in a hierarchical way, i.e., first the "NTLP level" objects, then the "PDR/PHR" objects and finally the "e2e service" objects. 4.1. RSVPv2 NSLP protocol features provided by the intra-domain level The RSVPv2 NSLP protocol functions provided by the intra-domain level are composed by the protocol functions provided by the PDR and PHR protocol parts (similar to [RMD-frame], [RODA], [RIMA]). Westberg, et al. Expires October 2003 [Page 22] Internet Draft Proposal for RSVPv2-NSLP April 2003 4.1.1. PDR protocol part functions The RSVPv2 NSLP PHR and PDR protocol parts that implement the RSVPv2 NSLP intra-domain level are listed below. A PDR protocol part implements all or a subset of the following functions: * Admission control and/or resource reservation signaling within a domain (i.e., on the edge nodes). * Mapping of external QoS request provided by the e2e service level to a traffic class identifier, e.g., Diffserv Code Point (DSCP). * Modification of an already installed RSVPv2-NSLP reservation state. * Notification of the NF ingress node IP address to the NF egress node. * Notification of resource availability in all the nodes located in the communication path from the NF ingress to the NF egress nodes. * Severe congestion handling. Due to a route change or a link failure, a severe congestion situation may occur. The NF egress node is notified by PHR when such a severe congestion situation occurs. Using PDR, the egress node notifies the NF ingress node about this severe congestion situation. The NF ingress node resolves this situation by using a predefined policy, e.g., refusing new incoming flows and terminating a portion of the affected flows. * Uni / bi-directional reservation. Both unidirectional as well as bi-direction reservations SHOULD be possible * Notification that lost signalling messages (containing PHR and PDR information) occurred in the communication path from the ingress to the egress nodes. 4.1.2. PHR protocol part functions A RSVPv2-NSLP PHR protocol part implements all or a subset of the following functions: Westberg, et al. Expires October 2003 [Page 23] Internet Draft Proposal for RSVPv2-NSLP April 2003 * Admission control and/or resource reservation signaling within a node. * Management of one reservation state (i.e., PHR state) per traffic class by using a combination of the reservation soft state and explicit release signaling principles (see e.g., [RODA]). Note that the PHR state is maintained by using the NTLP soft state principle. Each NF node in the communication path from an NF ingress node to an NF egress node keeps only one reservation state per traffic class. The reservation signaling is done in terms of resource units, which may be based on a single parameter, such as bandwidth, or on more sophisticated parameters. These resources are requested dynamically per traffic class (e.g., per DSCP) and reserved on demand on all nodes in the communication path from an NF ingress node to an NF egress node. This concept is denoted as reservation based "PHR". * Measurement of the user traffic load (see e.g., [RIMA]). This PHR function is used to check the availability of resources before flows are admitted and without installing any reservation state. That is, the resource management function that is used is actually a Measurement Based Admission Control (MBAC) algorithm, which performs measurements on the traffic (user) data load. The main advantage of this PHR group is that the PHR functionality that is executed at the edge and interior nodes will not have to maintain any reservation states. This concept is denoted as measurement based "PHR". * Stores a pre-configured threshold value on maximal allowable traffic load (or resource units) per traffic class, e.g., PHB. When the resource management function (RMF) that is used in combination with this PHR protocol function maintains a reservation state per traffic class it also has to maintain a threshold for each traffic class (e.g., PHB) that specifies the maximum number of reservable resource units. This threshold could, for example, be statically configured. When the resource management function (RMF) that is used in combination with this PHR protocol function is an MBAC algorithm it also has to maintain one state per traffic class that stores the measured user traffic load associated to the traffic class, e.g., PHB and another state per traffic class, e.g., PHB that stores the Westberg, et al. Expires October 2003 [Page 24] Internet Draft Proposal for RSVPv2-NSLP April 2003 maximum allowable traffic load per traffic class, e.g., PHB. * Severe congestion notification. This situation occurs as a result of route changes or a link failure. The PHR has to notify the NF edges about the occurrence of this situation. Once detected the severe congestion should be signalled to the NF(edges). As previously mentioned, the NF(egress) node will first be notified, after which the NF(egress) will notify the NF(ingress) node using the NSLP PDR functionality. Below is a list of several notification methods that can be used: * Greedy marking: all user data packets which pass through a severe congested interior node and are associated with a certain traffic class, e.g., DSCP, will be remarked into a another traffic class, e.g., a domain specific (DSCP) * Proportional marking: this method is similar to the previous method, with the difference that the number of the remarked packets is proportional to the detected overload * PHR message marking: only PHR objects that pass through a severely congested interior node will be marked. The marking is done by setting a special flag in the "PHR" object, i.e., "S" (see [RODA]). The last method can only be applied on the reservation-based "PHR" concept, while the other two can be applied on both "PHR" concept types. A comparison between different severe congestion solutions is given in [CsTa02]. Note that in the RMD NSLP the PHR and PDR protocol parts have to be generated and discarded at the edge nodes (ingress and egress nodes) and not at the end hosts. 4.2. RSVPv2 NSLP protocol features provided by the e2e service level The e2e service level protocol features that are used by this NSLP should satisfy all or a subset of the application signaling requirements provided in [Bru03]. The detailed description of these features will be included in the next updated versions of this draft. Westberg, et al. Expires October 2003 [Page 25] Internet Draft Proposal for RSVPv2-NSLP April 2003 5. RSVPv2 NSLP specification RSVPv2 NSLP is considered in this draft to be primarily optimised for unicast and sender initiated signaling. This section provides a first step in the RSVPv2 NSLP specification. 5.1. RSVPv2 NSLP Object Classes structure As described in [WeKa03] the NTLP message format consists of a common header, followed by a body consisting of a number of variable-length, typed transport layer "objects". The application layer (NSLP) "objects" are placed always after the transport layer "objects". Note that the application layer (NSLP) "objects" are opaque and transparent to NTLP. The NTLP message format is depicted in Figure 3. 0 1 2 3 +-------------+-------------+-------------+-------------+ | | + Common Header + | | +-------------+-------------+-------------+-------------+ | | // (Transport layer objects content) // | | +-------------+-------------+-------------+-------------+ | | // Application layer (RSVPv2 NSLP) objects content) // | | +-------------+-------------+-------------+-------------+ Figure 3: NTLP message format The Application layer (RSVPv2 NSLP) depicted in Figure 3 contains RSVPv2 NSLP messages. The RSVPv2 NSLP messages and their meaning is introduced in Table 1. Furthermore, the same table identifies the NTLP message that will transport a NSLP message. Westberg, et al. Expires October 2003 [Page 26] Internet Draft Proposal for RSVPv2-NSLP April 2003 Table 1: NSLP messages Meaning of the NSLP message NSLP Message Type NTLP Message Type __________________________ _____________ _________________ Initiation NslpPathInit PATH Initiation NslpResvInit RESV Modification NslpPathMod PATH Modification NslpResvMod RESV Refresh NslpPathRef PATH Refresh NslpResvRef RESV Path Tear down NslpPathTear PATHTEAR Resv Tear down NslpResvTear RESVTEAR Path Error report NslpPathErr PATHERROR Resv Error report NslpResvErr RESVERROR Resv Confirm NslpResvConfirm RESVCONFIRM In order to have a flexible and modular RSVPv2 NSLP object class structure, we propose a grouping of signalling information into RSVPv2 NSLP object classes, called RSVPv2 NSLP Object_Classes. These will contain objects that are defined globally and/or locally. A locally defined object will allow signalling of information relevant to nodes belonging to a certain domain, while the globally defined objects will be used anywhere on the Internet. The globally defined objects are denoted as "e2e service objects" and the locally defined objects are denoted as ""PDR/PHR" objects. In the RSVPv2 NSLP structure the following RSVPv2 NSLP Object_Classes are defined: * Service_Class This object class carries the information related to the service desired from the network, i.e. QoS. This class includes all information related to the requested/expected network service. The resource reservation is related to the QoS request as well as to the response on this QoS request. This object class is flexible in order to support different kinds of QoS requests for different kinds of networking scenarios such as a end-to-edge (proxy) scenario, bi-directional reservations, receiver-initiated, etc. Westberg, et al. Expires October 2003 [Page 27] Internet Draft Proposal for RSVPv2-NSLP April 2003 * Session_ID_Class This object class is common for the NTLP and NSLP. In [Weka03] this object class is denoted as Session object. This class includes information related to the identification of NTLP states. This object will contain a session identifier. The session identifier has to identify a NTLP state and has to remain unchanged for the complete duration of a data flow. Moreover, the Session_ID_Class identifier has to be associated with the flow ID information included in the Flow_Specification_Class object. In other words, for the duration of a data flow, the session identifier remains the same while the flow ID information associated with the same data flow might change. For example, in a mobile IP scenario, during handover the IP address of a mobile node might change, causing a change in the flow ID of an ongoing data flow. However, the session identifier associated with that data flow should not change. * Flow_Specification_Class This object class specifies the relation of the addressing (IP address/mask/port) to the reservation and if/how the reservation is shared between many addresses. In general, Flow_Specification contains information that identifies a particular data flow for which the specific service is requested from the network. For example, a flow ID consisting of a combination of source IP address, destination IP address, Source port, Destination port, Protocol number will be typical information belonging to the Flow_Specification_Class. This class should also contain an NSLP identifier, which identifies the NSLP type. * Security_class This object class includes information related to the protection, authorization and authentication of the information in the message. This object class is optional. * Error_message_class This class includes information related to the errors that Westberg, et al. Expires October 2003 [Page 28] Internet Draft Proposal for RSVPv2-NSLP April 2003 occur during reservation state processing. This object class can be considered as common for the NTLP and NSLP. In [Weka03] this object class is denoted as Error_Spec object. 5.1.1. RSVPv2 NSLP Message Structure The exact object structure and the object sequence will have to be defined for each network scenario by a pre-defined "profile" (see Section 3.2). A profile can be either standardized or it could be an agreement between two or more participants. Based on the above defined RSVPv2 object-class structure the format of the RSVPv2 NSLP messages may be as follows: | | | | | | ::= [] | ::= [] 5.2. RSVPv2-NSLP Objects in RSVPv2-NSLP Object_Classes This section presents a generic method of mapping globally and locally defined RSVPv2 NSLP objects into RSVPv2 NSLP classes. Based on the definitions of the RSVPv2 NSLP object classes, an RSVPv2 NSLP Object_Class might contain globally and locally defined objects. Below is shown a possible way of mapping globally and locally defined objects into the RSVPv2 NSLP Object_Classes. The locally defined Westberg, et al. Expires October 2003 [Page 29] Internet Draft Proposal for RSVPv2-NSLP April 2003 objects are the "PHR" (Per Hop Reservation) and "PDR" (Per Domain Reservation). These objects are used for intra-domain signaling and are described in more detail in the Appendix. Service_Class: [] [] Flow_Specification_Class: Session_ID_Class: Security_Class: Error_Message_Class: where: [] is optional for unicast and multicast support and sender-initiated and receiver-initiated approach 5.2.1. Example of mapping of RSVPv1 [RFC2205] objects in RSVPv2 object_classes" This section gives an example of mapping the RSVPv1 objects into the RSVPv2 object_classes when RSVPv1 is optimized for unicast and sender initiated signaling. If RSVPv1 is to be optimized for unicast and sender initiated signaling certain changes in the mandatory usage of RSVPv1 objects have to be provided. Based on the RSVPv2 object-class structure an example of a possible mapping of current RSVPv1 objects in RSVPv2 NSLP object structure is given. The mandatory objects that will be needed in an sender-initiated NSLP RSVPv2 optimized for unicast are: Westberg, et al. Expires October 2003 [Page 30] Internet Draft Proposal for RSVPv2-NSLP April 2003 * SESSION It contains the IP destination address (DestAddress), the IP protocol id, and some form of generalized destination port, to define a specific session for the other objects that follow. This object contains information that is used to define the flow ID. * SENDER_TSPEC Defines the traffic characteristics of a sender's data flow. Required in a Path message. This object is used to specify the QoS service required by the sender. * SENDER_TEMPLATE Contains a sender IP address and perhaps some additional de-multiplexing information to identify a sender. Required in a Path message. This object contains information that is used to define the flow ID. * TIME_VALUES Contains the value for the refresh period R used by the creator of the message. Required in every Path and Resv message. * ERROR_SPEC Specifies an error in a PathErr, ResvErr, or a confirmation in a ResvConf message. * POLICY_DATA Carries information that will allow a local policy module to decide whether an associated reservation is administratively permitted. May appear in Path, Resv, PathErr, or ResvErr message. The use of POLICY_DATA objects is not fully specified at this time; a future document will fill this gap. * INTEGRITY Carries cryptographic data to authenticate the originating node and to verify the contents of this RSVPv1 message. The use of the INTEGRITY object is described in [RFC2747]. Westberg, et al. Expires October 2003 [Page 31] Internet Draft Proposal for RSVPv2-NSLP April 2003 Based on the definitions of the RSVPv2 object classes, some of the RSVPv1 objects (see [RFC2205]) can be re-used in a RSVPv2 NSLP object-class structure. During the RSVPv2 NSLP design phase the RSVPv1 objects may be changed or removed completely and also some other objects may be defined as well. The goal is to reuse as much as possible of RSVPv1 objects. Based on the description of RSVPv2 NSLP object classes and the current RSVPv1 objects the mapping of RSVPv1 objects into the RSVPv2 NSLP object-class structure is rather simple. This mapping is given below and it is done for all RSVPv1 objects. Note that the Service_Class contains the PHR and PDR objects that are locally defined objects and are used for intra- domain signaling. Service_Class: [] [] {} [FLOWSPEC] {} [] Flow_Specification_Class: {} {