draft-ietf-tsvwg-rsvp-proxy-proto-07.txt   draft-ietf-tsvwg-rsvp-proxy-proto-08.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: January 2, 2009 University of Helsinki Expires: September 3, 2009 University of Helsinki
A. Narayanan A. Narayanan
Cisco Cisco
A. Guillou A. Guillou
H. Malik
Neuf Neuf
July 1, 2008 H. Malik
Bharti
March 2, 2009
RSVP Extensions for Path-Triggered RSVP Receiver Proxy RSVP Extensions for Path-Triggered RSVP Receiver Proxy
draft-ietf-tsvwg-rsvp-proxy-proto-07.txt draft-ietf-tsvwg-rsvp-proxy-proto-08.txt
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any This Internet-Draft is submitted to IETF in full conformance with the
applicable patent or other IPR claims of which he or she is aware provisions of BCP 78 and BCP 79. This document may contain material
have been or will be disclosed, and any of which he or she becomes from IETF Documents or IETF Contributions published or made publicly
aware will be disclosed, in accordance with Section 6 of BCP 79. available before November 10, 2008. The person(s) controlling the
copyright in some of this material may not have granted the IETF
Trust the right to allow modifications of such material outside the
IETF Standards Process. Without obtaining an adequate license from
the person(s) controlling the copyright in such materials, this
document may not be modified outside the IETF Standards Process, and
derivative works of it may not be created outside the IETF Standards
Process, except to format it for publication as an RFC or to
translate it into languages other than English.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on January 2, 2009. This Internet-Draft will expire on September 3, 2009.
Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents in effect on the date of
publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document.
Abstract Abstract
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 QoS required by certain in an IP network in order to guarantee the QoS required by certain
flows. With conventional RSVP, both the data sender and receiver of flows. With conventional RSVP, both the data sender and receiver of
a given flow take part in RSVP signaling. Yet, there are many use a given flow take part in RSVP signaling. Yet, there are many use
cases where resource reservation is required, but the receiver, the cases where resource reservation is required, but the receiver, the
sender, or both, is not RSVP-capable. Where the receiver is not sender, or both, is not RSVP-capable. Where the receiver is not
RSVP-capable, an RSVP router may behave as an RSVP Receiver Proxy RSVP-capable, an RSVP router may behave as an RSVP Receiver Proxy
skipping to change at page 3, line 7 skipping to change at page 4, line 7
allows resource reservations to be established on the segment of the allows resource reservations to be established on the segment of the
end-to-end path from the sender to the RSVP Receiver Proxy. However, end-to-end path from the sender to the RSVP Receiver Proxy. However,
as discussed in the companion document presenting RSVP Proxy as discussed in the companion document presenting RSVP Proxy
approaches, RSVP extensions are needed to facilitate operations with approaches, RSVP extensions are needed to facilitate operations with
an RSVP Receiver Proxy whose signaling is triggered by receipt of an RSVP Receiver Proxy whose signaling is triggered by receipt of
RSVP Path messages from the sender. This document specifies these RSVP Path messages from the sender. This document specifies these
extensions. extensions.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.1. Conventions Used in This Document . . . . . . . . . . . . 5 1.1. Conventions Used in This Document . . . . . . . . . . . . 7
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 8
3. RSVP Extensions for Sender Notification . . . . . . . . . . . 7 3. RSVP Extensions for Sender Notification . . . . . . . . . . . 9
3.1. Sender Notification via PathErr Message . . . . . . . . . 10 3.1. Sender Notification via PathErr Message . . . . . . . . . 12
3.1.1. Composition of SESSION and <Sender descriptor> . . . . 12 3.1.1. Composition of SESSION and Sender Descriptor . . . . . 15
3.1.2. Composition of ERROR_SPEC . . . . . . . . . . . . . . 13 3.1.2. Composition of ERROR_SPEC . . . . . . . . . . . . . . 15
3.1.3. Use of Path_State_Removed Flag . . . . . . . . . . . . 14 3.1.3. Use of Path_State_Removed Flag . . . . . . . . . . . . 16
3.1.4. Use of PathErr by Regular Receivers . . . . . . . . . 15 3.1.4. Use of PathErr by Regular Receivers . . . . . . . . . 17
3.2. Sender Notification via Notify Message . . . . . . . . . . 16 3.2. Sender Notification via Notify Message . . . . . . . . . . 18
4. Security Considerations . . . . . . . . . . . . . . . . . . . 20 4. Security Considerations . . . . . . . . . . . . . . . . . . . 25
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28
6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 24 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 29
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 25 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 30
7.1. Normative References . . . . . . . . . . . . . . . . . . . 25 7.1. Normative References . . . . . . . . . . . . . . . . . . . 30
7.2. Informative References . . . . . . . . . . . . . . . . . . 25 7.2. Informative References . . . . . . . . . . . . . . . . . . 30
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 26 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 31
Intellectual Property and Copyright Statements . . . . . . . . . . 28
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 operate 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 need 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 synchronised 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
to satisfy application requirements). to satisfy application requirements).
One RSVP Proxy approach is referred to as the Path-Triggered RSVP One RSVP Proxy approach is referred to as the Path-Triggered RSVP
Receiver Proxy approach. With this approach, the RSVP Receiver Proxy Receiver Proxy approach. With this approach, the RSVP Receiver Proxy
uses the RSVP Path messages generated by the sender (or RSVP Sender uses the RSVP Path messages generated by the sender (or RSVP Sender
Proxy) as the cue for establishing the RSVP reservation on behalf of Proxy) as the cue for establishing the RSVP reservation on behalf of
the non-RSVP-capable receiver. The RSVP Receiver Proxy is the non-RSVP-capable receiver(s). The RSVP Receiver Proxy is
effectively acting as an intermediary making reservations (on behalf effectively acting as an intermediary making reservations (on behalf
of the receiver) under the sender's control (or RSVP Sender Proxy's of the receiver) under the sender's control (or RSVP Sender Proxy's
control). This changes somewhat the usual RSVP reservation model control). This changes somewhat the usual RSVP reservation model
where reservations are normally controlled by receivers. Such a where reservations are normally controlled by receivers. Such a
change greatly facilitates operations in the scenario of interest change greatly facilitates operations in the scenario of interest
here, which is where the receiver is not RSVP-capable. Indeed it here, which is where the receiver is not RSVP-capable. Indeed it
allows the RSVP Receiver Proxy to remain application unaware by allows the RSVP Receiver Proxy to remain application unaware by
taking advantage of the application awareness and RSVP awareness of taking advantage of the application awareness and RSVP awareness of
the sender (or RSVP Sender Proxy). the sender (or RSVP Sender Proxy).
Since the synchronisation between RSVP reservation and application Since the synchronization between an RSVP reservation and an
requirement is now effectively performed by the sender (or RSVP application is now effectively performed by the sender (or RSVP
Sender Proxy), it is important that the sender (or RSVP Sender Proxy) Sender Proxy), it is important that the sender (or RSVP Sender Proxy)
is aware of the reservation state. However, as conventional RSVP is aware of the reservation state. However, as conventional RSVP
assumes that the reservation is to be controlled by the receiver, assumes that the reservation is to be controlled by the receiver,
some notifications about reservation state (notably the error message some notifications about reservation state (notably the error message
sent in case of admission control rejection of the reservation) are sent in case of admission control rejection of the reservation) are
only sent towards the receiver and therefore, in our case, sunk by only sent towards the receiver and therefore, in our case, sunk by
the RSVP Receiver Proxy. This document specifies extension to RSVP the RSVP Receiver Proxy. This document specifies extension to RSVP
procedures allowing such notifications to be also conveyed towards procedures allowing such notifications also to be conveyed towards
the sender. This facilitates synchronization by the sender (or RSVP the sender. This facilitates synchronization by the sender (or RSVP
Sender Proxy) between RSVP reservation and application requirements Sender Proxy) between the RSVP reservation and the application
in scenarios involving a Path-Triggered RSVP receiver Proxy. requirements and facilitates sender-driven control of reservation in
scenarios involving a Path-Triggered RSVP receiver Proxy.
This document discusses extension to facilitate operations in the With unicast applications in the presence of RSVP Receiver Proxies,
presence of a Path-triggered RSVP Receiver Proxy. As explicitly if the sender is notified about the state of the reservation towards
pointed out in the text above, those apply equally whether RSVP the receiver (as enabled by the present document), the sender is
signaling is initiated by a regular RSVP sender or by an RSVP Sender generally in a good position to synchronize the reservation with the
Proxy (with some means to synchronize reservation state with application and to perform efficient sender-driven reservation: the
application level requirements that are outside the scope of this sender can control establishment (respectively removal) of the
document). For readability, the rest of this document discusses reservation towards the receiver by sending Path (respectively
operation assuming a regular RSVP sender; however, such operation is PathTear) messages. For example, if the sender is notified that the
equally applicable where an RSVP Sender Proxy is used to initiated reservation for a point to point audio session towards the receiver
RSVP signaling on behalf of a non-RSVP-capable sender. is rejected, the sender may trigger rejection of the session at the
application layer and may issue a PathTear message to remove any
corresponding RSVP state (e.g. Path states) previously established.
However, we note that multicast applications do not always mesh well
with RSVP Receiver Proxies, since sender notification about
reservation state towards each RSVP Receiver Proxy may not be
sufficient to achieve tight application level synchronization by
multicast senders. These limitations stem from the fact that
multicast operation is receiver-driven and, while end-to-end RSVP is
also receiver-driven (precisely to deal with multicast efficiently),
the use of RSVP Receiver Proxies only allows sender-driven
reservation. For example, a sender generally is not aware of which
receivers have joined downstream of a given RSVP Receiver Proxy, or
even which RSVP Receiver Proxies have joined downstream of a given
failure point. Therefore, it may not be possible to support a mode
of operation whereby a given receiver only joins a group if that
receiver can be protected by a reservation. Additionally, a sender
may have no recourse if only a subset of RSVP Receiver Proxies return
successful reservations (even if application-level signalling runs
between the sender and receivers), since the sender may not be able
to correctly identify the set of receivers who do not have
reservations. However, it is possible to support a mode of operation
whereby multicast traffic is transmitted if and only if all receivers
are protected by a reservation (from sender to their respective RSVP
Receiver Proxy): the sender can ensure this by sending a PathTear
message and stopping transmission whenever it gets a notification for
reservation reject for one or more RSVP Receiver Proxy. It is also
possible to support a mode of operation whereby receivers join
independently of whether they can be protected by a reservation (to
their respective RSVP Receiver Proxy) or not, but do benefit from a
reservation whenever the corresponding resources are reservable on
the relevant path.
This document discusses extensions to facilitate operations in the
presence of a Path-triggered RSVP Receiver Proxy. As pointed out
previously, those apply equally whether RSVP signaling is initiated
by a regular RSVP sender or by an RSVP Sender Proxy (with some means
to synchronize reservation state with application level requirements
that are outside the scope of this document). For readability, the
rest of this document discusses operation assuming a regular RSVP
sender; however, such operation is equally applicable where an RSVP
Sender Proxy is used to initiated RSVP signaling on behalf of a non-
RSVP-capable sender.
1.1. Conventions Used in This Document 1.1. Conventions Used in This Document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
2. Terminology 2. Terminology
The following terminology is borrowed from The following terminology is borrowed from
skipping to change at page 6, line 22 skipping to change at page 8, line 22
[RFC2205] [RFC2205]
o RSVP Receiver Proxy: an RSVP-capable router performing, on behalf o RSVP Receiver Proxy: an RSVP-capable router performing, on behalf
of a receiver, the RSVP operations which would normally be of a receiver, the RSVP operations which would normally be
performed by an RSVP-capable receiver if end-to-end RSVP signaling performed by an RSVP-capable receiver if end-to-end RSVP signaling
was used. Note that while RSVP is used upstream of the RSVP was used. Note that while RSVP is used upstream of the RSVP
Receiver Proxy, RSVP is not used downstream of the RSVP Receiver Receiver Proxy, RSVP is not used downstream of the RSVP Receiver
Proxy. Proxy.
o RSVP Sender Proxy: an RSVP-capable router performing, on behalf of o RSVP Sender Proxy: an RSVP-capable router performing, on behalf of
a sender, the RSVP operations which would normally be performed by a sender, the RSVP operations that normally would be performed by
an RSVP-capable sender if end-to-end RSVP signaling was used. an RSVP-capable sender if end-to-end RSVP signaling was used.
Note that while RSVP is used downstream of the RSVP Sender Proxy, Note that while RSVP is used downstream of the RSVP Sender Proxy,
RSVP is not used upstream of the RSVP Sender Proxy. RSVP is not used upstream of the RSVP Sender Proxy.
o Regular RSVP Router: an RSVP-capable router which is not behaving o Regular RSVP Router: an RSVP-capable router which is not behaving
as a RSVP Receiver Proxy nor as a RSVP Sender Proxy. as a RSVP Receiver Proxy nor as a RSVP Sender Proxy.
Note that the roles of RSVP Receiver Proxy, RSVP Sender Proxy, Note that the roles of RSVP Receiver Proxy, RSVP Sender Proxy,
Regular RSVP Router are all relative to one unidirectional flow. A Regular RSVP Router are all relative to one unidirectional flow. A
given router may act as the RSVP Receiver Proxy for a flow, as the given router may act as the RSVP Receiver Proxy for a flow, as the
skipping to change at page 7, line 25 skipping to change at page 9, line 25
configured to use receipt of a regular RSVP Path message as the configured to use receipt of a regular RSVP Path message as the
trigger for RSVP Receiver Proxy behavior. On receipt of the RSVP trigger for RSVP Receiver Proxy behavior. On receipt of the RSVP
Path message, the RSVP Receiver Proxy: Path message, the RSVP Receiver Proxy:
1. establishes the RSVP Path state as per regular RSVP processing 1. establishes the RSVP Path state as per regular RSVP processing
2. identifies the downstream interface towards the receiver 2. identifies the downstream interface towards the receiver
3. sinks the Path message 3. sinks the Path message
4. behaves as if a Resv message (whose details are discussed below) 4. behaves as if a corresponding Resv message (on its way upstream
was received on the downstream interface. This includes from the receiver) was received on the downstream interface.
performing admission control on the downstream interface, This includes performing admission control on the downstream
establishing a Resv state (in case of successful admission interface, establishing a Resv state (in case of successful
control) and forwarding the Resv message upstream, sending admission control) and forwarding the Resv message upstream,
periodic refreshes of the Resv message and tearing down the sending periodic refreshes of the Resv message and tearing down
reservation if the Path state is torn down. the reservation if the Path state is torn down.
Operation of the Path-Triggered Receiver Proxy in the case of a Operation of the Path-Triggered Receiver Proxy in the case of a
successful reservation is illustrated in Figure 1. successful reservation is illustrated in Figure 1.
|----| *** *** *** |----------| |----| |----| *** *** *** |----------| |----|
| S |--------*r*--------*r*--------*r*--------| RSVP |------| R | | S |--------*r*--------*r*--------*r*--------| RSVP |------| R |
|----| *** *** *** | Receiver | |----| |----| *** *** *** | Receiver | |----|
| Proxy | | Proxy |
|----------| |----------|
skipping to change at page 8, line 36 skipping to change at page 10, line 36
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
only ensure that the receiver (or the RSVP Receiver Proxy) is ensure only that the receiver (or the RSVP Receiver Proxy) is
notified of the reservation failure. Specifically, in case of an notified of the reservation failure. Specifically, in case of an
admission control rejection on a regular RSVP router, a ResvErr admission control rejection on a regular RSVP router, a ResvErr
message is sent downstream towards the receiver. In the presence of message is sent downstream towards the receiver. In the presence of
an RSVP Receiver Proxy, if we simply follow conventional RSVP an RSVP Receiver Proxy, if we simply follow conventional RSVP
procedures, this means that the RSVP Receiver Proxy is notified of procedures, this means that the RSVP Receiver Proxy is notified of
the reservation failure, but the sender is not. Operation of the the reservation failure, but the sender is not. Operation of the
Path-Triggered RSVP Receiver Proxy in the case of an admission Path-Triggered RSVP Receiver Proxy in the case of an admission
control failure, assuming conventional RSVP procedures, is control failure, assuming conventional RSVP procedures, is
illustrated in Figure 2. illustrated in Figure 2.
skipping to change at page 9, line 33 skipping to change at page 11, line 33
|----| |----| *** router |----| |----| *** router
***> media flow ***> media flow
==> segment of flow path protected by RSVP reservation ==> segment of flow path protected by 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), faster end-user notification at application layer (e.g., busy signal),
application level reaction (e.g. application level rerouting), as faster application level reaction (e.g., application level
well as faster release of application-level resources. rerouting), as well as faster release of application-level resources.
Section 3.1 defines a method which can be used to achieve sender Section 3.1 defines a method that can be used to achieve sender
notification of reservation failure. A router implementation notification of reservation failure. A router implementation
claiming compliance with this document MUST support the method claiming compliance with this document MUST support the method
defined in Section 3.1. defined in Section 3.1.
Section 3.2 defines another method which can be used to achieve Section 3.2 defines another method that can be used to achieve sender
sender notification of reservation failure. A router implementation notification of reservation failure. A router implementation
claiming compliance with this document MAY support the method defined claiming compliance with this document MAY support the method defined
in Section 3.2. in Section 3.2.
In a given network environment, a network administrator may elect to In a given network environment, a network administrator may elect to
use the method defined in Section 3.1, or the method defined in use the method defined in Section 3.1, or the method defined in
Section 3.2, or possibly combine the two. Section 3.2, or possibly combine the two.
3.1. Sender Notification via PathErr Message 3.1. Sender Notification via PathErr Message
With this method, the RSVP Receiver Proxy MUST generate a PathErr With this method, the RSVP Receiver Proxy MUST generate a PathErr
message whenever the two following conditions are met: message whenever the two following conditions are met:
1. The reservation establishment has failed (or the previously 1. The reservation establishment has failed (or the previously
established reservation has been torn down) established reservation has been torn down)
2. The RSVP Receiver Proxy determines that it cannot re-establish 2. The RSVP Receiver Proxy determines that it cannot re-establish
the reservation (e.g. by adapting its reservation request in the reservation (e.g., by adapting its reservation request in
reaction to the error code provided in the received ResvErr in reaction to the error code provided in the received ResvErr in
accordance with local policy) accordance with local policy)
Note that this notion of generating a PathErr message upstream in Note that this notion of generating a PathErr message upstream in
order to notify the sender about a reservation failure is not order to notify the sender about a reservation failure is not
completely new. It is borrowed from [RFC3209] where it has been completely new. It is borrowed from [RFC3209] where it has been
introduced in order to achieve a similar requirement, which is to introduced in order to achieve a similar requirement, which is to
allow an MPLS TE Label Switch Router to notify the TE Tunnel Head-end allow an MPLS TE Label Switch Router to notify the TE Tunnel Head-end
(i.e. the sender) of a failure to establish (or maintain) a TE Tunnel (i.e., the sender) of a failure to establish (or maintain) a TE
Label Switch Path. Tunnel Label Switch Path.
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 PathErr admission control failure, using sender notification via PathErr
Message, is illustrated in Figure 3. Message, is illustrated in Figure 3.
|----| *** *** *** |----------| |----| |----| *** *** *** |----------| |----|
| S |--------*r*--------*r*--------*r*--------| RSVP |------| R | | S |--------*r*--------*r*--------*r*--------| RSVP |------| R |
|----| *** *** *** | Receiver | |----| |----| *** *** *** | Receiver | |----|
| Proxy | | Proxy |
|----------| |----------|
skipping to change at page 11, line 41 skipping to change at page 13, line 41
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
generation of a ResvErr (for example, CAC failure), the Receiver generation of a ResvErr (for example, admission control failure), the
Proxy MUST generate a PathErr towards the sender. The Receiver Proxy Receiver Proxy MUST generate a PathErr towards the sender. The
MAY additionally generate a PathErr upon local failures which would Receiver Proxy MAY additionally generate a PathErr upon local
not ordinarily cause generation of a ResvErr message, such as failures which would not ordinarily cause generation of a ResvErr
described in Appendix B of [RFC2205]. message, such as described in Appendix B of [RFC2205].
The PathErr generated by the Receiver Proxy corresponds to the The PathErr generated by the Receiver Proxy corresponds to the
sender(s) which triggered generation of Resv messages that failed. sender(s) that triggered generation of Resv messages that failed.
For Fixed-Filter (FF) style reservations, the Receiver Proxy sends a For Fixed-Filter (FF) style reservations, the Receiver Proxy MUST
PathErr towards the (single) sender matching the failed reservation. send a PathErr towards the (single) sender matching the failed
reservation. For Shared-Explicit (SE) style reservations, the
Receiver Proxy MUST send the PathErr(s) towards the set of senders
that triggered reservations that failed. This may be a subset of
senders sharing the same reservation, in which case the remaining
senders would have their reservation intact and would not receive a
PathErr. In both cases, the rules described in Section 3.1.8 of
[RFC2205] for generating flow descriptors in ResvErr messages, also
apply when generating sender descriptors in PathErr messages.
For Shared-Explicit (SE) style reservations, the Receiver Proxy sends For Wildcard-Filter (WF) style reservations, it is not always
the PathErr(s) towards the set of senders which triggered possible for the Receiver Proxy to reliably know which sender caused
reservations that failed. This may be a subset of senders sharing the reservation failure. Therefore, the Receiver Proxy SHOULD send a
the same reservation, in which case the remaining senders would have PathErr towards each sender. This means that all the senders will
their reservation intact and would not receive a PathErr. In both receive a notification that the reservation is not established,
cases, the rules described in Section 3.1.8 of [RFC2205] for including senders that did not cause the reservation failure.
generating flow descriptors in ResvErr messages, also apply for Therefore, the method of sender notification via PathErr message is
generating sender descriptors in PathErr messages. somewhat over-conservative (i.e., in some cases rejecting
reservations from some senders when those could have actually been
established) when used in combination with Wildcard-Filter style (and
when there is more than one sender).
For Wildcard-Filter (WF) style reservations, it is not possible for The sender notification via PathErr method applies to both unicast
the receiver to know which sender caused the reservation failure. and multicast sessions. However, for a multicast session, it is
Therefore, the procedures described in this section do not apply to possible that reservation failure (e.g., admission control failure)
WF-style reservations. in a node close to a sender may cause ResvErr messages to be sent to
a large group of Receiver Proxies. These Receiver Proxies would, in
turn, all send PathErr messages back to the same sender, which could
cause a scalability issue in some environments.
The procedures described in this section apply to both unicast and From the perspective of the sender, errors that prevent a reservation
multicast sessions. However, for a multicast session, it is possible from being set up can be classified in two ways:
that reservation failure (e.g. admission control failure) in a node
close to a sender may cause ResvErr messages to be sent to a large
group of receivers. These receivers would, in turn, all send PathErr
messages back to the same sender, which could cause a scalability
issue in some environments. From the perspective of the sender,
errors that prevent a reservation from being set up can be classified
in two ways:
1. Errors which the sender can attempt to correct. The error code 1. Errors that the sender can attempt to correct. The error code
for those errors should explicitly be communicated back to the for those errors should explicitly be communicated back to the
sender. An examples of this is "Class 1: Admission Control sender. An examples of this is "Class 1: Admission Control
Failure", because the sender could potentially resend a Path with Failure", because the sender could potentially resend a Path with
smaller traffic parameters. smaller traffic parameters.
2. Errors which the sender has no control over. For these errors, 2. Errors over which the sender has no control. For these errors,
it is sufficient to notify the sender that the reservation was it is sufficient to notify the sender that the reservation was
not set up successfully. An example of this is "Class 13: not set up successfully. An example of this is "Class 13:
Unknown Object", because the sender has no control over the Unknown Object", because the sender has no control over the
objects inserted into the reservation by the Receiver Proxy. objects inserted into the reservation by the Receiver Proxy.
The PathErr message generated by the Receiver Proxy has the same The PathErr message generated by the Receiver Proxy has the same
format as regular PathErr messages defined in [RFC2205]. The format as regular PathErr messages defined in [RFC2205]. The
SESSION, ERROR_SPEC and sender descriptor are composed by the SESSION, ERROR_SPEC and sender descriptor are composed by the
Receiver Proxy as specified in the following subsections. The Receiver Proxy as specified in the following subsections. The
Receiver Proxy MAY reflect back towards the sender in the PathErr any Receiver Proxy MAY reflect back towards the sender in the PathErr any
POLICY_DATA objects received in the ResvErr. POLICY_DATA objects received in the ResvErr.
3.1.1. Composition of SESSION and <Sender descriptor> 3.1.1. Composition of SESSION and Sender Descriptor
The Receiver Proxy MUST insert the SESSION object corresponding to The Receiver Proxy MUST insert the SESSION object corresponding to
the failed reservation, into the PathErr. For Fixed-Filter (FF) the failed reservation, into the PathErr. For Fixed-Filter (FF)
style reservations, the Receiver Proxy MUST insert a <sender style reservations, the Receiver Proxy MUST insert a sender
descriptor> corresponding to the failed reservation, into the descriptor corresponding to the failed reservation, into the PathErr.
PathErr. This is equal to the <flow descriptor> in the ResvErr This is equal to the error flow descriptor in the ResvErr received by
received by the Receiver Proxy. For Shared-Explicit (SE) style the Receiver Proxy. For Shared-Explicit (SE) style reservations, the
reservations, the Receiver Proxy MUST insert a <sender descriptor> Receiver Proxy MUST insert a sender descriptor corresponding to the
corresponding to the sender triggering the failed reservation, into sender triggering the failed reservation, into the PathErr. This is
the PathErr. This is equal to the <flow descriptor> in the ResvErr equal to the error flow descriptor in the ResvErr received by the
received by the Receiver Proxy. If multiple <flow descriptors> could Receiver Proxy. If multiple flow descriptors could not be admitted
not be admitted at a midpoint node, that node would generate multiple at a midpoint node, that node would generate multiple ResvErr
ResvErr messages towards the receiver as per Section 3.1.8 of messages towards the receiver as per Section 3.1.8 of [RFC2205].
[RFC2205]. Each ResvErr would contain a <flow descriptor> that Each ResvErr would contain an error flow descriptor that matches a
matches a specific sender. The Receiver Proxy MUST generate a specific sender. The Receiver Proxy MUST generate a PathErr for each
PathErr for each ResvErr received, towards the corresponding sender. ResvErr received, towards the corresponding sender. As specified
earlier, for Wildcard-Filter style reservations, the Receiver Proxy
SHOULD send a PathErr to each sender.
3.1.2. Composition of ERROR_SPEC 3.1.2. Composition of ERROR_SPEC
The Receiver Proxy MUST compose the ERROR_SPEC to be inserted into The Receiver Proxy MUST compose the ERROR_SPEC to be inserted into
the PathErr as follows: the PathErr as follows:
1. If the Receiver Proxy receives a ResvErr with any of these error 1. If the Receiver Proxy receives a ResvErr with any of these error
codes: "Code 1 - Admission Control Failure" or "Code 2 - Policy codes: "Code 1 - Admission Control Failure" or "Code 2 - Policy
Control Failure" then the Receiver Proxy copies the error code Control Failure" then the Receiver Proxy copies the error code
and value from the ERROR_SPEC in the ResvErr, into the ERROR_SPEC and value from the ERROR_SPEC in the ResvErr, into the ERROR_SPEC
skipping to change at page 14, line 35 skipping to change at page 16, line 44
3. If the Receiver Proxy Receives a ResvErr with the InPlace flag 3. If the Receiver Proxy Receives a ResvErr with the InPlace flag
set in the ERROR_SPEC, it MUST also set the InPlace flag in the set in the ERROR_SPEC, it MUST also set the InPlace flag in the
ERROR_SPEC of the PathErr. ERROR_SPEC of the PathErr.
3.1.3. Use of Path_State_Removed Flag 3.1.3. Use of Path_State_Removed Flag
[RFC3473] defines an optional behavior whereby a node forwarding a [RFC3473] defines an optional behavior whereby a node forwarding a
PathErr message can remove the Path State associated with the PathErr PathErr message can remove the Path State associated with the PathErr
message and indicate so by including the Path_State_Removed flag in message and indicate so by including the Path_State_Removed flag in
the ERROR_SPEC object of the PathErr message. This can be used in the ERROR_SPEC object of the PathErr message. This can be used in
some situations to expedite release of resources and minimise some situations to expedite release of resources and minimize
signaling load. signaling load.
This section discusses aspects of the use of the Path_State_Removed This section discusses aspects of the use of the Path_State_Removed
flag that are specific to the RSVP Receiver Proxy. In any other flag that are specific to the RSVP Receiver Proxy. In any other
aspects, the Path_State_Removed flag operates as per [RFC3473]. aspects, the Path_State_Removed flag operates as per [RFC3473].
By default, the RSVP Receiver Proxy MUST NOT include the By default, the RSVP Receiver Proxy MUST NOT include the
Path_State_Removed flag in the ERROR_SPEC of the PathErr message. Path_State_Removed flag in the ERROR_SPEC of the PathErr message.
This ensures predictable operations in all environments including This ensures predictable operations in all environments including
those where some RSVP routers do not understand the those where some RSVP routers do not understand the
Path_State_Removed flag. Path_State_Removed flag.
The RSVP Receiver Proxy MAY support an OPTIONAL mode to be activated The RSVP Receiver Proxy MAY support an OPTIONAL mode (to be activated
by configuration whereby the RSVP Receiver Proxy includes the by configuration) whereby the RSVP Receiver Proxy includes the
Path_State_Removed flag in the ERROR_SPEC of the PathErr message and Path_State_Removed flag in the ERROR_SPEC of the PathErr message and
removes its local Path state. Where all routers on the path of a removes its local Path state. When all routers on the path of a
reservation support the Path_State_Removed flag, its use will indeed reservation support the Path_State_Removed flag, its use will indeed
result in expedited resource release and reduced signaling. However, result in expedited resource release and reduced signaling. However,
if there is one (or more) RSVP router on the path of the reservation if there are one or more RSVP router on the path of the reservation
that does not support the Path_State_Removed flag (we refer to such a that do not support the Path_State_Removed flag (we refer to such
router as an "old RSVP router"), the use of the Path_State_Removed routers as "old RSVP routers"), the use of the Path_State_Removed
flag will actually result in slower resource release and increased flag will actually result in slower resource release and increased
signaling. This is because the Path_State_Removed flag will be signaling. This is because the Path_State_Removed flag will be
propagated upstream by an old RSVP router (even if it does not propagated upstream by an old RSVP router (even if it does not
understand it and does not tear its Path state). Thus, the sender understand it and does not tear its Path state). Thus, the sender
will not send a Path Tear and the old RSVP router will only release will not send a Path Tear and the old RSVP router will release its
its Path state through refresh time-out. A network administrator Path state only through refresh time-out. A network administrator
needs to keep these considerations in mind when deciding whether to needs to keep these considerations in mind when deciding whether to
activate the use of the Path_State_Removed flag on the RSVP Receiver activate the use of the Path_State_Removed flag on the RSVP Receiver
Proxy. In a controlled environment where all routers are known to Proxy. In a controlled environment where all routers are known to
support the Path_State_Removed flag, its use can be safely activated support the Path_State_Removed flag, its use can be safely activated
on the RSVP Receiver Proxy. In other environments, the network on the RSVP Receiver Proxy. In other environments, the network
administrator needs to assess whether the improvement achieved with administrator needs to assess whether the improvement achieved with
some reservations outweighs the degradation experienced by other some reservations outweighs the degradation experienced by other
reservations. reservations.
3.1.4. Use of PathErr by Regular Receivers 3.1.4. Use of PathErr by Regular Receivers
Note that while this document specifies that an RSVP Receiver Proxy Note that while this document specifies that an RSVP Receiver Proxy
generates a PathErr upstream in case of reservation failure, this generates a PathErr upstream in case of reservation failure, this
document does NOT propose that the same be done by regular receivers. document does NOT propose that the same be done by regular receivers.
In other words, this document does NOT propose to modify the behavior In other words, this document does NOT propose to modify the behavior
of regular receivers as currently specified in [RFC2205]. The of regular receivers as currently specified in [RFC2205]. The
rationale for this includes the following: rationale for this includes the following:
o when the receiver is RSVP capable, the current receiver-driven o When the receiver is RSVP capable, the current receiver-driven
model of [RFC2205] is fully applicable because the receiver can model of [RFC2205] is fully applicable because the receiver can
synchronise RSVP reservation state and application state (since it synchronise RSVP reservation state and application state (since it
participates in both). The sender(s) needs not be aware of the participates in both). The sender(s) needs not be aware of the
RSVP reservation state. Thus, we can retain the benefits of RSVP reservation state. Thus, we can retain the benefits of
receiver-driven operations which were explicitly sought by receiver-driven operations which were explicitly sought by
[RFC2205]. Quoting from it: " In order to efficiently accommodate [RFC2205]. Quoting from it: " In order to efficiently accommodate
large groups, dynamic group membership, and heterogeneous receiver large groups, dynamic group membership, and heterogeneous receiver
requirements, RSVP makes receivers responsible for requesting a requirements, RSVP makes receivers responsible for requesting a
specific QoS". But even for the most simple single_sender/ specific QoS". But even for the simplest single_sender/
single_receiver reservations, the current receiver-driven model single_receiver reservations, the current receiver-driven model
reduces signaling load and per-hop RSVP processing by not sending reduces signaling load and per-hop RSVP processing by not sending
any error message to the sender in case of CAC reject. any error message to the sender in case of admission control
reject.
o the motivation for adding sender error notification in case of o The motivation for adding sender error notification in case of
receiver proxy lies in the fact that the actual receiver can no receiver proxy lies in the fact that the actual receiver can no
longer synchronize RSVP reservation with application state (since longer synchronize the RSVP reservation with application state
the receiver does not participate in RSVP signaling), while the (since the receiver does not participate in RSVP signaling), while
sender can. This motivation does not apply in case of regular the sender can. This motivation does not apply in case of regular
receiver. receiver.
o there is a lot of existing code and deployed systems successfully o There is a lot of existing code and deployed systems successfully
working under the current [RFC2205] model in the absence of proxy working under the current [RFC2205] model in the absence of proxy
today. The current behavior should not be changed for those today. The current behavior should not be changed for those
unless there were a very strong motivation. unless there were a very strong motivation.
3.2. Sender Notification via Notify Message 3.2. Sender Notification via Notify Message
The OPTIONAL method for sender notification of reservation failure The OPTIONAL method for sender notification of reservation failure
defined in this section aims at providing a more efficient method defined in this section aims to provide a more efficient method than
than the one defined in Section 3.1. Its objectives include : the one defined in Section 3.1. Its objectives include:
o allow the failure notification to be sent directly upstream to the o allow the failure notification to be sent directly upstream to the
sender by the router where the failure occurs (as opposed to first sender by the router where the failure occurs (as opposed to first
travelling downstream towards the Receiver Proxy and then travelling downstream towards the Receiver Proxy and then
travelling upstream from the Receiver Proxy to the sender, as travelling upstream from the Receiver Proxy to the sender, as
effectively happens with the method defined in Section 3.1) effectively happens with the method defined in Section 3.1)
o allow the failure notification to travel directly to the sender o allow the failure notification to travel without hop-by-hop RSVP
without hop-by-hop RSVP processing processing
o ensure that such a notification is sent to senders which are o ensure that such a notification is sent to senders that are
capable and willing to process it (i.e. to synchronize reservation capable and willing to process it (i.e., to synchronize
status with application) reservation status with application)
o ensure that such a notification is only sent in case the receiver o ensure that such a notification is only sent in case the receiver
is not itself capable and willing to do the synchronisation with is not itself capable and willing to do the synchronization with
the application (i.e. because we are in the presence of a receiver the application (i.e., because we are in the presence of a
proxy so that RSVP signaling is not visible to the receiver). Receiver Proxy so that RSVP signaling is not visible to the
receiver).
Note, however, that such benefits come at the cost of : Note, however, that such benefits come at the cost of :
o a requirement for RSVP routers and senders to support the Notify o a requirement for RSVP routers and senders to support the Notify
messages and procedures defined in [RFC3473] messages and procedures defined in [RFC3473]
o a requirement for senders to process Notify messages traveling o a requirement for senders to process Notify messages traveling
upstream but conveying a downstream notification. upstream but conveying a downstream notification.
[RFC3473] defines (in section "4.3 Notify Messages") the Notify [RFC3473] defines (in section "4.3 Notify Messages") the Notify
skipping to change at page 17, line 9 skipping to change at page 19, line 21
generalized notification mechanism. Notify messages are normally generalized notification mechanism. Notify messages are normally
generated only after a Notify Request object has been received. generated only after a Notify Request object has been received.
This section discusses aspects of the use of the Notify message that This section discusses aspects of the use of the Notify message that
are specific to the RSVP Receiver Proxy. In any other aspects, the are specific to the RSVP Receiver Proxy. In any other aspects, the
Notify message operates as per [RFC3473]. Notify message operates as per [RFC3473].
In order to achieve sender notification of reservation failure in the In order to achieve sender notification of reservation failure in the
context of the present document: context of the present document:
o an RSVP sender interested in being notified of reservation failure o An RSVP sender interested in being notified of reservation failure
MUST include a Notify Request object (containing the sender's IP MUST include a Notify Request object (containing the sender's IP
address) in the Path messages it generates address) in the Path messages it generates.
o Upon receiving a Path message with a Notify Request object, the o Upon receiving a Path message with a Notify Request object, the
RSVP Receiver Proxy MUST include a Notify Request object in the RSVP Receiver Proxy MUST include a Notify Request object in the
Resv messages it generates. This Notify Request object MUST Resv messages it generates. This Notify Request object MUST
contain the address that was included in the Notify Request of the contain:
received Path message- a.k.a. the sender's address- and not an
address of the Receiver Proxy.
As a result, as per existing Notify procedures, if an RSVP router * either the address that was included in the Notify Request of
detects an error relating to a Resv state (e.g. Admission Control the received Path message- a.k.a. the sender's address-. We
rejection after IP reroute), the RSVP router will send a Notify refer to this approach as the "Direct Notify".
message (conveying the Resv Err code) to the IP address contained in
the Resv Notify Request object. Since this address has been set to * or an address of the Receiver Proxy. We refer to this approach
the sender's address by the Receiver Proxy, the Notify message is as the "Indirect Notify".
sent to the sender.
o Upon receiving a downstream error notification (whether in the
form of a Notify or a ResvErr or both), the RSVP Receiver Proxy:
* MUST generate a Notify message with upstream notification to
the corresponding sender, if the sender included a Notify
Request object in its Path messages and if Indirect
Notification is used.
* SHOULD generate a Notify message with upstream notification to
the corresponding sender, if the sender included a Notify
Request object in its Path messages and if Direct Notification
is used. The reason for this recommendation is that the
failure node may not support Notify, so that even if Direct
Notification was requested by the RSVP Receiver Proxy, the
sender may not actually have received a Notify from the failure
node: generating a Notify from the Receiver Proxy will
accelerate sender notification, as compared to simply relying
on PathErr, in this situation. In controlled environments
where all the nodes are known to support Notify, the Receiver
Proxy MAY be configured to not generate the Notify with
upstream notification when Direct Notification is used, in
order to avoid duplication of Notify messages (i.e. the sender
receiving both a Notify from the failure node and from the
Receiver Proxy)
As a result of these sender and Receiver Proxy behaviors, as per
existing Notify procedures, if an RSVP router detects an error
relating to a Resv state (e.g., admission control rejection after IP
reroute), the RSVP router will send a Notify message (conveying the
downstream notification with the ResvErr error code) to the IP
address contained in the Resv Notify Request object. If this address
has been set by the RSVP Receiver Proxy to the sender's address
(Direct Notify), the Notify message is sent directly to the sender.
If this address has been set by the RSVP Receiver Proxy to one of its
address (Indirect Notify), the Notify message is sent to the RSVP
Receiver Proxy that, in turn, will generate a Notify message directly
addressed to the sender.
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 Notify admission control failure, using sender notification via Direct
Message, is illustrated in Figure 4. Notify, is illustrated in Figure 4.
|----| *** *** *** |----------| |----| |----| *** *** *** |----------| |----|
| S |--------*r*--------*r*--------*r*--------| RSVP |------| R | | S |--------*r*--------*r*--------*r*--------| RSVP |------| R |
|----| *** *** *** | Receiver | |----| |----| *** *** *** | Receiver | |----|
| Proxy | | Proxy |
|----------| |----------|
--Path*--> --Path*--> --Path*--> --Path*--> --Path*--> --Path*--> --Path*--> --Path*-->
<--Resv*-- <--Resv*-- <--Resv*-- <--Resv*--
<------Notify------- <------NotifyD--------
-ResvErr-> -ResvErr-> -ResvErr-> -ResvErr->
<------------------NotifyU------------------
<-PathErr- <-PathErr- <-PathErr- <-PathErr-
===================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 to be protected by RSVP reservation
(but not protected in this case since reservation failed) (but not protected in this case since reservation failed)
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
Notify = Notify message NotifyD = Notify message containing a downstream notification
Figure 4: Reservation Failure With Sender Notification via Notify Figure 4: Reservation Failure With Sender Notification via Direct
Notify
Operation of the Path-Triggered RSVP Receiver Proxy in the case of an
admission control failure, using sender notification via Indirect
Notify, is illustrated in Figure 5.
|----| *** *** *** |----------| |----|
| S |--------*r*--------*r*--------*r*--------| RSVP |------| R |
|----| *** *** *** | Receiver | |----|
| Proxy |
|----------|
--Path*--> --Path*--> --Path*--> --Path*-->
<--Resv*-- <--Resv*--
-------NotifyD------->
<------------------NotifyU------------------
-ResvErr-> -ResvErr->
<-PathErr- <-PathErr- <-PathErr- <-PathErr-
===================RSVP===================>
************************************************************>
|----| |----| ***
| S | Sender | R | Receiver *r* regular RSVP
|----| |----| *** router
***> media flow
==> segment of flow path to be protected by RSVP reservation
(but not protected in this case since reservation failed)
Path* = Path message containing a Notify Request object
with sender IP Address
Resv* = Resv message containing a Notify Request object
with RSVP Receiver Proxy IP address
NotifyD = Notify message containing a downstream notification
NotifyU = Notify message containing an upstream notification
Figure 5: Reservation Failure With Sender Notification via Indirect
Notify
For local failures on the Receiver Proxy node, if a similar failure For local failures on the Receiver Proxy node, if a similar failure
on an RSVP midpoint would cause the generation of a ResvErr (for on an RSVP midpoint would cause the generation of a ResvErr (for
example, CAC failure), the Receiver Proxy MUST generate a Notify example, admission control failure), the Receiver Proxy MUST generate
towards the sender. The Receiver Proxy MAY additionally generate a a Notify towards the sender. The Receiver Proxy MAY additionally
Notify upon local failures which would not ordinarily cause generate a Notify upon local failures that would not ordinarily cause
generation of a ResvErr message, such as described in Appendix B of generation of a ResvErr message, such as described in Appendix B of
[RFC2205]. [RFC2205].
When the method of sender notification via Notify message is used, it When the method of sender notification via Notify message is used, it
is RECOMMENDED that the RSVP Receiver Proxy also issues sender is RECOMMENDED that the RSVP Receiver Proxy also issue a sender
notification via a PathErr message. This maximizes the chances that notification via a PathErr message. This maximizes the chances that
the notification reaches the sender in all situations (e.g. even if the notification will reach the sender in all situations (e.g., even
some RSVP routers do not support the Notify procedure, or if a Notify if some RSVP routers do not support the Notify procedure, or if a
message gets dropped). However, for controlled environments (e.g. Notify message gets dropped). However, for controlled environments
where all RSVP routers are known to support Notify procedures) and (e.g., where all RSVP routers are known to support Notify procedures)
where it is desirable to minimize the volume of signaling, the RSVP and where it is desirable to minimize the volume of signaling, the
Receiver Proxy MAY rely exclusively on sender notification via Notify RSVP Receiver Proxy MAY rely exclusively on sender notification via
message and thus not issue sender notification via PathErr message. Notify message and thus not issue sender notification via PathErr
message.
In environments where there are both RSVP-capable receivers and RSVP In environments where there are both RSVP-capable receivers and RSVP
Receiver Proxies acting on behalf of non RSVP-capable receivers, a Receiver Proxies acting on behalf of non RSVP-capable receivers, a
sender does not know whether a given reservation is established with sender does not know whether a given reservation is established with
an RSVP-capable receiver or with an RSVP Receiver Proxy. Thus, a an RSVP-capable receiver or with an RSVP Receiver Proxy. Thus, a
sender that supports the procedures defined in this section may very sender that supports the procedures defined in this section may
well include a Notify Request object in Path messages for a include a Notify Request object in Path messages for a reservation
reservation that happens to be controlled by an RSVP-capable that happens to be controlled by an RSVP-capable receiver. This
receiver. This document does not define, nor expect, any change in document does not define, nor expect, any change in existing receiver
existing receiver behavior. As a result, in this case, the sender behavior. As a result, in this case, the sender will not receive
will actually not receive Notify messages conveying downstream Notify messages conveying downstream notifications. However, this is
notifications. However, this is perfectly fine because the perfectly fine because the synchronization between the RSVP
synchronisation between the RSVP reservation state and the reservation state and the application requirement can be performed by
application requirement can be performed by the actual receiver in the actual receiver in this case as per the regular end-to-end RSVP
this case as per the regular end-to-end RSVP model, so that in this model, so that in this case, the sender need not care about
case, the sender need not care about downstream notifications. downstream notifications.
A sender that does not support the procedures defined in this section A sender that does not support the procedures defined in this section
could happen to include a Notify Request object in Path messages for might include a Notify Request object in Path messages for a
a reservation simply because it is interested in getting upstream reservation simply because it is interested in getting upstream
notifications faster. If the reservation happens to be controlled by notifications faster. If the reservation is controlled by an RSVP
an RSVP Receiver Proxy supporting the procedures defined in this Receiver Proxy supporting the procedures defined in this section, the
section, the sender will then also receive unexpected Notify messages sender will also receive unexpected Notify messages containing
containing downstream notifications. It is expected that such a downstream notifications. It is expected that such a sender will
sender will simply naturally drop such downstream notifications as simply naturally drop such downstream notifications as invalid.
invalid. Because it is RECOMMENDED above that the RSVP Receiver Because it is RECOMMENDED above that the RSVP Receiver Proxy also
Proxy also issues sender notification via a PathErr message even when issues sender notification via a PathErr message even when sender
sender notification via Notify message is used, the sender will still notification is effected via a Notify message, the sender will still
be notified of reservation failure in accordance with the "sender be notified of a reservation failure in accordance with the "sender
notification via PathErr" method. In summary, activating the notification via PathErr" method. In summary, activating the
OPTIONAL "sender notification via Notify" method on a Receiver Proxy, OPTIONAL "sender notification via Notify" method on a Receiver Proxy,
does not prevent a sender that does not support this method, to rely does not prevent a sender that does not support this method, to rely
on the MANDATORY "sender notification via PathErr" method. It would, on the MANDATORY "sender notification via PathErr" method. It would,
however, allow a sender supporting the "sender notification via however, allow a sender supporting the "sender notification via
Notify" method to take advantage of this OPTIONAL method. Notify" method to take advantage of this OPTIONAL method.
With Direct Notification, the downstream notification generated by
the RSVP router where the failure occurs is sent to the IP address
contained in the Notification Request Object of the corresponding
Resv message. In the presence of multiple senders towards the same
session, it cannot be generally assumed that a separate Resv message
is used for each sender (in fact with WF and SE there is a single
Resv message for all senders, and with FF the downstream router has
the choice of generating separate Resv messages or a single one).
Hence, in the presence of multiple senders, Direct Notification
cannot guarantee notification of all affected senders. Therefore,
Direct Notification is better suited to single sender applications.
With Indirect Notification, the RSVP Receiver Proxy can generate
Notify messages with the same logic that is used to generate PathErr
messages in the "Sender Notification via PathErr" method (in fact
those are conveying the same error information, only the Notify is
directly addressed to the sender while the PathErr travels hop-by-
hop). Therefore, operations of Indirect Notify method in the
presence of multiple senders is similar to that of the PathErr method
as discussed in Section 3.1: with FF (respectively, SE) a Notify MUST
be sent to the sender (respectively, the set of affected senders).
With WF, the RSVP Receiver Proxy SHOULD send a Notify to each sender,
again resulting in a somewhat over-conservative behavior in the
presence of multiple senders.
4. Security Considerations 4. Security Considerations
To ensure the integrity of the associated reservation and admission To ensure the integrity and authenticity of the associated
control mechanisms, the RSVP Authentication mechanisms defined in reservation and admission control mechanisms, the RSVP Authentication
[RFC2747] and [RFC3097] may be used. Those protect RSVP message mechanisms defined in [RFC2747] and [RFC3097] can be used. Those
integrity hop-by-hop and provide node authentication as well as protect RSVP message integrity hop-by-hop and provide node
replay protection, thereby protecting against corruption and spoofing authentication as well as replay protection, thereby protecting
of RSVP messages. These hop-by-hop integrity mechanisms can be used against corruption and spoofing of RSVP messages. These hop-by-hop
to protect the RSVP reservations established using an RSVP receiver integrity mechanisms can be used to protect RSVP reservations
proxy in accordance with the present document. established using an RSVP receiver proxy in accordance with the
present document.
[RFC2747] discusses several approaches for key distribution. First, [RFC2747] discusses several approaches to key distribution. First,
the RSVP Authentication shared keys can be distributed manually. the RSVP Authentication shared keys can be distributed manually.
This is the base option and its support is mandated for any This is the base option and its support is mandated for every
implementation. However, in some environments, this approach may implementation. However, in some environments, this approach may
become a burden if keys frequently change over time. Alternatively, become a burden if keys change frequently over time. Alternatively,
a standard key management protocol for secure key distribution can be a standard key management protocol for secure key distribution can be
used. However, existing key distribution protocols may not be used.
appropriate in all environments because of the complexity or
operational burden they involve.
The use of RSVP Authentication in parts of the network where there The use of RSVP Authentication in parts of the network where there
may be one or more IP hops in between two RSVP neighbors raises an may be one or more IP hops in between two RSVP neighbors raises an
additional challenge. This is because, with some RSVP messages such additional challenge. This is because, with some RSVP messages such
as a Path message, an RSVP router does not know the RSVP next hop for as a Path message, an RSVP router does not know the RSVP next hop for
that message at the time of forwarding it. In fact, part of the role that message at the time of forwarding it. In fact, part of the role
of a Path message is precisely to discover the RSVP next hop (and to of a Path message is precisely to discover the RSVP next hop (and to
dynamically re-discover it when it changes, say because of a routing dynamically re-discover it when it changes, say because of a routing
change). Hence, the RSVP router may not know which security change). Hence, the RSVP router may not know which security
association to use when forwarding such a message. In that association to use when forwarding such a message (see [RFC2747] for
situation, one approach is to share the same RSVP Authentication definition of RSVP security association). In that situation, one
shared key across all the RSVP routers of a part of the network where approach is to share the same RSVP Authentication key across all the
there may be RSVP neighbors with IP hops in between. For example, RSVP routers in a part of the network where there may be RSVP
all the RSVP routers of an administrative domain (including the neighbors with IP hops in between. For example, all the RSVP routers
receiver proxys) could share the same RSVP Authentication key, while of an administrative domain (including the receiver proxies) could
different per-neighbor keys could be used between any RSVP router share the same RSVP Authentication key, while different per-neighbor
pair straddling the boundary between two administrative domains that keys could be used between any RSVP router pair straddling the
have agreed to use RSVP signaling. boundary between two administrative domains that have agreed to use
RSVP signaling.
When the same RSVP Authentication shared key is to be shared among When the same RSVP Authentication key is to be shared among multiple
multiple RSVP neighbors, manual key distribution may be used. RSVP neighbors, manual key distribution may be used.
[I-D.ietf-tsvwg-rsvp-security-groupkeying] also discusses [I-D.ietf-tsvwg-rsvp-security-groupkeying] also discusses
applicability of dynamic group key distribution method for dynamic applicability of dynamic group key distribution method for dynamic
update of such shared keys among RSVP routers. update of such shared keys among RSVP routers.
The RSVP Authentication mechanisms do not provide confidentiality. The RSVP Authentication mechanisms do not provide confidentiality.
If confidentiality is required, IPsec ESP ([RFC4303]) may be used, If confidentiality is required, IPsec ESP ([RFC4303]) may be used,
although it imposes the burden of key distribution. It also faces although it imposes the burden of key distribution. It also faces
the additional issue discussed for key management above in the case the additional issue discussed for key management above in the case
where there can be IP hops in between RSVP hops. where there can be IP hops in between RSVP hops.
[I-D.ietf-tsvwg-rsvp-security-groupkeying] discusses applicability of [I-D.ietf-tsvwg-rsvp-security-groupkeying] discusses applicability of
skipping to change at page 21, line 28 skipping to change at page 26, line 28
RSVP reservations. So the use of RSVP receiver proxy is not seen as RSVP reservations. So the use of RSVP receiver proxy is not seen as
introducing any significant additional security threat or as introducing any significant additional security threat or as
modifying the RSVP trust model. modifying the RSVP trust model.
In fact, there are situations where the use of RSVP receiver proxy In fact, there are situations where the use of RSVP receiver proxy
reduces the security risks. One example is where a network operator reduces the security risks. One example is where a network operator
relies on RSVP to perform resource reservation and admission control relies on RSVP to perform resource reservation and admission control
within a network and where RSVP senders and RSVP routers are located within a network and where RSVP senders and RSVP routers are located
in the operator premises while the many RSVP receivers are located in in the operator premises while the many RSVP receivers are located in
the operator's customers premises. Such an environment is further the operator's customers premises. Such an environment is further
illustrated in "Annex A.1. RSVP-based VoD CAC in Broadband illustrated in "Annex A.1. RSVP-based VoD Admission Control in
Aggregation Networks" of [I-D.ietf-tsvwg-rsvp-proxy-approaches]. Broadband Aggregation Networks" of
From the operator's perspective, the RSVP routers and RSVP senders [I-D.ietf-tsvwg-rsvp-proxy-approaches]. From the operator's
are in physically secured locations and therefore exposed to a lower perspective, the RSVP routers and RSVP senders are in physically
risk of being tampered with; While the receivers are in locations secured locations and therefore exposed to a lower risk of being
which are physically unsecured and therefore subject to a higher risk tampered with; While the receivers are in locations that are
of being tampered with. The use of an RSVP receiver proxy function physically unsecured and therefore subject to a higher risk of being
tampered with. The use of an RSVP receiver proxy function
effectively increases the security of the operator's reservation and effectively increases the security of the operator's reservation and
admission control solution by completely excluding receivers from its admission control solution by completely excluding receivers from its
operation. Filters can be placed at the edge of the operator network operation. Filters can be placed at the edge of the operator network
discarding any RSVP message received from end-users. This provides a discarding any RSVP message received from end-users. This provides a
very simple and effective protection of the RSVP reservation and very simple and effective protection of the RSVP reservation and
admission control solution operating inside the operator's network. admission control solution operating inside the operator's network.
This document defines in Section 3.2 an optional method relying on This document defines in Section 3.2 an optional method relying on
the use of the Notify message specified in [RFC3473]. The Notify the use of the Notify message specified in [RFC3473]. The Notify
message can be sent in a non-hop-by-hop fashion that precludes RSVP's message can be sent in a non-hop-by-hop fashion that precludes use of
hop-by-hop integrity and authentication model. The approaches and RSVP hop-by-hop integrity and authentication model. The approaches
considerations for addressing this issue presented in the Security and considerations for addressing this issue presented in the
Considerations section of [RFC3473] apply. In particular, where the Security Considerations section of [RFC3473] apply. In particular,
Notify messages are transmitted non-hop-by-hop and the same level of where the Notify messages are transmitted non-hop-by-hop and the same
security provided by [RFC2747] is desired, the standard IPsec based level of security provided by [RFC2747] is desired, IPsec-based
integrity and authentication can be used. Alternatively, the sending integrity and authentication can be used ([RFC4302] or [RFC4303]).
of non-hop-by-hop Notify messages can be disabled. Finally,
[I-D.ietf-tsvwg-rsvp-security-groupkeying] discusses applicability of Alternatively, the sending of non-hop-by-hop Notify messages can be
group keying for non-hop-by-hop Notify messages. disabled. Finally, [I-D.ietf-tsvwg-rsvp-security-groupkeying]
discusses applicability of group keying for non-hop-by-hop Notify
messages.
5. IANA Considerations 5. IANA Considerations
Since, as discussed in Section 3.1.2, this document allows two Error Since, as discussed in Section 3.1.2, this document allows two Error
Codes to be used in PathErr messages while [RFC2205] only specified Codes to be used in PathErr messages while [RFC2205] only specified
their use in ResvErr messages, this document requires that IANA their use in ResvErr messages, this document requires that IANA
updates the existing entries for these two Error Codes under the updates the existing entries for these two Error Codes under the
"Error Codes and Globally-Defined Error Value Sub-Codes" registry. "Error Codes and Globally-Defined Error Value Sub-Codes" registry.
Each entry should refer to this document, in addition to referring to Each entry should refer to this document, in addition to referring to
[RFC2205]. Specifically, the entry for Error Code 1 and Error Code 2 [RFC2205]. Specifically, the entry for Error Code 1 and Error Code 2
skipping to change at page 25, line 31 skipping to change at page 30, line 31
April 2001. April 2001.
[RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V.,
and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP
Tunnels", RFC 3209, December 2001. Tunnels", RFC 3209, December 2001.
[RFC3473] Berger, L., "Generalized Multi-Protocol Label Switching [RFC3473] Berger, L., "Generalized Multi-Protocol Label Switching
(GMPLS) Signaling Resource ReserVation Protocol-Traffic (GMPLS) Signaling Resource ReserVation Protocol-Traffic
Engineering (RSVP-TE) Extensions", RFC 3473, January 2003. Engineering (RSVP-TE) Extensions", RFC 3473, January 2003.
[RFC4302] Kent, S., "IP Authentication Header", RFC 4302,
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.
7.2. Informative References 7.2. Informative References
[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-04 (work in draft-ietf-tsvwg-rsvp-proxy-approaches-06 (work in
progress), April 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-00 (work in draft-ietf-tsvwg-rsvp-security-groupkeying-02 (work in
progress), February 2008. progress), November 2008.
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
skipping to change at page 26, line 40 skipping to change at page 31, line 40
United States United States
Email: ashokn@cisco.com Email: ashokn@cisco.com
Allan Guillou Allan Guillou
Neuf Cegetel Neuf Cegetel
40-42 Quai du Point du Jour 40-42 Quai du Point du Jour
Boulogne-Billancourt, 92659 Boulogne-Billancourt, 92659
France France
Email: allan.guillou@neufcegetel.fr Email: allan.guillou@sfr.com
Hemant Malik Hemant Malik
Bharti Airtel Ltd. Bharti Airtel Ltd.
4th Floor, Tower A, Unitech Cyber Park 4th Floor, Tower A, Unitech Cyber Park
Gurgaon, Sector 39, 122001 Gurgaon, Sector 39, 122001
India India
Email: Hemant.Malik@airtel.in Email: Hemant.Malik@airtel.in
Full Copyright Statement
Copyright (C) The IETF Trust (2008).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
 End of changes. 77 change blocks. 
234 lines changed or deleted 430 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/