[Docs] [txt|pdf] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits] [IPR]

Versions: (draft-lefaucheur-tsvwg-rsvp-proxy) 00 01 02 03 04 05 06 07 08 09 10 11 RFC 5946

TSVWG                                                     F. Le Faucheur
Internet-Draft                                                     Cisco
Intended status: Standards Track                               J. Manner
Expires: April 17, 2008                           University of Helsinki
                                                            A. Narayanan
                                                                   Cisco
                                                              A. Guillou
                                                                    Neuf
                                                                H. Malik
                                                                  Bharti
                                                        October 15, 2007


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

Status of this Memo

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, in accordance with Section 6 of 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."

   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 April 17, 2008.

Copyright Notice

   Copyright (C) The IETF Trust (2007).







Le Faucheur, et al.      Expires April 17, 2008                 [Page 1]

Internet-Draft       RSVP Receiver Proxy Extensions         October 2007


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.


































Le Faucheur, et al.      Expires April 17, 2008                 [Page 2]

Internet-Draft       RSVP Receiver Proxy Extensions         October 2007


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
     1.1.  Conventions Used in This Document  . . . . . . . . . . . .  5
   2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  6
   3.  RSVP Extensions for Sender Notification  . . . . . . . . . . .  7
     3.1.  Sender Notification via PathErr Message  . . . . . . . . . 10
       3.1.1.  Composition of SESSION and <Sender descriptor> . . . . 12
       3.1.2.  Composition of ERROR_SPEC  . . . . . . . . . . . . . . 13
       3.1.3.  Use of Path_State_Removed Flag . . . . . . . . . . . . 14
       3.1.4.  Use of PathErr by Regular Receivers  . . . . . . . . . 15
     3.2.  Sender Notification via Notify Message . . . . . . . . . . 16
   4.  Security Considerations  . . . . . . . . . . . . . . . . . . . 19
   5.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 22
   6.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 23
   7.  Normative References . . . . . . . . . . . . . . . . . . . . . 24
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 25
   Intellectual Property and Copyright Statements . . . . . . . . . . 27

































Le Faucheur, et al.      Expires April 17, 2008                 [Page 3]

Internet-Draft       RSVP Receiver Proxy Extensions         October 2007


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 distinct RSVP Proxy cases.  In the first case, an entity in
   the network must operate on behalf of the data sender, 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 must 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-02.txt].  That document also
   discusses, for each approach, how the reservations controlled by the
   RSVP Proxy can be synchronised 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.  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 synchronisation between RSVP reservation and application
   requirement is now effectively performed by the sender (or RSVP
   Sender Proxy), it is important that the sender (or RSVP Sender Proxy)
   is aware of the reservation state.  However, as conventional RSVP



Le Faucheur, et al.      Expires April 17, 2008                 [Page 4]

Internet-Draft       RSVP Receiver Proxy Extensions         October 2007


   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.  This document specifies extension to RSVP
   procedures allowing such notifications to be also conveyed towards
   the sender.  This facilitates synchronization by the sender (or RSVP
   Sender Proxy) between RSVP reservation and application requirements
   in scenarios involving a Path-Triggered RSVP receiver Proxy.

   This document discusses extension to facilitate operations in the
   presence of an RSVP Receiver Proxy.  As explicitly pointed out in the
   text above, 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.

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 April 17, 2008                 [Page 5]

Internet-Draft       RSVP Receiver Proxy Extensions         October 2007


2.  Terminology

   The following terminology is borrowed from
   [I-D.ietf-tsvwg-rsvp-proxy-approaches-02.txt] 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 which would normally 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.

   o  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 April 17, 2008                 [Page 6]

Internet-Draft       RSVP Receiver Proxy Extensions         October 2007


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-02.txt], 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 Resv message (whose details are discussed below)
       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 April 17, 2008                 [Page 7]

Internet-Draft       RSVP Receiver Proxy Extensions         October 2007


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

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

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

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

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


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


 ***> media flow

 ==>  segment of flow path protected by 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
   only ensure 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 April 17, 2008                 [Page 8]

Internet-Draft       RSVP Receiver Proxy Extensions         October 2007


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

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

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

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

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

                            -ResvErr-> -ResvErr->



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

 ***> media flow

 ==>  segment of flow path protected by 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 which 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 which 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



Le Faucheur, et al.      Expires April 17, 2008                 [Page 9]

Internet-Draft       RSVP Receiver Proxy Extensions         October 2007


   use the method defined in Section 3.1, or the method defined in
   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 April 17, 2008                [Page 10]

Internet-Draft       RSVP Receiver Proxy Extensions         October 2007


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

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

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

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

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

                            -ResvErr-> -ResvErr->

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



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

 ***> media flow

 ==>  segment of flow path protected by RSVP reservation


    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, CAC 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) which triggered generation of Resv messages that failed.
   For Fixed-Filter (FF) style reservations, the Receiver Proxy sends a
   PathErr towards the (single) sender matching the failed reservation.



Le Faucheur, et al.      Expires April 17, 2008                [Page 11]

Internet-Draft       RSVP Receiver Proxy Extensions         October 2007


   For Shared-Explicit (SE) style reservations, the Receiver Proxy sends
   the PathErr(s) towards the set of senders which 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 for
   generating sender descriptors in PathErr messages.

   For Wildcard-Filter (WF) style reservations, it is not possible for
   the receiver to know which sender caused the reservation failure.
   Therefore, the procedures described in this section do not apply to
   WF-style reservations.

   The procedures described in this section apply 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 receivers.  These receivers 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 which 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 which the sender has no control over.  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
   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



Le Faucheur, et al.      Expires April 17, 2008                [Page 12]

Internet-Draft       RSVP Receiver Proxy Extensions         October 2007


   descriptor> corresponding to the failed reservation, into the
   PathErr.  This is equal to the <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 <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 a <flow descriptor> that
   matches a specific sender.  The Receiver Proxy MUST generate a
   PathErr for each ResvErr received, towards the corresponding 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.
       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:





Le Faucheur, et al.      Expires April 17, 2008                [Page 13]

Internet-Draft       RSVP Receiver Proxy Extensions         October 2007


       *  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 minimise
   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.
   This ensures predictable operations in all environments including
   those where some RSVP routers do not understand the
   Path_State_Removed flag.

   Optionally, the RSVP Receiver Proxy MAY support an optional mode that
   can 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.  Where all routers on the
   path of a reservation support the Path_State_Removed flag, its use



Le Faucheur, et al.      Expires April 17, 2008                [Page 14]

Internet-Draft       RSVP Receiver Proxy Extensions         October 2007


   will indeed result in expedited resource release and reduced
   signaling.  However, if there is one (or more) "old" router on the
   path of the reservation that does not support the Path_State_Removed
   flag, its use 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" 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" router will only release its
   Path state 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 most simple single_sender/
      single_receiver reservations, the current receiver-driven model
      reduces signaling load and per-hop RSVP processing by not sending
      any error message to the sender in case of CAC 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 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.




Le Faucheur, et al.      Expires April 17, 2008                [Page 15]

Internet-Draft       RSVP Receiver Proxy Extensions         October 2007


   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 at providing 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 directly to the sender
      without hop-by-hop RSVP processing

   o  ensure that such a notification is only sent to senders which 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 synchronisation 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 more
   sophistication and of a requirement for RSVP routers and senders to
   support the Notify messages and procedures defined in [RFC3473].

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



Le Faucheur, et al.      Expires April 17, 2008                [Page 16]

Internet-Draft       RSVP Receiver Proxy Extensions         October 2007


   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 the address that was included in the Notify Request of the
      received Path message- a.k.a. the sender's address- and not an
      address of the Receiver Proxy.

   As a result, 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 Resv Err code) to the IP address contained in
   the Resv Notify Request object.  Since this address has been set to
   the sender's address by the Receiver Proxy, the Notify message is
   sent to the sender.

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





























Le Faucheur, et al.      Expires April 17, 2008                [Page 17]

Internet-Draft       RSVP Receiver Proxy Extensions         October 2007


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

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

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

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

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

      <------Notify-------
                            -ResvErr-> -ResvErr->



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

 ***> media flow

 ==>  segment of flow path protected by RSVP reservation

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

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

 Notify = Notify message


     Figure 4: Reservation Failure With Sender Notification via 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
   example, CAC failure), the Receiver Proxy MUST generate a Notify
   towards the sender.  The Receiver Proxy MAY additionally generate a
   Notify upon local failures which would not ordinarily cause
   generation of a ResvErr message, such as described in Appendix B of
   [RFC2205].






Le Faucheur, et al.      Expires April 17, 2008                [Page 18]

Internet-Draft       RSVP Receiver Proxy Extensions         October 2007


4.  Security Considerations

   To ensure the integrity of the associated reservation and admission
   control mechanisms, the RSVP Authentication mechanisms defined in
   [RFC2747] and [RFC3097] may be used.  These 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 the RSVP reservations established using an RSVP receiver
   proxy in accordance with the present document.

   [RFC2747] discusses several approaches for key distribution.  First,
   the RSVP Authentication shared keys can be distributed manually.
   This is the base option and its support is mandated for any
   implementation.  However, in some environments, this approach may
   become a burden if keys frequently change over time.  Alternatively,
   a standard key management protocol for secure key distribution can be
   used.  However, existing key distribution protocols may not be
   appropriate in all environments because of the complexity or
   operational burden they involve.

   The use of RSVP Authentication in parts of the network where there
   may be one or more IP hops in between two RSVP neighbors raises an
   additional challenge.  This is because, with some RSVP messages such
   as a Path message, an RSVP router does not know the RSVP next hop for
   that message at the time of forwarding it.  In fact, part of the role
   of a Path message is precisely to discover the RSVP next hop (and to
   dynamically re-discover it when it changes, say because of a routing
   change).  Hence, the RSVP router may not know which security
   association to use when forwarding such a message.  In that
   situation, one approach is to share the same RSVP Authentication
   shared key across all the RSVP routers of a part of the network where
   there may be RSVP neighbors with IP hops in between.  For example,
   all the RSVP routers of an administrative domain (including the
   receiver proxys) could share the same RSVP Authentication key, while
   different per-neighbor keys could be used between any RSVP router
   pair straddling the boundary between two administrative domains that
   have agreed to use RSVP signaling.

   When the same RSVP Authentication shared key is to be shared among
   multiple RSVP neighbors, manual key distribution may be used.  It
   might also be possible, in the future, to adapt a multicast dynamic
   group key distribution method (e.g. from IETF Multicast Security
   Working Group) for dynamic key distribution among RSVP nodes.  This
   is discussed in
   [I-D.behringer-tsvwg-rsvp-security-groupkeying-00.txt].  For
   situations where RSVP is being used for unicast flows across domain
   boundaries, it is not currently clear how one might provide automated



Le Faucheur, et al.      Expires April 17, 2008                [Page 19]

Internet-Draft       RSVP Receiver Proxy Extensions         October 2007


   key management.

   The RSVP Authentication mechanisms do not provide confidentiality.
   If confidentiality is required, IPsec ESP ([RFC4303]) may be used,
   although it imposes the burden of key distribution.  It also faces
   the additional issue discussed for key management above in the case
   where there can be IP hops in between RSVP hops.  In the future,
   confidentiality solutions may be developed for the case where there
   can be IP hops in between RSVP hops, perhaps again by adapting
   confidentiality solutions developed by the IETF MSEC Working Group.
   Such confidentiality solutions for RSVP are outside the scope of this
   document.

   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.

   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 CAC in Broadband
   Aggregation Networks" of
   [I-D.ietf-tsvwg-rsvp-proxy-approaches-02.txt].  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 which 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.

   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 RSVP's



Le Faucheur, et al.      Expires April 17, 2008                [Page 20]

Internet-Draft       RSVP Receiver Proxy Extensions         October 2007


   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, the standard IPsec based
   integrity and authentication can be used.  Alternatively, the sending
   of non-hop-by-hop Notify messages can be disabled.












































Le Faucheur, et al.      Expires April 17, 2008                [Page 21]

Internet-Draft       RSVP Receiver Proxy Extensions         October 2007


5.  IANA Considerations

   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.










Le Faucheur, et al.      Expires April 17, 2008                [Page 22]

Internet-Draft       RSVP Receiver Proxy Extensions         October 2007


6.  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 Ken Carlberg for his complete review of the
   document and suggestions.











































Le Faucheur, et al.      Expires April 17, 2008                [Page 23]

Internet-Draft       RSVP Receiver Proxy Extensions         October 2007


7.  Normative References

   [I-D.behringer-tsvwg-rsvp-security-groupkeying-00.txt]
              Behringer, M. and F. Le Faucheur, "A Framework for RSVP
              Security Using Dynamic Group Keying", July 2007.

   [I-D.ietf-tsvwg-rsvp-proxy-approaches-02.txt]
              Le Faucheur, F., Manner, J., Wing, D., and A. Guillou,
              "RSVP Proxy Approaches", September 2007.

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

   [RFC2747]  Baker, F., Lindell, B., and M. Talwar, "RSVP Cryptographic
              Authentication", RFC 2747, 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.

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

















Le Faucheur, et al.      Expires April 17, 2008                [Page 24]

Internet-Draft       RSVP Receiver Proxy Extensions         October 2007


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
   University of Helsinki
   P.O. Box 68
   University of Helsinki  FIN-00014 University of Helsinki
   Finland

   Phone: +358 9 191 51298
   Email: jmanner@cs.helsinki.fi
   URI:   http://www.cs.helsinki.fi/u/jmanner/


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

   Email: ashokn@cisco.com


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

   Email: allan.guillou@neufcegetel.fr












Le Faucheur, et al.      Expires April 17, 2008                [Page 25]

Internet-Draft       RSVP Receiver Proxy Extensions         October 2007


   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 April 17, 2008                [Page 26]

Internet-Draft       RSVP Receiver Proxy Extensions         October 2007


Full Copyright Statement

   Copyright (C) The IETF Trust (2007).

   This document is subject to the rights, licenses and restrictions
   contained in BCP 78, and except as set forth therein, the authors
   retain all their rights.

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
   THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
   OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
   THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.


Intellectual Property

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   ietf-ipr@ietf.org.


Acknowledgment

   Funding for the RFC Editor function is provided by the IETF
   Administrative Support Activity (IASA).





Le Faucheur, et al.      Expires April 17, 2008                [Page 27]


Html markup produced by rfcmarkup 1.109, available from https://tools.ietf.org/tools/rfcmarkup/