Internet Draft RSVPv1 as NTLP March 2003 Internet Engineering Task Force L. Westberg INTERNET-DRAFT G. Karagiannis Expires September 2003 V. Rexhepi Ericsson March 2003 Using RSVPv1 as NTLP (NSIS Transport Layer Protocol): suggestions for modifications on RFC2205 draft-westberg-nsis-rsvp-as-ntlp-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 September 2003 [Page 1] Internet Draft RSVPv1 as NTLP March 2003 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 is proposing a (NSIS Transport Layer Protocol) NTLP that is a modified version of RSVPv1 specified in RFC2205. Furthermore, it provides design guidelines and specifications for the development of the NLTP that is based on a modified version of RSVPv1. Westberg, et al. Expires September 2003 [Page 2] Internet Draft RSVPv1 as NTLP March 2003 Table of Contents 1 Introduction ................................................. 4 1.1 Motivation of using RSVPv1 as NTLP ........................ 4 1.2 Definitions/Terminology .................................... 5 2 NTLP concept and features .................................... 8 2.1 NTLP features .............................................. 8 2.2 NTLP Message Formats ....................................... 9 2.2.1 Common Header ............................................ 10 2.2.2 Transport layer object formats ........................... 12 2.3 NTLP concept ............................................... 14 3 Suggestions for modifications on RFC2205 ..................... 16 4 References ................................................... 18 5 Authors' Addresses ........................................... 19 Westberg, et al. Expires September 2003 [Page 3] Internet Draft RSVPv1 as NTLP March 2003 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. The NSIS WG uses the two-level architecture for Internet Signaling proposed in [BrLi01]: (1) a common lower level that performs transport-layer functions. This common lower level is denoted in [Hanco2] as NSIS Transport Layer Protocol (NTLP) that is a placeholder name for the NSIS protocol component that will support lower layer (signaling application independent) 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 signaling layer protocols denoted in [Hanc02] as NSIS Signaling Layer Protocol (NSLP). This memo outlines the main concept that is used by the proposed NTLP and provides guidelines and specifications for the modifications that have to be done in RFC2205 [RFC2205], such that RSVPv1 can be applied as NTLP. 1.1. Motivation of using RSVPv1 as NTLP A great deal of effort was put into the specification and design of the RSVPv1 [RFC2205] protocol. 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. The main transport-layer features supported by RSVPv1 [RFC2205], such as support of unicast path-coupled signaling and soft state support have been proven in practice of being lightweight and robust. However, the multicast support introduces a level of complexity into the RSVPv1 protocol that is not needed in support of unicast applications. For example, RSVPv1's state maintenance is complex as Westberg, et al. Expires September 2003 [Page 4] Internet Draft RSVPv1 as NTLP March 2003 it needs to support dynamic membership changes in the multicast groups, such as reservation state merging and maintenance. Our working assumption is that RSVPv1 should be optimized for unicast rather than multicast and that relaxing this design constraint will in turn greatly simplify the protocol. Using RSVPv1 as NTLP will eliminate the need of reinventing solutions for transport-layer features. Furthermore, this will shorten the time needed to standardize NTLP by reusing the current RSVP design experience and RSVP protocol specification. Moreover, after minor modifications, existing RSVPv1 [RFC2205] implementations can be reused and used as NTLP, decreasing the deployment costs. Additional transport-layer features can be introduced in a modular way, either by adding them one by one as optional features into the NTLP specifications and implementations or using an existing protocol below NTLP that could provide these additional features. 1.2. Definitions/Terminology 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) (identical to [Hanc02]): Administrative domain where an NSIS protocol signals for a resource or set of resources. NSIS Entity (NE) (identical to [Hanc02]): 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. Westberg, et al. Expires September 2003 [Page 5] Internet Draft RSVPv1 as NTLP March 2003 NSIS Forwarder (NF) (identical to [Hanc02]): 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: 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 [Hanc02]): NSIS Entity that initiates NSIS signaling for a network resource. NSIS Responder (NR) (identical to [Hanc02]): NSIS Entity that terminates NSIS signaling and can optionally interact with applications as well. NSIS Signaling Layer Protocol (NSLP) (identical to [Hanc02]): generic term for an NSIS protocol component that supports a specific signaling application. NSIS Transport Layer Protocol (NTLP) (identical to [Hanc02]): Westberg, et al. Expires September 2003 [Page 6] Internet Draft RSVPv1 as NTLP March 2003 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 NF entity that is NTLP stateful. NF NTLP stateless NF entity that is NTLP stateless. Resource Management Function (RMF) (identical to [Hanc02]): 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 Westberg, et al. Expires September 2003 [Page 7] Internet Draft RSVPv1 as NTLP March 2003 can be considered as a NI or a NR. 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. NTLP concept and features As mentioned in Section 1 of this memo the NTLP performs transport- layer functions that are signaling application independent. 2.1. NTLP features The NTLP provides the following subset of transport layer functions: * Support of Path-Coupled (Path-Directed) Signaling. The NTLP signaling messages are routed on the same path as the path followed by the data path. NTLP is not itself a routing protocol and it should be designed to operate with current and future routing protocols. Similar to RSVPv1 [RFC2205], a NTLP process, consults the local routing database(s) to obtain routes. * Soft state support: This feature is similar to the soft state feature supported by RSVPv1 [RFC2205] and ensures that a state will be removed if it is not periodically refreshed or explicitly removed. This state is mainly used as a path state, where it maintains path-coupled routing information. The NTLP soft state, similar to RSVPv1, is created and periodically refreshed by Path and Resv messages. This state, similar to RSVPv1, is deleted either if no matching refresh messages arrive before the expiration of a "cleanup timeout" interval, or may also be deleted by an explicit "teardown" message, i.e., PathTear or ResvTear. At the expiration of each "refresh timeout" period and after a state change, NTLP scans its state to build and forward Path and Resv refresh messages to succeeding hops. The state is globally and unique identified by a transport state identifier that is associated to a data flow and has to remain unchanged for the complete duration of the data flow. Moreover, for the duration of a data flow, the transport state identifier remains the same while the Westberg, et al. Expires September 2003 [Page 8] Internet Draft RSVPv1 as NTLP March 2003 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 transport state identifier associated with that data flow should not change. The RSVPv1 "Session" object can be applied as NTLP transport state ID. * 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 NTLP protocol level has to adapt to load sharing once it is used. * The NTLP signaling protocol is able to exchange local information between NSIS Forwarders located within one single administrative domain. * In case of unexpected situations, e.g., errors, any NSIS Forwarder is able to asynchronously generate a signaling message. * NTLP transports application layer (NSLP) "objects" that are opaque to NTLP. * NTLP provides transparent operation through routers that do not support it. * NTLP supports both IPv4 and IPv6. 2.2. NTLP Message Formats NTLP uses the existing RSVPv1 signaling messages as NTLP transport protocol messages. However, ResvConf is not anymore used, since the confirmation of a reservation is considered to be an application layer related feature. The NTLP message types are: Path, Resv, PathErr, ResvErr, ResvTear. The main difference is related to the objects that will be carried by these messages, where the number of mandatory objects is reduced substantially. The NTLP message, see Figure 1, 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 Westberg, et al. Expires September 2003 [Page 9] Internet Draft RSVPv1 as NTLP March 2003 layer (NSLP) "objects" are opaque and transparent to NTLP. A router implementation should create and read messages with the objects in the order shown in [RFC2205]. However, note that only a subset of the objects specified in [RFC2205] are needed in NTLP. 0 1 2 3 +-------------+-------------+-------------+-------------+ | | + Common Header + | | +-------------+-------------+-------------+-------------+ | | // (Transport layer objects content) // | | +-------------+-------------+-------------+-------------+ | | // (Application layer (NSLP) objects content) // | | +-------------+-------------+-------------+-------------+ Figure 1: NTLP message format 2.2.1. Common Header The common header, excluding the ResvConf message, is identical to the RSVPv1 Common header specified in [RFC2205]. Westberg, et al. Expires September 2003 [Page 10] Internet Draft RSVPv1 as NTLP March 2003 0 1 2 3 +-------------+-------------+-------------+-------------+ | Vers | Flags| Msg Type | RSVP Checksum | +-------------+-------------+-------------+-------------+ | Send_TTL | (Reserved) | RSVP Length | +-------------+-------------+-------------+-------------+ The fields in the common header are as follows: Vers: 4 bits Protocol version number. This is version 1. Flags: 4 bits 0x01-0x08: Reserved No flag bits are defined yet. Msg Type: 8 bits 1 = Path 2 = Resv 3 = PathErr 4 = ResvErr 5 = PathTear 6 = ResvTear RSVP Checksum: 16 bits The one's complement of the one's complement sum of the message, with the checksum field replaced by zero for the purpose of computing the checksum. An all-zero value means that no checksum was transmitted. Send_TTL: 8 bits Westberg, et al. Expires September 2003 [Page 11] Internet Draft RSVPv1 as NTLP March 2003 The IP TTL value with which the message was sent. See Section 3.8. RSVP Length: 16 bits The total length of this RSVP message in bytes, including the common header and the variable-length objects that follow. 2.2.2. Transport layer object formats Similar to [RFC2205], every object consists of one or more 32-bit words with a one-word header, with the following format: 0 1 2 3 +-------------+-------------+-------------+-------------+ | Length (bytes) | Class-Num | C-Type | +-------------+-------------+-------------+-------------+ | | // (Transport layer object content) // | | +-------------+-------------+-------------+-------------+ An object header has the following fields: Length A 16-bit field containing the total object length in bytes. Must always be a multiple of 4, and at least 4. Class-Num Identifies the object class (see [RFC2205]); An NTLP implementation must recognize the following classes: NULL (as in [RFC2205]) A NULL object has a Class-Num of zero, and its C-Type is ignored. Its length must be at least 4, but can be any multiple of 4. A NULL object may appear anywhere in a sequence of objects, and its contents will be ignored by the receiver. SESSION (as in [RFC2205]) Westberg, et al. Expires September 2003 [Page 12] Internet Draft RSVPv1 as NTLP March 2003 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. Required in every NTLP message. The "Session" object can be applied as NTLP transport state ID. RSVP_HOP (as in [RFC2205]) Carries the IP address of the NTLP aware node that sent this message and a logical outgoing interface handle (LIH). This document refers to a RSVP_HOP object as a PHOP ("previous hop") object for downstream messages or as a NHOP (" next hop") object for upstream messages. TIME_VALUES (as in [RFC2205]) Contains the value for the refresh period R used by the creator of the message; Required in every Path and Resv message. ERROR_SPEC (as in [RFC2205]) Specifies an error in a PathErr, ResvErr, or a confirmation in a ResvConf message. INTEGRITY (as in [RFC2205]) Carries cryptographic data to authenticate the originating node and to verify the contents of this NTLP message. The use of the INTEGRITY object is described in [RFC2747]. C-Type Object type, unique within Class-Num. Values are defined in [RFC2205]. Westberg, et al. Expires September 2003 [Page 13] Internet Draft RSVPv1 as NTLP March 2003 2.3. NTLP concept The NTLP protocol can be used for End-to-End, Edge-to-Edge, and End- to-Edge scenarios. In the End-to-End scenario 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 NSIS framework shown in Figure 2 and Figure 3 is separated in two different levels. The lowest hierarchical level represents the NTLP level protocol and the higher hierarchical level represents the NSLP. Note that 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, the NF interior nodes of a domain can be either NTLP stateful nodes (see Figure 2) or, when processing optimisation is required, the NF interior nodes can be NTLP stateless nodes (see Figure 3). The NF NTLP 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 NTLP protocol. The interface between NTLP and NSLP can be based on an Application Program Interface (API) and its specification is ouf of the scope of this memo. Westberg, et al. Expires September 2003 [Page 14] Internet Draft RSVPv1 as NTLP March 2003 |------| |-------| |-------| |-------| |-------| |------| | NSLP |<->| NSLP |<->| NSLP |<->| NSLP |<->| NSLP |<->| NSLP | | | | | | | | | | | | | |------| |-------| |-------| |-------| |-------| |------|--- | | | | | | | | | | | | ^ | | | | | | | | | | | | | -------------------------------------------------------------------API | | | | | | | | | | | | | | | | | | | | | | | | | v |------| |-------| |-------| |-------| |-------| |------|--- | NTLP |<->| NTLP |<->| NTLP |<->| NTLP |<->| NTLP |<->| NTLP | |st.ful| |st.ful | |st.ful | |st.ful | |st.full| |st.ful| |------| |-------| |-------| |-------| |-------| |------| NI NF NF NF NF NR (edge) (interior) (interior) (edge) NTLP st.ful : NTLP stateful Figure 2: NTLP/NSLP framework with stateful NF(interior) nodes Westberg, et al. Expires September 2003 [Page 15] Internet Draft RSVPv1 as NTLP March 2003 |------| |-------| |-------| |-------| |-------| |------| | NSLP |<->| NSLP |<->| NSLP |<->| NSLP |<->| NSLP |<->| NSLP | | | | | | | | | | | | | |------| |-------| |-------| |-------| |-------| |------|--- | | | | | | | | | | | | ^ | | | | | | | | | | | | | -------------------------------------------------------------------API | | | | | | | | | | | | | | | | | | | | | | | | | v |------| |-------| |-------| |-------| |-------| |------|--- | 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 3: NTLP/NSLP framework with stateless NF(interior) nodes 3. Suggestions for modifications on RFC2205 Based on the introduced features and concept presented in Section 2, we've gone through the RFC2205 to find out how much of the RSVPv1 specification can be reused in changing RSVPv1 into an NTLP. We've seen that a lot of work and text available in RFC2205 can be re-used in specifying a modified version of RSVPv1 that can be used as NTLP. A list with such changes on RFC2205 is given below. RFC2205 table of contents: * Section 1 of RFC2205: Introduction - needs to be re-written 1.1 Data Flows 1.2 Reservation Model - needs to be re-written to introduce the used transport model 1.3 Reservation Styles - is not needed anymore as this is Signaling Application specific 1.4 Examples of Styles - is not needed anymore as this is Signaling Application specific * Section 2 of RFC2205: RSVP Protocol Mechanisms 2.1 RSVP Messages - minor changes are needed to emphasise that these messages are mainly used for Westberg, et al. Expires September 2003 [Page 16] Internet Draft RSVPv1 as NTLP March 2003 transport layer functionality. 2.2 Merging Flowspecs - is not needed anymore as this is Signaling Application specific 2.3 Soft State - needs to be changed such that it explains transport state management functionality, see Section 2 of this memo. 2.4 Teardown - needs to be changed such that it explains transport state management functionality 2.5 Errors - minor changes are needed to emphasize the transport layer functionality 2.6 Confirmation - is not needed anymore as this is Signaling Application specific 2.7 Policy Control - is not needed any more as this is Signaling Application specific 2.8 Security - minor changes are needed to emphasize the transport layer functionality 2.9 Non-RSVP Clouds - may remain the same 2.10 Host model- we can reuse it, but we'll need to update it to emphaise the transport layer functionality * Section 3 of RFC2205: RSVP Functional Specification 3.1 RSVP Message Formats - remains basically the same apart from the objects, i.e. the mentioned objects in Section 2 of this memo remain while the rest of the objects will be removed completely. . . 3.2 Port Usage - remains the same 3.3 Sending RSVP Messages - remains the same apart from the multicast part which we'll need to remove 3.4 Avoiding RSVP Message Loops - remains the same. Here there is a paragraph that explains what to do when WF is used, which it could be removed. 3.5 Blockade State - probably it could be removed, since the blockade state can be considered as Signaling Application specific 3.6 Local Repair - minor changes are needed to emphasize the transport layer functionality 3.7 Time Parameters - minor changes are needed to emphasize the transport state management and refresh mechanisms. 3.8 Traffic Policing and Non-Integrated Service Hops - is not Westberg, et al. Expires September 2003 [Page 17] Internet Draft RSVPv1 as NTLP March 2003 needed as it is Signaling Application specific, i.e., Intserv specific 3.9 Multihomed Hosts - may be reused 3.10 Future Compatibility remains the same 3.11 RSVP Interfaces - it will either be completely removed or it will be changed to define new API interfaces to the signaling application layer (NSLP). * Section 4 of RFC2205: Acknowledgements needs of course to be re-written * APPENDIX A. Object Definitions - needs to be changed, according to the details provided in Section 2 of this memo. * APPENDIX B. Error Codes and Values - most error codes and values will remain the same. However, new error codes and values might be defined. * APPENDIX C. UDP Encapsulation - remains the same * APPENDIX D. Glossary - needs to be updated accordingly with the changes in the document * REFERENCES - need to be updated accordingly 4. References [BrLi01] Braden, R., Lindell, B., "A Two-Level Architecture for Internet Signaling", Internet Draft (work in progress), 2001. [Hanc02] Hancock, R., Freytsis, I., Karagiannis, G., Loughney, J., Van den Bosch, S., "Next Steps in Signaling: Framework", Internet Draft, 2002, Work in progress. [RFC2205] Braden, R., Zhang, L., Berson, S., Herzog, A., Jamin, S., "Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification", IETF RFC 2205, 1997. [RFC2747] F. Baker, B. Lindell, M.Talwar. "RSVP Cryptographic Authentication", IETF RFC, January 2000. Westberg, et al. Expires September 2003 [Page 18] Internet Draft RSVPv1 as NTLP March 2003 5. Authors' Addresses Lars Westberg Ericsson Research Torshamnsgatan 23 SE-164 80 Stockholm Sweden EMail: Lars.Westberg@era.ericsson.se Georgios Karagiannis Ericsson EuroLab Netherlands B.V. Institutenweg 25 P.O.Box 645 7500 AP Enschede The Netherlands EMail: Georgios.Karagiannis@eln.ericsson.se Vlora Rexhepi Ericsson EuroLab Netherlands B.V. Institutenweg 25 P.O.Box 645 7500 AP Enschede The Netherlands EMail: Vlora.Rexhepi@eln.ericsson.se Westberg, et al. Expires September 2003 [Page 19]