draft-ietf-tsvwg-rsvp-proxy-approaches-07.txt   draft-ietf-tsvwg-rsvp-proxy-approaches-08.txt 
TSVWG F. Le Faucheur TSVWG F. Le Faucheur
Internet-Draft Cisco Internet-Draft Cisco
Intended status: Informational J. Manner Intended status: Informational J. Manner
Expires: November 15, 2009 University of Helsinki Expires: April 29, 2010 TKK
D. Wing D. Wing
Cisco Cisco
A. Guillou A. Guillou
Neuf SFR
May 14, 2009 October 26, 2009
RSVP Proxy Approaches RSVP Proxy Approaches
draft-ietf-tsvwg-rsvp-proxy-approaches-07.txt draft-ietf-tsvwg-rsvp-proxy-approaches-08.txt
Status of this Memo Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79. This document may contain material provisions of BCP 78 and BCP 79. This document may contain material
from IETF Documents or IETF Contributions published or made publicly from IETF Documents or IETF Contributions published or made publicly
available before November 10, 2008. The person(s) controlling the available before November 10, 2008. The person(s) controlling the
copyright in some of this material may not have granted the IETF copyright in some of this material may not have granted the IETF
Trust the right to allow modifications of such material outside the Trust the right to allow modifications of such material outside the
IETF Standards Process. Without obtaining an adequate license from IETF Standards Process. Without obtaining an adequate license from
skipping to change at page 1, line 47 skipping to change at page 1, line 47
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on November 15, 2009. This Internet-Draft will expire on April 29, 2010.
Copyright Notice Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the Copyright (c) 2009 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents in effect on the date of Provisions Relating to IETF Documents in effect on the date of
publication of this document (http://trustee.ietf.org/license-info). publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights Please review these documents carefully, as they describe your rights
and restrictions with respect to this document. and restrictions with respect to this document.
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 many use cases where resource reservation signaling. Yet, there are use cases where resource reservation is
is required, but the receiver, the sender, or both, is not RSVP- required, but the receiver, the sender, or both, is not RSVP-capable.
capable. This document presents RSVP Proxy behaviors allowing RSVP This document presents RSVP Proxy behaviors allowing RSVP routers to
routers to initiate or terminate RSVP signaling on behalf of a initiate or terminate RSVP signaling on behalf of a receiver or a
receiver or a sender that is not RSVP-capable. This allows resource sender that is not RSVP-capable. This allows resource reservations
reservations to be established on a critical subset of the end-to-end to be established on a critical subset of the end-to-end path. This
path. This document reviews conceptual approaches for deploying RSVP document reviews conceptual approaches for deploying RSVP Proxies and
Proxies and discusses how RSVP reservations can be synchronized with discusses how RSVP reservations can be synchronized with application
application requirements, despite the sender, receiver, or both not requirements, despite the sender, receiver, or both not participating
participating in RSVP. This document also points out where in RSVP. This document also points out where extensions to RSVP (or
extensions to RSVP (or to other protocols) may be needed for to other protocols) may be needed for deployment of a given RSVP
deployment of a given RSVP Proxy approach. However, such extensions Proxy approach. However, such extensions are outside the scope of
are outside the scope of this document. Finally, practical use cases this document. Finally, practical use cases for RSVP Proxy are
for RSVP Proxy are described. described.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. RSVP Proxy Behaviors . . . . . . . . . . . . . . . . . . . . . 6 2. RSVP Proxy Behaviors . . . . . . . . . . . . . . . . . . . . . 6
2.1. RSVP Receiver Proxy . . . . . . . . . . . . . . . . . . . 6 2.1. RSVP Receiver Proxy . . . . . . . . . . . . . . . . . . . 6
2.2. RSVP Sender Proxy . . . . . . . . . . . . . . . . . . . . 7 2.2. RSVP Sender Proxy . . . . . . . . . . . . . . . . . . . . 7
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 8 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 8
4. RSVP Proxy Approaches . . . . . . . . . . . . . . . . . . . . 9 4. RSVP Proxy Approaches . . . . . . . . . . . . . . . . . . . . 9
4.1. Path-Triggered Receiver Proxy . . . . . . . . . . . . . . 9 4.1. Path-Triggered Receiver Proxy . . . . . . . . . . . . . . 9
4.2. Path-Triggered Sender Proxy for Reverse Direction . . . . 12 4.1.1. Mechanisms for Maximizing the Reservation Span . . . . 12
4.3. Inspection-Triggered Proxy . . . . . . . . . . . . . . . . 16 4.2. Path-Triggered Sender Proxy for Reverse Direction . . . . 15
4.4. STUN-Triggered Proxy . . . . . . . . . . . . . . . . . . . 18 4.3. Inspection-Triggered Proxy . . . . . . . . . . . . . . . . 18
4.5. Application_Entity-Controlled Proxy . . . . . . . . . . . 21 4.4. STUN-Triggered Proxy . . . . . . . . . . . . . . . . . . . 21
4.5. Application_Entity-Controlled Proxy . . . . . . . . . . . 23
4.5.1. Application_Entity-Controlled Sender Proxy using 4.5.1. Application_Entity-Controlled Sender Proxy using
"RSVP over GRE" . . . . . . . . . . . . . . . . . . . 23 "RSVP over GRE" . . . . . . . . . . . . . . . . . . . 26
4.5.2. Application_Entity-Controlled Proxy via Co-Location . 25 4.5.2. Application_Entity-Controlled Proxy via Co-Location . 28
4.6. Policy_Server-Controlled Proxy . . . . . . . . . . . . . . 26 4.6. Policy_Server-Controlled Proxy . . . . . . . . . . . . . . 29
4.7. RSVP-Signaling-Triggered Proxy . . . . . . . . . . . . . . 29 4.7. RSVP-Signaling-Triggered Proxy . . . . . . . . . . . . . . 32
4.8. Reachability Considerations . . . . . . . . . . . . . . . 30 4.8. Reachability Considerations . . . . . . . . . . . . . . . 33
5. Security Considerations . . . . . . . . . . . . . . . . . . . 31 5. Security Considerations . . . . . . . . . . . . . . . . . . . 34
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 32 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 36
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 32 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 36
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 33 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 36
8.1. Normative References . . . . . . . . . . . . . . . . . . . 33 8.1. Normative References . . . . . . . . . . . . . . . . . . . 36
8.2. Informative References . . . . . . . . . . . . . . . . . . 33 8.2. Informative References . . . . . . . . . . . . . . . . . . 37
Appendix A. Use Cases for RSVP Proxies . . . . . . . . . . . . . 35 Appendix A. Use Cases for RSVP Proxies . . . . . . . . . . . . . 39
A.1. RSVP-based VoD Admission Control in Broadband A.1. RSVP-based VoD Admission Control in Broadband
Aggregation Networks . . . . . . . . . . . . . . . . . . . 35 Aggregation Networks . . . . . . . . . . . . . . . . . . . 39
A.2. RSVP-based Voice/Video CAC in Enterprise WAN . . . . . . . 39 A.2. RSVP-based Voice/Video CAC in Enterprise WAN . . . . . . . 43
A.3. RSVP-based Voice CAC in Telephony Service Provider Core . 40 A.3. RSVP Proxies for Mobile Access Networks . . . . . . . . . 44
A.4. RSVP Proxies for Mobile Access Networks . . . . . . . . . 42 A.4. RSVP Proxies for Reservations in the presence of IPsec
A.5. RSVP Proxies for Reservations in the presence of IPsec Gateways . . . . . . . . . . . . . . . . . . . . . . . . . 46
Gateways . . . . . . . . . . . . . . . . . . . . . . . . . 44 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 49
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 47
1. Introduction 1. Introduction
Guaranteed Quality of Service (QoS) for some applications with tight Guaranteed Quality of Service (QoS) for some applications with tight
requirements (such as voice or video) may be achieved by reserving requirements (such as voice or video) may be achieved by reserving
resources in each node on the end-to-end path. The main IETF resources in each node on the end-to-end path. The main IETF
protocol for these resource reservations is RSVP, specified in protocol for these resource reservations is RSVP, specified in
[RFC2205]. RSVP does not require that all intermediate nodes support [RFC2205]. RSVP does not require that all intermediate nodes support
RSVP, however it assumes that both the sender and the receiver of the RSVP, however it assumes that both the sender and the receiver of the
data flow support RSVP. There are environments where it would be data flow support RSVP. There are environments where it would be
skipping to change at page 4, line 46 skipping to change at page 4, line 46
synchronize the establishment, maintenance and tear down of the RSVP synchronize the establishment, maintenance and tear down of the RSVP
reservation with the application requirements. Similarly they are in reservation with the application requirements. Similarly they are in
a natural position to determine the characteristics of the a natural position to determine the characteristics of the
reservation (bandwidth, QoS service,...) which best match the reservation (bandwidth, QoS service,...) which 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 Initation synchronized by endpoints that uses the [RFC3261] Session Initiation
Protocol (SIP) for session control. Protocol (SIP) for session control.
When RSVP reservation establishment, maintenance and tearing down is When RSVP reservation establishment, maintenance and tearing down is
to be handled by RSVP Proxies on behalf of an RSVP sender or to be handled by RSVP Proxies on behalf of an RSVP sender or
receiver, a key challenge for the RSVP Proxy is to determine when the receiver, a key challenge for the RSVP Proxy is to determine when the
RSVP reservations need to be established, maintained and torn down RSVP reservations need to be established, maintained and torn down
and to determine what are the characteristics (bandwidth, QoS and to determine what are the characteristics (bandwidth, QoS
Service,...) of the required RSVP reservations matching the Service,...) of the required RSVP reservations matching the
application requirements. We refer to this problem as the application requirements. We refer to this problem as the
synchronization of RSVP reservations with application level synchronization of RSVP reservations with application level
skipping to change at page 5, line 20 skipping to change at page 5, line 20
The IETF Next Steps in Signaling (NSIS) working group is specifying a The IETF Next Steps in Signaling (NSIS) working group is specifying 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) ([I-D.ietf-nsis-qos-nslp]). This protocol also includes the
notion of proxy operation, and terminating QoS signaling on nodes notion of proxy operation, and terminating QoS signaling on nodes
that are not the actual data senders or receivers (see section "4.8 that are not the actual data senders or receivers (see section "4.8
Proxy Mode" of [I-D.ietf-nsis-qos-nslp]. This is the same concept as Proxy Mode" of [I-D.ietf-nsis-qos-nslp]. This is the same concept as
the proxy operation for RSVP discussed in this document. One the proxy operation for RSVP discussed in this document. One
difference though is that the NSIS framework does not consider difference though is that the NSIS framework does not consider
multicast resource reservations, which RSVP provides today. multicast resource reservations, which RSVP provides today.
The next section introduces the notion of RSVP Sender Proxy and RSVP Section 2 introduces the notion of RSVP Sender Proxy and RSVP
Receiver Proxy. The following section defines useful terminology. Receiver Proxy. Section 3 defines useful terminology. Section 4
The subsequent section then presents several fundamental RSVP Proxy then presents several fundamental RSVP Proxy approaches discussing
approaches discussing how they achieve the necessary synchronization how they achieve the necessary synchronization of RSVP reservations
of RSVP reservations with application level requirements. Appendix A with application level requirements. Appendix A includes more
includes more detailed use cases for the proxies in various real life detailed use cases for the proxies in various real life deployment
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 constaints. The additional and/or impose 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 attempt senders/receivers it is not (so that an RSVP Proxy does not perform
establishment of reservations on behalf of devices that are already establishment of reservations on behalf of devices that are capable
establishing the reservations themselves). The additional of doing so themselves but would then be prevented -without
topological constaints come in particular from the requirement to notification- from doing so by the RSVP Proxy). The additional
topological constraints come in particular from the requirement to
have one RSVP Receiver Proxy on the path from any sender to every 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). benefits). In the case of the Path-triggered Receiver Proxy
approach, the operational burden and topological constraints can be
significantly alleviated using the mechanisms discussed in
Section 4.1.1.
It is also worth noting that RSVP operations on endsystems is It is also worth noting that RSVP operations on endsystems is
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 endsystems are very lightweight (particularly
considering modern endsystems capabilities, including mobile and considering modern endsystems capabilities, including mobile and
portable devices). For example, endsystem RSVP implementations are portable devices). For example, endsystem 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 the present document should not be seen as an encouragement to depart
from the end to end RSVP model. Its purpose is only to allow RSVP from the end to end RSVP model. Its purpose is only to allow RSVP
deployment in special environments where RSVP just cannot be used on deployment in special environments where RSVP just cannot be used on
skipping to change at page 9, line 23 skipping to change at page 9, line 23
signaling. signaling.
The roles of RSVP Receiver Proxy, RSVP Sender Proxy, Regular RSVP The roles of RSVP Receiver Proxy, RSVP Sender Proxy, Regular RSVP
Router are all relative to a given unidirectional flow. A given 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 explicitely 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 where
one end supports RSVP and the other does not (and is helped by an one end supports RSVP and the other does not (and is helped by an
RSVP Proxy), the application level signaling entity supporting the 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 to use 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 implementing a SIP "segmented" Status Type of [RFC3312] and/or by taking advantage of a
[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
skipping to change at page 10, line 39 skipping to change at page 10, line 39
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 which mirrors the SENDER_TSPEC object in the received Path
message. 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 12, line 39 skipping to change at page 12, line 39
Figure 4: Path-Triggered RSVP Receiver Proxy with Failure Figure 4: Path-Triggered RSVP Receiver Proxy with Failure
Since, as explained above, in this scenario involving the RSVP Since, as explained above, in this scenario involving the RSVP
Receiver Proxy, synchronization between application and RSVP Receiver Proxy, synchronization between application and RSVP
reservation is generally performed by the sender, notifying the reservation is generally performed by the sender, notifying the
sender of reservation failure is needed. sender of reservation failure is needed.
[I-D.ietf-tsvwg-rsvp-proxy-proto] specifies RSVP extensions allowing [I-D.ietf-tsvwg-rsvp-proxy-proto] specifies RSVP extensions allowing
such sender notification in case of reservation failure in the such sender notification in case of reservation failure in the
presence of a Path-Triggered RSVP Receiver Proxy. presence of a Path-Triggered RSVP Receiver Proxy.
4.1.1. Mechanisms for Maximizing the Reservation Span
The presence in the flow path of a Path-triggered RSVP Receiver Proxy
(for a given flow) that strictly behaves as described previously
would cause the Path message to be terminated and a Resv message to
be generated towards the sender. When the receiver is indeed not
RSVP capable and there is no other RSVP Receiver Proxy downstream on
the flow path, this achieves the best achievable result of
establishing an RSVP reservation as far downstream as the RSVP
Receiver Proxy.
However, if the eventual receiver was in fact RSVP capable, it would
be prevented from participating in RSVP signalling since it does not
receive any Path message. As a result, the RSVP reservation would
only span a subset of the path it could actually span. A similar
suboptimality would exist with multiple Receiver Proxies in the path
of the flow: the first Receiver Proxy may prevent the Path message
from reaching the second one and therefore prevent the reservation
from extending down to the second Receiver Proxy.
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,
the RSVP reservation spans as much of the flow path as possible.
This can be achieved dynamically (avoiding tedious specific
configuration), using the mechanisms described in Section 4.1.1.1 and
in Section 4.1.1.2.
4.1.1.1. Dynamic Discovery of Downstream RSVP Functionality
When generating a proxy Resv message upstream, a Receiver Proxy may
be configured to perform dynamic discovery of downstream RSVP
functionality. To that end, when generating the proxy Resv message
upstream, the Receiver Proxy forwards the Path message downstream
instead of terminating it. This allows an RSVP capable receiver (or
a downstream Receiver Proxy) to respond to the Path with an upstream
Resv message. On receipt of a Resv message, the Receiver Proxy
internally converts its state from a proxied reservation to a regular
midpoint RSVP behavior. From then on, everything proceeds as if the
RSVP router had behaved as a regular RSVP router at reservation
establishment (as opposed to having behaved as an RSVP receiver proxy
for that flow).
The RSVP Receiver Proxy behavior for dynamic discovery of downstream
RSVP functionality is also discussed in section 4.1 of
[I-D.ietf-tsvwg-rsvp-proxy-proto].
This dynamic discovery mechanism has the benefit that new (or
upgraded) RSVP endpoints will automatically and seamlessly be able to
take advantage of end-to-end reservations, without impacting the
ability of a Receiver Proxy to proxy RSVP for other, non-RSVP-capable
endpoints. This mechanism also achieves the goal of automatically
discovering the longest possible RSVP-supporting segment in a network
with multiple Receiver Proxies along the path. This mechanism
dynamically adjusts to any topology and routing change. Also, this
mechanism dynamically handles the situation where a receiver was
RSVP-capable and for some reason (e.g. Software downgrade) no longer
is. Finally, this approach requires no new RSVP protocol extensions
and no configuration changes to the Receiver Proxy as new RSVP-
capable endpoints come and go.
The only identified drawbacks to this approach are:
o If admission control fails on the segment between the Receiver
Proxy and the RSVP-capable receiver, the receiver will get a
ResvError and can take application-level signalling steps to
terminate the call. However, the receiver proxy has already sent
a Resv upstream for this flow, so the sender will see a "false"
reservation which is not truly end-to-end. The actual admission
control status will resolve itself in a short while, but the
sender will need to roll back any permanent action (such as
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
not participating in application signalling, it will convert the
received ResvError into a PathError which will be received by the
sender.
o If there is no RSVP-capable receiver (or other Receiver Proxy)
downstream of the Receiver Proxy, then the Path messages sent by
the Receiver Proxy every RSVP refresh interval (e.g. 30 seconds by
default) will never be responded to. However, these messages
consume a small amount of bandwidth, and in addition would install
some RSVP state on RSVP-capable midpoint nodes downstream of the
first Receiver Proxy. This is seen as a very minor sub-
optimality. We also observe that such resources would be consumed
anyways if the receiver was RSVP capable. Still, if deemed
necessary, to mitigate this, the receiver proxy can tear down any
unanswered downstream Path state after a predetermined time, and
stop sending Path messages for the flow (or only send them at much
lower frequency).
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
terminates, based on local policy decision. For example, an edge
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,
not for Path messages that are transiting through it but stay within
the domain. As another example, the receiver proxy may be
configurable to only proxy for flows addressed to a given destination
address or destination address ranges (for which end devices are
known to not be RSVP capable).
The decision to proxy a Resv for a Path may also be based on
information signalled from the sender in the Path message. For
example, the sender may identify the type of application or flow in
the Application Identity Policy Element ([RFC2872]) in the Path, and
the Receiver Proxy may be configured to proxy for only certain types
of flows. Or, if the sender knows (for example through application
signalling) that the receiver is RSVP capable, the sender can include
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 support RSVP, the sender could include an indication to
Receiver Proxies that they ought to generate a proxy Resv message).
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.
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,
skipping to change at page 13, line 20 skipping to change at page 15, line 39
in terms of bandwidth for the two directions of the flow (as is in terms of bandwidth for the two directions of the flow (as is
currently typical for IP telephony, for example). currently typical for IP telephony, for example).
The signaling flow for the Path-Triggered Sender Proxy for Reverse The signaling flow for the Path-Triggered Sender Proxy for Reverse
Direction is illustrated in Figure 5. Direction is illustrated in Figure 5.
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 asymetric routing (such that if a RSVP Sender Proxy where there is no asymmetric routing (such that if a RSVP Sender
is on the path from receiver to sender, then it is also on the path Proxy is on the path from receiver to sender, then it is also on the
from sender to receiver). In some topologies (such as those path from sender to receiver). In some topologies (such as those
involving asymetric routing), this may not always happen naturally. involving asymmetric routing), this may not always happen naturally.
Measures to ensure this does happen in these topologies are outside Measures to ensure this does happen in these topologies are outside
the scope of this document. the scope of this document.
|----| *** *** |----------| |----| |----| *** *** |----------| |----|
| R |---------*r*----------*r*---------| RSVP |----------| S | | R |---------*r*----------*r*---------| RSVP |----------| S |
|----| *** *** | Sender | |----| |----| *** *** | Sender | |----|
| Proxy | | Proxy |
|----------| |----------|
---Path---> ----Path----> ---Path----> ---Path---> ----Path----> ---Path---->
skipping to change at page 16, line 46 skipping to change at page 18, line 46
information from these packets of interest to determine what RSVP information from these packets of interest to determine what RSVP
reservations need to be established, when and with what reservations need to be established, when and with what
characteristics (possibly also using some configured information). characteristics (possibly also using some configured information).
One example of "packets of interest" could be application level One example of "packets of interest" could be application level
signaling. An RSVP Proxy capable of inspecting SIP signaling for signaling. An RSVP Proxy capable of inspecting SIP signaling for
multimedia session or RTSP signaling for Video streaming, can obtain multimedia session or RTSP signaling for Video streaming, can obtain
from such signaling information about when a multimedia session is up from such signaling information about when a multimedia session is up
or when a Video is going to be streamed. It can also identify the or when a Video is going to be streamed. It can also identify the
addresses and ports of senders and receivers and can determine the addresses and ports of senders and receivers and can determine the
bandwidth of the corresponding flows. Thus, such an RSVP Proxy can bandwidth of the corresponding flows. It can also determine when the
determine all necessary information to synchronize RSVP reservations reservation is no longer needed and tear it down. Thus, such an RSVP
to application requirements. This is illustrated in Figure 7. Proxy can determine all necessary information to synchronize RSVP
reservations to application requirements. This is illustrated in
Figure 7.
|-------------| |-------------|
| Application | | Application |
| Signaling | | Signaling |
| Entity | | Entity |
|-------------| |-------------|
/ \ / \
/ \ / \
/ \ / \
</////////////////////// \\\\\\\\\\\\\\\\\\\\\\\\> </////////////////////// \\\\\\\\\\\\\\\\\\\\\\\\>
skipping to change at page 17, line 36 skipping to change at page 19, line 36
|----| |----| *** router |----| |----| *** router
</\> application level signaling </\> application level signaling
***> media flow ***> media flow
==> segment of flow path protected by RSVP reservation ==> segment of flow path protected by RSVP reservation
Figure 7: Inspection-Triggered RSVP Proxy Figure 7: Inspection-Triggered RSVP Proxy
Another example of "packets of interest" could be packets belonging Another example of "packets of interest" could be transport control
to the application flow itself (e.g. media packets). An RSVP Proxy messages (e.g. RTCP [RFC3550]) traveling alongside the application
capable of detecting the transit of packets from a particular flow, flow itself (i.e. Media packets). An RSVP Proxy capable of
can attempt to establish a reservation corresponding to that flow. detecting the transit of packets from a particular flow, can attempt
Characteristics of the reservation may be derived from configuration, to establish a reservation corresponding to that flow.
flow measurement or a combination of those. Characteristics of the reservation may be derived by various methods
such as from configuration, flow measurement or a combination of
those. However, these methods usually come with their respective
operational drawbacks: configuration involves an operational cost and
may hinder introduction of new applications, measurement is reactive
so that accurate reservation may lag actual traffic.
Note however, that in case of reservation failure, the inspection- In case of reservation failure, the inspection-triggered RSVP Proxy
triggered RSVP Proxy does not have a direct mechanism for notifying does not have a direct mechanism for notifying the application (since
the application (since it is not participating itself actively in it is not participating itself actively in application signaling) so
application signaling) so that the application is not in a position that the application is not in a position to take appropriate action
to take appropriate action (for example terminate the corresponding (for example terminate the corresponding session). To mitigate this
session). To mitigate this problem, the inspection-triggered RSVP problem, the inspection-triggered RSVP Proxy may mark differently the
Proxy may mark differently the Differentiated Services codepoint Differentiated Services codepoint (DSCP) ([RFC2474]) of flows for
(DSCP) ([RFC2474]) of flows for which an RSVP reservation has been which an RSVP reservation has been successfully proxied from the
successfully proxied from the flows for which a reservation is not in flows for which a reservation is not in place. In some situations,
place. In some situations, the Inspection-Triggered Proxy might be the Inspection-Triggered Proxy might be able to modify the "packets
able to modify the "packets of interest" (e.g. application signaling of interest" (e.g. Application signaling messages) to convey some
messages) to convey some hint to applications that the corresponding hint to applications that the corresponding flows cannot be
flows cannot be guaranteed by RSVP reservations. 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 ends up establishing a reservation for a
media flow that actually never starts. However, this can be media flow that actually never starts. However, this can be
mitigated by timing out and tear down of an unnecessary reservation mitigated by timing out and tearing down of an unnecessary
by the RSVP Proxy when no corresponding media flow is observed. The reservation by the RSVP Proxy when no corresponding media flow is
inspection-triggered approach is also subject to the general observed. This flow observation and time out approach can also be
used to tear down reservation that were rightfully established for a
flow but are no longer needed because the flow stopped.
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
defeated in the presence of encryption or being dependent on some impeded by encryption or tunnelling, 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
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
via inspection of the [RFC3312]/[RFC4032] Precondition), in which
case it would not behave as a Proxy for that endpoint . Also, the
"Inspection-Triggered" RSVP proxy may inspect RSVP signaling and if
it sees RSVP signaling for the flow of interest, it can disable its
sender proxy behavior for that flow (or that sender). Optionally,
through RSVP signaling inspection, the sender proxy might also
gradually "learn" (possibly with some timeout) which sender is RSVP
capable of not. These mechanisms can facilitate gradual and dynamic
migration from the Proxy model towards the end-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 STUN ([RFC5389]) signaling to synchronize
RSVP reservations with application requirements. The STUN signaling RSVP reservations with application requirements. The STUN signaling
is sent from endpoint to endpoint. This is illustrated in Figure 8. is sent from endpoint to endpoint. This is illustrated in Figure 8.
In this approach, a STUN message triggers the RSVP Proxy. In this approach, a STUN message triggers the RSVP Proxy.
|----| |--------| *** |--------| |----| |----| |--------| *** |--------| |----|
| S |--------| RSVP |------*r*--------| RSVP |----------| R | | S |--------| RSVP |------*r*--------| RSVP |----------| R |
skipping to change at page 19, line 46 skipping to change at page 22, line 13
appropriately-sized reservation for each flow. Including such new 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 facilitates 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-
skipping to change at page 20, line 39 skipping to change at page 23, line 5
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 ends 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 where
the end-systems is interested enough in establishing connectivity for the end-systems is interested enough in establishing connectivity for
a flow but yet never transmit. Also, this can be mitigated by timing a flow but yet never transmit. Also, this can be mitigated by timing
out and tear down of an unnecessary reservations by the RSVP Proxy out and tear down of an unnecessary reservations by the RSVP Proxy
when no corresponding media flow is observed. 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
explicitely 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 synchronisation 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
STUN-triggered RSVP Proxy approach is used, it can establish RSVP
reservations for flows for which ICE connectivity is performed.
However, the STUN-triggered RSVP Proxy will not establish a
reservation for flows for which ICE connectivity check is not
performed. Those flows will either not benefit from an RSVP
reservation or can benefit from an RSVP reservation established
through other means (end-to-end RSVP, other forms of RSVP Proxy).
The STUN-triggered approach relies on interception and inspection of
STUN messages. Thus, this approach may be impeded by encryption or
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 which is located
in the datapath of the application flows (i.e. "on-path"). With this in the datapath 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 attempt to determine itself 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
skipping to change at page 22, line 50 skipping to change at page 25, line 11
the context of SIP Servers ([RFC3261]) or Session Border Controllers the context of SIP Servers ([RFC3261]) or Session Border Controllers
(SBCs) (see [I-D.ietf-sipping-sbc-funcs] for description of SBCs) to (SBCs) (see [I-D.ietf-sipping-sbc-funcs] for description of SBCs) to
establish RSVP reservations for multimedia sessions. In that case, establish RSVP reservations for multimedia sessions. In that case,
the Application Entity may be the signaling component of the SBC. the Application Entity may be the signaling component of the SBC.
This RSVP Proxy approach does not require any extension to the RSVP This RSVP Proxy approach does not require any extension to the RSVP
protocol. However, it relies on an RSVP Proxy control interface protocol. However, it relies on an RSVP Proxy control interface
allowing control of the RSVP Proxy by an application signaling allowing control of the RSVP Proxy by an application signaling
entity. This RSVP Proxy control interface is beyond the scope of the entity. This RSVP Proxy control interface is beyond the scope of the
present document. Candidate protocols for realizing such interface present document. Candidate protocols for realizing such interface
include SNMP ([RFC3416]), COPS-PR ([RFC3084]), QPIM ([RFC3644]), the include the IETF NETCONF configuration protocol
Extensible Markup Language (XML) and DIAMETER ([RFC3588]). This ([RFC4741],[RFC5277]), Web Services protocol ([W3C]), QPIM
interface can rely on soft states or hard states. Clearly, when hard ([RFC3644]) and DIAMETER ([RFC3588]). This interface can rely on
states are used, those need to be converted appropriately by the RSVP soft states or hard states. Clearly, when hard states are used,
Proxy entities into the corresponding RSVP soft states. As an those need to be converted appropriately by the RSVP Proxy entities
example, [I-D.ietf-dime-diameter-qos] is intended to allow control of into the corresponding RSVP soft states. As an example,
RSVP Proxy via DIAMETER. [I-D.ietf-dime-diameter-qos] is intended to allow control of RSVP
Proxy via 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 RSVP-
AGGREGATE type as specified in [RFC3175] or of GENERIC-AGGREGATE type AGGREGATE type as specified in [RFC3175] or of GENERIC-AGGREGATE type
as specified in [RFC4860]. Such aggregate reservations could be used as specified in [RFC4860]. Such aggregate reservations could be used
skipping to change at page 23, line 34 skipping to change at page 25, line 43
For situations where only the RSVP Sender Proxy has to be controlled For situations where only the RSVP Sender Proxy has to be controlled
by this interface, the interface may be realized through the simple by this interface, the interface may be realized through the simple
use of RSVP itself, over a GRE tunnel from the application entity to use of RSVP itself, over a GRE tunnel from the application entity to
the RSVP Sender Proxy. This particular case is further discussed in the RSVP Sender Proxy. This particular case is further discussed in
Section 4.5.1. Another particular case of interest is where the Section 4.5.1. Another particular case of interest is where the
application signaling entity resides on the same device as the RSVP application signaling entity resides on the same device as the RSVP
Proxy. In that case, this interface may be trivially realized as an Proxy. In that case, this interface may be trivially realized as an
internal API. An example environment based on this particular case internal API. An example environment based on this particular case
is illustrated in Section 4.5.2. is illustrated in Section 4.5.2.
The application entity controlling the RSVP Proxy (e.g. a SIP Call
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
RSVP Proxy anyways. So it is reasonable to assume that such an
application is aware of whether a given endpoint is RSVP-capable or
not. The application may also consider the QoS preconditions and QoS
mechanisms signaled by an endpoint as per [RFC3312]/[RFC4032] and
[RFC5432]. The information about endpoint RSVP capability can then
be used by the application to decide whether to trigger Proxy
behavior or not for a given endpoint. This can facilitate gradual
and dynamic migration from the Proxy model towards the end-to-end
RSVP model as more and more endpoints become RSVP capable.
In some environments, the application entities (e.g. SIP Back-to-
Back User Agents) that need to control the RSVP Proxies would already
be deployed independently of the use, or not, of the
Application_Entity-Controlled Proxy approach. In this case, the
activation of the RSVP Proxy approach should not introduce
significant disruption in the application signaling path. In some
environments, additional application entities may need to be deployed
to control the RSVP Proxies. In this case, the network operator
needs to consider the associated risks of disruption to the
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
skipping to change at page 25, line 13 skipping to change at page 28, line 13
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 ensuring 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 that the actual stream sourced by the sender.
o encapsulates the Path message into a GRE tunnel whose destination o encapsulates the Path message into a GRE tunnel whose destination
address is 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 datapath for the flow (and upstream of the segment which
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
skipping to change at page 29, line 26 skipping to change at page 32, line 26
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 a 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:
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
skipping to change at page 30, line 16 skipping to change at page 33, line 16
flag. The Receiver Proxy is located on the signaling and data path, flag. The Receiver Proxy is located on the signaling and data path,
eventually gets the Path message, and replies back with a Resv eventually gets the Path message, and replies back with a Resv
message. A node triggers an RSVP Sender Proxy with a newly defined message. A node triggers an RSVP Sender Proxy with a newly defined
Path_Request message, which instructs the proxy to send Path messages Path_Request message, which instructs the proxy to send Path messages
towards the triggering node. The node then replies back with a Resv. towards the triggering node. The node then replies back with a Resv.
More details can be found in [I-D.manner-tsvwg-rsvp-proxy-sig]. More details can be found in [I-D.manner-tsvwg-rsvp-proxy-sig].
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 the present
document). However it could provide more flexibility in the control document). However it could provide more flexibility in the control
of the Proxy behavior (e.g. control of reverse reservation of the Proxy behavior (e.g. Control of reverse reservation
parameters) than provided by the Path-Triggered approaches defined in parameters) than provided by the Path-Triggered approaches defined in
Section 4.1 and Section 4.2. Section 4.1 and 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,[I-D.manner-tsvwg-rsvp-proxy-sig] proposed a mechanism example,[I-D.manner-tsvwg-rsvp-proxy-sig] proposed a mechanism
allowing an end-system to control whether a reservation can be allowing an end-system to control whether a reservation can be
handled by an RSVP Proxy on the path or is to be established end-to- handled by an RSVP Proxy on the path or is to be 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 where the RSVP Receiver Proxy is reachable by
skipping to change at page 31, line 6 skipping to change at page 34, line 6
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 ( [I-D.ietf-mmusic-ice]). Finally, even if the sender does not
detect that the receiver is unreachable before triggering the RSVP detect that the receiver is unreachable before triggering the RSVP
reservation establishment, it is very likely that the application reservation establishment, it is very likely that the application
will quickly realise this lack of connectivity (e.g. the human will quickly realise this lack of connectivity (e.g. The human
accepting the phone call on the receiver side will not hear the accepting the phone call on the receiver side will not hear the
human's voice on the sender side) and therefore tear down the session human's voice on the sender side) and therefore tear down the session
(e.g. hang up the phone) which in turn will trigger RSVP reservation (e.g. Hang up 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 Proxys.
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 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.
[I-D.ietf-tsvwg-rsvp-security-groupkeying] discusses key types and [I-D.ietf-tsvwg-rsvp-security-groupkeying] discusses key types and
key provisioning methods as well as their respective applicability to key provisioning methods as well as their respective applicability to
RSVP authentication and RSVP encryption (e.g. [RFC4303]). RSVP authentication.
[I-D.ietf-tsvwg-rsvp-security-groupkeying] also discusses
applicability of IPsec mechanisms ([RFC4303], [RFC4303]) and
associated key provisioning methods for security protection of RSVP.
This discusion applies to the protection of RSVP in the presence of
RSVP Proxies as defined in the present document.
A subset of RSVP messages are signaled with the router alert option
([RFC2113],[RFC2711]). Based on the current security concerns
associated with the use of the IP router alert option, the
applicability of RSVP (and therefore of the RSVP Proxy approaches
discussed in the present document) is limited to controlled
environments (i.e. Environments where the security risks associated
with the use of the router alert option are understood and protected
against). The security aspects and common practices around the use
of the current IP router alert option and consequences of using the
IP router alert option by applications such as RSVP are discussed in
details in [I-D.rahman-rtg-router-alert-considerations].
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
skipping to change at page 32, line 18 skipping to change at page 35, line 36
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 the interfaces involved in the reservation control chain (e.g. Inside
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 [I-D.ietf-tsvwg-rsvp-proxy-proto].
This could also be the case because the use of RSVP Proxy allows
localization of RSVP operation within the boundaries of a given
administrative domain (thus easily operating as a controlled
environment) while the end-to-end flow path spans multiple
administrative domains.
6. IANA Considerations 6. IANA Considerations
This document does not make any request to IANA registration. This document does not make any request to IANA registration.
7. Acknowledgments 7. Acknowledgments
This document benefited from earlier work on the concept of RSVP This document benefited from earlier work on the concept of RSVP
Proxy including the one documented by Silvano Gai, Dinesh Dutt, Proxy including the one documented by Silvano Gai, Dinesh Dutt,
Nitsan Elfassy and Yoram Bernet. It also benefited from discussions Nitsan Elfassy and Yoram Bernet. It also benefited from discussions
with Pratik Bose, Chris Christou and Michael Davenport. 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 and Magnus Westerlund for their Section 4.6. Thanks to James Polk, Magnus Westerlund, Dan Romascanu,
thorough review and comments. Ross Callon, Cullen Jennings and Jari Arkko for their thorough review
and comments.
8. References 8. References
8.1. Normative References 8.1. Normative References
[I-D.ietf-mmusic-ice] [I-D.ietf-mmusic-ice]
Rosenberg, J., "Interactive Connectivity Establishment Rosenberg, J., "Interactive Connectivity Establishment
(ICE): A Protocol for Network Address Translator (NAT) (ICE): A Protocol for Network Address Translator (NAT)
Traversal for Offer/Answer Protocols", Traversal for Offer/Answer Protocols",
draft-ietf-mmusic-ice-19 (work in progress), October 2007. draft-ietf-mmusic-ice-19 (work in progress), October 2007.
[I-D.ietf-tsvwg-rsvp-security-groupkeying]
Behringer, M. and F. Faucheur, "Applicability of Keying
Methods for RSVP Security",
draft-ietf-tsvwg-rsvp-security-groupkeying-05 (work in
progress), June 2009.
[RFC2205] Braden, B., Zhang, L., Berson, S., Herzog, S., and S. [RFC2205] Braden, B., Zhang, L., Berson, S., Herzog, S., and S.
Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1
Functional Specification", RFC 2205, September 1997. Functional Specification", RFC 2205, September 1997.
[RFC2210] Wroclawski, J., "The Use of RSVP with IETF Integrated [RFC2210] Wroclawski, J., "The Use of RSVP with IETF Integrated
Services", RFC 2210, September 1997. Services", RFC 2210, September 1997.
[RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., [RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z.,
and W. Weiss, "An Architecture for Differentiated and W. Weiss, "An Architecture for Differentiated
Services", RFC 2475, December 1998. Services", RFC 2475, December 1998.
skipping to change at page 34, line 10 skipping to change at page 37, line 38
Initiation Protocol) Session Border Control Deployments", Initiation Protocol) Session Border Control Deployments",
April 2007. April 2007.
[I-D.ietf-tsvwg-rsvp-proxy-proto] [I-D.ietf-tsvwg-rsvp-proxy-proto]
Faucheur, F., Malik, H., Manner, J., Narayanan, A., Faucheur, F., Malik, H., Manner, J., Narayanan, A.,
Guillou, A., and L. Faucheur, "RSVP Extensions for Path- Guillou, A., and L. Faucheur, "RSVP Extensions for Path-
Triggered RSVP Receiver Proxy", Triggered RSVP Receiver Proxy",
draft-ietf-tsvwg-rsvp-proxy-proto-09 (work in progress), draft-ietf-tsvwg-rsvp-proxy-proto-09 (work in progress),
May 2009. May 2009.
[I-D.ietf-tsvwg-rsvp-security-groupkeying]
Behringer, M. and F. Faucheur, "Applicability of Keying
Methods for RSVP Security",
draft-ietf-tsvwg-rsvp-security-groupkeying-04 (work in
progress), March 2009.
[I-D.manner-tsvwg-rsvp-proxy-sig] [I-D.manner-tsvwg-rsvp-proxy-sig]
Manner, J., "Localized RSVP for Controlling RSVP Proxies", Manner, J., "Localized RSVP for Controlling RSVP Proxies",
October 2006. October 2006.
[I-D.rahman-rtg-router-alert-considerations]
Faucheur, F., "IP Router Alert Considerations and Usage",
draft-rahman-rtg-router-alert-considerations-02 (work in
progress), July 2009.
[RFC1633] Braden, B., Clark, D., and S. Shenker, "Integrated [RFC1633] Braden, B., Clark, D., and S. Shenker, "Integrated
Services in the Internet Architecture: an Overview", Services in the Internet Architecture: an Overview",
RFC 1633, June 1994. RFC 1633, June 1994.
[RFC2113] Katz, D., "IP Router Alert Option", RFC 2113,
February 1997.
[RFC2326] Schulzrinne, H., Rao, A., and R. Lanphier, "Real Time [RFC2326] Schulzrinne, H., Rao, A., and R. Lanphier, "Real Time
Streaming Protocol (RTSP)", RFC 2326, April 1998. Streaming Protocol (RTSP)", RFC 2326, April 1998.
[RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, [RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black,
"Definition of the Differentiated Services Field (DS "Definition of the Differentiated Services Field (DS
Field) in the IPv4 and IPv6 Headers", RFC 2474, Field) in the IPv4 and IPv6 Headers", RFC 2474,
December 1998. December 1998.
[RFC2711] Partridge, C. and A. Jackson, "IPv6 Router Alert Option",
RFC 2711, October 1999.
[RFC2872] Bernet, Y. and R. Pabbati, "Application and Sub
Application Identity Policy Element for Use with RSVP",
RFC 2872, June 2000.
[RFC2961] Berger, L., Gan, D., Swallow, G., Pan, P., Tommasi, F., [RFC2961] Berger, L., Gan, D., Swallow, G., Pan, P., Tommasi, F.,
and S. Molendini, "RSVP Refresh Overhead Reduction and S. Molendini, "RSVP Refresh Overhead Reduction
Extensions", RFC 2961, April 2001. Extensions", RFC 2961, April 2001.
[RFC3084] Chan, K., Seligson, J., Durham, D., Gai, S., McCloghrie,
K., Herzog, S., Reichmeyer, F., Yavatkar, R., and A.
Smith, "COPS Usage for Policy Provisioning (COPS-PR)",
RFC 3084, March 2001.
[RFC3175] Baker, F., Iturralde, C., Le Faucheur, F., and B. Davie, [RFC3175] Baker, F., Iturralde, C., Le Faucheur, F., and B. Davie,
"Aggregation of RSVP for IPv4 and IPv6 Reservations", "Aggregation of RSVP for IPv4 and IPv6 Reservations",
RFC 3175, September 2001. RFC 3175, September 2001.
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
A., Peterson, J., Sparks, R., Handley, M., and E. A., Peterson, J., Sparks, R., Handley, M., and E.
Schooler, "SIP: Session Initiation Protocol", RFC 3261, Schooler, "SIP: Session Initiation Protocol", RFC 3261,
June 2002. June 2002.
[RFC3312] Camarillo, G., Marshall, W., and J. Rosenberg, [RFC3312] Camarillo, G., Marshall, W., and J. Rosenberg,
"Integration of Resource Management and Session Initiation "Integration of Resource Management and Session Initiation
Protocol (SIP)", RFC 3312, October 2002. Protocol (SIP)", RFC 3312, October 2002.
[RFC3416] Presuhn, R., "Version 2 of the Protocol Operations for the [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V.
Simple Network Management Protocol (SNMP)", STD 62, Jacobson, "RTP: A Transport Protocol for Real-Time
RFC 3416, December 2002. Applications", STD 64, RFC 3550, July 2003.
[RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. [RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J.
Arkko, "Diameter Base Protocol", RFC 3588, September 2003. Arkko, "Diameter Base Protocol", RFC 3588, September 2003.
[RFC3644] Snir, Y., Ramberg, Y., Strassner, J., Cohen, R., and B. [RFC3644] Snir, Y., Ramberg, Y., Strassner, J., Cohen, R., and B.
Moore, "Policy Quality of Service (QoS) Information Moore, "Policy Quality of Service (QoS) Information
Model", RFC 3644, November 2003. Model", RFC 3644, November 2003.
[RFC4032] Camarillo, G. and P. Kyzivat, "Update to the Session
Initiation Protocol (SIP) Preconditions Framework",
RFC 4032, March 2005.
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the [RFC4301] Kent, S. and K. Seo, "Security Architecture for the
Internet Protocol", RFC 4301, December 2005. Internet Protocol", RFC 4301, December 2005.
[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)",
RFC 4303, December 2005. RFC 4303, December 2005.
[RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session
Description Protocol", RFC 4566, July 2006. Description Protocol", RFC 4566, July 2006.
[RFC4741] Enns, R., "NETCONF Configuration Protocol", RFC 4741,
December 2006.
[RFC4860] Le Faucheur, F., Davie, B., Bose, P., Christou, C., and M. [RFC4860] Le Faucheur, F., Davie, B., Bose, P., Christou, C., and M.
Davenport, "Generic Aggregate Resource ReSerVation Davenport, "Generic Aggregate Resource ReSerVation
Protocol (RSVP) Reservations", RFC 4860, May 2007. Protocol (RSVP) Reservations", RFC 4860, May 2007.
[RFC4923] Baker, F. and P. Bose, "Quality of Service (QoS) Signaling [RFC4923] Baker, F. and P. Bose, "Quality of Service (QoS) Signaling
in a Nested Virtual Private Network", RFC 4923, in a Nested Virtual Private Network", RFC 4923,
August 2007. August 2007.
[RFC5277] Chisholm, S. and H. Trevino, "NETCONF Event
Notifications", RFC 5277, July 2008.
[RFC5432] Polk, J., Dhesikan, S., and G. Camarillo, "Quality of [RFC5432] Polk, J., Dhesikan, S., and G. Camarillo, "Quality of
Service (QoS) Mechanism Selection in the Session Service (QoS) Mechanism Selection in the Session
Description Protocol (SDP)", RFC 5432, March 2009. Description Protocol (SDP)", RFC 5432, March 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 are becoming more and more
prevalent, next generation aggregation networks are being deployed in prevalent, next generation aggregation networks are being deployed in
order to aggregate traffic from broadband users (whether attached via order to aggregate traffic from broadband users (whether attached via
Digital Subscriber Line technology aka DSL, Fiber To The Home/Curb Digital Subscriber Line technology aka DSL, Fiber To The Home/Curb
aka FTTx, Cable or other broadband access technology). Video on aka FTTx, Cable or other broadband access technology). Video on
Demand (VoD) services which may be offered to broadband users present Demand (VoD) services which may be offered to broadband users present
significant capacity planning challenges for the aggregation network significant capacity planning challenges for the aggregation network
for a number of reasons. First each VoD stream requires significant for a number of reasons. First each VoD stream requires significant
dedicated sustained bandwidth (typically 2-4 Mb/s in Standard dedicated sustained bandwidth (typically 2-4 Mb/s in Standard
Definition TV and 6-12 Mb/s in High Definition TV). Secondly, the Definition TV and 6-12 Mb/s in High Definition TV). Secondly, the
VoD codec algorithms are very sensitive to packet loss. Finally, the VoD codec algorithms are very sensitive to packet loss. Finally, the
load resulting from such services is very hard to predict (e.g. it load resulting from such services is very hard to predict (e.g. It
can vary very suddenly with block-buster titles made available as can vary very suddenly with block-buster titles made available as
well as with promotional offerings). As a result, transport of VoD well as with promotional offerings). As a result, transport of VoD
streams on the aggregation network usually translate into a strong streams on the aggregation network usually translate into a strong
requirement for admission control. The admission control solution requirement for admission control. The admission control solution
protects the quality of established VoD sessions by rejecting the protects the quality of established VoD sessions by rejecting the
additional excessive session attempts during unpredictable peaks, additional excessive session attempts during unpredictable peaks,
during link or node failures, or combination of those factors. during link or node failures, or combination of those factors.
RSVP can be used in the aggregation network for admission control of RSVP can be used in the aggregation network for admission control of
the VoD sessions. However, since Customer Premises equipment such as the VoD sessions. However, since Customer Premises equipment such as
skipping to change at page 40, line 47 skipping to change at page 44, line 47
<==> segment of flow path protected by RSVP reservation <==> segment of flow path protected by RSVP reservation
/\ SIP signaling /\ SIP signaling
// control interface between the SIP Server/Proxy and // control interface between the SIP Server/Proxy and
RSVP Proxy RSVP Proxy
Figure 15: CAC on Enterprise WAN Use Case Figure 15: CAC on Enterprise WAN Use Case
A.3. RSVP-based Voice CAC in Telephony Service Provider Core A.3. RSVP Proxies for Mobile Access Networks
Let us consider an environment involving a Telephony Service Provider
(TSP). Let us further assume that end-users are attached to the TSP
via Session Border Controllers (SBCs). The SBCs may be remotely
controlled by a SIP Server. The SIP Server may control establishment
of RSVP reservations between the SBCs for admission control of
sessions over the core. This relies on the Application_Entity-
Controlled RSVP Proxy approach presented in Section 4.5. This is
illustrated in the Figure below.
|---------|
//////////////| SIP |\\\\\\\\\\\\
/ | Server/ | \
/ | Proxy | \
/ |---------| \
/ // \\ \
/ // \\ \
/ // \\ \
/ // \\ \
/ // \\ \
|-----| |--------| *** *** |--------| |-----|
| IP |------| |---*r*---*r*---| |-------|IP |
|Phone| | SBC | *** *** | SBC | |Phone|
|-----| | + | | + | |-----|
| RSVP | | RSVP |
| Proxy | | Proxy |
|--------| |--------|
<---Access----> <---Access----->
<---------Core---------->
<*************> <***********************> <**************>
<=========RSVP==========>
***
*r* Regular RSVP router
***
<***> media flow
<==> segment of flow path protected by RSVP reservation
/\ SIP signaling
// control interface between the SIP Server/Proxy and
SBC/RSVP Proxy
Figure 16: Voice CAC in TSP Domain
A.4. RSVP Proxies for Mobile Access Networks
Mobile access networks are increasingly based on IP technology. This Mobile access networks are increasingly based on IP technology. This
implies that, on the network layer, all traffic, both traditional implies that, on the network layer, all traffic, both traditional
data and streamed data like audio or video, is transmitted as data and streamed data like audio or video, is transmitted as
packets. Increasingly popular multimedia applications would benefit packets. Increasingly popular multimedia applications would benefit
from better than best-effort service from the network, a forwarding from better than best-effort service from the network, a forwarding
service with strict Quality of Service (QoS) with guaranteed minimum service with strict Quality of Service (QoS) with guaranteed minimum
bandwidth and bounded delay. Other applications, such as electronic bandwidth and bounded delay. Other applications, such as electronic
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.
skipping to change at page 44, line 8 skipping to change at page 46, line 8
application protocols. Another option is that the mobile end host application protocols. Another option is that the mobile end host
makes an explicit reservation that identifies the intention and the makes an explicit reservation that identifies the intention and the
access network will find the correct local access network node(s) to access network will find the correct local access network node(s) to
respond to the reservation. RSVP proxies would, thus, allow resource respond to the reservation. RSVP proxies would, thus, allow resource
reservation over the segment which is the most likely bottleneck, the reservation over the segment which is the most likely bottleneck, the
wireless connectivity. If the wireless access network uses a local wireless connectivity. If the wireless access network uses a local
mobility management mechanism, where the IP address of the mobile mobility management mechanism, where the IP address of the mobile
node does not change during handover, RSVP reservations would follow node does not change during handover, RSVP reservations would follow
the mobile node movement. the mobile node movement.
A.5. RSVP Proxies for Reservations in the presence of IPsec Gateways 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 cyphertext 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 cyphertext 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
skipping to change at page 44, line 44 skipping to change at page 46, line 44
o the RSVP Proxies are located inside the cyphertext domain and use o the RSVP Proxies are located inside the cyphertext domain and use
aggregate RSVP reservations, aggregate RSVP reservations,
o the Application Entity exchange application level signaling with o the Application Entity exchange application level signaling with
the end systems in the plaintext domain, the end systems in the plaintext domain,
o the Application Entity controls the RSVP Proxies in the cyphertext o the Application Entity controls the RSVP Proxies in the cyphertext
domain via an RSVP Proxy control interface domain via an RSVP Proxy control interface
This is illustrated in Figure 17 in the case where the application is This is illustrated in Figure 16 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 45, line 50 skipping to change at page 47, line 50
^ Network management interface between SIP Server/Proxy ^ Network management interface between SIP Server/Proxy
and IPsec security gateway and IPsec security gateway
// control interface between SIP Server/Proxy and ARSVP Proxy // control interface between SIP Server/Proxy and ARSVP Proxy
PT Plaintext network PT Plaintext network
CT Cyphertext network CT Cyphertext network
Figure 17: RSVP Proxies for Reservations in the Presence of IPsec Figure 16: RSVP Proxies for Reservations in the Presence of IPsec
Gateways Gateways
Where the sender and receiver are RSVP capable, they may also use Where the sender and receiver are RSVP capable, they may also use
RSVP signaling. This achieves resource reservation on the plaintext RSVP signaling. This achieves resource reservation on the plaintext
segments of the end-to-end i.e. : segments of the end-to-end i.e. :
o from the sender to the ingress IPsec gateway and o from the sender to the ingress IPsec gateway and
o from the egress IPsec gateway to the receiver. o from the egress IPsec gateway to the receiver.
skipping to change at page 46, line 39 skipping to change at page 48, line 39
that network nodes can only classify traffic based on IP address that network nodes can only classify traffic based on IP address
and Differentiated Services codepoints (DSCPs). As a result, and Differentiated Services codepoints (DSCPs). As a result,
only aggregate RSVP reservations (such as those specified in only aggregate RSVP reservations (such as those specified in
[RFC3175] or [RFC4860] ) can be used. This is similar to [RFC3175] or [RFC4860] ) can be used. This is similar to
[RFC4923]. [RFC4923].
2. Determining the RSVP Sender proxy and RSVP receiver Proxy to be 2. Determining the RSVP Sender proxy and RSVP receiver Proxy to be
used for aggregation of a given flow from sender to receiver used for aggregation of a given flow from sender to receiver
creates a number of challenges. Details on how this may be creates a number of challenges. Details on how this may be
achieved are beyond the scope of this document. We observe that, achieved are beyond the scope of this document. We observe that,
as illustrated in Figure 17, this may be facilitated by a network as illustrated in Figure 16, this may be facilitated by a network
management interface between the application entity and the IPsec management interface between the application entity and the IPsec
gateways. For example, this interface may be used by the gateways. For example, this interface may be used by the
application entity to obtain information about which IPsec application entity to obtain information about which IPsec
gateway is on the path of a given end-to-end flow. Then, the gateway is on the path of a given end-to-end flow. Then, the
application entity may maintain awareness of which RSVP Proxy is application entity may maintain awareness of which RSVP Proxy is
on the cyphertext path between a given pair of IPsec gateways. on the cyphertext path between a given pair of IPsec gateways.
How such awareness is achieved is beyond the scope of this How such awareness is achieved is beyond the scope of this
document. We simply observe that such awareness can be easily document. We simply observe that such awareness can be easily
achieved through simple configuration in the particular case achieved through simple configuration in the particular case
where a single (physical or logical) RSVP Proxy is fronting a where a single (physical or logical) RSVP Proxy is fronting a
skipping to change at page 47, line 31 skipping to change at page 49, line 31
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
University of Helsinki Helsinki University of Technology (TKK)
P.O. Box 68 P.O. Box 3000
University of Helsinki FIN-00014 University of Helsinki Espoo FIN-02015 TKK
Finland Finland
Phone: +358 9 191 51298 Phone: +358 9 451 2481
Email: jmanner@cs.helsinki.fi Email: jukka.manner@tkk.fi
URI: http://www.cs.helsinki.fi/u/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
Neuf Cegetel SFR
40-42 Quai du Point du Jour 40-42 Quai du Point du Jour
Boulogne-Billancourt, 92659 Boulogne-Billancourt, 92659
France France
Phone:
Fax:
Email: allan.guillou@sfr.com Email: allan.guillou@sfr.com
URI:
 End of changes. 64 change blocks. 
190 lines changed or deleted 372 lines changed or added

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