draft-ietf-tsvwg-rsvp-proxy-approaches-04.txt   draft-ietf-tsvwg-rsvp-proxy-approaches-05.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: October 12, 2008 University of Helsinki Expires: May 4, 2009 University of Helsinki
D. Wing D. Wing
Cisco Cisco
A. Guillou A. Guillou
Neuf Neuf
April 10, 2008 October 31, 2008
RSVP Proxy Approaches RSVP Proxy Approaches
draft-ietf-tsvwg-rsvp-proxy-approaches-04.txt draft-ietf-tsvwg-rsvp-proxy-approaches-05.txt
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 39 skipping to change at page 1, line 39
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on October 12, 2008. This Internet-Draft will expire on May 4, 2009.
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 19 skipping to change at page 2, line 19
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 . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. RSVP Proxy Behaviors . . . . . . . . . . . . . . . . . . . . . 4 2. RSVP Proxy Behaviors . . . . . . . . . . . . . . . . . . . . . 5
2.1. RSVP Receiver Proxy . . . . . . . . . . . . . . . . . . . 5 2.1. RSVP Receiver Proxy . . . . . . . . . . . . . . . . . . . 5
2.2. RSVP Sender Proxy . . . . . . . . . . . . . . . . . . . . 5 2.2. RSVP Sender Proxy . . . . . . . . . . . . . . . . . . . . 6
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 7
4. RSVP Proxy Approaches . . . . . . . . . . . . . . . . . . . . 8 4. RSVP Proxy Approaches . . . . . . . . . . . . . . . . . . . . 8
4.1. Path-Triggered Receiver Proxy . . . . . . . . . . . . . . 8 4.1. Path-Triggered Receiver Proxy . . . . . . . . . . . . . . 8
4.2. Path-Triggered Sender Proxy for Reverse Direction . . . . 10 4.2. Path-Triggered Sender Proxy for Reverse Direction . . . . 11
4.3. Inspection-Triggered Proxy . . . . . . . . . . . . . . . . 14 4.3. Inspection-Triggered Proxy . . . . . . . . . . . . . . . . 15
4.4. STUN-Triggered Proxy . . . . . . . . . . . . . . . . . . . 16 4.4. STUN-Triggered Proxy . . . . . . . . . . . . . . . . . . . 17
4.5. Application_Entity-Controlled Proxy . . . . . . . . . . . 18 4.5. Application_Entity-Controlled Proxy . . . . . . . . . . . 20
4.5.1. Application_Entity-Controlled Sender Proxy using 4.5.1. Application_Entity-Controlled Sender Proxy using
"RSVP over GRE" . . . . . . . . . . . . . . . . . . . 20 "RSVP over GRE" . . . . . . . . . . . . . . . . . . . 22
4.5.2. Application_Entity-Controlled Proxy via Co-Location . 22 4.5.2. Application_Entity-Controlled Proxy via Co-Location . 24
4.6. Policy_Server-Controlled Proxy . . . . . . . . . . . . . . 23 4.6. Policy_Server-Controlled Proxy . . . . . . . . . . . . . . 25
4.7. RSVP-Signaling-Triggered Proxy . . . . . . . . . . . . . . 26 4.7. RSVP-Signaling-Triggered Proxy . . . . . . . . . . . . . . 28
4.8. Reachability Considerations . . . . . . . . . . . . . . . 27 4.8. Reachability Considerations . . . . . . . . . . . . . . . 29
5. Security Considerations . . . . . . . . . . . . . . . . . . . 28 5. Security Considerations . . . . . . . . . . . . . . . . . . . 30
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 29 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 31
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 29 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 31
8. Informative References . . . . . . . . . . . . . . . . . . . . 29 8. Informative References . . . . . . . . . . . . . . . . . . . . 31
Appendix A. Use Cases for RSVP Proxies . . . . . . . . . . . . . 32 Appendix A. Use Cases for RSVP Proxies . . . . . . . . . . . . . 34
A.1. RSVP-based VoD CAC in Broadband Aggregation Networks . . . 32 A.1. RSVP-based VoD CAC in Broadband Aggregation Networks . . . 34
A.2. RSVP-based Voice/Video CAC in Enterprise WAN . . . . . . . 36 A.2. RSVP-based Voice/Video CAC in Enterprise WAN . . . . . . . 38
A.3. RSVP-based Voice CAC in Telephony Service Provider Core . 37 A.3. RSVP-based Voice CAC in Telephony Service Provider Core . 39
A.4. RSVP Proxies for Mobile Access Networks . . . . . . . . . 39 A.4. RSVP Proxies for Mobile Access Networks . . . . . . . . . 41
A.5. RSVP Proxies for Reservations in the presence of IPsec A.5. RSVP Proxies for Reservations in the presence of IPsec
Gateways . . . . . . . . . . . . . . . . . . . . . . . . . 41 Gateways . . . . . . . . . . . . . . . . . . . . . . . . . 43
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 44 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 46
Intellectual Property and Copyright Statements . . . . . . . . . . 46 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 29 skipping to change at page 4, line 29
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 insisting on how they achieve the necessary
synchronization of RSVP reservations with application level synchronization of RSVP reservations with application level
requirements. Appendix A includes more detailed use cases for the requirements. Appendix A includes more detailed use cases for the
proxies in various real life deployment environments. proxies in various real life 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. It is also worth noting that RSVP application requirements. Also, when compared to the end to end RSVP
operations on endsystems is considerably simpler than on a router, model, the use of RSVP Proxies involves additional operational burden
and consequently that RSVP implementations on endsystems are very and/or impose some topological constaints. The additional
lightweight (particularly considering modern endsystems capabilities, operational burden comes in particular from additional configuration
including mobile and portable devices). For example, endsystem RSVP needed to activate the RSVP Proxies and to help them identify for
implementations are reported to only consume low tens of kilobytes of which senders/receivers a Proxy behavior is required and for which
code space. The present document should not be seen as an senders/receivers it is not (so that an RSVP Proxy does not attempt
encouragement to depart from the end to end RSVP model. Its purpose establishment of reservations on behalf of devices that are already
is only to allow RSVP deployment in special environments where RSVP establishing the reservations themselves). The additional
just cannot be used on some senders and/or some receivers for reasons topological constaints come in particular from the requirement to
specific to the environment. have one, and only one, Receiver Proxy on the path from any sender to
every non-RSVP capable device (so that an non-RSVP capable device is
always taken care of by an RSVP Proxy, and so that an RSVP Proxy does
not short-circuit another RSVP Proxy closer to the non-RSVP capable
device).
It is also worth noting that RSVP operations on endsystems is
considerably simpler than on a router, and consequently that RSVP
implementations on endsystems are very lightweight (particularly
considering modern endsystems capabilities, including mobile and
portable devices). For example, endsystem RSVP implementations are
reported to only consume low tens of kilobytes of code space. Hence,
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
deployment in special environments where RSVP just cannot be used on
some senders and/or some receivers for reasons specific to the
environment.
2. RSVP Proxy Behaviors 2. RSVP Proxy Behaviors
This section discusses the two types of proxies; the RSVP Sender This section discusses the two types of proxies; the RSVP Sender
Proxy operating on behalf of data senders, and the RSVP Receiver Proxy operating on behalf of data senders, and the RSVP Receiver
Proxy operating for data receivers. The concepts presented in this Proxy operating for data receivers. The concepts presented in this
document are not meant to deprecate the traditional [RFC2205] RSVP document are not meant to deprecate the traditional [RFC2205] RSVP
end-to-end model: end-to-end RSVP reservations are still expected to end-to-end model: end-to-end RSVP reservations are still expected to
be used whenever possible. However, RSVP Proxies are intended to be used whenever possible. However, RSVP Proxies are intended to
facilitate RSVP deployment where end-to-end RSVP signaling is not facilitate RSVP deployment where end-to-end RSVP signaling is not
skipping to change at page 16, line 10 skipping to change at page 17, line 10
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 DSCP of flows for which an RSVP
reservation has been successfully proxied from the flows for which a reservation has been successfully proxied from the flows for which a
reservation is not in place. In some situations, the Inspection- reservation is not in place. In some situations, the Inspection-
Triggered Proxy might be able to modify the "packets of interest" Triggered Proxy might be able to modify the "packets of interest"
(e.g. application signaling messages) to convey some hint to (e.g. application signaling messages) to convey some hint to
applications that the corresponding flows cannot be guaranteed by applications that the corresponding flows cannot be guaranteed by
RSVP reservations. RSVP reservations.
With the inspection-triggered Proxy approach, the RSVP Receiver Proxy With the inspection-triggered Proxy approach, the RSVP Proxy is
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 in can traffic inspection and then is somewhat limited in the actions it can
take in case of reservation failure. However, this may be a useful take in case of reservation failure. Depending on the "packets of
approach in some environments. Note also that this approach does not interest" used by the RSVP Proxy to trigger the reservation, there is
require any change to the RSVP protocol. a risk that the RSVP Proxy ends up establishing a reservation for a
media flow that actually never starts. However, this can be
mitigated by timing out and tear down of an unnecessary reservation
by the RSVP Proxy when no corresponding media flow is observed. The
inspection-triggered approach is also subject to the general
limitations associated with data inspection. This includes being
defeated in the presence of encryption or being dependent on some
topology constraints such as relying on the fact that both the
packets of interest and the corresponding flow packets always transit
through the same RSVP Proxy.
Nonetheless, this may be a useful approach in specific environments.
Note also that this approach does not require any change to the RSVP
protocol.
With the "Inspection-Triggered" RSVP Proxy approach, the RSVP router With the "Inspection-Triggered" RSVP Proxy approach, the RSVP router
may be configurable to use and interpret some specific "packets of may be configurable to use and interpret some specific "packets of
interest" as the trigger for RSVP Receiver Proxy behavior. interest" as the trigger for RSVP Receiver Proxy behavior.
4.4. STUN-Triggered Proxy 4.4. STUN-Triggered Proxy
In this approach, the RSVP Proxy 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 signaling to synchronize RSVP
reservations with application requirements. The STUN signaling is reservations with application requirements. The STUN signaling is
sent from endpoint to endpoint. This is illustrated in Figure 8. sent from endpoint to endpoint. This is illustrated in [RFC5389].
|----| |--------| *** |--------| |----| |----| |--------| *** |--------| |----|
| S |--------| RSVP |------*r*--------| RSVP |----------| R | | S |--------| RSVP |------*r*--------| RSVP |----------| R |
|----| | Proxy | *** | Proxy | |----| |----| | Proxy | *** | Proxy | |----|
|--------| |--------| |--------| |--------|
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^>
=======RSVP=======> =======RSVP=======>
skipping to change at page 17, line 28 skipping to change at page 18, 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 [I-D.ietf-behave-rfc3489bis] message In this approach, a STUN[RFC5389] message triggers the RSVP Proxy.
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
facilitates operation of the RSVP Proxy. The RSVP Proxy agent can facilitates operation of the RSVP Proxy. To ensure RSVP reservations
inform endpoints of an RSVP reservation failure implicitely by are only established when needed, the RSVP Proxy needs to
dropping the ICE connectivity check message or explicitely by sending distinguish, among all the STUN messages, the ones that reflect (with
ICMP messages back to the endpoint. This allows reasonably effective high likelihood) an actual upcoming media flow. This can be achieved
synchronisation between RSVP reservations handled by the RSVP Proxies by identifying the STUN messages associated with an ICE connectivity
and the application running on non RSVP-capable endpoints. It also check. In turn, this can be achieved through (some combination of)
has the benefits of operating through NATs. the following checks:
o if, as discussed above, new STUN attributes (e.g. conveying the
flow bandwidth) are indeed defined in the future in view of
facilitating STUN-Triggered reservations, then the presence of
these attributes would reveal that the STUN message is part of an
ICE connectivity check.
o the presence of the PRIORITY, USE-CANDIDATE, ICE-CONTROLLED or
ICE-CONTROLLING attributes reveals that the STUN message is part
of an ICE connectivity check
o the RSVP Proxy may wait for a STUN message containing the USE-
CANDIDATE attribute indicating the selected ICE "path" to trigger
reservation only for the selected "path". This allows the RSVP
Proxy to only trigger a reservation for the "path" actually
selected and therefore for the media flow that will actually be
established (for example when ICE is being used for v4/v6 path
selection).
o the RSVP Proxy configuration could contain some information
facilitating determination of when to perform RSVP Proxy
reservation and not. For example, the RSVP Proxy configuration
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
ICE connectivity check. As another example, the RSVP Proxy
configuration could contain information identifying the set of
DiffServ Code Point (DSCP) values that the media flows requiring
reservation use, so that STUN messages not using one of theses
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
Proxy ends up establishing a reservation for a media flow that
actually never starts. However, this is limited to situations where
the end-systems is interested enough in establishing connectivity for
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
when no cortresponding media flow is observed.
The RSVP Proxy agent can inform endpoints of an RSVP reservation
failure implicitely by dropping the ICE connectivity check message or
explicitely by sending ICMP messages back to the endpoint. This
allows reasonably effective synchronisation between RSVP reservations
handled by the RSVP Proxies and the application running on non RSVP-
capable endpoints. It also has the benefits of operating through
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 can't use ICE), a STUN Indication message [RFC5389] could be used to
[I-D.ietf-behave-rfc3489bis] could be used to carry the (yet to be carry the (yet to be defined) STUN attributes mentioned earlier to
defined) STUN attributes mentioned earlier to indicate the flow indicate the flow bandwidth, thereby providing a benefit similar to
bandwidth, thereby providing a benefit similar to the ICE the ICE connectivity check. STUN Indication messages are not
connectivity check. STUN Indication messages are not acknowledged by acknowledged by the receiver and have the same scalability as the
the receiver and have the same scalability as the underlying underlying multicast flow.
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. 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
trigger reservations) that is beyond its initial intended purpose,
the potential security implications need to be considered by the
operator.
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
skipping to change at page 29, line 29 skipping to change at page 31, line 29
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. Section 4.6. Thanks to James Polk and Magnus Westerlund for their
thorough review and comments.
8. Informative References 8. Informative References
[I-D.ietf-behave-rfc3489bis]
Rosenberg, J., Mahy, R., Matthews, P., and D. Wing,
"Session Traversal Utilities for (NAT) (STUN)",
draft-ietf-behave-rfc3489bis-15 (work in progress),
February 2008.
[I-D.ietf-dime-diameter-qos] [I-D.ietf-dime-diameter-qos]
Zorn, G., "Protocol for Diameter Quality of Service Zorn, G., "Protocol for Diameter Quality of Service
Application", November 2007. Application", November 2007.
[I-D.ietf-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] [I-D.ietf-mmusic-qos-identification]
Polk, J., Dhesikan, S., and G. Camarillo, "Quality of 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)", Description Protocol (SDP)",
draft-ietf-mmusic-qos-identification-01 (work in draft-ietf-mmusic-qos-identification-02 (work in
progress), January 2008. progress), October 2008.
[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., Manner, J., Narayanan, A., Guillou, A., and
L. Faucheur, "RSVP Extensions for Path-Triggered RSVP L. Faucheur, "RSVP Extensions for Path-Triggered RSVP
Receiver Proxy", draft-ietf-tsvwg-rsvp-proxy-proto-04 Receiver Proxy", draft-ietf-tsvwg-rsvp-proxy-proto-07
(work in progress), December 2007. (work in progress), July 2008.
[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-00 (work in draft-ietf-tsvwg-rsvp-security-groupkeying-01 (work in
progress), February 2008. progress), July 2008.
[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. [RFC2205] Braden, B., Zhang, L., Berson, S., Herzog, S., and S.
skipping to change at page 32, line 17 skipping to change at page 34, line 13
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,
"Session Traversal Utilities for NAT (STUN)", RFC 5389,
October 2008.
Appendix A. Use Cases for RSVP Proxies Appendix A. Use Cases for RSVP Proxies
A.1. RSVP-based VoD CAC in Broadband Aggregation Networks A.1. RSVP-based VoD CAC in Broadband Aggregation Networks
As broadband services for residential are becoming more and more As broadband services for residential are becoming more and more
prevalent, next generation aggregation networks are being deployed in prevalent, next generation aggregation networks are being deployed in
order to aggregate traffic from broadband users (whether attached via order to aggregate traffic from broadband users (whether attached via
Digital Subscriber Line technology aka DSL, Fiber To The Home/Curb Digital Subscriber Line technology aka DSL, Fiber To The Home/Curb
aka FTTx, Cable or other broadband access technology). 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
 End of changes. 22 change blocks. 
76 lines changed or deleted 151 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/