RSVP Receiver Proxy October 1999 Network Working Group Silvano Gai Internet Draft Dinesh Dutt draft-sgai-rsvp-proxy-00.txt Nitsan Elfassy Expiration Date: April 2000 Cisco Systems Yoram Bernet Microsoft October 1999 RSVP Receiver Proxy 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 Receiver Proxy October 1999 Abstract RSVP has been extended in several directions [Policy], [Identity], [DCLASS], [AggrRSVP], [DiffModel],[COPS-RSVP], These extensions have broadened the applicability of RSVP characterizing it as a signaling protocol usable outside the IntServ model. With the addition of the "Null Service Type" [NullServ], RSVP is being adopted also by mission critical applications that require some form of prioritized service, but cannot readily specify their resource requirements. These applications do not need to set-up a reservation end-to-end, but only to signal to the network their policy information [Policy], [Identity] and obtain in response an applicable DSCP [DCLASS]. RSVP Receiver Proxy is an extension to the RSVP message processing (not to the protocol itself), mainly designed to operate in conjunction with the Null Service Type and with an extension of the COPS for RSVP protocol [COPS-RSVP-EXT]. Table of contents 1. Introduction .....................................................3 2. An overview of RSVP Receiver Proxy ...............................5 3. Detailed description of the message processing ...................6 4. The role of the policy server ....................................8 4.1 Generation of the Resv message by the Receiver Proxy..........8 4.2 Communication With the Policy Server..........................9 4.3 Enhancements To Existing Infrastructure......................10 4.4 Processing of other RSVP messages............................10 5. RSVP With Null Service Type .....................................11 6. Security Considerations .........................................11 7. Intellectual Property Considerations ............................11 8. References ......................................................12 9. Author Information ..............................................14 10. Full Copyright Statement .......................................15 Gai, Dutt, Elfassy, Bernet [Page 2] RSVP Receiver Proxy October 1999 1. Introduction The IETF has come up with two architectures to support QoS in IP networks. IntServ (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 which can be 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. DiffServ (Differentiated Services, [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. The recognition of data flows and the assignment of an appropriate DSCP is a tricky task and often requires stateful inspection of flows and symmetrical routing paths. Moreover, 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. For this reason RSVP has been proposed also for mission critical applications (e.g. ERP) that require some form of prioritized service, but cannot readily specify their resource requirements. The ISSLL WG is discussing the specification of the Null Service Type as a way to use RSVP with a broader range of applications [NullServ]. Gai, Dutt, Elfassy, Bernet [Page 3] RSVP Receiver Proxy October 1999 Some of these applications have the requirement for the end-to-end message processing of RSVP. Others simply need to signal to the network their identity [Identity] and some additional policy information [Policy] related to the flows and obtaining from the network some decisions, e.g. the DSCP to be used [DCLASS]. RSVP Receiver Proxy is a proposal that mainly addresses this second type of applications, i.e., applications that simply want to use RSVP as a signaling protocol toward the network. For them, the end-to-end nature of RSVP is not interesting and often is perceived as a disadvantage, since it is characterized by a higher latency. The RSVP Receiver Proxy: o is an alternate way to process RSVP messages and policy information in the switch/routers; o it does not require any change to the RSVP protocol; o it does require an extension to the COPS for RSVP protocol [COPS- RSVP-EXT]. In general, "RSVP Proxy" should be symmetric, i.e., it may be useful to have RSVP Sender Proxy as well as RSVP Receiver Proxy. This document does not define RSVP Sender Proxy at this stage. If the document is accepted by the IETF community, the RSVP Sender Proxy can be added in the next version. This document defines RSVP Receiver Proxy in association with the Null Service Type, but nothing prevents using this feature also in association with other service types, e.g. the Controlled Load service. The following section uses an example in which the Receiver Proxy functionality is placed in the first hop switch/router. This is a possibility, but it is not a requirement. While designing a network the following trade-off should be considered: o Proxying closer to the server reduces turn around time. o Proxying further from the server enables additional downstream network elements to benefit from the information carried in the signaling messages, and to participate in the response. o Proxying anywhere in the network enables the deployment of such applications in which only the server is required to signal, but Gai, Dutt, Elfassy, Bernet [Page 4] RSVP Receiver Proxy October 1999 the client may remain unchanged. The COPS-RSVP Extension [COPS-RSVP-EXT] should enable the network administrator to decide how to make the tradeoffs described above. 2. An overview of RSVP Receiver Proxy With RSVP Receiver Proxy a switch/router acts as a proxy for the receiver, e.g. when it receives an RSVP Path message, it generates an RSVP Resv message on behalf of the receiver. The generation of the Resv message is done under policy control, the switch/router may be programmed either to classify the packets marking them with an appropriate DSCP or to use the DCLASS object [DCLASS] to communicate the classification decision to the host. The adoption of RSVP Receiver Proxy do not change the basic model of RSVP, i.e.: o the handling of data flows is unidirectional. 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. o The application on the host assumes the host model of RSVP, including the extensions proposed in [DiffModel], [Policy], [Identity], [NullServ]. o The message format and the message types are the same of RSVP, including the DCLASS object previously proposed in [DCLASS] and the Null Service Type [NullServ]. o The switch/router acts as a COPS client [COPS] in communicating with the policy server, i.e. it uses RSVP client for COPS [COPS- RSVP]. Certain extensions to COPS for RSVP are needed [COPS-RSVP- EXT], see Section 4. 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 There is no special support for subflows (a set of packets inside a microflow). Of course, an application may send different Path Gai, Dutt, Elfassy, Bernet [Page 5] RSVP Receiver Proxy October 1999 messages for the same flow at different times, thus providing a support for subflows not overlapping in time. 3. Detailed description of the message processing This sections details some of the message processing of a switch/router acting as RSVP Receiver Proxy. The description is mainly focused on the two fundamental messages in RSVP, i.e. the Path Message and the Resv message. Other messages are discussed in Section 4.4. Figure 1 depicts a simple network topology (two hosts H1 & H2 and intermediate routers, R1-R5) that will be used in the explanation. Path Message -----> <----- Resv Message +-----+ +-----+ | PS1 | | PS1 | +-----+ +-----+ / | \ / | / | \ / | / | \ / | +----+ +----+ +----+ +----+ +----+ +----+ +----+ | H1 |---| R1 |---| R2 |---| R3 |---| R4 |---| R5 |---| H2 | +----+ +----+ +----+ +----+ +----+ +----+ +----+ H1 ----> R1 ----> R2 ----> R3 ----> R4 ----> R5 ----> H2 (Regular | RSVP v case) H1 <---- R1 <---- R2 <---- R3 <---- R4 <---- R5 ----> H2 H1 ----> R1 | (RSVP Receiver Proxy) v H1 <---- R1 Hx: Host x Ry: Router y PSz: Policy Server z Figure 1: Possible Message Forwarding Behaviors in RSVP Gai, Dutt, Elfassy, Bernet [Page 6] RSVP Receiver Proxy October 1999 Immediately below the network, the normal RSVP message processing is reported. 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. The interaction between the network devices and the policy servers is the one specified by COPS for RSVP ([COPS], [COPS-RSVP]). With RSVP Receiver Proxy the propagation of the RSVP Path message is terminated in the router acting as a proxy. Any router in the network may act as RSVP Receiver Proxy, but it is a good design guideline to place the proxy functionality as close as possible to the sender. In our case R1 acts as a proxy for H2 under the control of a policy server. For example, an application on H1 uses RSVP to signal parameters upon which to base the decision to assign the QoS for a microflow. 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 A possible sequence of steps 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. 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 originate and send 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 specify to the host the DSCP and shaping information to be associated with the microflow using the DCLASS object [DCLASS]. o On receiving the Resv message, H1 may start marking correctly the data traffic accordingly to the DSCP received in the Resv message. Gai, Dutt, Elfassy, Bernet [Page 7] RSVP Receiver Proxy October 1999 4. The role of the policy server To implement both RSVP and RSVP Receiver Proxy the policy server needs to specify a set of decisions [COPS-RSVP-EXT] 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 and possibly Forwarding a RSVP Resv message. 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. 4.1 Generation of the Resv message by the Receiver Proxy 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): ::= [ ] [ ] [ ] [ ... ]