Internet Draft Proposal for RSVPv2 October 2002 Internet Engineering Task Force L. Westberg INTERNET-DRAFT G. Karagiannis Expires April 2003 D. Partain V. Rexhepi Ericsson October 2002 A Proposal for RSVPv2 draft-westberg-proposal-for-rsvpv2-01.txt 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 Copyright (C) The Internet Society (2002). All Rights Reserved. Westberg, et al. Expires April 2003 [Page 1] Internet Draft Proposal for RSVPv2 October 2002 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 desire of many to deploy technology to deliver services with different levels of quality of service (QoS) to their customers. The reasons for this are arguably well-understood and documented and are not the focus of this memo. This memo seeks to initiate a dialog about the design of a new version of RSVPv1, which we call RSVPv2. The RSVPv2 framework could use the combination of two concepts. The concept of ALSP (Application Layer Signaling Protocol) and the concept of Common Signaling Transport Protocol (CSTP). This memo outlines the motivation for doing this work and provides design guidelines and specifications for the development of the RSVPv2 ALSP. RSVPv2 ALSP is an ALSP type that can be a part of the RSVPv2 framework. Westberg, et al. Expires April 2003 [Page 2] Internet Draft Proposal for RSVPv2 October 2002 Table of Contents 1 Introduction ................................................. 5 1.1 Definitions/Terminology .................................... 5 2 Motivation for RSVPv2 ........................................ 10 2.1 Effects of the Design of RSVPv1 ............................ 10 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 .......... 12 2.2 Different Network Signalling Requirements/Needs and RSVP ........................................................... 13 3 Design Goals and General Features for RSVPv2-ALSP ............ 14 3.1 Increased Modularity and Extendability ..................... 14 3.2 Increased Object Modularity ................................ 15 3.3 Hierarchical Object Structure .............................. 16 3.4 Global and Local Objects ................................... 16 3.5 Local information exchange ................................. 17 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 ....................................... 18 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 .............................................. 19 3.14 End-to-edge ............................................... 19 4 Overview of the RSVPv2-ALSP Framework ........................ 19 4.1 RSVPv2 protocol features provided by the intra-domain level ..................................................... 23 4.1.1 PDR protocol part functions .............................. 23 4.1.2 PHR protocol part functions .............................. 24 4.2 CSTP protocol functions needed by the RSVPv2 ALSP .......... 26 4.3 RSVPv2 ALSP protocol features provided by the e2e service level ..................................................... 27 5 RSVPv2 ALSP specification .................................... 28 5.1 RSVPv2 ALSP Object Classes structure ....................... 28 5.1.1 Combined CSTP and RSVPv2 ALSP Message Structure .......... 29 5.1.1.1 Message Structure for inter-domain signaling ........... 30 5.1.1.2 Message Structure for intra-domain signaling ........... 31 5.1.1.3 Format of RSVPv2 ALSP SAPUs ............................ 32 5.2 RSVPv2 ALSP Objects in RSVPv2 ALSP Object_Classes .......... 34 5.2.1 Example of mapping of RSVPv1 objects in RSVPv2 ob­ ject_classes .............................................. 34 5.2.2 PDR/PHR objects .......................................... 38 5.3 RSVPv2 ALSP functionality on nodes used for inter-domain Westberg, et al. Expires April 2003 [Page 3] Internet Draft Proposal for RSVPv2 October 2002 signaling ................................................. 39 5.4 RSVPv2 ALSP functionality on nodes used for intra-domain signaling ................................................. 39 6 Example of RSVPv2 ALSP Inter-domain signaling procedures ..... 39 6.1 Normal operation for uni-directional reservation ........... 39 6.2 Normal operation for bi-directional reservation ............ 44 7 Example of RSVPv2 ALSP Intra-domain signaling procedures ..... 44 7.1 Normal operation for uni-directional reservation ........... 44 7.2 Example of Fault Handling Operation ........................ 58 7.2.1 Loss of CSTP signalling messages ......................... 59 7.2.2 Severe Congestion Handling operation ..................... 59 7.2.2.1 Proportional marking ................................... 60 7.3 Example of Adaptation to load sharing operation ............ 61 7.4 Normal operation for bi-directional reservation ............ 62 8 Appendix 1 - Proposed modifications on the CSTP protocol ..... 62 8.1 Modified CSTP messages ..................................... 63 8.2 ALSP/CSTP interface ........................................ 64 8.3 Adaptation to load sharing operation ....................... 64 9 Appendix 2 - Examples of PHR and PDR object specifications ........................................................... 64 9.1 PHR objects ................................................ 64 9.2 PDR objects ................................................ 67 10 References .................................................. 72 11 Authors' Addresses .......................................... 75 Westberg, et al. Expires April 2003 [Page 4] Internet Draft Proposal for RSVPv2 October 2002 1. Introduction A number of different QoS solutions have been developed by the IETF, amongst them IntServ and its signalling protocol, RSVPv1, defined in [RFC2205]. RSVPv1 [RFC2205] is a resource reservation signalling 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 scalability, 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 RSVPv2 framework would be to rectify the issues that have been identified with RSVPv1 and provide an evolutionary path forward. The RSVPv2 framework could use the combination of two concepts that have been introduced in [BrLi01]. The concept of ALSP (Application- Level Signaling Protocol) and the concept of Common Signaling Transport Protocol (CSTP). This memo outlines the motivation for doing this work and provides design guidelines and specifications for the development of the RSVPv2 ALSP. RSVPv2 ALSP is an ALSP type that can be a part of the RSVPv2 framework. In order to be able to communicate with the CSTP, the RSVPv2 ALSP needs to use an ALSP Identifier that has to be assigned by the NSIS (Next Steps In Signaling) WG. 1.1. Definitions/Terminology Application-Layer Siganling Protocol (ALSP) (similar to [BrLi01]): is a protocol level that implements the algorithms and data structures for a particular signaling task. RSVPv2 ALSP: an ALSP type that can be a part of the RSVPv2 framework. ALSP intra-domain: Westberg, et al. Expires April 2003 [Page 5] Internet Draft Proposal for RSVPv2 October 2002 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. Common Signaling Transport Protocol (CSTP) (similar to [BrLi01]): is a protocol level that CSTP implements transport and soft-state functions. CSTP supports a suite of higher-level ALSPs. CSTP aware node: a node that implements and supports the CSTP protocol. CSTP stateful neighbor: a first hop CSTP aware neighbor node (of a CSTP aware node) that maintains a CSTP state. CSTP stateful node: a CSTP aware node that maintains a CSTP state. CSTP stateless neighbor: a first hop CSTP aware neighbor node (of a CSTP aware node) that does not maintain a CSTP state. CSTP stateless node: a CSTP aware node that does not maintain a CSTP state. 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 Westberg, et al. Expires April 2003 [Page 6] Internet Draft Proposal for RSVPv2 October 2002 differentiated services documents; usually used in reference to a node or device. Interdomain traffic - Traffic that passes from one NSIS domain to another ([identical to [Hanc02]). Intra-domain NSIS signaling is where the NSIS signaling messages are originated, processed and terminated within the same NSIS domain. NSIS Domain (ND) - Administrative domain where an NSIS protocol signals for a resource or set of resources (identical to [Hanc02]). NSIS Entity (NE) - the function within a node which implements an NSIS protocol (identical to [Hanc02]). NE CSTP stateful - NE entity that is CSTP stateful. NE CSTP stateless - NE entity that is CSTP stateless. 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 [Hanc02]). Note that NF can be also considered as a RSVPv2 forwarder. NF CSTP stateful - NF entity that is CSTP stateful. NF CSTP stateless - NF entity that is CSTP stateless. NSIS Initiator (NI) - NSIS Entity that initiates NSIS signaling for a network resource (identical to [Hanc02]). 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 [Hanc02]). Note that NR can be also considered as a RSVPv2 responder. Westberg, et al. Expires April 2003 [Page 7] Internet Draft Proposal for RSVPv2 October 2002 Path-coupled signaling - a mode of signaling where the signaling messages follow a path that is tied to the data messages. (see [Hanc02]). Path-decoupled signaling - signaling with independent data and signaling paths (see [Hanc02]). 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 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. Westberg, et al. Expires April 2003 [Page 8] Internet Draft Proposal for RSVPv2 October 2002 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 (identical to [Hanc02]). Resource Management Function (RMF) - an abstract concept, representing the management of resources in a domain or a node (identical to [Hanc02]). NF Edge nodes: NF Nodes that are located at the boundary of a Diffserv domain. This node is a CSTP aware node that maintains a CSTP state. NF Interior node: All the nodes that are part of a domain and are not NF edge nodes. An interior node is a CSTP aware node that does not maintain a CSTP state. NF Ingress node: An NF edge node that handles the traffic as it enters the domain. This node is a CSTP aware node that maintains a CSTP state. NF Egress node: An NF edge node that handles the traffic as it leaves the domain. This node is a CSTP aware node that maintains a CSTP state. End Host: QoS-aware end terminal, either fixed or mobile, i.e. running QoS-aware applications. This node is a CSTP aware node that maintains a CSTP state. This node can be considered as a NI or a NR. SAPU (similar to [BrLi01]): A Signaling Application Protocol Unit (SAPU) is the basic transmission unit for signaling and it is used to set, modify, or delete state in a CSTP aware node that maintains a CSTP state. Westberg, et al. Expires April 2003 [Page 9] Internet Draft Proposal for RSVPv2 October 2002 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 signalling protocol, RSVPv1. As such, there must be a clear need for the evolution of RSVPv1. This section tries to provides that motivation. We believe that this work can be motivated by examining some of the design constraints placed upon the development of RSVPv1 and in considering whether those design constraints can be relaxed or changed in designing RSVPv2. Note that RSVPv2 uses the concept of ALSP's that has been introduced in [BrLi01]. The RSVPv2 ALSP must be used in combination with the Common Signaling Transport Protocol (CSTP) specified in [BrLi01]. In order to be able to communicate with the CSTP, the RSVPv2 ALSP needs to use an ALSP Identifier that has to be assigned by the NSIS (Next Steps In Signaling) WG. 2.1. Effects of the Design of RSVPv1 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. 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. Westberg, et al. Expires April 2003 [Page 10] Internet Draft Proposal for RSVPv2 October 2002 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 setuop 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. 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 Westberg, et al. Expires April 2003 [Page 11] Internet Draft Proposal for RSVPv2 October 2002 specification may ahve 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 signalling 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. 2.1.4. Designed for End-host to End-host Communication RSVPv1 was primarily designed with signalling 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 signalling conversations that may be needed in different parts of the network. Each of these kinds of signalling implies a different -- and potentially conflicting -- set of requirements on the signalling protocol. For example, the signalling requirements for the conversation between the end-host and the network may indeed need more complexity than RSVPv1 whereas the signalling needs in a DiffServ-capable access network would require significantly less. Westberg, et al. Expires April 2003 [Page 12] Internet Draft Proposal for RSVPv2 October 2002 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 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]. Westberg, et al. Expires April 2003 [Page 13] Internet Draft Proposal for RSVPv2 October 2002 3. Design Goals and General Features for RSVPv2-ALSP This section briefly outlines some of the guiding principles behind the design of RSVPv2 ALSP. Moreover, the RSVPv2 ALSP general features are described. These design goals and features are in line with some of the NSIS requirements described in [Bru02] and [Hanc02]. 3.1. Increased Modularity and Extendability The essential design goal for RSVPv2 framework is to preserve the flexibility of RSVPv1 while at the same time further expanding its modularity. This is fulfilled by using the two-level architecture for Internet Signaling proposed in [BrLi01]. In [BrLi01] is proposed that the Internet Signaling should be composed by two protocol levels: (1) a common lower level that performs transport-layer functions. This common lower level is called CSTP ("Common Signaling Transport Protocol") to implement transport ans soft-state functions. (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 ALSPs ("Application Layer Signaling Protocols). The CSTP together with the set of ALSPs will implement the Internet Signaling Protocol Suite (ISPS). The RSVPv2 ALSP protocol can be considered as an ALSP that will use a subset of the transport layer functions provided by the CSTP (see [BrLi01]) such as: * Support of Path-Coupled (Path-Directed) Signaling; * Reliable delivery of signaling messages: By using this feature the CSTP signaling messages can be delivered reliably when needed such that the sate can be reliably added, changed and explicitly removed. * Soft state support: This feature ensures that a state will be removed if it is not periodically refreshed or explicitly removed. * Modification of an already installed reservation state. Westberg, et al. Expires April 2003 [Page 14] Internet Draft Proposal for RSVPv2 October 2002 * Adaptation to load sharing. Load sharing allows NF interior nodes to take advantage of multiple routes to the same destination by sending via some or all of these available routes. The CSTP protocol level has to adapt to load sharing once it is used. * The CSTP signaling protocol MUST be able to exchange local information 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 this object modularity is to increase processing efficiency of RSVPv2 (ALSP and CSTP) 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 ALSP 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. Westberg, et al. Expires April 2003 [Page 15] Internet Draft Proposal for RSVPv2 October 2002 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 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 ALSP objects within RSVPv2 (ALSP and CSTP) messages for each networking scenario. Each profile used for a network scenario will have to specify how the objects are structured into the RSVPv2 ALSP SAPU (Signaling Application Protocol Unit)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. Objects that will be processed only in specific routers can be placed later in the sequence. 3.4. Global and Local Objects ALSP 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. By using this feature the requirement described in Section 5.4.2 (Possibility to add and remove local domain information) of [Bru02] will be satisfied. Westberg, et al. Expires April 2003 [Page 16] Internet Draft Proposal for RSVPv2 October 2002 3.5. Local information exchange The signaling protocol MUST be able to exchange local information between NSIS Forwarders located within one single administrative domain (see also Section 5.3.5 (Local information exchange) in [Bru02]). Local information might, for example, be IP addresses, severe congestion notification, notification of successful or erroneous processing of signaling messages. 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 ALSP 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. Westberg, et al. Expires April 2003 [Page 17] Internet Draft Proposal for RSVPv2 October 2002 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) (see also Section 5.5.2 (Low latency in setup) of [Bru02]). 3.10. Highest possible network utilization There are networking environments that require high network utilization for various reasons, and the signaling protocol SHOULD to 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 (see also Section 5.5.5 (Highest possible network utilization) of [Bru02]. 3.11. Uni / bi-directional reservation Both unidirectional as well as bi-direction reservations SHOULD be possible (see also Section 5.6.4 of [Bru02]). 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 [Hanc02]), the RSVPv2 ALSP protocol is initiated by an end host and is terminated by another end host. In this context, RSVPv2 ALSP can be applied as needed within all of the RSVPv2 ALSP domains between the end hosts. In the end-to-end path, RSVPv2 ALSP may be used both for intra-domain RSVPv2 ALSP signaling, as well as for inter-domain signaling. Westberg, et al. Expires April 2003 [Page 18] Internet Draft Proposal for RSVPv2 October 2002 3.13. Edge-to-edge In this scenario (see also [Hanc02]) the RSVPv2 ALSP protocol is initiated by an edge node of a RSVPv2 ALSP domain and is terminated by another edge node of the same (or possibly different) RSVPv2 NSIS domain. RSVPv2 ALSP can be applied either within one single RSVPv2 ALSP domain, which is denoted as edge-to-edge in a single domain, or within a concatenated number of RSVPv2 ALSP 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 ALSP domains, these concatenated RSVPv2 ALSP domains are considered, in terms of RSVPv2 ALSP, to be a single, larger RSVPv2 ALSP domain. 3.14. End-to-edge In this scenario (see also [Hanc02]) the RSVPv2 ALSP 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 ALSP domain. 4. Overview of the RSVPv2-ALSP Framework The RSVPv2 protocol can be considered as an ALSP that will use a subset of the transport layer functions provided by the CSTP protocol level (see [BrLi01]). 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 RSVPv2 ALSP framework shown in Figure 1 is separated in different levels. The lowest hierarchical level in Figure 1 represents the CSTP level protocol. This level provides basic resource management functionality related to soft state maintenance and to transport functions, such as reliable delivery of signaling messages, congestion control notification and load sharing adaptation. Note that the NF nodes are usually considered to be CSTP stateful nodes. This holds also for the NF nodes used at the boundary of a domain, i.e., the NF edge nodes. However, the interior nodes of a domain can be considered to be CSTP stateless nodes, i.e., NF stateless nodes. Westberg, et al. Expires April 2003 [Page 19] Internet Draft Proposal for RSVPv2 October 2002 The NF CSTP stateful nodes are NF CSTP aware nodes that maintain a CSTP state by using the CSTP soft state principle and are able to process and modify the CSTP information that is transported by the CSTP protocol. The NF CSTP stateless nodes are NF CSTP aware nodes that do not maintain a CSTP state, but they are able to process and modify the CSTP information that is transported by the CSTP protocol. The RSVPv2 ALSP framework is separated in two levels: * the intra-domain level (located above the CSTP 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 ALSP and CSTP has to be moved as much as possible away from the interior nodes. Therefore, the RSVPv2 ALSP 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 ALSP intra-doamin. The first resource reservation protocol part type is denoted as Per 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 CSTP state and there is no PDR functionality. Note that these NF interior nodes are CSTP 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 Westberg, et al. Expires April 2003 [Page 20] Internet Draft Proposal for RSVPv2 October 2002 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 1) to "local" parameters that are useful to the intra-domain scheme. Note that in the NF edge nodes (NF ingress and NF egress) a CSTP 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 ALSP and CSTP complies to the interface specified in [BrLi01]. However, a number of modifications on the CSTP protocol level are proposed in Appendix 1. Note that Appendix 1 describes a possible manner of enhancing the CSTP protocol level described in [BrLi01] such that it can be used in combination with the RSVPv2 ALSP. However, these proposed CSTP modifications should be seen as an example and should not preclude other ways of achieving the interaction between the CSTP protocol level and the RSVPv2 ALSP level. An RSVPv2 ALSP SAPU (Signaling Application Protocol Unit)) caries the objects used by the e2e service and PDR/PHR ALSP protocol levels. The RSVPv2 ALSP SAPU similar to the proposal given in [BrLi01] contains a (, ) pair. The part contains the SAPU- id. The part is a container that contains the "e2e service" objects that are "global" objects and the "PDR/PHR" objects that are "local" objects. Note however, that there are certain differences in the CSTP level functionalities that are required by this ALSP with the CSTP level functionalities described in [BrLi01]. The proposed main differences of the CSTP level that has to be used in combination with the RMD ALSP and the CSTP level described in [BrLi01] are the following: (Note that Appendix 1 describes a possible manner of enhancing the CSTP protocol level described in [BrLi01] such that it can be used in combination with the RSVPv2 ALSP. However, these proposed CSTP modifications should be seen as an example and should not preclude other ways of achieving the interaction between the CSTP protocol level and the RSVPv2 ALSP level) Westberg, et al. Expires April 2003 [Page 21] Internet Draft Proposal for RSVPv2 October 2002 * in the CSTP level described in [BrLi01] the CSTP states have to be created by all CSTP aware nodes. * in the CSTP level used in the RSVPv2 ALSP the CSTP states do not have to be created in all CSTP aware nodes. There are nodes, such as the NF interior nodes, that are not creating and maintaining such CSTP states. These NF nodes are called NF CSTP stateless nodes. The NF nodes that are creating and maintaining such CSTP states are called NF CSTP stateful nodes. The consequence of this difference is that the information that has to be carried by some CSTP messages and the ALSP/CSTP interface has to be modified. * Adaptation to load sharing. Load sharing allows NF interior nodes to take advantage of multiple routes to the same destination by sending via some or all of these available routes. The CSTP protocol level has to adapt to load sharing once it is used. As shown in Figure 1, the two ALSP hierarchical levels might be applied on different NSIS entities. This architecture for NSIS (e.g., RSVPv2) signaling can be provided by using: *) a single end-to-end NSIS (e.g., RSVPv2) protocol that supports both ALSP 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. Westberg, et al. Expires April 2003 [Page 22] Internet Draft Proposal for RSVPv2 October 2002 |------| |-------| |-------| |------| | e2e |<--| e2e |<------------------------->| e2e |<->| e2e | service|<--|service| |service|<->|service | | |-------| |-------| |------| | | | | | | | | | | |-------| |-------| |-------| |-------| | | | | |PDR/PHR|<->| PHR |<->| PHR |<->|PDR/PHR| | |ALSP | | | | | | | | | | | | ^ | | |-------| |-------| |-------| |-------| | | | --------------------------------------------------------------------- | | | | | | | | | |------| |-------| |-------| |-------| |-------| |------| V | level|<->| level |<->| level |<->| level |<->| level |<->|level |CSTP | CSTP |<->| CSTP |<->| CSTP |<->| CSTP |<->| CSTP |<->|CSTP | |st.ful| |st.ful | |st.less| |st.less| |st.full| |st.ful| |------| |-------| |-------| |-------| |-------| |------| NI NF NF NF NF NR (edge) (interior) (interior) (edge) CSTP st.ful : CSTP stateful CSTP st.less : CSTP stateless Figure 1: Combination of RSVPv2 ALSP framework and CSTP level 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 "CSTP level" objects, then the "PDR/PHR" objects and finally the "e2e service" objects. 4.1. RSVPv2 protocol features provided by the intra-domain level The RSVPv2 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]). 4.1.1. PDR protocol part functions The RSVPv2 ALSP PHR and PDR protocol parts that implement the RSVPv2 ALSP intra-domain level are listed below. A PDR protocol part implements all or a subset of the following functions: Westberg, et al. Expires April 2003 [Page 23] Internet Draft Proposal for RSVPv2 October 2002 * Admission control and/or resource reservation signaling within a domain (i.e., on the edge nodes). * Stores the PDR flow identifier and PDR reservation state per flow (or aggregated flows). * 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 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 4.1.2. PHR protocol part functions A RSVPv2 ALSP PHR protocol part implements all or a subset of the following functions: * 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 CSTP soft state principle. Westberg, et al. Expires April 2003 [Page 24] Internet Draft Proposal for RSVPv2 October 2002 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 trafic 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 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. Westberg, et al. Expires April 2003 [Page 25] Internet Draft Proposal for RSVPv2 October 2002 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 ALSP 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]. 4.2. CSTP protocol functions needed by the RSVPv2 ALSP The main CSTP protocol level should provide all or a subset of the following functions: * Soft state support of the PHR state. This functionality is provided by the CSTP soft state support functionality. * Notification that lost signalling messages (containing PHR and PDR information) occurred in the communication path from the ingress to the egress nodes. This functionality is provided by the CSTP reliable delivery functionality. In the RMD ALSP 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. Westberg, et al. Expires April 2003 [Page 26] Internet Draft Proposal for RSVPv2 October 2002 4.3. RSVPv2 ALSP protocol features provided by the e2e service level The e2e service level protocol features that are used by this ALSP should satisfy all or a subset of the application signaling requirements provided in [Bru02]. The detailed description of these features will be included in the next updated versions of this draft. Westberg, et al. Expires April 2003 [Page 27] Internet Draft Proposal for RSVPv2 October 2002 5. RSVPv2 ALSP specification RSVPv2 is considered in this draft to be primarily optimised for unicast and sender initiated signaling. This section provides a first step in the RSVPv2 ALSP specification. 5.1. RSVPv2 ALSP Object Classes structure In order to have a flexible and modular RSVPv2 ALSP object class structure, we propose a grouping of signalling information into RSVPv2 ALSP object classes, called RSVPv2 ALSP 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 ALSP structure the following RSVPv2 ALSP 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. * Reservation_State_Management_Class This object class includes information related to the management of reservation states. This object will contain a reservation state identifier and information such as refresh period information, flags for receiver or sender-initiated reservation, etc. The reservation state identifier has to identify a data flow and has to remain unchanged for the complete duration of a Westberg, et al. Expires April 2003 [Page 28] Internet Draft Proposal for RSVPv2 October 2002 data flow. Moreover, the reservation state 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 reservation state 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 reservation state 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. * 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 occur during reservation state processing. 5.1.1. Combined CSTP and RSVPv2 ALSP Message Structure A possible message structure in RSVPv2 is using a combined CSTP and ALSP information. 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. Westberg, et al. Expires April 2003 [Page 29] Internet Draft Proposal for RSVPv2 October 2002 There are two types of RSVPv2 (ALSP and CSTP) message structures: * RSVPv2 (ALSP and CSTP) messages that are used for inter-domain signaling * RSVPv2 (ALSP and CSTP) messages that are used for intra-domain signaling 5.1.1.1. Message Structure for inter-domain signaling The structure of the RSVPv2 (ALSP and CSTP) messages that are used for inter-domain signaling is based on the one proposed in [BrLi01]. Note that this structure contains also the CSTP Info message, which transports a SAPU type with neither reliable delivery nor refreshing. Moreover, note that the SAPU type that is transported within a CSTP NEW or CSTP MOD message is transported without reliable delivery. CSTP NEW: xSig(NEW, h-src, SAPUid, SAPU, R) CSTP MOD: xSig(MOD, h-src, SAPUid, SAPU, old-SAPUid, R) CSTP TEAR: xSig(TEAR, h-src, SAPUid) CSTP REFRESH: xSig(REFRESH, h-src, SAPUid, R) CSTP ACK: xSig(ACK, h-src, SAPUid-list) CSTP NACK: xSig(NACK, h-src, SAPUid) CSTP EVENT: xSig(EVENT, h-src, SAPUid, SAPU) CSTP CHALLENGE: xSig(CHALLENGE, h-src, challenge-object) CSTP RESPONSE: xSig(RESPONSE, h-src, challenge-object) CSTP INFO: xSig(INFO, h-src, SAPUid, SAPU, SAPUinfo) Where the parameters are identical to the ones described in [BrLi01]. The only additional parameter is the SAPUinfo parameter. SAPUinfo that will be used to report information related to how the a SAPU has been processed along the path. Note that the SAPUinfo is associated to a SAPUid and a SAPU, which includes reporting information related to the SAPU that is identified by the SAPUid. Westberg, et al. Expires April 2003 [Page 30] Internet Draft Proposal for RSVPv2 October 2002 5.1.1.2. Message Structure for intra-domain signaling The structure of the RSVPv2 (ALSP and CSTP) messages that are used for intra-domain signaling is similar on the one proposed in [BrLi01]. Note that this structure contains also the CSTP INFO message, which transports a SAPU type with neither reliable nor refreshing delivery. Moreover, note that the SAPU type that is transported within a CSTP NEW or CSTP MOD message is transported without reliable delivery. CSTP NEW: xSig(NEW, h-src, SAPUid, SAPU, R, LocalSAPU) CSTP MOD: xSig(MOD, h-src, SAPUid, SAPU, old-SAPUid, R, LocalSAPU) CSTP TEAR: xSig(TEAR, h-src, SAPUid, LocalSAPU) CSTP REFRESH: xSig(REFRESH, h-src, SAPUid, R, LocalSAPU) CSTP ACK: xSig(ACK, h-src, SAPUid-list) CSTP NACK: xSig(NACK, h-src, SAPUid) CSTP EVENT: xSig(EVENT, h-src, SAPUid, SAPU) CSTP CHALLENGE: xSig(CHALLENGE, h-src, challenge-object) CSTP RESPONSE: xSig(RESPONSE, h-src, challenge-object) CSTP INFO: xSig(INFO, h-src, SAPUid, SAPU, SAPUinfo) Where the parameters are identical to the ones described in [BrLi01]. The only additional parameters are the SAPUinfo and LocalSAPU parameters. The SAPUinfo parameter is used to report information related to how the a SAPU has been processed along the path. Note that the SAPUinfo is associated to a SAPUid and a SAPU, which includes reporting information related to the SAPU that is identified by the SAPUid. The LocalSAPU information includes locally defined objects that are only used in a domain. Westberg, et al. Expires April 2003 [Page 31] Internet Draft Proposal for RSVPv2 October 2002 5.1.1.3. Format of RSVPv2 ALSP SAPUs Based on the above defined RSVPv2 object-class structure the format of the RSVPv2 ALSP SAPUs may be as follows: ::= [] Path SAPU contains globally defined objects and Path LocalSAPU contain locally defined objects ::= [] Resv SAPU contains globally defined objects and Resv LocalSAPU contain locally defined objects ::= [] The ACK SAPUinfo is used to report to ALSP that an ALSP has been succesfully processed. It can contain globally and/or locally defined objects. ::= [] The NACK SAPUinfo is used to report to ALSP that an ALSP has not been processed successfully. It can contain globally and/or locally defined objects. ::= Westberg, et al. Expires April 2003 [Page 32] Internet Draft Proposal for RSVPv2 October 2002 [] ::= [] The above listed SAPU types of the RSVPv2 ALSP protocol will be mapped and transported by the following CSTP messages (see [BrLi01]): Meaning of SAPUs SAPU Type CSTP Message Type __________________________ _____________ _________________ Initiation Path NEW Initiation Resv NEW Modification Path MOD Modification Resv MOD Positive ACK report ACK SAPUinfo INFO Negative NACK report NACK SAPUinfo INFO Local Path initiation info LocalSAPU NEW Local Path modification info LocalSAPU MOD Local Path refreshing info LocalSAPU REFRESH Local Path tear info LocalSAPU TEAR Local Resv initiation info LocalSAPU NEW Local Resv modification info LocalSAPU MOD Local Resv refreshing info LocalSAPU REFRESH Local Resv tear info LocalSAPU TEAR Local positive ACK report ACK SAPUinfo INFO Local negative ACK report NACK SAPUinfo INFO Path Tear down Path TEAR Resv Tear down Resv TEAR Path Error report PathErr EVENT Resv Error report ResvErr EVENT Resv Confirm ResvErr EVENT Westberg, et al. Expires April 2003 [Page 33] Internet Draft Proposal for RSVPv2 October 2002 5.2. RSVPv2 ALSP Objects in RSVPv2 ALSP Object_Classes This section presents a generic method of mapping globally and locally defined RSVPv2 ALSP objects into RSVPv2 ALSP classes. Based on the definitions of the RSVPv2 ALSP object classes, an RSVPv2 ALSP 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 ALSP Object_Classes. The locally defined 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 Section 5.2.2. Service_Class: [] [] Flow_Specification_Class: Reservation_State_Management_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 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 Westberg, et al. Expires April 2003 [Page 34] Internet Draft Proposal for RSVPv2 October 2002 have to be provided. Based on the ALSP RSVPv2 object-class structure an example of a possible mapping of RSVPv1 objects in RSVPv2 object structure is given. The main design constraint for RSVPv1 was multicast support. Because of this, RSVPv1 is a receiver-initiated protocol with complex "soft" state maintenance in order to support dynamic membership changes in the multicast group, i.e. reservation state merging and maintenance. Given that the vast majority of traffic in typical IP networks is point-to-point unicast, the need to optimize RSVPv2 for unicast is clear. If optimized for unicast, RSVPv1 does not have to be receiver- initiated. Optimization for unicast support as a design requirement will introduce some beneficial changes in the RSVPv2 protocol. These changes will lead to a reduced complexity in reservation state maintenance, for example there will be no need for dynamic membership changes in a multicast group. In RSVPv1 there are a number of mandatory objects related to the multicast support and receiver-initiated approach. These objects will not be needed, i.e. will not be mandatory if the protocol is optimized for unicast and is sender-initiated. The RSVPv1 Objects dedicated to multicast support and received- initiated approach are: * SCOPE Carries an explicit list of sender hosts towards which the information in the message is to be forwarded. This object is an object for multicast support and it may appear in a Resv, ResvErr, or ResvTear RSVPv1 messages. * STYLE Defines the reservation style plus style-specific information that is not in FLOWSPEC or FILTER_SPEC objects. It is mandatory in every Resv RSVPv1 message. This is also an multicast object. Once the protocol is optimized for unicast there will only be one style of reservation, i.e. explicit reservation style. * FILTER_SPEC Defines a subset of session data packets that should receive the desired QoS (specified by a FLOWSPEC object), Westberg, et al. Expires April 2003 [Page 35] Internet Draft Proposal for RSVPv2 October 2002 in a Resv message. This is an object that is related to multicast and receiver-initiated approach. In a unicast sender-initiated approach due to a single reservation style there will only be one filter used, i.e. Fixed Filter (FF) by a single unicast session. * RSVP_HOP object This object carries the IP address of the RSVP-capable node that sent this message and a logical outgoing interface handle. In RSVPv1, RSVP_HOP object is referred as a PHOP ("previous hop") object for downstream messages or as a NHOP (" next hop") object for upstream messages. Thus it is used for backward routing that is only useful in receiver-initiated approach. * FLOWSPEC This object contains the QoS request desired by the receiver. Thus it is needed only for the receiver-initiated approach. * ADSPEC This object carries the OPWA data in a Path message in the communication path from the sender to the receiver. It is only useful in a receiver-initiated approach. * RESV_CONFIRM Carries the IP address of a receiver that requested a confirmation. This object is only required in the receiver initiated approach. Therefore the mandatory objects that will be needed in an sender- initiated ALSP RSVPv2 optimized for unicast are: * 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. Westberg, et al. Expires April 2003 [Page 36] Internet Draft Proposal for RSVPv2 October 2002 * 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]. Based on the definitions of the RSVPv2 object classes, RSVPv1 objects (see [RFC2205]) can be re-used in a RSVPv2 object-class structure. During the RSVPv2 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 object classes and the current RSVPv1 objects the mapping of RSVPv1 objects into the RSVPv2 object- Westberg, et al. Expires April 2003 [Page 37] Internet Draft Proposal for RSVPv2 October 2002 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: [] [] {} {} {} [] Flow_Specification_Class: {} {} Reservation_State_Management_Class: {