


TSVWG                                                     F. Le Faucheur
Internet-Draft                                                     Cisco
Updates: 2205 (if approved)                                    J. Manner
Intended status: Standards Track                                     TKK
Expires: September 9, 2010                                  A. Narayanan
                                                                   Cisco
                                                              A. Guillou
                                                                    Neuf
                                                                H. Malik
                                                                  Bharti
                                                           March 8, 2010


         RSVP Extensions for Path-Triggered RSVP Receiver Proxy
                draft-ietf-tsvwg-rsvp-proxy-proto-11.txt

Abstract

   RSVP signaling can be used to make end-to-end resource reservations
   in an IP network in order to guarantee the QoS required by certain
   flows.  With conventional RSVP, both the data sender and receiver of
   a given flow take part in RSVP signaling.  Yet, there are many use
   cases where resource reservation is required, but the receiver, the
   sender, or both, is not RSVP-capable.  Where the receiver is not
   RSVP-capable, an RSVP router may behave as an RSVP Receiver Proxy
   thereby performing RSVP signaling on behalf of the receiver.  This
   allows resource reservations to be established on the segment of the
   end-to-end path from the sender to the RSVP Receiver Proxy.  However,
   as discussed in the companion document presenting RSVP Proxy
   approaches, RSVP extensions are needed to facilitate operations with
   an RSVP Receiver Proxy whose signaling is triggered by receipt of
   RSVP Path messages from the sender.  This document specifies these
   extensions.

Status of this Memo

   This Internet-Draft is submitted to IETF in full conformance with the
   provisions of BCP 78 and BCP 79.

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



Le Faucheur, et al.     Expires September 9, 2010               [Page 1]

Internet-Draft       RSVP Receiver Proxy Extensions           March 2010


   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.

   This Internet-Draft will expire on September 9, 2010.

Copyright Notice

   Copyright (c) 2010 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the BSD License.

   This document may contain material from IETF Documents or IETF
   Contributions published or made publicly available before November
   10, 2008.  The person(s) controlling the copyright in some of this
   material may not have granted the IETF Trust the right to allow
   modifications of such material outside the IETF Standards Process.
   Without obtaining an adequate license from the person(s) controlling
   the copyright in such materials, this document may not be modified
   outside the IETF Standards Process, and derivative works of it may
   not be created outside the IETF Standards Process, except to format
   it for publication as an RFC or to translate it into languages other
   than English.

















Le Faucheur, et al.     Expires September 9, 2010               [Page 2]

Internet-Draft       RSVP Receiver Proxy Extensions           March 2010


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
     1.1.  Conventions Used in This Document  . . . . . . . . . . . .  7
   2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  8
   3.  RSVP Extensions for Sender Notification  . . . . . . . . . . .  9
     3.1.  Sender Notification via PathErr Message  . . . . . . . . . 12
       3.1.1.  Composition of SESSION and Sender Descriptor . . . . . 15
       3.1.2.  Composition of ERROR_SPEC  . . . . . . . . . . . . . . 15
       3.1.3.  Use of Path_State_Removed Flag . . . . . . . . . . . . 16
       3.1.4.  Use of PathErr by Regular Receivers  . . . . . . . . . 17
     3.2.  Sender Notification via Notify Message . . . . . . . . . . 18
   4.  Mechanisms for Maximizing the Reservation Span . . . . . . . . 26
     4.1.  Dynamic Discovery of Downstream RSVP Functionality . . . . 26
     4.2.  Receiver Proxy Control Policy Element  . . . . . . . . . . 28
       4.2.1.  Default Handling . . . . . . . . . . . . . . . . . . . 31
   5.  Security Considerations  . . . . . . . . . . . . . . . . . . . 32
     5.1.  Security Considerations for the Sender Notification
           via Notify Message . . . . . . . . . . . . . . . . . . . . 33
     5.2.  Security Considerations for the Receiver Proxy Control
           Policy Element . . . . . . . . . . . . . . . . . . . . . . 33
   6.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 35
     6.1.  RSVP Error Codes . . . . . . . . . . . . . . . . . . . . . 35
     6.2.  Policy Element . . . . . . . . . . . . . . . . . . . . . . 35
   7.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 37
   8.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 38
     8.1.  Normative References . . . . . . . . . . . . . . . . . . . 38
     8.2.  Informative References . . . . . . . . . . . . . . . . . . 39
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 40






















Le Faucheur, et al.     Expires September 9, 2010               [Page 3]

Internet-Draft       RSVP Receiver Proxy Extensions           March 2010


1.  Introduction

   Guaranteed QoS for some applications with tight QoS requirements may
   be achieved by reserving resources in each node on the end-to-end
   path.  The main IETF protocol for these resource reservations is RSVP
   specified in [RFC2205].  RSVP does not require that all intermediate
   nodes support RSVP, but it assumes that both the sender and the
   receiver of the data flow support RSVP.  However, there are
   environments where it would be useful to be able to reserve resources
   for a flow (at least a subset of the flow path) even when the sender
   or the receiver (or both) is not RSVP-capable.

   Since both the data sender and receiver may be unaware of RSVP, there
   are two types of RSVP Proxies.  In the first case, an entity in the
   network needs to invoke RSVP on behalf of the data sender and thus
   generate RSVP Path messages, and eventually receive, process and sink
   Resv messages.  We refer to this entity as the RSVP Sender Proxy.  In
   the second case, an entity in the network needs to operate RSVP on
   behalf of the receiver and thus receive Path messages sent by a data
   sender (or by an RSVP Sender Proxy), and reply to those with Resv
   messages generated on behalf of the data receiver(s).  We refer to
   this entity as the RSVP Receiver Proxy.

   RSVP Proxy approaches are presented in
   [I-D.ietf-tsvwg-rsvp-proxy-approaches].  That document also
   discusses, for each approach, how the reservations controlled by the
   RSVP Proxy can be synchronized with the application requirements
   (e.g., when to establish, maintain and tear down the RSVP reservation
   to satisfy application requirements).

   One RSVP Proxy approach is referred to as the Path-Triggered RSVP
   Receiver Proxy approach.  With this approach, the RSVP Receiver Proxy
   uses the RSVP Path messages generated by the sender (or RSVP Sender
   Proxy) as the cue for establishing the RSVP reservation on behalf of
   the non-RSVP-capable receiver(s).  The RSVP Receiver Proxy is
   effectively acting as an intermediary making reservations (on behalf
   of the receiver) under the sender's control (or RSVP Sender Proxy's
   control).  This changes somewhat the usual RSVP reservation model
   where reservations are normally controlled by receivers.  Such a
   change greatly facilitates operations in the scenario of interest
   here, which is where the receiver is not RSVP-capable.  Indeed it
   allows the RSVP Receiver Proxy to remain application unaware by
   taking advantage of the application awareness and RSVP awareness of
   the sender (or RSVP Sender Proxy).

   Since the synchronization between an RSVP reservation and an
   application is now effectively performed by the sender (or RSVP
   Sender Proxy), it is important that the sender (or RSVP Sender Proxy)



Le Faucheur, et al.     Expires September 9, 2010               [Page 4]

Internet-Draft       RSVP Receiver Proxy Extensions           March 2010


   is aware of the reservation state.  However, as conventional RSVP
   assumes that the reservation is to be controlled by the receiver,
   some notifications about reservation state (notably the error message
   sent in case of admission control rejection of the reservation) are
   only sent towards the receiver and therefore, in our case, sunk by
   the RSVP Receiver Proxy.  Section 3 of the present document specifies
   extensions to RSVP procedures allowing such notifications to be also
   conveyed towards the sender.  This facilitates synchronization by the
   sender (or RSVP Sender Proxy) between the RSVP reservation and the
   application requirements and facilitates sender-driven control of
   reservation in scenarios involving a Path-Triggered RSVP receiver
   Proxy.

   With unicast applications in the presence of RSVP Receiver Proxies,
   if the sender is notified about the state of the reservation towards
   the receiver (as enabled by the present document), the sender is
   generally in a good position to synchronize the reservation with the
   application and to perform efficient sender-driven reservation: the
   sender can control establishment (respectively removal) of the
   reservation towards the receiver by sending Path (respectively
   PathTear) messages.  For example, if the sender is notified that the
   reservation for a point to point audio session towards the receiver
   is rejected, the sender may trigger rejection of the session at the
   application layer and may issue a PathTear message to remove any
   corresponding RSVP state (e.g.  Path states) previously established.

   However, we note that multicast applications do not always coexist
   well with RSVP Receiver Proxies, since sender notification about
   reservation state towards each RSVP Receiver Proxy may not be
   sufficient to achieve tight application level synchronization by
   multicast senders.  These limitations stem from the fact that
   multicast operation is receiver-driven and, while end-to-end RSVP is
   also receiver-driven (precisely to deal with multicast efficiently),
   the use of RSVP Receiver Proxies only allows sender-driven
   reservation.  For example, a sender generally is not aware of which
   receivers have joined downstream of a given RSVP Receiver Proxy, or
   even which RSVP Receiver Proxies have joined downstream of a given
   failure point.  Therefore, it may not be possible to support a mode
   of operation whereby a given receiver only joins a group if that
   receiver benefits from a reservation.  Additionally, a sender may
   have no recourse if only a subset of RSVP Receiver Proxies return
   successful reservations (even if application-level signalling runs
   between the sender and receivers), since the sender may not be able
   to correctly identify the set of receivers who do not have
   reservations.  However, it is possible to support a mode of operation
   whereby multicast traffic is transmitted if and only if all receivers
   benefit from a reservation (from sender to their respective RSVP
   Receiver Proxy): the sender can ensure this by sending a PathTear



Le Faucheur, et al.     Expires September 9, 2010               [Page 5]

Internet-Draft       RSVP Receiver Proxy Extensions           March 2010


   message and stopping transmission whenever it gets a notification for
   reservation reject for one or more RSVP Receiver Proxy.  It is also
   possible to support a mode of operation whereby receivers join
   independently of whether they can benefit from a reservation (to
   their respective RSVP Receiver Proxy) or not, but do benefit from a
   reservation whenever the corresponding resources are reservable on
   the relevant path.

   This document discusses extensions to facilitate operations in the
   presence of a Path-triggered RSVP Receiver Proxy.  As pointed out
   previously, those apply equally whether RSVP signaling is initiated
   by a regular RSVP sender or by an RSVP Sender Proxy (with some means
   to synchronize reservation state with application level requirements
   that are outside the scope of this document).  For readability, the
   rest of this document discusses operation assuming a regular RSVP
   sender; however, such operation is equally applicable where an RSVP
   Sender Proxy is used to initiated RSVP signaling on behalf of a non-
   RSVP-capable sender.

   As discussed in [I-D.ietf-tsvwg-rsvp-proxy-approaches], it is
   important to keep in mind that the strongly recommended RSVP
   deployment model remains end to end as assumed in [RFC2205] with RSVP
   support on the sender and the receiver.  The end to end model allows
   the most effective synchronization between the reservation and
   application requirements.  Also, when compared to the end to end RSVP
   model, the use of RSVP Proxies involves additional operational burden
   and/or impose some topological constraints.  Thus, the purpose of
   this document is only to allow RSVP deployment in special
   environments where RSVP just cannot be used on some senders and/or
   some receivers for reasons specific to the environment.

   Section 4.1.1 of [I-D.ietf-tsvwg-rsvp-proxy-approaches] discusses
   mechanisms allowing the RSVP reservation for a given flow to be
   dynamically extended downstream of an RSVP Proxy whenever possible
   (i.e.  When the receiver is RSVP capable or when there is another
   RSVP Receiver Proxy downstream).  This can considerably alleviate the
   operational burden and the topological constraints associated with
   Path-triggered RSVP Receiver Proxies.  This allows (without
   corresponding manual configuration) an RSVP reservation to
   dynamically span as much of the corresponding flow path as possible,
   with any arbitrary number of RSVP Receiver Proxies on the flow path
   and whether the receiver is RSVP capable or not.  In turn, this
   facilitates migration from an RSVP deployment model based on Path-
   triggered Receiver Proxies to an end-to-end RSVP model, since
   receivers can gradually and independently be upgraded to support RSVP
   and then instantaneously benefit from end-to-end reservations.
   Section 4 of the present document specifies these mechanisms and
   associated RSVP extensions.



Le Faucheur, et al.     Expires September 9, 2010               [Page 6]

Internet-Draft       RSVP Receiver Proxy Extensions           March 2010


1.1.  Conventions Used in This Document

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [RFC2119].














































Le Faucheur, et al.     Expires September 9, 2010               [Page 7]

Internet-Draft       RSVP Receiver Proxy Extensions           March 2010


2.  Terminology

   The following terminology is borrowed from
   [I-D.ietf-tsvwg-rsvp-proxy-approaches] and is used extensively in the
   present document:

   o  RSVP-capable (or RSVP-aware): supporting the RSVP protocol as per
      [RFC2205]

   o  RSVP Receiver Proxy: an RSVP-capable router performing, on behalf
      of a receiver, the RSVP operations which would normally be
      performed by an RSVP-capable receiver if end-to-end RSVP signaling
      was used.  Note that while RSVP is used upstream of the RSVP
      Receiver Proxy, RSVP is not used downstream of the RSVP Receiver
      Proxy.

   o  RSVP Sender Proxy: an RSVP-capable router performing, on behalf of
      a sender, the RSVP operations that normally would be performed by
      an RSVP-capable sender if end-to-end RSVP signaling was used.
      Note that while RSVP is used downstream of the RSVP Sender Proxy,
      RSVP is not used upstream of the RSVP Sender Proxy.

   o  Regular RSVP Router: an RSVP-capable router which is not behaving
      as a RSVP Receiver Proxy nor as a RSVP Sender Proxy.

   Note that the roles of RSVP Receiver Proxy, RSVP Sender Proxy,
   Regular RSVP Router are all relative to one unidirectional flow.  A
   given router may act as the RSVP Receiver Proxy for a flow, as the
   RSVP Sender Proxy for another flow and as a Regular RSVP router for
   yet another flow.

   The following terminology is also used in the present document:

   o  Regular RSVP Sender: an RSVP-capable host behaving as the sender
      for the considered flow and participating in RSVP signaling in
      accordance with the sender behavior specified in [RFC2205].

   o  Regular RSVP Receiver: an RSVP-capable host behaving as the
      receiver for the considered flow and participating in RSVP
      signaling in accordance with the receiver behavior specified in
      [RFC2205].










Le Faucheur, et al.     Expires September 9, 2010               [Page 8]

Internet-Draft       RSVP Receiver Proxy Extensions           March 2010


3.  RSVP Extensions for Sender Notification

   This section defines extensions to RSVP procedures allowing sender
   notification of reservation failure.  This facilitates
   synchronization by the sender between RSVP reservation and
   application requirements in scenarios involving a Path-Triggered RSVP
   Receiver Proxy.

   As discussed in [I-D.ietf-tsvwg-rsvp-proxy-approaches], with the
   Path-Triggered RSVP Receiver Proxy approach, the RSVP router may be
   configured to use receipt of a regular RSVP Path message as the
   trigger for RSVP Receiver Proxy behavior.  On receipt of the RSVP
   Path message, the RSVP Receiver Proxy:

   1.  establishes the RSVP Path state as per regular RSVP processing

   2.  identifies the downstream interface towards the receiver

   3.  sinks the Path message

   4.  behaves as if a corresponding Resv message (on its way upstream
       from the receiver) was received on the downstream interface.
       This includes performing admission control on the downstream
       interface, establishing a Resv state (in case of successful
       admission control) and forwarding the Resv message upstream,
       sending periodic refreshes of the Resv message and tearing down
       the reservation if the Path state is torn down.

   Operation of the Path-Triggered Receiver Proxy in the case of a
   successful reservation is illustrated in Figure 1.





















Le Faucheur, et al.     Expires September 9, 2010               [Page 9]

Internet-Draft       RSVP Receiver Proxy Extensions           March 2010


 |****|        ***        ***        ***        |**********|      |----|
 | S  |--------*r*--------*r*--------*r*--------| RSVP     |------| R  |
 |****|        ***        ***        ***        | Receiver |      |----|
                                                | Proxy    |
                                                |**********|

      --Path---> --Path---> --Path---> --Path--->

      <---Resv-- <---Resv-- <---Resv-- <---Resv--

      ===================RSVP===================>

      ************************************************************>


 |****| RSVP-capable     |----| Non-RSVP-capable        ***
 | S  | Sender           | R  | Receiver                *r* regular RSVP
 |****|                  |----|                         *** router


 ***> media flow

 ==>  segment of flow path benefiting from an RSVP reservation


                     Figure 1: Successful Reservation

   We observe that, in the case of successful reservation, conventional
   RSVP procedures ensure that the sender is notified of the successful
   reservation establishment.  Thus, no extensions are required in the
   presence of a Path-Triggered RSVP Receiver Proxy in the case of
   successful reservation establishment.

   However, in case of reservation failure, conventional RSVP procedures
   ensure only that the receiver (or the RSVP Receiver Proxy) is
   notified of the reservation failure.  Specifically, in case of an
   admission control rejection on a regular RSVP router, a ResvErr
   message is sent downstream towards the receiver.  In the presence of
   an RSVP Receiver Proxy, if we simply follow conventional RSVP
   procedures, this means that the RSVP Receiver Proxy is notified of
   the reservation failure, but the sender is not.  Operation of the
   Path-Triggered RSVP Receiver Proxy in the case of an admission
   control failure, assuming conventional RSVP procedures, is
   illustrated in Figure 2.







Le Faucheur, et al.     Expires September 9, 2010              [Page 10]

Internet-Draft       RSVP Receiver Proxy Extensions           March 2010


 |****|        ***        ***        ***        |**********|      |----|
 | S  |--------*r*--------*r*--------*r*--------| RSVP     |------| R  |
 |****|        ***        ***        ***        | Receiver |      |----|
                                                | Proxy    |
                                                |**********|

      --Path---> --Path---> --Path---> --Path--->

                            <---Resv-- <---Resv--

                            -ResvErr-> -ResvErr->

      ===================RSVP===================>

      ************************************************************>


 |****| RSVP-capable  |----| Non-RSVP-capable   ***
 | S  | Sender        | R  | Receiver           *r* regular RSVP
 |****|               |----|                    *** router

 ***> media flow

 ==>  segment of flow path benefiting from an RSVP reservation


           Figure 2: Reservation Failure With Conventional RSVP

   While the sender could infer reservation failure from the fact that
   it has not received a Resv message after a certain time, there are
   clear benefits in ensuring that the sender gets a prompt, explicit
   notification in case of reservation failure.  This includes faster
   end-user notification at application layer (e.g., busy signal),
   faster application level reaction (e.g., application level
   rerouting), as well as faster release of application-level resources.

   Section 3.1 defines a method that can be used to achieve sender
   notification of reservation failure.  A router implementation
   claiming compliance with this document MUST support the method
   defined in Section 3.1.

   Section 3.2 defines another method that can be used to achieve sender
   notification of reservation failure.  A router implementation
   claiming compliance with this document MAY support the method defined
   in Section 3.2.

   In a given network environment, a network administrator may elect to
   use the method defined in Section 3.1, or the method defined in



Le Faucheur, et al.     Expires September 9, 2010              [Page 11]

Internet-Draft       RSVP Receiver Proxy Extensions           March 2010


   Section 3.2, or possibly combine the two.

3.1.  Sender Notification via PathErr Message

   With this method, the RSVP Receiver Proxy MUST generate a PathErr
   message whenever the two following conditions are met:

   1.  The reservation establishment has failed (or the previously
       established reservation has been torn down)

   2.  The RSVP Receiver Proxy determines that it cannot re-establish
       the reservation (e.g., by adapting its reservation request in
       reaction to the error code provided in the received ResvErr in
       accordance with local policy)

   Note that this notion of generating a PathErr message upstream in
   order to notify the sender about a reservation failure is not
   completely new.  It is borrowed from [RFC3209] where it has been
   introduced in order to achieve a similar requirement, which is to
   allow an MPLS TE Label Switch Router to notify the TE Tunnel Head-end
   (i.e., the sender) of a failure to establish (or maintain) a TE
   Tunnel Label Switch Path.

   Operation of the Path-Triggered RSVP Receiver Proxy in the case of an
   admission control failure, using sender notification via PathErr
   Message, is illustrated in Figure 3.

























Le Faucheur, et al.     Expires September 9, 2010              [Page 12]

Internet-Draft       RSVP Receiver Proxy Extensions           March 2010


 |****|        ***        ***        ***        |**********|      |----|
 | S  |--------*r*--------*r*--------*r*--------| RSVP     |------| R  |
 |****|        ***        ***        ***        | Receiver |      |----|
                                                | Proxy    |
                                                |**********|

      --Path---> --Path---> --Path---> --Path--->

                            <---Resv-- <---Resv--

                            -ResvErr-> -ResvErr->

      <-PathErr- <-PathErr- <-PathErr- <-PathErr-

      ===================RSVP===================>

      ************************************************************>


 |****| RSVP-capable  |----| Non-RSVP-capable   ***
 | S  | Sender        | R  | Receiver           *r* regular RSVP
 |****|               |----|                    *** router

 ***> media flow

 ==>  segment of flow path benefiting from RSVP
      (but not benefiting from a reservation in this case)


    Figure 3: Reservation Failure With Sender Notification via PathErr

   The role of this PathErr is to notify the sender that the reservation
   was not established or was torn down.  This may be in the case of
   receipt of a ResvErr, or because of local failure on the Receiver
   Proxy.  On receipt of a ResvErr, in all situations where the
   reservation cannot be installed, the Receiver Proxy MUST generate a
   PathErr towards the sender.  For local failures on the Receiver Proxy
   node, if a similar failure on an RSVP midpoint would cause the
   generation of a ResvErr (for example, admission control failure), the
   Receiver Proxy MUST generate a PathErr towards the sender.  The
   Receiver Proxy MAY additionally generate a PathErr upon local
   failures which would not ordinarily cause generation of a ResvErr
   message, such as described in Appendix B of [RFC2205].

   The PathErr generated by the Receiver Proxy corresponds to the
   sender(s) that triggered generation of Resv messages that failed.
   For Fixed-Filter (FF) style reservations, the Receiver Proxy MUST
   send a PathErr towards the (single) sender matching the failed



Le Faucheur, et al.     Expires September 9, 2010              [Page 13]

Internet-Draft       RSVP Receiver Proxy Extensions           March 2010


   reservation.  For Shared-Explicit (SE) style reservations, the
   Receiver Proxy MUST send the PathErr(s) towards the set of senders
   that triggered reservations that failed.  This may be a subset of
   senders sharing the same reservation, in which case the remaining
   senders would have their reservation intact and would not receive a
   PathErr.  In both cases, the rules described in Section 3.1.8 of
   [RFC2205] for generating flow descriptors in ResvErr messages, also
   apply when generating sender descriptors in PathErr messages.

   For Wildcard-Filter (WF) style reservations, it is not always
   possible for the Receiver Proxy to reliably know which sender caused
   the reservation failure.  Therefore, the Receiver Proxy SHOULD send a
   PathErr towards each sender.  This means that all the senders will
   receive a notification that the reservation is not established,
   including senders that did not cause the reservation failure.
   Therefore, the method of sender notification via PathErr message is
   somewhat over-conservative (i.e., in some cases rejecting
   reservations from some senders when those could have actually been
   established) when used in combination with Wildcard-Filter style (and
   when there is more than one sender).

   The sender notification via PathErr method applies to both unicast
   and multicast sessions.  However, for a multicast session, it is
   possible that reservation failure (e.g., admission control failure)
   in a node close to a sender may cause ResvErr messages to be sent to
   a large group of Receiver Proxies.  These Receiver Proxies would, in
   turn, all send PathErr messages back to the same sender, which could
   cause a scalability issue in some environments.

   From the perspective of the sender, errors that prevent a reservation
   from being set up can be classified in two ways:

   1.  Errors that the sender can attempt to correct.  The error code
       for those errors should explicitly be communicated back to the
       sender.  An examples of this is "Class 1: Admission Control
       Failure", because the sender could potentially resend a Path with
       smaller traffic parameters.

   2.  Errors over which the sender has no control.  For these errors,
       it is sufficient to notify the sender that the reservation was
       not set up successfully.  An example of this is "Class 13:
       Unknown Object", because the sender has no control over the
       objects inserted into the reservation by the Receiver Proxy.

   The PathErr message generated by the Receiver Proxy has the same
   format as regular PathErr messages defined in [RFC2205].  The
   SESSION, ERROR_SPEC and sender descriptor are composed by the
   Receiver Proxy as specified in the following subsections.  The



Le Faucheur, et al.     Expires September 9, 2010              [Page 14]

Internet-Draft       RSVP Receiver Proxy Extensions           March 2010


   Receiver Proxy MAY reflect back towards the sender in the PathErr any
   POLICY_DATA objects received in the ResvErr.

3.1.1.  Composition of SESSION and Sender Descriptor

   The Receiver Proxy MUST insert the SESSION object corresponding to
   the failed reservation, into the PathErr.  For Fixed-Filter (FF)
   style reservations, the Receiver Proxy MUST insert a sender
   descriptor corresponding to the failed reservation, into the PathErr.
   This is equal to the error flow descriptor in the ResvErr received by
   the Receiver Proxy.  For Shared-Explicit (SE) style reservations, the
   Receiver Proxy MUST insert a sender descriptor corresponding to the
   sender triggering the failed reservation, into the PathErr.  This is
   equal to the error flow descriptor in the ResvErr received by the
   Receiver Proxy.  If multiple flow descriptors could not be admitted
   at a midpoint node, that node would generate multiple ResvErr
   messages towards the receiver as per Section 3.1.8 of [RFC2205].
   Each ResvErr would contain an error flow descriptor that matches a
   specific sender.  The Receiver Proxy MUST generate a PathErr for each
   ResvErr received, towards the corresponding sender.  As specified
   earlier, for Wildcard-Filter style reservations, the Receiver Proxy
   SHOULD send a PathErr to each sender.

3.1.2.  Composition of ERROR_SPEC

   The Receiver Proxy MUST compose the ERROR_SPEC to be inserted into
   the PathErr as follows:

   1.  If the Receiver Proxy receives a ResvErr with any of these error
       codes: "Code 1 - Admission Control Failure" or "Code 2 - Policy
       Control Failure" then the Receiver Proxy copies the error code
       and value from the ERROR_SPEC in the ResvErr, into the ERROR_SPEC
       of the PathErr message.  The error node in the PathErr MUST be
       set to the address of the Receiver Proxy.  This procedure MUST
       also be followed for a local error on the Receiver Proxy that
       would ordinarily cause a midpoint to generate a ResvErr with one
       of the above codes.

   2.  If the Receiver Proxy receives a ResvErr with any error code
       other than the ones listed in 1 above, it composes a new
       ERROR_SPEC with error code "<TBD-See IANA Considerations
       section>: Unrecoverable Receiver Proxy Error".  The error node in
       the PathErr MUST be set to the address of the Receiver Proxy.
       This procedure MUST also be followed for a local error on the
       Receiver Proxy that would ordinarily cause a midpoint to generate
       a ResvErr with any error code except than those listed in 1
       above, or if the Receiver Proxy generates a PathErr for a local
       error which ordinarily would not cause generation of a ResvErr.



Le Faucheur, et al.     Expires September 9, 2010              [Page 15]

Internet-Draft       RSVP Receiver Proxy Extensions           March 2010


       In some cases it may be predetermined that the PathErr will not
       reach the sender.  For example, a node receiving a ResvErr with
       "Code 3: No Path for Resv", knows a priori that the PathErr
       message it generates cannot be forwarded by the same node which
       could not process the Resv.  Nevertheless, the procedures above
       MUST be followed.  For the error code "<TBD-See IANA
       Considerations section>: Unrecoverable Receiver Proxy Error", the
       16 bits of the Error Value field are:

       *  hhhh hhhh llll llll

       where the bits are:

       *  hhhh hhhh = 0000 0000: then the low order 8 bits (llll llll)
          MUST be set by Receiver Proxy to 0000 0000 and MUST be ignored
          by the sender.

       *  hhhh hhhh = 0000 0001: then the low order 8 bits (llll llll)
          MUST be set by the Receiver Proxy to the value of the error
          code received in the ResvErr ERROR_SPEC (or, in case the
          Receiver Proxy generated the PathErr without having received a
          ResvErr, to the error code value that would have been included
          by the Receiver Proxy in the ERROR_SPEC in similar conditions
          if it was to generate a ResvErr).  This error value MAY be
          used by the sender to further interpret the reason of the
          reservation failure.

       *  hhhh hhhh = any other value: reserved.

   3.  If the Receiver Proxy Receives a ResvErr with the InPlace flag
       set in the ERROR_SPEC, it MUST also set the InPlace flag in the
       ERROR_SPEC of the PathErr.

3.1.3.  Use of Path_State_Removed Flag

   [RFC3473] defines an optional behavior whereby a node forwarding a
   PathErr message can remove the Path State associated with the PathErr
   message and indicate so by including the Path_State_Removed flag in
   the ERROR_SPEC object of the PathErr message.  This can be used in
   some situations to expedite release of resources and minimize
   signaling load.

   This section discusses aspects of the use of the Path_State_Removed
   flag that are specific to the RSVP Receiver Proxy.  In any other
   aspects, the Path_State_Removed flag operates as per [RFC3473].

   By default, the RSVP Receiver Proxy MUST NOT include the
   Path_State_Removed flag in the ERROR_SPEC of the PathErr message.



Le Faucheur, et al.     Expires September 9, 2010              [Page 16]

Internet-Draft       RSVP Receiver Proxy Extensions           March 2010


   This ensures predictable operations in all environments including
   those where some RSVP routers do not understand the
   Path_State_Removed flag.

   The RSVP Receiver Proxy MAY support an OPTIONAL mode (to be activated
   by configuration) whereby the RSVP Receiver Proxy includes the
   Path_State_Removed flag in the ERROR_SPEC of the PathErr message and
   removes its local Path state.  When all routers on the path of a
   reservation support the Path_State_Removed flag, its use will indeed
   result in expedited resource release and reduced signaling.  However,
   if there are one or more RSVP router on the path of the reservation
   that do not support the Path_State_Removed flag (we refer to such
   routers as "old RSVP routers"), the use of the Path_State_Removed
   flag will actually result in slower resource release and increased
   signaling.  This is because the Path_State_Removed flag will be
   propagated upstream by an old RSVP router (even if it does not
   understand it and does not tear its Path state).  Thus, the sender
   will not send a Path Tear and the old RSVP router will release its
   Path state only through refresh time-out.  A network administrator
   needs to keep these considerations in mind when deciding whether to
   activate the use of the Path_State_Removed flag on the RSVP Receiver
   Proxy.  In a controlled environment where all routers are known to
   support the Path_State_Removed flag, its use can be safely activated
   on the RSVP Receiver Proxy.  In other environments, the network
   administrator needs to assess whether the improvement achieved with
   some reservations outweighs the degradation experienced by other
   reservations.

3.1.4.  Use of PathErr by Regular Receivers

   Note that while this document specifies that an RSVP Receiver Proxy
   generates a PathErr upstream in case of reservation failure, this
   document does NOT propose that the same be done by regular receivers.
   In other words, this document does NOT propose to modify the behavior
   of regular receivers as currently specified in [RFC2205].  The
   rationale for this includes the following:

   o  When the receiver is RSVP capable, the current receiver-driven
      model of [RFC2205] is fully applicable because the receiver can
      synchronise RSVP reservation state and application state (since it
      participates in both).  The sender(s) needs not be aware of the
      RSVP reservation state.  Thus, we can retain the benefits of
      receiver-driven operations which were explicitly sought by
      [RFC2205].  Quoting from it: " In order to efficiently accommodate
      large groups, dynamic group membership, and heterogeneous receiver
      requirements, RSVP makes receivers responsible for requesting a
      specific QoS".  But even for the simplest single_sender/
      single_receiver reservations, the current receiver-driven model



Le Faucheur, et al.     Expires September 9, 2010              [Page 17]

Internet-Draft       RSVP Receiver Proxy Extensions           March 2010


      reduces signaling load and per-hop RSVP processing by not sending
      any error message to the sender in case of admission control
      reject.

   o  The motivation for adding sender error notification in case of
      receiver proxy lies in the fact that the actual receiver can no
      longer synchronize the RSVP reservation with application state
      (since the receiver does not participate in RSVP signaling), while
      the sender can.  This motivation does not apply in case of regular
      receiver.

   o  There is a lot of existing code and deployed systems successfully
      working under the current [RFC2205] model in the absence of proxy
      today.  The current behavior should not be changed for those
      unless there were a very strong motivation.

3.2.  Sender Notification via Notify Message

   The OPTIONAL method for sender notification of reservation failure
   defined in this section aims to provide a more efficient method than
   the one defined in Section 3.1.  Its objectives include:

   o  allow the failure notification to be sent directly upstream to the
      sender by the router where the failure occurs (as opposed to first
      travelling downstream towards the Receiver Proxy and then
      travelling upstream from the Receiver Proxy to the sender, as
      effectively happens with the method defined in Section 3.1)

   o  allow the failure notification to travel without hop-by-hop RSVP
      processing

   o  ensure that such a notification is sent to senders that are
      capable and willing to process it (i.e., to synchronize
      reservation status with application)

   o  ensure that such a notification is only sent in case the receiver
      is not itself capable and willing to do the synchronization with
      the application (i.e., because we are in the presence of a
      Receiver Proxy so that RSVP signaling is not visible to the
      receiver).

   Note, however, that such benefits come at the cost of:

   o  a requirement for RSVP routers and senders to support the Notify
      messages and procedures defined in [RFC3473]

   o  a requirement for senders to process Notify messages traveling
      upstream but conveying a downstream notification.



Le Faucheur, et al.     Expires September 9, 2010              [Page 18]

Internet-Draft       RSVP Receiver Proxy Extensions           March 2010


   [RFC3473] defines (in section "4.3 Notify Messages") the Notify
   message that provides a mechanism to inform non-adjacent nodes of
   events related to the RSVP reservation.  The Notify message differs
   from the error messages defined in [RFC2205] (i.e., PathErr and
   ResvErr messages) in that it can be "targeted" to a node other than
   the immediate upstream or downstream neighbor and that it is a
   generalized notification mechanism.  Notify messages are normally
   generated only after a Notify Request object has been received.

   This section discusses aspects of the use of the Notify message that
   are specific to the RSVP Receiver Proxy.  In any other aspects, the
   Notify message operates as per [RFC3473].

   In order to achieve sender notification of reservation failure in the
   context of the present document:

   o  An RSVP sender interested in being notified of reservation failure
      MUST include a Notify Request object (containing the sender's IP
      address) in the Path messages it generates.

   o  Upon receiving a Path message with a Notify Request object, the
      RSVP Receiver Proxy MUST include a Notify Request object in the
      Resv messages it generates.  This Notify Request object MUST
      contain:

      *  either the address that was included in the Notify Request of
         the received Path message- a.k.a.  The sender's address-.  We
         refer to this approach as the "Direct Notify".

      *  or an address of the Receiver Proxy.  We refer to this approach
         as the "Indirect Notify".

   o  Upon receiving a downstream error notification (whether in the
      form of a Notify or a ResvErr or both), the RSVP Receiver Proxy:

      *  MUST generate a Notify message with upstream notification to
         the corresponding sender, if the sender included a Notify
         Request object in its Path messages and if Indirect
         Notification is used.

      *  SHOULD generate a Notify message with upstream notification to
         the corresponding sender, if the sender included a Notify
         Request object in its Path messages and if Direct Notification
         is used.  The reason for this recommendation is that the
         failure node may not support Notify, so that even if Direct
         Notification was requested by the RSVP Receiver Proxy, the
         sender may not actually have received a Notify from the failure
         node: generating a Notify from the Receiver Proxy will



Le Faucheur, et al.     Expires September 9, 2010              [Page 19]

Internet-Draft       RSVP Receiver Proxy Extensions           March 2010


         accelerate sender notification, as compared to simply relying
         on PathErr, in this situation.  In controlled environments
         where all the nodes are known to support Notify, the Receiver
         Proxy MAY be configured to not generate the Notify with
         upstream notification when Direct Notification is used, in
         order to avoid duplication of Notify messages (i.e.  The sender
         receiving both a Notify from the failure node and from the
         Receiver Proxy)

   As a result of these sender and Receiver Proxy behaviors, as per
   existing Notify procedures, if an RSVP router detects an error
   relating to a Resv state (e.g., admission control rejection after IP
   reroute), the RSVP router will send a Notify message (conveying the
   downstream notification with the ResvErr error code) to the IP
   address contained in the Resv Notify Request object.  If this address
   has been set by the RSVP Receiver Proxy to the sender's address
   (Direct Notify), the Notify message is sent directly to the sender.
   If this address has been set by the RSVP Receiver Proxy to one of its
   address (Indirect Notify), the Notify message is sent to the RSVP
   Receiver Proxy that, in turn, will generate a Notify message directly
   addressed to the sender.

   Operation of the Path-Triggered RSVP Receiver Proxy in the case of an
   admission control failure, using sender notification via Direct
   Notify, is illustrated in Figure 4.


























Le Faucheur, et al.     Expires September 9, 2010              [Page 20]

Internet-Draft       RSVP Receiver Proxy Extensions           March 2010


 |****|        ***        ***        ***        |**********|      |----|
 | S  |--------*r*--------*r*--------*r*--------| RSVP     |------| R  |
 |****|        ***        ***        ***        | Receiver |      |----|
                                                | Proxy    |
                                                |**********|

      --Path*--> --Path*--> --Path*--> --Path*-->

                            <--Resv*-- <--Resv*--

      <------NotifyD--------

                            -ResvErr-> -ResvErr->

      <------------------NotifyU------------------

      <-PathErr- <-PathErr- <-PathErr- <-PathErr-

      ===================RSVP===================>

      ************************************************************>


 |****| RSVP-capable  |----| Non-RSVP-capable   ***
 | S  | Sender        | R  | Receiver           *r* regular RSVP
 |****|               |----|                    *** router

 ***> media flow

 ==>  segment of flow path benefiting from RSVP
      (but not benefiting from a reservation in this case)

 Path*  = Path message containing a Notify Request object
          with sender IP Address

 Resv*  = Resv message containing a Notify Request object
          with sender IP address

 NotifyD = Notify message containing a downstream notification

 NotifyU = Notify message containing an upstream notification


     Figure 4: Reservation Failure With Sender Notification via Direct
                                  Notify

   Operation of the Path-Triggered RSVP Receiver Proxy in the case of an
   admission control failure, using sender notification via Indirect



Le Faucheur, et al.     Expires September 9, 2010              [Page 21]

Internet-Draft       RSVP Receiver Proxy Extensions           March 2010


   Notify, is illustrated in Figure 5.


















































Le Faucheur, et al.     Expires September 9, 2010              [Page 22]

Internet-Draft       RSVP Receiver Proxy Extensions           March 2010


 |****|        ***        ***        ***        |**********|      |----|
 | S  |--------*r*--------*r*--------*r*--------| RSVP     |------| R  |
 |****|        ***        ***        ***        | Receiver |      |----|
                                                | Proxy    |
                                                |**********|

      --Path*--> --Path*--> --Path*--> --Path*-->

                            <--Resv*-- <--Resv*--

                            -------NotifyD------->

      <------------------NotifyU------------------

                            -ResvErr-> -ResvErr->

      <-PathErr- <-PathErr- <-PathErr- <-PathErr-

      ===================RSVP===================>

      ************************************************************>


 |****| RSVP-capable  |----| Non-RSVP-capable   ***
 | S  | Sender        | R  | Receiver           *r* regular RSVP
 |****|               |----|                    *** router

 ***> media flow

 ==>  segment of flow path benefiting from RSVP
      (but not benefiting from a reservation in this case)

 Path*  = Path message containing a Notify Request object
          with sender IP Address

 Resv*  = Resv message containing a Notify Request object
          with RSVP Receiver Proxy IP address

 NotifyD = Notify message containing a downstream notification

 NotifyU = Notify message containing an upstream notification


    Figure 5: Reservation Failure With Sender Notification via Indirect
                                  Notify

   For local failures on the Receiver Proxy node, if a similar failure
   on an RSVP midpoint would cause the generation of a ResvErr (for



Le Faucheur, et al.     Expires September 9, 2010              [Page 23]

Internet-Draft       RSVP Receiver Proxy Extensions           March 2010


   example, admission control failure), the Receiver Proxy MUST generate
   a Notify towards the sender.  The Receiver Proxy MAY additionally
   generate a Notify upon local failures that would not ordinarily cause
   generation of a ResvErr message, such as described in Appendix B of
   [RFC2205].

   When the method of sender notification via Notify message is used, it
   is RECOMMENDED that the RSVP Receiver Proxy also issue a sender
   notification via a PathErr message.  This maximizes the chances that
   the notification will reach the sender in all situations (e.g., even
   if some RSVP routers do not support the Notify procedure, or if a
   Notify message gets dropped).  However, for controlled environments
   (e.g., where all RSVP routers are known to support Notify procedures)
   and where it is desirable to minimize the volume of signaling, the
   RSVP Receiver Proxy MAY rely exclusively on sender notification via
   Notify message and thus not issue sender notification via PathErr
   message.

   In environments where there are both RSVP-capable receivers and RSVP
   Receiver Proxies acting on behalf of non RSVP-capable receivers, a
   sender does not know whether a given reservation is established with
   an RSVP-capable receiver or with an RSVP Receiver Proxy.  Thus, a
   sender that supports the procedures defined in this section may
   include a Notify Request object in Path messages for a reservation
   that happens to be controlled by an RSVP-capable receiver.  This
   document does not define, nor expect, any change in existing receiver
   behavior.  As a result, in this case, the sender will not receive
   Notify messages conveying downstream notifications.  However, this is
   perfectly fine because the synchronization between the RSVP
   reservation state and the application requirement can be performed by
   the actual receiver in this case as per the regular end-to-end RSVP
   model, so that in this case, the sender need not care about
   downstream notifications.

   A sender that does not support the procedures defined in this section
   might include a Notify Request object in Path messages for a
   reservation simply because it is interested in getting upstream
   notifications faster.  If the reservation is controlled by an RSVP
   Receiver Proxy supporting the procedures defined in this section, the
   sender will also receive unexpected Notify messages containing
   downstream notifications.  It is expected that such a sender will
   simply naturally drop such downstream notifications as invalid.
   Because it is RECOMMENDED above that the RSVP Receiver Proxy also
   issues sender notification via a PathErr message even when sender
   notification is effected via a Notify message, the sender will still
   be notified of a reservation failure in accordance with the "sender
   notification via PathErr" method.  In summary, activating the
   OPTIONAL "sender notification via Notify" method on a Receiver Proxy,



Le Faucheur, et al.     Expires September 9, 2010              [Page 24]

Internet-Draft       RSVP Receiver Proxy Extensions           March 2010


   does not prevent a sender that does not support this method, to rely
   on the MANDATORY "sender notification via PathErr" method.  It would,
   however, allow a sender supporting the "sender notification via
   Notify" method to take advantage of this OPTIONAL method.

   With Direct Notification, the downstream notification generated by
   the RSVP router where the failure occurs is sent to the IP address
   contained in the Notification Request Object of the corresponding
   Resv message.  In the presence of multiple senders towards the same
   session, it cannot be generally assumed that a separate Resv message
   is used for each sender (in fact with WF and SE there is a single
   Resv message for all senders, and with FF the downstream router has
   the choice of generating separate Resv messages or a single one).
   Hence, in the presence of multiple senders, Direct Notification
   cannot guarantee notification of all affected senders.  Therefore,
   Direct Notification is better suited to single sender applications.

   With Indirect Notification, the RSVP Receiver Proxy can generate
   Notify messages with the same logic that is used to generate PathErr
   messages in the "Sender Notification via PathErr" method (in fact
   those are conveying the same error information, only the Notify is
   directly addressed to the sender while the PathErr travels hop-by-
   hop).  Therefore, operations of Indirect Notify method in the
   presence of multiple senders is similar to that of the PathErr method
   as discussed in Section 3.1: with FF (respectively, SE) a Notify MUST
   be sent to the sender (respectively, the set of affected senders).
   With WF, the RSVP Receiver Proxy SHOULD send a Notify to each sender,
   again resulting in a somewhat over-conservative behavior in the
   presence of multiple senders.






















Le Faucheur, et al.     Expires September 9, 2010              [Page 25]

Internet-Draft       RSVP Receiver Proxy Extensions           March 2010


4.  Mechanisms for Maximizing the Reservation Span

   This section defines extensions to RSVP procedures allowing an RSVP
   reservation to span as much as possible of the flow path, with any
   arbitrary number of RSVP Receiver Proxies on the flow path and
   whether the receiver is RSVP capable or not.  This facilitates
   deployment and operations of Path-triggered RSVP Receiver Proxies
   since it alleviates the topological constraints and/or configuration
   load otherwise associated with Receiver Proxies (e.g.  Make sure
   there is no RSVP Receiver Proxy for a flow upstream of a given
   Receiver Proxy, ensure there is no Receiver Proxy for a flow if the
   receiver is RSVP capable).  This also facilitates migration from an
   RSVP deployment model based on Path-triggered Receiver Proxies to an
   end-to-end RSVP model, since receivers can gradually and
   independently be upgraded to support RSVP and then instantaneously
   benefit from end-to-end reservations.

   Section 4.1 defines a method that allows a Path-triggered Receiver
   Proxy function to discover whether there is another Receiver Proxy or
   an RSVP capable receiver downstream and then dynamically extend the
   span of the RSVP reservation downstream.  A router implementation
   claiming compliance with this document SHOULD support the method
   defined in Section 4.1.

   Section 4.2 defines a method that allows a sender to control whether
   an RSVP router supporting the Path-triggered Receiver Proxy function
   is to behave as a Receiver Proxy for a given flow or not.  A router
   implementation claiming compliance with this document MAY support the
   method defined in Section 4.2.

   In a given network environment, a network administrator may elect to
   use the method defined in Section 4.1, or the method defined in
   Section 4.2, or possibly combine the two.

4.1.  Dynamic Discovery of Downstream RSVP Functionality

   When generating a proxy Resv message upstream, a Receiver Proxy
   supporting dynamic discovery of downstream RSVP functionality MUST
   forward the Path message downstream instead of terminating it (unless
   dynamic discovery of downstream RSVP functionality is explicitely
   disabled).  If the destination endpoint supports RSVP (or there is
   another Receiver Proxy downstream), it will receive the Path and
   generate a Resv upstream.  When this Resv message reaches the
   Receiver Proxy, it recognizes the presence of a RSVP-capable receiver
   (or of another RSVP Receiver Proxy) downstream and MUST internally
   converts its state from a proxied reservation to a regular midpoint
   RSVP behavior.  From then on, the RSVP router MUST behave as a
   regular RSVP router for that reservation (i.e.  As if the RSVP router



Le Faucheur, et al.     Expires September 9, 2010              [Page 26]

Internet-Draft       RSVP Receiver Proxy Extensions           March 2010


   never behaved as an RSVP receiver proxy for that flow).  This method
   is illustrated in Figure 6.

      |****|         ***         |**********|   |----|
      | S  |---------*r*---------| RSVP     |---| R1 |
      |****|         ***         | Receiver |   |----|
                                 | Proxy    |
                                 |          |
                                 |          |            |****|
                                 |          |------------| R2 |
                                 |**********|            |****|

           ---Path--->  --Path--->
              (R1)        (R1)    \-------Path-->
                                  /       (R1)
           <--Resv---  <---Resv---

          ================RSVP===>

          **************************************>



           ---Path--->  --Path--->
              (R2)        (R2)    \-------------Path---->
                                  /             (R2)
           <--Resv---  <---Resv---
                                             <----Resv---

          ================RSVP===========================>

          ***********************************************>


   |****| RSVP-capable  |----| non-RSVP-capable  |****| RSVP-capable
   | S  | Sender        | R  | Receiver          | R  | Receiver
   |****|               |----|                   |****|

   ***
   *r* regular RSVP
   *** router

   (R1) = Path message contains a Session object whose destination is R1

   ***> media flow

   ==>  segment of flow path protected by RSVP reservation




Le Faucheur, et al.     Expires September 9, 2010              [Page 27]

Internet-Draft       RSVP Receiver Proxy Extensions           March 2010


       Figure 6: Dynamic Discovery of Downstream RSVP Functionality

   If there is no RSVP-capable receiver (or other Receiver Proxy)
   downstream of the Receiver Proxy, then the Path messages sent by the
   Receiver Proxy every RSVP refresh interval (e.g. 30 seconds by
   default) will never be responded to.  However, these messages consume
   a small amount of bandwidth, and in addition would install some RSVP
   state on RSVP-capable midpoint nodes downstream of the first Receiver
   Proxy.  This is seen as a very minor sub-optimality, however, to
   mitigate this, the Receiver Proxy MAY tear down any unanswered
   downstream Path state after a predetermined time (that SHOULD be
   greater or equal to the Path refresh interval), and MAY stop sending
   Path messages for the flow (or MAY only send them at much lower
   frequency).

   This approach only requires support of the behavior described in the
   previous paragraph and does not require any new RSVP extensions.

4.2.  Receiver Proxy Control Policy Element

   [RFC2750] defines extensions for supporting generic policy based
   admission control in RSVP.  These extensions include the standard
   format of POLICY_DATA objects and a description of RSVP handling of
   policy events.

   The POLICY_DATA object contains one or more of Policy Elements, each
   representing a different (and perhaps orthogonal) policy.  As an
   example, [RFC3181] specifies the Preemption Priority Policy Element.

   The present document defines a new Policy Element called the Receiver
   Proxy Control Policy Element.  The present document only defines the
   use of this Policy Element in Path messages and for unicast
   reservations.  Other usage are outside the scope of the present
   document.

   The format of the Receiver Proxy Control Policy Element is as shown
   in Figure 7:














Le Faucheur, et al.     Expires September 9, 2010              [Page 28]

Internet-Draft       RSVP Receiver Proxy Extensions           March 2010


          0           0 0           1 1           2 2           3
          0  . . .    7 8   . . .   5 6    . . .  3 4  . . .    1
         +-------------+-------------+-------------+-------------+
         |     Length                | P-Type=REC_PROXY_CONTROL  |
         +-------------+-------------+-------------+-------------+
         |              Reserved                   |Control-Value|
         +---------------------------+---------------------------+

              Figure 7: Receiver Proxy Control Policy Element

   where:

   o  Length: 16 bits

      *  Always 8.  The overall length of the policy element, in bytes.

   o  P-Type: 16 bits

      *  REC_PROXY_CONTROL = To be allocated by IANA (see "IANA
         Considerations" section)

   o  Reserved: 24 bits

      *  SHALL be set to zero on transmit and SHALL be ignored on
         reception

   o  Control-Value: 8 bits (unsigned)

      *  0 (Reserved).  An RSVP Receiver Proxy that understands this
         policy element MUST ignore the policy element if its Control-
         Value is set to that value.

      *  1 (Receiver-Proxy-Needed): An Receiver Proxy that understands
         this policy element MUST attempt to insert itself as a Receiver
         Proxy for that flow if the corresponding Path message contains
         this Control-Value.  If the Receiver Proxy also supports
         dynamic discovery of downstream RSVP functionality as specified
         in Section 4.1, it MUST still send the Path message downstream
         and attempt to extend the reservation downstream so that the
         reservation can be extended to the last Receiver Proxy).  An
         RSVP sender MAY insert the Receiver Proxy Control Policy
         Element with this Control-Value when it knows (say by other
         means such as application-level signalling) that the receiver
         is not RSVP capable.

      *  2 (Receiver-Proxy-Not-Needed): An Receiver Proxy that
         understands this policy element MUST NOT attempt to insert
         itself as a Receiver Proxy for that flow if the corresponding



Le Faucheur, et al.     Expires September 9, 2010              [Page 29]

Internet-Draft       RSVP Receiver Proxy Extensions           March 2010


         Path message contains this Control-Value.  An RSVP sender MAY
         insert the Receiver Proxy Control Policy Element with this
         Control-Value when it knows (say by other means such as
         application-level signalling) that the receiver is RSVP
         capable.

   Figure 8 illustrates the method based on the Receiver Proxy Control
   Policy Element and allowing a sender to control whether an RSVP
   router supporting the Path-triggered Receiver Proxy function is to
   behave as a Receiver Proxy for a given flow or not.

      |****|         ***         |**********|   |----|
      | S  |---------*r*---------| RSVP     |---| R1 |
      |****|         ***         | Receiver |   |----|
                                 | Proxy    |
                                 |          |
                                 |          |            |****|
                                 |          |------------| R2 |
                                 |**********|            |****|

           ---Path--->  --Path--->
            (R1/N)      (R1/N)

           <--Resv---  <---Resv---

          ================RSVP===>

          **************************************>



           ---Path--->  --Path--->          ----Path---->
            (R2/NN)      (R2/NN)               (R2/NN)

           <--Resv---  <---Resv---          <----Resv----

          ================RSVP===========================>

          ***********************************************>


   |****| RSVP-capable  |----| non-RSVP-capable  |****| RSVP-capable
   | S  | Sender        | R  | Receiver          | R  | Receiver
   |****|               |----|                   |****|

   ***
   *r* regular RSVP
   *** router



Le Faucheur, et al.     Expires September 9, 2010              [Page 30]

Internet-Draft       RSVP Receiver Proxy Extensions           March 2010


   (R1) = Path message contains a Session object whose destination is R1

   (N)  = Path message contains a Receiver Proxy Control Policy Element
        whose Control-Value is set to Receiver-Proxy-Needed

   (NN) = Path message contains a Receiver Proxy Control Policy Element
        whose Control-Value is set to Receiver-Proxy-Not-Needed

   ***> media flow

   ==>  segment of flow path protected by RSVP reservation


                Figure 8: Receiver Proxy Control by Sender

4.2.1.  Default Handling

   As specified in section 4.2 of [RFC2750], Policy Ignorant Nodes
   (PINs) implement a default handling of POLICY_DATA objects ensuring
   that those objects can traverse PIN nodes in transit from one Policy
   Enforcement Point (PEP) to another.  This applies to the situations
   where POLICY_DATA objects contain the Receiver Proxy Control Policy
   Element specified in this document, so that those can traverse PIN
   nodes.

   Section 4.2 of [RFC2750] also defines a similar default behavior for
   policy-capable nodes that do not recognized a particular Policy
   Element.  This applies to the Receiver Proxy Control Policy Element
   specified in this document, so that those can traverse policy-capable
   nodes that do not support this document.





















Le Faucheur, et al.     Expires September 9, 2010              [Page 31]

Internet-Draft       RSVP Receiver Proxy Extensions           March 2010


5.  Security Considerations

   As this document defines extensions to RSVP, the security
   considerations of RSVP apply.  Those are discussed in [RFC2205],
   [RFC4230] and [I-D.ietf-tsvwg-rsvp-security-groupkeying].  Approaches
   for addressing those concerns are discussed further below.

   The RSVP Authentication mechanisms defined in [RFC2747] and [RFC3097]
   protect RSVP message integrity hop-by-hop and provide node
   authentication as well as replay protection, thereby protecting
   against corruption and spoofing of RSVP messages.  These hop-by-hop
   integrity mechanisms can be used to protect RSVP reservations
   established using an RSVP receiver proxy in accordance with the
   present document.  [I-D.ietf-tsvwg-rsvp-security-groupkeying]
   discusses key types and key provisioning methods as well as their
   respective applicability to RSVP authentication.  RSVP Authentication
   (defined in [RFC2747] and [RFC3097]) SHOULD be supported by an
   implementation of the present document.

   [I-D.ietf-tsvwg-rsvp-security-groupkeying] also discusses
   applicability of IPsec mechanisms ([RFC4302], [RFC4303]) and
   associated key provisioning methods for security protection of RSVP.
   This discussion applies to the protection of RSVP in the presence of
   Path-triggered RSVP Receiver Proxies as defined in the present
   document.

   A subset of RSVP messages are signaled with the router alert option
   ([RFC2113],[RFC2711]).  Based on the current security concerns
   associated with the use of the IP router alert option, the
   applicability of RSVP (and therefore of the RSVP Proxy approaches
   discussed in the present document) is limited to controlled
   environments (i.e.  Environments where the security risks associated
   with the use of the router alert option are understood and protected
   against).  The security aspects and common practices around the use
   of the current IP router alert option and consequences of using the
   IP router alert option by applications such as RSVP are discussed in
   details in [I-D.rahman-rtg-router-alert-considerations].

   When an RSVP receiver proxy is used, the RSVP reservation is no
   longer controlled by the receiver, but rather is controlled by the
   receiver proxy (using hints received from the sender in the Path
   message) on behalf of the sender.  Thus, the receiver proxy ought to
   be trusted by the end-systems to control the RSVP reservation
   appropriately.  However, basic RSVP operation already assumes a trust
   model where end-systems trust RSVP nodes to appropriately perform
   RSVP reservations.  So the use of RSVP receiver proxy is not seen as
   introducing any significant additional security threat or as
   modifying the RSVP trust model.



Le Faucheur, et al.     Expires September 9, 2010              [Page 32]

Internet-Draft       RSVP Receiver Proxy Extensions           March 2010


   In fact, there are situations where the use of RSVP receiver proxy
   reduces the security risks.  One example is where a network operator
   relies on RSVP to perform resource reservation and admission control
   within a network and where RSVP senders and RSVP routers are located
   in the operator premises while the many RSVP receivers are located in
   the operator's customers premises.  Such an environment is further
   illustrated in "Annex A.1.  RSVP-based VoD Admission Control in
   Broadband Aggregation Networks" of
   [I-D.ietf-tsvwg-rsvp-proxy-approaches].  From the operator's
   perspective, the RSVP routers and RSVP senders are in physically
   secured locations and therefore exposed to a lower risk of being
   tampered with; While the receivers are in locations that are
   physically unsecured and therefore subject to a higher risk of being
   tampered with.  The use of an RSVP receiver proxy function
   effectively increases the security of the operator's reservation and
   admission control solution by completely excluding receivers from its
   operation.  Filters can be placed at the edge of the operator network
   discarding any RSVP message received from end-users.  This provides a
   very simple and effective protection of the RSVP reservation and
   admission control solution operating inside the operator's network.

5.1.  Security Considerations for the Sender Notification via Notify
      Message

   This document defines in Section 3.2 an optional method relying on
   the use of the Notify message specified in [RFC3473].  The Notify
   message can be sent in a non-hop-by-hop fashion that precludes use of
   RSVP hop-by-hop integrity and authentication model.  The approaches
   and considerations for addressing this issue presented in the
   Security Considerations section of [RFC3473] apply.  In particular,
   where the Notify messages are transmitted non-hop-by-hop and the same
   level of security provided by [RFC2747] is desired, IPsec-based
   integrity and authentication can be used ([RFC4302] or [RFC4303]).
   Alternatively, the sending of non-hop-by-hop Notify messages can be
   disabled.  Finally, [I-D.ietf-tsvwg-rsvp-security-groupkeying]
   discusses applicability of group keying for non-hop-by-hop Notify
   messages.

5.2.  Security Considerations for the Receiver Proxy Control Policy
      Element

   This document also defines inSection 4.2 the optional Receiver Proxy
   Control Policy Element.  Policy Elements are signaled by RSVP through
   encapsulation in a Policy Data object as defined in [RFC2750].
   Therefore, like any other Policy Elements, the integrity of the
   Receiver Proxy Control Policy Element can be protected as discussed
   in section 6 of [RFC2750] by two optional security mechanisms.




Le Faucheur, et al.     Expires September 9, 2010              [Page 33]

Internet-Draft       RSVP Receiver Proxy Extensions           March 2010


   The first mechanism relies on the RSVP Authentication discussed above
   that provides a chain of trust when all RSVP nodes are policy
   capable.  With this mechanism, the INTEGRITY object is carried inside
   RSVP messages.

   The second mechanism relies on the INTEGRITY object within the
   POLICY_DATA object to guarantee integrity between RSVP Policy
   Enforcement Points (PEPs) that are not RSVP neighbors.  This is
   useful only when some RSVP nodes are Policy Ignorant Nodes (PINs).
   The INTEGRITY object within the POLICY_DATA object MAY be supported
   by an implementation of the present document.

   Details for computation of the content of the INTEGRITY object can be
   found in Appendix B of [RFC2750].  This states that the Policy
   Decision Point (PDP), at its discretion, and based on destination
   PEP/PDP or other criteria, selects an Authentication Key and the hash
   algorithm to be used.  Keys to be used between PDPs can be
   distributed manually or via standard key management protocol for
   secure key distribution.

   Note that where non-RSVP hops may exist in between RSVP hops, as well
   as where RSVP capable Policy Ignorant Nodes (PINs) may exist in
   between PEPs, it may be difficult for the PDP to determine what is
   the destination PDP for a POLICY_DATA object contained in some RSVP
   messages (such as a Path message).  This is because in those cases
   the next PEP is not known at the time of forwarding the message.  In
   this situation, key shared across multiple PDPs may be used.  This is
   conceptually similar to the use of key shared across multiple RSVP
   neighbors discussed in [I-D.ietf-tsvwg-rsvp-security-groupkeying].
   We observe also that this issue may not exist in some deployment
   scenarios where a single (or low number of) PDP is used to control
   all the PEPs of a region (such as an administrative domain).  In such
   scenarios, it may be easy for a PDP to determine what is the next hop
   PDP, even when the next hop PEP is not known, simply by determining
   what is the next region that will be traversed (say based on the
   destination address).















Le Faucheur, et al.     Expires September 9, 2010              [Page 34]

Internet-Draft       RSVP Receiver Proxy Extensions           March 2010


6.  IANA Considerations

6.1.  RSVP Error Codes

   Since, as discussed in Section 3.1.2, this document allows two Error
   Codes to be used in PathErr messages while [RFC2205] only specified
   their use in ResvErr messages, this document requires that IANA
   updates the existing entries for these two Error Codes under the
   "Error Codes and Globally-Defined Error Value Sub-Codes" registry.
   Each entry should refer to this document, in addition to referring to
   [RFC2205].  Specifically, the entry for Error Code 1 and Error Code 2
   should respectively read:

   "

   1 Admission Control Failure [RFC2205] [RFCXXX]

   ...

   2 Policy Control Failure [RFC2205] [RFCXXX]

   ...

   "

   where [RFCXXX] refers to this document.

   This document also requires that IANA allocates a new RSVP Error Code
   "<TBD>: Unrecoverable Receiver Proxy Error", as discussed in
   Section 3.1.2.  This Error Code is to be allocated under the "Error
   Codes and Globally-Defined Error Value Sub-Codes" registry.  The
   entry for this error code should read:

   "

   TBD Unrecoverable Receiver Proxy Error [RFCXXX]

   The sixteen bits of the Error Value field are defined in [RFCXXX]

   "

   where [RFCXXX] refers to this document and TBD is the value to be
   allocated by IANA.

6.2.  Policy Element

   This document defines in Section 4.2 a new Policy Element called the
   Receiver Proxy Control Policy Element.  As specified in [RFC2750],



Le Faucheur, et al.     Expires September 9, 2010              [Page 35]

Internet-Draft       RSVP Receiver Proxy Extensions           March 2010


   Standard RSVP Policy Elements (P-type values) are to be assigned by
   IANA as per "IETF Consensus" policy following the policies outlined
   in [RFC2434] (this policy is now called "IETF Review" as per
   [RFC5226]) .

   Thus, this document requires that IANA allocates one P-Type to the
   Receiver Proxy Control Policy Element from the Standard RSVP Policy
   Element range.

   In Section 4.2, the present document defines a Control-Value field
   inside the Receiver Proxy Control Policy Element.  IANA needs to
   create a registry for this field and allocate the following values:

   o  0 : Reserved

   o  1 : Receiver-Proxy-Needed

   o  2 : Receiver-Proxy-Not-Needed

   Following the policies outlined in [RFC5226], numbers in the range
   3-127 are allocated according to the "IETF Review" policy, numbers in
   the range 128-240 as "First Come First Served" and numbers between
   241-255 are reserved for "Private Use".




























Le Faucheur, et al.     Expires September 9, 2010              [Page 36]

Internet-Draft       RSVP Receiver Proxy Extensions           March 2010


7.  Acknowledgments

   This document benefited from discussions with Carol Iturralde and
   Anca Zamfir.  Lou Berger, Adrian Farrel and John Drake provided
   review and guidance, in particular on the usage of the
   Path_State_Removed flag and of the Notify message, both borrowed from
   [RFC3473].  We also thank Stephen Kent, Ken Carlberg and Tim Polk for
   their valuable input and proposed enhancements.  Finally we thank
   Cullen Jennings, Magnus Westerlund and Robert Sparks for stimulating
   the work on extensions maximizing the reservation span and
   facilitating migration from Proxy model to end-to-end RSVP model.








































Le Faucheur, et al.     Expires September 9, 2010              [Page 37]

Internet-Draft       RSVP Receiver Proxy Extensions           March 2010


8.  References

8.1.  Normative References

   [RFC2113]  Katz, D., "IP Router Alert Option", RFC 2113,
              February 1997.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

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

   [RFC2434]  Narten, T. and H. Alvestrand, "Guidelines for Writing an
              IANA Considerations Section in RFCs", BCP 26, RFC 2434,
              October 1998.

   [RFC2711]  Partridge, C. and A. Jackson, "IPv6 Router Alert Option",
              RFC 2711, October 1999.

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

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

   [RFC3097]  Braden, R. and L. Zhang, "RSVP Cryptographic
              Authentication -- Updated Message Type Value", RFC 3097,
              April 2001.

   [RFC3209]  Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V.,
              and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP
              Tunnels", RFC 3209, December 2001.

   [RFC3473]  Berger, L., "Generalized Multi-Protocol Label Switching
              (GMPLS) Signaling Resource ReserVation Protocol-Traffic
              Engineering (RSVP-TE) Extensions", RFC 3473, January 2003.

   [RFC4302]  Kent, S., "IP Authentication Header", RFC 4302,
              December 2005.

   [RFC4303]  Kent, S., "IP Encapsulating Security Payload (ESP)",
              RFC 4303, December 2005.

   [RFC5226]  Narten, T. and H. Alvestrand, "Guidelines for Writing an
              IANA Considerations Section in RFCs", BCP 26, RFC 5226,
              May 2008.



Le Faucheur, et al.     Expires September 9, 2010              [Page 38]

Internet-Draft       RSVP Receiver Proxy Extensions           March 2010


8.2.  Informative References

   [I-D.ietf-tsvwg-rsvp-proxy-approaches]
              Faucheur, F., Guillou, A., Manner, J., and D. Wing, "RSVP
              Proxy Approaches",
              draft-ietf-tsvwg-rsvp-proxy-approaches-08 (work in
              progress), October 2009.

   [I-D.ietf-tsvwg-rsvp-security-groupkeying]
              Behringer, M. and F. Faucheur, "Applicability of Keying
              Methods for RSVP Security",
              draft-ietf-tsvwg-rsvp-security-groupkeying-05 (work in
              progress), June 2009.

   [I-D.rahman-rtg-router-alert-considerations]
              Faucheur, F., "IP Router Alert Considerations and Usage",
              draft-rahman-rtg-router-alert-considerations-03 (work in
              progress), October 2009.

   [RFC3181]  Herzog, S., "Signaled Preemption Priority Policy Element",
              RFC 3181, October 2001.

   [RFC4230]  Tschofenig, H. and R. Graveman, "RSVP Security
              Properties", RFC 4230, December 2005.



























Le Faucheur, et al.     Expires September 9, 2010              [Page 39]

Internet-Draft       RSVP Receiver Proxy Extensions           March 2010


Authors' Addresses

   Francois Le Faucheur
   Cisco Systems
   Greenside, 400 Avenue de Roumanille
   Sophia Antipolis  06410
   France

   Phone: +33 4 97 23 26 19
   Email: flefauch@cisco.com


   Jukka Manner
   Helsinki University of Technology (TKK)
   P.O. Box 3000
   Espoo  FIN-02015 TKK
   Finland

   Phone: +358 9 451 2481
   Email: jukka.manner@tkk.fi
   URI:   http://www.netlab.tkk.fi/~jmanner/


   Ashok Narayanan
   Cisco Systems
   300 Beaver Brook Road
   Boxborough, MAS  01719
   United States

   Email: ashokn@cisco.com


   Allan Guillou
   SFR
   40-42 Quai du Point du Jour
   Boulogne-Billancourt,   92659
   France

   Email: allan.guillou@sfr.com












Le Faucheur, et al.     Expires September 9, 2010              [Page 40]

Internet-Draft       RSVP Receiver Proxy Extensions           March 2010


   Hemant Malik
   Bharti Airtel Ltd.
   4th Floor, Tower A, Unitech Cyber Park
   Gurgaon, Sector 39,  122001
   India

   Email: Hemant.Malik@airtel.in












































Le Faucheur, et al.     Expires September 9, 2010              [Page 41]


