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

                                                           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 The list of
   Internet-Draft Shadow Directories can be accessed at

   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

   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

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

   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

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

   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

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
     H1 <---- R1 <---- R2 <---- R3 <---- R4 ----> H2

      H1 ----> R1
                |                       Case B: RSVP Receiver Proxy
      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],

   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

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

   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):

   <Resv Message> ::= <Common Header> [ <INTEGRITY> ]
                       <SESSION> <RSVP HOP> <TIME_VALUES><DCLASS>
                       [<RESV_CONFIRM>] [<SCOPE>] [<POLICY_DATA>...]
                       <STYLE> <flow descriptor list>

   o The network device SHOULD put its IP address and L2 address in the
     source IP and source mac-address fields. Since Resv messages follow
     Path messages, this would constitute a valid Resv message.

   o The SESSION object SHOULD be copied from the Path message.

   o The RSVP HOP object MUST be filled in with the IP address of the
     network device generating this Resv message.

Gai, Dutt, Elfassy, Bernet                                      [Page 5]

RSVP Receiver Proxy                                        February 2000

   o The TIME_VALUES object contains the refresh period.

   o The STYLE object MUST be set to what is specified by the policy
     control. If policy control does not specify this object, Wildcard
     Filter (WF) style indicating that the reservation is to be shared and
     that the sender is wildcarded is chosen as the default. Associated
     with a WF style is a FLOWSPEC object which is encoded as specified
     in [RFC2210] or [NullServ].

   o The POLICY_DATA objects as specified by policy control MUST be
     included in the generated Resv message.

   o If policy control specifies a DCLASS object as part of the
     replacement object to be sent in the Resv message, the DCLASS
     object MUST be included in the generated Resv message.

   o Refresh Resv messages MUST be generated periodically in keeping
     with the soft state of RSVP.

3.2 Enhancements To Existing Infrastructure

   o COPS for RSVP has to be enhanced to support the new functionality
     specified by this document. A proposal for this is presented in

   o When SBM is in use, it is possible that a device which does not
     support RSVP Receiver Proxy becomes the DSBM on the first-hop
     segment which results in loss of the Receiver Proxy
     functionality. This can be prevented by configuring the appropriate
     priority on the device with RSVP Receiver Proxy support.

3.3 Processing of other RSVP messages

   This section details the processing of the protocol messages in RSVP
   other than Path and Resv. Only the differences in the processing from
   classical RSVP is specified.

   o PathTear message is honored and its forwarding behavior is similar
     to a Path message. If a policy server is used for policy control,
     the policy server need not be contacted on receiving a PathTear
     message. This is consistent with the existing behavior of COPS for

   o PathErr messages are treated as in normal RSVP.

Gai, Dutt, Elfassy, Bernet                                      [Page 6]

RSVP Receiver Proxy                                        February 2000

4. RSVP Path 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.

5. Security Considerations

   RSVP messages contain an INTEGRITY object which authenticates the
   originating node and is also used to verify the contents of the
   message. Moreover the RSVP message SHOULD contain an IDENTITY object
   that SHOULD be authenticated. If the policy server does not implement
   any security mechanisms, it SHOULD use a clear text version of the
   user identity.

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

   [COPS] Boyle, J., Cohen, R., Durham, D., Herzog, S., Raja, R.,
          Sastry, A., "The COPS (Common Open Policy Service) Protocol,
          RFC 2748, January 2000.

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

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

   [RFC2210] J. Wroclawski, "The Use of RSVP with IETF Integrated
             Services," September 1997.

Gai, Dutt, Elfassy, Bernet                                      [Page 7]

RSVP Receiver Proxy                                        February 2000

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

   [RFC2475] S. Blake, D. Black, M. Carlson, E. Davies, Z. Wang,
             W. Weiss, "An Architecture for Differentiated Service," RFC
             2475, December 1998.

   [COPS-RSVP] Jim Boyle, Ron Cohen, David Durham, Shai Herzog, Raju
               Rajan, Arun Sastry, "COPS usage for RSVP," RFC 2749,
               January 2000

   [COPS-RSVP-EXT] Dinesh Dutt, Nitsan Elfassy, "COPS Extensions for
                   RSVP Receiver Proxy Support","
                   <draft-nitsan-cops-rsvp-proxy-01.txt>, February 2000.

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

   [DiffModel] Y. Bernet, A. Smith, S. Blake, "A Conceptual Model for
               Diffserv Routers," Internet Draft,
               <draft-ietf-diffserv-model-00.txt>,  June 1999.

   [Identity] Satyendra Yadav, Raj Yavatkar, Ramesh Pabbati, Peter Ford,
              Tim Moore, Shai Herzog, "Identity Representation for
              RSVP," RFC 2752, January 2000.

   [AggrRSVP] Fred Baker, Carol Iturralde, Francois Le Faucheur, Bruce
              Davie, "Aggregation of RSVP for IP4 and IP6 Reservations,"
              <draft-ietf-issll-rsvp-aggr-00.txt>, September 1999.

   [DCLASS] Bernet, Y., "Usage and Format of the DCLASS Object With RSVP
            Signaling," <draft-ietf-issll-dclass-00.txt >, August 1999.

   [NullServ] Yoram Bernet, Andrew Smith, B. Davie, "Specification of
              the Null Service Type,"
              <draft-ietf-issll-nullservice-00.txt>, September 1999.

   [RSVPDIFF] Bernet, R. Yavatkar, P. Ford, F. Baker, L. Zhang,
              M. Sheer, B. Braden, B. Davie, J. Wroclawski,
              E. Felstaine, "Integrated Services Operation Over Diffserv
              Networks," <draft-ietf-issll-diffserv-rsvp-03.txt>,
              September 1999

   [DQOS] PacketCable Dynamic Quality Of Service Specification,
          Interim Version,

Gai, Dutt, Elfassy, Bernet                                      [Page 8]

RSVP Receiver Proxy                                        February 2000

8. Author Information

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

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

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

Yoram Bernet
One Microsoft Way,
Redmond, WA 98052
Phone: (425) 936-9568

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.

Gai, Dutt, Elfassy, Bernet                                      [Page 9]

RSVP Receiver Proxy                                        February 2000
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

Gai, Dutt, Elfassy, Bernet                                     [Page 10]