Network Working Group                                        Silvano Gai
Internet Draft                                             Dinesh G Dutt
draft-ietf-rsvp-proxy-03.txt                              Nitsan Elfassy
Expiration Date: September 2002                        Cisco Systems Inc.
                                                            Yoram Bernet
                                                               Microsoft

                                                              March 2002


                               RSVP 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 Proxy                                                    March 2002

Abstract

   RSVP has been extended in several directions [POLICY], [RSVP-APPID],
   [DCLASS], [AGGRRSVP], [RSVPDIFF]. These extensions have broadened the
   applicability of RSVP characterizing it as a signaling protocol
   usable both inside and outside the Integrated Services [INTSERV]
   model.

   With the addition of the "Null Service Type" [NULLSERV], RSVP is
   also being adopted by mission critical applications that require some
   form of prioritized service, but cannot quantify their resource
   requirements. In cases where RSVP cannot travel end-to-end, these
   applications may still benefit from reservations that are not truly
   end-to-end, but that are 'proxied' by a network node on the data path
   between the sender and the receiver(s).

   RSVP Receiver Proxy is an extension to the RSVP message processing
   (not to the protocol itself) in which an intermediate network node
   originates the Resv message on behalf of the receiver(s) identified
   by the Path message.

   RSVP Sender Proxy involves generating a Path message based on some
   match criteria at a router. For example, a packet filter can be
   installed at a router and the action associated with a match in the
   filter could be to generate a Path message.

1. Introduction

   Network administrators and application developers would sometimes
   like to provide QoS to a flow based on information such as:

   o the type of application to which the flow belongs
   o a specific transaction within an application to which the flow
     belongs
   o the user running the application to which the flow belongs

   Typically, such flows belong to applications that cannot quantify
   their traffic characteristics.

   Since the data packets themselves do not usually carry information
   such as application or user id, an alternative approach is to 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 RFC [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.

Gai, Dutt, Elfassy, Bernet                                      [Page 2]


RSVP Proxy                                                    March 2002

   However, 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 always applicable. For
   example, it might be that the application has been modified only on
   the sender side to support RSVP; there is no use in forwarding this
   message to the receiver since it does not support RSVP. Another
   example is where RSVP is used only within an administrative domain
   and a provisioned core is used outside of this domain. In such
   situations, RSVP is beneficial only within the administrative domain
   it has been enabled in. An example of this situation is QoS in
   PacketCable[DQOS], where resource reservations are used only within
   the access portion of the network and the core of the network is
   provisioned.

   RSVP Receiver Proxy is proposed to address such situations.

2. 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 originates
   the Resv message in response to an incoming Path message, on behalf
   of the receiver(s) identified by the Path message.

   The generation of the Resv message is done under policy control.
   Policy control can be performed using policy that has either been
   locally specified or specified by a policy server via a protocol such
   as COPS for RSVP [COPS-RSVP].

   The proxy functionality does not imply merely generating a single
   Resv message. Proxying the Resv involves installing state in the node
   doing the proxy i.e. the proxying node should act as if it had
   received a Resv from the true endpoint. This involves reserving
   resources (if required), sending periodic refreshes of the Resv
   message and tearing down the reservation if the Path is torn down.

   Optionally, the network device can also be configured to classify the
   packets and mark them with an appropriate DSCP. The codepoint used to
   mark these packets can also be communicated to the sender of the Path
   message via the DCLASS[DCLASS] object carried in the proxy Resv
   message.

   RSVP Receiver Proxy does not change the "on-the-wire" RSVP protocol.
   It entails only a modification in the processing of the RSVP
   messages.

   RSVP Receiver Proxy can be used with all the service types -
   Controlled Load [CLSVC], Guaranteed Service[GUSVC] and Null Service -
   defined by Integrated Services.

2.1 Processing of other RSVP messages

   Apart from proxying the Resv message, the proxying node must also be

Gai, Dutt, Elfassy, Bernet                                      [Page 3]


RSVP Proxy                                                    March 2002

   modified to handle differently the following RSVP messages:

   o PathTear message is honored and its forwarding behavior is similar
     to a Path message. However, in addition to tearing down the Path
     state, the node must also send a ResvTear and tear down the
     reservation state.

   o PathErr messages are treated as in normal RSVP. Just as in the case
     of PathTear, if a Resv is being proxied, the PathErr should also
     result in the tear down of the reservation state.

   Processing of other RSVP messages is similar to existing behavior as
   defined in [RFC2205].

2.2 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.

   Figure 1 depicts a simple network topology consisting of two hosts H1
   and H2 and four intermediate routers, R1-R4.

                        Path Message ----->
                        <----- Resv Message

    +----+   +----+   +----+   +----+   +----+   +----+
    | 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

   Figure 1: Possible Message Forwarding Behaviors in RSVP

   In Figure 1, case A illustrates the normal RSVP message processing.
   The Path message is generated by H1, is destined to H2, and it gets
   to H2 from H1 via R1, R2, R3 and R4. The Resv message uses the

Gai, Dutt, Elfassy, Bernet                                      [Page 4]


RSVP Proxy                                                    March 2002

   reverse of the path setup by the Path message and goes hop-by-hop
   from H2 to H1.

   With RSVP Receiver Proxy (case B) the RSVP Path message is terminated
   by the router R1 acting as a proxy for H2.

   A possible sequence of steps is:

   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.

   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 applies
     policy control to decide how to process this message.

   o The policy specifies a decision to not forward the Path message,
     but instead to proxy a Resv on behalf of H2. Additionally, the
     policy could specify the list of objects that need to be sent in
     the Resv message. One such additional object is the DCLASS
     object. Further, the policy could specify a DSCP that the
     network device (R1) must mark the flow identified by the Path
     message.

   o On receiving the Resv message, if the DCLASS object is specified
     the message, H1 can mark the packets of the traffic flow signaled,
     according to the DSCP specified in the DCLASS object.

3. RSVP Sender Proxy

   Just as a network device can proxy a Resv message on behalf of a
   receiver, it can also be made to proxy a Path message on behalf of a
   sender. However the trigger that determines when a network device
   must generate a proxy Path message is potentially outside the RSVP
   subsystem. One mechanism for example, would be to install filter
   entries in the network device such that if an incoming flow matched
   one of the filters, the device would start generating a proxy Path
   message. At this point, it could potentially contact a policy server
   or use local policy in determining the behavior and contents of the
   proxy Path message.

   The device generating the Path message must correctly terminate the
   Resv, ResvTear and PathErr messages.

4. Where To Proxy

   In the example described in section 3, the Receiver Proxy
   functionality was placed in the network device that was the first hop

Gai, Dutt, Elfassy, Bernet                                      [Page 5]


RSVP Proxy                                                    March 2002

   from the sender of the Path message. This is one possibility, not
   a requirement. While designing a network, the following trade-offs
   should be considered:

   o In case of Receiver Proxy, 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. For example, if some receivers are
     located off low-bandwidth links and other receivers off
     high-bandwidth links, the QoS to be applied could be different for
     the different receivers.

   o The proxying might be done at the boundary of an access network and
     a core network as in the case of PacketCable.

   o In case of Receiver Proxy, proxying closer to the sender results in
     a lower the latency experienced by the sender between the
     generation of the Path message and the receipt of the Resv
     message. This lower latency might be desirable to some
     applications.

   The network administrator must take into account such factors in
   deciding where to place the proxy.

5. Security Considerations

   The security considerations related to proxying are similar to those
   raised with respect to RSVP (section 2.8 in [RFC2205]). Specifically,
   the main concern in using a proxy is to ensure that unauthorized
   nodes do not mount a denial of service attack or cause theft of
   service by generating proxy RSVP messages on behalf of either a
   receiver or a sender. The problem is addressed via router to router
   authentication and using the INTEGRITY object [RFC 2747] in RSVP
   messages. Security policy enforcement can further prevent such attacks.

6. Intellectual Property Considerations

   The IETF is being notified of intellectual property rights claimed in
   regard to some or all of the specification contained in this document.
   For more information consult the online list of claimed rights.

7. References

   [INTSERV]   R. Braden, D. Clark, S. Shenker, "Integrated Services in
               the Internet Architecture: an Overview," June 1994.

   [RFC2205]   R. Braden, L. Zhang, S. Berson, S. Herzog, S. Jamin,
               "Resource Reservation Protocol (RSVP) Version 1
               Functional Specification", RFC 2205, September 1997.

Gai, Dutt, Elfassy, Bernet                                      [Page 6]


RSVP Proxy                                                    March 2002

   [DIFFSERV]  K. Nichols, S. Blake, F. Baker, D. Black, "Definition of
               the Differentiated Services Field (DS Field) in the IPv4
               and IPv6 Headers," RFC 2474, December 1998.

   [CLSVC]     J. Wroclawski, "Specification of the Controlled-Load
               Network Element Service," RFC 2211, September 1997.

   [GUSVC]     S. Shenker, C. Partridge, R. Guerin, "Specification of
               Guaranteed Quality of Service," RFC 2212, September 1997.

   [COPS-RSVP] J. Boyle, R. Cohen, D. Durham, S. Herzog, R. Rajan,
               A. Sastry,  "COPS usage for RSVP," RFC 2749,
               January 2000.

   [POLICY]    Shai Herzog, "RSVP Extensions for Policy Control,"
               RFC 2750, January 2000.

   [RSVPDIFF]  Y. Bernet, R. Yavatkar, et. al., "A Framework For
               Integrated Services Operation Over Diffserv Networks, "
               RFC 2998, November 2000.

   [RSVP-APPID] Y. Bernet, R. Pabbati, "Application and Sub Application
                Identity Policy Element for Use with RSVP," RFC 2872,
                June 2000.

   [AGGRRSVP]  F. Baker, C. Iturralde, F. Le Faucheur, B. Davie,
               "Aggregation of RSVP for IP4 and IP6 Reservations,"
               RFC 3175, September 2001.

   [DCLASS]    Y. Bernet, "Format of the RSVP DCLASS Object",
               RFC 2996, November 2000.

   [NULLSERV]  Y. Bernet, A. Smith, B. Davie, "Specification of the Null
               Service Type," RFC 2997, November 2000.

   [DQOS]      PacketCable Dynamic Quality Of Service Specification,
               Interim Version,
               http://www.packetcable.com/specs/pkt-sp-dqos-I01-991201.pdf.

   [RFC2747]   F. Baker, B. Lindell, M.Talwar, "RSVP Cryptographic
               Authentication", RFC 2747, January 2000.

8. Author Information

Silvano Gai
Cisco Systems, Inc.
170 Tasman Dr.
San Jose, CA 95134-1706
Phone: (408) 527-2690
email: sgai@cisco.com


Gai, Dutt, Elfassy, Bernet                                      [Page 7]


RSVP Proxy                                                    March 2002

Dinesh G Dutt
Cisco Systems, Inc.
170 Tasman Dr.
San Jose, CA 95134-1706
Phone: (408) 527-0955
email: ddutt@cisco.com

Nitsan Elfassy
Cisco Systems, Inc.
Cisco Systems, Inc.
170 Tasman Dr.
San Jose, CA 95134-1706
Phone: +972 9 970 0066
email: nitsan@cisco.com

Yoram Bernet
Microsoft
One Microsoft Way,
Redmond, WA 98052
Phone: (425) 936-9568
Email: yoramb@microsoft.com

9. Full Copyright Statement

Copyright (C) The Internet Society (1997). All Rights Reserved.

This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it or
assist in its implementation may be prepared, copied, published and
distributed, in whole or in part, without restriction of any kind,
provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing the
copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of developing
Internet standards in which case the procedures for copyrights defined

in the Internet Standards process must be followed, or as required to
translate it into languages other than English.

The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.

This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT
NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL
NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR
FITNESS FOR A PARTICULAR PURPOSE.

Gai, Dutt, Elfassy, Bernet                                      [Page 8]