Internet Draft Proposal for RSVPv2 August 2002 Internet Engineering Task Force L. Westberg INTERNET-DRAFT G. Karagiannis Expires February 2003 D. Partain V. Rexhepi Ericsson August 2002 A Proposal for RSVPv2 draft-westberg-proposal-for-rsvpv2-00.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. Westberg, et al. Expires February 2003 [Page 1] Internet Draft Proposal for RSVPv2 August 2002 Abstract The Resource ReSerVation Protocol (RSVP) 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. Rather, this memo attempts to look forward toward a new version of RSVP that would address the problems and remove some barriers to the realization of new QoS-based services. Westberg, et al. Expires February 2003 [Page 2] Internet Draft Proposal for RSVPv2 August 2002 Table of Contents 1 Introduction ................................................. 4 2 Motivation for RSVPv2 ........................................ 4 2.1 Effects of the Design of RSVP .............................. 5 2.1.1 Designed for Multicast Applications ...................... 5 2.1.2 Least Common Denominator Not Small Enough ................ 5 2.1.3 Sender-initiated versus Receiver-initiated Signalling .... 6 2.1.4 Designed for End-host to End-host Communication .......... 6 2.2 Different Network Signalling Requirements/Needs and RSVP ........................................................... 7 3 Design Goals for RSVPv2 ...................................... 8 3.1 Increased Object Modularity ................................ 8 3.2 Hierarchical Object Structure .............................. 9 3.3 Global and Local Objects ................................... 9 3.4 Object Re-use .............................................. 9 3.5 Reduced Focus on Multicast ................................. 10 3.6 Primarily Sender-initiated Signalling ...................... 10 4 RSVPv2 Object Structure ...................................... 10 4.1 Message Structure in RSVPv2 ................................ 12 5 Appendix 1 ................................................... 14 5.1 RSVP Optimized for Unicast and Sender-Initiated ............ 14 5.2 Mapping of RSVP Objects in RSVPv2 Object Structure ......... 17 5.3 Example of a RSVPv2 Message Structure ...................... 18 6 References ................................................... 19 7 Authors' Addresses ........................................... 20 Westberg, et al. Expires February 2003 [Page 3] Internet Draft Proposal for RSVPv2 August 2002 1. Introduction A number of different QoS solutions have been developed by the IETF, amongst them IntServ and its signalling protocol, RSVP, defined in [RFC2205]. RSVP [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. RSVP 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 RSVP, which we call RSVPv2. The goal of RSVPv2 would be to rectify the issues that have been identified with RSVP and provide an evolutionary path forward. This memo first outlines the motivation for doing this work and provides some design guidelines for the development of RSVPv2. Thereafter, it proposes a new structure of RSVP objects, which we refer to as the RSVPv2 object structure. The goal of this RSVPv2 object structure is to provide the initial step in the design of RSVPv2. 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, RSVP. As such, there must be a clear need for the evolution of RSVP. 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 RSVP and in considering whether those design constraints can be relaxed or changed in designing RSVPv2. Westberg, et al. Expires February 2003 [Page 4] Internet Draft Proposal for RSVPv2 August 2002 2.1. Effects of the Design of RSVP This section outlines some of the design considerations that went into the design of RSVP, which in turn led to decisions that make it difficult to use RSVP beyond its originally-intended scope. RSVP 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. 2.1.1. Designed for Multicast Applications One of the most important design requirement for RSVP 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, RSVP'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, RSVP 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, RSVP 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: Westberg, et al. Expires February 2003 [Page 5] Internet Draft Proposal for RSVPv2 August 2002 * Some objects are always carried in RSVP 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 RSVP. On May 20, 2002, Bob Braden, one of the creators of RSVP, 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 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 RSVP 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 RSVP 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 Westberg, et al. Expires February 2003 [Page 6] Internet Draft Proposal for RSVPv2 August 2002 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 RSVP whereas the signalling 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, RSVP 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, RSVP 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 RSVP. * 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) Westberg, et al. Expires February 2003 [Page 7] Internet Draft Proposal for RSVPv2 August 2002 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 for RSVPv2 This section briefly outlines some of the guiding principles behind the design of RSVPv2. 3.1. Increased Object Modularity The essential design goal for RSVPv2 is to preserve the flexibility of RSVP while at the same time further expanding its modularity. The purpose of this object modularity is to increase processing efficiency of RSVPv2 messages by only including those objects relevant in a particular part of the network. RSVP uses flexible object definitions that are opaque to RSVP 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 RSVP message may contain up to fourteen classes of attribute objects. Even if some of the RSVP objects are not needed in a scenario they will have to be included in RSVP messages and considered as mandatory objects. In order to achieve modularity, the RSVPv2 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 RSVP object structure and by introducing a concept of "profiles". A profile is a specification of which RSVP objects are needed for a certain network scenario (see Section 2.2 above). In this way, the RSVP messages will only carry the RSVP 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 February 2003 [Page 8] Internet Draft Proposal for RSVPv2 August 2002 3.2. Hierarchical Object Structure RSVP, 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. RSVPv2 will endeavor to improve this by providing a hierarchical structure and positioning of the RSVPv2 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 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. Objects that will be processed only in specific routers can be placed later in the sequence. 3.3. Global and Local Objects 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.4. Object Re-use Obviously, whenever it is appropriate, RSVPv2 will re-use objects that are defined for RSVP. Westberg, et al. Expires February 2003 [Page 9] Internet Draft Proposal for RSVPv2 August 2002 3.5. 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, it is entirely possible that appropriate objects will be defined in support of multicast. 3.6. Primarily Sender-initiated Signalling Given a reduced focus on multicast, the "obvious" choice of sender- initiated signalling seems to be applicable to RSVPv2. The receiver- initiated reservations will undoubtedly still be needed in some network scenarios, so RSVPv2 will need to handle such reservations as well. However, this feature will be optional. 4. RSVPv2 Object Structure In order to have a flexible and modular RSVPv2 object structure, we propose a grouping of signalling information into RSVPv2 object classes, called RSVPv2 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. In RSVPv2 object structure the following RSVPv2 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 Westberg, et al. Expires February 2003 [Page 10] Internet Draft Proposal for RSVPv2 August 2002 of networking scenarios such as a host-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 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 Westberg, et al. Expires February 2003 [Page 11] Internet Draft Proposal for RSVPv2 August 2002 This class includes information related to the errors that occur during reservation state processing. 4.1. Message Structure in RSVPv2 During the design of RSVPv2 the role of the RSVP messages might change. Also, it might be that some messages will not be used and new messages may be defined. In any case, the message structure will remain the same as in RSVP. However, 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.1). A profile can be either standardized or it could be an agreement between two or more participants. Although a detailed discussion on RSVPv2 message structure is outside of the scope of this draft, based on the above defined RSVPv2 object structure the format of the RSVPv2 messages may be as follows: ::= [] ::= [] ::= [] ::= [] Westberg, et al. Expires February 2003 [Page 12] Internet Draft Proposal for RSVPv2 August 2002 ::= [] ::= [] * ::= [] * where Resv_Confirm message is mandatory only for multicast support and receiver-initiated approach Westberg, et al. Expires February 2003 [Page 13] Internet Draft Proposal for RSVPv2 August 2002 5. Appendix 1 This appendix describes the changes in the mandatory usage of RSVP objects, if RSVP is to be optimized for unicast support. Based on the RSVPv2 object structure described in Section 4, an example of a possible mapping of of RSVP objects in RSVPv2 object structure is given. An example of an RSVPv2 message structure is shown as well. 5.1. RSVP Optimized for Unicast and Sender-Initiated The main design constraint for RSVP was multicast support. Because of this, RSVP 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, RSVP 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 RSVP 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 RSVP 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 RSVP 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 RSVP message. This is also an multicast object. Once the protocol is optimized for Westberg, et al. Expires February 2003 [Page 14] Internet Draft Proposal for RSVPv2 August 2002 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), 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 RSVP, 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 RSVPv2 optimized for unicast are: * SESSION Westberg, et al. Expires February 2003 [Page 15] Internet Draft Proposal for RSVPv2 August 2002 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 RSVP message. The use of the INTEGRITY object is described in [RFC2747]. Westberg, et al. Expires February 2003 [Page 16] Internet Draft Proposal for RSVPv2 August 2002 5.2. Mapping of RSVP Objects in RSVPv2 Object Structure Based on the above definitions of the RSVPv2 object classes, RSVP objects can be re-used in a RSVPv2 object structure. During the RSVPv2 design phase the RSVP 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 RSVP objects. Based on the description of RSVPv2 object classes and the current RSVP objects the mapping of RSVP objects into the RSVPv2 object structure is rather simple. This mapping is given below and it is done for all RSVP objects: Service_Class: {} {} {} [] Flow_Specification_Class: {} {} Reservation_State_Management_Class: {