draft-ietf-tsvwg-rsvp-proxy-approaches-08.txt   draft-ietf-tsvwg-rsvp-proxy-approaches-09.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: April 29, 2010 TKK Expires: September 9, 2010 TKK
D. Wing D. Wing
Cisco Cisco
A. Guillou A. Guillou
SFR SFR
October 26, 2009 March 8, 2010
RSVP Proxy Approaches RSVP Proxy Approaches
draft-ietf-tsvwg-rsvp-proxy-approaches-08.txt draft-ietf-tsvwg-rsvp-proxy-approaches-09.txt
Abstract
The Resource ReSerVation Protocol (RSVP) can be used to make end-to-
end resource reservations in an IP network in order to guarantee the
quality of service required by certain flows. RSVP assumes that both
the data sender and receiver of a given flow take part in RSVP
signaling. Yet, there are use cases where resource reservation is
required, but the receiver, the sender, or both, is not RSVP-capable.
This document presents RSVP Proxy behaviors allowing RSVP routers to
initiate or terminate RSVP signaling on behalf of a receiver or a
sender that is not RSVP-capable. This allows resource reservations
to be established on a critical subset of the end-to-end path. This
document reviews conceptual approaches for deploying RSVP Proxies and
discusses how RSVP reservations can be synchronized with application
requirements, despite the sender, receiver, or both not participating
in RSVP. This document also points out where extensions to RSVP (or
to other protocols) may be needed for deployment of a given RSVP
Proxy approach. However, such extensions are outside the scope of
this document. Finally, practical use cases for RSVP Proxy are
described.
Status of this Memo Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79. This document may contain material provisions of BCP 78 and BCP 79.
from IETF Documents or IETF Contributions published or made publicly
available before November 10, 2008. The person(s) controlling the
copyright in some of this material may not have granted the IETF
Trust the right to allow modifications of such material outside the
IETF Standards Process. Without obtaining an adequate license from
the person(s) controlling the copyright in such materials, this
document may not be modified outside the IETF Standards Process, and
derivative works of it may not be created outside the IETF Standards
Process, except to format it for publication as an RFC or to
translate it into languages other than English.
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
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
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 April 29, 2010. This Internet-Draft will expire on September 9, 2010.
Copyright Notice Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the
Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents in effect on the date of Provisions Relating to IETF Documents
publication of this document (http://trustee.ietf.org/license-info). (http://trustee.ietf.org/license-info) in effect on the date of
Please review these documents carefully, as they describe your rights publication of this document. Please review these documents
and restrictions with respect to this document. carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
Abstract include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the BSD License.
The Resource ReSerVation Protocol (RSVP) can be used to make end-to- This document may contain material from IETF Documents or IETF
end resource reservations in an IP network in order to guarantee the Contributions published or made publicly available before November
quality of service required by certain flows. RSVP assumes that both 10, 2008. The person(s) controlling the copyright in some of this
the data sender and receiver of a given flow take part in RSVP material may not have granted the IETF Trust the right to allow
signaling. Yet, there are use cases where resource reservation is modifications of such material outside the IETF Standards Process.
required, but the receiver, the sender, or both, is not RSVP-capable. Without obtaining an adequate license from the person(s) controlling
This document presents RSVP Proxy behaviors allowing RSVP routers to the copyright in such materials, this document may not be modified
initiate or terminate RSVP signaling on behalf of a receiver or a outside the IETF Standards Process, and derivative works of it may
sender that is not RSVP-capable. This allows resource reservations not be created outside the IETF Standards Process, except to format
to be established on a critical subset of the end-to-end path. This it for publication as an RFC or to translate it into languages other
document reviews conceptual approaches for deploying RSVP Proxies and than English.
discusses how RSVP reservations can be synchronized with application
requirements, despite the sender, receiver, or both not participating
in RSVP. This document also points out where extensions to RSVP (or
to other protocols) may be needed for deployment of a given RSVP
Proxy approach. However, such extensions are outside the scope of
this document. Finally, practical use cases for RSVP Proxy are
described.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. RSVP Proxy Behaviors . . . . . . . . . . . . . . . . . . . . . 6 2. RSVP Proxy Behaviors . . . . . . . . . . . . . . . . . . . . . 6
2.1. RSVP Receiver Proxy . . . . . . . . . . . . . . . . . . . 6 2.1. RSVP Receiver Proxy . . . . . . . . . . . . . . . . . . . 6
2.2. RSVP Sender Proxy . . . . . . . . . . . . . . . . . . . . 7 2.2. RSVP Sender Proxy . . . . . . . . . . . . . . . . . . . . 7
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 8 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 8
4. RSVP Proxy Approaches . . . . . . . . . . . . . . . . . . . . 9 4. RSVP Proxy Approaches . . . . . . . . . . . . . . . . . . . . 9
4.1. Path-Triggered Receiver Proxy . . . . . . . . . . . . . . 9 4.1. Path-Triggered Receiver Proxy . . . . . . . . . . . . . . 9
4.1.1. Mechanisms for Maximizing the Reservation Span . . . . 12 4.1.1. Mechanisms for Maximizing the Reservation Span . . . . 12
4.2. Path-Triggered Sender Proxy for Reverse Direction . . . . 15 4.2. Path-Triggered Sender Proxy for Reverse Direction . . . . 16
4.3. Inspection-Triggered Proxy . . . . . . . . . . . . . . . . 18 4.3. Inspection-Triggered Proxy . . . . . . . . . . . . . . . . 19
4.4. STUN-Triggered Proxy . . . . . . . . . . . . . . . . . . . 21 4.4. STUN-Triggered Proxy . . . . . . . . . . . . . . . . . . . 22
4.5. Application_Entity-Controlled Proxy . . . . . . . . . . . 23 4.5. Application_Entity-Controlled Proxy . . . . . . . . . . . 24
4.5.1. Application_Entity-Controlled Sender Proxy using 4.5.1. Application_Entity-Controlled Sender Proxy using
"RSVP over GRE" . . . . . . . . . . . . . . . . . . . 26 "RSVP over GRE" . . . . . . . . . . . . . . . . . . . 27
4.5.2. Application_Entity-Controlled Proxy via Co-Location . 28 4.5.2. Application_Entity-Controlled Proxy via Co-Location . 29
4.6. Policy_Server-Controlled Proxy . . . . . . . . . . . . . . 29 4.6. Policy_Server-Controlled Proxy . . . . . . . . . . . . . . 30
4.7. RSVP-Signaling-Triggered Proxy . . . . . . . . . . . . . . 32 4.7. RSVP-Signaling-Triggered Proxy . . . . . . . . . . . . . . 33
4.8. Reachability Considerations . . . . . . . . . . . . . . . 33 4.8. Reachability Considerations . . . . . . . . . . . . . . . 34
5. Security Considerations . . . . . . . . . . . . . . . . . . . 34 5. Security Considerations . . . . . . . . . . . . . . . . . . . 35
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 36 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 37
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 36 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 37
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 36 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 37
8.1. Normative References . . . . . . . . . . . . . . . . . . . 36 8.1. Normative References . . . . . . . . . . . . . . . . . . . 37
8.2. Informative References . . . . . . . . . . . . . . . . . . 37 8.2. Informative References . . . . . . . . . . . . . . . . . . 38
Appendix A. Use Cases for RSVP Proxies . . . . . . . . . . . . . 39 Appendix A. Use Cases for RSVP Proxies . . . . . . . . . . . . . 40
A.1. RSVP-based VoD Admission Control in Broadband A.1. RSVP-based VoD Admission Control in Broadband
Aggregation Networks . . . . . . . . . . . . . . . . . . . 39 Aggregation Networks . . . . . . . . . . . . . . . . . . . 40
A.2. RSVP-based Voice/Video CAC in Enterprise WAN . . . . . . . 43 A.2. RSVP-based Voice/Video CAC in Enterprise WAN . . . . . . . 44
A.3. RSVP Proxies for Mobile Access Networks . . . . . . . . . 44 A.3. RSVP Proxies for Mobile Access Networks . . . . . . . . . 45
A.4. RSVP Proxies for Reservations in the presence of IPsec A.4. RSVP Proxies for Reservations in the presence of IPsec
Gateways . . . . . . . . . . . . . . . . . . . . . . . . . 46 Gateways . . . . . . . . . . . . . . . . . . . . . . . . . 47
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 49 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 50
1. Introduction 1. Introduction
Guaranteed Quality of Service (QoS) for some applications with tight Guaranteed Quality of Service (QoS) for some applications with tight
requirements (such as voice or video) may be achieved by reserving requirements (such as voice or video) may be achieved by reserving
resources in each node on the end-to-end path. The main IETF resources in each node on the end-to-end path. The main IETF
protocol for these resource reservations is RSVP, specified in protocol for these resource reservations is RSVP, specified in
[RFC2205]. RSVP does not require that all intermediate nodes support [RFC2205]. RSVP does not require that all intermediate nodes support
RSVP, however it assumes that both the sender and the receiver of the RSVP, however it assumes that both the sender and the receiver of the
data flow support RSVP. There are environments where it would be data flow support RSVP. There are environments where it would be
skipping to change at page 7, line 5 skipping to change at page 7, line 5
protocol number. protocol 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 determines that the data receiver will RSVP routers on the data path determines that the data receiver will
not be participating in the resource reservation signaling and not be participating in the resource reservation signaling and
performs RSVP Receiver Proxy functionality on behalf of the data performs RSVP Receiver Proxy functionality on behalf of the data
receiver. This is illustrated in Figure 1. Various mechanisms by receiver. This is illustrated in Figure 1. Various mechanisms by
which the RSVP proxy router can gain the required information are which the RSVP proxy router can gain the required information are
discussed later in the document. discussed later in the 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 end-to-end RSVP operations, if a data sender is not With conventional end-to-end RSVP operations, if a data sender is not
skipping to change at page 8, line 5 skipping to change at page 8, line 5
reservation. This node is referred to as the RSVP Sender Proxy and reservation. This node is referred to as the RSVP Sender Proxy and
is illustrated in Figure 2. This case presents additional challenges is illustrated in Figure 2. This case presents additional challenges
over the Receiver Proxy case, since the RSVP Sender Proxy must be over the Receiver Proxy case, since the RSVP Sender Proxy must be
able to generate all the information in the Path message (such as the able to generate all the information in the Path message (such as the
Sender TSpec) without the benefit of having previously received any Sender TSpec) without the benefit of having previously received any
RSVP message. An RSVP Receiver Proxy, by contrast only needs to RSVP message. An RSVP Receiver Proxy, by contrast only needs to
formulate an appropriate Resv message in response to an incoming Path formulate an appropriate Resv message in response to an incoming Path
message. Mechanisms to operate an RSVP Sender Proxy are discussed message. Mechanisms to operate an RSVP Sender Proxy are discussed
later in this document. 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
o On-Path: located on the datapath of the actual flow of application o On-Path: located on the datapath of the actual flow of application
skipping to change at page 11, line 5 skipping to change at page 11, line 5
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 (as an RSVP-capable receiver would typically do). message (as an RSVP-capable receiver would typically do).
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 Figure 3. successful reservation is illustrated in Figure 3.
|----| *** *** |----------| |----| |****| *** *** |**********| |----|
| S |---------*r*----------*r*---------| RSVP |----------| R | | S |---------*r*----------*r*---------| RSVP |----------| R |
|----| *** *** | Receiver | |----| |****| *** *** | Receiver | |----|
| Proxy | | Proxy |
|----------| |**********|
---Path---> ----Path----> ---Path----> ---Path---> ----Path----> ---Path---->
<--Resv---> <---Resv----- <--Resv---- <--Resv---> <---Resv----- <--Resv----
==================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
***> 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 Figure 4. control failure is illustrated in Figure 4.
|----| *** *** |----------| |----| |****| *** *** |**********| |----|
| S |---------*r*----------*r*---------| RSVP |----------| R | | S |---------*r*----------*r*---------| RSVP |----------| R |
|----| *** *** | Receiver | |----| |****| *** *** | Receiver | |----|
| Proxy | | Proxy |
|----------| |**********|
---Path---> ----Path----> ---Path----> ---Path---> ----Path----> ---Path---->
<---Resv----- <--Resv------ <---Resv----- <--Resv------
---ResvErr---> --ResvErr---> ---ResvErr---> --ResvErr--->
===================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
***> 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, synchronization 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
skipping to change at page 13, line 34 skipping to change at page 13, line 34
instead of terminating it. This allows an RSVP capable receiver (or instead of terminating it. This allows an RSVP capable receiver (or
a downstream Receiver Proxy) to respond to the Path with an upstream a downstream Receiver Proxy) to respond to the Path with an upstream
Resv message. On receipt of a Resv message, the Receiver Proxy Resv message. On receipt of a Resv message, the Receiver Proxy
internally converts its state from a proxied reservation to a regular internally converts its state from a proxied reservation to a regular
midpoint RSVP behavior. From then on, everything proceeds as if the midpoint RSVP behavior. From then on, everything proceeds as if the
RSVP router had behaved as a regular RSVP router at reservation RSVP router had behaved as a regular RSVP router at reservation
establishment (as opposed to having behaved as an RSVP receiver proxy establishment (as opposed to having behaved as an RSVP receiver proxy
for that flow). for that flow).
The RSVP Receiver Proxy behavior for dynamic discovery of downstream The RSVP Receiver Proxy behavior for dynamic discovery of downstream
RSVP functionality is also discussed in section 4.1 of RSVP functionality is illustrated in Figure 5 and is also discussed
[I-D.ietf-tsvwg-rsvp-proxy-proto]. in section 4.1 of [I-D.ietf-tsvwg-rsvp-proxy-proto].
|****| *** |**********| |----|
| S |---------*r*---------| RSVP |---| R1 |
|****| *** | Receiver | |----|
| Proxy |
| |
| | |****|
| |------------| R2 |
|**********| |****|
---Path---> --Path--->
(R1) (R1) \-------Path-->
/ (R1)
<--Resv--- <---Resv---
================RSVP===>
**************************************>
---Path---> --Path--->
(R2) (R2) \-------------Path---->
/ (R2)
<--Resv--- <---Resv---
<----Resv---
================RSVP===========================>
***********************************************>
|****| RSVP-capable |----| non-RSVP-capable |****| RSVP-capable
| S | Sender | R | Receiver | R | Receiver
|****| |----| |****|
***
*r* regular RSVP
*** router
(R1) = Path message contains a Session object whose destination is R1
***> media flow
==> segment of flow path protected by RSVP reservation
Figure 5: Dynamic Discovery of Downstream RSVP Functionality
This dynamic discovery mechanism has the benefit that new (or This dynamic discovery mechanism has the benefit that new (or
upgraded) RSVP endpoints will automatically and seamlessly be able to upgraded) RSVP endpoints will automatically and seamlessly be able to
take advantage of end-to-end reservations, without impacting the take advantage of end-to-end reservations, without impacting the
ability of a Receiver Proxy to proxy RSVP for other, non-RSVP-capable ability of a Receiver Proxy to proxy RSVP for other, non-RSVP-capable
endpoints. This mechanism also achieves the goal of automatically endpoints. This mechanism also achieves the goal of automatically
discovering the longest possible RSVP-supporting segment in a network discovering the longest possible RSVP-supporting segment in a network
with multiple Receiver Proxies along the path. This mechanism with multiple Receiver Proxies along the path. This mechanism
dynamically adjusts to any topology and routing change. Also, this dynamically adjusts to any topology and routing change. Also, this
mechanism dynamically handles the situation where a receiver was mechanism dynamically handles the situation where a receiver was
skipping to change at page 14, line 29 skipping to change at page 15, line 45
o If there is no RSVP-capable receiver (or other Receiver Proxy) o If there is no RSVP-capable receiver (or other Receiver Proxy)
downstream of the Receiver Proxy, then the Path messages sent by downstream of the Receiver Proxy, then the Path messages sent by
the Receiver Proxy every RSVP refresh interval (e.g. 30 seconds by the Receiver Proxy every RSVP refresh interval (e.g. 30 seconds by
default) will never be responded to. However, these messages default) will never be responded to. However, these messages
consume a small amount of bandwidth, and in addition would install consume a small amount of bandwidth, and in addition would install
some RSVP state on RSVP-capable midpoint nodes downstream of the some RSVP state on RSVP-capable midpoint nodes downstream of the
first Receiver Proxy. This is seen as a very minor sub- first Receiver Proxy. This is seen as a very minor sub-
optimality. We also observe that such resources would be consumed optimality. We also observe that such resources would be consumed
anyways if the receiver was RSVP capable. Still, if deemed anyways if the receiver was RSVP capable. Still, if deemed
necessary, to mitigate this, the receiver proxy can tear down any necessary, to mitigate this, the receiver proxy can tear down any
unanswered downstream Path state after a predetermined time, and unanswered downstream Path state and stop sending Path messages
stop sending Path messages for the flow (or only send them at much for the flow (or only send them at much lower frequency) as
lower frequency). further discussed in [I-D.ietf-tsvwg-rsvp-proxy-proto] .
4.1.1.2. Selective Receiver Proxy and Sender Control of Receiver Proxy 4.1.1.2. Selective Receiver Proxy and Sender Control of Receiver Proxy
An RSVP Receiver Proxy can be selective about the sessions that it An RSVP Receiver Proxy can be selective about the sessions that it
terminates, based on local policy decision. For example, an edge terminates, based on local policy decision. For example, an edge
router functioning as a Receiver Proxy may behave as a proxy only for router functioning as a Receiver Proxy may behave as a proxy only for
Path messages that are actually going to exit the domain in question, Path messages that are actually going to exit the domain in question,
not for Path messages that are transiting through it but stay within not for Path messages that are transiting through it but stay within
the domain. As another example, the receiver proxy may be the domain. As another example, the receiver proxy may be
configurable to only proxy for flows addressed to a given destination configurable to only proxy for flows addressed to a given destination
skipping to change at page 15, line 33 skipping to change at page 17, line 6
Proxy can take the creation (respectively, maintenance and teardown) Proxy can take the creation (respectively, maintenance and teardown)
of a Path state by the receiver as the cue to create (respectively, of a Path state by the receiver as the cue to create (respectively,
maintain and teardown) a Path state towards the receiver. Thus, the maintain and teardown) a Path state towards the receiver. Thus, the
RSVP Proxy is effectively acting as a Sender Proxy for the reverse RSVP Proxy is effectively acting as a Sender Proxy for the reverse
direction under the control of the receiver (for the reverse direction under the control of the receiver (for the reverse
direction). Note that this assumes a degree of symmetry for example direction). Note that this assumes a degree of symmetry for example
in terms of bandwidth for the two directions of the flow (as is in terms of bandwidth for the two directions of the flow (as is
currently typical for IP telephony, for example). currently typical for IP telephony, for example).
The signaling flow for the Path-Triggered Sender Proxy for Reverse The signaling flow for the Path-Triggered Sender Proxy for Reverse
Direction is illustrated in Figure 5. Direction is illustrated in Figure 6.
Path messages generated by the receiver need to transit via the RSVP Path messages generated by the receiver need to transit via the RSVP
Sender Proxy that is on the path from the sender to the receiver. In Sender Proxy that is on the path from the sender to the receiver. In
some topologies, this will always be the case: for example where the some topologies, this will always be the case: for example where the
sender is on a stub network hanging off the RSVP Sender Proxy or sender is on a stub network hanging off the RSVP Sender Proxy or
where there is no asymmetric routing (such that if a RSVP Sender where there is no asymmetric routing (such that if a RSVP Sender
Proxy is on the path from receiver to sender, then it is also on the Proxy is on the path from receiver to sender, then it is also on the
path from sender to receiver). In some topologies (such as those path from sender to receiver). In some topologies (such as those
involving asymmetric routing), this may not always happen naturally. involving asymmetric routing), this may not always happen naturally.
Measures to ensure this does happen in these topologies are outside Measures to ensure this does happen in these topologies are outside
the scope of this document. the scope of this document.
|----| *** *** |----------| |----| |****| *** *** |**********| |----|
| R |---------*r*----------*r*---------| RSVP |----------| S | | R |---------*r*----------*r*---------| RSVP |----------| S |
|----| *** *** | Sender | |----| |****| *** *** | Sender | |----|
| Proxy | | Proxy |
|----------| |**********|
---Path---> ----Path----> ---Path----> ---Path---> ----Path----> ---Path---->
<--Path---> <---Path----- <--Path---- <--Path---> <---Path----- <--Path----
---Resv---> ----Resv----> ---Resv----> ---Resv---> ----Resv----> ---Resv---->
<================RSVP================== <================RSVP==================
<********************************************************** <**********************************************************
|----| RSVP-capable |----| Non-RSVP-capable *** |****| RSVP-capable |----| Non-RSVP-capable ***
| R | Receiver for | S | Sender for *r* regular RSVP | R | Receiver for | S | Sender for *r* regular RSVP
|----| reverse direction |----| reverse direction *** router |****| reverse direction |----| reverse direction *** 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 6: 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 Figure 6. for symmetric flows. This is illustrated in Figure 7.
|----| *** *** |----------| |----| |****| *** *** |----------| |----|
|S/R |---------*r*----------*r*---------| RSVP |----------|S/R&| |S/R |---------*r*----------*r*---------| RSVP |----------|S/R |
|----| *** *** | Receiver | |----| |****| *** *** | Receiver | |----|
| & Sender | | & Sender |
| Proxy | | Proxy |
|----------| |----------|
---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==================> ================RSVP==================>
<================RSVP================== <================RSVP==================
**********************************************************> **********************************************************>
<********************************************************** <**********************************************************
|----| RSVP-capable |----| Non-RSVP-capable *** |****| RSVP-capable |----| Non-RSVP-capable ***
|S/R | Sender and |S/R&| Sender and *r* regular RSVP |S/R | Sender and |S/R | Sender and *r* regular RSVP
|----| Receiver |----| Receiver *** router |****| Receiver |----| Receiver *** router
***> media flow ***> media flow
==> segment of flow path protected by RSVP reservation ==> 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 7: 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
RSVP Sender Receiver Proxy : RSVP Sender Receiver Proxy :
1. sinks the Path message 1. sinks the Path message
skipping to change at page 18, line 17 skipping to change at page 19, line 17
In order to build the Path message for the reverse direction, the In order to build the Path message for the reverse direction, the
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.
In the case where reservations are required in both directions (as In the case where reservations are required in both directions (as
shown in Figure 6), the RSVP-capable device simply needs to behave as shown in Figure 7), the RSVP-capable device simply needs to behave as
a regular RSVP sender and RSVP receiver. It needs not be aware that a regular RSVP sender and RSVP receiver. It needs not be aware that
an RSVP Proxy happens to be used and the Path message it sent for the an RSVP Proxy happens to be used and the Path message it sent for the
forward reservation also acts as the trigger for establishment of the forward reservation also acts as the trigger for establishment of the
reverse reservation. However, in the case where a reservation is reverse reservation. However, in the case where a reservation is
only required in the reverse direction (as shown in Figure 5), the only required in the reverse direction (as shown in Figure 6), the
RSVP-capable device has to generate Path messages in order to trigger RSVP-capable device has to generate Path messages in order to trigger
the reverse direction reservation even if no reservation is required the reverse direction reservation even if no reservation is required
in the forward direction. Although this is not in violation with in the forward direction. Although this is not in violation with
[RFC2205], it may not be the default behavior of an RSVP-capable [RFC2205], it may not be the default behavior of an RSVP-capable
device and therefore may need a behavioral change specifically to device and therefore may need a behavioral change specifically to
facilitate operation of the Path-Triggered Sender Proxy for Reverse facilitate operation of the Path-Triggered Sender Proxy for Reverse
Direction. Direction.
4.3. Inspection-Triggered Proxy 4.3. Inspection-Triggered Proxy
skipping to change at page 18, line 50 skipping to change at page 19, line 50
One example of "packets of interest" could be application level One example of "packets of interest" could be application level
signaling. An RSVP Proxy capable of inspecting SIP signaling for signaling. An RSVP Proxy capable of inspecting SIP signaling for
multimedia session or RTSP signaling for Video streaming, can obtain multimedia session or RTSP signaling for Video streaming, can obtain
from such signaling information about when a multimedia session is up from such signaling information about when a multimedia session is up
or when a Video is going to be streamed. It can also identify the or when a Video is going to be streamed. It can also identify the
addresses and ports of senders and receivers and can determine the addresses and ports of senders and receivers and can determine the
bandwidth of the corresponding flows. It can also determine when the bandwidth of the corresponding flows. It can also determine when the
reservation is no longer needed and tear it down. Thus, such an RSVP reservation is no longer needed and tear it down. Thus, such an RSVP
Proxy can determine all necessary information to synchronize RSVP Proxy can determine all necessary information to synchronize RSVP
reservations to application requirements. This is illustrated in reservations to application requirements. This is illustrated in
Figure 7. Figure 8.
|-------------| |-------------|
| Application | | Application |
| Signaling | | Signaling |
| Entity | | Entity |
|-------------| |-------------|
/ \ / \
/ \ / \
/ \ / \
</////////////////////// \\\\\\\\\\\\\\\\\\\\\\\\> </////////////////////// \\\\\\\\\\\\\\\\\\\\\\\\>
|----| |--------| *** |--------| |----| |----| |********| *** |********| |----|
| S |--------| RSVP |------*r*--------| RSVP |----------| R | | S |--------| RSVP |------*r*--------| RSVP |----------| R |
|----| | Proxy | *** | Proxy | |----| |----| | Proxy | *** | Proxy | |----|
|--------| |--------| |********| |********|
=======RSVP=======> =======RSVP=======>
********************************************************> ********************************************************>
|----| Non-RSVP-capable |----| Non-RSVP-capable *** |----| Non-RSVP-capable |----| Non-RSVP-capable ***
| S | Sender | R | Receiver *r* regular RSVP | S | Sender | R | Receiver *r* regular RSVP
|----| |----| *** router |----| |----| *** 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 8: Inspection-Triggered RSVP Proxy
Another example of "packets of interest" could be transport control Another example of "packets of interest" could be transport control
messages (e.g. RTCP [RFC3550]) traveling alongside the application messages (e.g. RTCP [RFC3550]) traveling alongside the application
flow itself (i.e. Media packets). An RSVP Proxy capable of flow itself (i.e. Media packets). An RSVP Proxy capable of
detecting the transit of packets from a particular flow, can attempt detecting the transit of packets from a particular flow, can attempt
to establish a reservation corresponding to that flow. to establish a reservation corresponding to that flow.
Characteristics of the reservation may be derived by various methods Characteristics of the reservation may be derived by various methods
such as from configuration, flow measurement or a combination of such as from configuration, flow measurement or a combination of
those. However, these methods usually come with their respective those. However, these methods usually come with their respective
operational drawbacks: configuration involves an operational cost and operational drawbacks: configuration involves an operational cost and
skipping to change at page 21, line 14 skipping to change at page 22, line 14
gradually "learn" (possibly with some timeout) which sender is RSVP gradually "learn" (possibly with some timeout) which sender is RSVP
capable of not. These mechanisms can facilitate gradual and dynamic capable of not. These mechanisms can facilitate gradual and dynamic
migration from the Proxy model towards the end-to-end RSVP model as migration from the Proxy model towards the end-to-end RSVP model as
more and more endpoints become RSVP capable. more and more endpoints become RSVP capable.
4.4. STUN-Triggered Proxy 4.4. STUN-Triggered Proxy
In this approach, the RSVP Proxy takes advantage of the application In this approach, the RSVP Proxy takes advantage of the application
awareness provided by the STUN ([RFC5389]) signaling to synchronize awareness provided by the STUN ([RFC5389]) signaling to synchronize
RSVP reservations with application requirements. The STUN signaling RSVP reservations with application requirements. The STUN signaling
is sent from endpoint to endpoint. This is illustrated in Figure 8. is sent from endpoint to endpoint. This is illustrated in Figure 9.
In this approach, a STUN message triggers the RSVP Proxy. In this approach, a STUN message triggers the RSVP Proxy.
|----| |--------| *** |--------| |----| |----| |********| *** |********| |----|
| S |--------| RSVP |------*r*--------| RSVP |----------| R | | S |--------| RSVP |------*r*--------| RSVP |----------| R |
|----| | Proxy | *** | Proxy | |----| |----| | Proxy | *** | Proxy | |----|
|--------| |--------| |********| |********|
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^>
=======RSVP=======> =======RSVP=======>
********************************************************> ********************************************************>
|----| Non-RSVP-capable |----| Non-RSVP-capable *** |----| Non-RSVP-capable |----| Non-RSVP-capable ***
| S | Sender | R | Receiver *r* regular RSVP | S | Sender | R | Receiver *r* regular RSVP
|----| |----| *** router |----| |----| *** router
^^^> STUN message flow (over same UDP ports as media flow) ^^^> 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
***> RTP media flow ***> RTP media flow
Figure 8: STUN-Triggered Proxy Figure 9: STUN-Triggered Proxy
For unicast flows, [I-D.ietf-mmusic-ice] is a widely-adopted approach For unicast flows, [I-D.ietf-mmusic-ice] is a widely-adopted approach
for NAT traversal. For our purposes of triggering RSVP Proxy for NAT traversal. For our purposes of triggering RSVP Proxy
behavior, we rely on ICE's connectivity check which is based on the behavior, we rely on ICE's connectivity check which is based on the
exchange of STUN Binding Request messages between hosts to verify exchange of STUN Binding Request messages between hosts to verify
connectivity (see section 2.2 of [I-D.ietf-mmusic-ice]). The STUN connectivity (see section 2.2 of [I-D.ietf-mmusic-ice]). The STUN
message could also include (yet to be specified) STUN attributes to message could also include (yet to be specified) STUN attributes to
indicate information such as the bandwidth and application requesting indicate information such as the bandwidth and application requesting
the flow, which would allow the RSVP proxy agent to create an the flow, which would allow the RSVP proxy agent to create an
appropriately-sized reservation for each flow. Including such new appropriately-sized reservation for each flow. Including such new
skipping to change at page 24, line 9 skipping to change at page 25, line 9
instructed by the entity participating in application level signaling instructed by the entity participating in application level signaling
to 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 synchronizing RSVP signaling with application level requirements for synchronizing RSVP signaling with application level requirements
is to rely on an application-level signaling entity that controls an is to rely on an application-level signaling entity that controls an
RSVP Proxy function that sits in the flow datapath. This approach RSVP Proxy function that sits in the flow datapath. This approach
allows control of an RSVP Sender Proxy, an RSVP Receiver Proxy or allows control of an RSVP Sender Proxy, an RSVP Receiver Proxy or
both. both.
Operation of the Application_Entity-Controlled Proxy is illustrated Operation of the Application_Entity-Controlled Proxy is illustrated
in Figure 9. in Figure 10.
|---------| |---------| |---------| |---------|
/////////| App |////\\\\| App |\\\\\\\\ /////////| App |////\\\\| App |\\\\\\\\
/ | Entity | | Entity | \ / | Entity | | Entity | \
/ |---------| |---------| \ / |---------| |---------| \
/ // \\ \ / // \\ \
/ // \\ \ / // \\ \
/ // \\ \ / // \\ \
/ // \\ \ / // \\ \
/ // \\ \ / // \\ \
|----| |--------| *** |---------| |----| |----| |********| *** |*********| |----|
| S |----------| |------*r*-------| |---------| R | | S |----------| |------*r*-------| |---------| R |
|----| | RSVP | *** | RSVP | |----| |----| | RSVP | *** | RSVP | |----|
| Sender | | Receiver| | Sender | | Receiver|
| Proxy | | Proxy | | Proxy | | Proxy |
|--------| |---------| |********| |*********|
=======RSVP=======> =======RSVP=======>
********************************************************> ********************************************************>
|----| Non-RSVP-capable |----| Non-RSVP-capable *** |----| Non-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
/\ Application signaling (e.g. SIP) /\ Application signaling (e.g. SIP)
// RSVP Proxy control interface // RSVP Proxy control interface
Figure 9: Application_Entity-Controlled Proxy Figure 10: Application_Entity-Controlled Proxy
As an example, the Application_Entity-Controlled Proxy may be used in As an example, the Application_Entity-Controlled Proxy may be used in
the context of SIP Servers ([RFC3261]) or Session Border Controllers the context of SIP Servers ([RFC3261]) or Session Border Controllers
(SBCs) (see [I-D.ietf-sipping-sbc-funcs] for description of SBCs) to (SBCs) (see [I-D.ietf-sipping-sbc-funcs] for description of SBCs) to
establish RSVP reservations for multimedia sessions. In that case, establish RSVP reservations for multimedia sessions. In that case,
the Application Entity may be the signaling component of the SBC. 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 relies on an RSVP Proxy control interface protocol. However, it relies on an RSVP Proxy control interface
allowing control of the RSVP Proxy by an application signaling allowing control of the RSVP Proxy by an application signaling
skipping to change at page 26, line 34 skipping to change at page 27, line 34
effectively used as the control protocol between the application effectively used as the control protocol between the application
signaling entity and the RSVP Sender Proxy. signaling entity and the RSVP Sender Proxy.
In this approach, the RSVP messages (e.g. RSVP Path message) are In this approach, the RSVP messages (e.g. RSVP Path message) are
effectively generated by the application entity and logically effectively generated by the application entity and logically
"tunnelled" to the RSVP Sender Proxy via GRE tunneling. This is to "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.
Figure 10 illustrates such an environment. Figure 11 illustrates such an environment.
|-------------| |-------------|
////////////| Application |\\\\\\\\\ ////////////| Application |\\\\\\\\\
/ | Entity | \ / | Entity | \
/ |-------------| \ / |-------------| \
/ /=/ \ / /=/ \
/ /=/ \ / /=/ \
/ /=/ \ / /=/ \
/ /=/ \ / /=/ \
/ /=/ \ / /=/ \
/ /=/ \ / /=/ \
/ /=/ \ / /=/ \
/ /=/ \ / /=/ \
|----| |--------| *** |----| |----| |********| *** |****|
| S |-----------| RSVP |-----------*r*-----------------| R | | S |-----------| RSVP |-----------*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
***> media flow ***> media flow
==> segment of flow path protected by RSVP reservation ==> segment of flow path protected by RSVP reservation
/\ Application level signaling /\ Application level signaling
/=/ GRE-tunnelled RSVP (Path messages) /=/ GRE-tunnelled RSVP (Path messages)
Figure 10: Application-Entity-Controlled Sender Proxy via "RSVP over Figure 11: Application-Entity-Controlled Sender Proxy via "RSVP over
GRE" GRE"
With the Application_Entity-Controlled Sender Proxy using "RSVP Over With the Application_Entity-Controlled Sender Proxy using "RSVP Over
GRE", the application entity : 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 corresponding Path state. The Path message built by the
application entity is exactly the same as would be built by the application entity is exactly the same as would be built by the
actual sender (if it was RSVP-capable), with one single exception actual sender (if it was RSVP-capable), with one single exception
skipping to change at page 28, line 40 skipping to change at page 29, line 40
4.5.2. Application_Entity-Controlled Proxy via Co-Location 4.5.2. Application_Entity-Controlled Proxy via Co-Location
This approach is simply a particular case of the more general This approach is simply a particular case of the more general
Application_Entity-Controlled Proxy, but where the application entity Application_Entity-Controlled Proxy, but where the application entity
is co-located with the RSVP Proxy. As an example, Session Border is co-located with the RSVP Proxy. As an example, Session Border
Controllers (SBC) with on-board SIP agents could implement RSVP Proxy Controllers (SBC) with on-board SIP agents could implement RSVP Proxy
functions and make use of such an approach to achieve session functions and make use of such an approach to achieve session
admission control over the SBC-to-SBC segment using RSVP signaling. admission control over the SBC-to-SBC segment using RSVP signaling.
Figure 11 illustrates operations of the Application_Entity-Controlled Figure 12 illustrates operations of the Application_Entity-Controlled
RSVP Proxy via Co-location. RSVP Proxy via Co-location.
|---------| |---------| |---------| |---------|
////////| App |////////\\\\\\\| App |\\\\\\\\\ ////////| App |////////\\\\\\\| App |\\\\\\\\\
/ | Entity | | Entity | \ / | Entity | | Entity | \
/ | | | | \ / | | | | \
|----| |---------| *** |---------| |----| |----| |*********| *** |*********| |----|
| S |--------| RSVP |------*r*------| RSVP |---------| R | | S |--------| RSVP |------*r*------| RSVP |---------| R |
|----| | Sender | *** | Receiver| |----| |----| | Sender | *** | Receiver| |----|
| Proxy | | Proxy | | Proxy | | Proxy |
|---------| |---------| |*********| |*********|
=======RSVP======> =======RSVP======>
*******************************************************> *******************************************************>
|----| Non-RSVP-capable |----| Non-RSVP-capable *** |----| Non-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
/\ Application level signaling /\ Application level signaling
Figure 11: Application_Entity-Controlled Proxy via Co-Location Figure 12: Application_Entity-Controlled Proxy via Co-Location
This RSVP Proxy approach does not require any protocol extensions. This RSVP Proxy approach does not require any protocol extensions.
We also observe that when multiple sessions are to be established on We also observe that when multiple sessions are to be established on
paths sharing the same RSVP Sender Proxy and the same RSVP Receiver paths sharing the same RSVP Sender Proxy and the same RSVP Receiver
Proxy, the RSVP Proxies have the option to establish aggregate RSVP Proxy, the RSVP Proxies have the option to establish aggregate RSVP
reservations (as defined in ([RFC3175] or [RFC4860]) for a group of reservations (as defined in ([RFC3175] or [RFC4860]) for a group of
sessions, instead of establishing one RSVP reservation per session. sessions, instead of establishing one RSVP reservation per session.
4.6. Policy_Server-Controlled Proxy 4.6. Policy_Server-Controlled Proxy
skipping to change at page 30, line 12 skipping to change at page 31, line 12
specific reservation mechanism (i.e. RSVP) or the topology of the specific reservation mechanism (i.e. RSVP) or the topology of the
network layer, but instead it simply asks the policy server to network layer, but instead it simply asks the policy server to
perform (or tear down) a reservation. In other words, with this perform (or tear down) a reservation. In other words, with this
approach, the solution for synchronizing RSVP signaling with approach, the solution for synchronizing RSVP signaling with
application level requirements is to rely on an application level application level requirements is to rely on an application level
entity that controls a policy server that, in turn, controls an RSVP entity that controls a policy server that, in turn, controls an RSVP
Proxy function that sits in the flow datapath. This approach allows Proxy function that sits in the flow datapath. This approach allows
control of an RSVP Sender Proxy, an RSVP Receiver Proxy or both. control of an RSVP Sender Proxy, an RSVP Receiver Proxy or both.
Operation of the Policy_Server-Controlled Proxy is illustrated Operation of the Policy_Server-Controlled Proxy is illustrated
Figure 12. Figure 13.
|---------| |---------|
/////////////| App |\\\\\\\\\\\\\\ /////////////| App |\\\\\\\\\\\\\\
/ | Entity | \ / | Entity | \
/ |---------| \ / |---------| \
/ I \ / I \
/ I \ / I \
/ |----------| \ / |----------| \
/ | Policy | \ / | Policy | \
/ | Server | \ / | Server | \
/ |----------| \ / |----------| \
/ // \\ \ / // \\ \
/ // \\ \ / // \\ \
/ // \\ \ / // \\ \
|----| |--------| *** |---------| |----| |----| |********| *** |*********| |----|
| S |-----------| |------*r*-----| |----------| R | | S |-----------| |------*r*-----| |----------| R |
|----| | RSVP | *** | RSVP | |----| |----| | RSVP | *** | RSVP | |----|
| Sender | | Receiver| | Sender | | Receiver|
| Proxy | | Proxy | | Proxy | | Proxy |
|--------| |---------| |********| |*********|
=====RSVP========> =====RSVP========>
**********************************************************> **********************************************************>
|----| Non-RSVP-capable |----| Non-RSVP-capable *** |----| Non-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
/\ Application signaling (e.g. SIP) /\ Application signaling (e.g. SIP)
// RSVP Proxy control interface // RSVP Proxy control interface
I Interface between Application Entity and Policy Server I Interface between Application Entity and Policy Server
Figure 12: Policy_Server-Controlled Proxy Figure 13: 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. However, as with the Application_Entity-Controlled Proxy protocol. However, as with the Application_Entity-Controlled Proxy
approach presented in Figure 9, this approach relies on an RSVP Proxy approach presented in Figure 10, this approach relies on an RSVP
control interface allowing control of the RSVP Proxy (by the Policy Proxy control interface allowing control of the RSVP Proxy (by the
Server in this case). This RSVP Proxy control interface is beyond Policy Server in this case). This RSVP Proxy control interface is
the scope of the present document. Considerations about candidate beyond the scope of the present document. Considerations about
protocols for realizing such interface can be found in Section 4.5. candidate protocols for realizing such interface can be found in
Section 4.5. Again, for situations where only the RSVP Sender Proxy
Again, for situations where only the RSVP Sender Proxy has to be has to be controlled by this interface, the interface may be realized
controlled by this interface, the interface may be realized through through the simple use of RSVP Itself, over a GRE tunnel from the
the simple use of RSVP Itself, over a GRE tunnel from the Policy Policy Server to the RSVP Sender Proxy. This is similar to what is
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 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 is used in this case by the Policy Server (instead of the application
entity). entity).
The interface between the Application Entity and the Policy Server is The interface between the Application Entity and the Policy Server is
beyond the scope of this document. 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
skipping to change at page 36, line 27 skipping to change at page 37, line 27
Section 4.6. Thanks to James Polk, Magnus Westerlund, Dan Romascanu, Section 4.6. Thanks to James Polk, Magnus Westerlund, Dan Romascanu,
Ross Callon, Cullen Jennings and Jari Arkko for their thorough review Ross Callon, Cullen Jennings and Jari Arkko for their thorough review
and comments. and comments.
8. References 8. References
8.1. Normative References 8.1. Normative References
[I-D.ietf-mmusic-ice] [I-D.ietf-mmusic-ice]
Rosenberg, J., "Interactive Connectivity Establishment Rosenberg, J., "Interactive Connectivity Establishment
(ICE): A Protocol 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-19 (work in progress), October 2007. draft-ietf-mmusic-ice-19 (work in progress), October 2007.
[I-D.ietf-tsvwg-rsvp-security-groupkeying]
Behringer, M. and F. Faucheur, "Applicability of Keying
Methods for RSVP Security",
draft-ietf-tsvwg-rsvp-security-groupkeying-05 (work in
progress), June 2009.
[RFC2205] Braden, B., Zhang, L., Berson, S., Herzog, S., and S. [RFC2205] Braden, B., Zhang, L., Berson, S., Herzog, S., and S.
Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1
Functional Specification", RFC 2205, September 1997. Functional Specification", RFC 2205, September 1997.
[RFC2210] Wroclawski, J., "The Use of RSVP with IETF Integrated [RFC2210] Wroclawski, J., "The Use of RSVP with IETF Integrated
Services", RFC 2210, September 1997. Services", RFC 2210, September 1997.
[RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., [RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z.,
and W. Weiss, "An Architecture for Differentiated and W. Weiss, "An Architecture for Differentiated
Services", RFC 2475, December 1998. Services", RFC 2475, December 1998.
skipping to change at page 37, line 22 skipping to change at page 38, line 17
October 2008. October 2008.
8.2. Informative References 8.2. Informative References
[I-D.ietf-dime-diameter-qos] [I-D.ietf-dime-diameter-qos]
Zorn, G., "Protocol for Diameter Quality of Service Zorn, G., "Protocol for Diameter Quality of Service
Application", November 2007. Application", November 2007.
[I-D.ietf-nsis-qos-nslp] [I-D.ietf-nsis-qos-nslp]
Manner, J., Karagiannis, G., and A. McDonald, "NSLP for Manner, J., Karagiannis, G., and A. McDonald, "NSLP for
Quality-of-Service Signaling", draft-ietf-nsis-qos-nslp-16 Quality-of-Service Signaling", draft-ietf-nsis-qos-nslp-18
(work in progress), February 2008. (work in progress), January 2010.
[I-D.ietf-sipping-sbc-funcs] [I-D.ietf-sipping-sbc-funcs]
Hautakorpi, J., Camarillo, G., Penfield, R., Hawrylyshen, Hautakorpi, J., Camarillo, G., Penfield, R., Hawrylyshen,
A., and M. Bhatia, "Requirements from SIP (Session A., and M. Bhatia, "Requirements from SIP (Session
Initiation Protocol) Session Border Control Deployments", Initiation Protocol) Session Border Control Deployments",
April 2007. April 2007.
[I-D.ietf-tsvwg-rsvp-proxy-proto] [I-D.ietf-tsvwg-rsvp-proxy-proto]
Faucheur, F., Malik, H., Manner, J., Narayanan, A., Faucheur, F., Guillou, A., Manner, J., Malik, H., and A.
Guillou, A., and L. Faucheur, "RSVP Extensions for Path- Narayanan, "RSVP Extensions for Path-Triggered RSVP
Triggered RSVP Receiver Proxy", Receiver Proxy", draft-ietf-tsvwg-rsvp-proxy-proto-10
draft-ietf-tsvwg-rsvp-proxy-proto-09 (work in progress), (work in progress), October 2009.
May 2009.
[I-D.ietf-tsvwg-rsvp-security-groupkeying]
Behringer, M. and F. Faucheur, "Applicability of Keying
Methods for RSVP Security",
draft-ietf-tsvwg-rsvp-security-groupkeying-05 (work in
progress), June 2009.
[I-D.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.
[I-D.rahman-rtg-router-alert-considerations] [I-D.rahman-rtg-router-alert-considerations]
Faucheur, F., "IP Router Alert Considerations and Usage", Faucheur, F., "IP Router Alert Considerations and Usage",
draft-rahman-rtg-router-alert-considerations-02 (work in draft-rahman-rtg-router-alert-considerations-03 (work in
progress), July 2009. progress), October 2009.
[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",
RFC 1633, June 1994. RFC 1633, June 1994.
[RFC2113] Katz, D., "IP Router Alert Option", RFC 2113, [RFC2113] Katz, D., "IP Router Alert Option", RFC 2113,
February 1997. February 1997.
[RFC2326] Schulzrinne, H., Rao, A., and R. Lanphier, "Real Time [RFC2326] Schulzrinne, H., Rao, A., and R. Lanphier, "Real Time
Streaming Protocol (RTSP)", RFC 2326, April 1998. Streaming Protocol (RTSP)", RFC 2326, April 1998.
skipping to change at page 40, line 23 skipping to change at page 41, line 22
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 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 Figure 14 illustrates operation of RSVP-based admission control of
control of VoD sessions in an Aggregation network involving RSVP VoD sessions in an aggregation network involving RSVP support on the
support on the VoD Pump (the senders) and RSVP Receiver Proxy on the VoD Pump (the senders) and RSVP Receiver Proxy on the last IP hop of
last IP hop of the aggregation network. All the customer premises the aggregation network. All the customer premises equipment remain
equipment remain RSVP unaware. RSVP unaware.
|-------------| |-------------|
| VoD SRM | | VoD SRM |
| | | |
////////| |\\\\\\\\\\\\\\\ ////////| |\\\\\\\\\\\\\\
/ |-------------| \ / |-------------| \
/ \ / \
/ \ / \
/ \ / \
/ \ / \
/ \ / \
|----| |------| *** *** |--------| |-----| |---| |****| *** *** *** |********| |-----| |---|
| VoD|--|RSVP |----*r*--*r*--|RSVP |--|DSLAM|~~~~|STB|--TV |VoD |---*r*---*r*---*r*---|RSVP |---|DSLAM|~~~~|STB|--TV
|Pump| |Router| *** *** |Receiver| |-----| |---| |Pump| *** *** *** |Receiver| |-----| |---|
|----| |------| |Proxy | |****| |Proxy |
|--------| |********|
<---Aggregation Net-------------> <---Aggregation Net----------->
******************************************************> ************************************************>
============RSVP====================> ==============RSVP================>
SRM Session Resource Manager SRM Session Resource Manager
*** |---| *** |---|
*r* regular RSVP |STB| Set Top Box *r* regular RSVP |STB| Set Top Box
*** router |---| *** router |---|
***> VoD media flow ***> VoD media flow
==> segment of flow path protected by RSVP reservation ==> segment of flow path protected by RSVP reservation
/\ VoD Application level signaling (e.g. RTSP) /\ VoD Application level signaling (e.g. RTSP)
Figure 13: VoD Use Case with Receiver Proxy Figure 14: VoD Use Case with Receiver Proxy
In the case where the VoD Pumps are not RSVP-capable, an In the case where the VoD Pumps are not RSVP-capable, an
Application_Entity-Controlled Sender Proxy via "RSVP over GRE" Application_Entity-Controlled Sender Proxy via "RSVP over GRE"
approach (as described in Section 4.5.1) can also be implemented on approach (as described in Section 4.5.1) can also be implemented on
the VoD Controller or Session Resource Manager (SRM) devices the VoD Controller or Session Resource Manager (SRM) devices
typically involved in VoD deployments. Figure 14 illustrates typically involved in VoD deployments. Figure 15 illustrates
operation of RSVP-based admission control of VoD sessions in an operation of RSVP-based admission control of VoD sessions in an
Aggregation network involving such Application_Entity-Controlled Aggregation network involving such Application_Entity-Controlled
Source Proxy combined with an RSVP Receiver Proxy on the last IP hop Source Proxy combined with an RSVP Receiver Proxy on the last IP hop
of the aggregation network. All the customer premises equipment, as of the aggregation network. All the customer premises equipment, as
well as the VoD pumps, remain RSVP unaware. well as the VoD pumps, remain RSVP unaware.
|-------------| |-------------|
////| VoD SRM |\\\\\\\\\\\ ////| VoD SRM |\\\\\\\\\\\
/ | | \ / | | \
/ | + | \ / | + | \
/ | RSVP Sender | \ / | RSVP Sender | \
/ |Proxy Control| \ / |Proxy Control| \
/ |-------------| \ / |-------------| \
/ /=/ \ / /=/ \
/ /=/ \ / /=/ \
/ /=/ \ / /=/ \
/ /=/ \ / /=/ \
/ /=/ \ / /=/ \
|----| |------| *** *** |--------| |-----| |---| |----| |******| *** *** |********| |-----| |---|
| VoD|--|RSVP |----*r*--*r*--|RSVP |--|DSLAM|~~~~|STB|--TV | VoD|--|RSVP |----*r*--*r*--|RSVP |--|DSLAM|~~~~|STB|--TV
|Pump| |Sender| *** *** |Receiver| |-----| |---| |Pump| |Sender| *** *** |Receiver| |-----| |---|
|----| |Proxy | |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 |---|
***> VoD media flow ***> VoD media flow
==> segment of flow path protected by RSVP reservation ==> segment of flow path protected by RSVP reservation
/ VoD Application level signaling (e.g. RTSP) / VoD Application level signaling (e.g. RTSP)
/=/ GRE-tunnelled RSVP (Path messages) /=/ GRE-tunnelled RSVP (Path messages)
Figure 14: VoD Use Case with Receiver Proxy and SRM-based Sender Figure 15: 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 without network or VoD Pump upgrade. broadband aggregation networks without network or VoD Pump upgrade.
skipping to change at page 43, line 37 skipping to change at page 44, line 37
naturally "on-path" for all inter-campus calls (or sessions) and naturally "on-path" for all inter-campus calls (or sessions) and
behave as RSVP Proxies. The RSVP Proxies establish, maintain and behave as RSVP Proxies. The RSVP Proxies establish, maintain and
tear-down RSVP reservations over the WAN segment for the calls (or tear-down RSVP reservations over the WAN segment for the calls (or
sessions) under the control of the SIP Server/Proxy. The SIP Server/ sessions) under the control of the SIP Server/Proxy. The SIP Server/
Proxy synchronizes the RSVP reservation status with the status of Proxy synchronizes the RSVP reservation status with the status of
end-to-end calls. For example, the called IP phone will only be end-to-end calls. For example, the called IP phone will only be
instructed to play a ring tone if the RSVP reservations over the instructed to play a ring tone if the RSVP reservations over the
corresponding WAN segment has been successfully established. corresponding WAN segment 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 Figure 15. video on the Enterprise WAN is illustrated in Figure 16.
|---------| |---------|
//////////////| SIP |\\\\\\\\\\\\ //////////////| SIP |\\\\\\\\\\\\
/ | Server/ | \ / | Server/ | \
/ | Proxy | \ / | Proxy | \
/ |---------| \ / |---------| \
/ // \\ \ / // \\ \
/ // \\ \ / // \\ \
/ // \\ \ / // \\ \
/ // \\ \ / // \\ \
/ // \\ \ / // \\ \
|-----| |--------| *** *** |--------| |-----| |-----| |********| *** *** |********| |-----|
| IP |------| Media |---*r*---*r*---| Media |-------|IP | | IP |------| Media |---*r*---*r*---| Media |-------|IP |
|Phone| | Relay | *** *** | Relay | |Phone| |Phone| | Relay | *** *** | Relay | |Phone|
|-----| | + | | + | |-----| |-----| | + | | + | |-----|
| RSVP | | RSVP | | RSVP | | RSVP |
| Proxy | | Proxy | | Proxy | | Proxy |
|--------| |--------| |********| |********|
<--campus--> <--campus--> <--campus--> <--campus-->
network network network network
<---------WAN-----------> <---------WAN----------->
<*************> <***********************> <**************> <*************> <***********************> <**************>
<=========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
RSVP Proxy RSVP Proxy
Figure 15: CAC on Enterprise WAN Use Case Figure 16: CAC on Enterprise WAN Use Case
A.3. RSVP Proxies for Mobile Access Networks A.3. 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 46, line 44 skipping to change at page 47, line 44
o the RSVP Proxies are located inside the cyphertext domain and use o the RSVP Proxies are located inside the cyphertext domain and use
aggregate RSVP reservations, aggregate RSVP reservations,
o the Application Entity exchange application level signaling with o the Application Entity exchange application level signaling with
the end systems in the plaintext domain, the end systems in the plaintext domain,
o the Application Entity controls the RSVP Proxies in the cyphertext o the Application Entity controls the RSVP Proxies in the cyphertext
domain via an RSVP Proxy control interface domain via an RSVP Proxy control interface
This is illustrated in Figure 16 in the case where the application is This is illustrated in Figure 17 in the case where the application is
SIP-based multimedia communications. SIP-based multimedia communications.
|-------| |-------| |-------| |-------|
|SIP |///////////////////\\\\\\\\\\\\\\\\\|SIP | |SIP |///////////////////\\\\\\\\\\\\\\\\\|SIP |
/|Server/| |Server/|\ /|Server/| |Server/|\
/ |Proxy | |Proxy | \ / |Proxy | |Proxy | \
/ |-------| |-------| \ / |-------| |-------| \
/ ^ \\ // ^ \ / ^ \\ // ^ \
/ ^ \\ // ^ \ / ^ \\ // ^ \
/ ^ \\ // ^ \ / ^ \\ // ^ \
|---| |------| |--------| *** *** |--------| |------| |---| |***| |------| |********| *** *** |********| |------| |***|
| S |---|IPsec |--| ARSVP |---*r*---*r*---| ARSVP |--|IPsec |---| R | | S |---|IPsec |--| ARSVP |---*r*---*r*---| ARSVP |--|IPsec |---| R |
|---| | GW | | Sender | *** *** |Receiver| | GW | |---| |***| | GW | | Sender | *** *** |Receiver| | GW | |***|
|------| | Proxy | | Proxy | |------| |------| | Proxy | | Proxy | |------|
|--------| |--------| |********| |********|
***PT*****> **********************CT****************> ****PT***> ***PT*****> **********************CT****************> ****PT***>
=====> =====> =====> =====>
=====ARSVP======> =====ARSVP======>
|----| RSVP-capable |----| RSVP-capable *** |****| RSVP-capable |****| RSVP-capable ***
| S | Sender | R | Receiver *r* regular RSVP | S | Sender | R | Receiver *r* regular RSVP
|----| |----| *** router |****| |****| *** router
|------| |------|
|IPsec | IPsec security gateway |IPsec | IPsec security gateway
| GW | | GW |
|------| |------|
ARSVP Aggregate RSVP ARSVP Aggregate RSVP
***> media flow ***> media flow
skipping to change at page 47, line 50 skipping to change at page 48, line 50
^ Network management interface between SIP Server/Proxy ^ Network management interface between SIP Server/Proxy
and IPsec security gateway and IPsec security gateway
// control interface between SIP Server/Proxy and ARSVP Proxy // control interface between SIP Server/Proxy and ARSVP Proxy
PT Plaintext network PT Plaintext network
CT Cyphertext network CT Cyphertext network
Figure 16: RSVP Proxies for Reservations in the Presence of IPsec Figure 17: RSVP Proxies for Reservations in the Presence of IPsec
Gateways Gateways
Where the sender and receiver are RSVP capable, they may also use Where the sender and receiver are RSVP capable, they may also use
RSVP signaling. This achieves resource reservation on the plaintext RSVP signaling. This achieves resource reservation on the plaintext
segments of the end-to-end i.e. : segments of the end-to-end i.e. :
o from the sender to the ingress IPsec gateway and o from the sender to the ingress IPsec gateway and
o from the egress IPsec gateway to the receiver. o from the egress IPsec gateway to the receiver.
skipping to change at page 48, line 39 skipping to change at page 49, line 39
that network nodes can only classify traffic based on IP address that network nodes can only classify traffic based on IP address
and Differentiated Services codepoints (DSCPs). As a result, and Differentiated Services codepoints (DSCPs). As a result,
only aggregate RSVP reservations (such as those specified in only aggregate RSVP reservations (such as those specified in
[RFC3175] or [RFC4860] ) can be used. This is similar to [RFC3175] or [RFC4860] ) can be used. This is similar to
[RFC4923]. [RFC4923].
2. Determining the RSVP Sender proxy and RSVP receiver Proxy to be 2. Determining the RSVP Sender proxy and RSVP receiver Proxy to be
used for aggregation of a given flow from sender to receiver used for aggregation of a given flow from sender to receiver
creates a number of challenges. Details on how this may be creates a number of challenges. Details on how this may be
achieved are beyond the scope of this document. We observe that, achieved are beyond the scope of this document. We observe that,
as illustrated in Figure 16, this may be facilitated by a network as illustrated in Figure 17, this may be facilitated by a network
management interface between the application entity and the IPsec management interface between the application entity and the IPsec
gateways. For example, this interface may be used by the gateways. For example, this interface may be used by the
application entity to obtain information about which IPsec application entity to obtain information about which IPsec
gateway is on the path of a given end-to-end flow. Then, the gateway is on the path of a given end-to-end flow. Then, the
application entity may maintain awareness of which RSVP Proxy is application entity may maintain awareness of which RSVP Proxy is
on the cyphertext path between a given pair of IPsec gateways. on the cyphertext path between a given pair of IPsec gateways.
How such awareness is achieved is beyond the scope of this How such awareness is achieved is beyond the scope of this
document. We simply observe that such awareness can be easily document. We simply observe that such awareness can be easily
achieved through simple configuration in the particular case achieved through simple configuration in the particular case
where a single (physical or logical) RSVP Proxy is fronting a where a single (physical or logical) RSVP Proxy is fronting a
 End of changes. 102 change blocks. 
194 lines changed or deleted 243 lines changed or added

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