draft-ietf-tsvwg-rsvp-proxy-approaches-09.txt   rfc5945.txt 
TSVWG F. Le Faucheur Internet Engineering Task Force (IETF) F. Le Faucheur
Internet-Draft Cisco Request for Comments: 5945 Cisco
Intended status: Informational J. Manner Category: Informational J. Manner
Expires: September 9, 2010 TKK ISSN: 2070-1721 Aalto University
D. Wing D. Wing
Cisco Cisco
A. Guillou A. Guillou
SFR SFR
March 8, 2010 October 2010
RSVP Proxy Approaches Resource Reservation Protocol (RSVP) Proxy Approaches
draft-ietf-tsvwg-rsvp-proxy-approaches-09.txt
Abstract Abstract
The Resource ReSerVation Protocol (RSVP) can be used to make end-to- The Resource Reservation Protocol (RSVP) can be used to make end-to-
end resource reservations in an IP network in order to guarantee the end resource reservations in an IP network in order to guarantee the
quality of service required by certain flows. RSVP assumes that both quality of service required by certain flows. RSVP assumes that both
the data sender and receiver of a given flow take part in RSVP the data sender and receiver of a given flow take part in RSVP
signaling. Yet, there are use cases where resource reservation is signaling. Yet, there are use cases where resource reservation is
required, but the receiver, the sender, or both, is not RSVP-capable. required, but the receiver, the sender, or both, is not RSVP-capable.
This document presents RSVP Proxy behaviors allowing RSVP routers to This document presents RSVP proxy behaviors allowing RSVP routers to
initiate or terminate RSVP signaling on behalf of a receiver or a initiate or terminate RSVP signaling on behalf of a receiver or a
sender that is not RSVP-capable. This allows resource reservations sender that is not RSVP-capable. This allows resource reservations
to be established on a critical subset of the end-to-end path. This to be established on a critical subset of the end-to-end path. This
document reviews conceptual approaches for deploying RSVP Proxies and document reviews conceptual approaches for deploying RSVP proxies and
discusses how RSVP reservations can be synchronized with application discusses how RSVP reservations can be synchronized with application
requirements, despite the sender, receiver, or both not participating requirements, despite the sender, receiver, or both not participating
in RSVP. This document also points out where extensions to RSVP (or in RSVP. This document also points out where extensions to RSVP (or
to other protocols) may be needed for deployment of a given RSVP to other protocols) may be needed for deployment of a given RSVP
Proxy approach. However, such extensions are outside the scope of proxy approach. However, such extensions are outside the scope of
this document. Finally, practical use cases for RSVP Proxy are this document. Finally, practical use cases for RSVP proxy are
described. described.
Status of this Memo Status of This Memo
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at This document is not an Internet Standards Track specification; it is
http://www.ietf.org/ietf/1id-abstracts.txt. published for informational purposes.
The list of Internet-Draft Shadow Directories can be accessed at This document is a product of the Internet Engineering Task Force
http://www.ietf.org/shadow.html. (IETF). It represents the consensus of the IETF community. It has
received public review and has been approved for publication by the
Internet Engineering Steering Group (IESG). Not all documents
approved by the IESG are a candidate for any level of Internet
Standard; see Section 2 of RFC 5741.
This Internet-Draft will expire on September 9, 2010. Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
http://www.rfc-editor.org/info/rfc5945.
Copyright Notice Copyright Notice
Copyright (c) 2010 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 Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the BSD License. described in the Simplified BSD License.
This document may contain material from IETF Documents or IETF This document may contain material from IETF Documents or IETF
Contributions published or made publicly available before November Contributions published or made publicly available before November
10, 2008. The person(s) controlling the copyright in some of this 10, 2008. The person(s) controlling the copyright in some of this
material may not have granted the IETF Trust the right to allow material may not have granted the IETF Trust the right to allow
modifications of such material outside the IETF Standards Process. modifications of such material outside the IETF Standards Process.
Without obtaining an adequate license from the person(s) controlling Without obtaining an adequate license from the person(s) controlling
the copyright in such materials, this document may not be modified the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other it for publication as an RFC or to translate it into languages other
than English. than English.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction ....................................................3
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 .....................................................7
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 .....11
4.2. Path-Triggered Sender Proxy for Reverse Direction . . . . 16 4.2. Path-Triggered Sender Proxy for Reverse Direction .........15
4.3. Inspection-Triggered Proxy . . . . . . . . . . . . . . . . 19 4.3. Inspection-Triggered Proxy ................................18
4.4. STUN-Triggered Proxy . . . . . . . . . . . . . . . . . . . 22 4.4. STUN-Triggered Proxy ......................................21
4.5. Application_Entity-Controlled Proxy . . . . . . . . . . . 24 4.5. Application_Entity-Controlled Proxy .......................23
4.5.1. Application_Entity-Controlled Sender Proxy using 4.5.1. Application_Entity-Controlled Sender Proxy
"RSVP over GRE" . . . . . . . . . . . . . . . . . . . 27 Using "RSVP over GRE" ..............................26
4.5.2. Application_Entity-Controlled Proxy via Co-Location . 29 4.5.2. Application_Entity-Controlled Proxy via Co-Location 28
4.6. Policy_Server-Controlled Proxy . . . . . . . . . . . . . . 30 4.6. Policy_Server-Controlled Proxy ............................29
4.7. RSVP-Signaling-Triggered Proxy . . . . . . . . . . . . . . 33 4.7. RSVP-Signaling-Triggered Proxy ............................32
4.8. Reachability Considerations . . . . . . . . . . . . . . . 34 4.8. Reachability Considerations ...............................33
5. Security Considerations . . . . . . . . . . . . . . . . . . . 35 5. Security Considerations ........................................34
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 37 6. Acknowledgments ................................................36
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 37 7. References .....................................................36
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 37 7.1. Normative References ......................................36
8.1. Normative References . . . . . . . . . . . . . . . . . . . 37 7.2. Informative References ....................................37
8.2. Informative References . . . . . . . . . . . . . . . . . . 38 Appendix A. Use Cases for RSVP Proxies ...........................40
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 ......................................40
Aggregation Networks . . . . . . . . . . . . . . . . . . . 40 A.2. RSVP-Based Voice/Video Connection Admission Control
A.2. RSVP-based Voice/Video CAC in Enterprise WAN . . . . . . . 44 (CAC) in Enterprise WAN ...................................43
A.3. RSVP Proxies for Mobile Access Networks . . . . . . . . . 45 A.3. RSVP Proxies for Mobile Access Networks ...................44
A.4. RSVP Proxies for Reservations in the presence of IPsec A.4. RSVP Proxies for Reservations in the Presence of IPsec
Gateways . . . . . . . . . . . . . . . . . . . . . . . . . 47 Gateways ..................................................46
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 the Resource Reservation
[RFC2205]. RSVP does not require that all intermediate nodes support Protocol (RSVP), as specified in [RFC2205]. RSVP does not require
RSVP, however it assumes that both the sender and the receiver of the that all intermediate nodes support RSVP; however, it assumes that
data flow support RSVP. There are environments where it would be both the sender and the receiver of the data flow support RSVP.
useful to be able to reserve resources for a flow on at least a There are environments where it would be useful to be able to reserve
subset of the flow path even when the sender or the receiver (or resources for a flow on at least a subset of the flow path even when
both) is not RSVP (for example from the sender to the network edge, the sender or the receiver (or both) is not RSVP-capable (for
or from edge to edge, or from the network edge to the receiver). example, from the sender to the network edge, or from edge to edge,
or from the network edge to the receiver).
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 types of RSVP Proxies. When the sender is not using RSVP, an two types of RSVP proxies. When the sender is not using RSVP, an
entity in the network must operate on behalf of the data sender, and entity in the network must operate on behalf of the data sender, and
in particular, generate RSVP Path messages, and eventually receive, in particular, generate RSVP Path messages, and eventually receive,
process and sink Resv messages. We refer to this entity as the RSVP process, and sink Resv messages. We refer to this entity as the RSVP
Sender Proxy. When the receiver is not using RSVP, an entity in the Sender Proxy. When the receiver is not using RSVP, an entity in the
network must receive Path messages sent by a data sender (or by an network must receive Path messages sent by a data sender (or by an
RSVP Sender Proxy), sink those, and return Resv messages on behalf of RSVP Sender Proxy), sink those, and return Resv messages on behalf of
the data receiver(s). We refer to this entity as the RSVP Receiver the data receiver(s). We refer to this entity as the RSVP Receiver
Proxy. The RSVP Proxies need to be on the data path in order to Proxy. The RSVP proxies need to be on the data path in order to
establish the RSVP reservation; Note, however, that some of the establish the RSVP reservation; note, however, that some of the
approaches described in this document allow the RSVP Proxies to be approaches described in this document allow the RSVP proxies to be
controlled/triggered by an off-path entity. controlled/triggered by an off-path entity.
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 teardown of the RSVP
reservation with the application requirements. Similarly they are in reservation with the application requirements. Similarly, they are
a natural position to determine the characteristics of the in a natural position to determine the characteristics of the
reservation (bandwidth, QoS service,...) which best match the reservation (bandwidth, QoS service, etc.) that best match the
application requirements. For example, before completing the application requirements. For example, before completing the
establishment of a multimedia session, the endpoints may decide to establishment of a multimedia session, the endpoints may decide to
establish RSVP reservations for the corresponding flows. Similarly, establish RSVP reservations for the corresponding flows. Similarly,
when the multimedia session is torn down, the endpoints may decide to when the multimedia session is torn down, the endpoints may decide to
tear down the corresponding RSVP reservations. For instance, tear down the corresponding RSVP reservations. For instance,
[RFC3312] discusses how RSVP reservations can be very tightly [RFC3312] discusses how RSVP reservations can be very tightly
synchronized by endpoints that uses the [RFC3261] Session Initiation synchronized by endpoints that uses the Session Initiation Protocol
Protocol (SIP) for session control. (SIP) ([RFC3261]) for session control.
When RSVP reservation establishment, maintenance and tearing down is When RSVP reservation establishment, maintenance, and teardown are to
to be handled by RSVP Proxies on behalf of an RSVP sender or be handled by RSVP proxies on behalf of an RSVP sender or receiver, a
receiver, a key challenge for the RSVP Proxy is to determine when the key challenge for the RSVP proxy is to determine when the RSVP
RSVP reservations need to be established, maintained and torn down reservations need to be established, maintained, and torn down, and
and to determine what are the characteristics (bandwidth, QoS to determine what the characteristics are (bandwidth, QoS, etc.) of
Service,...) of the required RSVP reservations matching the the required RSVP reservations matching the application requirements.
application requirements. We refer to this problem as the We refer to this problem as the synchronization of RSVP reservations
synchronization of RSVP reservations with application level with application-level requirements.
requirements.
The IETF Next Steps in Signaling (NSIS) working group is specifying a The IETF Next Steps in Signaling (NSIS) working group has specified a
new QoS signaling protocol: the QoS NSIS Signaling Layer Protocol new QoS signaling protocol: the QoS NSIS Signaling Layer Protocol
(NSLP) ([I-D.ietf-nsis-qos-nslp]). This protocol also includes the (NSLP) ([RFC5974]). This protocol also includes the notion of proxy
notion of proxy operation, and terminating QoS signaling on nodes operation, and terminating QoS signaling on nodes that are not the
that are not the actual data senders or receivers (see section "4.8 actual data senders or receivers (see Section 4.8, "Proxy Mode", of
Proxy Mode" of [I-D.ietf-nsis-qos-nslp]. This is the same concept as [RFC5974]. This is the same concept as the proxy operation for RSVP
the proxy operation for RSVP discussed in this document. One discussed in this document. One difference, though, is that the NSIS
difference though is that the NSIS framework does not consider framework does not consider multicast resource reservations, which
multicast resource reservations, which RSVP provides today. RSVP provides today.
Section 2 introduces the notion of RSVP Sender Proxy and RSVP Section 2 introduces the notion of RSVP Sender Proxy and RSVP
Receiver Proxy. Section 3 defines useful terminology. Section 4 Receiver Proxy. Section 3 defines useful terminology. Section 4
then presents several fundamental RSVP Proxy approaches discussing then presents several fundamental RSVP proxy approaches, discussing
how they achieve the necessary synchronization of RSVP reservations how they achieve the necessary synchronization of RSVP reservations
with application level requirements. Appendix A includes more with application-level requirements. Appendix A includes more
detailed use cases for the proxies in various real life deployment detailed use cases for the proxies in various real-life deployment
environments. environments.
It is important to keep in mind that the strongly recommended RSVP It is important to keep in mind that the strongly recommended RSVP
deployment model remains end to end as assumed in [RFC2205] with RSVP deployment model remains end-to-end as assumed in [RFC2205] with RSVP
support on the sender and the receiver. The end to end model allows support on the sender and the receiver. The end-to-end model allows
the most effective synchronization between the reservation and the most effective synchronization between the reservation and
application requirements. Also, when compared to the end to end RSVP application requirements. Also, when compared to the end-to-end RSVP
model, the use of RSVP Proxies involves additional operational burden model, the use of RSVP proxies involves additional operational burden
and/or impose some topological constraints. The additional and/or imposes some topological constraints. The additional
operational burden comes in particular from additional configuration operational burden comes in particular from additional configuration
needed to activate the RSVP Proxies and to help them identify for needed to activate the RSVP proxies and to help them identify for
which senders/receivers a Proxy behavior is required and for which which senders/receivers a proxy behavior is required and for which
senders/receivers it is not (so that an RSVP Proxy does not perform senders/receivers it is not (so that an RSVP proxy does not perform
establishment of reservations on behalf of devices that are capable establishment of reservations on behalf of devices that are capable
of doing so themselves but would then be prevented -without of doing so themselves but would then be prevented -- without
notification- from doing so by the RSVP Proxy). The additional notification -- from doing so by the RSVP proxy). The additional
topological constraints come in particular from the requirement to topological constraints come in particular from the requirement to
have one RSVP Receiver Proxy on the path from any sender to every have one RSVP Receiver Proxy on the path from any sender to every
non-RSVP capable device (so that a non-RSVP capable device is always non-RSVP-capable device (so that a non-RSVP-capable device is always
taken care of by an RSVP Proxy) and the objective to have only one taken care of by an RSVP proxy) and the objective to have only one
such Receiver Proxy on the path from any sender to every non-RSVP such Receiver Proxy on the path from any sender to every non-RSVP-
capable device (so that an RSVP Receiver Proxy does not short-circuit capable device (so that an RSVP Receiver Proxy does not short-circuit
another RSVP Receiver Proxy closer to the non-RSVP capable device, another RSVP Receiver Proxy closer to the non-RSVP-capable device,
thereby reducing the span of the RSVP reservation and the associated thereby reducing the span of the RSVP reservation and the associated
benefits). In the case of the Path-triggered Receiver Proxy benefits). In the case of the Path-Triggered Receiver Proxy
approach, the operational burden and topological constraints can be approach, the operational burden and topological constraints can be
significantly alleviated using the mechanisms discussed in significantly alleviated using the mechanisms discussed in
Section 4.1.1. Section 4.1.1.
It is also worth noting that RSVP operations on endsystems is It is also worth noting that RSVP operations on end-systems are
considerably simpler than on a router, and consequently that RSVP considerably simpler than on a router, and consequently that RSVP
implementations on endsystems are very lightweight (particularly implementations on end-systems are very lightweight (particularly
considering modern endsystems capabilities, including mobile and considering modern end-systems' capabilities, including mobile and
portable devices). For example, endsystem RSVP implementations are portable devices). For example, end-system RSVP implementations are
reported to only consume low tens of kilobytes of code space. Hence, reported to only consume low tens of kilobytes of code space. Hence,
the present document should not be seen as an encouragement to depart this document should not be seen as an encouragement to depart from
from the end to end RSVP model. Its purpose is only to allow RSVP the end-to-end RSVP model. Its purpose is only to allow RSVP
deployment in special environments where RSVP just cannot be used on deployment in special environments where RSVP just cannot be used on
some senders and/or some receivers for reasons specific to the some senders and/or some receivers for reasons specific to the
environment. environment.
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 deprecate the traditional [RFC2205] RSVP document are not meant to deprecate the traditional [RFC2205] RSVP
end-to-end model: end-to-end RSVP reservations are still expected to end-to-end model: end-to-end RSVP reservations are still expected to
be used whenever possible. However, RSVP Proxies are intended to be used whenever possible. However, RSVP proxies are intended to
facilitate RSVP deployment where end-to-end RSVP signaling is not facilitate RSVP deployment where end-to-end RSVP signaling is not
possible. possible.
2.1. RSVP Receiver Proxy 2.1. RSVP Receiver Proxy
With conventional end-to-end RSVP operations, RSVP reservations are With conventional end-to-end RSVP operations, RSVP reservations are
controlled by receivers of data. After a data sender has sent an controlled by receivers of data. After a data sender has sent an
RSVP Path message towards the intended recipient(s), each recipient RSVP Path message towards the intended recipient(s), each recipient
that requires a reservation generates a Resv message. If, however, a that requires a reservation generates a Resv message. If, however, a
data receiver is not running the RSVP protocol, the last hop RSVP data receiver is not running the RSVP protocol, the last-hop RSVP
router will still send the Path message to the data receiver, which router will still send the Path message to the data receiver, which
will silently drop this message as an IP packet with an unknown will silently drop this message as an IP packet with an unknown
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
skipping to change at page 7, line 20 skipping to change at page 6, line 50
===================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
running the RSVP protocol, a resource reservation can not be set up; running the RSVP protocol, a resource reservation cannot be set up; a
a data receiver can not alone reserve resources without Path messages data receiver alone cannot reserve resources without Path messages
first being received. Thus, even if the data receiver is running first being received. Thus, even if the data receiver is running
RSVP, it still needs some node on the data path to send a Path RSVP, it still needs some node on the data path to send a Path
message towards the data receiver. message towards the data receiver.
In that case, an RSVP node on the data path determines that it should In that case, an RSVP node on the data path determines that it should
generate Path messages to allow the receiver to set up the resource generate Path messages to allow the receiver to set up the resource
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 object) without the benefit of having previously
RSVP message. An RSVP Receiver Proxy, by contrast only needs to received any RSVP message. An RSVP Receiver Proxy, by contrast, only
formulate an appropriate Resv message in response to an incoming Path needs to formulate an appropriate Resv message in response to an
message. Mechanisms to operate an RSVP Sender Proxy are discussed incoming Path message. Mechanisms to operate an RSVP Sender Proxy
later in this document. are discussed later in this document.
|----| |**********| *** *** |****| |----| |**********| *** *** |****|
| S |---------| RSVP |---------*r*----------*r*----------| R | | S |---------| RSVP |---------*r*----------*r*----------| R |
|----| | Sender | *** *** |****| |----| | Sender | *** *** |****|
| Proxy | | Proxy |
|**********| |**********|
================RSVP==================> ================RSVP==================>
***********************************************************> ***********************************************************>
skipping to change at page 8, line 27 skipping to change at page 7, line 48
|----| |****| *** 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 data path of the actual flow of
data (regardless of where it is located with respect to the application data (regardless of where it is located with respect
application level signaling path). to the application-level signaling path).
o Off-Path: not On-Path. o Off-Path: not On-Path.
o RSVP-capable (or RSVP-aware): which supports the RSVP protocol as o RSVP-capable (or RSVP-aware): supporting the RSVP protocol as per
per [RFC2205]. [RFC2205].
o RSVP Receiver Proxy: an RSVP capable router performing, on behalf o RSVP Receiver Proxy: an RSVP-capable router performing, on behalf
of a receiver, the RSVP operations which would normally be of a receiver, the RSVP operations that would normally be
performed by an RSVP-capable receiver if end-to-end RSVP signaling performed by an RSVP-capable receiver if end-to-end RSVP signaling
was used. Note that while RSVP is used upstream of the RSVP were used. Note that while RSVP is used upstream of the RSVP
Receiver Proxy, RSVP is not used downstream of the RSVP Receiver Receiver Proxy, RSVP is not used downstream of the RSVP Receiver
Proxy. Proxy.
o RSVP Sender Proxy: an RSVP capable router performing, on behalf of o RSVP Sender Proxy: an RSVP-capable router performing, on behalf of
a sender, the RSVP operations which would normally be performed by a sender, the RSVP operations that would normally be performed by
an RSVP-capable sender if end-to-end RSVP signaling was used. an RSVP-capable sender if end-to-end RSVP signaling were used.
Note that while RSVP is used downstream of the RSVP Sender Proxy, Note that while RSVP is used downstream of the RSVP Sender Proxy,
RSVP is not used upstream of the RSVP Sender Proxy. RSVP is not used upstream of the RSVP Sender Proxy.
o Regular RSVP Router: an RSVP-capable router which is not behaving o Regular RSVP Router: an RSVP-capable router that is not behaving
as a RSVP Receiver Proxy nor as a RSVP Sender Proxy. as an RSVP Receiver Proxy or as an RSVP Sender Proxy.
o Application level signaling: signaling between entities operating o 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 that are aware of the QoS requirements for
actual media flows. SIP ([RFC3261]) and RTSP ([RFC2326]) are actual media flows. SIP ([RFC3261]) and the Real Time Streaming
examples of application level signaling protocol. SDP ([RFC4566]) Protocol (RTSP) ([RFC2326]) are examples of application-level
is an example of session description protocol that can be used by signaling protocols. The Session Description Protocol (SDP)
the application level signaling protocol and from which some of ([RFC4566]) is an example of a protocol that can be used by the
the RSVP reservation parameters (addresses, ports and bandwidth) application-level signaling protocol and from which some of the
might be derived. RSVP is clearly not an application level RSVP reservation parameters (addresses, ports, and bandwidth)
signaling. might be derived. RSVP is clearly not an application-level
signaling protocol.
The roles of RSVP Receiver Proxy, RSVP Sender Proxy, Regular RSVP The roles of the RSVP Receiver Proxy, RSVP Sender Proxy, and regular
Router are all relative to a given unidirectional flow. A given RSVP router are all relative to a given unidirectional flow. A given
router may act as the RSVP Receiver Proxy for a flow, as the RSVP router may act as the RSVP Receiver Proxy for a flow, as the RSVP
Sender Proxy for another flow and as a Regular RSVP router for yet Sender Proxy for another flow, and as a regular RSVP router for yet
another flow. another flow.
Some application level signaling protocols support negotiation of QoS Some application-level signaling protocols support negotiation of QoS
reservations for a media stream. For example, with [RFC3312], reservations for a media stream. For example, with [RFC3312],
resource reservation requirements are explicitly signaled during resource reservation requirements are explicitly signaled during
session establishment using SIP and SDP. Also, [RFC5432] defines a session establishment using SIP and SDP. Also, [RFC5432] defines a
mechanism to negotiate which resource reservation mechanism is to be mechanism to negotiate which resource reservation mechanism is to be
used for a particular media stream. Clearly, these reservation used for a particular media stream. Clearly, these reservation
negotiation mechanisms can be invoked and operate effectively when negotiation mechanisms can be invoked and operate effectively when
both ends support RSVP (and obviously RSVP Proxies are not used). both ends support RSVP (and obviously RSVP proxies are not used).
When both ends do not support RSVP (and RSVP proxies are used at both When both ends do not support RSVP (and RSVP proxies are used at both
ends) these mechanisms will simply not be invoked. In the case where ends), these mechanisms will simply not be invoked. In the case
one end supports RSVP and the other does not (and is helped by an where one end supports RSVP and the other does not (and is helped by
RSVP Proxy), the application level signaling entity supporting the an RSVP proxy), the application-level signaling entity supporting the
non RSVP capable end might use the reservation negotiation mechanisms non-RSVP-capable end might use the reservation negotiation mechanisms
in such a way that the non RSVP capable end (helped by an RSVP Proxy) in such a way that the non-RSVP-capable end (helped by an RSVP proxy)
appears to the remote end as an RSVP capable device. This will appears to the remote end as an RSVP-capable device. This will
ensure that the RSVP capable end is not discouraged to use RSVP ensure that the RSVP-capable end is not discouraged from using RSVP
because the remote end is not RSVP capable. In the case of SIP, the because the remote end is not RSVP-capable. In the case of SIP, the
application level entity may achieve this by taking advantage of the application-level entity may achieve this by taking advantage of the
"segmented" Status Type of [RFC3312] and/or by taking advantage of a "segmented" status type of [RFC3312] and/or by taking advantage of a
SIP [RFC3261] Back-to-Back User Agent (B2BUA). SIP [RFC3261] Back-to-Back User Agent (B2BUA).
4. RSVP Proxy Approaches 4. RSVP Proxy Approaches
This section discusses fundamental RSVP Proxy approaches. This section discusses 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 synchronization 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
taking advantage of the application awareness and RSVP awareness of taking advantage of the application awareness and RSVP awareness of
the sender. the sender.
With the Path-Triggered RSVP Receiver Proxy approach, the RSVP router With the Path-Triggered RSVP Receiver Proxy approach, the RSVP router
may be configured to use receipt of a regular RSVP Path message as may be configured to use receipt of a regular RSVP Path message as
the trigger for RSVP Receiver Proxy behavior. the trigger for RSVP Receiver Proxy behavior.
On receipt of the RSVP Path message, the RSVP Receiver Proxy: On receipt of the RSVP Path message, the RSVP Receiver Proxy:
1. establishes the RSVP Path state as per regular RSVP processing 1. establishes the RSVP Path state as per regular RSVP processing.
2. identifies the downstream interface towards the receiver 2. identifies the downstream interface towards the receiver.
3. sinks the Path message 3. sinks the Path message.
4. behaves as if a Resv message (whose details are discussed below) 4. behaves as if a Resv message (whose details are discussed below)
was received on the downstream interface. This includes was received on the downstream interface. This includes
performing admission control on the downstream interface, performing admission control on the downstream interface,
establishing a Resv state (in case of successful admission establishing a Resv state (in case of successful admission
control) and forwarding the Resv message upstream, sending control), and forwarding the Resv message upstream, sending
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 that 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 |
|**********| |**********|
skipping to change at page 11, line 29 skipping to change at page 10, line 41
|****| 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 to
for notification of the sender of the reservation failure. Operation the 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---->
skipping to change at page 12, line 32 skipping to change at page 11, line 32
| 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 an application and an 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. [RFC5946] specifies RSVP
[I-D.ietf-tsvwg-rsvp-proxy-proto] specifies RSVP extensions allowing extensions allowing such sender notification in the case of
such sender notification in case of reservation failure in the reservation failure in the presence of a Path-Triggered RSVP Receiver
presence of a Path-Triggered RSVP Receiver Proxy. Proxy.
4.1.1. Mechanisms for Maximizing the Reservation Span 4.1.1. Mechanisms for Maximizing the Reservation Span
The presence in the flow path of a Path-triggered RSVP Receiver Proxy The presence in the flow path of a Path-Triggered RSVP Receiver Proxy
(for a given flow) that strictly behaves as described previously (for a given flow) that strictly behaves as described previously
would cause the Path message to be terminated and a Resv message to would cause the Path message to be terminated and a Resv message to
be generated towards the sender. When the receiver is indeed not be generated towards the sender. When the receiver is indeed not
RSVP capable and there is no other RSVP Receiver Proxy downstream on RSVP-capable and there is no other RSVP Receiver Proxy downstream on
the flow path, this achieves the best achievable result of the flow path, this achieves the best achievable result of
establishing an RSVP reservation as far downstream as the RSVP establishing an RSVP reservation as far downstream as the RSVP
Receiver Proxy. Receiver Proxy.
However, if the eventual receiver was in fact RSVP capable, it would However, if the eventual receiver was in fact RSVP-capable, it would
be prevented from participating in RSVP signalling since it does not be prevented from participating in RSVP signaling, since it does not
receive any Path message. As a result, the RSVP reservation would receive any Path message. As a result, the RSVP reservation would
only span a subset of the path it could actually span. A similar only span a subset of the path it could actually span. A similar
suboptimality would exist with multiple Receiver Proxies in the path sub-optimality would exist with multiple Receiver Proxies in the path
of the flow: the first Receiver Proxy may prevent the Path message of the flow: the first Receiver Proxy may prevent the Path message
from reaching the second one and therefore prevent the reservation from reaching the second one and therefore prevent the reservation
from extending down to the second Receiver Proxy. from extending down to the second Receiver Proxy.
It is desirable that, in the presence of Path-triggered RSVP Receiver It is desirable that, in the presence of Path-Triggered RSVP Receiver
Proxies and of a mix of RSVP-capable and non-RSVP-capable receivers, Proxies and of a mix of RSVP-capable and non-RSVP-capable receivers,
the RSVP reservation spans as much of the flow path as possible. the RSVP reservation spans as much of the flow path as possible.
This can be achieved dynamically (avoiding tedious specific This can be achieved dynamically (avoiding tedious specific
configuration), using the mechanisms described in Section 4.1.1.1 and configuration), using the mechanisms described in Sections 4.1.1.1
in Section 4.1.1.2. and 4.1.1.2.
4.1.1.1. Dynamic Discovery of Downstream RSVP Functionality 4.1.1.1. Dynamic Discovery of Downstream RSVP Functionality
When generating a proxy Resv message upstream, a Receiver Proxy may When generating a proxy Resv message upstream, a Receiver Proxy may
be configured to perform dynamic discovery of downstream RSVP be configured to perform dynamic discovery of downstream RSVP
functionality. To that end, when generating the proxy Resv message functionality. To that end, when generating the proxy Resv message
upstream, the Receiver Proxy forwards the Path message downstream upstream, the Receiver Proxy forwards the Path message downstream
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 illustrated in Figure 5 and is also discussed RSVP functionality is illustrated in Figure 5 and is also discussed
in section 4.1 of [I-D.ietf-tsvwg-rsvp-proxy-proto]. in Section 4.1 of [RFC5946].
|****| *** |**********| |----| |****| *** |**********| |----|
| S |---------*r*---------| RSVP |---| R1 | | S |---------*r*---------| RSVP |---| R1 |
|****| *** | Receiver | |----| |****| *** | Receiver | |----|
| Proxy | | Proxy |
| | | |
| | |****| | | |****|
| |------------| R2 | | |------------| R2 |
|**********| |****| |**********| |****|
skipping to change at page 15, line 13 skipping to change at page 14, line 9
Figure 5: Dynamic Discovery of Downstream RSVP Functionality 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 in which a receiver was
RSVP-capable and for some reason (e.g. Software downgrade) no longer RSVP-capable and for some reason (e.g., software downgrade) no longer
is. Finally, this approach requires no new RSVP protocol extensions is. Finally, this approach requires no new RSVP protocol extensions
and no configuration changes to the Receiver Proxy as new RSVP- and no configuration changes to the Receiver Proxy as new RSVP-
capable endpoints come and go. capable endpoints come and go.
The only identified drawbacks to this approach are: The only identified drawbacks to this approach are:
o If admission control fails on the segment between the Receiver o If admission control fails on the segment between the Receiver
Proxy and the RSVP-capable receiver, the receiver will get a Proxy and the RSVP-capable receiver, the receiver will get a
ResvError and can take application-level signalling steps to ResvErr and can take application-level signaling steps to
terminate the call. However, the receiver proxy has already sent terminate the call. However, the Receiver Proxy has already sent
a Resv upstream for this flow, so the sender will see a "false" a Resv upstream for this flow, so the sender will see a "false"
reservation which is not truly end-to-end. The actual admission reservation that is not truly end-to-end. The actual admission
control status will resolve itself in a short while, but the control status will resolve itself in a short while, but the
sender will need to roll back any permanent action (such as sender will need to roll back any permanent action (such as
billing) that may have been taken on receipt of the phantom Resv. billing) that may have been taken on receipt of the phantom Resv.
Note that if the second receiver is also a Receiver Proxy which is Note that if the second receiver is also a Receiver Proxy that is
not participating in application signalling, it will convert the not participating in application signaling, it will convert the
received ResvError into a PathError which will be received by the received ResvErr into a PathErr that will be received by the
sender. sender.
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
default) will never be responded to. However, these messages by 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 and stop sending Path messages unanswered downstream Path state and stop sending Path messages
for the flow (or only send them at much lower frequency) as for the flow (or only send them at much lower frequency) as
further discussed in [I-D.ietf-tsvwg-rsvp-proxy-proto] . further discussed in [RFC5946].
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 and not for Path messages that are transiting through it but stay
the domain. As another example, the receiver proxy may be within 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
address or destination address ranges (for which end devices are address or destination address ranges (for which end devices are
known to not be RSVP capable). known to not be RSVP-capable).
The decision to proxy a Resv for a Path may also be based on The decision to proxy a Resv for a Path may also be based on
information signalled from the sender in the Path message. For information signaled from the sender in the Path message. For
example, the sender may identify the type of application or flow in example, the sender may identify the type of application or flow in
the Application Identity Policy Element ([RFC2872]) in the Path, and the Application Identity policy element ([RFC2872]) in the Path, and
the Receiver Proxy may be configured to proxy for only certain types the Receiver Proxy may be configured to proxy for only certain types
of flows. Or, if the sender knows (for example through application of flows. Or, if the sender knows (for example, through application
signalling) that the receiver is RSVP capable, the sender can include signaling) that the receiver is RSVP-capable, the sender can include
an indication in a Policy Element to any Receiver Proxy that it ought an indication in a policy element to any Receiver Proxy that it ought
not to terminate the Path (or conversely, if the receiver is known not to terminate the Path (or conversely, if the receiver is known
not to support RSVP, the sender could include an indication to not to support RSVP, the sender could include an indication to
Receiver Proxies that they ought to generate a proxy Resv message). Receiver Proxies that they ought to generate a proxy Resv message).
The Receiver Proxy Control Policy Element specified in section 4.2 of The Receiver Proxy Control policy element specified in Section 4.2 of
[I-D.ietf-tsvwg-rsvp-proxy-proto] can be used for that purpose. [RFC5946] can be used for that purpose.
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 synchronization 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 receiver (for the RSVP proxy uses the RSVP signaling generated by the receiver (for
the reverse direction) as the cue for initiating RSVP signaling for the reverse direction) as the cue for initiating RSVP signaling for
the reservation in the reverse direction. More precisely, the RSVP the reservation in the reverse direction. More precisely, the RSVP
Proxy can take the creation (respectively, maintenance and teardown) proxy can take the creation (or maintenance or teardown) of a Path
of a Path state by the receiver as the cue to create (respectively, state by the receiver as the cue to create (or maintain or tear down,
maintain and teardown) a Path state towards the receiver. Thus, the respectively) a Path state towards the receiver. Thus, the RSVP
RSVP Proxy is effectively acting as a Sender Proxy for the reverse 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
in terms of bandwidth for the two directions of the flow (as is example, in terms of bandwidth for the two directions of the flow (as
currently typical for IP telephony, for example). is currently typical for IP telephony).
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 6. 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 an 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 |
skipping to change at page 17, line 46 skipping to change at page 16, line 38
| 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 6: 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 7. 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 |
skipping to change at page 18, line 35 skipping to change at page 17, line 35
|****| 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 7: Path Triggered Receiver & Sender Proxy Figure 7: Path Triggered Receiver and 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.
2. behaves as if a Path message for reverse direction (whose details 2. behaves as if a Path message for the reverse direction (whose
are discussed below) had been received by the Sender Proxy. This details are discussed below) had been received by the Sender
includes establishing the corresponding Path state, forwarding Proxy. This includes establishing the corresponding Path state,
the Path message downstream, sending periodic refreshes of the forwarding the Path message downstream, sending periodic
Path message and tearing down the Path in reverse direction when refreshes of the Path message, and tearing down the Path in the
the Path state in forward direction is torn down. reverse direction when the Path state in the forward direction is
torn down.
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 7), 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 need 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
forward reservation also acts as the trigger for establishment of the the forward reservation also acts as the trigger for establishment of
reverse reservation. However, in the case where a reservation is the reverse reservation. However, in the case where a reservation is
only required in the reverse direction (as shown in Figure 6), 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 of
[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
In this approach, it is assumed that the RSVP Proxy is on the In this approach, it is assumed that the RSVP proxy is on the data
datapath of "packets of interest", that it can inspect such packets path of "packets of interest", that it can inspect such packets on
on the fly as they transit through it, and that it can infer the fly as they transit through it, and that it can infer information
information from these packets of interest to determine what RSVP from these packets of interest to determine what RSVP reservations
reservations need to be established, when and with what need to be established, as well as when and with what characteristics
characteristics (possibly also using some configured information). (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 capable of inspecting SIP signaling for signaling. An RSVP proxy capable of inspecting SIP signaling for a
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 8. Figure 8.
|-------------| |-------------|
| Application | | Application |
| Signaling | | Signaling |
| Entity | | Entity |
|-------------| |-------------|
/ \ / \
/ \ / \
skipping to change at page 20, line 28 skipping to change at page 19, line 28
|********| |********| |********| |********|
=======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 8: 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., the Real-time Transport Control Protocol (RTCP)
flow itself (i.e. Media packets). An RSVP Proxy capable of [RFC3550]) traveling alongside the application flow itself (i.e.,
detecting the transit of packets from a particular flow, can attempt media packets). An RSVP proxy capable of detecting the transit of
to establish a reservation corresponding to that flow. packets from a particular flow can attempt to establish a reservation
Characteristics of the reservation may be derived by various methods corresponding to that flow. Characteristics of the reservation may
such as from configuration, flow measurement or a combination of be derived by various methods such as from configuration, flow
those. However, these methods usually come with their respective measurement, or a combination of those. However, these methods
operational drawbacks: configuration involves an operational cost and usually come with their respective operational drawbacks:
may hinder introduction of new applications, measurement is reactive configuration involves an operational cost and may hinder
so that accurate reservation may lag actual traffic. introduction of new applications, and measurement is reactive so that
accurate reservation may lag actual traffic.
In case of reservation failure, the inspection-triggered RSVP Proxy In the case of reservation failure, the Inspection-Triggered RSVP
does not have a direct mechanism for notifying the application (since Proxy does not have a direct mechanism for notifying the application
it is not participating itself actively in application signaling) so (since it is not participating itself actively in application
that the application is not in a position to take appropriate action signaling) so that the application is not in a position to take
(for example terminate the corresponding session). To mitigate this appropriate action (for example, terminate the corresponding
problem, the inspection-triggered RSVP Proxy may mark differently the session). To mitigate this problem, the Inspection-Triggered RSVP
Differentiated Services codepoint (DSCP) ([RFC2474]) of flows for Proxy may differently mark the Differentiated Services codepoint
which an RSVP reservation has been successfully proxied from the (DSCP) ([RFC2474]) of flows for which an RSVP reservation has been
flows for which a reservation is not in place. In some situations, successfully proxied from the flows for which a reservation is not in
the Inspection-Triggered Proxy might be able to modify the "packets place. In some situations, the Inspection-Triggered Proxy might be
of interest" (e.g. Application signaling messages) to convey some able to modify the "packets of interest" (e.g., application signaling
hint to applications that the corresponding flows cannot be messages) to convey some hint to applications that the corresponding
guaranteed by RSVP reservations. flows cannot be guaranteed by RSVP reservations.
With the inspection-triggered Proxy approach, the RSVP Proxy is With the Inspection-Triggered Proxy approach, the RSVP proxy is
effectively required to attempt to build application awareness by effectively required to attempt to build application awareness by
traffic inspection and then is somewhat limited in the actions it can traffic inspection and then is somewhat limited in the actions it can
take in case of reservation failure. Depending on the "packets of take in case of reservation failure. Depending on the "packets of
interest" used by the RSVP Proxy to trigger the reservation, there is interest" used by the RSVP proxy to trigger the reservation, there is
a risk that the RSVP Proxy ends up establishing a reservation for a a risk that the RSVP proxy will end up establishing a reservation for
media flow that actually never starts. However, this can be a media flow that actually never starts. However, this can be
mitigated by timing out and tearing down of an unnecessary mitigated by the timing out and tearing down of an unnecessary
reservation by the RSVP Proxy when no corresponding media flow is reservation by the RSVP proxy when no corresponding media flow is
observed. This flow observation and time out approach can also be observed. This flow observation and timeout approach can also be
used to tear down reservation that were rightfully established for a used to tear down reservations that were rightfully established for a
flow but are no longer needed because the flow stopped. flow but are no longer needed because the flow stopped.
The inspection-triggered approach is also subject to the general The Inspection-Triggered approach is also subject to the general
limitations associated with data inspection. This includes being limitations associated with data inspection. This includes being
impeded by encryption or tunnelling, or being dependent on some impeded by encryption or tunneling, or being dependent on some
topology constraints such as relying on the fact that both the topology constraints such as relying on the fact that both the
packets of interest and the corresponding flow packets always transit packets of interest and the corresponding flow packets always transit
through the same RSVP Proxy. through the same RSVP proxy.
Nonetheless, this may be a useful approach in specific environments. Nonetheless, this may be a useful approach in specific environments.
Note also that this approach does not require any change to the RSVP Note also that this approach does not require any change to the RSVP
protocol. 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.
When operating off signaling traffic, the "Inspection-Triggered" RSVP When operating off signaling traffic, the Inspection-Triggered RSVP
Proxy may be able to detect from the signaling that the endpoint is Proxy may be able to detect from the signaling that the endpoint is
capable of establishing an RSVP reservation (e.g. In the case of SIP capable of establishing an RSVP reservation (e.g., in the case of
via inspection of the [RFC3312]/[RFC4032] Precondition), in which SIP, via the inspection of the [RFC3312]/[RFC4032] precondition), in
case it would not behave as a Proxy for that endpoint . Also, the which case it would not behave as a proxy for that endpoint. Also,
"Inspection-Triggered" RSVP proxy may inspect RSVP signaling and if the Inspection-Triggered RSVP Proxy may inspect RSVP signaling, and
it sees RSVP signaling for the flow of interest, it can disable its if it sees RSVP signaling for the flow of interest, it can disable
sender proxy behavior for that flow (or that sender). Optionally, its Sender Proxy behavior for that flow (or that sender).
through RSVP signaling inspection, the sender proxy might also Optionally, through RSVP signaling inspection, the Sender Proxy might
gradually "learn" (possibly with some timeout) which sender is RSVP also gradually "learn" (possibly with some timeout) which sender is
capable of not. These mechanisms can facilitate gradual and dynamic RSVP-capable and which is not. These mechanisms can facilitate
migration from the Proxy model towards the end-to-end RSVP model as gradual and dynamic migration from the proxy model towards the end-
more and more endpoints become RSVP capable. to-end RSVP model as 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 Session Traversal Utilities for NAT (STUN)
RSVP reservations with application requirements. The STUN signaling ([RFC5389]) signaling to synchronize RSVP reservations with
is sent from endpoint to endpoint. This is illustrated in Figure 9. application requirements. The STUN signaling is sent from endpoint
In this approach, a STUN message triggers the RSVP Proxy. to endpoint. This is illustrated in Figure 9. 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=======>
skipping to change at page 22, line 40 skipping to change at page 21, line 41
|----| |----| *** 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 9: STUN-Triggered Proxy Figure 9: STUN-Triggered Proxy
For unicast flows, [I-D.ietf-mmusic-ice] is a widely-adopted approach For unicast flows, [RFC5245] is a widely adopted approach for Network
for NAT traversal. For our purposes of triggering RSVP Proxy Address Translator (NAT) traversal. For our purposes of triggering
behavior, we rely on ICE's connectivity check which is based on the RSVP proxy behavior, we rely on the Interactive Connectivity
exchange of STUN Binding Request messages between hosts to verify Establishment (ICE) protocol's connectivity check, which is based on
connectivity (see section 2.2 of [I-D.ietf-mmusic-ice]). The STUN the exchange of STUN Binding Request messages between hosts to verify
message could also include (yet to be specified) STUN attributes to connectivity (see Section 2.2 of [RFC5245]). The STUN message could
indicate information such as the bandwidth and application requesting also include (yet to be specified) STUN attributes to indicate
the flow, which would allow the RSVP proxy agent to create an information such as the bandwidth and application requesting the
appropriately-sized reservation for each flow. Including such new flow, which would allow the RSVP proxy agent to create an
appropriately sized reservation for each flow. Including such new
STUN attributes in the ICE connectivity check messages would STUN attributes in the ICE connectivity check messages would
facilitates operation of the RSVP Proxy. To ensure RSVP reservations facilitate operation of the RSVP proxy. To ensure RSVP reservations
are only established when needed, the RSVP Proxy needs to are only established when needed, the RSVP proxy needs to
distinguish, among all the STUN messages, the ones that reflect (with distinguish, among all the STUN messages, the ones that reflect (with
high likelihood) an actual upcoming media flow. This can be achieved high likelihood) an actual upcoming media flow. This can be achieved
by identifying the STUN messages associated with an ICE connectivity by identifying the STUN messages associated with an ICE connectivity
check. In turn, this can be achieved through (some combination of) check. In turn, this can be achieved through (some combination of)
the following checks: the following checks:
o if, as discussed above, new STUN attributes (e.g. Conveying the o if, as discussed above, new STUN attributes (e.g., conveying the
flow bandwidth) are indeed defined in the future in view of flow bandwidth) are indeed defined in the future in view of
facilitating STUN-Triggered reservations, then the presence of facilitating STUN-Triggered reservations, then the presence of
these attributes would reveal that the STUN message is part of an these attributes would reveal that the STUN message is part of an
ICE connectivity check. ICE connectivity check.
o the presence of the PRIORITY, USE-CANDIDATE, ICE-CONTROLLED or o the presence of the PRIORITY, USE-CANDIDATE, ICE-CONTROLLED, or
ICE-CONTROLLING attributes reveals that the STUN message is part ICE-CONTROLLING attributes reveals that the STUN message is part
of an ICE connectivity check of an ICE connectivity check.
o the RSVP Proxy may wait for a STUN message containing the USE- o the RSVP proxy may wait for a STUN message containing the USE-
CANDIDATE attribute indicating the selected ICE "path" to trigger CANDIDATE attribute indicating the selected ICE "path" to trigger
reservation only for the selected "path". This allows the RSVP reservation only for the selected "path". This allows the RSVP
Proxy to only trigger a reservation for the "path" actually proxy to only trigger a reservation for the "path" actually
selected and therefore for the media flow that will actually be selected and therefore for the media flow that will actually be
established (for example when ICE is being used for v4/v6 path established (for example, when ICE is being used for IPv4/v6 path
selection). selection).
o the RSVP Proxy configuration could contain some information o the RSVP proxy configuration could contain some information
facilitating determination of when to perform RSVP Proxy facilitating determination of when to perform RSVP proxy
reservation and not. For example, the RSVP Proxy configuration reservation and when not to. For example, the RSVP proxy
could contain the IP addresses of the STUN servers such that STUN configuration could contain the IP addresses of the STUN servers
messages to/from those addresses are known to not be part of an such that STUN messages to/from those addresses are known to not
ICE connectivity check. As another example, the RSVP Proxy be part of an ICE connectivity check. As another example, the
configuration could contain information identifying the set of RSVP proxy configuration could contain information identifying the
Differentiated Services codepoint (DSCP) values that the media set of Differentiated Services codepoint (DSCP) values that the
flows requiring reservation use, so that STUN messages not using media flows requiring reservation use, so that STUN messages not
one of these DSCP values are known to not be part of an ICE using one of these DSCP values are known to not be part of an ICE
connectivity check. connectivity check.
Despite these checks, there is always a potential risk that the RSVP Despite these checks, there is always a potential risk that the RSVP
Proxy ends up establishing a reservation for a media flow that proxy will end up establishing a reservation for a media flow that
actually never starts. However, this is limited to situations where actually never starts. However, this is limited to situations in
the end-systems is interested enough in establishing connectivity for which the end-systems are interested enough in establishing
a flow but yet never transmit. Also, this can be mitigated by timing connectivity for a flow but never transmit. Also, this can be
out and tear down of an unnecessary reservations by the RSVP Proxy mitigated by timing out and tear down of an unnecessary reservation
when no corresponding media flow is observed. by the RSVP proxy when no corresponding media flow is observed.
The RSVP Proxy agent can inform endpoints of an RSVP reservation The RSVP proxy agent can inform endpoints of an RSVP reservation
failure implicitly by dropping the ICE connectivity check message or failure implicitly by dropping the ICE connectivity check message or
explicitly by sending ICMP messages back to the endpoint. This explicitly by sending ICMP messages back to the endpoint. This
allows reasonably effective synchronisation between RSVP reservations allows reasonably effective synchronization between RSVP reservations
handled by the RSVP Proxies and the application running on non RSVP- handled by the RSVP proxies and the application running on non-RSVP-
capable endpoints. It also has the benefits of operating through capable endpoints. It also has the benefits of operating through
NATs. NATs.
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 [RFC5389] could be used to can't use ICE), a STUN Indication message [RFC5389] could be used to
carry the (yet to be defined) STUN attributes mentioned earlier to carry the (yet to be defined) STUN attributes mentioned earlier to
indicate the flow bandwidth, thereby providing a benefit similar to indicate the flow bandwidth, thereby providing a benefit similar to
the ICE connectivity check. STUN Indication messages are not the ICE connectivity check. STUN Indication messages are not
acknowledged by the receiver and have the same scalability as the acknowledged by the receiver and have the same scalability as the
underlying multicast flow. underlying multicast flow.
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. As the They may be defined in the future in a separate document. As the
STUN-triggered RSVP Proxy approach uses STUN in a way (i.e. To STUN-Triggered RSVP Proxy approach uses STUN in a way (i.e., to
trigger reservations) that is beyond its initial intended purpose, trigger reservations) that is beyond its initial intended purpose,
the potential security implications need to be considered by the the potential security implications need to be considered by the
operator. operator.
ICE connectivity checks is not always used for all flows. When the ICE connectivity checks are not always used for all flows. When the
STUN-triggered RSVP Proxy approach is used, it can establish RSVP STUN-Triggered RSVP Proxy approach is used, it can establish RSVP
reservations for flows for which ICE connectivity is performed. reservations for flows for which ICE connectivity is performed.
However, the STUN-triggered RSVP Proxy will not establish a However, the STUN-Triggered RSVP Proxy will not establish a
reservation for flows for which ICE connectivity check is not reservation for flows for which an ICE connectivity check is not
performed. Those flows will either not benefit from an RSVP performed. Those flows either will not benefit from an RSVP
reservation or can benefit from an RSVP reservation established reservation or can benefit from an RSVP reservation established
through other means (end-to-end RSVP, other forms of RSVP Proxy). through other means (end-to-end RSVP, other forms of RSVP proxy).
The STUN-triggered approach relies on interception and inspection of The STUN-Triggered approach relies on interception and inspection of
STUN messages. Thus, this approach may be impeded by encryption or STUN messages. Thus, this approach may be impeded by encryption or
tunneling. tunneling.
4.5. Application_Entity-Controlled 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 which is located application-level signaling controls an RSVP proxy that is located in
in the datapath of the application flows (i.e. "on-path"). With this the data path of the application flows (i.e., "on-path"). With this
approach, the RSVP Proxy does not attempt to determine itself the approach, the RSVP proxy does not itself attempt to determine the
application reservation requirements. Instead the RSVP Proxy is application reservation requirements. Instead, the RSVP proxy is
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 data path. 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 10. in Figure 10.
|---------| |---------| |---------| |---------|
/////////| App |////\\\\| App |\\\\\\\\ /////////| App |////\\\\| App |\\\\\\\\
/ | Entity | | Entity | \ / | Entity | | Entity | \
/ |---------| |---------| \ / |---------| |---------| \
/ // \\ \ / // \\ \
skipping to change at page 25, line 39 skipping to change at page 24, line 40
********************************************************> ********************************************************>
|----| 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 10: 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 [RFC5853] for a description of SBCs) to establish RSVP
establish RSVP reservations for multimedia sessions. In that case, reservations for multimedia sessions. In that case, the application
the Application Entity may be the signaling component of the SBC. 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
entity. This RSVP Proxy control interface is beyond the scope of the entity. This RSVP proxy control interface is beyond the scope of
present document. Candidate protocols for realizing such interface this document. Candidate protocols for realizing such an interface
include the IETF NETCONF configuration protocol include the IETF Network Configuration (NETCONF) Protocol ([RFC4741],
([RFC4741],[RFC5277]), Web Services protocol ([W3C]), QPIM [RFC5277]), the Web Services protocol ([W3C]), the QoS Policy
([RFC3644]) and DIAMETER ([RFC3588]). This interface can rely on Information Model (QPIM) ([RFC3644]), and Diameter ([RFC3588]). This
soft states or hard states. Clearly, when hard states are used, interface can rely on soft states or hard states. Clearly, when hard
those need to be converted appropriately by the RSVP Proxy entities states are used, those need to be converted appropriately by the RSVP
into the corresponding RSVP soft states. As an example, proxy entities into the corresponding RSVP soft states. As an
[I-D.ietf-dime-diameter-qos] is intended to allow control of RSVP example, [RFC5866] is intended to allow control of RSVP proxy via
Proxy via DIAMETER. Diameter.
In general, the Application Entity is not expected to maintain In general, the application entity is not expected to maintain
awareness of which RSVP Receiver Proxy is on the path to which awareness of which RSVP Receiver Proxy is on the path to which
destination. However, in the particular cases where it does so destination. However, in the particular cases where it does so
reliably, we observe that the Application Entity could control the reliably, we observe that the application entity could control the
RSVP Sender Proxy and Receiver Proxy so that aggregate RSVP RSVP Sender Proxy and Receiver Proxy so that aggregate RSVP
reservations are used between those, instead of one reservation per reservations are used between those, instead of one reservation per
flow. For example, these aggregate reservations could be of RSVP- flow. For example, these aggregate reservations could be of the
AGGREGATE type as specified in [RFC3175] or of GENERIC-AGGREGATE type RSVP-AGGREGATE type, as specified in [RFC3175], or of the GENERIC-
as specified in [RFC4860]. Such aggregate reservations could be used AGGREGATE type, as specified in [RFC4860]. Such aggregate
so that a single reservation can be used for multiple (possibly all) reservations could be used so that a single reservation can be used
application flows transiting via the same RSVP Sender Proxy and the for multiple (possibly all) application flows transiting via the same
same RSVP Receiver Proxy. RSVP Sender Proxy and the same RSVP Receiver Proxy.
For situations where only the RSVP Sender Proxy has to be controlled For situations in which only the RSVP Sender Proxy has to be
by this interface, the interface may be realized through the simple controlled by this interface, the interface may be realized through
use of RSVP itself, over a GRE tunnel from the application entity to the simple use of RSVP itself, over a Generic Routing Encapsulation
the RSVP Sender Proxy. This particular case is further discussed in (GRE) tunnel from the application entity to the RSVP Sender Proxy.
Section 4.5.1. Another particular case of interest is where the This particular case is further discussed in Section 4.5.1. Another
application signaling entity resides on the same device as the RSVP particular case of interest is where the application signaling entity
Proxy. In that case, this interface may be trivially realized as an resides on the same device as the RSVP proxy. In that case, this
internal API. An example environment based on this particular case interface may be trivially realized as an internal API. An example
is illustrated in Section 4.5.2. environment based on this particular case is illustrated in
Section 4.5.2.
The application entity controlling the RSVP Proxy (e.g. a SIP Call The application entity controlling the RSVP proxy (e.g., a SIP Call
Agent) would often be aware of a number of endpoint capabilities and Agent) would often be aware of a number of endpoint capabilities, and
it has to be aware about which endpoint can be best "served" by which it has to be aware of which endpoint can be best "served" by which
RSVP Proxy anyways. So it is reasonable to assume that such an RSVP proxy anyways. So it is reasonable to assume that such an
application is aware of whether a given endpoint is RSVP-capable or application is aware of whether a given endpoint is RSVP-capable or
not. The application may also consider the QoS preconditions and QoS not. The application may also consider the QoS preconditions and QoS
mechanisms signaled by an endpoint as per [RFC3312]/[RFC4032] and mechanisms signaled by an endpoint as per [RFC3312]/[RFC4032] and
[RFC5432]. The information about endpoint RSVP capability can then [RFC5432]. The information about endpoint RSVP capability can then
be used by the application to decide whether to trigger Proxy be used by the application to decide whether to trigger proxy
behavior or not for a given endpoint. This can facilitate gradual behavior or not for a given endpoint. This can facilitate gradual
and dynamic migration from the Proxy model towards the end-to-end and dynamic migration from the proxy model towards the end-to-end
RSVP model as more and more endpoints become RSVP capable. RSVP model as more and more endpoints become RSVP-capable.
In some environments, the application entities (e.g. SIP Back-to- In some environments, the application entities (e.g., SIP back-to-
Back User Agents) that need to control the RSVP Proxies would already back user agents) that need to control the RSVP proxies would already
be deployed independently of the use, or not, of the be deployed independently of the use, or not, of the
Application_Entity-Controlled Proxy approach. In this case, the Application_Entity-Controlled Proxy approach. In this case, the
activation of the RSVP Proxy approach should not introduce activation of the RSVP proxy approach should not introduce
significant disruption in the application signaling path. In some significant disruption in the application signaling path. In some
environments, additional application entities may need to be deployed environments, additional application entities may need to be deployed
to control the RSVP Proxies. In this case, the network operator to control the RSVP proxies. In this case, the network operator
needs to consider the associated risks of disruption to the needs to consider the associated risks of disruption to the
application signaling path. application signaling path.
4.5.1. Application_Entity-Controlled Sender Proxy using "RSVP over GRE" 4.5.1. Application_Entity-Controlled Sender Proxy Using "RSVP over GRE"
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 only RSVP Sender Application_Entity-Controlled Proxy, but where only RSVP Sender
Proxies need to be controlled by the application, and where RSVP is Proxies need to be controlled by the application, and where RSVP is
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 "tunneled" 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 that is to be subject to RSVP reservations.
Figure 11 illustrates such an environment. Figure 11 illustrates such an environment.
|-------------| |-------------|
////////////| Application |\\\\\\\\\ ////////////| Application |\\\\\\\\\
/ | Entity | \ / | Entity | \
/ |-------------| \ / |-------------| \
/ /=/ \ / /=/ \
/ /=/ \ / /=/ \
/ /=/ \ / /=/ \
skipping to change at page 28, line 35 skipping to change at page 27, line 35
*****************************************************> *****************************************************>
|----| 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-tunneled RSVP (Path messages)
Figure 11: Application-Entity-Controlled Sender Proxy via "RSVP over Figure 11: Application_Entity-Controlled Sender Proxy via
GRE" "RSVP over 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,
which is that the Application Entity puts its own IP address as which is that the application entity puts its own IP address as
the RSVP Previous Hop. In particular, it is recommended that the the RSVP previous hop. In particular, it is recommended that the
source address of the Path message built by the application entity source address of the Path message built by the application entity
be set to the IP address of the sender (not of the application be set to the IP address of the sender (not of the application
entity). This helps ensuring that, in the presence of non-RSVP entity). This helps ensure that, in the presence of non-RSVP
routers and of load-balancing in the network where the load- routers and of load-balancing in the network where the load-
balancing algorithm takes into account the source IP address, the balancing algorithm takes into account the source IP address, the
Path message generated by the application entity follows the exact Path message generated by the application entity follows the exact
same path that the actual stream sourced by the sender. same path as 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 the RSVP Sender Proxy i.e. An RSVP Router sitting on address is the RSVP Sender Proxy, i.e., an RSVP router sitting on
the datapath for the flow (and upstream of the segment which the data path for the flow (and upstream of the segment that
requires QoS guarantees via 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 synchronizes 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 application entity encodes its own IP address as Note that since the application entity encodes its own IP address as
the previous RSVP hop inside the [RFC2205] RSVP_HOP object of the the previous RSVP hop inside the [RFC2205] RSVP_HOP object of the
Path message, the RSVP Router terminating the GRE tunnel naturally Path message, the RSVP router terminating the GRE tunnel naturally
addresses all the RSVP messages travelling upstream hop-by-hop (such addresses all the RSVP messages traveling upstream hop-by-hop (such
as Resv messages) to the application entity (without having to as Resv messages) to the application entity (without having to
encapsulate those in a reverse-direction GRE tunnel towards the encapsulate those in a reverse-direction GRE tunnel towards the
application entity). application entity).
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 (SBCs) with on-board SIP agents could implement RSVP
functions and make use of such an approach to achieve session proxy 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 12 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 |
|*********| |*********| |*********| |*********|
skipping to change at page 30, line 27 skipping to change at page 29, line 27
*******************************************************> *******************************************************>
|----| 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 12: 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
In this approach, it is assumed that a Policy Server, which is In this approach, it is assumed that a policy server, which is
located in the control plane of the network, controls an RSVP Proxy 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- that is located in the data path of the application flows (i.e., "on-
path"). In turn, the Policy server is triggered by an entity path"). In turn, the policy server is triggered by an entity
involved in the application level signaling. With this approach, the involved in the application-level signaling. With this approach, the
RSVP Proxy does not attempt to determine itself the application RSVP proxy does not itself attempt to determine the application
reservation requirements, but instead is instructed by the Policy reservation requirements, but instead is instructed by the policy
Server to establish, maintain and tear down reservations as needed by server to establish, maintain, and tear down reservations as needed
the application flows. Moreover, the entity participating in by the application flows. Moreover, the entity participating in
application level signaling does not attempt to understand the application-level signaling does not attempt to understand the
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 data path. 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 in
Figure 13. Figure 13.
|---------| |---------|
/////////////| App |\\\\\\\\\\\\\\ /////////////| App |\\\\\\\\\\\\\\
/ | Entity | \ / | Entity | \
/ |---------| \ / |---------| \
/ I \ / I \
/ I \ / I \
/ |----------| \ / |----------| \
/ | Policy | \ / | Policy | \
skipping to change at page 32, line 37 skipping to change at page 31, line 37
**********************************************************> **********************************************************>
|----| 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 13: 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 10, this approach relies on an RSVP approach presented in Figure 10, this approach relies on an RSVP
Proxy control interface allowing control of the RSVP Proxy (by the proxy control interface allowing control of the RSVP proxy (by the
Policy Server in this case). This RSVP Proxy control interface is policy server in this case). This RSVP proxy control interface is
beyond the scope of the present document. Considerations about beyond the scope of this document. Considerations about candidate
candidate protocols for realizing such interface can be found in protocols for realizing such an interface can be found in
Section 4.5. Again, for situations where only the RSVP Sender Proxy Section 4.5. Again, for situations in which only the RSVP Sender
has to be controlled by this interface, the interface may be realized Proxy has to be controlled by this interface, the interface may be
through the simple use of RSVP Itself, over a GRE tunnel from the realized through the simple use of RSVP itself, over a GRE tunnel
Policy Server to the RSVP Sender Proxy. This is similar to what is from the policy server to the RSVP Sender Proxy. This is similar to
presented in Section 4.5.1 except that the "RSVP over GRE" interface what is presented in Section 4.5.1, except that the "RSVP over GRE"
is used in this case by the Policy Server (instead of the application interface is used in this case by the policy server (instead of the
entity). application 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
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 explicitly capable sender could send a new or extended RSVP message explicitly
requesting an RSVP Proxy on the path towards the receiver to behave requesting an RSVP proxy on the path towards the receiver to behave
as an RSVP Receiver Proxy and also to trigger a reverse direction as an RSVP Receiver Proxy and also to trigger a reverse-direction
reservation thus also behaving as a RSVP Sender Proxy. The new or reservation, thus also behaving as an RSVP Sender Proxy. The new 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 include: The challenges in these explicit signaling schemes include the
following:
o How can the nodes determine when a reservation request ought to be o How can the nodes determine when a reservation request ought to be
proxied and when it should not, and accordingly invoke appropriate proxied and when it should not, and accordingly invoke appropriate
signaling procedures? signaling procedures?
o How does the node sending the messages explicitly triggering the o How does the node sending the messages explicitly triggering the
Proxy know where the Proxy is located, e.g., determine an IP proxy know where the proxy is located, e.g., determine an IP
address of the proxy that should reply to the signaling? address of the proxy that should reply to the signaling?
o How is all the information needed by a Sender Proxy to generate a o How is all the information needed by a Sender Proxy to generate a
Path message actually communicated to the Proxy? 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 [QOS-MOBILE]. This
[I-D.manner-tsvwg-rsvp-proxy-sig]. This scheme is primarily targeted scheme is primarily targeted to local access network reservations
to local access network reservations whereby an end host can request whereby an end host can request resource reservations for both
resource reservations for both incoming and outgoing flows only over incoming and outgoing flows only over the access network. This may
the access network. This may be useful in environments where the be useful in environments where the access network is typically the
access network is typically the bottleneck while the core is bottleneck while the core is comparatively over-provisioned, as may
comparatively over-provisioned, as may be the case with a number of be the case with a number of radio access technologies. In this
radio access technologies. In this proposal, messages targeted to proposal, messages targeted to the proxy are flagged with one bit in
the Proxy are flagged with one bit in all RSVP messages. Similarly, all RSVP messages. Similarly, all RSVP messages sent back by the
all RSVP messages sent back by the Proxy are also flagged. The use proxy are also flagged. The use of such a flag allows
of such a flag allows differentiating between proxied and end-to-end differentiating between proxied and end-to-end reservations. For
reservations. For triggering an RSVP Receiver Proxy, the sender of triggering an RSVP Receiver Proxy, the sender of the data sends a
the data sends a Path message which is marked with the mentioned Path message that is marked with the mentioned flag. The Receiver
flag. The Receiver Proxy is located on the signaling and data path, Proxy is located on the signaling and data path, eventually gets the
eventually gets the Path message, and replies back with a Resv Path message, and replies back with a Resv message. A node triggers
message. A node triggers an RSVP Sender Proxy with a newly defined an RSVP Sender Proxy with a newly defined Path_Request message, which
Path_Request message, which instructs the proxy to send Path messages instructs the proxy to send Path messages towards the triggering
towards the triggering node. The node then replies back with a Resv. node. The node then replies back with a Resv. More details can be
More details can be found in [I-D.manner-tsvwg-rsvp-proxy-sig]. found in [QOS-MOBILE].
Such an RSVP-Signaling-Triggered Proxy approach would require RSVP Such an RSVP-Signaling-Triggered Proxy approach would require RSVP
signaling extensions (that are outside the scope of the present signaling extensions (that are outside the scope of this document).
document). However it could provide more flexibility in the control However, it could provide more flexibility in the control of the
of the Proxy behavior (e.g. Control of reverse reservation proxy behavior (e.g., control of reverse reservation parameters) than
parameters) than provided by the Path-Triggered approaches defined in would the Path-Triggered approaches defined in Section 4.1 and
Section 4.1 and Section 4.2. Section 4.2.
Through potential corresponding protocol extensions, an RSVP- Through potential corresponding protocol extensions, an RSVP-
Signaling-Triggered Proxy approach could facilitate operation (e.g. Signaling-Triggered Proxy approach could facilitate operation (e.g.,
Reduce or avoid the need for associated configuration) in hybrid reduce or avoid the need for associated configuration) in hybrid
environments involving both reservations established end-to-end and environments involving both reservations established end-to-end and
reservations established via RSVP Proxies. For reservations established via RSVP proxies. For example, [QOS-MOBILE]
example,[I-D.manner-tsvwg-rsvp-proxy-sig] proposed a mechanism proposed a mechanism allowing an end-system to control whether a
allowing an end-system to control whether a reservation can be reservation can be handled by an RSVP proxy on the path, or is to be
handled by an RSVP Proxy on the path or is to be established end-to- established end-to-end.
end.
4.8. Reachability Considerations 4.8. Reachability Considerations
There may be situations where the RSVP Receiver Proxy is reachable by There may be situations in which the RSVP Receiver Proxy is reachable
the sender, while the receiver itself is not. In such situations, it by the sender, while the receiver itself is not. In such situations,
is possible that the RSVP Receiver Proxy is not always aware that the it is possible that the RSVP Receiver Proxy is not always aware that
receiver is unreachable, and consequently may accept to establish an the receiver is unreachable, and consequently may accept to establish
RSVP reservation on behalf of that receiver. This would result in an RSVP reservation on behalf of that receiver. This would result in
unnecessary reservation establishment and unnecessary network unnecessary reservation establishment and unnecessary network
resource consumption. resource consumption.
This is not considered a significant practical concern for a number This is not considered a significant practical concern for a number
of reasons. First, in many cases, if the receiver is not reachable of reasons. First, in many cases, if the receiver is not reachable
from the sender, it will not be reachable either for application from the sender, it will not be reachable for application signaling
signaling so that application level session establishment will not be either, and so application-level session establishment will not be
possible in the first place. Secondly, where the receiver is possible in the first place. Secondly, where the receiver is
unreachable from the sender but is reachable for application level unreachable from the sender but is reachable for application-level
signaling (say because session establishment is performed through an signaling (say, because session establishment is performed through an
off-path SIP agent that uses a different logical topology to off-path SIP agent that uses a different logical topology to
communicate with the receiver), then the sender may detect that the communicate with the receiver), then the sender may detect that the
receiver is unreachable before attempting reservation establishment. receiver is unreachable before attempting reservation establishment.
This may be achieved through mechanisms such as ICE's connectivity This may be achieved through mechanisms such as ICE's connectivity
check ( [I-D.ietf-mmusic-ice]). Finally, even if the sender does not check ([RFC5245]). Finally, even if the sender does not detect that
detect that the receiver is unreachable before triggering the RSVP the receiver is unreachable before triggering the RSVP reservation
reservation establishment, it is very likely that the application establishment, it is very likely that the application will quickly
will quickly realise this lack of connectivity (e.g. The human realize this lack of connectivity (e.g., the human accepting the
accepting the phone call on the receiver side will not hear the phone call on the receiver side will not hear the human's voice on
human's voice on the sender side) and therefore tear down the session the sender side) and therefore tear down the session (e.g., hang up
(e.g. Hang up the phone) which in turn will trigger RSVP reservation the phone), which in turn will trigger RSVP reservation release.
release.
Nonetheless, it is recommended that network administrators consider Nonetheless, it is recommended that network administrators consider
the above in light of their particular environment when deploying the above in light of their particular environment when deploying
RSVP Proxys. RSVP proxies.
The mirror considerations apply for situations involving an RSVP The mirror considerations apply for situations involving an RSVP
Sender Proxy and where the sender cannot reach the destination while Sender Proxy and where the sender cannot reach the destination while
the RSVP Sender Proxy can. the RSVP Sender Proxy can.
5. Security Considerations 5. Security Considerations
In the environments of concern for 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. The general security considerations associated with path of flows. The general security considerations associated with
[RFC2205] apply. To ensure the integrity of the associated [RFC2205] apply. To ensure the integrity of the associated
reservation and admission control mechanisms, the RSVP cryptographic reservation and admission control mechanisms, the RSVP cryptographic
authentication mechanisms defined in [RFC2747]] and [RFC3097] can be authentication mechanisms defined in [RFC2747] and [RFC3097] can be
used. Those protect RSVP messages integrity hop-by-hop and provide used. Those protect RSVP messages integrity hop-by-hop and provide
node authentication, thereby protecting against corruption, spoofing node authentication, thereby protecting against corruption, spoofing
of RSVP messages and replay. of RSVP messages, and replay. [RSVP-SEC-KEY] discusses key types and
[I-D.ietf-tsvwg-rsvp-security-groupkeying] discusses key types and key provisioning methods, as well as their respective applicability
key provisioning methods as well as their respective applicability to to RSVP authentication.
RSVP authentication.
[I-D.ietf-tsvwg-rsvp-security-groupkeying] also discusses [RSVP-SEC-KEY] also discusses applicability of IPsec mechanisms
applicability of IPsec mechanisms ([RFC4303], [RFC4303]) and ([RFC4302][RFC4303]) and associated key provisioning methods for
associated key provisioning methods for security protection of RSVP. security protection of RSVP. This discussion applies to the
This discusion applies to the protection of RSVP in the presence of protection of RSVP in the presence of RSVP proxies as defined in this
RSVP Proxies as defined in the present document. document.
A subset of RSVP messages are signaled with the router alert option A subset of RSVP messages are signaled with the IP router alert
([RFC2113],[RFC2711]). Based on the current security concerns option ([RFC2113], [RFC2711]). Based on the current security
associated with the use of the IP router alert option, the concerns associated with the use of the IP router alert option, the
applicability of RSVP (and therefore of the RSVP Proxy approaches applicability of RSVP (and therefore of the RSVP proxy approaches
discussed in the present document) is limited to controlled discussed in this document) is limited to controlled environments
environments (i.e. Environments where the security risks associated (i.e., environments where the security risks associated with the use
with the use of the router alert option are understood and protected of the IP router alert option are understood and protected against).
against). The security aspects and common practices around the use The security aspects and common practices around the use of the
of the current IP router alert option and consequences of using the current IP router alert option, and consequences of using the IP
IP router alert option by applications such as RSVP are discussed in router alert option by applications such as RSVP, are discussed in
details in [I-D.rahman-rtg-router-alert-considerations]. detail in [RTR-ALERT].
A number of additional security considerations apply to the use of A number of additional security considerations apply to the use of
RSVP proxies and are discussed below. RSVP proxies and are discussed below.
With some RSVP Proxy approaches, the RSVP proxy operates autonomously With some RSVP proxy approaches, the RSVP proxy operates autonomously
inside an RSVP router. This is the case for the Path-Triggered Proxy inside an RSVP router. This is the case for the Path-Triggered Proxy
approaches defined in Section 4.1 and in Section 4.2, for the approaches defined in Section 4.1 and in Section 4.2, for the
Inspection-Triggered Proxy approach defined in Section 4.3, for the Inspection-Triggered Proxy approach defined in Section 4.3, for the
STUN-Triggered Proxy approach defined in Section 4.4 and for the STUN-Triggered Proxy approach defined in Section 4.4, and for the
RSVP-Signaling-Triggered approach defined in Section 4.7. Proper RSVP-Signaling-Triggered approach defined in Section 4.7. Proper
reservation operation assumes that the RSVP proxy can be trusted to reservation operation assumes that the RSVP proxy can be trusted to
behave correctly in order to control the RSVP reservation as required behave correctly in order to control the RSVP reservation as required
and expected by the end systems. Since, the basic RSVP operation and expected by the end-systems. Since the basic RSVP operation
already assumes a trust model where end-systems trust RSVP nodes to already assumes a trust model where end-systems trust RSVP nodes to
appropriately perform RSVP reservations, the use of RSVP proxy that appropriately perform RSVP reservations, the use of an RSVP proxy
behave autonomously within an RSVP router is not seen as introducing that behaves autonomously within an RSVP router is not seen as
any significant additional security threat or as fundamentally introducing any significant additional security threat or as
modifying the RSVP trust model. fundamentally modifying the RSVP trust model.
With some RSVP Proxy approaches, the RSVP proxy operates under the With some RSVP proxy approaches, the RSVP proxy operates under the
control of another entity. This is the case for the control of another entity. This is the case for the
Application_Entity-Controlled Proxy approach defined in Section 4.5 Application_Entity-Controlled Proxy approach defined in Section 4.5
and for the Policy_Server-Controlled Proxy approach defined in and for the Policy_Server-Controlled Proxy approach defined in
Section 4.6. This introduces additional security risks since the Section 4.6. This introduces additional security risks since the
entity controlling the RSVP Proxy needs to be trusted for proper entity controlling the RSVP proxy needs to be trusted for proper
reservation operation and also introduces additional authentication reservation operation and also introduces additional authentication
and confidentiality requirements. The exact mechanisms to establish and confidentiality requirements. The exact mechanisms to establish
such trust, authentication and confidentiality are beyond the scope such trust, authentication, and confidentiality are beyond the scope
of this document, but they may include security mechanisms inside the of this document, but they may include security mechanisms inside the
protocol used as the control interface between the RSVP Proxy and the protocol used as the control interface between the RSVP proxy and the
entity controlling it, as well as security mechanisms for all the entity controlling it, as well as security mechanisms for all the
interfaces involved in the reservation control chain (e.g. Inside interfaces involved in the reservation control chain (e.g., inside
the application signaling protocol between the end systems and the the application signaling protocol between the end-systems and the
application entity, and, in the case of the Policy_Server-Controlled application entity, and, in the case of the Policy_Server-Controlled
Proxy approach, in the protocol between the application entity and Proxy approach, in the protocol between the application entity and
the policy server). the policy server).
In some situations, the use of RSVP Proxy to control reservations on In some situations, the use of RSVP proxy to control reservations on
behalf of end-systems may actually reduce the security risk (at least behalf of end-systems may actually reduce the security risk (at least
from the network operator viewpoint). This could be the case, for from the network operator viewpoint). This could be the case, for
example, because the routers where the RSVP Proxy functionality runs example, because the routers where the RSVP proxy functionality runs
are less exposed to tampering than end-systems. Such a case is 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]. further discussed in Section 4 of [RFC5946]. This could also be the
This could also be the case because the use of RSVP Proxy allows case because the use of RSVP proxy allows localization of RSVP
localization of RSVP operation within the boundaries of a given operation within the boundaries of a given administrative domain
administrative domain (thus easily operating as a controlled (thus easily operating as a controlled environment) while the end-to-
environment) while the end-to-end flow path spans multiple end flow path spans multiple administrative domains.
administrative domains.
6. IANA Considerations
This document does not make any request to IANA registration.
7. Acknowledgments 6. 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. Tullio with Pratik Bose, Chris Christou, and Michael Davenport. Tullio
Loffredo and Massimo Sassi provided the base material for Loffredo and Massimo Sassi provided the base material for
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
and comments. review and comments.
8. References
8.1. Normative References 7. References
[I-D.ietf-mmusic-ice] 7.1. Normative References
Rosenberg, J., "Interactive Connectivity Establishment
(ICE): A Protocol for Network Address Translator (NAT)
Traversal for Offer/Answer Protocols",
draft-ietf-mmusic-ice-19 (work in progress), October 2007.
[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.
[RFC2747] Baker, F., Lindell, B., and M. Talwar, "RSVP Cryptographic [RFC2747] Baker, F., Lindell, B., and M. Talwar, "RSVP Cryptographic
Authentication", RFC 2747, January 2000. Authentication", RFC 2747, January 2000.
[RFC3097] Braden, R. and L. Zhang, "RSVP Cryptographic [RFC3097] Braden, R. and L. Zhang, "RSVP Cryptographic
Authentication -- Updated Message Type Value", RFC 3097, Authentication -- Updated Message Type Value", RFC 3097,
April 2001. April 2001.
[RFC5245] Rosenberg, J., "Interactive Connectivity Establishment
(ICE): A Protocol for Network Address Translator (NAT)
Traversal for Offer/Answer Protocols", RFC 5245,
April 2010.
[RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, [RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing,
"Session Traversal Utilities for NAT (STUN)", RFC 5389, "Session Traversal Utilities for NAT (STUN)", RFC 5389,
October 2008. October 2008.
8.2. Informative References 7.2. Informative References
[I-D.ietf-dime-diameter-qos] [QOS-MOBILE] Manner, J., "Provision of Quality of Service in IP-
Zorn, G., "Protocol for Diameter Quality of Service based Mobile Access Networks", Doctoral
Application", November 2007. dissertation, University of Helsinki, 2003,
<http://ethesis.helsinki.fi>.
[I-D.ietf-nsis-qos-nslp] [RFC1633] Braden, B., Clark, D., and S. Shenker, "Integrated
Manner, J., Karagiannis, G., and A. McDonald, "NSLP for Services in the Internet Architecture: an Overview",
Quality-of-Service Signaling", draft-ietf-nsis-qos-nslp-18 RFC 1633, June 1994.
(work in progress), January 2010.
[I-D.ietf-sipping-sbc-funcs] [RFC2113] Katz, D., "IP Router Alert Option", RFC 2113,
Hautakorpi, J., Camarillo, G., Penfield, R., Hawrylyshen, February 1997.
A., and M. Bhatia, "Requirements from SIP (Session
Initiation Protocol) Session Border Control Deployments",
April 2007.
[I-D.ietf-tsvwg-rsvp-proxy-proto] [RFC2326] Schulzrinne, H., Rao, A., and R. Lanphier, "Real Time
Faucheur, F., Guillou, A., Manner, J., Malik, H., and A. Streaming Protocol (RTSP)", RFC 2326, April 1998.
Narayanan, "RSVP Extensions for Path-Triggered RSVP
Receiver Proxy", draft-ietf-tsvwg-rsvp-proxy-proto-10
(work in progress), October 2009.
[I-D.ietf-tsvwg-rsvp-security-groupkeying] [RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black,
Behringer, M. and F. Faucheur, "Applicability of Keying "Definition of the Differentiated Services Field (DS
Methods for RSVP Security", Field) in the IPv4 and IPv6 Headers", RFC 2474,
draft-ietf-tsvwg-rsvp-security-groupkeying-05 (work in December 1998.
progress), June 2009.
[I-D.manner-tsvwg-rsvp-proxy-sig] [RFC2711] Partridge, C. and A. Jackson, "IPv6 Router Alert
Manner, J., "Localized RSVP for Controlling RSVP Proxies", Option", RFC 2711, October 1999.
October 2006.
[I-D.rahman-rtg-router-alert-considerations] [RFC2872] Bernet, Y. and R. Pabbati, "Application and Sub
Faucheur, F., "IP Router Alert Considerations and Usage", Application Identity Policy Element for Use with
draft-rahman-rtg-router-alert-considerations-03 (work in RSVP", RFC 2872, June 2000.
progress), October 2009.
[RFC1633] Braden, B., Clark, D., and S. Shenker, "Integrated [RFC2961] Berger, L., Gan, D., Swallow, G., Pan, P., Tommasi,
Services in the Internet Architecture: an Overview", F., and S. Molendini, "RSVP Refresh Overhead
RFC 1633, June 1994. Reduction Extensions", RFC 2961, April 2001.
[RFC2113] Katz, D., "IP Router Alert Option", RFC 2113, [RFC3175] Baker, F., Iturralde, C., Le Faucheur, F., and B.
February 1997. Davie, "Aggregation of RSVP for IPv4 and IPv6
Reservations", RFC 3175, September 2001.
[RFC2326] Schulzrinne, H., Rao, A., and R. Lanphier, "Real Time [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G.,
Streaming Protocol (RTSP)", RFC 2326, April 1998. Johnston, A., Peterson, J., Sparks, R., Handley, M.,
and E. Schooler, "SIP: Session Initiation Protocol",
RFC 3261, June 2002.
[RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, [RFC3312] Camarillo, G., Marshall, W., and J. Rosenberg,
"Definition of the Differentiated Services Field (DS "Integration of Resource Management and Session
Field) in the IPv4 and IPv6 Headers", RFC 2474, Initiation Protocol (SIP)", RFC 3312, October 2002.
December 1998.
[RFC2711] Partridge, C. and A. Jackson, "IPv6 Router Alert Option", [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V.
RFC 2711, October 1999. Jacobson, "RTP: A Transport Protocol for Real-Time
Applications", STD 64, RFC 3550, July 2003.
[RFC2872] Bernet, Y. and R. Pabbati, "Application and Sub [RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and
Application Identity Policy Element for Use with RSVP", J. Arkko, "Diameter Base Protocol", RFC 3588,
RFC 2872, June 2000. September 2003.
[RFC2961] Berger, L., Gan, D., Swallow, G., Pan, P., Tommasi, F., [RFC3644] Snir, Y., Ramberg, Y., Strassner, J., Cohen, R., and
and S. Molendini, "RSVP Refresh Overhead Reduction B. Moore, "Policy Quality of Service (QoS)
Extensions", RFC 2961, April 2001. Information Model", RFC 3644, November 2003.
[RFC3175] Baker, F., Iturralde, C., Le Faucheur, F., and B. Davie, [RFC4032] Camarillo, G. and P. Kyzivat, "Update to the Session
"Aggregation of RSVP for IPv4 and IPv6 Reservations", Initiation Protocol (SIP) Preconditions Framework",
RFC 3175, September 2001. RFC 4032, March 2005.
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, [RFC4301] Kent, S. and K. Seo, "Security Architecture for the
A., Peterson, J., Sparks, R., Handley, M., and E. Internet Protocol", RFC 4301, December 2005.
Schooler, "SIP: Session Initiation Protocol", RFC 3261,
June 2002.
[RFC3312] Camarillo, G., Marshall, W., and J. Rosenberg, [RFC4302] Kent, S., "IP Authentication Header", RFC 4302,
"Integration of Resource Management and Session Initiation December 2005.
Protocol (SIP)", RFC 3312, October 2002.
[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)",
Jacobson, "RTP: A Transport Protocol for Real-Time RFC 4303, December 2005.
Applications", STD 64, RFC 3550, July 2003.
[RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP:
Arkko, "Diameter Base Protocol", RFC 3588, September 2003. Session Description Protocol", RFC 4566, July 2006.
[RFC3644] Snir, Y., Ramberg, Y., Strassner, J., Cohen, R., and B. [RFC4741] Enns, R., "NETCONF Configuration Protocol", RFC 4741,
Moore, "Policy Quality of Service (QoS) Information December 2006.
Model", RFC 3644, November 2003.
[RFC4032] Camarillo, G. and P. Kyzivat, "Update to the Session [RFC4860] Le Faucheur, F., Davie, B., Bose, P., Christou, C.,
Initiation Protocol (SIP) Preconditions Framework", and M. Davenport, "Generic Aggregate Resource
RFC 4032, March 2005. ReSerVation Protocol (RSVP) Reservations", RFC 4860,
May 2007.
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the [RFC4923] Baker, F. and P. Bose, "Quality of Service (QoS)
Internet Protocol", RFC 4301, December 2005. Signaling in a Nested Virtual Private Network",
RFC 4923, August 2007.
[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", [RFC5277] Chisholm, S. and H. Trevino, "NETCONF Event
RFC 4303, December 2005. Notifications", RFC 5277, July 2008.
[RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session [RFC5432] Polk, J., Dhesikan, S., and G. Camarillo, "Quality of
Description Protocol", RFC 4566, July 2006. Service (QoS) Mechanism Selection in the Session
Description Protocol (SDP)", RFC 5432, March 2009.
[RFC4741] Enns, R., "NETCONF Configuration Protocol", RFC 4741, [RFC5853] Hautakorpi, J., Camarillo, G., Penfield, R.,
December 2006. Hawrylyshen, A., and M. Bhatia, "Requirements from
Session Initiation Protocol (SIP) Session Border
Control (SBC) Deployments", RFC 5853, April 2010.
[RFC4860] Le Faucheur, F., Davie, B., Bose, P., Christou, C., and M. [RFC5866] Sun, D., McCann, P., Tschofenig, H., Tsou, T., Doria,
Davenport, "Generic Aggregate Resource ReSerVation A., and G. Zorn, "Diameter Quality-of-Service
Protocol (RSVP) Reservations", RFC 4860, May 2007. Application", RFC 5866, May 2010.
[RFC4923] Baker, F. and P. Bose, "Quality of Service (QoS) Signaling [RFC5946] Le Faucheur, F., Manner, J., Narayanan, A., Guillou,
in a Nested Virtual Private Network", RFC 4923, A., and H. Malik, "Resource Reservation Protocol
August 2007. (RSVP) Extensions for Path-Triggered RSVP Receiver
Proxy", RFC 5946, October 2010.
[RFC5277] Chisholm, S. and H. Trevino, "NETCONF Event [RFC5974] Manner, J., Karagiannis, G., and A. McDonald, "NSIS
Notifications", RFC 5277, July 2008. Signaling Layer Protocol (NSLP) for Quality-of-
Service Signaling", RFC 5974, October 2010.
[RFC5432] Polk, J., Dhesikan, S., and G. Camarillo, "Quality of [RSVP-SEC-KEY] Behringer, M. and F. Le Faucheur, "Applicability of
Service (QoS) Mechanism Selection in the Session Keying Methods for RSVP Security", Work in Progress,
Description Protocol (SDP)", RFC 5432, March 2009. June 2009.
[W3C] "World Wide Web Consortium (W3C) - Web Services [RTR-ALERT] Le Faucheur, F., "IP Router Alert Considerations and
Architecture", <http://www.w3.org/TR/ws-arch/>. Usage", Work in Progress, October 2009.
[W3C] "World Wide Web Consortium (W3C) - Web Services
Architecture", <http://www.w3.org/TR/ws-arch/>.
Appendix A. Use Cases for RSVP Proxies Appendix A. Use Cases for RSVP Proxies
A.1. RSVP-based VoD Admission Control in Broadband Aggregation Networks A.1. RSVP-Based VoD Admission Control in Broadband Aggregation Networks
As broadband services for residential are becoming more and more As broadband services for residential customers are becoming more and
prevalent, next generation aggregation networks are being deployed in more prevalent, next-generation aggregation networks are being
order to aggregate traffic from broadband users (whether attached via deployed in order to aggregate traffic from broadband users (whether
Digital Subscriber Line technology aka DSL, Fiber To The Home/Curb attached via Digital Subscriber Line technology, aka DSL; Fiber To
aka FTTx, Cable or other broadband access technology). Video on The Home/Curb, aka FTTx; Cable; or other broadband access
Demand (VoD) services which may be offered to broadband users present technology). Video on Demand (VoD) services, which may be offered to
significant capacity planning challenges for the aggregation network broadband users, present significant capacity planning challenges for
for a number of reasons. First each VoD stream requires significant the aggregation network for a number of reasons. First, each VoD
dedicated sustained bandwidth (typically 2-4 Mb/s in Standard stream requires significant dedicated sustained bandwidth (typically
Definition TV and 6-12 Mb/s in High Definition TV). Secondly, the 2-4 Mb/s in Standard Definition TV and 6-12 Mb/s in High Definition
VoD codec algorithms are very sensitive to packet loss. Finally, the TV). Secondly, the VoD codec algorithms are very sensitive to packet
load resulting from such services is very hard to predict (e.g. It loss. Finally, the load resulting from such services is very hard to
can vary very suddenly with block-buster titles made available as predict (e.g., it can vary quite suddenly with blockbuster titles
well as with promotional offerings). As a result, transport of VoD made available as well as with promotional offerings). As a result,
streams on the aggregation network usually translate into a strong transport of VoD streams on the aggregation network usually translate
requirement for admission control. The admission control solution into a strong requirement for admission control. The admission
protects the quality of established VoD sessions by rejecting the control solution protects the quality of established VoD sessions by
additional excessive session attempts during unpredictable peaks, rejecting the additional excessive session attempts during
during link or node failures, or combination of those factors. unpredictable peaks, during link or node failures, or a 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 (STBs) (which behave as the receiver for VoD streams)
not support RSVP, the last IP hop in the aggregation network can often do not support RSVP, the last IP hop in the aggregation network
behave as an RSVP Receiver Proxy. This way, RSVP can be used between can behave as an RSVP Receiver Proxy. This way, RSVP can be used
VoD Pumps and the last IP hop in the Aggregation network to perform between VoD pumps and the last IP hop in the aggregation network to
accurate admission control of VoD streams over the resources set perform accurate admission control of VoD streams over the resources
aside for VoD in the aggregation network (typically a certain set 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.
Figure 14 illustrates operation of RSVP-based admission control of Figure 14 illustrates operation of RSVP-based admission control of
VoD sessions in an aggregation network involving RSVP support on the VoD sessions in an aggregation network involving RSVP support on the
VoD Pump (the senders) and RSVP Receiver Proxy on the last IP hop of VoD pump (the senders) and the RSVP Receiver proxy on the last IP hop
the aggregation network. All the customer premises equipment remain of the aggregation network. All the customer premises equipment
RSVP unaware. remains RSVP-unaware.
|-------------| |-------------|
| VoD SRM | | VoD SRM |
| | | |
////////| |\\\\\\\\\\\\\\ ////////| |\\\\\\\\\\\\\\
/ |-------------| \ / |-------------| \
/ \ / \
/ \ / \
/ \ / \
/ \ / \
skipping to change at page 42, line 37 skipping to change at page 41, line 37
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 14: 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 the "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 15 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 an 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| \
/ |-------------| \ / |-------------| \
/ /=/ \ / /=/ \
/ /=/ \ / /=/ \
skipping to change at page 43, line 39 skipping to change at page 42, line 39
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-tunneled RSVP (Path messages)
Figure 15: VoD Use Case with Receiver Proxy and SRM-based Sender Figure 15: VoD Use Case with Receiver Proxy
Proxy and SRM-Based Sender 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.
Those include accurate bandwidth accounting regardless of topology Those include accurate bandwidth accounting regardless of topology
(hub-and-spoke, ring, mesh, star, arbitrary combinations) and dynamic (hub-and-spoke, ring, mesh, star, arbitrary combinations) and dynamic
adjustment to any change in topology (such as failure, routing adjustment to any change in topology (such as failure, routing
change, additional links...). change, additional links, etc.).
A.2. RSVP-based Voice/Video CAC in Enterprise WAN A.2. RSVP-Based Voice/Video Connection Admission Control (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 (Time-Division Multiplexing) systems to ensure the QoS of these
even when transiting through the enterprise's Wide Area Network applications is maintained even when transiting through the
(WAN). Since many of the endpoints already deployed (such as IP enterprise's Wide Area Network (WAN). Since many of the endpoints
Phones or Videoconferencing terminals) are not RSVP capable, RSVP already deployed (such as IP phones or videoconferencing terminals)
Proxy approaches are very useful: they allow deployment of an RSVP- are not RSVP-capable, RSVP proxy approaches are very useful: they
based admission control solution over the WAN without requiring allow deployment of an RSVP-based admission control solution over the
upgrade of the existing terminals. WAN without requiring upgrade of the existing terminals.
A common deployment architecture for such environments relies on the A common deployment architecture for such environments relies on the
Application_Entity-Controlled Proxy approach as defined in Application_Entity-Controlled Proxy approach as defined in
Section 4.5. Routers sitting at the edges of the WAN network and Section 4.5. Routers sitting at the edges of the WAN are naturally
naturally "on-path" for all inter-campus calls (or sessions) and "on-path" for all inter-campus calls (or sessions) and behave as RSVP
behave as RSVP Proxies. The RSVP Proxies establish, maintain and proxies. The RSVP proxies establish, maintain, and tear down RSVP
tear-down RSVP reservations over the WAN segment for the calls (or reservations over the WAN segment for the calls (or sessions) under
sessions) under the control of the SIP Server/Proxy. The SIP Server/ the control of the SIP server/proxy. The SIP server/proxy
Proxy synchronizes the RSVP reservation status with the status of synchronizes the RSVP reservation status with the status of end-to-
end-to-end calls. For example, the called IP phone will only be end calls. For example, the called IP phone will only be instructed
instructed to play a ring tone if the RSVP reservations over the to play a ring tone if the RSVP reservation over the corresponding
corresponding WAN segment has been successfully established. 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 16. video on the enterprise WAN is illustrated in Figure 16.
|---------| |---------|
//////////////| SIP |\\\\\\\\\\\\ //////////////| SIP |\\\\\\\\\\\\
/ | Server/ | \ / | Server/ | \
/ | Proxy | \ / | Proxy | \
/ |---------| \ / |---------| \
/ // \\ \ / // \\ \
/ // \\ \ / // \\ \
/ // \\ \ / // \\ \
/ // \\ \ / // \\ \
skipping to change at page 45, line 42 skipping to change at page 44, line 42
*** ***
*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 16: 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
commerce, network control and management, and remote login commerce, network control and management, and remote-login
applications, would also benefit from a differentiated treatment. applications, would also benefit from a differentiated treatment.
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-
transmission service. The Differentiated Services (DiffServ) end 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 potential weaknesses for deployment However, these architectures have potential weaknesses for deployment
in Mobile Access Networks. For example, RSVP requires support from in Mobile Access Networks. For example, RSVP requires support from
both communication end points, and the protocol may have potential both communication endpoints, and the protocol may have potential
performance issues in mobile environments. DiffServ can only provide performance issues in mobile environments. Diffserv can only provide
statistical guarantees and is not well suited for dynamic statistical guarantees and is not well suited for dynamic
environments. 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 Differentiated Services not able to mark its traffic with a proper Differentiated Services
codepoint (DSCP) to trigger service differentiation, the multimedia codepoint (DSCP) to trigger service differentiation, the multimedia
stream will get only best-effort service which may result in poor stream will get only best-effort service, which may result in poor
visual and audio quality in the receiving application. Even if the visual and audio quality in the receiving application. Even if the
connecting wired network is over-provisioned, an end host would still connecting wired network is over-provisioned, an end host would still
benefit from local resource reservations, especially in wireless benefit from local resource reservations, especially in wireless
access networks, where the bottleneck resource is most probably the access networks, where the bottleneck resource is most probably the
wireless link. wireless link.
RSVP proxies would be a very beneficial solution to this problem. It RSVP proxies would be a very beneficial solution to this problem. It
would allow distinguishing local network reservations from the end- would allow distinguishing local network reservations from the end-
to-end reservations. The end host does not need to know the access to-end reservations. The end host does not need to know the access
network topology or the nodes that will reserve the local resources. network topology or the nodes that will reserve the local resources.
The access network would do resource reservations for both incoming The access network would do resource reservations for both incoming
and outgoing flows based on certain criterion, e.g., filters based on and outgoing flows based on certain criteria, e.g., filters based on
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 that is the most likely bottleneck, the
wireless connectivity. If the wireless access network uses a local wireless link. If the wireless access network uses a local mobility
mobility management mechanism, where the IP address of the mobile management mechanism, where the IP address of the mobile node does
node does not change during handover, RSVP reservations would follow not change during handover, RSVP reservations would follow the mobile
the mobile node movement. node movement.
A.4. RSVP Proxies for Reservations in the presence of IPsec Gateways A.4. RSVP Proxies for Reservations in the Presence of IPsec Gateways
[RFC4923] discusses how resource reservation can be supported end-to- [RFC4923] discusses how resource reservation can be supported end-to-
end in a nested VPN environment. At each VPN level, VPN Routers end in a nested VPN environment. At each VPN level, VPN routers
behave as [RFC4301] security gateways between a plaintext domain and behave as [RFC4301] security gateways between a plaintext domain and
a cyphertext domain. To achieve end-to-end resource reservation, the a ciphertext domain. To achieve end-to-end resource reservation, the
VPN Routers process RSVP signaling on the plaintext side, perform VPN routers process RSVP signaling on the plaintext side, perform
aggregation of plaintext reservations, and maintain the corresponding aggregation of plaintext reservations, and maintain the corresponding
aggregate RSVP reservations on the cyphertext side. Each aggregate aggregate RSVP reservations on the ciphertext side. Each aggregate
reservation is established on behalf of multiple encrypted end-to-end reservation is established on behalf of multiple encrypted end-to-end
sessions sharing the same ingress and egress VPN Routers. These sessions sharing the same ingress and egress VPN routers. These
aggregate reservations can be as specified in [RFC3175] or [RFC4860]. aggregate reservations can be as specified in [RFC3175] or [RFC4860].
Section 3 of [RFC4923] discusses the necessary data flows within a Section 3 of [RFC4923] discusses the necessary data flows within a
VPN Router to achieve the behavior described in the previous VPN router to achieve the behavior described in the previous
paragraph. Two mechanisms are described to achieve such data flows. paragraph. Two mechanisms are described to achieve such data flows.
Section 3.1 presents the case where the VPN Router carries data Section 3.1 presents the case where the VPN router carries data
across the cryptographic boundary. Section 3.2 discusses the case across the cryptographic boundary. Section 3.2 discusses the case
where the VPN router uses a Network-Guard. where the VPN router uses a Network Guard.
Where such mechanisms are not supported by the VPN Routers, the Where such mechanisms are not supported by the VPN routers, the
approach for end-to-end reservation presented in [RFC4923] cannot be approach for end-to-end reservations presented in [RFC4923] cannot be
deployed. An alternative approach to support resource reservations deployed. An alternative approach to support resource reservations
within the cyphertext core is to use the "Application_Entity- within the ciphertext core is to use the Application_Entity-
Controlled Proxy" approach (as defined in Section 4.5) in the Controlled Proxy approach (as defined in Section 4.5) in the
following way: following way:
o the RSVP Proxies are located inside the cyphertext domain and use o the RSVP proxies are located inside the ciphertext 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 ciphertext
domain via an RSVP Proxy control interface domain via an RSVP proxy control interface.
This is illustrated in Figure 17 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 | \
/ |-------| |-------| \ / |-------| |-------| \
/ ^ \\ // ^ \ / ^ \\ // ^ \
skipping to change at page 48, line 41 skipping to change at page 47, line 41
|------| |------|
ARSVP Aggregate RSVP ARSVP Aggregate RSVP
***> media flow ***> media flow
==> segment of flow path protected by RSVP reservation ==> segment of flow path protected by RSVP reservation
/ \ SIP signaling / \ SIP signaling
^ 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 Ciphertext network
Figure 17: RSVP Proxies for Reservations in the Presence of IPsec Figure 17: RSVP Proxies for Reservations in the Presence of
Gateways IPsec 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.
In this use case, because the VPN Routers do not support any RSVP In this use case, because the VPN routers do not support any RSVP-
specific mechanism, the end-to-end RSVP signaling is effectively specific mechanism, the end-to-end RSVP signaling is effectively
hidden by the IPsec gateways on the cyphertext segment of the end-to- hidden by the IPsec gateways on the ciphertext segment of the end-to-
end path. end path.
As with the "Application_Entity-Controlled Proxy" approach (defined As with the Application_Entity-Controlled Proxy approach (defined in
in Section 4.5), the solution here for synchronizing RSVP signaling Section 4.5), the solution here for synchronizing RSVP signaling with
with application-level signaling is to rely on an application-level application-level signaling is to rely on an application-level
signaling device that controls an on-path RSVP Proxy function. signaling device that controls an on-path RSVP proxy function.
However, in the present use case, the RSVP Proxies are a component of However, in this use case, the RSVP proxies are a component of a
a cyphertext network where all user (bearer) traffic is IPsec ciphertext network where all user (bearer) traffic is IPsec
encrypted. This has a number of implications including the encrypted. This has a number of implications, including the
following: following:
1. encrypted flows can not be identified in the cyphertext domain so 1. encrypted flows cannot be identified in the ciphertext domain so
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 17, 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 ciphertext 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
given IPsec gateway. We also observe that when awareness of the given IPsec gateway. We also observe that when awareness of the
RSVP Receiver Proxy for a particular egress IPsec gateway (or RSVP Receiver Proxy for a particular egress IPsec gateway (or
end-to-end flow) is not available, the aggregate reservation may end-to-end flow) is not available, the aggregate reservation may
be signaled by the RSVP Sender Proxy to the destination address be signaled by the RSVP Sender Proxy to the destination address
of the egress IPsec gateway and then proxied by the RSVP Receiver of the egress IPsec gateway and then proxied by the RSVP Receiver
Proxy. Proxy.
Different flavors of operations are possible in terms of aggregate Different flavors of operations are possible in terms of aggregate
reservation sizing. For example, the application entity can initiate reservation sizing. For example, the application entity can initiate
an aggregate reservation of fixed size a priori and then simply keep an aggregate reservation of fixed size a priori and then simply keep
count of the bandwidth used by sessions and reject sessions that count of the bandwidth used by sessions and reject sessions that
would result in excess usage of an aggregate reservation. The would result in excess usage of an aggregate reservation. The
application entity could also re-size the aggregate reservations on a application entity could also re-size the aggregate reservations on a
session by session basis. Alternatively, the application entity session-by-session basis. Alternatively, the application entity
could re-size the aggregate reservations in step increments typically could re-size the aggregate reservations in step increments typically
corresponding to the bandwidth requirement of multiple sessions. 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
Jukka Manner Jukka Manner
Helsinki University of Technology (TKK) Aalto University
P.O. Box 3000 Department of Communications and Networking (Comnet)
Espoo FIN-02015 TKK P.O. Box 13000
FIN-00076 Aalto
Finland Finland
Phone: +358 9 451 2481 Phone: +358 9 470 22481
Email: jukka.manner@tkk.fi EMail: jukka.manner@tkk.fi
URI: http://www.netlab.tkk.fi/~jmanner/ URI: http://www.netlab.tkk.fi/~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
SFR SFR
40-42 Quai du Point du Jour 40-42 Quai du Point du Jour
Boulogne-Billancourt, 92659 Boulogne-Billancourt 92659
France France
Phone: EMail: allan.guillou@sfr.com
Fax:
Email: allan.guillou@sfr.com
URI:
 End of changes. 313 change blocks. 
815 lines changed or deleted 806 lines changed or added

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