draft-ietf-tsvwg-rsvp-proxy-approaches-00.txt   draft-ietf-tsvwg-rsvp-proxy-approaches-01.txt 
TSVWG F. Le Faucheur TSVWG F. Le Faucheur
Internet-Draft Cisco Internet-Draft Cisco
Intended status: Informational J. Manner Intended status: Informational J. Manner
Expires: August 28, 2007 University of Helsinki Expires: January 10, 2008 University of Helsinki
D. Wing D. Wing
Cisco Cisco
A. Guillou A. Guillou
Neuf Neuf
February 24, 2007 July 9, 2007
RSVP Proxy Approaches RSVP Proxy Approaches
draft-ietf-tsvwg-rsvp-proxy-approaches-00.txt draft-ietf-tsvwg-rsvp-proxy-approaches-01.txt
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware 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 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. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 39 skipping to change at page 1, line 39
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on August 28, 2007. This Internet-Draft will expire on January 10, 2008.
Copyright Notice Copyright Notice
Copyright (C) The IETF Trust (2007). Copyright (C) The IETF Trust (2007).
Abstract Abstract
RSVP signaling can be used to make end-to-end resource reservations 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 in an IP network in order to guarantee the Quality of Service
flows. With conventional RSVP, both the data sender and receiver of required by certain flows. With conventional RSVP, both the data
a given flow take part in RSVP signaling. Yet, there are many use sender and receiver of a given flow take part in RSVP signaling.
cases where resource reservation is required, but the receiver, the Yet, there are many use cases where resource reservation is required,
sender, or both, is not RSVP-capable. This document presents RSVP but the receiver, the sender, or both, is not RSVP-capable. This
Proxy behaviors allowing RSVP routers to perform RSVP signaling on document presents RSVP Proxy behaviors allowing RSVP routers to
behalf of a receiver or a sender that is not RSVP-capable. This perform RSVP signaling on behalf of a receiver or a sender that is
allows resource reservations to be established on parts of the end- not RSVP-capable. This allows resource reservations to be
to-end path. This document reviews conceptual approaches for established on critical parts of the end-to-end path. This document
deploying RSVP Proxies and discusses how those can synchronize RSVP reviews conceptual approaches for deploying RSVP Proxies and
reservations with application requirements. This document also discusses how RSVP reservations can be synchronized with application
points out where extensions to RSVP (or to other protocols) may be requirements, despite the sender, receiver, or both not participating
needed for deployment of a given RSVP Proxy approach. However, such in RSVP. This document also points out where extensions to RSVP (or
extensions are outside the scope of this document. Finally, to other protocols) may be needed for deployment of a given RSVP
practical use cases for RSVP Proxy are described. Proxy approach. However, such extensions are outside the scope of
this document. Finally, practical use cases for RSVP Proxy are
described.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. RSVP Proxy Behaviors . . . . . . . . . . . . . . . . . . . . . 4 2. RSVP Proxy Behaviors . . . . . . . . . . . . . . . . . . . . . 5
2.1. RSVP Receiver Proxy . . . . . . . . . . . . . . . . . . . 4 2.1. RSVP Receiver Proxy . . . . . . . . . . . . . . . . . . . 5
2.2. RSVP Sender Proxy . . . . . . . . . . . . . . . . . . . . 5 2.2. RSVP Sender Proxy . . . . . . . . . . . . . . . . . . . . 6
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 7
4. RSVP Proxy Approaches . . . . . . . . . . . . . . . . . . . . 7 4. RSVP Proxy Approaches . . . . . . . . . . . . . . . . . . . . 8
4.1. Path-Triggered Receiver Proxy . . . . . . . . . . . . . . 7 4.1. Path-Triggered Receiver Proxy . . . . . . . . . . . . . . 8
4.2. Path-Triggered Sender Proxy for Reverse Direction . . . . 10 4.2. Path-Triggered Sender Proxy for Reverse Direction . . . . 10
4.3. Inspection-Triggered Proxy . . . . . . . . . . . . . . . . 13 4.3. Inspection-Triggered Proxy . . . . . . . . . . . . . . . . 13
4.4. STUN-Triggered Proxy . . . . . . . . . . . . . . . . . . . 15 4.4. STUN-Triggered Proxy . . . . . . . . . . . . . . . . . . . 15
4.5. Application-Signaling-Triggered On-Path Proxy . . . . . . 17 4.5. Application_Entity-Controlled Proxy . . . . . . . . . . . 17
4.6. Application-Signaling-Triggered Off-Path Source Proxy . . 21 4.5.1. Application_Entity-Controlled Sender Proxy using
4.7. RSVP-Signaling-Triggered Proxy . . . . . . . . . . . . . . 23 "RSVP over GRE" . . . . . . . . . . . . . . . . . . . 19
4.8. Other Approaches . . . . . . . . . . . . . . . . . . . . . 24 4.5.2. Application_Entity-Controlled Proxy via Co-Location . 21
5. Security Considerations . . . . . . . . . . . . . . . . . . . 24 4.6. Policy_Server-Controlled Proxy . . . . . . . . . . . . . . 22
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25 4.7. RSVP-Signaling-Triggered Proxy . . . . . . . . . . . . . . 25
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 25 4.8. Endsystem-Controlled Proxy . . . . . . . . . . . . . . . . 26
8. Informative References . . . . . . . . . . . . . . . . . . . . 25 5. Security Considerations . . . . . . . . . . . . . . . . . . . 26
Appendix A. Use Cases for RSVP Proxies . . . . . . . . . . . . . 27 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27
A.1. RSVP-based VoD CAC in Broadband Aggregation Networks . . . 27 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 27
A.2. RSVP-based Voice/Video CAC in Enterprise WAN . . . . . . . 31 8. Informative References . . . . . . . . . . . . . . . . . . . . 28
A.3. RSVP-based Voice CAC in TSP Domain . . . . . . . . . . . . 33 Appendix A. Use Cases for RSVP Proxies . . . . . . . . . . . . . 29
A.4. RSVP Proxies for Mobile Access Networks . . . . . . . . . 34 A.1. RSVP-based VoD CAC in Broadband Aggregation Networks . . . 29
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 35 A.2. RSVP-based Voice/Video CAC in Enterprise WAN . . . . . . . 33
Intellectual Property and Copyright Statements . . . . . . . . . . 37 A.3. RSVP-based Voice CAC in Telephony Service Provider Core . 34
A.4. RSVP Proxies for Mobile Access Networks . . . . . . . . . 36
A.5. RSVP Proxies for Reservations in the presence of IPsec
Gateways . . . . . . . . . . . . . . . . . . . . . . . . . 38
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 41
Intellectual Property and Copyright Statements . . . . . . . . . . 43
1. Introduction 1. Introduction
Guaranteed QoS for some applications with tight QoS requirements may Guaranteed Quality of Service (QoS) for some applications with tight
be achieved by reserving resources in each node on the end-to-end requirements (such as voice or video) may be achieved by reserving
path. The main IETF protocol for these resource reservations is resources in each node on the end-to-end path. The main IETF
RSVP, specified in [RFC2205]. RSVP does not require that all protocol for these resource reservations is RSVP, specified in
intermediate nodes support RSVP, however it assumes that both the [RFC2205]. RSVP does not require that all intermediate nodes support
sender and the receiver of the data flow support RSVP. There are RSVP, however it assumes that both the sender and the receiver of the
environments where it would be useful to be able to reserve resources data flow support RSVP. There are environments where it would be
for a flow on at least a subset of the flow path even when the sender useful to be able to reserve resources for a flow on at least a
or the receiver (or both) is not RSVP capable. subset of the flow path even when the sender or the receiver (or
both) is not RSVP capable.
Since the data sender or receiver may be unaware of RSVP, there are Since the data sender or receiver may be unaware of RSVP, there are
two scenarios. In the first case, an entity in the network must two scenarios. In the first case, an entity in the network must
operate on behalf of the data sender, generate an RSVP Path message, operate on behalf of the data sender, and in particular, generate
and eventually receive, process and sink a Resv message. We refer to RSVP Path messages, and eventually receive, process and sink Resv
this entity as the RSVP Sender Proxy. In the latter case, an entity messages. We refer to this entity as the RSVP Sender Proxy. In the
in the network must receive a Path message sent by a data sender (or latter case, an entity in the network must receive Path messages sent
by an RSVP Sender Proxy), and reply to it with a Resv message on by a data sender (or by an RSVP Sender Proxy), sink those, and return
behalf of the data receiver(s). We refer to this entity as the RSVP Resv messages on behalf of the data receiver(s). We refer to this
Receiver Proxy. entity as the RSVP Receiver Proxy.
The flow sender and receiver generally have at least some (if not The flow sender and receiver generally have at least some (if not
full) awareness of the application producing or consuming that flow. full) awareness of the application producing or consuming that flow.
Hence, the sender and receiver are in a natural position to Hence, the sender and receiver are in a natural position to
synchronize the establishment, maintenance and tear down of the RSVP synchronize the establishment, maintenance and tear down of the RSVP
reservation with the application requirements and to determine the reservation with the application requirements. Similarly they are in
characteristics of the reservation (bandwidth, QoS service,...) which a natural position to determine the characteristics of the
best match the application requirements. For example, before reservation (bandwidth, QoS service,...) which best match the
completing the establishment of a multimedia session, the endpoints application requirements. For example, before completing the
may decide to establish RSVP reservations for the corresponding establishment of a multimedia session, the endpoints may decide to
flows. Similarly, when the multimedia session is torn down, the establish RSVP reservations for the corresponding flows. Similarly,
endpoints may decide to tear down the corresponding RSVP when the multimedia session is torn down, the endpoints may decide to
reservations. For example, [RFC3312] discusses how RSVP reservations tear down the corresponding RSVP reservations. For instance,
can be very tightly synchronised by SIP endpoints with SIP session [RFC3312] discusses how RSVP reservations can be very tightly
control and SIP signaling. synchronized by SIP endpoints with SIP session control and SIP
signaling.
When RSVP reservation establishment, maintenance and tear down is to When RSVP reservation establishment, maintenance and tearing down is
be handled by RSVP Proxy devices on behalf of an RSVP sender or 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 receiver, a key challenge for the RSVP Proxy is to determine when the
RSVP reservations need to be established, maintained and torn down RSVP reservations need to be established, maintained and torn down
and to determine what are the characteristics (bandwidth, QoS and to determine what are the characteristics (bandwidth, QoS
Service,...) of the required RSVP reservations matching the Service,...) of the required RSVP reservations matching the
application requirements. We refer to this problem as the application requirements. We refer to this problem as the
synchronization of RSVP reservations with application level synchronization of RSVP reservations with application level
requirements. requirements.
The IETF Next Steps in Signaling (NSIS) working group is designing, The IETF Next Steps in Signaling (NSIS) working group is designing,
as one their many charter items, a new QoS signaling protocol. This as one their charter items, a new QoS signaling protocol. This
scheme already includes the notion of proxy operation, and scheme already includes the notion of proxy operation, and
terminating QoS signaling on nodes that are not the actual data terminating QoS signaling on nodes that are not the actual data
senders or receivers. This is the same concept as the proxy senders or receivers. This is the same concept as the proxy
operation for RSVP discussed in this document. One difference though operation for RSVP discussed in this document. One difference though
is that the NSIS framework does not consider multicast resource is that the NSIS framework does not consider multicast resource
reservations, which RSVP provides today. reservations, which RSVP provides today.
The next two sections introduce the notion of RSVP Sender Proxy and The next section introduces the notion of RSVP Sender Proxy and RSVP
RSVP receiver Proxy. The following section defines useful Receiver Proxy. The following section defines useful terminology.
terminology. The subsequent section then presents several The subsequent section then presents several fundamental RSVP Proxy
fundamental RSVP Proxy approaches insisting on how they achieve the approaches insisting on how they achieve the necessary
synchronization of RSVP reservations with application level synchronization of RSVP reservations with application level
requirements. Appendix A includes more detailed use cases for the requirements. Appendix A includes more detailed use cases for the
proxies in various deployment environments. proxies in various real life deployment environments.
2. RSVP Proxy Behaviors 2. RSVP Proxy Behaviors
This section discusses the two types of proxies; the RSVP Sender This section discusses the two types of proxies; the RSVP Sender
Proxy operating on behalf of data senders, and the RSVP Receiver Proxy operating on behalf of data senders, and the RSVP Receiver
Proxy operating for data receivers. The concepts presented in this Proxy operating for data receivers. The concepts presented in this
document are not meant to replace the standard RSVP and end-to-end document are not meant to replace the standard RSVP and end-to-end
RSVP reservations are still expected to be used whenever possible. RSVP reservations are still expected to be used whenever possible.
However, RSVP Proxies are intended to facilitate RSVP deployment However, RSVP Proxies are intended to facilitate RSVP deployment
where end-to-end RSVP signaling is not possible. where end-to-end RSVP signaling is not possible.
skipping to change at page 4, line 46 skipping to change at page 5, line 48
receiver is not running the RSVP protocol, the last hop RSVP router receiver is not running the RSVP protocol, the last hop RSVP router
will still send the Path message to the data receiver, which will will still send the Path message to the data receiver, which will
silently drop this message as an IP packet with an unknown protocol silently drop this message as an IP packet with an unknown protocol
number. number.
In order for reservations to be made in such a scenario, one of the In order for reservations to be made in such a scenario, one of the
RSVP routers on the data path must somehow know that the data RSVP routers on the data path must somehow know that the data
receiver will not be participating in the resource reservation receiver will not be participating in the resource reservation
signaling. This RSVP router should, thus, perform RSVP Receiver signaling. This RSVP router should, thus, perform RSVP Receiver
Proxy functionality on behalf of the data receiver. This is Proxy functionality on behalf of the data receiver. This is
illustrated in the figure below. Various mechanisms by which the illustrated in Figure 1. Various mechanisms by which the RSVP proxy
RSVP proxy router can gain the required information are discussed router can gain the required information are discussed later in the
later in the document. document.
|----| *** *** |----------| |----| |----| *** *** |----------| |----|
| S |---------*r*----------*r*---------| RSVP |----------| R | | S |---------*r*----------*r*---------| RSVP |----------| R |
|----| *** *** | Receiver | |----| |----| *** *** | Receiver | |----|
| Proxy | | Proxy |
|----------| |----------|
*************************************************************> ===================RSVP==============>
===================RSVP======================> ***********************************************************>
|----| RSVP-capable |----| non-RSVP-capable *** |----| RSVP-capable |----| non-RSVP-capable ***
| S | Sender | R | Receiver *r* regular RSVP | S | Sender | R | Receiver *r* regular RSVP
|----| |----| *** router |----| |----| *** router
***> unidirectional media flow ***> unidirectional media flow
==> segment of flow path protected by RSVP reservation ==> segment of flow path protected by RSVP reservation
Figure 1: RSVP Receiver Proxy Figure 1: RSVP Receiver Proxy
2.2. RSVP Sender Proxy 2.2. RSVP Sender Proxy
With conventional RSVP operations, If a data sender is not running With conventional RSVP operations, if a data sender is not running
the RSVP protocol, a resource reservation can not be set up; a data the RSVP protocol, a resource reservation can not be set up; a data
receiver can not alone reserve resources without Path messages first receiver can not alone reserve resources without Path messages first
being sent. Thus, even if the data receiver is running RSVP, it 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 still needs some node on the data path to send a Path message towards
the data receiver. the data receiver.
In that case, in a similar manner to the RSVP Receiver Proxy In that case, an RSVP node on the data path must somehow know that it
described before, an RSVP node on the data path must somehow know should generate Path messages to allow the receiver to set up the
that it should generate a Path message for setting up a resource resource reservation. This node is referred to as the RSVP Sender
reservation. This case is more complex than the Receiver Proxy, Proxy and is illustrated in Figure 2. This case is more complex than
since the RSVP Sender Proxy must be able to generate all the the Receiver Proxy case, since the RSVP Sender Proxy must be able to
information in the Path message (such as the Sender TSpec) without generate all the information in the Path message (such as the Sender
the benefit of having previously seen any RSVP messages. An RSVP TSpec) without the benefit of having previously received any RSVP
Receiver Proxy, by contrast only needs to formulate an appropriate message. An RSVP Receiver Proxy, by contrast only needs to formulate
Resv message in response to an incoming Path message. Mechanisms to an appropriate Resv message in response to an incoming Path message.
operate an RSVP Sender Proxy are discussed later in this document. Mechanisms to operate an RSVP Sender Proxy are discussed later in
this document.
|----| |----------| *** *** |----| |----| |----------| *** *** |----|
| S |---------| RSVP |---------*r*----------*r*----------| R | | S |---------| RSVP |---------*r*----------*r*----------| R |
|----| | Sender | *** *** |----| |----| | Sender | *** *** |----|
| Proxy | | Proxy |
|----------| |----------|
*************************************************************> ================RSVP==================>
================RSVP======================> ***********************************************************>
|----| non-RSVP-capable |----| RSVP-capable *** |----| non-RSVP-capable |----| RSVP-capable ***
| S | Sender | R | Receiver *r* regular RSVP | S | Sender | R | Receiver *r* regular RSVP
|----| |----| *** router |----| |----| *** router
***> unidirectional media flow ***> unidirectional media flow
==> segment of flow path protected by RSVP reservation ==> segment of flow path protected by RSVP reservation
Figure 2: RSVP Sender Proxy Figure 2: RSVP Sender Proxy
3. Terminology 3. Terminology
On-Path: located on the datapath of the actual flow of data from the On-Path: located on the datapath of the actual flow of application
application (regardless of where it is located on the application data (regardless of where it is located with respect to the
level signaling path) application level signaling path).
Off-Path: not On-Path Off-Path: not On-Path.
RSVP-capable (or RSVP-aware): which supports the RSVP protocol as per RSVP-capable (or RSVP-aware): which supports the RSVP protocol as per
[RFC2205] [RFC2205].
RSVP Receiver Proxy: an RSVP capable router performing, on behalf of RSVP Receiver Proxy: an RSVP capable router performing, on behalf of
a receiver, the RSVP operations which would normally be performed by a receiver, the RSVP operations which would normally be performed by
an RSVP-capable receiver if end-to-end RSVP signaling was used. Note 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 that while RSVP is used upstream of the RSVP Receiver Proxy, RSVP is
not used downstream of the RSVP Receiver Proxy. not used downstream of the RSVP Receiver Proxy.
RSVP Sender Proxy: an RSVP capable router performing, on behalf of a RSVP Sender Proxy: an RSVP capable router performing, on behalf of a
sender, the RSVP operations which would normally be performed by an sender, the RSVP operations which would normally be performed by an
RSVP-capable sender if end-to-end RSVP signaling was used. Note that RSVP-capable sender if end-to-end RSVP signaling was used. Note that
skipping to change at page 7, line 20 skipping to change at page 8, line 19
yet another flow. yet another flow.
Application level signaling: signaling between entities operating Application level signaling: signaling between entities operating
above the IP layer and which are aware of the QoS requirements for above the IP layer and which are aware of the QoS requirements for
actual media flows. SIP and RTSP are examples of application level actual media flows. SIP and RTSP are examples of application level
signaling protocol. RSVP is clearly not an application level signaling protocol. RSVP is clearly not an application level
signaling. signaling.
4. RSVP Proxy Approaches 4. RSVP Proxy Approaches
This section specifies several fundamental RSVP Proxy approaches. This section discusses several fundamental RSVP Proxy approaches.
4.1. Path-Triggered Receiver Proxy 4.1. Path-Triggered Receiver Proxy
In this approach, it is assumed that the sender is RSVP capable and In this approach, it is assumed that the sender is RSVP capable and
takes full care of the synchronisation between application takes full care of the synchronization between application
requirements and RSVP reservations. With this approach, the RSVP requirements and RSVP reservations. With this approach, the RSVP
Receiver Proxy uses the RSVP Path messages generated by the sender as Receiver Proxy uses the RSVP Path messages generated by the sender as
the cue for establishing the RSVP reservation on behalf of the the cue for establishing the RSVP reservation on behalf of the
receiver. The RSVP Receiver Proxy is effectively acting as a slave receiver. The RSVP Receiver Proxy is effectively acting as a slave
making reservations (on behalf of the receiver) under the sender's making reservations (on behalf of the receiver) under the sender's
control. This changes somewhat the usual RSVP reservation model control. This changes somewhat the usual RSVP reservation model
where reservations are normally controlled by receivers. Such a where reservations are normally controlled by receivers. Such a
change greatly facilitates operations in the scenario of interest change greatly facilitates operations in the scenario of interest
here, which is where the receiver is not RSVP capable. Indeed it here, which is where the receiver is not RSVP capable. Indeed it
allows the RSVP Receiver Proxy to remain application unaware by allows the RSVP Receiver Proxy to remain application unaware by
skipping to change at page 8, line 19 skipping to change at page 9, line 17
periodic refreshes of the Resv message and tearing down the periodic refreshes of the Resv message and tearing down the
reservation if the Path state is torn down. reservation if the Path state is torn down.
In order to build the Resv message, the RSVP Receiver Proxy can take In order to build the Resv message, the RSVP Receiver Proxy can take
into account information received in the Path message. For example, into account information received in the Path message. For example,
the RSVP Receiver Proxy may compose a FLOWSPEC object for the Resv the RSVP Receiver Proxy may compose a FLOWSPEC object for the Resv
message which mirrors the SENDER_TSPEC object in the received Path message which mirrors the SENDER_TSPEC object in the received Path
message. message.
Operation of the Path-Triggered Receiver Proxy in the case of a Operation of the Path-Triggered Receiver Proxy in the case of a
successful reservation is illustrated in the Figure below. successful reservation is illustrated in Figure 3.
|----| *** *** |----------| |----| |----| *** *** |----------| |----|
| S |---------*r*----------*r*---------| RSVP |----------| R | | S |---------*r*----------*r*---------| RSVP |----------| R |
|----| *** *** | Receiver | |----| |----| *** *** | Receiver | |----|
| Proxy | | Proxy |
|----------| |----------|
*************************************************************>
===================RSVP======================>
---Path---> ----Path----> ---Path----> ---Path---> ----Path----> ---Path---->
<--Resv---> <---Resv----- <--Resv---- <--Resv---> <---Resv----- <--Resv----
|----| RSVP-capable |----| Non-RSCP-capable *** ==================RSVP===============>
**********************************************************>
|----| RSVP-capable |----| Non-RSVP-capable ***
| S | Sender | R | Receiver *r* regular RSVP | S | Sender | R | Receiver *r* regular RSVP
|----| |----| *** router |----| |----| *** router
***> media flow ***> media flow
==> segment of flow path protected by RSVP reservation ==> segment of flow path protected by RSVP reservation
Figure 3: Path-Triggered RSVP Receiver Proxy Figure 3: Path-Triggered RSVP Receiver Proxy
In case the reservation establishment is rejected (for example In case the reservation establishment is rejected (for example
because of an admission control failure on a regular RSVP router on because of an admission control failure on a regular RSVP router on
the path between the RSVP-capable sender and the RSVP Receiver the path between the RSVP-capable sender and the RSVP Receiver
Proxy), a ResvErr message will be generated as per conventional RSVP Proxy), a ResvErr message will be generated as per conventional RSVP
operations and will travel downstream towards the RSVP Receiver operations and will travel downstream towards the RSVP Receiver
Proxy. While this ensures that the RSVP Receiver Proxy is aware of Proxy. While this ensures that the RSVP Receiver Proxy is aware of
the reservation failure, conventional RSVP procedures do not cater the reservation failure, conventional RSVP procedures do not cater
for notification of the sender of the reservation failure. Operation for notification of the sender of the reservation failure. Operation
of the Path-Triggered RSVP Receiver Proxy in the case of an admission of the Path-Triggered RSVP Receiver Proxy in the case of an admission
control failure is illustrated in the Figure below. control failure is illustrated in Figure 4.
|----| *** *** |----------| |----| |----| *** *** |----------| |----|
| S |---------*r*----------*r*---------| RSVP |----------| R | | S |---------*r*----------*r*---------| RSVP |----------| R |
|----| *** *** | Receiver | |----| |----| *** *** | Receiver | |----|
| Proxy | | Proxy |
|----------| |----------|
*************************************************************>
===================RSVP======================>
---Path---> ----Path----> ---Path----> ---Path---> ----Path----> ---Path---->
<---Resv----- <--Resv------ <---Resv----- <--Resv------
---ResvErr---> --ResvErr---> ---ResvErr---> --ResvErr--->
|----| RSVP-capable |----| Non-RSCP-capable *** ===================RSVP===============>
**********************************************************>
|----| RSVP-capable |----| Non-RSVP-capable ***
| S | Sender | R | Receiver *r* regular RSVP | S | Sender | R | Receiver *r* regular RSVP
|----| |----| *** router |----| |----| *** router
***> media flow ***> media flow
==> segment of flow path protected by RSVP reservation ==> segment of flow path protected by RSVP reservation
Figure 4: Path-Triggered RSVP Receiver Proxy with Failure Figure 4: Path-Triggered RSVP Receiver Proxy with Failure
Since, as explained above, in this scenario involving the RSVP Since, as explained above, in this scenario involving the RSVP
Receiver Proxy, synchronisation between application and RSVP Receiver Proxy, synchronization between application and RSVP
reservation is generally performed by the sender, notifying the reservation is generally performed by the sender, notifying the
sender of reservation failure is needed. sender of reservation failure is needed.
[I-D.ietf-tsvwg-rsvp-proxy-proto] specifies RSVP extensions allowing [I-D.ietf-tsvwg-rsvp-proxy-proto] specifies RSVP extensions allowing
such sender notification in case of reservation failure. such sender notification in case of reservation failure in the
presence of a Path-Triggered RSVP Receiver Proxy.
4.2. Path-Triggered Sender Proxy for Reverse Direction 4.2. Path-Triggered Sender Proxy for Reverse Direction
In this approach, it is assumed that one endpoint is RSVP capable and In this approach, it is assumed that one endpoint is RSVP capable and
takes full care of the synchronisation between application takes full care of the synchronization between application
requirements and RSVP reservations. This endpoint is the sender for requirements and RSVP reservations. This endpoint is the sender for
one flow direction (which we refer to as the "forward" direction) and one flow direction (which we refer to as the "forward" direction) and
is the receiver for the flow in the opposite direction (which we is the receiver for the flow in the opposite direction (which we
refer to as the "reverse" direction). refer to as the "reverse" direction).
With the Path-Triggered Sender Proxy for Reverse Direction approach, With the Path-Triggered Sender Proxy for Reverse Direction approach,
the RSVP Proxy uses the RSVP signaling generated by the sender as the the RSVP Proxy uses the RSVP signaling generated by the sender as the
cue for initiating RSVP signaling for the reservation in the reverse cue for initiating RSVP signaling for the reservation in the reverse
direction. Thus, the RSVP Proxy is effectively acting as a Sender direction. Thus, the RSVP Proxy is effectively acting as a Sender
Proxy for the reverse direction under the control of the sender for Proxy for the reverse direction under the control of the sender for
the forward direction. Note that this assumes a degree of symmetry the forward direction. Note that this assumes a degree of symmetry
for the two directions of the flow (as is currently typical for IP for the two directions of the flow (as is currently typical for IP
telephony, for example). telephony, for example). This is illustrated in Figure 5.
This is illustrated in the Figure below.
|----| *** *** |----------| |----| |----| *** *** |----------| |----|
| E |---------*r*----------*r*---------| RSVP |----------| E | | R |---------*r*----------*r*---------| RSVP |----------| S |
|----| *** *** | Sender | |----| |----| *** *** | Sender | |----|
| Proxy | | Proxy |
|----------| |----------|
*************************************************************>
<===================RSVP======================
---Path---> ----Path----> ---Path----> ---Path---> ----Path----> ---Path---->
<--Path---> <---Path----- <--Path---- <--Path---> <---Path----- <--Path----
---Resv---> ----Resv----> ---Resv----> ---Resv---> ----Resv----> ---Resv---->
|----| *** <================RSVP==================
| E | Endpoint *r* regular RSVP
|----| *** router <**********************************************************
|----| RSVP-capable |----| Non-RSVP-capable ***
| R | Receiver | S | Sender *r* regular RSVP
|----| |----| *** router
***> media flow ***> media flow
==> segment of flow path protected by RSVP reservation ==> segment of flow path protected by RSVP reservation
in reverse direction in reverse direction
Figure 5: Path-Triggered Sender Proxy for Reverse Direction Figure 5: Path-Triggered Sender Proxy for Reverse Direction
Of course, the RSVP Proxy may simultaneously (and typically will) Of course, the RSVP Proxy may simultaneously (and typically will)
also act as the Path-Triggered Receiver Proxy for the forward also act as the Path-Triggered Receiver Proxy for the forward
direction, as defined in Section 4.1. Such an approach is most direction, as defined in Section 4.1. Such an approach is most
useful in situations involving RSVP reservations in both directions useful in situations involving RSVP reservations in both directions
for symmetric flows. This is illustrated in the Figure below for symmetric flows. This is illustrated in Figure 6.
|----| *** *** |----------| |----| |----| *** *** |----------| |----|
| E |---------*r*----------*r*---------| RSVP |----------| E | |S/R |---------*r*----------*r*---------| RSVP |----------|S/R&|
|----| *** *** | Receiver | |----| |----| *** *** | Receiver | |----|
| & Sender | | & Sender |
| Proxy | | Proxy |
|----------| |----------|
*************************************************************>
<===================RSVP=====================>
---Path---> ----Path----> ---Path----> ---Path---> ----Path----> ---Path---->
<--Resv---> <---Resv----- <--Resv---- <--Resv---> <---Resv----- <--Resv----
<--Path---> <---Path----- <--Path---- <--Path---> <---Path----- <--Path----
---Resv---> ----Resv----> ---Resv----> ---Resv---> ----Resv----> ---Resv---->
|----| *** ================RSVP==================>
| E | Endpoint *r* regular RSVP <================RSVP==================
|----| *** router
<***> media flow **********************************************************>
<**********************************************************
<==> segment of flow path protected by RSVP reservation |----| RSVP-capable |----| Non-RSVP-capable ***
|S/R | Sender and |S/R&| Sender and *r* regular RSVP
|----| Receiver |----| Receiver *** router
***> media flow
==> segment of flow path protected by RSVP reservation
in forward and in reverse direction in forward and in reverse direction
Figure 6: Path Triggered Receiver & Sender Proxy Figure 6: Path Triggered Receiver & Sender Proxy
With the Path-Triggered Sender Proxy for Reverse Direction approach, With the Path-Triggered Sender Proxy for Reverse Direction approach,
the RSVP router may be configurable to use receipt of a regular RSVP the RSVP router may be configurable to use receipt of a regular RSVP
Path message as the trigger for Sender Proxy for Reverse Direction Path message as the trigger for Sender Proxy for Reverse Direction
behavior. behavior.
On receipt of the RSVP Path message for the forward direction, the On receipt of the RSVP Path message for the forward direction, the
skipping to change at page 13, line 17 skipping to change at page 13, line 18
RSVP Sender Proxy can take into account information in the received RSVP Sender Proxy can take into account information in the received
Path message for the forward direction. For example, the RSVP Sender Path message for the forward direction. For example, the RSVP Sender
Proxy may mirror the SENDER_TSPEC object in the received Path Proxy may mirror the SENDER_TSPEC object in the received Path
message. message.
We observe that this approach does not require any extensions to the We observe that this approach does not require any extensions to the
existing RSVP protocol. existing RSVP protocol.
4.3. Inspection-Triggered Proxy 4.3. Inspection-Triggered Proxy
In this approach, it is assumed that the RSVP Proxy device is on the In this approach, it is assumed that the RSVP Proxy is on the
datapath of "packets of interest", that it can inspect such packets datapath of "packets of interest", that it can inspect such packets
on the fly as they transit through it, and that it can infer on the fly as they transit through it, and that it can infer
information from these packets of interest to determine what RSVP information from these packets of interest to determine what RSVP
reservations need to be established, when and with what reservations need to be established, when and with what
characteristics (possibly also using some configured information). characteristics (possibly also using some configured information).
One example of "packets of interest" could be application level One example of "packets of interest" could be application level
signaling. An RSVP Proxy device capable of inspecting SIP signaling signaling. An RSVP Proxy capable of inspecting SIP signaling for
for multimedia session or RTSP signaling for Video streaming, can multimedia session or RTSP signaling for Video streaming, can obtain
obtain from such signaling information about when a multimedia from such signaling information about when a multimedia session is up
session is up or when a Video is going to be streamed. It can also or when a Video is going to be streamed. It can also identify the
identify the addresses and ports of senders and receivers and can addresses and ports of senders and receivers and can determine the
determine the bandwidth of the corresponding flows. Thus, such an bandwidth of the corresponding flows. Thus, such an RSVP Proxy can
RSVP Proxy device can determine all necessary information to determine all necessary information to synchronize RSVP reservations
synchronise RSVP reservations to application requirements. This is to application requirements. This is illustrated in Figure 7.
illustrated in the Figure below.
|-------------| |-------------|
| Application | | Application |
| Signaling | | Signaling |
| Entity | | Entity |
|-------------| |-------------|
// \\ / \
// \\ / \
// \\ / \
<////////////////////////// \\\\\\\\\\\\\\\\\\\\\\\\\\> </////////////////////// \\\\\\\\\\\\\\\\\\\\\\\\>
|----| |--------| *** |--------| |----| |----| |--------| *** |--------| |----|
| E |--------| RSVP |------*r*--------| RSVP |----------| E | | S |--------| RSVP |------*r*--------| RSVP |----------| R |
|----| | Proxy | *** | Proxy | |----| |----| | Proxy | *** | Proxy | |----|
|--------| |--------| |--------| |--------|
<************************************************************> =======RSVP=======>
<=========RSVP=============>
|----| ********************************************************>
| E | End system (sender, or receiver, or both)
|----|
*** |----| Non-RSVP-capable |----| Non-RSVP-capable ***
*r* Regular RSVP router | S | Sender | R | Receiver *r* regular RSVP
*** |----| |----| *** router
<///> application level signaling </\> application level signaling
<***> media flow ***> media flow
<==> segment of flow path protected by RSVP reservation ==> segment of flow path protected by RSVP reservation
Figure 7: Inspection-Triggered RSVP Proxy Figure 7: Inspection-Triggered RSVP Proxy
Another example of "packets of interest" could be packets belonging Another example of "packets of interest" could be packets belonging
to the application flow itself (e.g. media packets). An RSVP Proxy to the application flow itself (e.g. media packets). An RSVP Proxy
device capable of detecting the transit of packets from a particular capable of detecting the transit of packets from a particular flow,
flow, can attempt to establish a reservation corresponding to that can attempt to establish a reservation corresponding to that flow.
flow. Characteristics of the reservation may be derived from Characteristics of the reservation may be derived from configuration,
configuration, flow measurement or a combination of those. flow measurement or a combination of those.
Note however, that in case of reservation failure, the inspection- Note however, that in case of reservation failure, the inspection-
triggered RSVP Proxy does not have a direct mechanism for notifying triggered RSVP Proxy does not have a direct mechanism for notifying
the application (since it is not participating itself actively in the application (since it is not participating itself actively in
application signaling) so that the application takes appropriate application signaling) so that the application takes appropriate
action (for example terminate the corresponding session). To action (for example terminate the corresponding session). To
mitigate this problem, the inspection-triggered RSVP Proxy may mark mitigate this problem, the inspection-triggered RSVP Proxy may mark
differently the DSCP of flows for which an RSVP reservation has been differently the DSCP of flows for which an RSVP reservation has been
successfully proxied from the flows for which a reservation is not in successfully proxied from the flows for which a reservation is not in
place. In some situations, the Inspection-Triggered Proxy might be place. In some situations, the Inspection-Triggered Proxy might be
skipping to change at page 15, line 27 skipping to change at page 15, line 22
take in case of reservation failure. However, this may be a useful take in case of reservation failure. However, this may be a useful
approach in some environments. Note also that this approach does not approach in some environments. Note also that this approach does not
require any change to the RSVP protocol. require any change to the RSVP protocol.
With the "Inspection-Triggered" RSVP Proxy approach, the RSVP router With the "Inspection-Triggered" RSVP Proxy approach, the RSVP router
may be configurable to use and interpret some specific "packets of may be configurable to use and interpret some specific "packets of
interest" as the trigger for RSVP Receiver Proxy behavior. interest" as the trigger for RSVP Receiver Proxy behavior.
4.4. STUN-Triggered Proxy 4.4. STUN-Triggered Proxy
In this approach, the RSVP Proxy entity takes advantage of the In this approach, the RSVP Proxy takes advantage of the application
application awareness provided by the STUN signaling to synchronise awareness provided by the STUN signaling to synchronize RSVP
RSVP reservations with application requirements. The STUN signaling reservations with application requirements. The STUN signaling is
is sent from endpoint to endpoint. This is illustrated in the figure sent from endpoint to endpoint. This is illustrated in Figure 8.
below.
|---------|
| SIP |
| Server |
|---------|
// \\
// \\
// \\
// \\
// \\
|----| |--------| *** |--------| |----| |----| |--------| *** |--------| |----|
| E |--------| RSVP |------*r*--------| RSVP |----------| E | | S |--------| RSVP |------*r*--------| RSVP |----------| R |
|----| | Proxy | *** | Proxy | |----| |----| | Proxy | *** | Proxy | |----|
|--------| |--------| |--------| |--------|
<**************************************************************> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^>
<=========RSVP=============> =======RSVP=======>
|----| ********************************************************>
| E | End system (sender, or receiver, or both) also STUN Clients
|----|
*** |----| Non-RSVP-capable |----| Non-RSVP-capable ***
*r* Regular RSVP router | S | Sender | R | Receiver *r* regular RSVP
*** |----| |----| *** router
<***> STUN message flow and RTP media flow (over same UDP ports) ^^^> STUN message flow (over same UDP ports as media flow)
<==> segment of flow path protected by RSVP reservation ==> segment of flow path protected by RSVP reservation
// signaling ***> RTP media flow
Figure 8: STUN-Triggered Proxy Figure 8: STUN-Triggered Proxy
In this approach, a STUN [I-D.ietf-behave-rfc3489bis] message In this approach, a STUN [I-D.ietf-behave-rfc3489bis] message
triggers the RSVP proxy. Using a STUN message eases the RSVP proxy triggers the RSVP proxy. Using a STUN message eases the RSVP proxy
agent's computational burden because it need only look for STUN agent's computational burden because it need only look for STUN
messages rather than maintain state of all flows. More importantly, messages rather than maintain state of all flows. More importantly,
the STUN message can also include a STUN attribute describing the the STUN message can also include a STUN attribute describing the
bandwidth and describing the application requesting the flow, which bandwidth and describing the application requesting the flow, which
allows the RSVP proxy agent to authorize an appropriately-sized allows the RSVP proxy agent to authorize an appropriately-sized
skipping to change at page 17, line 24 skipping to change at page 17, line 13
For multicast flows (or certain kinds of unicast flows that don't or For multicast flows (or certain kinds of unicast flows that don't or
can't use ICE), a STUN Indication message can't use ICE), a STUN Indication message
[I-D.ietf-behave-rfc3489bis] could be used for similar purposes. The [I-D.ietf-behave-rfc3489bis] could be used for similar purposes. The
STUN Indication message is not acknowledged by its receiver and has STUN Indication message is not acknowledged by its receiver and has
the same scalability as the underlying multicast flow itself. the same scalability as the underlying multicast flow itself.
The corresponding extensions to ICE and STUN for such a STUN- The corresponding extensions to ICE and STUN for such a STUN-
triggered RSVP Proxy approach are beyond the scope of this document. triggered RSVP Proxy approach are beyond the scope of this document.
They may be defined in the future in a separate document. They may be defined in the future in a separate document.
4.5. Application-Signaling-Triggered On-Path Proxy 4.5. Application_Entity-Controlled Proxy
In this approach, it is assumed that an entity involved in the In this approach, it is assumed that an entity involved in the
application level signaling controls an RSVP Proxy device which is application level signaling controls an RSVP Proxy which is located
located in the datapath of the application flows (i.e. "on-path"). in the datapath of the application flows (i.e. "on-path"). With this
In this case, the RSVP Proxy entity does not attempt to understand approach, the RSVP Proxy does not attempt to determine itself the
the application reservation requirements, but instead is instructed application reservation requirements. Instead the RSVP Proxy is
by the entity participating in application level signaling to instructed by the entity participating in application level signaling
establish, maintain and tear down reservations as needed by the to establish, maintain and tear down reservations as needed by the
application flows. In other words, with this approach, the solution application flows. In other words, with this approach, the solution
for synchronising RSVP signaling with application-level signaling is for synchronizing RSVP signaling with application level requirements
to rely on an application-level signaling entity which controls an is to rely on an application-level signaling entity that controls an
RSVP Proxy function that sits in the flow datapath. RSVP Proxy function that sits in the flow datapath. This approach
allows control of an RSVP Sender Proxy, an RSVP Receiver Proxy or
In some instantiations, the application-level signaling entity may be both.
collocated with the on-path RSVP Proxy device. The figure below
illustrates such an environment in the case where the application-
level signaling protocol is SIP.
|--------| |--------|
-----------|SIP |----------------|SIP |----------
/ |Server/ | |Server/ | \
/ |Proxy | |Server/ | \
|----| |--------| *** |--------| |----|
| E |-----------| Bearer |------*r*-------| Bearer |----------| E |
|----| | Path | *** | Path | |----|
| Entity | | Entity |
| + | | + |
| RSVP | | RSVP |
| Proxy | | Proxy |
|--------| |--------|
<******************> <***********************> <***************>
<=========RSVP=============>
|----|
| E | End system (sender, or receiver, or both)
|----|
***
*r* Regular RSVP router
***
<***> media flow
<==> segment of flow path protected by RSVP reservation
/ SIP signaling
Figure 9: Application-Signaling-Triggered On-Path Proxy
This RSVP Proxy approach does not require any protocol extensions.
We also observe that when multiple sessions are to be established
between two given such RSVP Proxy, the RSVP Proxy have the option to
establish aggregate RSVP reservations (as defined in ([RFC3175] or
[I-D.ietf-tsvwg-rsvp-ipsec]) for a group of sessions, instead of
establishing one RSVP reservation per session.
Consider an environment involving decomposed Session Border
Controllers (SBCs). The SBC function may be broken up into a
Signaling Border Element (SBE) and Datapath Border Elements (DBEs).
The DBEs are remotely controled by the SBE. This may be achieved
using a protocol like [RFC3525]. Where admission control and
bandwidth reservation is required between the SBEs for QoS guarantees
of the sessions, the SBE could implement RSVP Proxy functionality.
In that case, the application-level signaling entity (the SBE) is Operation of the Application_Entity-Controlled Proxy is illustrated
remotely located from the on-path RSVP Proxy devices (located in the in Figure 9.
DBEs). Such an environment is illustrated in the Figure below.
|---------| |---------| |---------|
-----------------| SBE |------------------ /////////| App |////\\\\| App |\\\\\\\\
/ | | \ / | Entity | | Entity | \
/ |---------| \ / |---------| |---------| \
/ // \\ \ / // \\ \
/ // \\ \ / // \\ \
/ // \\ \ / // \\ \
/ // \\ \ / // \\ \
/ // \\ \ / // \\ \
|----| |--------| *** |--------| |----| |----| |--------| *** |---------| |----|
| E |-----------| DBE |------*r*-------| DBE |----------| E | | S |----------| |------*r*-------| |---------| R |
|----| | | *** | | |----| |----| | RSVP | *** | RSVP | |----|
| + | | + | | Sender | | Receiver|
| RSVP | | RSVP |
| Proxy | | Proxy | | Proxy | | Proxy |
|--------| |--------| |--------| |---------|
<******************> <***********************> <***************>
<=========RSVP=============> =======RSVP=======>
|----| ********************************************************>
| E | End system (sender, or receiver, or both)
|----|
*** |----| Non-RSVP-capable |----| Non-RSVP-capable ***
*r* Regular RSVP router | S | Sender | R | Receiver *r* regular RSVP
*** |----| |----| *** router
SBE Signaling Border Element ***> media flow
DBE Datapath Border Element
SBE + DBE = decomposed Session Border Controller (decomposed SBC)
<***> media flow ==> segment of flow path protected by RSVP reservation
<==> segment of flow path protected by RSVP reservation /\ Application signaling (e.g. SIP)
/ SIP signaling // RSVP Proxy control interface
// control interface between the SBE and DBE Figure 9: Application_Entity-Controlled Proxy
Figure 10: Remote Signaling Border Element As an example, the Application_Entity-Controlled Proxy may be used in
the context of Session Border Controllers (SBCs) (see
[I-D.ietf-sipping-sbc-funcs] for description of SBCs) to establish
RSVP reservations for multimedia sessions. In that case, the
Application Entity may be the signaling component of the SBC.
This RSVP Proxy approach does not require any extension to the RSVP This RSVP Proxy approach does not require any extension to the RSVP
protocol. However, it may require extensions to the protocol (e.g. protocol. However, it relies on an RSVP Proxy control interface
that may be based on [RFC3525]) used by the application level allowing control of the RSVP Proxy by an application signaling
signaling entity to control the remote on-path RSVP Proxy entities. entity. This RSVP Proxy control interface is beyond the scope of the
present document. Candidate protocols for realizing such interface
include SNMP, COPS-PR, QPIM, XML and DIAMETER. This interface may
rely on soft states or hard states. Clearly, when hard states are
used, those need to be converted appropriately by the RSVP Proxy
entities into the corresponding RSVP soft states.
4.6. Application-Signaling-Triggered Off-Path Source Proxy In general, the Application Entity is not expected to maintain
awareness of which RSVP Receiver Proxy is on the path to which
destination. However, in the particular cases where it does so
reliably, we observe that the Application Entity could control the
RSVP Sender Proxy and Receiver Proxy so that aggregate RSVP
reservations are used between those, instead of one reservation per
flow. For example, these aggregate reservations could be of RSVP-
AGGREGATE type as specified in [RFC3175] or of GENERIC-AGGREGATE type
as specified in [RFC4860]. Such aggregate reservations could be used
so that a single reservation can be used for multiple (possibly all)
application flows transiting via the same RSVP Sender Proxy and the
same RSVP Receiver Proxy.
In this approach, it is assumed that an entity involved in the For situations where only the RSVP Sender Proxy has to be controlled
application level signaling also behaves as the RSVP Source Proxy by this interface, the interface may be realized through the simple
device. However, since such an application level signaling entity is use of RSVP itself, over a GRE tunnel from the application entity to
generally not on the datapath of the actual application flows, the the RSVP Sender Proxy. This particular case is further discussed in
RSVP messages need to be logically "tunnelled" between the off-path Section 4.5.1. Another particular case of interest is where the
RSVP Source Proxy and a router in the datapath and upstream of the application signaling entity resides on the same device as the RSVP
segment of the path to be protected by RSVP reservations. This is to Proxy. In that case, this interface may be trivially realized as an
internal API. An example environment based on this particular case
is illustrated in Section 4.5.2.
4.5.1. Application_Entity-Controlled Sender Proxy using "RSVP over GRE"
This approach is simply a particular case of the more general
Application_Entity-Controlled Proxy, but where only RSVP Sender
Proxies need to be controlled by the application, and where RSVP is
effectively used as the control protocol between the application
signaling entity and the RSVP Sender Proxy.
In this approach, the RSVP messages (e.g. RSVP Path message) are
effectively generated by the application entity and logically
"tunnelled" to the RSVP Sender Proxy via GRE tunneling. This is to
ensure that the RSVP messages follow the exact same path as the flow ensure that the RSVP messages follow the exact same path as the flow
they protect (as required by RSVP operations) on the segment of the they protect (as required by RSVP operations) on the segment of the
end-to-end path which is to be subject to RSVP reservations. end-to-end path which is to be subject to RSVP reservations.
With this approach, the solution for synchronising RSVP signaling Figure 10 illustrates such an environment.
with application-level signaling is to co-locale the RSVP Proxy
function with a (typically) off-path application-level signaling
entity and then "tunnel" the RSVP signaling towards the appropriate
router in the datapath.
The figure below illustrates such an environment.
|-------------| |-------------|
--------------| Application |----------- ////////////| Application |\\\\\\\\\
/ | Signaling | \ / | Entity | \
/ | Entity + | \
/ | RSVP Sender | \
/ | Proxy | \
/ |-------------| \ / |-------------| \
/ /=/ \ / /=/ \
/ /=/ \ / /=/ \
/ /=/ \ / /=/ \
/ /=/ \ / /=/ \
/ /=/ \ / /=/ \
/ /=/ \
/ /=/ \
/ /=/ \
|----| |--------| *** |----| |----| |--------| *** |----|
| S |-----------| RSVP |-----------*r*----------------------| R | | S |-----------| RSVP |-----------*r*-----------------| R |
|----| | Router | *** |----| |----| | Sender | *** |----|
| Proxy |
|--------| |--------|
****************************************************************> =========RSVP====================>
=========RSVP==============================> *****************************************************>
|----| |----| *** |----| non-RSVP-capable |----| RSVP-capable ***
| S | Sender | R | Receiver *r* regular RSVP | S | Sender | R | Receiver *r* regular RSVP
|----| |----| *** router |----| |----| *** router
<***> media flow ***> media flow
==> segment of flow path protected by RSVP reservation ==> segment of flow path protected by RSVP reservation
in forward direction
/ Application level signaling /\ Application level signaling
/*/ GRE-tunnelled RSVP (Path messages) /=/ GRE-tunnelled RSVP (Path messages)
Figure 11: Application-Signaling-Triggered Off-Path Source Proxy Figure 10: Application-Entity-Controlled Sender Proxy via "RSVP over
GRE"
With the "Application-Triggered Off-Path Source Proxy" approach, the With the Application_Entity-Controlled Sender Proxy using "RSVP Over
RSVP Source Proxy : GRE", the application entity :
o generates a Path message on behalf of the sender, corresponding to o generates a Path message on behalf of the sender, corresponding to
the reservation needed by the application and maintains the the reservation needed by the application and maintains the
corresponding Path state. The Path message built by the Source corresponding Path state. The Path message built by the
Proxy is exactly the same as would be built by the actual sender application entity is exactly the same as would be built by the
(if it was RSVP capable), with one single exception which is that actual sender (if it was RSVP-capable), with one single exception
the RSVP Sender Proxy put its own IP address as the RSVP Previous which is that the Application Entity puts its own IP address as
Hop. In particular, it is recommended that the source address of the RSVP Previous Hop. In particular, it is recommended that the
the Path message built by the RSVP Source Proxy be set to the IP source address of the Path message built by the application entity
address of the sender (not of the Sender Proxy). This helps be set to the IP address of the sender (not of the application
ensuring that, in the presence of non-RSVP routers and of load- entity). This helps ensuring that, in the presence of non-RSVP
balancing in the network where the load-balancing algorithm takes routers and of load-balancing in the network where the load-
into account the source IP address, the Path message generated by balancing algorithm takes into account the source IP address, the
the Sender Proxy follows the exact same path that the actual Path message generated by the application entity follows the exact
stream sourced by the sender. same path that the actual stream sourced by the sender.
o encapsulates the Path message into a GRE tunnel whose destination o encapsulates the Path message into a GRE tunnel whose destination
address is an RSVP Router sitting on the datapath for the flow address is the RSVP Sender Proxy i.e. an RSVP Router sitting on
(and upstream of the segment which requires QoS guarantees via the datapath for the flow (and upstream of the segment which
RSVP reservation). requires QoS guarantees via RSVP reservation).
o processes the corresponding received RSVP messages (including Resv o processes the corresponding received RSVP messages (including Resv
messages) as per regular RSVP. messages) as per regular RSVP.
o synchronises the RSVP reservation state with application level o synchronizes the RSVP reservation state with application level
requirements and signaling. requirements and signaling.
Note that since the Off-Path Source Proxy encodes its own IP address Note that since the application entity encodes its own IP address as
as the RSVP PHOP in the Path message, the RSVP Router terminating the the RSVP PHOP in the Path message, the RSVP Router terminating the
GRE tunnel naturally addresses all the RSVP messages travelling GRE tunnel naturally addresses all the RSVP messages travelling
upstream hop-by-hop (such as Resv messages) to the Off-Path Source upstream hop-by-hop (such as Resv messages) to the application entity
Proxy (without having to encapsulate those in a reverse-direction GRE (without having to encapsulate those in a reverse-direction GRE
tunnel to the Off-Path Proxy). tunnel towards the application entity).
4.5.2. Application_Entity-Controlled Proxy via Co-Location
This approach is simply a particular case of the more general
Application_Entity-Controlled Proxy, but where the application entity
is co-located with the RSVP Proxy. As an example, Session Border
Controllers (SBC) with on-board SIP agents could implement RSVP Proxy
functions and make use of such an approach to achieve session
admission control over the SBC-to-SBC segment using RSVP signaling.
Figure 11 illustrates operations of the Application_Entity-Controlled
RSVP Proxy via Co-location.
|---------| |---------|
////////| App |////////\\\\\\\| App |\\\\\\\\\
/ | Entity | | Entity | \
/ | | | | \
|----| |---------| *** |---------| |----|
| S |--------| RSVP |------*r*------| RSVP |---------| R |
|----| | Sender | *** | Receiver| |----|
| Proxy | | Proxy |
|---------| |---------|
=======RSVP======>
*******************************************************>
|----| Non-RSVP-capable |----| Non-RSVP-capable ***
| S | Sender | R | Receiver *r* regular RSVP
|----| |----| *** router
***> media flow
==> segment of flow path protected by RSVP reservation
/\ Application level signaling
Figure 11: Application_Entity-Controlled Proxy via Co-Location
This RSVP Proxy approach does not require any protocol extensions.
We also observe that when multiple sessions are to be established on
paths sharing the same RSVP Sender Proxy and the same RSVP Receiver
Proxy, the RSVP Proxies have the option to establish aggregate RSVP
reservations (as defined in ([RFC3175] or [RFC4860]) for a group of
sessions, instead of establishing one RSVP reservation per session.
4.6. Policy_Server-Controlled Proxy
In this approach, it is assumed that a Policy Server, which is
located in the control plane of the network, controls an RSVP Proxy
which is located in the datapath of the application flows (i.e. "on-
path"). In turn, the Policy server is triggered by an entity
involved in the application level signaling. With this approach, the
RSVP Proxy does not attempt to determine itself the application
reservation requirements, but instead is instructed by the Policy
Server to establish, maintain and tear down reservations as needed by
the application flows. Moreover, the entity participating in
application level signaling does not attempt to understand the
specific reservation mechanism (i.e. RSVP) or the topology of the
network layer, but instead it simply asks the policy server to
perform (or teardown) a reservation. In other words, with this
approach, the solution for synchronizing RSVP signaling with
application level requirements is to rely on an application level
entity that controls a policy server that, in turn, controls an RSVP
Proxy function that sits in the flow datapath. This approach allows
control of an RSVP Sender Proxy, an RSVP Receiver Proxy or both.
Operation of the Policy_Server-Controlled Proxy is illustrated
Figure 12.
|---------|
/////////////| App |\\\\\\\\\\\\\\
/ | Entity | \
/ |---------| \
/ I \
/ I \
/ |----------| \
/ | Policy | \
/ | Server | \
/ |----------| \
/ // \\ \
/ // \\ \
/ // \\ \
|----| |--------| *** |---------| |----|
| S |-----------| |------*r*-----| |----------| R |
|----| | RSVP | *** | RSVP | |----|
| Sender | | Receiver|
| Proxy | | Proxy |
|--------| |---------|
=====RSVP========>
**********************************************************>
|----| Non-RSVP-capable |----| Non-RSVP-capable ***
| S | Sender | R | Receiver *r* regular RSVP
|----| |----| *** router
***> media flow
==> segment of flow path protected by RSVP reservation
/\ Application signaling (e.g. SIP)
// RSVP Proxy control interface
I Interface between Application Entity and Policy Server
Figure 12: Policy_Server-Controlled Proxy
This RSVP Proxy approach does not require any extension to the RSVP This RSVP Proxy approach does not require any extension to the RSVP
protocol. It only requires tunneling of the downstream end-to-end protocol. However, as with the Application_Entity-Controlled Proxy
routed RSVP messages (in particular the Path messages) in a GRE approach presented in Figure 9, this approach relies on an RSVP Proxy
tunnel. control interface allowing control of the RSVP Proxy (by the Policy
Server in this case). This RSVP Proxy control interface is beyond
the scope of the present document. Considerations about candidate
protocols for realizing such interface can be found in Section 4.5.
Again, for situations where only the RSVP Sender Proxy has to be
controlled by this interface, the interface may be realized through
the simple use of RSVP Itself, over a GRE tunnel from the Policy
Server to the RSVP Sender Proxy. This is similar to what is
presented in Section 4.5.1 except that the "RSVP over GRE" interface
is used in this case by the Policy Server (instead of the application
entity).
The interface between the Application Entity and the Policy Server is
beyond the scope of this document.
4.7. RSVP-Signaling-Triggered Proxy 4.7. RSVP-Signaling-Triggered Proxy
An RSVP proxy can also be triggered and controlled through extended An RSVP Proxy can also be triggered and controlled through extended
RSVP signaling from the remote end that is RSVP-capable (and supports RSVP signaling from the remote end that is RSVP-capable (and supports
these RSVP extensions for Proxy control). For example, an RSVP these RSVP extensions for Proxy control). For example, an RSVP
capable sender could send a new or extended RSVP message explicitely capable sender could send a new or extended RSVP message explicitly
requesting an RSVP Proxy device on the path towards the receiver to requesting an RSVP Proxy on the path towards the receiver to behave
behave as an RSVP Receiver Proxy and also to trigger a reverse as an RSVP Receiver Proxy and also to trigger a reverse direction
direction reservation thus also behaving as a sender proxy. The new reservation thus also behaving as a RSVP Sender Proxy. The new or
or extended RSVP message sent by the sender could also include extended RSVP message sent by the sender could also include
attributes (e.g. bandwidth) for the reservations to be signaled by attributes (e.g. bandwidth) for the reservations to be signaled by
the RSVP Proxy. the RSVP Proxy.
The challenges in these explicit signaling schemes are: The challenges in these explicit signaling schemes include:
o How does the proxy differentiate between reservation requests that o How can the nodes determine when a reservation request ought to be
must be proxied, from requests that should go end-to-end? proxied and when it should not, and accordingly invoke appropriate
o How does the node sending the explicit messages know where the signaling procedures?
proxy is located, e.g., an IP address of the proxy that should
reply to the signaling?
o How are sender and receiver proxy operations differentiated? o How does the node sending the messages explicitly triggering the
Proxy know where the Proxy is located, e.g., determine an IP
address of the proxy that should reply to the signaling?
o How is all the information needed by a Sender Proxy to generate a
Path message actually communicated to the Proxy?
An example of such a mechanism is presented in An example of such a mechanism is presented in
[I-D.manner-tsvwg-rsvp-proxy-sig]. This scheme is primarily targeted [I-D.manner-tsvwg-rsvp-proxy-sig]. This scheme is primarily targeted
to local access network reservations whereby an end host can request to local access network reservations whereby an end host can request
resource reservations for both incoming and outgoing flows only over resource reservations for both incoming and outgoing flows only over
the access network. This may be useful in environments where the the access network. This may be useful in environments where the
access network is typically the bottleneck while the core is access network is typically the bottleneck while the core is
comparatively over-provisioned, as may be the case with a number of comparatively over-provisioned, as may be the case with a number of
radio access technologies. In this proposal, messages targeted to radio access technologies. In this proposal, messages targeted to
the proxy are flagged with one bit in all RSVP message. Similarly, the Proxy are flagged with one bit in all RSVP messages. Similarly,
all messages sent by the proxy back are marked. The use of one bit all RSVP messages sent back by the Proxy are also flagged. The use
allows differentiating between proxied and end-to-end reservations. of such a flag allows differentiating between proxied and end-to-end
For triggering an RSVP receiver proxy, the sender of the data sends a reservations. For triggering an RSVP Receiver Proxy, the sender of
PATH message which is marked with the mentioned one bit. The the data sends a Path message which is marked with the mentioned
receiver proxy is located on the signaling and data path, eventually flag. The Receiver Proxy is located on the signaling and data path,
gets the PATH message, and replies back with a RESV. A node triggers eventually gets the Path message, and replies back with a Resv
an RSVP sender proxy with a new PATH_REQUEST message, which instructs message. A node triggers an RSVP Sender Proxy with a newly defined
the proxy to send a PATH messages towards the triggering node. The Path_Request message, which instructs the proxy to send Path messages
node then replies back with a RESV. More details can be found in towards the triggering node. The node then replies back with a Resv.
[I-D.manner-tsvwg-rsvp-proxy-sig]. More details can be found in [I-D.manner-tsvwg-rsvp-proxy-sig].
Such RSVP-Signaling-Triggered Proxy approaches require RSVP signaling Such an RSVP-Signaling-Triggered Proxy approach would require RSVP
extensions which are outside the scope of the present document, signaling extensions (that are outside the scope of the present
however they can provide more flexibility in the control of the Proxy document). However it could provide more flexibility in the control
behavior (e.g. control of reverse reservation parameters). of the Proxy behavior (e.g. control of reverse reservation
parameters) than provided by the Path-Triggered approaches defined in
Section 4.1 and Section 4.2.
4.8. Other Approaches 4.8. Endsystem-Controlled Proxy
In some cases, having a full RSVP implementation running on an end In some cases, having a full RSVP implementation running on an end
host can be seen to produce excessive overhead. In end-hosts that host can be seen to produce excessive overhead. In end-hosts that
are low in processing power and functionality, having an RSVP daemon are low in processing power and functionality, having an RSVP daemon
run and take care of the signaling may introduce unnecessary run and take care of the signaling may introduce unnecessary
overhead. One article [Kars01] proposes to create a remote API so overhead. One article [Kars01] proposes to create a remote API so
that the daemon would in fact run on the end-host's default router that the daemon would in fact run on the end-host's default router
and the end-host application would send its requests to that daemon. and the end-host application would send its requests to that daemon.
Thus, we can have deployments, where an end host uses some Thus, we can have deployments, where an end host uses some
proprietary simple protocol to communicate with its pre-defined RSVP lightweight protocol to communicate with its pre-defined RSVP router
router - a form of RSVP proxy. - a form of RSVP proxy. Such a lightweight protocol is outside the
scope of the present document.
5. Security Considerations 5. Security Considerations
In the environments concerned by this document, RSVP messages are In the environments of concern for this document, RSVP messages are
used to control resource reservations on a segment of the end-to-end used to control resource reservations on a segment of the end-to-end
path of flows. To ensure the integrity of the associated reservation path of flows. To ensure the integrity of the associated reservation
and admission control mechanisms, the mechanisms defined in and admission control mechanisms, the cryptographic authentication
[RFC2747]] and [RFC3097] can be used. Those protect RSVP messages mechanisms defined in [RFC2747]] and [RFC3097] can be used. Those
integrity hop-by-hop and provide node authentication, thereby protect RSVP messages integrity hop-by-hop and provide node
protecting against corruption and spoofing of RSVP messages. authentication, thereby protecting against corruption, spoofing of
RSVP messages and replay.
[I-D.behringer-tsvwg-rsvp-security-groupkeying] discusses key types,
key provisioning methods as well as their respective applicability.
An important issue regarding the various types of proxy functionality A number of additional security considerations apply to the use of
is authorization: which node is authorized to send messages on behalf RSVP proxies and are discussed below.
of the data sender or receiver, and how is the authorization
verified? RFC 3520 [RFC3520] presents a mechanism to include With some RSVP Proxy approaches, the RSVP proxy operates autonomously
authorization information within RSVP signaling messages. Subsequent inside an RSVP router. This is the case for the Path-Triggered Proxy
versions of this document will discuss in more details how such approaches defined in Section 4.1 and in Section 4.2, for the
mechanisms can be used to address security of RSVP Proxy approaches. Inspection-Triggered Proxy approach defined in Section 4.3, for the
STUN-Triggered Proxy approach defined in Section 4.4 and for the
RSVP-Signaling-Triggered approach defined in Section 4.7. Proper
reservation operation assumes that the RSVP proxy can be trusted to
behave correctly in order to control the RSVP reservation as required
and expected by the end systems. Since, the basic RSVP operation
already assumes a trust model where end-systems trust RSVP nodes to
appropriately perform RSVP reservations, the use of RSVP proxy that
behave autonomously within an RSVP router is not seen as introducing
any significant additional security threat or as fundamentally
modifying the RSVP trust model.
With some RSVP Proxy approaches, the RSVP proxy operate under the
control of another entity. This is the case for the
Application_Entity-Controlled Proxy approach defined in Section 4.5
and for the Policy_Server-Controlled Proxy approach defined in
Section 4.6. This introduces additional security risks since the
entity controlling the RSVP Proxy needs to be trusted for proper
reservation operation. The exact mechanisms to establish such trust
are beyond the scope of this document, but they may include security
mechanisms inside the protocol used as the control interface between
the RSVP Proxy and the entity controlling it, as well as security
mechanisms for all the interfaces involved in the reservation control
chain (e.g. inside the application signaling protocol between the end
systems and the application entity, and, in the case of the
Policy_Server-Controlled Proxy approach, in the protocol between the
application entity and the policy server).
In some situations, the use of RSVP Proxy to control reservations on
behalf of end-systems may actually reduce the security risk (at least
from the network operator viewpoint). This could be the case, for
example, because the routers where the RSVP Proxy functionality runs
are less exposed to tampering than end-systems. Such a case is
further discussed in section 4 of [I-D.ietf-tsvwg-rsvp-proxy-proto].
6. IANA Considerations 6. IANA Considerations
This document does not make any request to IANA registration. This document does not make any request to IANA registration.
7. Acknowledgments 7. Acknowledgments
This document benefited from earlier work on the concept of RSVP This document benefited from earlier work on the concept of RSVP
Proxy including the one documented by Silvano Gai, Dinesh Dutt, Proxy including the one documented by Silvano Gai, Dinesh Dutt,
Nitsan Elfassy and Yoram Bernet. It also benefited from discussions Nitsan Elfassy and Yoram Bernet. It also benefited from discussions
with Pratik Bose, Chris Christou and Michael Davenport. with Pratik Bose, Chris Christou and Michael Davenport. Tullio
Loffredo and Massimo Sassi provided the base material for
Section 4.6.
8. Informative References 8. Informative References
[I-D.behringer-tsvwg-rsvp-security-groupkeying]
Behringer, M., Le Faucheur, F., and F. Baker, "A Framework
for RSVP Security Using Dynamic Group Keying", July 2007.
[I-D.ietf-behave-rfc3489bis] [I-D.ietf-behave-rfc3489bis]
Rosenberg, J., "Simple Traversal Underneath Network Rosenberg, J., Huitema, C., Mahy, R., Matthews, P., and D.
Address Translators (NAT) (STUN)", Wing, "Session Traversal Utilities for (NAT) (STUN)",
draft-ietf-behave-rfc3489bis-05 (work in progress), draft-ietf-behave-rfc3489bis-07 (work in progress),
October 2006. July 2007.
[I-D.ietf-mmusic-ice] [I-D.ietf-mmusic-ice]
Rosenberg, J., "Interactive Connectivity Establishment Rosenberg, J., "Interactive Connectivity Establishment
(ICE): A Methodology for Network Address Translator (NAT) (ICE): A Protocol for Network Address Translator (NAT)
Traversal for Offer/Answer Protocols", Traversal for Offer/Answer Protocols",
draft-ietf-mmusic-ice-13 (work in progress), January 2007. draft-ietf-mmusic-ice-16 (work in progress), June 2007.
[I-D.ietf-tsvwg-rsvp-ipsec] [I-D.ietf-sipping-sbc-funcs]
Le Faucheur, L., "Generic Aggregate Resource ReSerVation Hautakorpi, J., Camarillo, G., Penfield, R., Hawrylyshen,
Protocol (RSVP) Reservations", February 2007. A., and M. Bhatia, "Requirements from SIP (Session
Initiation Protocol) Session Border Control Deployments",
April 2007.
[I-D.ietf-tsvwg-rsvp-proxy-proto] [I-D.ietf-tsvwg-rsvp-proxy-proto]
Le Faucheur, L., "RSVP Extensions For Path-Triggered RSVP Le Faucheur, L., "RSVP Extensions For Path-Triggered RSVP
Receiver Proxy", February 2007. Receiver Proxy", February 2007.
[I-D.ietf-tsvwg-vpn-signaled-preemption]
Baker, F. and P. Bose, "QoS Signaling in a Nested Virtual
Private Network", February 2007.
[I-D.manner-tsvwg-rsvp-proxy-sig] [I-D.manner-tsvwg-rsvp-proxy-sig]
Manner, J., "Localized RSVP for Controlling RSVP Proxies", Manner, J., "Localized RSVP for Controlling RSVP Proxies",
October 2006. October 2006.
[Kars01] Karsten, M., "Experimental Extensions to RSVP -- Remote [Kars01] Karsten, M., "Experimental Extensions to RSVP -- Remote
Client and One-Pass Signalling", IWQoS Karlsruhe, Germany, Client and One-Pass Signalling", IWQoS Karlsruhe, Germany,
2006. 2006.
[RFC1633] Braden, B., Clark, D., and S. Shenker, "Integrated [RFC1633] Braden, B., Clark, D., and S. Shenker, "Integrated
Services in the Internet Architecture: an Overview", Services in the Internet Architecture: an Overview",
skipping to change at page 26, line 49 skipping to change at page 29, line 35
April 2001. April 2001.
[RFC3175] Baker, F., Iturralde, C., Le Faucheur, F., and B. Davie, [RFC3175] Baker, F., Iturralde, C., Le Faucheur, F., and B. Davie,
"Aggregation of RSVP for IPv4 and IPv6 Reservations", "Aggregation of RSVP for IPv4 and IPv6 Reservations",
RFC 3175, September 2001. RFC 3175, September 2001.
[RFC3312] Camarillo, G., Marshall, W., and J. Rosenberg, [RFC3312] Camarillo, G., Marshall, W., and J. Rosenberg,
"Integration of Resource Management and Session Initiation "Integration of Resource Management and Session Initiation
Protocol (SIP)", RFC 3312, October 2002. Protocol (SIP)", RFC 3312, October 2002.
[RFC3520] Hamer, L-N., Gage, B., Kosinski, B., and H. Shieh,
"Session Authorization Policy Element", RFC 3520,
April 2003.
[RFC3525] Groves, C., Pantaleo, M., Anderson, T., and T. Taylor, [RFC3525] Groves, C., Pantaleo, M., Anderson, T., and T. Taylor,
"Gateway Control Protocol Version 1", RFC 3525, June 2003. "Gateway Control Protocol Version 1", RFC 3525, June 2003.
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the
Internet Protocol", RFC 4301, December 2005.
[RFC4860] Le Faucheur, F., Davie, B., Bose, P., Christou, C., and M.
Davenport, "Generic Aggregate Resource ReSerVation
Protocol (RSVP) Reservations", RFC 4860, May 2007.
Appendix A. Use Cases for RSVP Proxies Appendix A. Use Cases for RSVP Proxies
A.1. RSVP-based VoD CAC in Broadband Aggregation Networks A.1. RSVP-based VoD CAC in Broadband Aggregation Networks
As broadband services for residential are becoming more and more As broadband services for residential are becoming more and more
prevalent, next generation aggregation networks are being deployed in prevalent, next generation aggregation networks are being deployed in
order to aggregate traffic from broadband users (whether attached via order to aggregate traffic from broadband users (whether attached via
Digital Subscriber Line technology aka DSL, Fiber To The Home/Curb Digital Subscriber Line technology aka DSL, Fiber To The Home/Curb
aka FTTx, Cable or other broadband access technology) and service aka FTTx, Cable or other broadband access technology). Video on
providers core network or service delivery platforms. Video on
Demand (VoD) services which may be offered to broadband users present Demand (VoD) services which may be offered to broadband users present
significant capacity planning challenges for the aggregation network significant capacity planning challenges for the aggregation network
because each VoD stream requires significant dedicated sustained for a number of reasons. First each VoD stream requires significant
bandwidth (typically 2-4 Mb/s in Standard Definition TV and 8-12 Mb/s dedicated sustained bandwidth (typically 2-4 Mb/s in Standard
in High Definition TV), the VoD codec algorithms are very sensitive Definition TV and 6-12 Mb/s in High Definition TV). Secondly, the
to packet loss and the load resulting from such services is very hard VoD codec algorithms are very sensitive to packet loss. Finally, the
to predict (e.g. it can vary very suddenly with block-buster titles load resulting from such services is very hard to predict (e.g. it
made available as well as with commercial offerings). As a result, can vary very suddenly with block-buster titles made available as
transport of VoD streams on the aggregation network usually translate well as with promotional offerings). As a result, transport of VoD
into a strong requirement for admission control, so that the quality streams on the aggregation network usually translate into a strong
of established VoD sessions can be protected at all times by requirement for admission control. The admission control solution
rejecting the excessive session attempts during unpredictable peaks, protects the quality of established VoD sessions by rejecting the
additional excessive session attempts during unpredictable peaks,
during link or node failures, or combination of those factors. during link or node failures, or combination of those factors.
RSVP can be used in the aggregation network for admission control of RSVP can be used in the aggregation network for admission control of
the VoD sessions. However, since Customer Premises equipment such as the VoD sessions. However, since Customer Premises equipment such as
Set Top Boxes (which behave as the receiver for VoD streams) often do Set Top Boxes (which behave as the receiver for VoD streams) often do
not yet support RSVP, the last IP hop in the aggregation network can not support RSVP, the last IP hop in the aggregation network can
behave as an RSVP Receiver Proxy. This way, RSVP can be used between behave as an RSVP Receiver Proxy. This way, RSVP can be used between
VoD Pumps and the Last IP hop in the Aggregation network to perform VoD Pumps and the last IP hop in the Aggregation network to perform
accurate admission control of VoD streams over the resources set accurate admission control of VoD streams over the resources set
aside for VoD in the aggregation network (typically a certain aside for VoD in the aggregation network (typically a certain
percentage of the bandwidth of any link). As VoD streams are percentage of the bandwidth of any link). As VoD streams are
unidirectional, a simple "Path-Triggered" RSVP Receiver Proxy (as unidirectional, a simple "Path-Triggered" RSVP Receiver Proxy (as
described in Section 4.1) is all that is required in this use case. described in Section 4.1) is all that is required in this use case.
The Figure below illustrates operation of RSVP-based admission The Figure below illustrates operation of RSVP-based admission
control of VoD sessions in an Aggregation network involving RSVP control of VoD sessions in an Aggregation network involving RSVP
support on the VoD Pump (the senders) and RSVP Receiver Proxy on the support on the VoD Pump (the senders) and RSVP Receiver Proxy on the
last IP hop of the aggregation network. All the customer premises last IP hop of the aggregation network. All the customer premises
equipment remain RSVP unaware. equipment remain RSVP unaware.
|-------------| |-------------|
----| VoD SRM |----------- | VoD SRM |
/ | | \ | |
/ | | \ ////////| |\\\\\\\\\\\\\\\
/ | | \
/ | | \
/ |-------------| \ / |-------------| \
/ \ / \
/ \ / \
/ \ / \
/ \ / \
/ \ / \
|----| |------| *** *** |--------| |-----| |---| |----| |------| *** *** |--------| |-----| |---|
| VoD|--|RSVP |----*r*--*r*--|RSVP |--|DSLAM|~~~~|STB|--TV | VoD|--|RSVP |----*r*--*r*--|RSVP |--|DSLAM|~~~~|STB|--TV
|Pump| |Router| *** *** |Receiver| |-----| |---| |Pump| |Router| *** *** |Receiver| |-----| |---|
|----| |------| |Proxy | |----| |------| |Proxy |
|--------| |--------|
<---Aggregation Net-------------> <---Aggregation Net------------->
******************************************************> ******************************************************>
====================RSVP==============> ============RSVP====================>
SRM Systems Resource Manager SRM Session Resource Manager
*** |---| *** |---|
*r* regular RSVP |STB| Set Top Box *r* regular RSVP |STB| Set Top Box
*** router |---| *** router |---|
<***> media flow ***> VoD media flow
==> segment of flow path protected by RSVP reservation ==> segment of flow path protected by RSVP reservation
in forward direction
/ VoD Application level signaling /\ VoD Application level signaling (e.g. RTSP)
Figure 12: VoD Use Case with Receiver Proxy Figure 13: VoD Use Case with Receiver Proxy
In the case where the VoD Pumps are not RSVP-capable, an Application- In the case where the VoD Pumps are not RSVP-capable, an
Signaling-triggered Off-Path Source Proxy (as described in Application_Entity-Controlled Sender Proxy via "RSVP over GRE"
Section 4.6) can also be implemented on the VoD Controller or Systems approach (as described in Section 4.5.1) can also be implemented on
Resource Manager (SRM) devices typically involved in VoD deployments. the VoD Controller or Session Resource Manager (SRM) devices
The Figure below illustrates operation of RSVP-based admission typically involved in VoD deployments. Figure 14 illustrates
control of VoD sessions in an Aggregation network involving such operation of RSVP-based admission control of VoD sessions in an
Application-Signaling-triggered Off-Path Source Proxy on the SRM and Aggregation network involving such Application_Entity-Controlled
RSVP Receiver Proxy on the Last IP hop of the aggregation network. Source Proxy combined with an RSVP Receiver Proxy on the last IP hop
All the customer premises equipment, as well as the VoD pumps, remain of the aggregation network. All the customer premises equipment, as
RSVP unaware. well as the VoD pumps, remain RSVP unaware.
|-------------| |-------------|
----| VoD SRM |----------- ////| VoD SRM |\\\\\\\\\\\
/ | | \ / | | \
/ | + | \ / | + | \
/ | RSVP Sender | \ / | RSVP Sender | \
/ | Proxy | \ / |Proxy Control| \
/ |-------------| \ / |-------------| \
/ /=/ \ / /=/ \
/ /=/ \ / /=/ \
/ /=/ \ / /=/ \
/ /=/ \ / /=/ \
/ /=/ \ / /=/ \
|----| |------| *** *** |--------| |-----| |---| |----| |------| *** *** |--------| |-----| |---|
| VoD|--|RSVP |----*r*--*r*--|RSVP |--|DSLAM|~~~~|STB|--TV | VoD|--|RSVP |----*r*--*r*--|RSVP |--|DSLAM|~~~~|STB|--TV
|Pump| |Router| *** *** |Receiver| |-----| |---| |Pump| |Sender| *** *** |Receiver| |-----| |---|
|----| |------| |Proxy | |----| |Proxy | |Proxy |
|--------| |------| |--------|
<---Aggregation Net-------------> <---Aggregation Net------------->
******************************************************> ******************************************************>
==============RSVP==============> =========RSVP==============>
SRM Systems Resource Manager SRM Systems Resource Manager
*** |---| *** |---|
*r* regular RSVP |STB| Set Top Box *r* regular RSVP |STB| Set Top Box
*** router |---| *** router |---|
<***> media flow ***> VoD media flow
==> segment of flow path protected by RSVP reservation ==> segment of flow path protected by RSVP reservation
in forward direction
/ VoD Application level signaling / VoD Application level signaling (e.g. RTSP)
/*/ GRE-tunnelled RSVP (Path messages) /=/ GRE-tunnelled RSVP (Path messages)
Figure 13: VoD Use Case with Receiver Proxy and SRM-based Sender Figure 14: VoD Use Case with Receiver Proxy and SRM-based Sender
Proxy Proxy
The RSVP Proxy entities specified in this document play a significant The RSVP Proxy entities specified in this document play a significant
role here since they allow immediate deployment of an RSVP-based role here since they allow immediate deployment of an RSVP-based
admission control solution for VoD without requiring any upgrade to admission control solution for VoD without requiring any upgrade to
the huge installed base of non-RSVP-capable customer premises the huge installed base of non-RSVP-capable customer premises
equipment. In one mode described above, they also avoid upgrade of equipment. In one mode described above, they also avoid upgrade of
non-RSVP-capable VoD pumps. In turn, this means that the benefits of non-RSVP-capable VoD pumps. In turn, this means that the benefits of
on-path admission control can be offered to VoD services over on-path admission control can be offered to VoD services over
broadband aggregation networks. Those include accurate bandwidth broadband aggregation networks without network or VoD Pump upgrade.
accounting regardless of topology (hub-and-spoke, ring, mesh, star, Those include accurate bandwidth accounting regardless of topology
arbitrary combinations) and dynamic adjustment to any change in (hub-and-spoke, ring, mesh, star, arbitrary combinations) and dynamic
topology (such as failure, routing change, additional links...). adjustment to any change in topology (such as failure, routing
change, additional links...).
A.2. RSVP-based Voice/Video CAC in Enterprise WAN A.2. RSVP-based Voice/Video CAC in Enterprise WAN
More and more enterprises are migrating their telephony and More and more enterprises are migrating their telephony and
videoconferencing applications onto IP. When doing so, there is a videoconferencing applications onto IP. When doing so, there is a
need for retaining admission control capabilities of existing TDM- need for retaining admission control capabilities of existing TDM-
based systems to ensure the QoS of these applications is maintained based systems to ensure the QoS of these applications is maintained
even when transiting through the enterprise's Wide Area Network even when transiting through the enterprise's Wide Area Network
(WAN). Since many of the endpoints already deployed (such as IP (WAN). Since many of the endpoints already deployed (such as IP
Phones or Videoconferencing terminals) are not RSVP capable, RSVP Phones or Videoconferencing terminals) are not RSVP capable, RSVP
Proxy approaches are very useful by allowing deployment of an RSVP- Proxy approaches are very useful: they allow deployment of an RSVP-
based admission control solution over the WAN without requiring based admission control solution over the WAN without requiring
upgrade of the existing terminals. upgrade of the existing terminals.
A common deployment architecture for such environments involves A common deployment architecture for such environments relies on the
Application-Signaling-Triggered On-Path RSVP Proxy as defined in Application_Entity-Controlled Proxy approach as defined in
Section 4.5. Routers sitting at the edges of the WAN network behave Section 4.5. Routers sitting at the edges of the WAN network and
as Media Relay in the datapath. For example, such a Media Relay naturally "on-path" for all inter-campus calls (or sessions) and
router on the WAN Edge may terminate a call-leg from the calling IP behave as RSVP Proxies. The RSVP Proxies establish, maintain and
phone and relay it to another call-leg setup on the WAN side towards tear-down RSVP reservations over the WAN segment for the calls (or
another Media Relay router on the egress side of the WAN towards the sessions) under the control of the SIP Server/Proxy. The SIP Server/
called IP phone. Finally that egress Media Relay router may Proxy synchronizes the RSVP reservation status with the status of
terminate the call leg from the ingress Media Relay router and relay end-to-end calls. For example, the called IP phone will only be
it onto a call-leg setup to the called IP Phone. The Media Relay instructed to play a ring tone if the RSVP reservations over the
routers setup, maintain and tear down the call-legs on the WAN corresponding WAN segment has been successfully established.
segment under the control of the SIP Server/Proxy. They also
establish, maintain and tear-down RSVP reservations over the WAN
segment for these call-legs also under the control of the SIP Server/
Proxy. The SIP Server/Proxy synchronises the RSVP reservation status
with the status of end-to-end calls. For example, the called IP
phone will only be instructed to play a ring tone if the RSVP
reservations for the corresponding WAN call leg has been successfully
established.
This architecture allowing RSVP-based admission control of voice and This architecture allowing RSVP-based admission control of voice and
video on the Enterprise WAN is illustrated in the Figure below. video on the Enterprise WAN is illustrated in Figure 15.
|---------| |---------|
--------------| SIP |------------ //////////////| SIP |\\\\\\\\\\\\
/ | Server/ | \ / | Server/ | \
/ | Proxy | \ / | Proxy | \
/ |---------| \ / |---------| \
/ // \\ \ / // \\ \
/ // \\ \ / // \\ \
/ // \\ \ / // \\ \
/ // \\ \ / // \\ \
/ // \\ \ / // \\ \
|-----| |--------| *** *** |--------| |-----| |-----| |--------| *** *** |--------| |-----|
| IP |------| Media |---*r*---*r*---| Media |-------|IP | | IP |------| Media |---*r*---*r*---| Media |-------|IP |
skipping to change at page 32, line 40 skipping to change at page 34, line 40
<=========RSVP===========> <=========RSVP===========>
*** ***
*r* Regular RSVP router *r* Regular RSVP router
*** ***
<***> media flow <***> media flow
<==> segment of flow path protected by RSVP reservation <==> segment of flow path protected by RSVP reservation
/ SIP signaling /\ SIP signaling
// control interface between the SIP Server/Proxy and // control interface between the SIP Server/Proxy and
Media Relay/RSVP Proxy RSVP Proxy
Figure 14: CAC on Enterprise WAN Use Case Figure 15: CAC on Enterprise WAN Use Case
A.3. RSVP-based Voice CAC in TSP Domain A.3. RSVP-based Voice CAC in Telephony Service Provider Core
Let us consider an environment involving multiple Telephony Service Let us consider an environment involving a Telephony Service Provider
Providers (TSPs). Those may be interconnected through Session Border (TSP). Let us further assume that end-users are attached to the TSP
Controllers (SBC) which are on-path i.e. on the datapath of the voice via Session Border Controllers (SBCs). The SBCs may be remotely
media streams. The SBCs may be remotely controlled by a SIP Server/ controlled by a SIP Server. The SIP Server may control establishment
Proxy. Support of RSVP Proxy on one side of the SBC may be used to of RSVP reservations between the SBCs for admission control of
perform RSVP-based admission control through one of the TSP Domain, sessions over the core. This relies on the Application_Entity-
even if it is not used end-to-end (and in particular when another TSP Controlled RSVP Proxy approach presented in Section 4.5. This is
domain remains entirely non-RSVP-aware). This relies on the illustrated in the Figure below.
Application-Signaling-Triggered On-Path RSVP Proxy presented in
Section 4.5. This is illustrated in the Figure below.
|---------| |---------|
--------------| SIP |------------ //////////////| SIP |\\\\\\\\\\\\
/ | Server/ | \ / | Server/ | \
/ | Proxy | \ / | Proxy | \
/ |---------| \ / |---------| \
/ || \ / // \\ \
/ || \ / // \\ \
/ || \ / // \\ \
/ || \ / // \\ \
/ || \ / // \\ \
|-----| |---------| |--------| |---------| |-----| |-----| |--------| *** *** |--------| |-----|
| IP |------| TSP |-----| SBC |-----| TSP |--|IP | | IP |------| |---*r*---*r*---| |-------|IP |
|Phone| | Domain1 | | + | | Domain2 | |Phone| |Phone| | SBC | *** *** | SBC | |Phone|
|-----| | | | RSVP | | | |-----| |-----| | + | | + | |-----|
| | | Proxy | | | | RSVP | | RSVP |
| | |--------| | | | Proxy | | Proxy |
|---------| |---------| |--------| |--------|
<******************************> <*************************> <---Access----> <---Access----->
<---------Core---------->
<=========RSVP===========> <*************> <***********************> <**************>
<=========RSVP==========>
***
*r* Regular RSVP router
***
<***> media flow <***> media flow
<==> segment of flow path protected by RSVP reservation <==> segment of flow path protected by RSVP reservation
/ SIP signaling /\ SIP signaling
|| control interface between the SIP Server/Proxy and // control interface between the SIP Server/Proxy and
SBC/RSVP Proxy SBC/RSVP Proxy
Figure 15: Voice CAC in TSP Domain Figure 16: Voice CAC in TSP Domain
A.4. RSVP Proxies for Mobile Access Networks A.4. RSVP Proxies for Mobile Access Networks
Mobile access networks are increasingly based on IP technology. This Mobile access networks are increasingly based on IP technology. This
implies that, on the network layer, all traffic, both traditional implies that, on the network layer, all traffic, both traditional
data and streamed data like audio or video, is transmitted as data and streamed data like audio or video, is transmitted as
packets. Increasingly popular multimedia applications would benefit packets. Increasingly popular multimedia applications would benefit
from better than best-effort service from the network, a forwarding from better than best-effort service from the network, a forwarding
service with strict Quality of Service (QoS) with guaranteed minimum service with strict Quality of Service (QoS) with guaranteed minimum
bandwidth and bounded delay. Other applications, such as electronic bandwidth and bounded delay. Other applications, such as electronic
skipping to change at page 35, line 12 skipping to change at page 37, line 19
The IETF has two main models for providing differentiated treatment The IETF has two main models for providing differentiated treatment
of packets in routers. The Integrated Services (IntServ) model of packets in routers. The Integrated Services (IntServ) model
[RFC1633] together with the Resource Reservation Protocol (RSVP) [RFC1633] together with the Resource Reservation Protocol (RSVP)
[RFC2205] [RFC2210] [RFC2961] provides per-flow guaranteed end-to-end [RFC2205] [RFC2210] [RFC2961] provides per-flow guaranteed end-to-end
transmission service. The Differentiated Services (DiffServ) transmission service. The Differentiated Services (DiffServ)
framework [RFC2475] provides non- signaled flow differentiation that framework [RFC2475] provides non- signaled flow differentiation that
usually provides, but does not guarantee, proper transmission usually provides, but does not guarantee, proper transmission
service. service.
However, these architectures have weaknesses, for example, RSVP However, these architectures have potential weaknesses for deployment
requires support from both communication end points, and the protocol in Mobile Access Networks. For example, RSVP requires support from
may have potential performance issues in mobile environments. both communication end points, and the protocol may have potential
DiffServ can only provide statistical guarantees and is not well performance issues in mobile environments. DiffServ can only provide
suited for dynamic environments. statistical guarantees and is not well suited for dynamic
environments.
Let us consider a scenario, where a fixed network correspondent node Let us consider a scenario, where a fixed network correspondent node
(CN) would be sending a multimedia stream to an end host behind a (CN) would be sending a multimedia stream to an end host behind a
wireless link. If the correspondent node does not support RSVP it wireless link. If the correspondent node does not support RSVP it
cannot signal its traffic characteristics to the network and request cannot signal its traffic characteristics to the network and request
specific forwarding services. Likewise, if the correspondent node is specific forwarding services. Likewise, if the correspondent node is
not able to mark its traffic with a proper DiffServ Code Point (DSCP) not able to mark its traffic with a proper DiffServ Code Point (DSCP)
to trigger service differentiation, the multimedia stream will get to trigger service differentiation, the multimedia stream will get
only best-effort service which may result in poor visual and audio only best-effort service which may result in poor visual and audio
quality in the receiving application. Even if the connecting wired quality in the receiving application. Even if the connecting wired
skipping to change at page 36, line 5 skipping to change at page 38, line 7
application protocols. Another option is that the mobile end host application protocols. Another option is that the mobile end host
makes an explicit reservation that identifies the intention and the makes an explicit reservation that identifies the intention and the
access network will find the correct local access network node(s) to access network will find the correct local access network node(s) to
respond to the reservation. RSVP proxies would, thus, allow resource respond to the reservation. RSVP proxies would, thus, allow resource
reservation over the segment which is the most likely bottleneck, the reservation over the segment which is the most likely bottleneck, the
wireless connectivity. If the wireless access network uses a local wireless connectivity. If the wireless access network uses a local
mobility management mechanism, where the IP address of the mobile mobility management mechanism, where the IP address of the mobile
node does not change during handover, RSVP reservations would follow node does not change during handover, RSVP reservations would follow
the mobile node movement. the mobile node movement.
A.5. RSVP Proxies for Reservations in the presence of IPsec Gateways
[I-D.ietf-tsvwg-vpn-signaled-preemption] discusses how resource
reservation can be supported end-to-end in a nested VPN environment.
At each VPN level, VPN Routers behave as [RFC4301] security gateways
between a plaintext domain and a cyphertext domain. To achieve end-
to-end resource reservation, the VPN Routers process RSVP signaling
on the plaintext side, perform aggregation of plaintext reservations,
and maintain the corresponding aggregate RSVP reservations on the
cyphertext side. Each aggregate reservation is established on behalf
of multiple encrypted end-to-end sessions sharing the same ingress
and egress VPN Routers. These aggregate reservations can be as
specified in [RFC3175] or [RFC4860].
Section 3 of [I-D.ietf-tsvwg-vpn-signaled-preemption] discusses the
necessary data flows within a VPN Router to achieve the behavior
described in the previous paragraph. Two mechanisms are described to
achieve such data flows. Section 3.1 presents the case where the VPN
Router carries data across the cryptographic boundary. Section 3.2
discusses the case where the VPN router uses a Network-Guard.
Where such mechanisms are not supported by the VPN Routers, the
approach for end-to-end reservation presented in
[I-D.ietf-tsvwg-vpn-signaled-preemption] cannot be deployed. An
alternative approach to support resource reservations within the
cyphertext core is to use the "Application_Entity-Controlled Proxy"
approach (as defined in Section 4.5) in the following way:
o the RSVP Proxies are located inside the cyphertext domain and use
aggregate RSVP reservations,
o the Application Entity exchange application level signaling with
the end systems in the plaintext domain,
o the Application Entity controls the RSVP Proxies in the cyphertext
domain via an RSVP Proxy control interface
This is illustrated in Figure 17 in the case where the application is
SIP-based multimedia communications.
|-------| |-------|
|SIP |///////////////////\\\\\\\\\\\\\\\\\|SIP |
/|Server/| |Server/|\
/ |Proxy | |Proxy | \
/ |-------| |-------| \
/ ^ \\ // ^ \
/ ^ \\ // ^ \
/ ^ \\ // ^ \
|---| |------| |--------| *** *** |--------| |------| |---|
| S |---|IPsec |--| ARSVP |---*r*---*r*---| ARSVP |--|IPsec |---| R |
|---| | GW | | Sender | *** *** |Receiver| | GW | |---|
|------| | Proxy | | Proxy | |------|
|--------| |--------|
***PT*****> **********************CT****************> ****PT***>
=====> =====>
=====ARSVP======>
|----| RSVP-capable |----| RSVP-capable ***
| S | Sender | R | Receiver *r* regular RSVP
|----| |----| *** router
|------|
|IPsec | IPsec security gateway
| GW |
|------|
ARSVP Aggregate RSVP
***> media flow
==> segment of flow path protected by RSVP reservation
/ \ SIP signaling
^ Network management interface between SIP Server/Proxy
and IPsec security gateway
// control interface between SIP Server/Proxy and ARSVP Proxy
PT Plaintext network
CT Cyphertext network
Figure 17: RSVP Proxies for Reservations in the Presence of IPsec
Gateways
Where the sender and receiver are RSVP capable, they may also use
RSVP signaling. This achieves resource reservation on the plaintext
segments of the end-to-end i.e. :
o from the sender to the ingress IPsec gateway and
o from the egress IPsec gateway to the receiver.
In this use case, because the VPN Routers do not support any RSVP
specific mechanism, the end-to-end RSVP signaling is effectively
hidden by the IPsec gateways on the cyphertext segment of the end-to-
end path.
As with the "Application_Entity-Controlled Proxy" approach (defined
in Section 4.5), the solution here for synchronizing RSVP signaling
with application-level signaling is to rely on an application-level
signaling device that controls an on-path RSVP Proxy function.
However, in the present use case, the RSVP Proxies are a component of
a cyphertext network where all user (bearer) traffic is IPsec
encrypted. This has a number of implications including the
following:
1. encrypted flows can not be identified in the cyphertext domain so
that network nodes can only classify traffic based on IP address
and DiffServ Code Points (DSCPs). As a result, only aggregate
RSVP reservations (such as those specified in [RFC3175] or
[RFC4860] ) can be used. This is similar to
[I-D.ietf-tsvwg-vpn-signaled-preemption].
2. Determining the RSVP Sender proxy and RSVP receiver Proxy to be
used for aggregation of a given flow from sender to receiver
creates a number of challenges. Details on how this may be
achieved are beyond the scope of this document. We observe that,
as illustrated in Figure 17, this may be facilitated by a network
management interface between the application entity and the IPsec
gateways. For example, this interface may be used by the
application entity to obtain information about which IPsec
gateway is on the path of a given end-to-end flow. Then, the
application entity may maintain awareness of which RSVP Proxy is
on the cyphertext path between a given pair of IPsec gateways.
How such awareness is achieved is beyond the scope of this
document. We simply observe that such awareness can be easily
achieved through simple configuration in the particular case
where a single (physical or logical) RSVP Proxy is fronting a
given IPsec gateway. We also observe that when awareness of the
RSVP Receiver Proxy for a particular egress IPsec gateway (or
end-to-end flow) is not available, the aggregate reservation may
be signaled by the RSVP Sender Proxy to the destination address
of the egress IPsec gateway and then proxied by the RSVP Receiver
Proxy.
Different flavors of operations are possible in terms of aggregate
reservation sizing. For example, the application entity can initiate
an aggregate reservation of fixed size a priori and then simply keep
count of the bandwidth used by sessions and reject sessions that
would result in excess usage of an aggregate reservation. The
application entity could also re-size the aggregate reservations on a
session by session basis. Alternatively, the application entity
could re-size the aggregate reservations in step increments typically
corresponding to the bandwidth requirement of multiple sessions.
Authors' Addresses Authors' Addresses
Francois Le Faucheur Francois Le Faucheur
Cisco Systems Cisco Systems
Greenside, 400 Avenue de Roumanille Greenside, 400 Avenue de Roumanille
Sophia Antipolis 06410 Sophia Antipolis 06410
France France
Phone: +33 4 97 23 26 19 Phone: +33 4 97 23 26 19
Email: flefauch@cisco.com Email: flefauch@cisco.com
skipping to change at page 36, line 33 skipping to change at page 42, line 4
Email: jmanner@cs.helsinki.fi Email: jmanner@cs.helsinki.fi
URI: http://www.cs.helsinki.fi/u/jmanner/ URI: http://www.cs.helsinki.fi/u/jmanner/
Dan Wing Dan Wing
Cisco Systems Cisco Systems
170 West Tasman Drive 170 West Tasman Drive
San Jose, CA 95134 San Jose, CA 95134
United States United States
Email: dwing@cisco.com Email: dwing@cisco.com
Allan Guillou Allan Guillou
Neuf Cegetel Neuf Cegetel
40-42 Quai du Point du Jour 40-42 Quai du Point du Jour
Boulogne-Billancourt, 92659 Boulogne-Billancourt, 92659
France France
Email: allan.guillou@neufcegetl.fr Email: allan.guillou@neufcegetel.fr
Full Copyright Statement Full Copyright Statement
Copyright (C) The IETF Trust (2007). Copyright (C) The IETF Trust (2007).
This document is subject to the rights, licenses and restrictions This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors contained in BCP 78, and except as set forth therein, the authors
retain all their rights. retain all their rights.
This document and the information contained herein are provided on an This document and the information contained herein are provided on an
 End of changes. 168 change blocks. 
516 lines changed or deleted 804 lines changed or added

This html diff was produced by rfcdiff 1.33. The latest version is available from http://tools.ietf.org/tools/rfcdiff/