TSVWG                                                     F. Le Faucheur
Internet-Draft                                                     Cisco
Intended status: Standards Track                               J. Manner
Expires: August 28, 2007                          University of Helsinki
                                                            A. Narayanan
                                                                   Cisco
                                                       February 24, 2007


         RSVP Extensions for Path-Triggered RSVP Receiver Proxy
                draft-ietf-tsvwg-rsvp-proxy-proto-00.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 August 28, 2007.

Copyright Notice

   Copyright (C) The IETF Trust (2007).











Le Faucheur, et al.      Expires August 28, 2007                [Page 1]

 
Internet-Draft       RSVP Receiver Proxy Extensions        February 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 August 28, 2007                [Page 2]

 
Internet-Draft       RSVP Receiver Proxy Extensions        February 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  . . . . . . . . .  9
       3.1.1.  Composition of SESSION and <Sender descriptor> . . . . 12
       3.1.2.  Composition of ERROR_SPEC  . . . . . . . . . . . . . . 12
   4.  Security Considerations  . . . . . . . . . . . . . . . . . . . 14
   5.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 15
   6.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 16
   7.  Normative References . . . . . . . . . . . . . . . . . . . . . 17
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18
   Intellectual Property and Copyright Statements . . . . . . . . . . 19




































Le Faucheur, et al.      Expires August 28, 2007                [Page 3]

 
Internet-Draft       RSVP Receiver Proxy Extensions        February 2007


.  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, however it assumes that both the sender and the
   receiver of the data flow support RSVP.  There are environments where
   it would be useful to be able to reserve resources for a flow on at
   least a subset of the flow path even when the sender or the receiver
   (or both) is not RSVP-capable.

   Since either the data sender or receiver may be unaware of RSVP,
   there are two distinct use cases.  In the first case, an entity in
   the network must operate on behalf of the data sender, generate an
   RSVP Path message, and eventually receive, process and sink a Resv
   message.  We refer to this entity as the RSVP Sender Proxy.  In the
   latter case, an entity in the network must receive a Path message
   sent by a data sender (or by an RSVP Sender Proxy), and reply to it
   with a Resv message 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 synchronised with the application requirements
   (e.g. when to establish, maintain, 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 as the cue for
   establishing the RSVP reservation on behalf of the non-RSVP-capable
   receiver.  The RSVP Receiver Proxy is effectively acting as a slave
   making reservations (on behalf of the receiver) under the sender'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.

   Since the synchronisation between RSVP reservation and application
   requirement is now effectively performed by the sender, it is
   important that the sender 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



Le Faucheur, et al.      Expires August 28, 2007                [Page 4]

 
Internet-Draft       RSVP Receiver Proxy Extensions        February 2007


   state (notably the error message sent in case of admission control
   rejection of the reservation) are only sent to the receiver.  This
   document specifies extension to RSVP procedures allowing such
   notifications to be also conveyed to the sender.  This facilitates
   synchronization by the sender between RSVP reservation and
   application requirements in scenarios involving a Path-Triggered RSVP
   receiver Proxy.

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 August 28, 2007                [Page 5]

 
Internet-Draft       RSVP Receiver Proxy Extensions        February 2007


.  Terminology

   RSVP-capable (or RSVP-aware): which supports the RSVP protocol as per
   [RFC2205]

   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.

   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.

   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.


























Le Faucheur, et al.      Expires August 28, 2007                [Page 6]

 
Internet-Draft       RSVP Receiver Proxy Extensions        February 2007


.  RSVP Extensions for Sender Notification

   This section defines extensions to RSVP procedures allowing
   notification of the sender 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 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 August 28, 2007                [Page 7]

 
Internet-Draft       RSVP Receiver Proxy Extensions        February 2007


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

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

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

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

         <--Resv---> <---Resv----- <--Resv----


 |----| RSVP-capable     |----| Non-RSCP-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
   succesful 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 does 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 August 28, 2007                [Page 8]

 
Internet-Draft       RSVP Receiver Proxy Extensions        February 2007


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

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

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

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

   Section 3.1 defines a method which can be used to achieve sender
   notification of reservation failure.  An implementation of this
   document MUST support the method defined in Section 3.1.

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



Le Faucheur, et al.      Expires August 28, 2007                [Page 9]

 
Internet-Draft       RSVP Receiver Proxy Extensions        February 2007


       reaction to the error code provided in the received ResvErr in
       accordance with local policy)

   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.


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

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

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

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

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

                    ---ResvErr---> --ResvErr--->

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

   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



Le Faucheur, et al.      Expires August 28, 2007               [Page 10]

 
Internet-Draft       RSVP Receiver Proxy Extensions        February 2007


   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.  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
   ResvErrs, also apply for generating sender descriptors in PathErrs.

   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 to the sender in the PathErr any
   POLICY_DATA objects received in the ResvErr.



Le Faucheur, et al.      Expires August 28, 2007               [Page 11]

 
Internet-Draft       RSVP Receiver Proxy Extensions        February 2007


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 <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
   ResvErrs 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>: Unrecoverable Receiver Proxy
       error" and error value "<TBD>".  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 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.  Use



Le Faucheur, et al.      Expires August 28, 2007               [Page 12]

 
Internet-Draft       RSVP Receiver Proxy Extensions        February 2007


       of extensions such as the Notify message defined in [RFC3473] may
       be investigated in the future to address this issue.

















































Le Faucheur, et al.      Expires August 28, 2007               [Page 13]

 
Internet-Draft       RSVP Receiver Proxy Extensions        February 2007


.  Security Considerations

   To be added.
















































Le Faucheur, et al.      Expires August 28, 2007               [Page 14]

 
Internet-Draft       RSVP Receiver Proxy Extensions        February 2007


.  IANA Considerations

   This document requires that IANA allocates a new RSVP Error Code
   "<TBD>: Unrecoverable Receiver Proxy error" as discussed in
   Section 3.1.2.














































Le Faucheur, et al.      Expires August 28, 2007               [Page 15]

 
Internet-Draft       RSVP Receiver Proxy Extensions        February 2007


.  Acknowledgments

   This document benefited from discussions with Carol Iturralde and
   Amca Zamfir.















































Le Faucheur, et al.      Expires August 28, 2007               [Page 16]

 
Internet-Draft       RSVP Receiver Proxy Extensions        February 2007


.  Normative References

   [I-D.ietf-tsvwg-rsvp-proxy-approaches]
              Le Faucheur, L., "RSVP Proxy Approaches", February 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.

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




































Le Faucheur, et al.      Expires August 28, 2007               [Page 17]

 
Internet-Draft       RSVP Receiver Proxy Extensions        February 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 Narayan
   Cisco Systems
   300 Beaver Brook Road
   Boxborough, MAS  01719
   United States

   Email: ashokn@cisco.com





















Le Faucheur, et al.      Expires August 28, 2007               [Page 18]

 
Internet-Draft       RSVP Receiver Proxy Extensions        February 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 August 28, 2007               [Page 19]