HTTP/1.1 200 OK Date: Tue, 09 Apr 2002 11:24:21 GMT Server: Apache/1.3.20 (Unix) Last-Modified: Fri, 02 Jul 1999 21:31:10 GMT ETag: "2e7021-9a41-377d2f9e" Accept-Ranges: bytes Content-Length: 39489 Connection: close Content-Type: text/plain RSVP+: An Extension to RSVP June 1999 Network Working Group Silvano Gai Internet Draft Dinesh Dutt draft-sgai-rsvp-plus-00.txt Nitsan Elfassy Expiration Date: December 1999 Cisco Systems Yoram Bernet Microsoft June 1999 RSVP+: An Extension to RSVP 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 (1998). All Rights Reserved. Gai, Dutt, Elfassy, Bernet [Page 1] RSVP+: An Extension to RSVP June 1999 Abstract RSVP has been extended in several direction [DiffEdge], [Policy], [Identity], [DCLASS], [AggrRSVP], [COPS-RSVP], [COPS-RSVP+], one of the more relevant being the addition of the support for qualitative QoS [QualSvc]. This document refers to these extensions as RSVP+ and describes variations on standard RSVP router message processing. Specific variations are driven under policy control. Variations include admission control to diffserv aggregate classes, receiver proxying, support for aggregated and tunneled RSVP and others. Table of contents 1. Introduction .....................................................3 2. An overview of RSVP+ .............................................4 3. Qualitative QoS With RSVP+ .......................................5 4. Detailed description .............................................6 4.1 Behavioral Actions Supported In RSVP+.........................8 4.1.1 Case a) ..................................................8 4.1.2 Case b) ..................................................8 4.1.3 Case c) ..................................................8 4.1.4 Case d) ..................................................8 4.1.5 Case e) ..................................................9 4.2 The role of the policy server................................10 4.3 Generation of the Resv message by the First-Hop Switch/Router10 4.4 Communication With the Policy Server.........................11 4.5 Enhancements To Existing Infrastructure To Support RSVP+.....12 4.6 Other RSVP+ messages.........................................12 5. RSVP+ Without Quantitative QoS ..................................13 6. Host Model ......................................................14 7. Security Considerations .........................................15 8. Intellectual Property Considerations ............................15 9. References ......................................................15 10. Author Information .............................................17 11. Full Copyright Statement .......................................18 Gai, Dutt, Elfassy, Bernet [Page 2] RSVP+: An Extension to RSVP June 1999 1. Introduction IETF has come up with two architectures to support QoS in IP networks. Integrated Services ([RFC1633], [RFC2210]) is an architecture that provides the ability for applications to choose among multiple, controlled levels of delivery service for their data packets. It relies upon explicit signaling by applications to the network for the desired QoS. These applications typically know their traffic characteristics and have possibly strict latency requirements. Such applications require so called "tight QoS" or "quantitative QoS". RSVP is the protocol used by applications to signal their QoS requirements to the network. Applications have to be modified to take advantage of the Integrated Services. The receivers control the QoS given to the data stream. Differentiated Services (DiffServ, [RFC2474], [RFC2475]) is another IETF architecture for implementing scalable service differentiation in the Internet. There is no explicit signaling protocol used in DiffServ. The network is logically divided into edge devices and core devices. The edge devices attempt to recognize data flows and assign QoS based on this. They also assign a DSCP (DiffServ Code Point) in the DS byte of the packets (the byte that used to be called the TOS byte). Core devices use the DSCP to assign a QoS to the microflows. Applications typically do not have to be modified to take advantage of Differentiated Services. Receivers do not control the QoS given to the data stream. However, application recognition is limited to the information present in the packet traversing the network and in most current network devices is further limited to what is in the IP/TCP/UDP headers. Application vendors desire to be able to assign QoS to their packets based on both information that may not be carried in the packet and information other than the IP/TCP/UDP header fields. For example, a SAP print transaction may require a different treatment than a SAP database update. Similarly, if the user of the application is the CTO of the company, the priority assigned to such packets maybe different from that assigned to packets of the application being used by some other person in the company. As discussed in [RSVPDIFF], there are limitations to pure diffserv networks which can be alleviated by incorporating RSVP signaling. RSVP+ is the term used to group a set of extensions to RSVP ([DiffEdge], [Policy], [Identity], [DCLASS], [AggrRSVP], [COPS-RSVP], [COPS-RSVP+], [QualSvc]) and to describe variations on standard RSVP router message processing. Specific variations are driven under policy control. Variations include admission control to diffserv Gai, Dutt, Elfassy, Bernet [Page 3] RSVP+: An Extension to RSVP June 1999 aggregate classes, receiver proxying, support for aggregated and tunneled RSVP and others. The extension defined in RSVP+ provides one method of differentiating the treatment of flows. Other well-known methods are RSVP itself, hosts marking packets with DSCP, and network based application recognition through the stateful inspection of flows. RSVP+ is designed to support an entire spectrum of applications that goes from purely quantitative QoS to purely qualitative QoS. 2. An overview of RSVP+ This section gives an overview of RSVP+, a more detailed description is given in Section 4. RSVP+, like RSVP itself, refers to unidirectional data flows. If the application data is strictly unidirectional it is sufficient to use RSVP+ only in one direction. In the case of bidirectional data, running RSVP+ only in one direction provides a certain performance benefit, but to get the maximum performance benefit it is necessary to use RSVP+ in both directions. Key characteristics of RSVP+ are: o The application on the host assumes the host model of RSVP, including the extensions proposed in [DiffEdge], [Policy], [Identity], [QualSvc]. o The message format and the message types are the same of RSVP, including the DCLASS object previously proposed in [DCLASS]. o The policy server is expected to act in charge of distinguishing between qualitative and quantitative QoS. This is determined by the policy configured by the network administrator. o The switch/router acts as a COPS client [COPS] in communicating with the policy server (i.e. uses RSVP client for COPS [COPS-RSVP], [COPS-RSVP+]). o RSVP+ add several alternative behaviors (see Section 4.1) to RSVP: o in some of them the differentiation of traffic occurs irrespective of whether an RSVP Resv message is received from the destination(s) or not; Gai, Dutt, Elfassy, Bernet [Page 4] RSVP+: An Extension to RSVP June 1999 o in some of them the Router Alert option is removed or changed from the RSVP Path message, similarly to what proposed in [AggrRSVP]. o in some of them the IP protocol identifier of RSVP is changed similarly to what proposed in [AggrRSVP]. o The classification of traffic cannot be more granular than microflow (the so called five-tuple) or in the case of IPSEC the four-tuple that includes the Parameter Index, or SPI, in place of the UDP/TCP-like ports [RFC2207]. o If a DSCP must be assigned to a microflow, this may be done by the first RSVP+ capable router or by the host which receives the DSCP through the DCLASS object [DCLASS]. o There is not special support for subflows (a set of packets inside a microflow). Of course, an application may send different Path messages for the same flow at different times, thus providing a support for subflows not overlapping in time. 3. Qualitative QoS With RSVP+ This section introduces RSVP+ through an example of a pure qualitative service. As explained later RSVP+ can cover the full spectrum from quantitative to qualitative QoS. The example assumes that the first hop router/switch proxies for the receiver under the control of a policy server. This can apply as well in the case of quantitative services. RSVP+ uses RSVP to signal the additional parameters upon which to base the decision to assign the QoS for a microflow. This is useful. for example, with applications that cannot define the bandwidth requirements they use [QualSvc]. The example assumes that the information needs to be used only by the edge network device and it is not required to propagate this further down the network (see Section 4.1 for details). A possible sequence of steps is illustrated in Figure 1.b and it consists of: o The application on H1 indicates to the RSVP subsystem that it is a sender and specifies its traffic characteristics. It may specify additional parameters. Gai, Dutt, Elfassy, Bernet [Page 5] RSVP+: An Extension to RSVP June 1999 o This causes the RSVP subsystem on H1 to start transmitting RSVP Path messages in accordance with normal RSVP/SBM rules. o The first hop switch/router (R1) receives this message and it communicates with the policy server for a decision on how to treat the Path message. It copies all the relevant information contained in the Path message to the policy server. o The policy server communicates a decision to R1 to not forward the Path message, but instead to start sending a Resv message to H1. H1 data traffic gets assigned the right DSCP by the switch/router as per the policy communicated by the policy server. The Resv message may also specifies to the host the DSCP and shaping information to be associated with the microflow using the DCLASS object. o On receiving the Resv message, H1 may start marking correctly the data traffic accordingly to the DSCP received in the Resv message [DCLASS]. 4. Detailed description This sections details the operation of RSVP+. Gai, Dutt, Elfassy, Bernet [Page 6] RSVP+: An Extension to RSVP June 1999 Path Message -----> <----- Resv Message +-----+ +-----+ | PS1 | | PS1 | +-----+ +-----+ / | \ / | / | \ / | / | \ / | +----+ +----+ +----+ +----+ +----+ +----+ +----+ | H1 |---| R1 |---| R2 |---| R3 |---| R4 |---| R5 |---| H2 | +----+ +----+ +----+ +----+ +----+ +----+ +----+ H1 ----> R1 ----> R2 ----> R3 ----> R4 ----> R5 ----> H2 | (case a) v H1 <---- R1 <---- R2 <---- R3 <---- R4 <---- R5 ----> H2 H1 ----> R1 | (case b) v H1 <---- R1 H1 ----> R1 ----------------------------------------> H2 | (case c) v H1 <---- R1 <---------------------------------------- H2 H1 ----> R1 ----------------------------------------> H2 | | (case d) v v H1 <---- R1 <---------------------------------------- H2 Hx: Host x Ry: Router y PSz: Policy Server z Figure 1: Possible Message Forwarding Behaviors in RSVP+ Gai, Dutt, Elfassy, Bernet [Page 7] RSVP+: An Extension to RSVP June 1999 4.1 Behavioral Actions Supported In RSVP+ The two fundamental messages in RSVP are the Path Message and the Resv message. It is important to define how a network device processes these two messages in the context of RSVP+. Consider Figure 1 which outlines a simple network topology with two hosts H1 & H2 and intermediate routers, R1-R5. Let's assume that all the entities, hosts and routers, implement RSVP+. There are multiple scenarios about how Path and Resv messages maybe treated by the intermediate nodes (see cases a-d in Figure 1, and e in Figure 2). 4.1.1 Case a) Case a) is the normal RSVP processing where the Path message goes hop-by-hop from H1 to H2. The Resv message uses the reverse path of the Path message and goes from H2 to H1. 4.1.2 Case b) Case b) is the simpler behavior and it has already been presented in Section 3. The host uses RSVP Path to signal the additional parameters to the first hop switch/router R1. R1 does not propagate the Path message further, but terminate it and also send a Resv message back. 4.1.3 Case c) In case c), the edge router R1 forwards the Path message, but it strips out the router alert option. This makes the following routers not see the Path message, but the destination host H2 receives the Path message as in the normal RSVP behavior. When H2 sends the Resv message, it also skips the intermediate routers and gets straight to R1. R1 contacts the policy server and propagates the Resv message to H1 adding the information about the QoS provided by the policy server. 4.1.4 Case d) Case d) is similar to c) except that R1 originates a Resv message toward H1. This behavior is important, for example when some of the possible destination support RSVP and some not. In this situation there is no guarantee that the destination generates the Resv message. If the Resv message is generated, it is received by R1 and passed to the policy server. The policy server may decide to modify the Resv message generated by R1 toward H1. Case d) has also a lower latency than case c). Gai, Dutt, Elfassy, Bernet [Page 8] RSVP+: An Extension to RSVP June 1999 Path Message -----> <----- Resv Message +-----+ +-----+ | PS1 | | PS1 | +-----+ +-----+ ******/***|*** \** ***/***|********* *** / | \ *** *** / | *** ** / | \ ** ** / | *** +----+ * +----+ +----+ +----+* * +----+ +----+ +----+ * | H1 |---| R1 |---| R2 |---| R3 |----| R4 |---| R5 |---| H2 | * +----+ * +----+ +----+ +----+* * +----+ +----+ +----+ * ** ** ** *** *** Domain A *** *** Domain B *** ****************** ***************** H1 ----> R1 -------------> R3 ----> R4 -----> R5 ----> H2 | (case e) v H1 <---- R1 <------------- R3 <---- R4 <----- R5 ----> H2 Hx: Host x Ry: Router y PSz: Policy Server z Figure 2: Another Possible Message Forwarding Behavior in RSVP+ 4.1.5 Case e) Case e) (see Figure 3) is the most complex one and is similar to what proposed in [AggrRSVP] and in [DiffEdge]. Let's suppose that routers R1, R2 and R3 belong to QoS policy domain A and that R4 and R5 belong to QoS policy domain B. Let's also suppose that DiffServ is used in the two domains. The host H1 sends the Path message, R1 process it and it changes the IP protocol number (let's call it "tunnel"), R2 receives the message (the router alert option is still present), but it does not process it, since it is not a DiffServ Edge router [DiffEdge]. It forwards the Path message to R3 that receives and processes it, changing the protocol type to the normal RSVP protocol type. R4 changes the protocol type back to tunnel and R5 back to normal RSVP. Gai, Dutt, Elfassy, Bernet [Page 9] RSVP+: An Extension to RSVP June 1999 4.2 The role of the policy server Which of these scenarios is to be enacted for a specific Path message is decided by the policy server [COPS-RSVP+]. The policy server can specify a set of possible forwarding decisions which is extended compared to COPS-RSVP [COPS-RSVP]. If the decision is to accept the Path message, the decision message must specify how the network device behaves with respect to each of the following: o Forwarding of the Path message; o Originating a RSVP Resv message; o Processing a RSVP Resv message for this Path, if received from some end host (for example let the PDP/LPDP decide what to do with the information in the In Resv and whether or not to modify the already installed Out Resv accordingly). The decision may also possibly include the QoS specification to be associated with the flow identified in the Path message. This specification consists of a DSCP and possibly a TSPEC (as specified by RSVP [RFC2210]) for policing the traffic. The network device is in charge of admission control. 4.3 Generation of the Resv message by the First-Hop Switch/Router It maybe required that the network device originate a Resv message. This is a proxy Resv message in the sense that it is being generated by the network device and not by the actual receiver(s) identified in the RSVP Path message. The format of a Resv message is as follows (see [RFC2205] for details): ::= [ ] [ ] [ ] [ ... ]