draft-ietf-tsvwg-rsvp-proxy-proto-08.txt   draft-ietf-tsvwg-rsvp-proxy-proto-09.txt 
TSVWG F. Le Faucheur TSVWG F. Le Faucheur
Internet-Draft Cisco Internet-Draft Cisco
Intended status: Standards Track J. Manner Intended status: Standards Track J. Manner
Expires: September 3, 2009 University of Helsinki Expires: November 5, 2009 University of Helsinki
A. Narayanan A. Narayanan
Cisco Cisco
A. Guillou A. Guillou
Neuf Neuf
H. Malik H. Malik
Bharti Bharti
March 2, 2009 May 4, 2009
RSVP Extensions for Path-Triggered RSVP Receiver Proxy RSVP Extensions for Path-Triggered RSVP Receiver Proxy
draft-ietf-tsvwg-rsvp-proxy-proto-08.txt draft-ietf-tsvwg-rsvp-proxy-proto-09.txt
Status of this Memo Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79. This document may contain material provisions of BCP 78 and BCP 79. This document may contain material
from IETF Documents or IETF Contributions published or made publicly from IETF Documents or IETF Contributions published or made publicly
available before November 10, 2008. The person(s) controlling the available before November 10, 2008. The person(s) controlling the
copyright in some of this material may not have granted the IETF copyright in some of this material may not have granted the IETF
Trust the right to allow modifications of such material outside the Trust the right to allow modifications of such material outside the
IETF Standards Process. Without obtaining an adequate license from IETF Standards Process. Without obtaining an adequate license from
skipping to change at page 1, line 49 skipping to change at page 1, line 49
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 September 3, 2009. This Internet-Draft will expire on November 5, 2009.
Copyright Notice Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the Copyright (c) 2009 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents in effect on the date of Provisions Relating to IETF Documents in effect on the date of
publication of this document (http://trustee.ietf.org/license-info). publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights Please review these documents carefully, as they describe your rights
skipping to change at page 4, line 17 skipping to change at page 4, line 17
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.1. Conventions Used in This Document . . . . . . . . . . . . 7 1.1. Conventions Used in This Document . . . . . . . . . . . . 7
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 8 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 8
3. RSVP Extensions for Sender Notification . . . . . . . . . . . 9 3. RSVP Extensions for Sender Notification . . . . . . . . . . . 9
3.1. Sender Notification via PathErr Message . . . . . . . . . 12 3.1. Sender Notification via PathErr Message . . . . . . . . . 12
3.1.1. Composition of SESSION and Sender Descriptor . . . . . 15 3.1.1. Composition of SESSION and Sender Descriptor . . . . . 15
3.1.2. Composition of ERROR_SPEC . . . . . . . . . . . . . . 15 3.1.2. Composition of ERROR_SPEC . . . . . . . . . . . . . . 15
3.1.3. Use of Path_State_Removed Flag . . . . . . . . . . . . 16 3.1.3. Use of Path_State_Removed Flag . . . . . . . . . . . . 16
3.1.4. Use of PathErr by Regular Receivers . . . . . . . . . 17 3.1.4. Use of PathErr by Regular Receivers . . . . . . . . . 17
3.2. Sender Notification via Notify Message . . . . . . . . . . 18 3.2. Sender Notification via Notify Message . . . . . . . . . . 18
4. Security Considerations . . . . . . . . . . . . . . . . . . . 25 4. Security Considerations . . . . . . . . . . . . . . . . . . . 26
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 29
6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 29 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 30
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 30 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 31
7.1. Normative References . . . . . . . . . . . . . . . . . . . 30 7.1. Normative References . . . . . . . . . . . . . . . . . . . 31
7.2. Informative References . . . . . . . . . . . . . . . . . . 30 7.2. Informative References . . . . . . . . . . . . . . . . . . 31
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 31 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 32
1. Introduction 1. Introduction
Guaranteed QoS for some applications with tight Qos requirements may Guaranteed QoS for some applications with tight QoS requirements may
be achieved by reserving resources in each node on the end-to-end be achieved by reserving resources in each node on the end-to-end
path. The main IETF protocol for these resource reservations is RSVP path. The main IETF protocol for these resource reservations is RSVP
specified in [RFC2205]. RSVP does not require that all intermediate specified in [RFC2205]. RSVP does not require that all intermediate
nodes support RSVP, but it assumes that both the sender and the nodes support RSVP, but it assumes that both the sender and the
receiver of the data flow support RSVP. However, there are receiver of the data flow support RSVP. However, there are
environments where it would be useful to be able to reserve resources environments where it would be useful to be able to reserve resources
for a flow (at least a subset of the flow path) even when the sender for a flow (at least a subset of the flow path) even when the sender
or the receiver (or both) is not RSVP-capable. or the receiver (or both) is not RSVP-capable.
Since both the data sender and receiver may be unaware of RSVP, there Since both the data sender and receiver may be unaware of RSVP, there
are two types of RSVP Proxies. In the first case, an entity in the are two types of RSVP Proxies. In the first case, an entity in the
network needs to invoke RSVP on behalf of the data sender and thus network needs to invoke RSVP on behalf of the data sender and thus
generate RSVP Path messages, and eventually receive, process and sink generate RSVP Path messages, and eventually receive, process and sink
Resv messages. We refer to this entity as the RSVP Sender Proxy. In Resv messages. We refer to this entity as the RSVP Sender Proxy. In
the second case, an entity in the network need to operate RSVP on the second case, an entity in the network needs to operate RSVP on
behalf of the receiver and thus receive Path messages sent by a data behalf of the receiver and thus receive Path messages sent by a data
sender (or by an RSVP Sender Proxy), and reply to those with Resv sender (or by an RSVP Sender Proxy), and reply to those with Resv
messages generated on behalf of the data receiver(s). We refer to messages generated on behalf of the data receiver(s). We refer to
this entity as the RSVP Receiver Proxy. this entity as the RSVP Receiver Proxy.
RSVP Proxy approaches are presented in RSVP Proxy approaches are presented in
[I-D.ietf-tsvwg-rsvp-proxy-approaches]. That document also [I-D.ietf-tsvwg-rsvp-proxy-approaches]. That document also
discusses, for each approach, how the reservations controlled by the discusses, for each approach, how the reservations controlled by the
RSVP Proxy can be synchronized with the application requirements RSVP Proxy can be synchronized with the application requirements
(e.g., when to establish, maintain and tear down the RSVP reservation (e.g., when to establish, maintain and tear down the RSVP reservation
skipping to change at page 6, line 29 skipping to change at page 6, line 29
generally in a good position to synchronize the reservation with the generally in a good position to synchronize the reservation with the
application and to perform efficient sender-driven reservation: the application and to perform efficient sender-driven reservation: the
sender can control establishment (respectively removal) of the sender can control establishment (respectively removal) of the
reservation towards the receiver by sending Path (respectively reservation towards the receiver by sending Path (respectively
PathTear) messages. For example, if the sender is notified that the PathTear) messages. For example, if the sender is notified that the
reservation for a point to point audio session towards the receiver reservation for a point to point audio session towards the receiver
is rejected, the sender may trigger rejection of the session at the is rejected, the sender may trigger rejection of the session at the
application layer and may issue a PathTear message to remove any application layer and may issue a PathTear message to remove any
corresponding RSVP state (e.g. Path states) previously established. corresponding RSVP state (e.g. Path states) previously established.
However, we note that multicast applications do not always mesh well However, we note that multicast applications do not always coexist
with RSVP Receiver Proxies, since sender notification about well with RSVP Receiver Proxies, since sender notification about
reservation state towards each RSVP Receiver Proxy may not be reservation state towards each RSVP Receiver Proxy may not be
sufficient to achieve tight application level synchronization by sufficient to achieve tight application level synchronization by
multicast senders. These limitations stem from the fact that multicast senders. These limitations stem from the fact that
multicast operation is receiver-driven and, while end-to-end RSVP is multicast operation is receiver-driven and, while end-to-end RSVP is
also receiver-driven (precisely to deal with multicast efficiently), also receiver-driven (precisely to deal with multicast efficiently),
the use of RSVP Receiver Proxies only allows sender-driven the use of RSVP Receiver Proxies only allows sender-driven
reservation. For example, a sender generally is not aware of which reservation. For example, a sender generally is not aware of which
receivers have joined downstream of a given RSVP Receiver Proxy, or receivers have joined downstream of a given RSVP Receiver Proxy, or
even which RSVP Receiver Proxies have joined downstream of a given even which RSVP Receiver Proxies have joined downstream of a given
failure point. Therefore, it may not be possible to support a mode failure point. Therefore, it may not be possible to support a mode
of operation whereby a given receiver only joins a group if that of operation whereby a given receiver only joins a group if that
receiver can be protected by a reservation. Additionally, a sender receiver benefits from a reservation. Additionally, a sender may
may have no recourse if only a subset of RSVP Receiver Proxies return have no recourse if only a subset of RSVP Receiver Proxies return
successful reservations (even if application-level signalling runs successful reservations (even if application-level signalling runs
between the sender and receivers), since the sender may not be able between the sender and receivers), since the sender may not be able
to correctly identify the set of receivers who do not have to correctly identify the set of receivers who do not have
reservations. However, it is possible to support a mode of operation reservations. However, it is possible to support a mode of operation
whereby multicast traffic is transmitted if and only if all receivers whereby multicast traffic is transmitted if and only if all receivers
are protected by a reservation (from sender to their respective RSVP benefit from a reservation (from sender to their respective RSVP
Receiver Proxy): the sender can ensure this by sending a PathTear Receiver Proxy): the sender can ensure this by sending a PathTear
message and stopping transmission whenever it gets a notification for message and stopping transmission whenever it gets a notification for
reservation reject for one or more RSVP Receiver Proxy. It is also reservation reject for one or more RSVP Receiver Proxy. It is also
possible to support a mode of operation whereby receivers join possible to support a mode of operation whereby receivers join
independently of whether they can be protected by a reservation (to independently of whether they can benefit from a reservation (to
their respective RSVP Receiver Proxy) or not, but do benefit from a their respective RSVP Receiver Proxy) or not, but do benefit from a
reservation whenever the corresponding resources are reservable on reservation whenever the corresponding resources are reservable on
the relevant path. the relevant path.
This document discusses extensions to facilitate operations in the This document discusses extensions to facilitate operations in the
presence of a Path-triggered RSVP Receiver Proxy. As pointed out presence of a Path-triggered RSVP Receiver Proxy. As pointed out
previously, those apply equally whether RSVP signaling is initiated previously, those apply equally whether RSVP signaling is initiated
by a regular RSVP sender or by an RSVP Sender Proxy (with some means by a regular RSVP sender or by an RSVP Sender Proxy (with some means
to synchronize reservation state with application level requirements to synchronize reservation state with application level requirements
that are outside the scope of this document). For readability, the that are outside the scope of this document). For readability, the
skipping to change at page 10, line 25 skipping to change at page 10, line 25
===================RSVP===================> ===================RSVP===================>
************************************************************> ************************************************************>
|----| RSVP-capable |----| Non-RSVP-capable *** |----| RSVP-capable |----| Non-RSVP-capable ***
| S | Sender | R | Receiver *r* regular RSVP | S | Sender | R | Receiver *r* regular RSVP
|----| |----| *** router |----| |----| *** router
***> media flow ***> media flow
==> segment of flow path protected by RSVP reservation ==> segment of flow path benefiting from an RSVP reservation
Figure 1: Successful Reservation Figure 1: Successful Reservation
We observe that, in the case of successful reservation, conventional We observe that, in the case of successful reservation, conventional
RSVP procedures ensure that the sender is notified of the successful RSVP procedures ensure that the sender is notified of the successful
reservation establishment. Thus, no extensions are required in the reservation establishment. Thus, no extensions are required in the
presence of a Path-Triggered RSVP Receiver Proxy in the case of presence of a Path-Triggered RSVP Receiver Proxy in the case of
successful reservation establishment. successful reservation establishment.
However, in case of reservation failure, conventional RSVP procedures However, in case of reservation failure, conventional RSVP procedures
skipping to change at page 11, line 27 skipping to change at page 11, line 27
===================RSVP===================> ===================RSVP===================>
************************************************************> ************************************************************>
|----| |----| *** |----| |----| ***
| S | Sender | R | Receiver *r* regular RSVP | S | Sender | R | Receiver *r* regular RSVP
|----| |----| *** router |----| |----| *** router
***> media flow ***> media flow
==> segment of flow path protected by RSVP reservation ==> segment of flow path benefiting from an RSVP reservation
Figure 2: Reservation Failure With Conventional RSVP Figure 2: Reservation Failure With Conventional RSVP
While the sender could infer reservation failure from the fact that While the sender could infer reservation failure from the fact that
it has not received a Resv message after a certain time, there are it has not received a Resv message after a certain time, there are
clear benefits in ensuring that the sender gets a prompt, explicit clear benefits in ensuring that the sender gets a prompt, explicit
notification in case of reservation failure. This includes faster notification in case of reservation failure. This includes faster
end-user notification at application layer (e.g., busy signal), end-user notification at application layer (e.g., busy signal),
faster application level reaction (e.g., application level faster application level reaction (e.g., application level
rerouting), as well as faster release of application-level resources. rerouting), as well as faster release of application-level resources.
skipping to change at page 13, line 29 skipping to change at page 13, line 29
===================RSVP===================> ===================RSVP===================>
************************************************************> ************************************************************>
|----| |----| *** |----| |----| ***
| S | Sender | R | Receiver *r* regular RSVP | S | Sender | R | Receiver *r* regular RSVP
|----| |----| *** router |----| |----| *** router
***> media flow ***> media flow
==> segment of flow path to be protected by RSVP reservation ==> segment of flow path benefiting from RSVP
(but not protected in this case since reservation failed) (but not benefiting from a reservation in this case)
Figure 3: Reservation Failure With Sender Notification via PathErr Figure 3: Reservation Failure With Sender Notification via PathErr
The role of this PathErr is to notify the sender that the reservation The role of this PathErr is to notify the sender that the reservation
was not established or was torn down. This may be in the case of was not established or was torn down. This may be in the case of
receipt of a ResvErr, or because of local failure on the Receiver receipt of a ResvErr, or because of local failure on the Receiver
Proxy. On receipt of a ResvErr, in all situations where the Proxy. On receipt of a ResvErr, in all situations where the
reservation cannot be installed, the Receiver Proxy MUST generate a reservation cannot be installed, the Receiver Proxy MUST generate a
PathErr towards the sender. For local failures on the Receiver Proxy PathErr towards the sender. For local failures on the Receiver Proxy
node, if a similar failure on an RSVP midpoint would cause the node, if a similar failure on an RSVP midpoint would cause the
skipping to change at page 21, line 33 skipping to change at page 21, line 33
===================RSVP===================> ===================RSVP===================>
************************************************************> ************************************************************>
|----| |----| *** |----| |----| ***
| S | Sender | R | Receiver *r* regular RSVP | S | Sender | R | Receiver *r* regular RSVP
|----| |----| *** router |----| |----| *** router
***> media flow ***> media flow
==> segment of flow path to be protected by RSVP reservation ==> segment of flow path benefiting from RSVP
(but not protected in this case since reservation failed) (but not benefiting from a reservation in this case)
Path* = Path message containing a Notify Request object Path* = Path message containing a Notify Request object
with sender IP Address with sender IP Address
Resv* = Resv message containing a Notify Request object Resv* = Resv message containing a Notify Request object
with sender IP address with sender IP address
NotifyD = Notify message containing a downstream notification NotifyD = Notify message containing a downstream notification
NotifyU = Notify message containing an upstream notification
Figure 4: Reservation Failure With Sender Notification via Direct Figure 4: Reservation Failure With Sender Notification via Direct
Notify Notify
Operation of the Path-Triggered RSVP Receiver Proxy in the case of an Operation of the Path-Triggered RSVP Receiver Proxy in the case of an
admission control failure, using sender notification via Indirect admission control failure, using sender notification via Indirect
Notify, is illustrated in Figure 5. Notify, is illustrated in Figure 5.
|----| *** *** *** |----------| |----| |----| *** *** *** |----------| |----|
| S |--------*r*--------*r*--------*r*--------| RSVP |------| R | | S |--------*r*--------*r*--------*r*--------| RSVP |------| R |
|----| *** *** *** | Receiver | |----| |----| *** *** *** | Receiver | |----|
skipping to change at page 22, line 33 skipping to change at page 23, line 33
===================RSVP===================> ===================RSVP===================>
************************************************************> ************************************************************>
|----| |----| *** |----| |----| ***
| S | Sender | R | Receiver *r* regular RSVP | S | Sender | R | Receiver *r* regular RSVP
|----| |----| *** router |----| |----| *** router
***> media flow ***> media flow
==> segment of flow path to be protected by RSVP reservation ==> segment of flow path benefiting from RSVP
(but not protected in this case since reservation failed) (but not benefiting from a reservation in this case)
Path* = Path message containing a Notify Request object Path* = Path message containing a Notify Request object
with sender IP Address with sender IP Address
Resv* = Resv message containing a Notify Request object Resv* = Resv message containing a Notify Request object
with RSVP Receiver Proxy IP address with RSVP Receiver Proxy IP address
NotifyD = Notify message containing a downstream notification NotifyD = Notify message containing a downstream notification
NotifyU = Notify message containing an upstream notification NotifyU = Notify message containing an upstream notification
skipping to change at page 30, line 48 skipping to change at page 31, line 48
[I-D.ietf-tsvwg-rsvp-proxy-approaches] [I-D.ietf-tsvwg-rsvp-proxy-approaches]
Faucheur, F., Manner, J., Wing, D., and A. Guillou, "RSVP Faucheur, F., Manner, J., Wing, D., and A. Guillou, "RSVP
Proxy Approaches", Proxy Approaches",
draft-ietf-tsvwg-rsvp-proxy-approaches-06 (work in draft-ietf-tsvwg-rsvp-proxy-approaches-06 (work in
progress), October 2008. progress), October 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-02 (work in draft-ietf-tsvwg-rsvp-security-groupkeying-04 (work in
progress), November 2008. progress), March 2009.
Authors' Addresses Authors' Addresses
Francois Le Faucheur Francois Le Faucheur
Cisco Systems Cisco Systems
Greenside, 400 Avenue de Roumanille Greenside, 400 Avenue de Roumanille
Sophia Antipolis 06410 Sophia Antipolis 06410
France France
Phone: +33 4 97 23 26 19 Phone: +33 4 97 23 26 19
 End of changes. 18 change blocks. 
29 lines changed or deleted 31 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/