Network Working Group Silvano Gai Internet Draft Dinesh G Dutt draft-ietf-rsvp-proxy-00.txt Nitsan Elfassy Expiration Date: August 2000 Cisco Systems Yoram Bernet Microsoft February 2000 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 February 2000 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 both inside and 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. If COPS is used for policy control, an extension to the COPS for RSVP protocol [COPS-RSVP-EXT] is also required. 1. Introduction Network administrators and application developers would like to have the QoS provided to a packet be based on information such as: o the type of application a packet belongs to o a specific transaction within the application that a packet belongs to o the user running the application that a packet belongs to. In turn, the machine hosting the applications would like to know some information about the QoS being provided to the applications. This could include information such as the DSCP assigned to the packets belonging to an application. The host machine could then use this information to mark the packets appropriately. Since the data packets themselves may not carry information such as application or user id, an alternative approach is to therefore signal this information separately. RSVP [RFC2205] is a well established, standard IETF protocol that is used by applications to signal their QoS requirements to the network and obtain feedback about the network's ability to provide the requested QoS. An existing draft [RSVP-APPID] defines the objects that can be used to carry the application id/sub-id and user-id in an RSVP message. Also, ISSLL has defined a new service type called Null Service Type [NullServ] for use within the IntServ framework. This service is intended for applications whose QoS requirements are better left to the discretion of the network administrators. As a result of these characteristics, RSVP emerges as a good choice as a signaling protocol to carry information such as, application id/sub-id and/or, user id. Gai, Dutt, Elfassy, Bernet [Page 2] RSVP Receiver Proxy February 2000 RSVP as currently defined travels end-to-end i.e. from the sender to the receiver and back. For the applications discussed above, this end-to-end nature of RSVP is not necessarily an useful feature. For example, the latency incurred in the Resv message returning to the sender might constitute a disadvantage. Or it might be that the application has been modified only on the sender side and so there is no use in forwarding this message to the receiver since it might not support RSVP. RSVP Receiver Proxy is proposed to address such concerns. 2. An overview of RSVP Receiver Proxy RSVP Receiver Proxy is a functionality provided by a network device, such as a switch or a router, in which the network device generates a proxy Resv message in response to an incoming Path message, on behalf of the receiver identified by the Path message. The generation of the Resv message is done under policy control. Policy control can either be performed using local policy or by a policy server via a protocol such as COPS for RSVP [COPS-RSVP]. The network device can be configured to classify the packets and mark them with an appropriate DSCP. This marking decision can also be communicated to the sender of the Path message via a DCLASS [DCLASS] object carried in the proxy Resv message. RSVP Receiver Proxy does not change the RSVP protocol. Only a modification in the processing of the RSVP messages is required. This document defines RSVP Receiver Proxy in association with the Null Service Type, but there do not appear to be any obvious problems in using this feature in association with other service types such as the Controlled Load service. For example, PacketCable [DQOS] uses RSVP Receiver Proxy to do admission control for voice in cable networks. RSVP Receiver Proxy does not provide any 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. RSVP Receiver Proxy: An Example This section illustrates the RSVP Receiver Proxy functionality provided by a network device. The description is focussed mainly on the two fundamental messages in RSVP, i.e. the Path Message and the Resv message. Other messages are discussed in Section 3.3. Figure 1 depicts a simple network topology (two hosts H1 & H2 and intermediate routers, R1-R4) that is used in the description that follows. Gai, Dutt, Elfassy, Bernet [Page 3] RSVP Receiver Proxy February 2000 Path Message -----> <----- Resv Message +-----+ +-----+ | PS1 | +--| PS1 | +-----+ / +-----+ / | / / / | / / / | / / +----+ +----+ +----+ +----+ +----+ +----+ | H1 |---| R1 |---| R2 |---| R3 |---| R4 |---| H2 | +----+ +----+ +----+ +----+ +----+ +----+ H1 ----> R1 ----> R2 ----> R3 ----> R4 ----> H2 Case A: Normal | RSVP Processing v H1 <---- R1 <---- R2 <---- R3 <---- R4 ----> H2 H1 ----> R1 | Case B: RSVP Receiver Proxy v H1 <---- R1 Hx: Host x Ry: Router y PSz: Policy Server z Figure 1: Possible Message Forwarding Behaviors in RSVP In figure 1 above, case A illustrates the normal RSVP message processing. The Path message goes hop-by-hop from H1 to H2. The Resv message uses the reverse of the path setup by the Path message and goes from H2 to H1. The interaction between the network devices and the policy servers is as specified by COPS for RSVP ([COPS], [COPS-RSVP]). With RSVP Receiver Proxy (case B) the RSVP Path message is terminated by the router R1 acting as a proxy for H2 under the control of a policy server (local policy at R1 could also have been used to achieve the same result). A possible sequence of steps that occurs is as follows: o An application on H1 indicates to the RSVP subsystem that it is a sender wishing to use RSVP. It might specify additional parameters such as traffic characteristics and application specific information. Gai, Dutt, Elfassy, Bernet [Page 4] RSVP Receiver Proxy February 2000 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 network device (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 in the request sent to the policy server. o The policy server communicates a decision to R1 to not forward the Path message, but instead to generate and send a Resv message to H1. H1 data traffic can be marked with the right DSCP by the network device if specified by the policy server. The policy server could also specify the list of objects that need to be sent in the Resv message. o On receiving the Resv message, H1 might decide to mark the packets of the traffic flow signaled, according to the DSCP specified in the DCLASS object contained in the Resv. In the example, the Receiver Proxy functionality was placed in the network device that was the first hop from the sender of the Path message. This is a possibility, but it is not a requirement. While designing a network, the following trade-offs should be considered: o Proxying closer to the sender of the Path message reduces turn around time. o Proxying farther from the sender of the Path message enables additional downstream network elements to benefit from the information carried in the signaling messages, and to participate in the response. The network administrator can decide how to make these trade-offs via policy control. 3.1 Generation of the Resv message by the Proxy The format of a Resv message generated by the proxy network device is as follows (see [RFC2205] for details): ::= [ ] [] [] [...]