draft-ietf-tsvwg-rsvp-proxy-approaches-06.txt   draft-ietf-tsvwg-rsvp-proxy-approaches-07.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: May 4, 2009 University of Helsinki Expires: November 15, 2009 University of Helsinki
D. Wing D. Wing
Cisco Cisco
A. Guillou A. Guillou
Neuf Neuf
October 31, 2008 May 14, 2009
RSVP Proxy Approaches RSVP Proxy Approaches
draft-ietf-tsvwg-rsvp-proxy-approaches-06.txt draft-ietf-tsvwg-rsvp-proxy-approaches-07.txt
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any This Internet-Draft is submitted to IETF in full conformance with the
applicable patent or other IPR claims of which he or she is aware provisions of BCP 78 and BCP 79. This document may contain material
have been or will be disclosed, and any of which he or she becomes from IETF Documents or IETF Contributions published or made publicly
aware will be disclosed, in accordance with Section 6 of BCP 79. available before November 10, 2008. The person(s) controlling the
copyright in some of this material may not have granted the IETF
Trust the right to allow modifications of such material outside the
IETF Standards Process. Without obtaining an adequate license from
the person(s) controlling the copyright in such materials, this
document may not be modified outside the IETF Standards Process, and
derivative works of it may not be created outside the IETF Standards
Process, except to format it for publication as an RFC or to
translate it into languages other than English.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on May 4, 2009. This Internet-Draft will expire on November 15, 2009.
Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents in effect on the date of
publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights
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 many use cases where resource reservation
is required, but the receiver, the sender, or both, is not RSVP- is required, but the receiver, the sender, or both, is not RSVP-
capable. This document presents RSVP Proxy behaviors allowing RSVP capable. This document presents RSVP Proxy behaviors allowing RSVP
skipping to change at page 2, line 18 skipping to change at page 3, line 7
Proxies and discusses how RSVP reservations can be synchronized with Proxies and discusses how RSVP reservations can be synchronized with
application requirements, despite the sender, receiver, or both not application requirements, despite the sender, receiver, or both not
participating in RSVP. This document also points out where participating in RSVP. This document also points out where
extensions to RSVP (or to other protocols) may be needed for extensions to RSVP (or to other protocols) may be needed for
deployment of a given RSVP Proxy approach. However, such extensions deployment of a given RSVP Proxy approach. However, such extensions
are outside the scope of this document. Finally, practical use cases are outside the scope of this document. Finally, practical use cases
for RSVP Proxy are described. for RSVP Proxy are described.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. RSVP Proxy Behaviors . . . . . . . . . . . . . . . . . . . . . 5 2. RSVP Proxy Behaviors . . . . . . . . . . . . . . . . . . . . . 6
2.1. RSVP Receiver Proxy . . . . . . . . . . . . . . . . . . . 5 2.1. RSVP Receiver Proxy . . . . . . . . . . . . . . . . . . . 6
2.2. RSVP Sender Proxy . . . . . . . . . . . . . . . . . . . . 6 2.2. RSVP Sender Proxy . . . . . . . . . . . . . . . . . . . . 7
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 7 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 8
4. RSVP Proxy Approaches . . . . . . . . . . . . . . . . . . . . 8 4. RSVP Proxy Approaches . . . . . . . . . . . . . . . . . . . . 9
4.1. Path-Triggered Receiver Proxy . . . . . . . . . . . . . . 8 4.1. Path-Triggered Receiver Proxy . . . . . . . . . . . . . . 9
4.2. Path-Triggered Sender Proxy for Reverse Direction . . . . 11 4.2. Path-Triggered Sender Proxy for Reverse Direction . . . . 12
4.3. Inspection-Triggered Proxy . . . . . . . . . . . . . . . . 15 4.3. Inspection-Triggered Proxy . . . . . . . . . . . . . . . . 16
4.4. STUN-Triggered Proxy . . . . . . . . . . . . . . . . . . . 17 4.4. STUN-Triggered Proxy . . . . . . . . . . . . . . . . . . . 18
4.5. Application_Entity-Controlled Proxy . . . . . . . . . . . 20 4.5. Application_Entity-Controlled Proxy . . . . . . . . . . . 21
4.5.1. Application_Entity-Controlled Sender Proxy using 4.5.1. Application_Entity-Controlled Sender Proxy using
"RSVP over GRE" . . . . . . . . . . . . . . . . . . . 22 "RSVP over GRE" . . . . . . . . . . . . . . . . . . . 23
4.5.2. Application_Entity-Controlled Proxy via Co-Location . 24 4.5.2. Application_Entity-Controlled Proxy via Co-Location . 25
4.6. Policy_Server-Controlled Proxy . . . . . . . . . . . . . . 25 4.6. Policy_Server-Controlled Proxy . . . . . . . . . . . . . . 26
4.7. RSVP-Signaling-Triggered Proxy . . . . . . . . . . . . . . 28 4.7. RSVP-Signaling-Triggered Proxy . . . . . . . . . . . . . . 29
4.8. Reachability Considerations . . . . . . . . . . . . . . . 29 4.8. Reachability Considerations . . . . . . . . . . . . . . . 30
5. Security Considerations . . . . . . . . . . . . . . . . . . . 30 5. Security Considerations . . . . . . . . . . . . . . . . . . . 31
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 31 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 32
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 31 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 32
8. Informative References . . . . . . . . . . . . . . . . . . . . 31 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 33
Appendix A. Use Cases for RSVP Proxies . . . . . . . . . . . . . 34 8.1. Normative References . . . . . . . . . . . . . . . . . . . 33
A.1. RSVP-based VoD CAC in Broadband Aggregation Networks . . . 34 8.2. Informative References . . . . . . . . . . . . . . . . . . 33
A.2. RSVP-based Voice/Video CAC in Enterprise WAN . . . . . . . 38 Appendix A. Use Cases for RSVP Proxies . . . . . . . . . . . . . 35
A.3. RSVP-based Voice CAC in Telephony Service Provider Core . 39 A.1. RSVP-based VoD Admission Control in Broadband
A.4. RSVP Proxies for Mobile Access Networks . . . . . . . . . 41 Aggregation Networks . . . . . . . . . . . . . . . . . . . 35
A.2. RSVP-based Voice/Video CAC in Enterprise WAN . . . . . . . 39
A.3. RSVP-based Voice CAC in Telephony Service Provider Core . 40
A.4. RSVP Proxies for Mobile Access Networks . . . . . . . . . 42
A.5. RSVP Proxies for Reservations in the presence of IPsec A.5. RSVP Proxies for Reservations in the presence of IPsec
Gateways . . . . . . . . . . . . . . . . . . . . . . . . . 43 Gateways . . . . . . . . . . . . . . . . . . . . . . . . . 44
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 46 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 47
Intellectual Property and Copyright Statements . . . . . . . . . . 48
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 23 skipping to change at page 5, line 23
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 The next section introduces the notion of RSVP Sender Proxy and RSVP
Receiver Proxy. The following section defines useful terminology. Receiver Proxy. The following section defines useful terminology.
The subsequent section then presents several fundamental RSVP Proxy The subsequent section then presents several fundamental RSVP Proxy
approaches insisting on how they achieve the necessary approaches discussing how they achieve the necessary synchronization
synchronization of RSVP reservations with application level of RSVP reservations with application level requirements. Appendix A
requirements. Appendix A includes more detailed use cases for the includes more detailed use cases for the proxies in various real life
proxies in various real life deployment environments. deployment 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 constaints. 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 attempt
establishment of reservations on behalf of devices that are already establishment of reservations on behalf of devices that are already
establishing the reservations themselves). The additional establishing the reservations themselves). The additional
topological constaints come in particular from the requirement to topological constaints come in particular from the requirement to
have one, and only one, Receiver Proxy on the path from any sender to have one RSVP Receiver Proxy on the path from any sender to every
every non-RSVP capable device (so that an non-RSVP capable device is non-RSVP capable device (so that a non-RSVP capable device is always
always taken care of by an RSVP Proxy, and so that an RSVP Proxy does taken care of by an RSVP Proxy) and the objective to have only one
not short-circuit another RSVP Proxy closer to the non-RSVP capable such Receiver Proxy on the path from any sender to every non-RSVP
device). capable device (so that an RSVP Receiver Proxy does not short-circuit
another RSVP Receiver Proxy closer to the non-RSVP capable device,
thereby reducing the span of the RSVP reservation and the associated
benefits).
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 8, line 24 skipping to change at page 9, line 24
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 explicitely signaled during
session establishment using SIP and SDP. Also, session establishment using SIP and SDP. Also, [RFC5432] defines a
[I-D.ietf-mmusic-qos-identification] defines a mechanism to negotiate mechanism to negotiate which resource reservation mechanism is to be
which resource reservation mechanism is to be used for a particular used for a particular media stream. Clearly, these reservation
media stream. Clearly, these reservation negotiation mechanisms can negotiation mechanisms can be invoked and operate effectively when
be invoked and operate effectively when when both ends support RSVP both ends support RSVP (and obviously RSVP Proxies are not used).
(and obviously RSVP Proxies are not used). When both ends do not When both ends do not support RSVP (and RSVP proxies are used at both
support RSVP (and RSVP proxies are used at both ends) these ends) these mechanisms will simply not be invoked. In the case where
mechanisms will simply not be invoked. In the case where one end one end supports RSVP and the other does not (and is helped by an
supports RSVP and the other does not (and is helped by an RSVP RSVP Proxy), the application level signaling entity supporting the
Proxy), the application level signaling entity supporting the non non RSVP capable end might use the reservation negotiation mechanisms
RSVP capable end might use the reservation negotiation mechanisms in in such a way that the non RSVP capable end (helped by an RSVP Proxy)
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 implementing a SIP
[RFC3261] Back-to-Back User Agent (B2BUA). [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.
skipping to change at page 16, line 49 skipping to change at page 17, line 49
can attempt to establish a reservation corresponding to that flow. can attempt to establish a reservation corresponding to that flow.
Characteristics of the reservation may be derived from configuration, Characteristics of the reservation may be derived from configuration,
flow measurement or a combination of those. flow measurement or a combination of those.
Note however, that in case of reservation failure, the inspection- Note however, that in case of reservation failure, the inspection-
triggered RSVP Proxy does not have a direct mechanism for notifying triggered RSVP Proxy does not have a direct mechanism for notifying
the application (since it is not participating itself actively in the application (since it is not participating itself actively in
application signaling) so that the application is not in a position application signaling) so that the application is not in a position
to take appropriate action (for example terminate the corresponding to take appropriate action (for example terminate the corresponding
session). To mitigate this problem, the inspection-triggered RSVP session). To mitigate this problem, the inspection-triggered RSVP
Proxy may mark differently the DSCP of flows for which an RSVP Proxy may mark differently the Differentiated Services codepoint
reservation has been successfully proxied from the flows for which a (DSCP) ([RFC2474]) of flows for which an RSVP reservation has been
reservation is not in place. In some situations, the Inspection- successfully proxied from the flows for which a reservation is not in
Triggered Proxy might be able to modify the "packets of interest" place. In some situations, the Inspection-Triggered Proxy might be
(e.g. application signaling messages) to convey some hint to able to modify the "packets of interest" (e.g. application signaling
applications that the corresponding flows cannot be guaranteed by messages) to convey some hint to applications that the corresponding
RSVP reservations. flows cannot be guaranteed by RSVP reservations.
With the inspection-triggered Proxy approach, the RSVP Proxy is With the inspection-triggered Proxy approach, the RSVP Proxy is
effectively required to attempt to build application awareness by effectively required to attempt to build application awareness by
traffic inspection and then is somewhat limited in the actions it can traffic inspection and then is somewhat limited in the actions it can
take in case of reservation failure. Depending on the "packets of take in case of reservation failure. Depending on the "packets of
interest" used by the RSVP Proxy to trigger the reservation, there is interest" used by the RSVP Proxy to trigger the reservation, there is
a risk that the RSVP Proxy ends up establishing a reservation for a a risk that the RSVP Proxy 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 tear down of an unnecessary reservation
by the RSVP Proxy when no corresponding media flow is observed. The by the RSVP Proxy when no corresponding media flow is observed. The
skipping to change at page 17, line 37 skipping to change at page 18, line 37
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.
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 signaling to synchronize RSVP awareness provided by the STUN ([RFC5389]) signaling to synchronize
reservations with application requirements. The STUN signaling is RSVP reservations with application requirements. The STUN signaling
sent from endpoint to endpoint. This is illustrated in [RFC5389]. is sent from endpoint to endpoint. This is illustrated in Figure 8.
In this approach, a STUN message triggers the RSVP Proxy.
|----| |--------| *** |--------| |----| |----| |--------| *** |--------| |----|
| S |--------| RSVP |------*r*--------| RSVP |----------| R | | S |--------| RSVP |------*r*--------| RSVP |----------| R |
|----| | Proxy | *** | Proxy | |----| |----| | Proxy | *** | Proxy | |----|
|--------| |--------| |--------| |--------|
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^>
=======RSVP=======> =======RSVP=======>
skipping to change at page 18, line 28 skipping to change at page 19, line 28
|----| |----| *** router |----| |----| *** router
^^^> STUN message flow (over same UDP ports as media flow) ^^^> STUN message flow (over same UDP ports as media flow)
==> segment of flow path protected by RSVP reservation ==> segment of flow path protected by RSVP reservation
***> RTP media flow ***> RTP media flow
Figure 8: STUN-Triggered Proxy Figure 8: STUN-Triggered Proxy
In this approach, a STUN[RFC5389] message triggers the RSVP Proxy.
For unicast flows, [I-D.ietf-mmusic-ice] is a widely-adopted approach For unicast flows, [I-D.ietf-mmusic-ice] is a widely-adopted approach
for NAT traversal. For our purposes of triggering RSVP Proxy for NAT traversal. For our purposes of triggering RSVP Proxy
behavior, we rely on ICE's connectivity check which is based on the behavior, we rely on ICE's connectivity check which is based on the
exchange of STUN Binding Request messages between hosts to verify exchange of STUN Binding Request messages between hosts to verify
connectivity (see section 2.2 of [I-D.ietf-mmusic-ice]). The STUN connectivity (see section 2.2 of [I-D.ietf-mmusic-ice]). The STUN
message could also include (yet to be specified) STUN attributes to message could also include (yet to be specified) STUN attributes to
indicate information such as the bandwidth and application requesting indicate information such as the bandwidth and application requesting
the flow, which would allow the RSVP proxy agent to create an the flow, which would allow the RSVP proxy agent to create an
appropriately-sized reservation for each flow. Including such new appropriately-sized reservation for each flow. Including such new
STUN attributes in the ICE connectivity check messages would STUN attributes in the ICE connectivity check messages would
skipping to change at page 19, line 26 skipping to change at page 20, line 24
established (for example when ICE is being used for v4/v6 path established (for example when ICE is being used for v4/v6 path
selection). selection).
o the RSVP Proxy configuration could contain some information o the RSVP Proxy configuration could contain some information
facilitating determination of when to perform RSVP Proxy facilitating determination of when to perform RSVP Proxy
reservation and not. For example, the RSVP Proxy configuration reservation and not. For example, the RSVP Proxy configuration
could contain the IP addresses of the STUN servers such that STUN could contain the IP addresses of the STUN servers such that STUN
messages to/from those addresses are known to not be part of an messages to/from those addresses are known to not be part of an
ICE connectivity check. As another example, the RSVP Proxy ICE connectivity check. As another example, the RSVP Proxy
configuration could contain information identifying the set of configuration could contain information identifying the set of
DiffServ Code Point (DSCP) values that the media flows requiring Differentiated Services codepoint (DSCP) values that the media
reservation use, so that STUN messages not using one of theses flows requiring reservation use, so that STUN messages not using
DSCP values are known to not be part of an ICE connectivity check. one of these DSCP values are known to not be part of an ICE
connectivity check.
Despite these checks, there is always a potential risk that the RSVP Despite these checks, there is always a potential risk that the RSVP
Proxy ends up establishing a reservation for a media flow that Proxy 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 cortresponding 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 implicitely 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 explicitely 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
skipping to change at page 31, line 6 skipping to change at page 32, line 6
RSVP-Signaling-Triggered approach defined in Section 4.7. Proper RSVP-Signaling-Triggered approach defined in Section 4.7. Proper
reservation operation assumes that the RSVP proxy can be trusted to reservation operation assumes that the RSVP proxy can be trusted to
behave correctly in order to control the RSVP reservation as required behave correctly in order to control the RSVP reservation as required
and expected by the end systems. Since, the basic RSVP operation and expected by the end systems. Since, the basic RSVP operation
already assumes a trust model where end-systems trust RSVP nodes to already assumes a trust model where end-systems trust RSVP nodes to
appropriately perform RSVP reservations, the use of RSVP proxy that appropriately perform RSVP reservations, the use of RSVP proxy that
behave autonomously within an RSVP router is not seen as introducing behave autonomously within an RSVP router is not seen as introducing
any significant additional security threat or as fundamentally any significant additional security threat or as fundamentally
modifying the RSVP trust model. modifying the RSVP trust model.
With some RSVP Proxy approaches, the RSVP proxy operate under the With some RSVP Proxy approaches, the RSVP proxy operates under the
control of another entity. This is the case for the control of another entity. This is the case for the
Application_Entity-Controlled Proxy approach defined in Section 4.5 Application_Entity-Controlled Proxy approach defined in Section 4.5
and for the Policy_Server-Controlled Proxy approach defined in and for the Policy_Server-Controlled Proxy approach defined in
Section 4.6. This introduces additional security risks since the Section 4.6. This introduces additional security risks since the
entity controlling the RSVP Proxy needs to be trusted for proper entity controlling the RSVP Proxy needs to be trusted for proper
reservation operation. The exact mechanisms to establish such trust reservation operation and also introduces additional authentication
are beyond the scope of this document, but they may include security and confidentiality requirements. The exact mechanisms to establish
mechanisms inside the protocol used as the control interface between such trust, authentication and confidentiality are beyond the scope
the RSVP Proxy and the entity controlling it, as well as security of this document, but they may include security mechanisms inside the
mechanisms for all the interfaces involved in the reservation control protocol used as the control interface between the RSVP Proxy and the
chain (e.g. inside the application signaling protocol between the end entity controlling it, as well as security mechanisms for all the
systems and the application entity, and, in the case of the interfaces involved in the reservation control chain (e.g. inside the
Policy_Server-Controlled Proxy approach, in the protocol between the application signaling protocol between the end systems and the
application entity and the policy server). application entity, and, in the case of the Policy_Server-Controlled
Proxy approach, in the protocol between the application entity and
the policy server).
In some situations, the use of RSVP Proxy to control reservations on 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].
6. IANA Considerations 6. IANA Considerations
skipping to change at page 31, line 43 skipping to change at page 32, line 45
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 and Magnus Westerlund for their
thorough review and comments. thorough review and comments.
8. Informative References 8. References
[I-D.ietf-dime-diameter-qos] 8.1. Normative References
Zorn, G., "Protocol for Diameter Quality of Service
Application", November 2007.
[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-mmusic-qos-identification] [RFC2205] Braden, B., Zhang, L., Berson, S., Herzog, S., and S.
Polk, J., Dhesikan, S., and G. Camarillo, "Quality of Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1
Service (QoS) Mechanism Selection in the Session Functional Specification", RFC 2205, September 1997.
Description Protocol (SDP)",
draft-ietf-mmusic-qos-identification-02 (work in [RFC2210] Wroclawski, J., "The Use of RSVP with IETF Integrated
progress), October 2008. Services", RFC 2210, September 1997.
[RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z.,
and W. Weiss, "An Architecture for Differentiated
Services", RFC 2475, December 1998.
[RFC2747] Baker, F., Lindell, B., and M. Talwar, "RSVP Cryptographic
Authentication", RFC 2747, January 2000.
[RFC3097] Braden, R. and L. Zhang, "RSVP Cryptographic
Authentication -- Updated Message Type Value", RFC 3097,
April 2001.
[RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing,
"Session Traversal Utilities for NAT (STUN)", RFC 5389,
October 2008.
8.2. Informative References
[I-D.ietf-dime-diameter-qos]
Zorn, G., "Protocol for Diameter Quality of Service
Application", November 2007.
[I-D.ietf-nsis-qos-nslp] [I-D.ietf-nsis-qos-nslp]
Manner, J., Karagiannis, G., and A. McDonald, "NSLP for Manner, J., Karagiannis, G., and A. McDonald, "NSLP for
Quality-of-Service Signaling", draft-ietf-nsis-qos-nslp-16 Quality-of-Service Signaling", draft-ietf-nsis-qos-nslp-16
(work in progress), February 2008. (work in progress), February 2008.
[I-D.ietf-sipping-sbc-funcs] [I-D.ietf-sipping-sbc-funcs]
Hautakorpi, J., Camarillo, G., Penfield, R., Hawrylyshen, Hautakorpi, J., Camarillo, G., Penfield, R., Hawrylyshen,
A., and M. Bhatia, "Requirements from SIP (Session A., and M. Bhatia, "Requirements from SIP (Session
Initiation Protocol) Session Border Control Deployments", Initiation Protocol) Session Border Control Deployments",
April 2007. April 2007.
[I-D.ietf-tsvwg-rsvp-proxy-proto] [I-D.ietf-tsvwg-rsvp-proxy-proto]
Faucheur, F., Manner, J., Narayanan, A., Guillou, A., and Faucheur, F., Malik, H., Manner, J., Narayanan, A.,
L. Faucheur, "RSVP Extensions for Path-Triggered RSVP Guillou, A., and L. Faucheur, "RSVP Extensions for Path-
Receiver Proxy", draft-ietf-tsvwg-rsvp-proxy-proto-07 Triggered RSVP Receiver Proxy",
(work in progress), July 2008. draft-ietf-tsvwg-rsvp-proxy-proto-09 (work in progress),
May 2009.
[I-D.ietf-tsvwg-rsvp-security-groupkeying] [I-D.ietf-tsvwg-rsvp-security-groupkeying]
Behringer, M. and F. Faucheur, "Applicability of Keying Behringer, M. and F. Faucheur, "Applicability of Keying
Methods for RSVP Security", Methods for RSVP Security",
draft-ietf-tsvwg-rsvp-security-groupkeying-01 (work in draft-ietf-tsvwg-rsvp-security-groupkeying-04 (work in
progress), July 2008. 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.
[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.
[RFC2205] Braden, B., Zhang, L., Berson, S., Herzog, S., and S.
Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1
Functional Specification", RFC 2205, September 1997.
[RFC2210] Wroclawski, J., "The Use of RSVP with IETF Integrated
Services", RFC 2210, September 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.
[RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., [RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black,
and W. Weiss, "An Architecture for Differentiated "Definition of the Differentiated Services Field (DS
Services", RFC 2475, December 1998. Field) in the IPv4 and IPv6 Headers", RFC 2474,
December 1998.
[RFC2747] Baker, F., Lindell, B., and M. Talwar, "RSVP Cryptographic
Authentication", RFC 2747, January 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, [RFC3084] Chan, K., Seligson, J., Durham, D., Gai, S., McCloghrie,
K., Herzog, S., Reichmeyer, F., Yavatkar, R., and A. K., Herzog, S., Reichmeyer, F., Yavatkar, R., and A.
Smith, "COPS Usage for Policy Provisioning (COPS-PR)", Smith, "COPS Usage for Policy Provisioning (COPS-PR)",
RFC 3084, March 2001. RFC 3084, March 2001.
[RFC3097] Braden, R. and L. Zhang, "RSVP Cryptographic
Authentication -- Updated Message Type Value", RFC 3097,
April 2001.
[RFC3175] Baker, F., Iturralde, C., Le Faucheur, F., and B. Davie, [RFC3175] Baker, F., Iturralde, C., Le Faucheur, F., and B. Davie,
"Aggregation of RSVP for IPv4 and IPv6 Reservations", "Aggregation of RSVP for IPv4 and IPv6 Reservations",
RFC 3175, September 2001. RFC 3175, September 2001.
[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,
skipping to change at page 34, line 23 skipping to change at page 35, line 34
Description Protocol", RFC 4566, July 2006. Description Protocol", RFC 4566, July 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.
[RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, [RFC5432] Polk, J., Dhesikan, S., and G. Camarillo, "Quality of
"Session Traversal Utilities for NAT (STUN)", RFC 5389, Service (QoS) Mechanism Selection in the Session
October 2008. Description Protocol (SDP)", RFC 5432, March 2009.
Appendix A. Use Cases for RSVP Proxies Appendix A. Use Cases for RSVP Proxies
A.1. RSVP-based VoD CAC in Broadband Aggregation Networks A.1. RSVP-based VoD 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
skipping to change at page 42, line 31 skipping to change at page 43, line 31
both communication end points, and the protocol may have potential both communication end points, and the protocol may have potential
performance issues in mobile environments. DiffServ can only provide performance issues in mobile environments. DiffServ can only provide
statistical guarantees and is not well suited for dynamic statistical guarantees and is not well suited for dynamic
environments. environments.
Let us consider a scenario, where a fixed network correspondent node Let us consider a scenario, where a fixed network correspondent node
(CN) would be sending a multimedia stream to an end host behind a (CN) would be sending a multimedia stream to an end host behind a
wireless link. If the correspondent node does not support RSVP it wireless link. If the correspondent node does not support RSVP it
cannot signal its traffic characteristics to the network and request cannot signal its traffic characteristics to the network and request
specific forwarding services. Likewise, if the correspondent node is specific forwarding services. Likewise, if the correspondent node is
not able to mark its traffic with a proper DiffServ Code Point (DSCP) not able to mark its traffic with a proper Differentiated Services
to trigger service differentiation, the multimedia stream will get codepoint (DSCP) to trigger service differentiation, the multimedia
only best-effort service which may result in poor visual and audio stream will get only best-effort service which may result in poor
quality in the receiving application. Even if the connecting wired visual and audio quality in the receiving application. Even if the
network is over-provisioned, an end host would still benefit from connecting wired network is over-provisioned, an end host would still
local resource reservations, especially in wireless access networks, benefit from local resource reservations, especially in wireless
where the bottleneck resource is most probably the wireless link. access networks, where the bottleneck resource is most probably the
wireless link.
RSVP proxies would be a very beneficial solution to this problem. It RSVP proxies would be a very beneficial solution to this problem. It
would allow distinguishing local network reservations from the end- would allow distinguishing local network reservations from the end-
to-end reservations. The end host does not need to know the access to-end reservations. The end host does not need to know the access
network topology or the nodes that will reserve the local resources. network topology or the nodes that will reserve the local resources.
The access network would do resource reservations for both incoming The access network would do resource reservations for both incoming
and outgoing flows based on certain criterion, e.g., filters based on and outgoing flows based on certain criterion, e.g., filters based on
application protocols. Another option is that the mobile end host application protocols. Another option is that the mobile end host
makes an explicit reservation that identifies the intention and the makes an explicit reservation that identifies the intention and the
access network will find the correct local access network node(s) to access network will find the correct local access network node(s) to
skipping to change at page 45, line 30 skipping to change at page 46, line 30
in Section 4.5), the solution here for synchronizing RSVP signaling in Section 4.5), the solution here for synchronizing RSVP signaling
with application-level signaling is to rely on an application-level with application-level signaling is to rely on an application-level
signaling device that controls an on-path RSVP Proxy function. signaling device that controls an on-path RSVP Proxy function.
However, in the present use case, the RSVP Proxies are a component of However, in the present use case, the RSVP Proxies are a component of
a cyphertext network where all user (bearer) traffic is IPsec a cyphertext network where all user (bearer) traffic is IPsec
encrypted. This has a number of implications including the encrypted. This has a number of implications including the
following: following:
1. encrypted flows can not be identified in the cyphertext domain so 1. encrypted flows can not be identified in the cyphertext domain so
that network nodes can only classify traffic based on IP address that network nodes can only classify traffic based on IP address
and DiffServ Code Points (DSCPs). As a result, only aggregate and Differentiated Services codepoints (DSCPs). As a result,
RSVP reservations (such as those specified in [RFC3175] or only aggregate RSVP reservations (such as those specified in
[RFC4860] ) can be used. This is similar to [RFC4923]. [RFC3175] or [RFC4860] ) can be used. This is similar to
[RFC4923].
2. Determining the RSVP Sender proxy and RSVP receiver Proxy to be 2. Determining the RSVP Sender proxy and RSVP receiver Proxy to be
used for aggregation of a given flow from sender to receiver used for aggregation of a given flow from sender to receiver
creates a number of challenges. Details on how this may be creates a number of challenges. Details on how this may be
achieved are beyond the scope of this document. We observe that, achieved are beyond the scope of this document. We observe that,
as illustrated in Figure 17, this may be facilitated by a network as illustrated in Figure 17, this may be facilitated by a network
management interface between the application entity and the IPsec management interface between the application entity and the IPsec
gateways. For example, this interface may be used by the gateways. For example, this interface may be used by the
application entity to obtain information about which IPsec application entity to obtain information about which IPsec
gateway is on the path of a given end-to-end flow. Then, the gateway is on the path of a given end-to-end flow. Then, the
skipping to change at page 47, line 10 skipping to change at page 48, line 10
San Jose, CA 95134 San Jose, CA 95134
United States United States
Email: dwing@cisco.com Email: dwing@cisco.com
Allan Guillou Allan Guillou
Neuf Cegetel Neuf Cegetel
40-42 Quai du Point du Jour 40-42 Quai du Point du Jour
Boulogne-Billancourt, 92659 Boulogne-Billancourt, 92659
France France
Email: allan.guillou@neufcegetel.fr Email: allan.guillou@sfr.com
Full Copyright Statement
Copyright (C) The IETF Trust (2008).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
 End of changes. 32 change blocks. 
131 lines changed or deleted 164 lines changed or added

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