M. Brunner Internet Draft R. Greco Document: draft-brunner-nsis-rsvp2-00.txt NEC Expires: March 2003 October 2002 Towards RSVP Version 2 <draft-brunner-nsis-rsvp2-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. Abstract This memo is a first step towards the design of RSVP Version 2. We take RSVP Version 1 as a basis of this work. RSVP has been criticized mainly because of its complexity and poor scalability among others. We present the first steps towards the definition of a new version of RSVP. The goal is to provide a more "light" approach that can help improve handling reservations in the network by means of a simplified behavior. This proposal for RSVP Version 2 is not meant as a complete replacement of RSVP Version 1 but is meant to coexist with Version 1. For some scenarios such as receiver orientation and multicasting we assume that RSVP version 1 works fine. 1. Introduction A key to the success in the provision of QoS over the Internet is the ability to schedule resources along the communications paths according to the reservations issued by users. As a result of reservation signaling, the nodes along the communications paths Brunner,Greco - Expires March 2003 1 Towards RSVP Version 2 October 2002 should contain sufficient information to detect packets belonging to specific data flows and be prepared to provide them with an adequate quality of service. Not only QoS needs signaling but different other applications should get enabled such as signaling for MPLA label switched paths or for firewall traversals [TIST][RSVP-TE]. Currently, the most widely used reservation protocol is RSVP. RSVP has a large number of implementations in place and it has been standardized by the IETF in September 1997. For these reasons, we take RSVP as the basis of this work. However, since its standardization, RSVP has been criticized mainly because of its complexity and poor scalability. The protocol has been designed for large multicast scenarios and for multicast applications such as the distribution of audio and video contents over IP multicast, as it is done with the MBONE [RFC 3170]. Although RSVP responds well to the needs why it has been designed, it is felt to be too complex to be used in many other scenarios, that are perhaps more restricted but nevertheless useful for a wide range of applications. This document presents the first steps towards the definition of a new version of RSVP, which we call RSVPv2. The goal of RSVPv2 is to provide a more "light" approach that can help improve handling reservations in the network by means of a simplified behavior. In particular, the new protocol should be able to be more efficient in terms of reservations setup time. We also introduce into the protocol a series of new mechanisms that extend it to make it able to handle mobility. It is a first experiment to open up the road for applications based on mobile IP that need an adequate provision of quality of service. RSVPv2 is not intended to replace RSVP but, on the contrary, to coexist with it in a dual stack architecture, so that both reservation protocols are available to applications with different needs. In the rest of this document, we present in details a possible design of RSVPv2, including the new features for mobility. The message formats are a quick shot and must be refined in the future anyway. 2. Conventions used in this document 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 RFC-2119. 3. Design Principles 3.1. Co-exist with RSVP Version 1 The proposal explicitly changes RSVP Version one such that it co- exists with the implementation of version 1. It is not meant to re- design the feature RSVP version 1 does in a nice way. Brunner, Greco Expires March 2003 2 Towards RSVP Version 2 October 2002 Version 2 should run dual-stack together with version 1. 3.2. Small and efficient core protocol The core protocol is small, simple and efficient. Only minimal functionality is used in the core protocol. Everything, which might not be used in some scenarios or environments is removed and should get handled in the service specific part. 3.3. Service-specific extensibility The service-specific part is freely extensible. Any type of service request can be used. We assume some service types will get standardized, others are Network provider specific, or vendor specific. 3.4. Service Toolbox Since still a set of functionality might be reused for several service. We provide the mechanism to add common parts into the service specification. The question then is only is the comman part present or not. Examples of such common parts include security and policy data for authentication and authorization. 4. General features The main features of RSVPv2 have been designed by evaluating pros and cons and trying to learn as much as possible from RSVP, other protocols and from the critics moved to them. 4.1. Unicast RSVPv2 has been thought as a unicast protocol. Even if we consider multicast as an important feature of a signaling protocol, we focused, as a first step in the protocol design, on simplicity and a lightweight approach that can fit very well in many scenarios. We think that multicast support can be regarded as an extension to be added to the protocol. The idea is to have an underlying common structure that can be specialised adding different functionalities required by particular scenarios. We even believe the proposed protocol works also for multicast, however with homogeneous receivers and with only small groups. 4.2. Sender-Oriented We propose a sender-oriented protocol. This approach has been chosen considering that, in this way, the complexity of the protocol can be reduced. In fact, the cost of sending advertisements, processing them in each aware router along the path is eliminated, together with the necessity of symmetric routing (from source to destination and vice versa). Besides, the time to obtain a reservation decreases. This Brunner, Greco Expires March 2003 3 Towards RSVP Version 2 October 2002 approach does not give the receiver the opportunity to choose or change service-parameters. However, from the experience with RSVP version 1, it has been seen that in most of the cases the receiver will simply request whatever traffic bandwidth the sender has indicated. The receiver-oriented approach is helpful in multicast scenario where there is the need to accommodate a large number of groups membership and heterogeneous receiver requirements. As previously mentioned, RSVPv2 has been thought for unicast scenarios and as a minimal protocol where multicast support can be provided by RSVP version 1 running dual stack with RSVPv2 or by extension of the protocol itself. 4.3. Soft State RSVP version 1 is a Soft State protocol, which means that information about the flows are temporary saved along the path. Soft state gives adaptivity to route changes during the lifetime of a reservation and increases the protocol robustness to loss of messages. Besides, unexpected loss of connectivity from an end-point will simply lead to timeout states after some time along the path. These characteristics seem to be very important in every scenario where a signaling protocol can be used. Soft state, on the other hand, introduces the issue of refreshing the information stored along the path. For RSVPv2, we propose to make the end points of the reservation responsible for sending end-to-end refresh messages and in particular the source. In this way, the effort done by intermediate nodes is reduced to the forwarding of the refresh message as opposite to issuing such messages upon expiration of the correspondent soft state lifetime. Besides, even if the soft state approach does not require the existence of any mechanism for the explicit end (teardown) of a reservation, this feature can be useful to avoid keeping resources allocated when they are not needed any longer. RSVPv2 supports the explicit end of a reservation coming from the source that requested the reservation. 4.4. Reservation and Error notification After sending a reservation request, it is desirable to receive an answer about its result. RSVPv2 has been designed including a reservation acknowledgement sent from the destination back to the source in the case of a successful reservation. This acknowledgement can be used by the source as an indication that the reservation has been completed along the path. A source may decide whether to wait for this acknowledgement or not before sending the data (optimistic versus pessimistic behavior). In the same way, it is desirable to receive information in case of failure of a reservation in a node along the network. RSVPv2 sends an error notification from the node where the reservation failed back to Brunner, Greco Expires March 2003 4 Towards RSVP Version 2 October 2002 the source. This message may contain information on the state of the resources at the node where the failure occurred and it can be used by the source to perform a new reservation request with different parameters. However, this information is very service specific, there for the acknowledgment might contain service-specific information. 4.5. Modularity and Extensibility The proposal is partly modular in the sense that two different layers are used. The base signaling protocol and a service-specific part are differentiated. The base signaling protocol is pretty monolithic because it is optimized for speed. The service-specific part is very open to any modularity and extensibility. 4.6. Service specification RSVP version 1 can provide one of the following types of service: Guaranteed Load and Controlled Load Services and defines the according service specifications. RSVPv2 wants, on the other hand, to be as general as possible as far as offering services is concerned. The idea is that the protocol should be able to carry specifications for a large number of services in order to be easily used in different scenarios and not only for QoS. 4.7. Transport mechanism For RSVPv2, all messages are sent as raw IP packets, following the same approach used in version 1. The main motivation lies in the architectural consideration that we want to have a network-level signaling protocol. This basically excludes to use any transport protocol. 4.8. Flow Identifier and Reservation Identifier To keep things separate as much as possible, RSVPv2 uses different information to identify a flow and a reservation. In other words, each RSVP message carries a Reservation Identifier to address the reservation and a Flow Identifier that allows matching data level mechanisms with the reservation previously set. Mobile IP scenarios and processing refresh messages profit of this feature. The first because the source or destination address of the same reservation might change; the second because searching for a Reservation Identifier is fast than a N-tuple search. 4.9. Refreshing Reservations As described before we propose to reuse the soft-state approach. This implies the use of a refresh mechanism of information stored in states. In RSVPv2 refresh messages are generated from the endpoints and refresh all the state for the reservation saved along the path. Brunner, Greco Expires March 2003 5 Towards RSVP Version 2 October 2002 Refreshes happen through two different messages a reservation message as well as through a refresh message. Sending a smaller refresh message containing only the reservation id and the time value optimizes for lower badwidth and faster message processing. Using the refresh message approach, it is necessary to be aware that in case of route change, there will not be any route adaptation. A compromise need to be found between reducing the refresh period and not increasing too much the overhead of the protocol. Reducing the refresh interval mainly means: -Quicker adaptability to the routing changes -Increased robustness to message loss -Increasing the protocol overhead For these reasons, RSVPv2 leaves the application requiring the reservation the freedom to choose the more appropriate time interval for the refresh. The cost for signaling can be handled in a market managed way. 4.10. Timers The states need to be refreshed somehow. In order to keep the protocol simple, the numbers of timers used is reduced to the minimum. RSVP version 1 sets a timer for each state saved. This fact adds complexity and increase scalability problems in the core network due to the management of thousands of timers. The proposal for RSVPv2 is to use just one timer for each RSVPv2 daemon. This timer acts as a garbage collector periodically scanning the list of the saved states and erasing all the timed out entries. The time value carried by the reservation messages can be a default value or the expected time an application needs that particular service. Both solutions have pros and cons, but what is suggested is that the first message should carry the default time (i.e. 30s as suggested in RSVP version 1) because the reservation can fail before the end point of the reservation is reached and the states already set should timeout quickly. If the reservation is established, a longer time should be carried. With this solution, the synchronization of periodic refresh messages stated in RSVPv1 is avoided. 5. Outline of the protocol 5.1. Overview +--------------------------+ | Service-specific | +--------------------------+ | Base RSVPv2 | +--------------------------+ | IP | +--------------------------+ Brunner, Greco Expires March 2003 6 Towards RSVP Version 2 October 2002 Figure: Layering RSVPv2 as already Version 1 operates directly on top of IP. There is a limited base signaling protocol, where service-specifics are placed on top of the base protocol. In the base-protocol not much extensibility, modularity, or different modes of operations are included. The base signaling protocol should be fast and provide very basic functionality, whereas service specific parts are keeping a lot of functionality used for the signaling for that particular service. For instance, any policy data and security relevant data is kept in the service-specific part, since this heavily depends on the environment and situation the protocol is used. However, we could imagine that the service-specific part does have two layers as well. A common service toolbox containing anything dealing with security and policy might be defined in order to have unified mechanisms to be used by several services using RSVPv2. 5.2. Operation The scenario (and we use a scenario for ease of understanding) presented here consists of two end-systems placed in different part of the network that want to request a reservation before transmitting the data. The goal of the protocol is to carry a service request from the data source to the destination. This operation is carried out in two steps. As a first step, the source sends a reservation (RESV) message to the destination. If the message reaches the receiver, than an acknowledgement (ACK) is sent back from the receiver to the source as a confirmation of the reservation set up. If an error occurs along the path, then, the RESV message is not further forwarded and an error message (NACK) is returned back to the source. While processing a RESV message, each aware router along the path saves state and sets an appropriate reservation for the flow. 5.3. Basic Message Format The basic format of a RSVPv2 message is represented in the following Figure. +------------------------+ | Common RSVPv2 Header | +------------------------+ | Message-Type Specific | +------------------------+ | Service-Specific | +------------------------+ Figure 1: Basic message format Brunner, Greco Expires March 2003 7 Towards RSVP Version 2 October 2002 The structure of RSVPv2 messages consists of a common part, a message specific part, and a service specific part. The common part is included in all the messages of different types. The message type- specific part contains information common to all messages of that particular type, and finally the service-specific part is open to contain any service-specific information. 5.4. The Common Header The common header is very similar to the header for RSVPv1. 0 1 2 3 +-------------+-------------+-------------+-------------+ | Vers | Flags| Msg Type | RSVP Checksum | +-------------+-------------+-------------+-------------+ | Send_TTL | (Reserved) | RSVP Length | +-------------+-------------+-------------+-------------+ | Reservation Identifier | +-------------+-------------+-------------+-------------+ The fields in the common header are as follows: Vers: 4 bits Protocol version number. This is version 2. Flags: 4 bits 0x01 = No message processing until destination reached. This flag is the equivalent to the usage of the router alert option for RSVPv2 messages. It means that the packet must not get handled in the daemon until it reaches the IP destination address. But it also allows the daemon to differentiate in-band versus out-of-band signaling, if both runs on the same daemon. 0x02 = IPv6 addresses used This means the flow identifier contains IPv6 adresses 0x04 = Trigger bi-directional reservation It this bit is set a reservation in the reverse direction is triggered. It doesnot mean the same path through the network is used. 0x08 = for further study Msg Type: 8 bits 2 = Resv 6 = ResvTear 8 = Refresh Brunner, Greco Expires March 2003 8 Towards RSVP Version 2 October 2002 13 = Ack/Nack 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 The IP TTL value with which the message was sent. RSVP Length: 16 bits The total length of this RSVP message in bytes, including the common header and the variable-length objects that follow. Reservation Identifier The Reservation Identifier is a unique number identifying the reservation independent of any flow or service specification. 5.5. The Message-type Specific Fields Reservation Message Specific Fields +------------------------------------------+ | | | | | Flow Identifier | | | | | +------------------------------------------+ | Time Value | +------------------------------------------+ | Service Type | +------------------------------------------+ Figure: Message-Type Specific Fields A so-called Flow Identifier including the IP source and destination address and the TCP/UDP source and the destination port numbers represents each flow. We have chosen to keep a basic flow identifier in the reservation message itself. The other place could have been the service-specific part. Keeping it general help in certain situation such as NAT traversal, where a NAT can replace the IP addresses if they are NSIS aware. However, some services for example QoS using DiffServ might specify coarser grained flows. So any type of address masking or ranges of ports need to be carried in the service-specific part. Brunner, Greco Expires March 2003 9 Towards RSVP Version 2 October 2002 As previously pointed out, the soft state approach requires to set and manage a number of timers for the RSVP state saved along the path. In order to keep the protocol simple, we propose a solution that reduces the number of timers simplifying its managing even if the deallocation of timed out resources can be slightly penalized. RSVP version 1 sets a timer for each state saved. This in fact adds complexity and increases scalability problems in the core network due to the management of these of timers. RSVPv2 uses just one timer for each RSVP list of entries. This timer periodically scans the list of the saved states and erases all the timed out entries. In order to reduce the impact of refresh messages in the overhead of the protocol, the initiating node responsible for the reservation request, can specify, as a time value, the whole expected duration of the data transmission without sending any refresh. In case of an earlier end, an explicit tear down of the reservation can be performed using an appropriate TearDown message (TEAR) included among the protocol messages. The time value needs to be chosen according to the expected route changes the signaling protocol needs to handle. The Service Type field +------------------------------------------+ | toolbox | service identifier | +------------------------------------------+ The service type defines the kind of service requested. It is also used in other messages referring to that service, such as the ACK and refreshes. In order to allow for toolbox approach it is divided into two parts. The service identifier and the tools used. The values for the toolbox are 0x00: no toolbox functionality used. 0x01: security 0x02: policy 0x04 - 0x0X TBD The following values for the service identifier are predefined: 0: unknown 1: RSVPv1 Controlled Load and Guaranteed Service. Contains the FLOWSPEC defined according to [RFC 2210]. 2-1023: reserved for standardized services [TBD IANA] 1024-X: IANA X-Y: provider/domain specific Refresh Message Specific Field The refresh message only contains an additional field namely the time value. The definition is exactly the same as for the reservation message. It basically prolongs a reservation. The reservation is identified by the reservation identifier field of the common header. Brunner, Greco Expires March 2003 10 Towards RSVP Version 2 October 2002 +------------------------------------------+ | Time Value | +------------------------------------------+ Acknowledge/Not Acknowledge message (ACK/NACK) This ACK/NACK messages are used for feedback of the reservation process. The functionality they offer is pretty basic, but it is coherent with the whole protocol and its scope. The ACK simply tells the sender of the reservation that complete reservation process has been handled gracefully, the NACK tells the opposite, namely an error occurred somewhere in the network. The type of message is coded into the code field. Also different reasons for failures can be given in the Reason field. +------------------------------------------+ | Code | Reason | +------------------------------------------+ | Service Type | +------------------------------------------+ Codes: 0x00 : unknown 0x01 : ACK 0x02 : ACK hint 0x03 : Error (see below for error reasons) ...0x04 : Service-specific notification. The reason is then service- specific and semantic depends on the service type. Reason (if Code is set to 0x03) 0x00 : unknown, just does not work 0x01 : unavailable resources 0x02 : unknown service-type 0x03 : service not available anymore .... TBD In any case service-specific information can follow. Teardown message The tear down message does not have any additional parameters. 5.6. Service-Specific Information Any service-specific information needs to be defined in a different document and is out of scope of this document. 6. Security Considerations 7. References Brunner, Greco Expires March 2003 11 Towards RSVP Version 2 October 2002 [NSIS-REQ] M. Brunner et al. "Requirements for Signaling Protocols", draft-ietf-nsis-req-04.txt, September 2002. [TIST] M. Shore, "The TIST (Topology-Insensitive Service Traversal) Protocol", draft-shore-tist-prot-00.txt, May 2002. [RFC2210] J. Wroclawski, "The Use of RSVP with IETF Integrated Services", RFC 2210, September 1997. 8. Author's Addresses Marcus Brunner, Rosella Greco Network Laboratories, NEC Europe Ltd. Adenauerplatz 6 D-69115 Heidelberg Germany Phone: +49 6221 905 110 Email: [brunner|greco]@ccrle.nec.de 9. Appendix: Protocol operations in some scenarios 9.1. Signaling of service between mobile hosts The mobile scenario has to be analyzed separating two possible cases: mobile sender and mobile receiver. Mobile sender In this case, RSVPv2 tries to increase the re-use of resources and the probability to obtain a reservation while moving from one place (IP address A) to another (IP address B). Brunner, Greco Expires March 2003 12 Towards RSVP Version 2 October 2002 +----+ | MN \ Position B +----+\\ \\ \ ------- \\ /// \\\ \\ | | \| | | | Router C \\\ /// ------- -- +-----+ ---- | | ---- | | ------- --|- /|/ \\\ | --| | | +-----+ | /| | --| Recv| |/ | | | +-----+ | \|\ /// /| | ------- / +-----+ / ------- / /// \\\ / | |/ --| | -- | | --- \\\ /// -- ------- +----+ -- | MN -- Position A +----+ Figure: Mobile Scenario Referring to the above Figure, we assume that a mobile user starts a reservation from its home site (A). The reservation is set through the entire path till the destination according normal routing. The Reservation Id identifies the reservation. When the mobile sender moves to B (which can be everywhere and we are not making any assumptions on that), it tries to set a new reservation from B. This new reservation can be sent through a certain numbers of routers, which are in common with the previous reservation. The Reservation Id remains unchanged as the source moves. When a new reservation request comes in a router where a reservation with the same reservation Id already exists, the flow Id is modified to reflect the change of the sender IP address and the same resources allocated for the old reservation are reused. At the merging point (C), a message is sent back to inform the source that, from there on, the protocol tries to exploit the old reservation. (note that this is a hint). Brunner, Greco Expires March 2003 13 Towards RSVP Version 2 October 2002 Had no Reservation Id field be used by the protocol, as with RSVP version 1, then the reservation from B would have been seen as completely new because the sender has a different IP address. Mobile receiver If the mobile end-system is the receiver of the data, the following approach is possible with RSVP version 2. Let us consider the above Figure again, assuming that a receiver host located in zone A moves to zone B. The proposed solution is to use a tunnel between the home agent located in A to the foreign agent located near location B and to make a separate and independent reservation across the tunnel. When a reservation request arrives at the home agent, this agent is responsible for the creation of a new reservation to the foreign agent and for forwarding signaling and data messages along the tunnel. The creation of the tunnel may introduce additional delay to the delivery time, which means that mobile users can experience temporary disruptions of QoS. Since tunnel management is separated from end to end reservation, it is possible to make tunnel reservation in advance or in a proprietary way limiting this service disruption. 9.2. Signaling between networks with centralized management of resources In a heterogeneous network as Internet is, there can be situations where signaling should follow a different path from the one followed by data. In specific, a possible scenario is a DiffServ network where admission control and all the management of resource inside the domain is done by a centralized management system often called Bandwidth Broker (BB) or QoS Server. In this case, when a RESV message arrives at the BB, it is processed and resources are reserved in the appropriate routers according to intra-domain decisions. At this point, a notification is sent back to the ingress router to notify the result of the reservation inside the domain. The message contains information necessary to set the routing tables for the data flow or take the existing route into consideration for admission control and reservation. Benefits of this mechanism are that it allows an independent management of resources inside a domain and it separates the data from the signaling path. Brunner, Greco Expires March 2003 14