Tech-invite3GPPspaceIETFspace
959493929190898887868584838281807978777675747372717069686766656463626160595857565554535251504948474645444342414039383736353433323130292827262524232221201918171615141312111009080706050403020100
in Index   Prev   Next

RFC 5945

Resource Reservation Protocol (RSVP) Proxy Approaches

Pages: 50
Informational
Part 1 of 3 – Pages 1 to 9
None   None   Next

Top   ToC   RFC5945 - Page 1
Internet Engineering Task Force (IETF)                    F. Le Faucheur
Request for Comments: 5945                                         Cisco
Category: Informational                                        J. Manner
ISSN: 2070-1721                                         Aalto University
                                                                 D. Wing
                                                                   Cisco
                                                              A. Guillou
                                                                     SFR
                                                            October 2010


         Resource Reservation Protocol (RSVP) Proxy Approaches

Abstract

The Resource Reservation Protocol (RSVP) can be used to make end-to- end resource reservations in an IP network in order to guarantee the quality of service required by certain flows. RSVP assumes that both the data sender and receiver of a given flow take part in RSVP signaling. Yet, there are use cases where resource reservation is required, but the receiver, the sender, or both, is not RSVP-capable. This document presents RSVP proxy behaviors allowing RSVP routers to initiate or terminate RSVP signaling on behalf of a receiver or a sender that is not RSVP-capable. This allows resource reservations to be established on a critical subset of the end-to-end path. This document reviews conceptual approaches for deploying RSVP proxies and discusses how RSVP reservations can be synchronized with application requirements, despite the sender, receiver, or both not participating in RSVP. This document also points out where extensions to RSVP (or to other protocols) may be needed for deployment of a given RSVP proxy approach. However, such extensions are outside the scope of this document. Finally, practical use cases for RSVP proxy are described.
Top   ToC   RFC5945 - Page 2
Status of This Memo

   This document is not an Internet Standards Track specification; it is
   published for informational purposes.

   This document is a product of the Internet Engineering Task Force
   (IETF).  It represents the consensus of the IETF community.  It has
   received public review and has been approved for publication by the
   Internet Engineering Steering Group (IESG).  Not all documents
   approved by the IESG are a candidate for any level of Internet
   Standard; see Section 2 of RFC 5741.

   Information about the current status of this document, any errata,
   and how to provide feedback on it may be obtained at
   http://www.rfc-editor.org/info/rfc5945.

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 Simplified 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.
Top   ToC   RFC5945 - Page 3

Table of Contents

1. Introduction ....................................................3 2. RSVP Proxy Behaviors ............................................6 2.1. RSVP Receiver Proxy ........................................6 2.2. RSVP Sender Proxy ..........................................7 3. Terminology .....................................................7 4. RSVP Proxy Approaches ...........................................9 4.1. Path-Triggered Receiver Proxy ..............................9 4.1.1. Mechanisms for Maximizing the Reservation Span .....11 4.2. Path-Triggered Sender Proxy for Reverse Direction .........15 4.3. Inspection-Triggered Proxy ................................18 4.4. STUN-Triggered Proxy ......................................21 4.5. Application_Entity-Controlled Proxy .......................23 4.5.1. Application_Entity-Controlled Sender Proxy Using "RSVP over GRE" ..............................26 4.5.2. Application_Entity-Controlled Proxy via Co-Location 28 4.6. Policy_Server-Controlled Proxy ............................29 4.7. RSVP-Signaling-Triggered Proxy ............................32 4.8. Reachability Considerations ...............................33 5. Security Considerations ........................................34 6. Acknowledgments ................................................36 7. References .....................................................36 7.1. Normative References ......................................36 7.2. Informative References ....................................37 Appendix A. Use Cases for RSVP Proxies ...........................40 A.1. RSVP-Based VoD Admission Control in Broadband Aggregation Networks ......................................40 A.2. RSVP-Based Voice/Video Connection Admission Control (CAC) in Enterprise WAN ...................................43 A.3. RSVP Proxies for Mobile Access Networks ...................44 A.4. RSVP Proxies for Reservations in the Presence of IPsec Gateways ..................................................46

1. Introduction

Guaranteed Quality of Service (QoS) for some applications with tight requirements (such as voice or video) may be achieved by reserving resources in each node on the end-to-end path. The main IETF protocol for these resource reservations is the Resource Reservation Protocol (RSVP), as 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 (for example, from the sender to the network edge, or from edge to edge, or from the network edge to the receiver).
Top   ToC   RFC5945 - Page 4
   Since the data sender or receiver may be unaware of RSVP, there are
   two types of RSVP proxies.  When the sender is not using RSVP, an
   entity in the network must operate on behalf of the data sender, and
   in particular, generate RSVP Path messages, and eventually receive,
   process, and sink Resv messages.  We refer to this entity as the RSVP
   Sender Proxy.  When the receiver is not using RSVP, an entity in the
   network must receive Path messages sent by a data sender (or by an
   RSVP Sender Proxy), sink those, and return Resv messages on behalf of
   the data receiver(s).  We refer to this entity as the RSVP Receiver
   Proxy.  The RSVP proxies need to be on the data path in order to
   establish the RSVP reservation; note, however, that some of the
   approaches described in this document allow the RSVP proxies to be
   controlled/triggered by an off-path entity.

   The flow sender and receiver generally have at least some (if not
   full) awareness of the application producing or consuming that flow.
   Hence, the sender and receiver are in a natural position to
   synchronize the establishment, maintenance, and teardown of the RSVP
   reservation with the application requirements.  Similarly, they are
   in a natural position to determine the characteristics of the
   reservation (bandwidth, QoS service, etc.) that best match the
   application requirements.  For example, before completing the
   establishment of a multimedia session, the endpoints may decide to
   establish RSVP reservations for the corresponding flows.  Similarly,
   when the multimedia session is torn down, the endpoints may decide to
   tear down the corresponding RSVP reservations.  For instance,
   [RFC3312] discusses how RSVP reservations can be very tightly
   synchronized by endpoints that uses the Session Initiation Protocol
   (SIP) ([RFC3261]) for session control.

   When RSVP reservation establishment, maintenance, and teardown are to
   be handled by RSVP proxies on behalf of an RSVP sender or receiver, a
   key challenge for the RSVP proxy is to determine when the RSVP
   reservations need to be established, maintained, and torn down, and
   to determine what the characteristics are (bandwidth, QoS, etc.) of
   the required RSVP reservations matching the application requirements.
   We refer to this problem as the synchronization of RSVP reservations
   with application-level requirements.

   The IETF Next Steps in Signaling (NSIS) working group has specified a
   new QoS signaling protocol: the QoS NSIS Signaling Layer Protocol
   (NSLP) ([RFC5974]).  This protocol also includes the notion of proxy
   operation, and terminating QoS signaling on nodes that are not the
   actual data senders or receivers (see Section 4.8, "Proxy Mode", of
   [RFC5974].  This is the same concept as the proxy operation for RSVP
   discussed in this document.  One difference, though, is that the NSIS
   framework does not consider multicast resource reservations, which
   RSVP provides today.
Top   ToC   RFC5945 - Page 5
   Section 2 introduces the notion of RSVP Sender Proxy and RSVP
   Receiver Proxy.  Section 3 defines useful terminology.  Section 4
   then presents several fundamental RSVP proxy approaches, discussing
   how they achieve the necessary synchronization of RSVP reservations
   with application-level requirements.  Appendix A includes more
   detailed use cases for the proxies in various real-life deployment
   environments.

   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 imposes some topological constraints.  The additional
   operational burden comes in particular from additional configuration
   needed to activate the RSVP proxies and to help them identify for
   which senders/receivers a proxy behavior is required and for which
   senders/receivers it is not (so that an RSVP proxy does not perform
   establishment of reservations on behalf of devices that are capable
   of doing so themselves but would then be prevented -- without
   notification -- from doing so by the RSVP proxy).  The additional
   topological constraints come in particular from the requirement to
   have one RSVP Receiver Proxy on the path from any sender to every
   non-RSVP-capable device (so that a non-RSVP-capable device is always
   taken care of by an RSVP proxy) and the objective to have only one
   such Receiver Proxy on the path from any sender to every non-RSVP-
   capable device (so that an RSVP Receiver Proxy does not short-circuit
   another RSVP Receiver Proxy closer to the non-RSVP-capable device,
   thereby reducing the span of the RSVP reservation and the associated
   benefits).  In the case of the Path-Triggered Receiver Proxy
   approach, the operational burden and topological constraints can be
   significantly alleviated using the mechanisms discussed in
   Section 4.1.1.

   It is also worth noting that RSVP operations on end-systems are
   considerably simpler than on a router, and consequently that RSVP
   implementations on end-systems are very lightweight (particularly
   considering modern end-systems' capabilities, including mobile and
   portable devices).  For example, end-system RSVP implementations are
   reported to only consume low tens of kilobytes of code space.  Hence,
   this document should not be seen as an encouragement to depart from
   the end-to-end RSVP model.  Its purpose 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.
Top   ToC   RFC5945 - Page 6

2. RSVP Proxy Behaviors

This section discusses the two types of proxies: the RSVP Sender Proxy operating on behalf of data senders, and the RSVP Receiver Proxy operating for data receivers. The concepts presented in this document are not meant to deprecate the traditional [RFC2205] RSVP end-to-end model: end-to-end RSVP reservations are still expected to be used whenever possible. However, RSVP proxies are intended to facilitate RSVP deployment where end-to-end RSVP signaling is not possible.

2.1. RSVP Receiver Proxy

With conventional end-to-end RSVP operations, RSVP reservations are controlled by receivers of data. After a data sender has sent an RSVP Path message towards the intended recipient(s), each recipient that requires a reservation generates a Resv message. If, however, a data receiver is not running the RSVP protocol, the last-hop RSVP router will still send the Path message to the data receiver, which will silently drop this message as an IP packet with an unknown protocol number. In order for reservations to be made in such a scenario, one of the RSVP routers on the data path determines that the data receiver will not be participating in the resource reservation signaling and performs RSVP Receiver Proxy functionality on behalf of the data receiver. This is illustrated in Figure 1. Various mechanisms by which the RSVP proxy router can gain the required information are discussed later in the document. |****| *** *** |**********| |----| | S |---------*r*----------*r*---------| RSVP |----------| R | |****| *** *** | Receiver | |----| | Proxy | |**********| ===================RSVP==============> ***********************************************************> |****| RSVP-capable |----| non-RSVP-capable *** | S | Sender | R | Receiver *r* regular RSVP |****| |----| *** router ***> unidirectional media flow ==> segment of flow path protected by RSVP reservation Figure 1: RSVP Receiver Proxy
Top   ToC   RFC5945 - Page 7

2.2. RSVP Sender Proxy

With conventional end-to-end RSVP operations, if a data sender is not running the RSVP protocol, a resource reservation cannot be set up; a data receiver alone cannot reserve resources without Path messages first being received. Thus, even if the data receiver is running RSVP, it still needs some node on the data path to send a Path message towards the data receiver. In that case, an RSVP node on the data path determines that it should generate Path messages to allow the receiver to set up the resource reservation. This node is referred to as the RSVP Sender Proxy and is illustrated in Figure 2. This case presents additional challenges over the Receiver Proxy case, since the RSVP Sender Proxy must be able to generate all the information in the Path message (such as the SENDER_TSPEC object) without the benefit of having previously received any RSVP message. An RSVP Receiver Proxy, by contrast, only needs to formulate an appropriate Resv message in response to an incoming Path message. Mechanisms to operate an RSVP Sender Proxy are discussed later in this document. |----| |**********| *** *** |****| | S |---------| RSVP |---------*r*----------*r*----------| R | |----| | Sender | *** *** |****| | Proxy | |**********| ================RSVP==================> ***********************************************************> |----| non-RSVP-capable |****| RSVP-capable *** | S | Sender | R | Receiver *r* regular RSVP |----| |****| *** router ***> unidirectional media flow ==> segment of flow path protected by RSVP reservation Figure 2: RSVP Sender Proxy

3. Terminology

o On-Path: located on the data path of the actual flow of application data (regardless of where it is located with respect to the application-level signaling path).
Top   ToC   RFC5945 - Page 8
   o  Off-Path: not On-Path.

   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 that would normally be
      performed by an RSVP-capable receiver if end-to-end RSVP signaling
      were 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 would normally be performed by
      an RSVP-capable sender if end-to-end RSVP signaling were 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 that is not behaving
      as an RSVP Receiver Proxy or as an RSVP Sender Proxy.

   o  Application-level signaling: signaling between entities operating
      above the IP layer and that are aware of the QoS requirements for
      actual media flows.  SIP ([RFC3261]) and the Real Time Streaming
      Protocol (RTSP) ([RFC2326]) are examples of application-level
      signaling protocols.  The Session Description Protocol (SDP)
      ([RFC4566]) is an example of a protocol that can be used by the
      application-level signaling protocol and from which some of the
      RSVP reservation parameters (addresses, ports, and bandwidth)
      might be derived.  RSVP is clearly not an application-level
      signaling protocol.

   The roles of the RSVP Receiver Proxy, RSVP Sender Proxy, and regular
   RSVP router are all relative to a given 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.

   Some application-level signaling protocols support negotiation of QoS
   reservations for a media stream.  For example, with [RFC3312],
   resource reservation requirements are explicitly signaled during
   session establishment using SIP and SDP.  Also, [RFC5432] defines a
   mechanism to negotiate which resource reservation mechanism is to be
   used for a particular media stream.  Clearly, these reservation
   negotiation mechanisms can be invoked and operate effectively when
   both ends support RSVP (and obviously RSVP proxies are not used).
   When both ends do not support RSVP (and RSVP proxies are used at both
   ends), these mechanisms will simply not be invoked.  In the case
Top   ToC   RFC5945 - Page 9
   where one end supports RSVP and the other does not (and is helped by
   an RSVP proxy), the application-level signaling entity supporting the
   non-RSVP-capable end might use the reservation negotiation mechanisms
   in such a way that the non-RSVP-capable end (helped by an RSVP proxy)
   appears to the remote end as an RSVP-capable device.  This will
   ensure that the RSVP-capable end is not discouraged from using RSVP
   because the remote end is not RSVP-capable.  In the case of SIP, the
   application-level entity may achieve this by taking advantage of the
   "segmented" status type of [RFC3312] and/or by taking advantage of a
   SIP [RFC3261] Back-to-Back User Agent (B2BUA).



(page 9 continued on part 2)

Next Section