draft-ietf-tsvwg-rsvp-proxy-approaches-01.txt   draft-ietf-tsvwg-rsvp-proxy-approaches-02.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: January 10, 2008 University of Helsinki Expires: March 15, 2008 University of Helsinki
D. Wing D. Wing
Cisco Cisco
A. Guillou A. Guillou
Neuf Neuf
July 9, 2007 September 12, 2007
RSVP Proxy Approaches RSVP Proxy Approaches
draft-ietf-tsvwg-rsvp-proxy-approaches-01.txt draft-ietf-tsvwg-rsvp-proxy-approaches-02.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 January 10, 2008. This Internet-Draft will expire on March 15, 2008.
Copyright Notice Copyright Notice
Copyright (C) The IETF Trust (2007). Copyright (C) The IETF Trust (2007).
Abstract Abstract
RSVP signaling can be used to make end-to-end resource reservations RSVP signaling can be used to make end-to-end resource reservations
in an IP network in order to guarantee the Quality of Service in an IP network in order to guarantee the Quality of Service
required by certain flows. With conventional RSVP, both the data required by certain flows. With conventional RSVP, both the data
skipping to change at page 2, line 39 skipping to change at page 2, line 39
4.2. Path-Triggered Sender Proxy for Reverse Direction . . . . 10 4.2. Path-Triggered Sender Proxy for Reverse Direction . . . . 10
4.3. Inspection-Triggered Proxy . . . . . . . . . . . . . . . . 13 4.3. Inspection-Triggered Proxy . . . . . . . . . . . . . . . . 13
4.4. STUN-Triggered Proxy . . . . . . . . . . . . . . . . . . . 15 4.4. STUN-Triggered Proxy . . . . . . . . . . . . . . . . . . . 15
4.5. Application_Entity-Controlled Proxy . . . . . . . . . . . 17 4.5. Application_Entity-Controlled Proxy . . . . . . . . . . . 17
4.5.1. Application_Entity-Controlled Sender Proxy using 4.5.1. Application_Entity-Controlled Sender Proxy using
"RSVP over GRE" . . . . . . . . . . . . . . . . . . . 19 "RSVP over GRE" . . . . . . . . . . . . . . . . . . . 19
4.5.2. Application_Entity-Controlled Proxy via Co-Location . 21 4.5.2. Application_Entity-Controlled Proxy via Co-Location . 21
4.6. Policy_Server-Controlled Proxy . . . . . . . . . . . . . . 22 4.6. Policy_Server-Controlled Proxy . . . . . . . . . . . . . . 22
4.7. RSVP-Signaling-Triggered Proxy . . . . . . . . . . . . . . 25 4.7. RSVP-Signaling-Triggered Proxy . . . . . . . . . . . . . . 25
4.8. Endsystem-Controlled Proxy . . . . . . . . . . . . . . . . 26 4.8. Endsystem-Controlled Proxy . . . . . . . . . . . . . . . . 26
5. Security Considerations . . . . . . . . . . . . . . . . . . . 26 4.9. Reachability Considerations . . . . . . . . . . . . . . . 26
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27 5. Security Considerations . . . . . . . . . . . . . . . . . . . 27
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 27 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 28
8. Informative References . . . . . . . . . . . . . . . . . . . . 28 8. Informative References . . . . . . . . . . . . . . . . . . . . 28
Appendix A. Use Cases for RSVP Proxies . . . . . . . . . . . . . 29 Appendix A. Use Cases for RSVP Proxies . . . . . . . . . . . . . 30
A.1. RSVP-based VoD CAC in Broadband Aggregation Networks . . . 29 A.1. RSVP-based VoD CAC in Broadband Aggregation Networks . . . 30
A.2. RSVP-based Voice/Video CAC in Enterprise WAN . . . . . . . 33 A.2. RSVP-based Voice/Video CAC in Enterprise WAN . . . . . . . 34
A.3. RSVP-based Voice CAC in Telephony Service Provider Core . 34 A.3. RSVP-based Voice CAC in Telephony Service Provider Core . 35
A.4. RSVP Proxies for Mobile Access Networks . . . . . . . . . 36 A.4. RSVP Proxies for Mobile Access Networks . . . . . . . . . 37
A.5. RSVP Proxies for Reservations in the presence of IPsec A.5. RSVP Proxies for Reservations in the presence of IPsec
Gateways . . . . . . . . . . . . . . . . . . . . . . . . . 38 Gateways . . . . . . . . . . . . . . . . . . . . . . . . . 39
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 41 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 42
Intellectual Property and Copyright Statements . . . . . . . . . . 43 Intellectual Property and Copyright Statements . . . . . . . . . . 44
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 8, line 19 skipping to change at page 8, line 19
yet another flow. yet another flow.
Application level signaling: signaling between entities operating Application level signaling: signaling between entities operating
above the IP layer and which are aware of the QoS requirements for above the IP layer and which are aware of the QoS requirements for
actual media flows. SIP and RTSP are examples of application level actual media flows. SIP and RTSP are examples of application level
signaling protocol. RSVP is clearly not an application level signaling protocol. RSVP is clearly not an application level
signaling. signaling.
4. RSVP Proxy Approaches 4. RSVP Proxy Approaches
This section discusses several fundamental RSVP Proxy approaches. This section discusses fundamental RSVP Proxy approaches.
4.1. Path-Triggered Receiver Proxy 4.1. Path-Triggered Receiver Proxy
In this approach, it is assumed that the sender is RSVP capable and In this approach, it is assumed that the sender is RSVP capable and
takes full care of the synchronization between application takes full care of the synchronization between application
requirements and RSVP reservations. With this approach, the RSVP requirements and RSVP reservations. With this approach, the RSVP
Receiver Proxy uses the RSVP Path messages generated by the sender as Receiver Proxy uses the RSVP Path messages generated by the sender as
the cue for establishing the RSVP reservation on behalf of the the cue for establishing the RSVP reservation on behalf of the
receiver. The RSVP Receiver Proxy is effectively acting as a slave receiver. The RSVP Receiver Proxy is effectively acting as a slave
making reservations (on behalf of the receiver) under the sender's making reservations (on behalf of the receiver) under the sender's
skipping to change at page 16, line 29 skipping to change at page 16, line 29
^^^> 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 [I-D.ietf-behave-rfc3489bis] message
triggers the RSVP proxy. Using a STUN message eases the RSVP proxy triggers the RSVP Proxy. The STUN message could also include (yet-
agent's computational burden because it need only look for STUN to-be-specified) STUN attributes to indicate information such as the
messages rather than maintain state of all flows. More importantly, bandwidth and application requesting the flow, which would allow the
the STUN message can also include a STUN attribute describing the RSVP proxy agent to create an appropriately-sized reservation for
bandwidth and describing the application requesting the flow, which each flow.
allows the RSVP proxy agent to authorize an appropriately-sized
reservation for each flow.
For unicast flows, [I-D.ietf-mmusic-ice] is an already widely-adopted For unicast flows, [I-D.ietf-mmusic-ice] is an already widely-adopted
emerging standard for NAT traversal. For our purposes, we are not emerging standard for NAT traversal. For our purposes of triggering
interested in its NAT traversal capabilities. Rather, ICE's useful RSVP Proxy behavior, we rely on ICE's connectivity check -- the
characteristic is its connectivity check -- the exchange of STUN exchange of STUN Binding Request messages between hosts to verify
Binding Request messages between hosts to verify connectivity (see connectivity (see section 2.2 of [I-D.ietf-mmusic-ice]). By
Connectivity Check Usage in [I-D.ietf-behave-rfc3489bis]). By including new STUN attributes in those connectivity check messages,
including new STUN attributes in those messages an RSVP proxy agent an RSVP Proxy agent could perform its functions more effectively.
could perform its functions more effectively. Additionally, the RSVP Additionally, the RSVP Proxy agent can inform endpoints of an RSVP
proxy agent can inform endpoints of an RSVP reservation failure by reservation failure by dropping the ICE connectivity check message or
dropping the ICE connectivity check message. This provides very sending ICMP messages back to the endpoint. This provides very RSVP-
RSVP-like call admission control and signaling to the endpoints, like call admission control and signaling to the endpoints, without
without implementing RSVP on the endpoints. implementing RSVP on the endpoints, and also operates 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
[I-D.ietf-behave-rfc3489bis] could be used for similar purposes. The [I-D.ietf-behave-rfc3489bis] could indicate the flow's bandwidth,
STUN Indication message is not acknowledged by its receiver and has providing a benefit similar to the ICE connectivity check. STUN
the same scalability as the underlying multicast flow itself. Indication messages are not acknowledged by the receiver and have the
same scalability as the 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. They may be defined in the future in a separate document.
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
skipping to change at page 26, line 34 skipping to change at page 26, line 34
are low in processing power and functionality, having an RSVP daemon are low in processing power and functionality, having an RSVP daemon
run and take care of the signaling may introduce unnecessary run and take care of the signaling may introduce unnecessary
overhead. One article [Kars01] proposes to create a remote API so overhead. One article [Kars01] proposes to create a remote API so
that the daemon would in fact run on the end-host's default router that the daemon would in fact run on the end-host's default router
and the end-host application would send its requests to that daemon. and the end-host application would send its requests to that daemon.
Thus, we can have deployments, where an end host uses some Thus, we can have deployments, where an end host uses some
lightweight protocol to communicate with its pre-defined RSVP router lightweight protocol to communicate with its pre-defined RSVP router
- a form of RSVP proxy. Such a lightweight protocol is outside the - a form of RSVP proxy. Such a lightweight protocol is outside the
scope of the present document. scope of the present document.
4.9. Reachability Considerations
There may be situations where the RSVP Receiver Proxy is reachable by
the sender, while the receiver itself is not. In such situations, it
is possible that the RSVP Receiver Proxy is not always aware that the
receiver is unreachable, and consequently may accept to establish an
RSVP reservation on behalf of that receiver. This would result in
unnecessary reservation establishment and unnecessary network
resource consumption.
This is not considered a significant practical concern for a number
of reasons. First, in many cases, if the receiver is not reachable
from the sender, it will not be reachable either for application
signaling so that application level session establishment will not be
possible in the first place. Secondly, where the receiver is
unreachable from the sender but is reachable for application level
signaling (say because session establishment is performed through an
off-path SIP agent that uses a different logical topology to
communicate with the receiver), then the sender may detect that the
receiver is unreachable before attempting reservation establishment.
This may be achieved through mechanisms such as ICE's connectivity
check ( [I-D.ietf-mmusic-ice]). Finally, even if the sender does not
detect that the receiver is unreachable before triggering the RSVP
reservation establishment, it is very likely that the application
will quickly realise this lack of connectivity (e.g. the human
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
(e.g. hang up the phone) which in turn will trigger RSVP reservation
release.
Nonetheless, it is recommended that network administrators consider
the above in light of their particular environment when deploying
RSVP Proxys.
The mirror considerations apply for situations involving an RSVP
Sender Proxy and where the sender cannot reach the destination while
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. To ensure the integrity of the associated reservation path of flows. To ensure the integrity of the associated reservation
and admission control mechanisms, the cryptographic authentication and admission control mechanisms, the cryptographic authentication
mechanisms defined in [RFC2747]] and [RFC3097] can be used. Those mechanisms defined in [RFC2747]] and [RFC3097] can be used. Those
protect RSVP messages integrity hop-by-hop and provide node protect RSVP messages integrity hop-by-hop and provide node
authentication, thereby protecting against corruption, spoofing of authentication, thereby protecting against corruption, spoofing of
RSVP messages and replay. RSVP messages and replay.
skipping to change at page 28, line 11 skipping to change at page 28, line 47
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.
8. Informative References 8. Informative References
[I-D.behringer-tsvwg-rsvp-security-groupkeying] [I-D.behringer-tsvwg-rsvp-security-groupkeying]
Behringer, M., Le Faucheur, F., and F. Baker, "A Framework Behringer, M. and F. Le Faucheur, "A Framework for RSVP
for RSVP Security Using Dynamic Group Keying", July 2007. Security Using Dynamic Group Keying", July 2007.
[I-D.ietf-behave-rfc3489bis] [I-D.ietf-behave-rfc3489bis]
Rosenberg, J., Huitema, C., Mahy, R., Matthews, P., and D. Rosenberg, J., Huitema, C., Mahy, R., Matthews, P., and D.
Wing, "Session Traversal Utilities for (NAT) (STUN)", Wing, "Session Traversal Utilities for (NAT) (STUN)",
draft-ietf-behave-rfc3489bis-07 (work in progress), draft-ietf-behave-rfc3489bis-09 (work in progress),
July 2007. August 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-16 (work in progress), June 2007. draft-ietf-mmusic-ice-17 (work in progress), July 2007.
[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]
Le Faucheur, L., "RSVP Extensions For Path-Triggered RSVP Le Faucheur, L., "RSVP Extensions For Path-Triggered RSVP
Receiver Proxy", February 2007. Receiver Proxy", February 2007.
 End of changes. 15 change blocks. 
42 lines changed or deleted 80 lines changed or added

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