draft-ietf-tsvwg-rsvp-proxy-approaches-03.txt   draft-ietf-tsvwg-rsvp-proxy-approaches-04.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: June 16, 2008 University of Helsinki Expires: October 12, 2008 University of Helsinki
D. Wing D. Wing
Cisco Cisco
A. Guillou A. Guillou
Neuf Neuf
December 14, 2007 April 10, 2008
RSVP Proxy Approaches RSVP Proxy Approaches
draft-ietf-tsvwg-rsvp-proxy-approaches-03.txt draft-ietf-tsvwg-rsvp-proxy-approaches-04.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 June 16, 2008. This Internet-Draft will expire on October 12, 2008.
Copyright Notice
Copyright (C) The IETF Trust (2007).
Abstract Abstract
RSVP signaling can be used to make end-to-end resource reservations The Resource ReSerVation Protocol (RSVP) can be used to make end-to-
in an IP network in order to guarantee the Quality of Service end resource reservations in an IP network in order to guarantee the
required by certain flows. With conventional RSVP, both the data quality of service required by certain flows. RSVP assumes that both
sender and receiver of a given flow take part in RSVP signaling. the data sender and receiver of a given flow take part in RSVP
Yet, there are many use cases where resource reservation is required, signaling. Yet, there are many use cases where resource reservation
but the receiver, the sender, or both, is not RSVP-capable. This is required, but the receiver, the sender, or both, is not RSVP-
document presents RSVP Proxy behaviors allowing RSVP routers to capable. This document presents RSVP Proxy behaviors allowing RSVP
perform RSVP signaling on behalf of a receiver or a sender that is routers to initiate or terminate RSVP signaling on behalf of a
not RSVP-capable. This allows resource reservations to be receiver or a sender that is not RSVP-capable. This allows resource
established on critical parts of the end-to-end path. This document reservations to be established on a critical subset of the end-to-end
reviews conceptual approaches for deploying RSVP Proxies and path. This document reviews conceptual approaches for deploying RSVP
discusses how RSVP reservations can be synchronized with application Proxies and discusses how RSVP reservations can be synchronized with
requirements, despite the sender, receiver, or both not participating application requirements, despite the sender, receiver, or both not
in RSVP. This document also points out where extensions to RSVP (or participating in RSVP. This document also points out where
to other protocols) may be needed for deployment of a given RSVP extensions to RSVP (or to other protocols) may be needed for
Proxy approach. However, such extensions are outside the scope of deployment of a given RSVP Proxy approach. However, such extensions
this document. Finally, practical use cases for RSVP Proxy are are outside the scope of this document. Finally, practical use cases
described. for RSVP Proxy are described.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. RSVP Proxy Behaviors . . . . . . . . . . . . . . . . . . . . . 5 2. RSVP Proxy Behaviors . . . . . . . . . . . . . . . . . . . . . 4
2.1. RSVP Receiver Proxy . . . . . . . . . . . . . . . . . . . 5 2.1. RSVP Receiver Proxy . . . . . . . . . . . . . . . . . . . 5
2.2. RSVP Sender Proxy . . . . . . . . . . . . . . . . . . . . 6 2.2. RSVP Sender Proxy . . . . . . . . . . . . . . . . . . . . 5
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 7 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6
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 . . . . 10
4.3. Inspection-Triggered Proxy . . . . . . . . . . . . . . . . 13 4.3. Inspection-Triggered Proxy . . . . . . . . . . . . . . . . 14
4.4. STUN-Triggered Proxy . . . . . . . . . . . . . . . . . . . 15 4.4. STUN-Triggered Proxy . . . . . . . . . . . . . . . . . . . 16
4.5. Application_Entity-Controlled Proxy . . . . . . . . . . . 17 4.5. Application_Entity-Controlled Proxy . . . . . . . . . . . 18
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" . . . . . . . . . . . . . . . . . . . 20
4.5.2. Application_Entity-Controlled Proxy via Co-Location . 21 4.5.2. Application_Entity-Controlled Proxy via Co-Location . 22
4.6. Policy_Server-Controlled Proxy . . . . . . . . . . . . . . 22 4.6. Policy_Server-Controlled Proxy . . . . . . . . . . . . . . 23
4.7. RSVP-Signaling-Triggered Proxy . . . . . . . . . . . . . . 25 4.7. RSVP-Signaling-Triggered Proxy . . . . . . . . . . . . . . 26
4.8. Endsystem-Controlled Proxy . . . . . . . . . . . . . . . . 26 4.8. Reachability Considerations . . . . . . . . . . . . . . . 27
4.9. Reachability Considerations . . . . . . . . . . . . . . . 26 5. Security Considerations . . . . . . . . . . . . . . . . . . . 28
5. Security Considerations . . . . . . . . . . . . . . . . . . . 27 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 29
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 29
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 28 8. Informative References . . . . . . . . . . . . . . . . . . . . 29
8. Informative References . . . . . . . . . . . . . . . . . . . . 28 Appendix A. Use Cases for RSVP Proxies . . . . . . . . . . . . . 32
Appendix A. Use Cases for RSVP Proxies . . . . . . . . . . . . . 30 A.1. RSVP-based VoD CAC in Broadband Aggregation Networks . . . 32
A.1. RSVP-based VoD CAC in Broadband Aggregation Networks . . . 30 A.2. RSVP-based Voice/Video CAC in Enterprise WAN . . . . . . . 36
A.2. RSVP-based Voice/Video CAC in Enterprise WAN . . . . . . . 34 A.3. RSVP-based Voice CAC in Telephony Service Provider Core . 37
A.3. RSVP-based Voice CAC in Telephony Service Provider Core . 35 A.4. RSVP Proxies for Mobile Access Networks . . . . . . . . . 39
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 . . . . . . . . . . . . . . . . . . . . . . . . . 39 Gateways . . . . . . . . . . . . . . . . . . . . . . . . . 41
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 42 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 44
Intellectual Property and Copyright Statements . . . . . . . . . . 44 Intellectual Property and Copyright Statements . . . . . . . . . . 46
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
useful to be able to reserve resources for a flow on at least a useful to be able to reserve resources for a flow on at least a
subset of the flow path even when the sender or the receiver (or subset of the flow path even when the sender or the receiver (or
both) is not RSVP capable. both) is not RSVP (for example from the sender to the network edge,
or from edge to edge, or from the network edge to the receiver).
Since the data sender or receiver may be unaware of RSVP, there are Since the data sender or receiver may be unaware of RSVP, there are
two scenarios. In the first case, an entity in the network must two types of RSVP Proxies. When the sender is not using RSVP, an
operate on behalf of the data sender, and in particular, generate entity in the network must operate on behalf of the data sender, and
RSVP Path messages, and eventually receive, process and sink Resv in particular, generate RSVP Path messages, and eventually receive,
messages. We refer to this entity as the RSVP Sender Proxy. In the process and sink Resv messages. We refer to this entity as the RSVP
latter case, an entity in the network must receive Path messages sent Sender Proxy. When the receiver is not using RSVP, an entity in the
by a data sender (or by an RSVP Sender Proxy), sink those, and return network must receive Path messages sent by a data sender (or by an
Resv messages on behalf of the data receiver(s). We refer to this RSVP Sender Proxy), sink those, and return Resv messages on behalf of
entity as the RSVP Receiver Proxy. the data receiver(s). We refer to this entity as the RSVP Receiver
Proxy.
The flow sender and receiver generally have at least some (if not The flow sender and receiver generally have at least some (if not
full) awareness of the application producing or consuming that flow. full) awareness of the application producing or consuming that flow.
Hence, the sender and receiver are in a natural position to Hence, the sender and receiver are in a natural position to
synchronize the establishment, maintenance and tear down of the RSVP synchronize the establishment, maintenance and tear down of the RSVP
reservation with the application requirements. Similarly they are in reservation with the application requirements. Similarly they are in
a natural position to determine the characteristics of the a natural position to determine the characteristics of the
reservation (bandwidth, QoS service,...) which best match the reservation (bandwidth, QoS service,...) which best match the
application requirements. For example, before completing the application requirements. For example, before completing the
establishment of a multimedia session, the endpoints may decide to establishment of a multimedia session, the endpoints may decide to
establish RSVP reservations for the corresponding flows. Similarly, establish RSVP reservations for the corresponding flows. Similarly,
when the multimedia session is torn down, the endpoints may decide to when the multimedia session is torn down, the endpoints may decide to
tear down the corresponding RSVP reservations. For instance, tear down the corresponding RSVP reservations. For instance,
[RFC3312] discusses how RSVP reservations can be very tightly [RFC3312] discusses how RSVP reservations can be very tightly
synchronized by SIP endpoints with SIP session control and SIP synchronized by endpoints that uses the [RFC3261] Session Initation
signaling. Protocol (SIP) for session control.
When RSVP reservation establishment, maintenance and tearing down is When RSVP reservation establishment, maintenance and tearing down is
to be handled by RSVP Proxies on behalf of an RSVP sender or to be handled by RSVP Proxies on behalf of an RSVP sender or
receiver, a key challenge for the RSVP Proxy is to determine when the receiver, a key challenge for the RSVP Proxy is to determine when the
RSVP reservations need to be established, maintained and torn down RSVP reservations need to be established, maintained and torn down
and to determine what are the characteristics (bandwidth, QoS and to determine what are the characteristics (bandwidth, QoS
Service,...) of the required RSVP reservations matching the Service,...) of the required RSVP reservations matching the
application requirements. We refer to this problem as the application requirements. We refer to this problem as the
synchronization of RSVP reservations with application level synchronization of RSVP reservations with application level
requirements. requirements.
The IETF Next Steps in Signaling (NSIS) working group is designing, The IETF Next Steps in Signaling (NSIS) working group is specifying a
as one their charter items, a new QoS signaling protocol. This new QoS signaling protocol: the QoS NSIS Signaling Layer Protocol
scheme already includes the notion of proxy operation, and (NSLP) ([I-D.ietf-nsis-qos-nslp]). This protocol also includes the
terminating QoS signaling on nodes that are not the actual data notion of proxy operation, and terminating QoS signaling on nodes
senders or receivers. This is the same concept as the proxy that are not the actual data senders or receivers (see section "4.8
operation for RSVP discussed in this document. One difference though Proxy Mode" of [I-D.ietf-nsis-qos-nslp]. This is the same concept as
is that the NSIS framework does not consider multicast resource the proxy operation for RSVP discussed in this document. One
reservations, which RSVP provides today. difference though is that the NSIS framework does not consider
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 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
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
the most effective synchronization between the reservation and
application requirements. 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. 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 replace the standard RSVP and end-to-end document are not meant to deprecate the traditional [RFC2205] RSVP
RSVP reservations are still expected to be used whenever possible. end-to-end model: end-to-end RSVP reservations are still expected to
However, RSVP Proxies are intended to facilitate RSVP deployment be used whenever possible. However, RSVP Proxies are intended to
where end-to-end RSVP signaling is not possible. facilitate RSVP deployment where end-to-end RSVP signaling is not
possible.
2.1. RSVP Receiver Proxy 2.1. RSVP Receiver Proxy
With conventional RSVP operations, RSVP reservations are controlled With conventional end-to-end RSVP operations, RSVP reservations are
by receivers of data. After a data sender has sent an RSVP Path controlled by receivers of data. After a data sender has sent an
message towards the intended recipient(s), each recipient that RSVP Path message towards the intended recipient(s), each recipient
requires a reservation generates a Resv message. If, however, a data that requires a reservation generates a Resv message. If, however, a
receiver is not running the RSVP protocol, the last hop RSVP router data receiver is not running the RSVP protocol, the last hop RSVP
will still send the Path message to the data receiver, which will router will still send the Path message to the data receiver, which
silently drop this message as an IP packet with an unknown protocol will silently drop this message as an IP packet with an unknown
number. protocol number.
In order for reservations to be made in such a scenario, one of the In order for reservations to be made in such a scenario, one of the
RSVP routers on the data path must somehow know that the data RSVP routers on the data path determines that the data receiver will
receiver will not be participating in the resource reservation not be participating in the resource reservation signaling and
signaling. This RSVP router should, thus, perform RSVP Receiver performs RSVP Receiver Proxy functionality on behalf of the data
Proxy functionality on behalf of the data receiver. This is receiver. This is illustrated in Figure 1. Various mechanisms by
illustrated in Figure 1. Various mechanisms by which the RSVP proxy which the RSVP proxy router can gain the required information are
router can gain the required information are discussed later in the discussed later in the document.
document.
|----| *** *** |----------| |----| |----| *** *** |----------| |----|
| S |---------*r*----------*r*---------| RSVP |----------| R | | S |---------*r*----------*r*---------| RSVP |----------| R |
|----| *** *** | Receiver | |----| |----| *** *** | Receiver | |----|
| Proxy | | Proxy |
|----------| |----------|
===================RSVP==============> ===================RSVP==============>
***********************************************************> ***********************************************************>
skipping to change at page 6, line 27 skipping to change at page 5, line 46
|----| |----| *** router |----| |----| *** router
***> unidirectional media flow ***> unidirectional media flow
==> segment of flow path protected by RSVP reservation ==> segment of flow path protected by RSVP reservation
Figure 1: RSVP Receiver Proxy Figure 1: RSVP Receiver Proxy
2.2. RSVP Sender Proxy 2.2. RSVP Sender Proxy
With conventional RSVP operations, if a data sender is not running With conventional end-to-end RSVP operations, if a data sender is not
the RSVP protocol, a resource reservation can not be set up; a data running the RSVP protocol, a resource reservation can not be set up;
receiver can not alone reserve resources without Path messages first a data receiver can not alone reserve resources without Path messages
being received. Thus, even if the data receiver is running RSVP, it first being received. Thus, even if the data receiver is running
still needs some node on the data path to send a Path message towards RSVP, it still needs some node on the data path to send a Path
the data receiver. message towards the data receiver.
In that case, an RSVP node on the data path must somehow know that it In that case, an RSVP node on the data path determines that it should
should generate Path messages to allow the receiver to set up the generate Path messages to allow the receiver to set up the resource
resource reservation. This node is referred to as the RSVP Sender reservation. This node is referred to as the RSVP Sender Proxy and
Proxy and is illustrated in Figure 2. This case is more complex than is illustrated in Figure 2. This case presents additional challenges
the Receiver Proxy case, since the RSVP Sender Proxy must be able to over the Receiver Proxy case, since the RSVP Sender Proxy must be
generate all the information in the Path message (such as the Sender able to generate all the information in the Path message (such as the
TSpec) without the benefit of having previously received any RSVP Sender TSpec) without the benefit of having previously received any
message. An RSVP Receiver Proxy, by contrast only needs to formulate RSVP message. An RSVP Receiver Proxy, by contrast only needs to
an appropriate Resv message in response to an incoming Path message. formulate an appropriate Resv message in response to an incoming Path
Mechanisms to operate an RSVP Sender Proxy are discussed later in message. Mechanisms to operate an RSVP Sender Proxy are discussed
this document. later in this document.
|----| |----------| *** *** |----| |----| |----------| *** *** |----|
| S |---------| RSVP |---------*r*----------*r*----------| R | | S |---------| RSVP |---------*r*----------*r*----------| R |
|----| | Sender | *** *** |----| |----| | Sender | *** *** |----|
| Proxy | | Proxy |
|----------| |----------|
================RSVP==================> ================RSVP==================>
***********************************************************> ***********************************************************>
skipping to change at page 7, line 27 skipping to change at page 6, line 39
|----| |----| *** router |----| |----| *** router
***> unidirectional media flow ***> unidirectional media flow
==> segment of flow path protected by RSVP reservation ==> segment of flow path protected by RSVP reservation
Figure 2: RSVP Sender Proxy Figure 2: RSVP Sender Proxy
3. Terminology 3. Terminology
On-Path: located on the datapath of the actual flow of application o On-Path: located on the datapath of the actual flow of application
data (regardless of where it is located with respect to the data (regardless of where it is located with respect to the
application level signaling path). application level signaling path).
Off-Path: not On-Path. o Off-Path: not On-Path.
RSVP-capable (or RSVP-aware): which supports the RSVP protocol as per
[RFC2205].
RSVP Receiver Proxy: an RSVP capable router performing, on behalf of o RSVP-capable (or RSVP-aware): which supports the RSVP protocol as
a receiver, the RSVP operations which would normally be performed by per [RFC2205].
an RSVP-capable receiver if end-to-end RSVP signaling was used. Note
that while RSVP is used upstream of the RSVP Receiver Proxy, RSVP is
not used downstream of the RSVP Receiver Proxy.
RSVP Sender Proxy: an RSVP capable router performing, on behalf of a o RSVP Receiver Proxy: an RSVP capable router performing, on behalf
sender, the RSVP operations which would normally be performed by an of a receiver, the RSVP operations which would normally be
RSVP-capable sender if end-to-end RSVP signaling was used. Note that performed by an RSVP-capable receiver if end-to-end RSVP signaling
while RSVP is used downstream of the RSVP Sender Proxy, RSVP is not was used. Note that while RSVP is used upstream of the RSVP
used upstream of the RSVP Sender Proxy. Receiver Proxy, RSVP is not used downstream of the RSVP Receiver
Proxy.
Regular RSVP Router: an RSVP-capable router which is not behaving as o RSVP Sender Proxy: an RSVP capable router performing, on behalf of
a RSVP Receiver Proxy nor as a RSVP Sender Proxy. a sender, the RSVP operations which would normally be performed by
an RSVP-capable sender if end-to-end RSVP signaling was used.
Note that while RSVP is used downstream of the RSVP Sender Proxy,
RSVP is not used upstream of the RSVP Sender Proxy.
Note that the roles of RSVP Receiver Proxy, RSVP Sender Proxy, o Regular RSVP Router: an RSVP-capable router which is not behaving
Regular RSVP Router are all relative to one unidirectional flow. A as a RSVP Receiver Proxy nor as a RSVP Sender Proxy.
given 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 another flow.
Application level signaling: signaling between entities operating o Application level signaling: signaling between entities operating
above the IP layer and which are aware of the QoS requirements for above the IP layer and which are aware of the QoS requirements for
actual media flows. SIP and RTSP are examples of application level actual media flows. SIP ([RFC3261]) and RTSP ([RFC2326]) are
signaling protocol. RSVP is clearly not an application level examples of application level signaling protocol. SDP ([RFC4566])
is an example of session description protocol that can be used by
the application level signaling protocol and from which some of
the RSVP reservation parameters (addresses, ports and bandwidth)
might be derived. RSVP is clearly not an application level
signaling. signaling.
The roles of RSVP Receiver Proxy, RSVP Sender Proxy, Regular RSVP
Router are all relative to a given unidirectional flow. A given
router may act as the RSVP Receiver Proxy for a flow, as the RSVP
Sender Proxy for another flow and as a Regular RSVP router for yet
another flow.
Some application level signaling protocols support negotiation of QoS
reservations for a media stream. For example, with [RFC3312],
resource reservation requirements are explicitely signaled during
session establishment using SIP and SDP. Also,
[I-D.ietf-mmusic-qos-identification] defines a mechanism to negotiate
which resource reservation mechanism is to be used for a particular
media stream. Clearly, these reservation negotiation mechanisms can
be invoked and operate effectively when when both ends support RSVP
(and obviously RSVP Proxies are not used). When both ends do not
support RSVP (and RSVP proxies are used at both ends) these
mechanisms will simply not be invoked. In the case where one end
supports RSVP and the other does not (and is helped by an RSVP
Proxy), the application level signaling entity supporting the non
RSVP capable end might use the reservation negotiation mechanisms in
such a way that the non RSVP capable end (helped by an RSVP Proxy)
appears to the remote end as an RSVP capable device. This will
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
application level entity may achieve this by taking advantage of the
"segmented" Status Type of [RFC3312] and/or by implementing a SIP
[RFC3261] Back-to-Back User Agent (B2BUA).
4. RSVP Proxy Approaches 4. RSVP Proxy Approaches
This section discusses fundamental RSVP Proxy approaches. This section discusses fundamental RSVP Proxy approaches.
4.1. Path-Triggered Receiver Proxy 4.1. Path-Triggered Receiver Proxy
In this approach, it is assumed that the sender is RSVP capable and In this approach, it is assumed that the sender is RSVP capable and
takes full care of the synchronization between application takes full care of the synchronization between application
requirements and RSVP reservations. With this approach, the RSVP requirements and RSVP reservations. With this approach, the RSVP
Receiver Proxy uses the RSVP Path messages generated by the sender as Receiver Proxy uses the RSVP Path messages generated by the sender as
skipping to change at page 11, line 4 skipping to change at page 10, line 49
4.2. Path-Triggered Sender Proxy for Reverse Direction 4.2. Path-Triggered Sender Proxy for Reverse Direction
In this approach, it is assumed that one endpoint is RSVP capable and In this approach, it is assumed that one endpoint is RSVP capable and
takes full care of the synchronization between application takes full care of the synchronization between application
requirements and RSVP reservations. This endpoint is the sender for requirements and RSVP reservations. This endpoint is the sender for
one flow direction (which we refer to as the "forward" direction) and one flow direction (which we refer to as the "forward" direction) and
is the receiver for the flow in the opposite direction (which we is the receiver for the flow in the opposite direction (which we
refer to as the "reverse" direction). refer to as the "reverse" direction).
With the Path-Triggered Sender Proxy for Reverse Direction approach, With the Path-Triggered Sender Proxy for Reverse Direction approach,
the RSVP Proxy uses the RSVP signaling generated by the sender as the the RSVP Proxy uses the RSVP signaling generated by the receiver (for
cue for initiating RSVP signaling for the reservation in the reverse the reverse direction) as the cue for initiating RSVP signaling for
direction. Thus, the RSVP Proxy is effectively acting as a Sender the reservation in the reverse direction. More precisely, the RSVP
Proxy for the reverse direction under the control of the sender for Proxy can take the creation (respectively, maintenance and teardown)
the forward direction. Note that this assumes a degree of symmetry of a Path state by the receiver as the cue to create (respectively,
for the two directions of the flow (as is currently typical for IP maintain and teardown) a Path state towards the receiver. Thus, the
telephony, for example). This is illustrated in Figure 5. RSVP Proxy is effectively acting as a Sender Proxy for the reverse
direction under the control of the receiver (for the reverse
direction). Note that this assumes a degree of symmetry for example
in terms of bandwidth for the two directions of the flow (as is
currently typical for IP telephony, for example).
The signaling flow for the Path-Triggered Sender Proxy for Reverse
Direction is illustrated in Figure 5.
Path messages generated by the receiver need to transit via the RSVP
Sender Proxy that is on the path from the sender to the receiver. In
some topologies, this will always be the case: for example where the
sender is on a stub network hanging off the RSVP Sender Proxy or
where there is no asymetric routing (such that if a RSVP Sender Proxy
is on the path from receiver to sender, then it is also on the path
from sender to receiver). In some topologies (such as those
involving asymetric routing), this may not always happen naturally.
Measures to ensure this does happen in these topologies are outside
the scope of this document.
|----| *** *** |----------| |----| |----| *** *** |----------| |----|
| R |---------*r*----------*r*---------| RSVP |----------| S | | R |---------*r*----------*r*---------| RSVP |----------| S |
|----| *** *** | Sender | |----| |----| *** *** | Sender | |----|
| Proxy | | Proxy |
|----------| |----------|
---Path---> ----Path----> ---Path----> ---Path---> ----Path----> ---Path---->
<--Path---> <---Path----- <--Path---- <--Path---> <---Path----- <--Path----
---Resv---> ----Resv----> ---Resv----> ---Resv---> ----Resv----> ---Resv---->
<================RSVP================== <================RSVP==================
<********************************************************** <**********************************************************
|----| RSVP-capable |----| Non-RSVP-capable *** |----| RSVP-capable |----| Non-RSVP-capable ***
| R | Receiver | S | Sender *r* regular RSVP | R | Receiver for | S | Sender for *r* regular RSVP
|----| |----| *** router |----| reverse direction |----| reverse direction *** router
***> media flow ***> media flow
==> segment of flow path protected by RSVP reservation ==> segment of flow path protected by RSVP reservation
in reverse direction in reverse direction
Figure 5: Path-Triggered Sender Proxy for Reverse Direction Figure 5: Path-Triggered Sender Proxy for Reverse Direction
Of course, the RSVP Proxy may simultaneously (and typically will) Of course, the RSVP Proxy may simultaneously (and typically will)
also act as the Path-Triggered Receiver Proxy for the forward also act as the Path-Triggered Receiver Proxy for the forward
skipping to change at page 13, line 16 skipping to change at page 14, line 16
In order to build the Path message for the reverse direction, the In order to build the Path message for the reverse direction, the
RSVP Sender Proxy can take into account information in the received RSVP Sender Proxy can take into account information in the received
Path message for the forward direction. For example, the RSVP Sender Path message for the forward direction. For example, the RSVP Sender
Proxy may mirror the SENDER_TSPEC object in the received Path Proxy may mirror the SENDER_TSPEC object in the received Path
message. message.
We observe that this approach does not require any extensions to the We observe that this approach does not require any extensions to the
existing RSVP protocol. existing RSVP protocol.
In the case where reservations are required in both directions (as
shown in Figure 6), the RSVP-capable device simply needs to behave as
a regular RSVP sender and RSVP receiver. It needs not be aware that
an RSVP Proxy happens to be used and the Path message it sent for the
forward reservation also acts as the trigger for establishment of the
reverse reservation. However, in the case where a reservation is
only required in the reverse direction (as shown in Figure 5), the
RSVP-capable device has to generate Path messages in order to trigger
the reverse direction reservation even if no reservation is required
in the forward direction. Although this is not in violation with
[RFC2205], it may not be the default behavior of an RSVP-capable
device and therefore may need a behavioral change specifically to
facilitate operation of the Path-Triggered Sender Proxy for Reverse
Direction.
4.3. Inspection-Triggered Proxy 4.3. Inspection-Triggered Proxy
In this approach, it is assumed that the RSVP Proxy is on the In this approach, it is assumed that the RSVP Proxy is on the
datapath of "packets of interest", that it can inspect such packets datapath of "packets of interest", that it can inspect such packets
on the fly as they transit through it, and that it can infer on the fly as they transit through it, and that it can infer
information from these packets of interest to determine what RSVP information from these packets of interest to determine what RSVP
reservations need to be established, when and with what reservations need to be established, when and with what
characteristics (possibly also using some configured information). characteristics (possibly also using some configured information).
One example of "packets of interest" could be application level One example of "packets of interest" could be application level
skipping to change at page 14, line 46 skipping to change at page 15, line 46
Another example of "packets of interest" could be packets belonging Another example of "packets of interest" could be packets belonging
to the application flow itself (e.g. media packets). An RSVP Proxy to the application flow itself (e.g. media packets). An RSVP Proxy
capable of detecting the transit of packets from a particular flow, capable of detecting the transit of packets from a particular flow,
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 takes appropriate application signaling) so that the application is not in a position
action (for example terminate the corresponding session). To to take appropriate action (for example terminate the corresponding
mitigate this problem, the inspection-triggered RSVP Proxy may mark session). To mitigate this problem, the inspection-triggered RSVP
differently the DSCP of flows for which an RSVP reservation has been Proxy may mark differently the DSCP of flows for which an RSVP
successfully proxied from the flows for which a reservation is not in reservation has been successfully proxied from the flows for which a
place. In some situations, the Inspection-Triggered Proxy might be reservation is not in place. In some situations, the Inspection-
able to modify the "packets of interest" (e.g. application signaling Triggered Proxy might be able to modify the "packets of interest"
messages) to convey some hint to applications that the corresponding (e.g. application signaling messages) to convey some hint to
flows cannot be guaranteed by RSVP reservations. applications that the corresponding flows cannot be guaranteed by
RSVP reservations.
With the inspection-triggered Proxy approach, the RSVP Receiver Proxy With the inspection-triggered Proxy approach, the RSVP Receiver Proxy
is effectively required to attempt to build application awareness by is 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 in can
take in case of reservation failure. However, this may be a useful take in case of reservation failure. However, this may be a useful
approach in some environments. Note also that this approach does not approach in some environments. Note also that this approach does not
require any change to the RSVP protocol. 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
skipping to change at page 16, line 29 skipping to change at page 17, 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. The STUN message could also include (yet- triggers the RSVP Proxy.
to-be-specified) STUN attributes to indicate information such as the
bandwidth and application requesting the flow, which would allow the
RSVP proxy agent to create 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 a widely-adopted approach
emerging standard for NAT traversal. For our purposes of triggering for NAT traversal. For our purposes of triggering RSVP Proxy
RSVP Proxy behavior, we rely on ICE's connectivity check -- 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]). By connectivity (see section 2.2 of [I-D.ietf-mmusic-ice]). The STUN
including new STUN attributes in those connectivity check messages, message could also include (yet to be specified) STUN attributes to
an RSVP Proxy agent could perform its functions more effectively. indicate information such as the bandwidth and application requesting
Additionally, the RSVP Proxy agent can inform endpoints of an RSVP the flow, which would allow the RSVP proxy agent to create an
reservation failure by dropping the ICE connectivity check message or appropriately-sized reservation for each flow. Including such new
sending ICMP messages back to the endpoint. This provides very RSVP- STUN attributes in the ICE connectivity check messages would
like call admission control and signaling to the endpoints, without facilitates operation of the RSVP Proxy. The RSVP Proxy agent can
implementing RSVP on the endpoints, and also operates through NATs. 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
[I-D.ietf-behave-rfc3489bis] could indicate the flow's bandwidth, [I-D.ietf-behave-rfc3489bis] could be used to carry the (yet to be
providing a benefit similar to the ICE connectivity check. STUN defined) STUN attributes mentioned earlier to indicate the flow
Indication messages are not acknowledged by the receiver and have the bandwidth, thereby providing a benefit similar to the ICE
same scalability as the underlying multicast flow. connectivity check. STUN 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 18, line 40 skipping to change at page 19, line 40
==> segment of flow path protected by RSVP reservation ==> segment of flow path protected by RSVP reservation
/\ Application signaling (e.g. SIP) /\ Application signaling (e.g. SIP)
// RSVP Proxy control interface // RSVP Proxy control interface
Figure 9: Application_Entity-Controlled Proxy Figure 9: Application_Entity-Controlled Proxy
As an example, the Application_Entity-Controlled Proxy may be used in As an example, the Application_Entity-Controlled Proxy may be used in
the context of Session Border Controllers (SBCs) (see the context of SIP Servers ([RFC3261]) or Session Border Controllers
[I-D.ietf-sipping-sbc-funcs] for description of SBCs) to establish (SBCs) (see [I-D.ietf-sipping-sbc-funcs] for description of SBCs) to
RSVP reservations for multimedia sessions. In that case, the establish RSVP reservations for multimedia sessions. In that case,
Application Entity may be the signaling component of the SBC. the Application Entity may be the signaling component of the SBC.
This RSVP Proxy approach does not require any extension to the RSVP This RSVP Proxy approach does not require any extension to the RSVP
protocol. However, it relies on an RSVP Proxy control interface protocol. However, it relies on an RSVP Proxy control interface
allowing control of the RSVP Proxy by an application signaling allowing control of the RSVP Proxy by an application signaling
entity. This RSVP Proxy control interface is beyond the scope of the entity. This RSVP Proxy control interface is beyond the scope of the
present document. Candidate protocols for realizing such interface present document. Candidate protocols for realizing such interface
include SNMP, COPS-PR, QPIM, XML and DIAMETER. This interface may include SNMP([RFC3416]), COPS-PR([RFC3084]), QPIM ([RFC3644]), the
rely on soft states or hard states. Clearly, when hard states are Extensible Markup Language (XML) and DIAMETER([RFC3588]). This
used, those need to be converted appropriately by the RSVP Proxy interface can rely on soft states or hard states. Clearly, when hard
entities into the corresponding RSVP soft states. As an example, states are used, those need to be converted appropriately by the RSVP
[I-D.ietf-dime-diameter-qos] is intended to allow control of RSVP Proxy entities into the corresponding RSVP soft states. As an
Proxy via DIAMETER. example, [I-D.ietf-dime-diameter-qos] is intended to allow control of
RSVP Proxy via DIAMETER.
In general, the Application Entity is not expected to maintain In general, the Application Entity is not expected to maintain
awareness of which RSVP Receiver Proxy is on the path to which awareness of which RSVP Receiver Proxy is on the path to which
destination. However, in the particular cases where it does so destination. However, in the particular cases where it does so
reliably, we observe that the Application Entity could control the reliably, we observe that the Application Entity could control the
RSVP Sender Proxy and Receiver Proxy so that aggregate RSVP RSVP Sender Proxy and Receiver Proxy so that aggregate RSVP
reservations are used between those, instead of one reservation per reservations are used between those, instead of one reservation per
flow. For example, these aggregate reservations could be of RSVP- flow. For example, these aggregate reservations could be of RSVP-
AGGREGATE type as specified in [RFC3175] or of GENERIC-AGGREGATE type AGGREGATE type as specified in [RFC3175] or of GENERIC-AGGREGATE type
as specified in [RFC4860]. Such aggregate reservations could be used as specified in [RFC4860]. Such aggregate reservations could be used
skipping to change at page 21, line 24 skipping to change at page 22, line 24
the datapath for the flow (and upstream of the segment which the datapath for the flow (and upstream of the segment which
requires QoS guarantees via RSVP reservation). requires QoS guarantees via RSVP reservation).
o processes the corresponding received RSVP messages (including Resv o processes the corresponding received RSVP messages (including Resv
messages) as per regular RSVP. messages) as per regular RSVP.
o synchronizes the RSVP reservation state with application level o synchronizes the RSVP reservation state with application level
requirements and signaling. requirements and signaling.
Note that since the application entity encodes its own IP address as Note that since the application entity encodes its own IP address as
the RSVP PHOP in the Path message, the RSVP Router terminating the the previous RSVP hop inside the [RFC2205] RSVP_HOP object of the
GRE tunnel naturally addresses all the RSVP messages travelling Path message, the RSVP Router terminating the GRE tunnel naturally
upstream hop-by-hop (such as Resv messages) to the application entity addresses all the RSVP messages travelling upstream hop-by-hop (such
(without having to encapsulate those in a reverse-direction GRE as Resv messages) to the application entity (without having to
tunnel towards the application entity). encapsulate those in a reverse-direction GRE tunnel towards the
application entity).
4.5.2. Application_Entity-Controlled Proxy via Co-Location 4.5.2. Application_Entity-Controlled Proxy via Co-Location
This approach is simply a particular case of the more general This approach is simply a particular case of the more general
Application_Entity-Controlled Proxy, but where the application entity Application_Entity-Controlled Proxy, but where the application entity
is co-located with the RSVP Proxy. As an example, Session Border is co-located with the RSVP Proxy. As an example, Session Border
Controllers (SBC) with on-board SIP agents could implement RSVP Proxy Controllers (SBC) with on-board SIP agents could implement RSVP Proxy
functions and make use of such an approach to achieve session functions and make use of such an approach to achieve session
admission control over the SBC-to-SBC segment using RSVP signaling. admission control over the SBC-to-SBC segment using RSVP signaling.
skipping to change at page 26, line 20 skipping to change at page 27, line 20
towards the triggering node. The node then replies back with a Resv. towards the triggering node. The node then replies back with a Resv.
More details can be found in [I-D.manner-tsvwg-rsvp-proxy-sig]. More details can be found in [I-D.manner-tsvwg-rsvp-proxy-sig].
Such an RSVP-Signaling-Triggered Proxy approach would require RSVP Such an RSVP-Signaling-Triggered Proxy approach would require RSVP
signaling extensions (that are outside the scope of the present signaling extensions (that are outside the scope of the present
document). However it could provide more flexibility in the control document). However it could provide more flexibility in the control
of the Proxy behavior (e.g. control of reverse reservation of the Proxy behavior (e.g. control of reverse reservation
parameters) than provided by the Path-Triggered approaches defined in parameters) than provided by the Path-Triggered approaches defined in
Section 4.1 and Section 4.2. Section 4.1 and Section 4.2.
4.8. Endsystem-Controlled Proxy 4.8. Reachability Considerations
In some cases, having a full RSVP implementation running on an end
host can be seen to produce excessive overhead. In end-hosts that
are low in processing power and functionality, having an RSVP daemon
run and take care of the signaling may introduce unnecessary
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
and the end-host application would send its requests to that daemon.
Thus, we can have deployments, where an end host uses some
lightweight protocol to communicate with its pre-defined RSVP router
- a form of RSVP proxy. Such a lightweight protocol is outside the
scope of the present document.
4.9. Reachability Considerations
There may be situations where the RSVP Receiver Proxy is reachable by There may be situations where the RSVP Receiver Proxy is reachable by
the sender, while the receiver itself is not. In such situations, it 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 is possible that the RSVP Receiver Proxy is not always aware that the
receiver is unreachable, and consequently may accept to establish an receiver is unreachable, and consequently may accept to establish an
RSVP reservation on behalf of that receiver. This would result in RSVP reservation on behalf of that receiver. This would result in
unnecessary reservation establishment and unnecessary network unnecessary reservation establishment and unnecessary network
resource consumption. resource consumption.
This is not considered a significant practical concern for a number This is not considered a significant practical concern for a number
skipping to change at page 27, line 33 skipping to change at page 28, line 19
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 RSVP messages and replay. [I-D.ietf-tsvwg-rsvp-security-groupkeying]
replay.[I-D.behringer-tsvwg-rsvp-security-groupkeying] discusses key discusses key types and key provisioning methods as well as their
types and key provisioning methods as well as their respective respective applicability to RSVP authentication mechanisms and to
applicability to RSVP authentication mechanisms and to IPsec IPsec protection (e.g. [RFC4303]) of RSVP.
protection (e.g. [RFC4303]) of RSVP.
A number of additional security considerations apply to the use of A number of additional security considerations apply to the use of
RSVP proxies and are discussed below. RSVP proxies and are discussed below.
With some RSVP Proxy approaches, the RSVP proxy operates autonomously With some RSVP Proxy approaches, the RSVP proxy operates autonomously
inside an RSVP router. This is the case for the Path-Triggered Proxy inside an RSVP router. This is the case for the Path-Triggered Proxy
approaches defined in Section 4.1 and in Section 4.2, for the approaches defined in Section 4.1 and in Section 4.2, for the
Inspection-Triggered Proxy approach defined in Section 4.3, for the Inspection-Triggered Proxy approach defined in Section 4.3, for the
STUN-Triggered Proxy approach defined in Section 4.4 and for the STUN-Triggered Proxy approach defined in Section 4.4 and for the
RSVP-Signaling-Triggered approach defined in Section 4.7. Proper RSVP-Signaling-Triggered approach defined in Section 4.7. Proper
skipping to change at page 28, line 48 skipping to change at page 29, line 33
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]
Behringer, M. and F. Le Faucheur, "Applicability of Keying
Methods for RSVP Security", November 2007.
[I-D.ietf-behave-rfc3489bis] [I-D.ietf-behave-rfc3489bis]
Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, Rosenberg, J., Mahy, R., Matthews, P., and D. Wing,
"Session Traversal Utilities for (NAT) (STUN)", "Session Traversal Utilities for (NAT) (STUN)",
draft-ietf-behave-rfc3489bis-13 (work in progress), draft-ietf-behave-rfc3489bis-15 (work in progress),
November 2007. 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]
Polk, J., Dhesikan, S., and G. Camarillo, "Quality of
Service (QoS) Mechanism Selection in the Session
Description Protocol (SDP)",
draft-ietf-mmusic-qos-identification-01 (work in
progress), January 2008.
[I-D.ietf-nsis-qos-nslp]
Manner, J., Karagiannis, G., and A. McDonald, "NSLP for
Quality-of-Service Signaling", draft-ietf-nsis-qos-nslp-16
(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]
Le Faucheur, F., Manner, J., Narayanan, A., Guillou, A., Faucheur, F., Manner, J., Narayanan, A., Guillou, A., and
and H. Malik, "RSVP Extensions For Path-Triggered RSVP L. Faucheur, "RSVP Extensions for Path-Triggered RSVP
Receiver Proxy", December 2007. Receiver Proxy", draft-ietf-tsvwg-rsvp-proxy-proto-04
(work in progress), December 2007.
[I-D.ietf-tsvwg-rsvp-security-groupkeying]
Behringer, M. and F. Faucheur, "Applicability of Keying
Methods for RSVP Security",
draft-ietf-tsvwg-rsvp-security-groupkeying-00 (work in
progress), February 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.
[Kars01] Karsten, M., "Experimental Extensions to RSVP -- Remote
Client and One-Pass Signalling", IWQoS Karlsruhe, Germany,
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.
Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1
Functional Specification", RFC 2205, September 1997. Functional Specification", RFC 2205, September 1997.
[RFC2210] Wroclawski, J., "The Use of RSVP with IETF Integrated [RFC2210] Wroclawski, J., "The Use of RSVP with IETF Integrated
Services", RFC 2210, September 1997. Services", RFC 2210, September 1997.
[RFC2326] Schulzrinne, H., Rao, A., and R. Lanphier, "Real Time
Streaming Protocol (RTSP)", RFC 2326, April 1998.
[RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., [RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z.,
and W. Weiss, "An Architecture for Differentiated and W. Weiss, "An Architecture for Differentiated
Services", RFC 2475, December 1998. Services", RFC 2475, December 1998.
[RFC2747] Baker, F., Lindell, B., and M. Talwar, "RSVP Cryptographic [RFC2747] Baker, F., Lindell, B., and M. Talwar, "RSVP Cryptographic
Authentication", RFC 2747, January 2000. Authentication", RFC 2747, January 2000.
[RFC2961] Berger, L., Gan, D., Swallow, G., Pan, P., Tommasi, F., [RFC2961] Berger, L., Gan, D., Swallow, G., Pan, P., Tommasi, F.,
and S. Molendini, "RSVP Refresh Overhead Reduction and S. Molendini, "RSVP Refresh Overhead Reduction
Extensions", RFC 2961, April 2001. Extensions", RFC 2961, April 2001.
[RFC3084] Chan, K., Seligson, J., Durham, D., Gai, S., McCloghrie,
K., Herzog, S., Reichmeyer, F., Yavatkar, R., and A.
Smith, "COPS Usage for Policy Provisioning (COPS-PR)",
RFC 3084, March 2001.
[RFC3097] Braden, R. and L. Zhang, "RSVP Cryptographic [RFC3097] Braden, R. and L. Zhang, "RSVP Cryptographic
Authentication -- Updated Message Type Value", RFC 3097, Authentication -- Updated Message Type Value", RFC 3097,
April 2001. April 2001.
[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,
A., Peterson, J., Sparks, R., Handley, M., and E.
Schooler, "SIP: Session Initiation Protocol", RFC 3261,
June 2002.
[RFC3312] Camarillo, G., Marshall, W., and J. Rosenberg, [RFC3312] Camarillo, G., Marshall, W., and J. Rosenberg,
"Integration of Resource Management and Session Initiation "Integration of Resource Management and Session Initiation
Protocol (SIP)", RFC 3312, October 2002. Protocol (SIP)", RFC 3312, October 2002.
[RFC3416] Presuhn, R., "Version 2 of the Protocol Operations for the
Simple Network Management Protocol (SNMP)", STD 62,
RFC 3416, December 2002.
[RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J.
Arkko, "Diameter Base Protocol", RFC 3588, September 2003.
[RFC3644] Snir, Y., Ramberg, Y., Strassner, J., Cohen, R., and B.
Moore, "Policy Quality of Service (QoS) Information
Model", RFC 3644, November 2003.
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the [RFC4301] Kent, S. and K. Seo, "Security Architecture for the
Internet Protocol", RFC 4301, December 2005. Internet Protocol", RFC 4301, December 2005.
[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)",
RFC 4303, December 2005. RFC 4303, December 2005.
[RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session
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.
Appendix A. Use Cases for RSVP Proxies Appendix A. Use Cases for RSVP Proxies
skipping to change at page 44, line 7 skipping to change at page 46, line 7
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@neufcegetel.fr
Full Copyright Statement Full Copyright Statement
Copyright (C) The IETF Trust (2007). Copyright (C) The IETF Trust (2008).
This document is subject to the rights, licenses and restrictions This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors contained in BCP 78, and except as set forth therein, the authors
retain all their rights. retain all their rights.
This document and the information contained herein are provided on an This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
skipping to change at page 44, line 44 skipping to change at line 1885
attempt made to obtain a general license or permission for the use of attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr. http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at this standard. Please address the information to the IETF at
ietf-ipr@ietf.org. ietf-ipr@ietf.org.
Acknowledgment
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
 End of changes. 54 change blocks. 
218 lines changed or deleted 321 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/