draft-ietf-tsvwg-rsvp-proxy-proto-11.txt   rfc5946.txt 
TSVWG F. Le Faucheur Internet Engineering Task Force (IETF) F. Le Faucheur
Internet-Draft Cisco Request for Comments: 5946 Cisco
Updates: 2205 (if approved) J. Manner Updates: 2205 J. Manner
Intended status: Standards Track TKK Category: Standards Track Aalto University
Expires: September 9, 2010 A. Narayanan ISSN: 2070-1721 A. Narayanan
Cisco Cisco
A. Guillou A. Guillou
Neuf SFR
H. Malik H. Malik
Bharti Airtel
March 8, 2010 October 2010
RSVP Extensions for Path-Triggered RSVP Receiver Proxy Resource Reservation Protocol (RSVP) Extensions
draft-ietf-tsvwg-rsvp-proxy-proto-11.txt for Path-Triggered RSVP Receiver Proxy
Abstract Abstract
RSVP signaling can be used to make end-to-end resource reservations Resource Reservation Protocol (RSVP) signaling can be used to make
in an IP network in order to guarantee the QoS required by certain end-to-end resource reservations in an IP network in order to
flows. With conventional RSVP, both the data sender and receiver of guarantee the Quality of Service (QoS) required by certain flows.
a given flow take part in RSVP signaling. Yet, there are many use With conventional RSVP, both the data sender and receiver of a given
cases where resource reservation is required, but the receiver, the flow take part in RSVP signaling. Yet, there are many use cases
sender, or both, is not RSVP-capable. Where the receiver is not where resource reservation is required, but the receiver, the sender,
RSVP-capable, an RSVP router may behave as an RSVP Receiver Proxy or both, is not RSVP-capable. Where the receiver is not RSVP-
thereby performing RSVP signaling on behalf of the receiver. This capable, an RSVP router may behave as an RSVP Receiver Proxy, thereby
allows resource reservations to be established on the segment of the performing RSVP signaling on behalf of the receiver. This allows
end-to-end path from the sender to the RSVP Receiver Proxy. However, resource reservations to be established on the segment of the end-to-
as discussed in the companion document presenting RSVP Proxy end path from the sender to the RSVP Receiver Proxy. However, as
approaches, RSVP extensions are needed to facilitate operations with discussed in the companion document "RSVP Proxy Approaches", RSVP
an RSVP Receiver Proxy whose signaling is triggered by receipt of extensions are needed to facilitate operations with an RSVP Receiver
RSVP Path messages from the sender. This document specifies these Proxy whose signaling is triggered by receipt of RSVP Path messages
extensions. from the sender. This document specifies these extensions.
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Status of This Memo
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months This is an Internet Standards Track document.
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at This document is a product of the Internet Engineering Task Force
http://www.ietf.org/shadow.html. (IETF). It represents the consensus of the IETF community. It has
received public review and has been approved for publication by the
Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 5741.
This Internet-Draft will expire on September 9, 2010. Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
http://www.rfc-editor.org/info/rfc5946.
Copyright Notice Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the Copyright (c) 2010 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 Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the BSD License. described in the Simplified BSD License.
This document may contain material from IETF Documents or IETF This document may contain material from IETF Documents or IETF
Contributions published or made publicly available before November Contributions published or made publicly available before November
10, 2008. The person(s) controlling the copyright in some of this 10, 2008. The person(s) controlling the copyright in some of this
material may not have granted the IETF Trust the right to allow material may not have granted the IETF Trust the right to allow
modifications of such material outside the IETF Standards Process. modifications of such material outside the IETF Standards Process.
Without obtaining an adequate license from the person(s) controlling Without obtaining an adequate license from the person(s) controlling
the copyright in such materials, this document may not be modified the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other it for publication as an RFC or to translate it into languages other
than English. than English.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction ....................................................4
1.1. Conventions Used in This Document . . . . . . . . . . . . 7 1.1. Conventions Used in This Document ..........................7
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 8 2. Terminology .....................................................7
3. RSVP Extensions for Sender Notification . . . . . . . . . . . 9 3. RSVP Extensions for Sender Notification .........................8
3.1. Sender Notification via PathErr Message . . . . . . . . . 12 3.1. Sender Notification via PathErr Message ...................11
3.1.1. Composition of SESSION and Sender Descriptor . . . . . 15 3.1.1. Composition of SESSION and Sender Descriptor .......14
3.1.2. Composition of ERROR_SPEC . . . . . . . . . . . . . . 15 3.1.2. Composition of ERROR_SPEC ..........................14
3.1.3. Use of Path_State_Removed Flag . . . . . . . . . . . . 16 3.1.3. Use of Path_State_Removed Flag .....................15
3.1.4. Use of PathErr by Regular Receivers . . . . . . . . . 17 3.1.4. Use of PathErr by Regular Receivers ................16
3.2. Sender Notification via Notify Message . . . . . . . . . . 18 3.2. Sender Notification via Notify Message ....................17
4. Mechanisms for Maximizing the Reservation Span . . . . . . . . 26 4. Mechanisms for Maximizing the Reservation Span .................23
4.1. Dynamic Discovery of Downstream RSVP Functionality . . . . 26 4.1. Dynamic Discovery of Downstream RSVP Functionality ........24
4.2. Receiver Proxy Control Policy Element . . . . . . . . . . 28 4.2. Receiver Proxy Control Policy Element .....................26
4.2.1. Default Handling . . . . . . . . . . . . . . . . . . . 31 4.2.1. Default Handling ...................................29
5. Security Considerations . . . . . . . . . . . . . . . . . . . 32 5. Security Considerations ........................................29
5.1. Security Considerations for the Sender Notification 5.1. Security Considerations for the Sender
via Notify Message . . . . . . . . . . . . . . . . . . . . 33 Notification via Notify Message ...........................30
5.2. Security Considerations for the Receiver Proxy Control 5.2. Security Considerations for the Receiver Proxy
Policy Element . . . . . . . . . . . . . . . . . . . . . . 33 Control Policy Element ....................................31
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 35 6. IANA Considerations ............................................32
6.1. RSVP Error Codes . . . . . . . . . . . . . . . . . . . . . 35 6.1. RSVP Error Codes ..........................................32
6.2. Policy Element . . . . . . . . . . . . . . . . . . . . . . 35 6.2. Policy Element ............................................32
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 37 7. Acknowledgments ................................................33
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 38 8. References .....................................................33
8.1. Normative References . . . . . . . . . . . . . . . . . . . 38 8.1. Normative References ......................................33
8.2. Informative References . . . . . . . . . . . . . . . . . . 39 8.2. Informative References ....................................34
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 40
1. Introduction 1. Introduction
Guaranteed QoS for some applications with tight QoS requirements may Guaranteed Quality of Service (QoS) for some applications with tight
be achieved by reserving resources in each node on the end-to-end QoS requirements may be achieved by reserving resources in each node
path. The main IETF protocol for these resource reservations is RSVP on the end-to-end path. The main IETF protocol for these resource
reservations is the Resource Reservation Protocol (RSVP), as
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
Resv messages. We refer to this entity as the RSVP Sender Proxy. In sink Resv messages. We refer to this entity as the RSVP Sender
the second case, an entity in the network needs to operate RSVP on Proxy. In the second case, an entity in the network needs to operate
behalf of the receiver and thus receive Path messages sent by a data RSVP on behalf of the receiver and thus receive Path messages sent by
sender (or by an RSVP Sender Proxy), and reply to those with Resv a data sender (or by an RSVP Sender Proxy), and reply to those with
messages generated on behalf of the data receiver(s). We refer to Resv messages generated on behalf of the data receiver(s). We refer
this entity as the RSVP Receiver Proxy. to this entity as the RSVP Receiver Proxy.
RSVP Proxy approaches are presented in RSVP Proxy approaches are presented in [RFC5945]. 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
to satisfy application requirements). reservation 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(s). 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 somewhat changes 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 synchronization between an RSVP reservation and an Since the synchronization between an RSVP reservation and an
application 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 the case of admission control rejection of the reservation)
only sent towards the receiver and therefore, in our case, sunk by are only sent towards the receiver and therefore, in our case, sunk
the RSVP Receiver Proxy. Section 3 of the present document specifies by the RSVP Receiver Proxy. Section 3 of this document specifies
extensions to RSVP procedures allowing such notifications to be also extensions to RSVP procedures allowing such notifications to be also
conveyed towards the sender. This facilitates synchronization by the conveyed towards the sender. This facilitates synchronization by the
sender (or RSVP Sender Proxy) between the RSVP reservation and the sender (or RSVP Sender Proxy) between the RSVP reservation and the
application requirements and facilitates sender-driven control of application requirements, and it facilitates sender-driven control of
reservation in scenarios involving a Path-Triggered RSVP receiver reservation in scenarios involving a Path-Triggered RSVP Receiver
Proxy. Proxy.
With unicast applications in the presence of RSVP Receiver Proxies, With unicast applications in the presence of RSVP Receiver Proxies,
if the sender is notified about the state of the reservation towards if the sender is notified about the state of the reservation towards
the receiver (as enabled by the present document), the sender is the receiver (as enabled by this document), the sender is generally
generally in a good position to synchronize the reservation with the 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 the establishment or removal of the reservation
reservation towards the receiver by sending Path (respectively towards the receiver by sending Path or PathTear messages,
PathTear) messages. For example, if the sender is notified that the respectively. 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 coexist However, we note that multicast applications do not always coexist
well 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 benefits from a reservation. Additionally, a sender may receiver benefits from a reservation. Additionally, a sender 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 signaling 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
benefit from 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 Proxies. 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 benefit from a reservation (to independently of whether or not they can benefit from a reservation
their respective RSVP Receiver Proxy) or not, but do benefit from a (to their respective RSVP Receiver Proxy), 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
rest of this document discusses operation assuming a regular RSVP rest of this document discusses operations assuming a regular RSVP
sender; however, such operation is equally applicable where an RSVP sender; however, such an operation is equally applicable where an
Sender Proxy is used to initiated RSVP signaling on behalf of a non- RSVP Sender Proxy is used to initiated RSVP signaling on behalf of a
RSVP-capable sender. non-RSVP-capable sender.
As discussed in [I-D.ietf-tsvwg-rsvp-proxy-approaches], it is As discussed in [RFC5945], it is important to keep in mind that the
important to keep in mind that the strongly recommended RSVP strongly recommended RSVP deployment model remains end to end as
deployment model remains end to end as assumed in [RFC2205] with RSVP assumed in [RFC2205] with RSVP support on the sender and the
support on the sender and the receiver. The end to end model allows receiver. The end-to-end model allows the most effective
the most effective synchronization between the reservation and synchronization between the reservation and application requirements.
application requirements. Also, when compared to the end to end RSVP Also, when compared to the end-to-end RSVP model, the use of RSVP
model, the use of RSVP Proxies involves additional operational burden Proxies involves additional operational burden and/or imposes some
and/or impose some topological constraints. Thus, the purpose of topological constraints. Thus, the purpose of this document is only
this document is only to allow RSVP deployment in special to allow RSVP deployment in special environments where RSVP just
environments where RSVP just cannot be used on some senders and/or cannot be used on some senders and/or some receivers for reasons
some receivers for reasons specific to the environment. specific to the environment.
Section 4.1.1 of [I-D.ietf-tsvwg-rsvp-proxy-approaches] discusses Section 4.1.1 of [RFC5945] discusses mechanisms allowing the RSVP
mechanisms allowing the RSVP reservation for a given flow to be reservation for a given flow to be dynamically extended downstream of
dynamically extended downstream of an RSVP Proxy whenever possible an RSVP Proxy whenever possible (i.e., when the receiver is RSVP-
(i.e. When the receiver is RSVP capable or when there is another capable or when there is another RSVP Receiver Proxy downstream).
RSVP Receiver Proxy downstream). This can considerably alleviate the This can considerably alleviate the operational burden and the
operational burden and the topological constraints associated with topological constraints associated with Path-Triggered RSVP Receiver
Path-triggered RSVP Receiver Proxies. This allows (without Proxies. This allows (without corresponding manual configuration) an
corresponding manual configuration) an RSVP reservation to RSVP reservation to dynamically span as much of the corresponding
dynamically span as much of the corresponding flow path as possible, flow path as possible, with any arbitrary number of RSVP Receiver
with any arbitrary number of RSVP Receiver Proxies on the flow path Proxies on the flow path and whether or not the receiver is RSVP-
and whether the receiver is RSVP capable or not. In turn, this capable. In turn, this facilitates migration from an RSVP deployment
facilitates migration from an RSVP deployment model based on Path- model based on Path-Triggered Receiver Proxies to an end-to-end RSVP
triggered Receiver Proxies to an end-to-end RSVP model, since model, since receivers can gradually and independently be upgraded to
receivers can gradually and independently be upgraded to support RSVP support RSVP and then instantaneously benefit from end-to-end
and then instantaneously benefit from end-to-end reservations. reservations. Section 4 of this document specifies these mechanisms
Section 4 of the present document specifies these mechanisms and and associated RSVP extensions.
associated RSVP extensions.
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 [RFC5945] and is used
[I-D.ietf-tsvwg-rsvp-proxy-approaches] and is used extensively in the extensively in this document:
present document:
o RSVP-capable (or RSVP-aware): supporting the RSVP protocol as per o RSVP-capable (or RSVP-aware): supporting the RSVP protocol as per
[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 that 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 were 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 that normally would 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 were 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 that is not behaving
as a RSVP Receiver Proxy nor as a RSVP Sender Proxy. as an RSVP Receiver Proxy nor as an RSVP Sender Proxy.
Note that the roles of RSVP Receiver Proxy, RSVP Sender Proxy, Note that the roles of the RSVP Receiver Proxy, RSVP Sender Proxy,
Regular RSVP Router are all relative to one unidirectional flow. A and regular RSVP Router are all relative to one unidirectional flow.
given router may act as the RSVP Receiver Proxy for a flow, as the A given router may act as the RSVP Receiver Proxy for a flow, as the
RSVP Sender Proxy for another flow and as a Regular RSVP router for RSVP Sender Proxy for another flow, and as a regular RSVP router for
yet another flow. yet another flow.
The following terminology is also used in the present document: The following terminology is also used in this document:
o Regular RSVP Sender: an RSVP-capable host behaving as the sender o Regular RSVP sender: an RSVP-capable host behaving as the sender
for the considered flow and participating in RSVP signaling in for the considered flow and participating in RSVP signaling in
accordance with the sender behavior specified in [RFC2205]. accordance with the sender behavior specified in [RFC2205].
o Regular RSVP Receiver: an RSVP-capable host behaving as the o Regular RSVP receiver: an RSVP-capable host behaving as the
receiver for the considered flow and participating in RSVP receiver for the considered flow and participating in RSVP
signaling in accordance with the receiver behavior specified in signaling in accordance with the receiver behavior specified in
[RFC2205]. [RFC2205].
3. RSVP Extensions for Sender Notification 3. RSVP Extensions for Sender Notification
This section defines extensions to RSVP procedures allowing sender This section defines extensions to RSVP procedures allowing sender
notification of reservation failure. This facilitates notification of reservation failure. This facilitates
synchronization by the sender between RSVP reservation and synchronization by the sender between RSVP reservation and
application requirements in scenarios involving a Path-Triggered RSVP application requirements in scenarios involving a Path-Triggered RSVP
Receiver Proxy. Receiver Proxy.
As discussed in [I-D.ietf-tsvwg-rsvp-proxy-approaches], with the As discussed in [RFC5945], with the Path-Triggered RSVP Receiver
Path-Triggered RSVP Receiver Proxy approach, the RSVP router may be Proxy approach, the RSVP router may be configured to use receipt of a
configured to use receipt of a regular RSVP Path message as the regular RSVP Path message as the trigger for RSVP Receiver Proxy
trigger for RSVP Receiver Proxy behavior. On receipt of the RSVP behavior. On receipt of the RSVP Path message, the RSVP Receiver
Path message, the RSVP Receiver Proxy: 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 corresponding Resv message (on its way upstream 4. behaves as if a corresponding Resv message (on its way upstream
from the receiver) was received on the downstream interface. from the receiver) was received on the downstream interface.
This includes performing admission control on the downstream This includes performing admission control on the downstream
interface, establishing a Resv state (in case of successful interface, establishing a Resv state (in the case of successful
admission control) and forwarding the Resv message upstream, admission control), and forwarding the Resv message upstream,
sending periodic refreshes of the Resv message and tearing down sending periodic refreshes of the Resv message and tearing down
the 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 10, line 35 skipping to change at page 9, line 35
==> segment of flow path benefiting from an 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 the case of reservation failure, conventional RSVP
ensure only that the receiver (or the RSVP Receiver Proxy) is procedures ensure only that the receiver (or the RSVP Receiver Proxy)
notified of the reservation failure. Specifically, in case of an is notified of the reservation failure. Specifically, in the case of
admission control rejection on a regular RSVP router, a ResvErr an 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.
|****| *** *** *** |**********| |----| |****| *** *** *** |**********| |----|
| S |--------*r*--------*r*--------*r*--------| RSVP |------| R | | S |--------*r*--------*r*--------*r*--------| RSVP |------| R |
skipping to change at page 11, line 29 skipping to change at page 10, line 29
************************************************************> ************************************************************>
|****| 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 benefiting from an 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 to ensuring that the sender gets a prompt, explicit
notification in case of reservation failure. This includes faster notification in the case of reservation failure. This includes
end-user notification at application layer (e.g., busy signal), faster end-user notification at the application layer (e.g., busy
faster application level reaction (e.g., application level signal) and faster application-level reaction (e.g., application-
rerouting), as well as faster release of application-level resources. level rerouting), as well as faster release of application-level
resources.
Section 3.1 defines a method that 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 that can be used to achieve sender Section 3.2 defines another 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 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, 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 was
introduced in order to achieve a similar requirement, which is to introduced in order to satisfy a similar requirement, which is to
allow an MPLS TE Label Switch Router to notify the TE Tunnel Head-end allow an MPLS Traffic Engineering (TE) Label Switching Router to
(i.e., the sender) of a failure to establish (or maintain) a TE notify the TE Tunnel head-end (i.e., the sender) of a failure to
Tunnel Label Switch Path. establish (or maintain) a TE 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 a 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 |
|**********| |**********|
--Path---> --Path---> --Path---> --Path---> --Path---> --Path---> --Path---> --Path--->
<---Resv-- <---Resv-- <---Resv-- <---Resv--
skipping to change at page 13, line 32 skipping to change at page 12, line 32
|****| 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 benefiting from RSVP ==> segment of flow path benefiting from RSVP
(but not benefiting from a reservation in this case) (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
generation of a ResvErr (for example, admission control failure), the generation of a ResvErr (for example, admission control failure), the
Receiver Proxy MUST generate a PathErr towards the sender. The Receiver Proxy MUST generate a PathErr towards the sender. The
Receiver Proxy MAY additionally generate a PathErr upon local Receiver Proxy MAY additionally generate a PathErr upon local
failures which would not ordinarily cause generation of a ResvErr failures that would not ordinarily cause generation of a ResvErr
message, such as described in Appendix B of [RFC2205]. message, such as those 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) that 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 MUST For FF-style (Fixed-Filter) reservations, the Receiver Proxy MUST
send a PathErr towards the (single) sender matching the failed send a PathErr towards the (single) sender matching the failed
reservation. For Shared-Explicit (SE) style reservations, the reservation. For SE-style (Shared-Explicit) reservations, the
Receiver Proxy MUST send the PathErr(s) towards the set of senders Receiver Proxy MUST send the PathErr(s) towards the set of senders
that triggered reservations that failed. This may be a subset of that triggered reservations that failed. This may be a subset of
senders sharing the same reservation, in which case the remaining senders sharing the same reservation, in which case the remaining
senders would have their reservation intact and would not receive a senders would have their reservation intact and would not receive a
PathErr. In both cases, the rules described in Section 3.1.8 of PathErr. In both cases, the rules described in Section 3.1.8 of
[RFC2205] for generating flow descriptors in ResvErr messages, also [RFC2205] for generating flow descriptors in ResvErr messages also
apply when generating sender descriptors in PathErr messages. apply when generating sender descriptors in PathErr messages.
For Wildcard-Filter (WF) style reservations, it is not always For WF-style (Wildcard-Filter) reservations, it is not always
possible for the Receiver Proxy to reliably know which sender caused possible for the Receiver Proxy to reliably know which sender caused
the reservation failure. Therefore, the Receiver Proxy SHOULD send a the reservation failure. Therefore, the Receiver Proxy SHOULD send a
PathErr towards each sender. This means that all the senders will PathErr towards each sender. This means that all the senders will
receive a notification that the reservation is not established, receive a notification that the reservation is not established,
including senders that did not cause the reservation failure. including senders that did not cause the reservation failure.
Therefore, the method of sender notification via PathErr message is Therefore, the method of sender notification via a PathErr message is
somewhat over-conservative (i.e., in some cases rejecting somewhat overly conservative (i.e., in some cases, rejecting
reservations from some senders when those could have actually been reservations from some senders when those could have actually been
established) when used in combination with Wildcard-Filter style (and established) when used in combination with the Wildcard-Filter style
when there is more than one sender). (and when there is more than one sender).
The sender notification via PathErr method applies to both unicast The sender notification via the PathErr method applies to both
and multicast sessions. However, for a multicast session, it is unicast and multicast sessions. However, for a multicast session, it
possible that reservation failure (e.g., admission control failure) is possible that reservation failure (e.g., admission control
in a node close to a sender may cause ResvErr messages to be sent to failure) in a node close to a sender may cause ResvErr messages to be
a large group of Receiver Proxies. These Receiver Proxies would, in sent to a large group of Receiver Proxies. These Receiver Proxies
turn, all send PathErr messages back to the same sender, which could would, in turn, all send PathErr messages back to the same sender,
cause a scalability issue in some environments. which could cause a scalability issue in some environments.
From the perspective of the sender, errors that prevent a reservation From the perspective of the sender, errors that prevent a reservation
from being set up can be classified in two ways: from being set up can be classified in two ways:
1. Errors that 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 these errors should explicitly be communicated back to the
sender. An examples of this is "Class 1: Admission Control sender. An example of this is "Code 1: Admission Control
Failure", because the sender could potentially resend a Path with Failure", because the sender could potentially resend a Path
smaller traffic parameters. message with smaller traffic parameters.
2. Errors over which the sender has no control. 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 "Code 13: Unknown
Unknown Object", because the sender has no control over the Object", because the sender has no control over the objects
objects inserted into the reservation by the Receiver Proxy. 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 FF-style reservations,
style reservations, the Receiver Proxy MUST insert a sender the Receiver Proxy MUST insert a sender descriptor corresponding to
descriptor corresponding to the failed reservation, into the PathErr. the failed reservation into the PathErr. This is equal to the error
This is equal to the error flow descriptor in the ResvErr received by flow descriptor in the ResvErr received by the Receiver Proxy. For
the Receiver Proxy. For Shared-Explicit (SE) style reservations, the SE-style reservations, the Receiver Proxy MUST insert a sender
Receiver Proxy MUST insert a sender descriptor corresponding to the descriptor corresponding to the sender triggering the failed
sender triggering the failed reservation, into the PathErr. This is reservation into the PathErr. This is equal to the error flow
equal to the error flow descriptor in the ResvErr received by the descriptor in the ResvErr received by the Receiver Proxy. If
Receiver Proxy. If multiple flow descriptors could not be admitted multiple flow descriptors could not be admitted at a midpoint node,
at a midpoint node, that node would generate multiple ResvErr that node would generate multiple ResvErr messages towards the
messages towards the receiver as per Section 3.1.8 of [RFC2205]. receiver as per Section 3.1.8 of [RFC2205]. Each ResvErr would
Each ResvErr would contain an error flow descriptor that matches a contain an error flow descriptor that matches a specific sender. The
specific sender. The Receiver Proxy MUST generate a PathErr for each Receiver Proxy MUST generate a PathErr for each ResvErr received
ResvErr received, towards the corresponding sender. As specified towards the corresponding sender. As specified earlier, for WF-style
earlier, for Wildcard-Filter style reservations, the Receiver Proxy reservations, the Receiver Proxy SHOULD send a PathErr to each
SHOULD send a PathErr to each sender. 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 either of these
codes: "Code 1 - Admission Control Failure" or "Code 2 - Policy error codes -- "Code 1: Admission Control Failure" or "Code 2:
Control Failure" then the Receiver Proxy copies the error code Policy Control Failure" -- then the Receiver Proxy copies the
and value from the ERROR_SPEC in the ResvErr, into the ERROR_SPEC error code and value from the ERROR_SPEC in the ResvErr into the
of the PathErr message. The error node in the PathErr MUST be ERROR_SPEC of the PathErr message. The error node in the PathErr
set to the address of the Receiver Proxy. This procedure MUST MUST be set to the address of the Receiver Proxy. This procedure
also be followed for a local error on the Receiver Proxy that MUST also be followed for a local error on the Receiver Proxy
would ordinarily cause a midpoint to generate a ResvErr with one that would ordinarily cause a midpoint to generate a ResvErr with
of the above codes. one of the above codes.
2. If the Receiver Proxy receives a ResvErr with any error code 2. If the Receiver Proxy receives a ResvErr with any error code
other than the ones listed in 1 above, it composes a new except the ones listed in item 1 above, it composes a new
ERROR_SPEC with error code "<TBD-See IANA Considerations ERROR_SPEC with error code "36: Unrecoverable Receiver Proxy
section>: Unrecoverable Receiver Proxy Error". The error node in Error". The error node address in the PathErr MUST be set to the
the PathErr MUST be set to the address of the Receiver Proxy. address of the Receiver Proxy. This procedure MUST also be
This procedure MUST also be followed for a local error on the followed for a local error on the Receiver Proxy that would
Receiver Proxy that would ordinarily cause a midpoint to generate ordinarily cause a midpoint to generate a ResvErr with any error
a ResvErr with any error code except than those listed in 1 code other than those listed in item 1 above, or if the Receiver
above, or if the Receiver Proxy generates a PathErr for a local Proxy generates a PathErr for a local error that ordinarily would
error which ordinarily would not cause generation of a ResvErr. not cause generation of a ResvErr. In some cases, it may be
predetermined that the PathErr will not reach the sender. For
In some cases it may be predetermined that the PathErr will not example, a node receiving a ResvErr with "Code 3: No Path for
reach the sender. For example, a node receiving a ResvErr with Resv", knows a priori that the PathErr message it generates
"Code 3: No Path for Resv", knows a priori that the PathErr cannot be forwarded by the same node that could not process the
message it generates cannot be forwarded by the same node which Resv. Nevertheless, the procedures above MUST be followed. For
could not process the Resv. Nevertheless, the procedures above the error code "36: Unrecoverable Receiver Proxy Error", the 16
MUST be followed. For the error code "<TBD-See IANA bits of the Error Value field are:
Considerations section>: Unrecoverable Receiver Proxy Error", the
16 bits of the Error Value field are:
* hhhh hhhh llll llll * hhhh hhhh llll llll
where the bits are: where the bits are:
* hhhh hhhh = 0000 0000: then the low order 8 bits (llll llll) * hhhh hhhh = 0000 0000: then the low order 8 bits (llll llll)
MUST be set by Receiver Proxy to 0000 0000 and MUST be ignored MUST be set by Receiver Proxy to 0000 0000 and MUST be ignored
by the sender. by the sender.
* hhhh hhhh = 0000 0001: then the low order 8 bits (llll llll) * hhhh hhhh = 0000 0001: then the low order 8 bits (llll llll)
MUST be set by the Receiver Proxy to the value of the error MUST be set by the Receiver Proxy to the value of the error
code received in the ResvErr ERROR_SPEC (or, in case the code received in the ResvErr ERROR_SPEC (or, in case the
Receiver Proxy generated the PathErr without having received a Receiver Proxy generated the PathErr without having received a
ResvErr, to the error code value that would have been included ResvErr, to the error code value that would have been included
by the Receiver Proxy in the ERROR_SPEC in similar conditions by the Receiver Proxy in the ERROR_SPEC in similar conditions
if it was to generate a ResvErr). This error value MAY be if it was to generate a ResvErr). This error value MAY be
used by the sender to further interpret the reason of the used by the sender to further interpret the reason for the
reservation failure. reservation failure.
* hhhh hhhh = any other value: reserved. * hhhh hhhh = any other value: reserved.
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 minimize 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
skipping to change at page 17, line 15 skipping to change at page 16, line 17
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. When 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 are one or more RSVP router on the path of the reservation if there are one or more RSVP routers on the path of the reservation
that do not support the Path_State_Removed flag (we refer to such that do not support the Path_State_Removed flag (we refer to such
routers as "old RSVP routers"), 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 release its will not send a Path Tear, and the old RSVP router will release its
Path state only 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 the 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 modifying 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 synchronize 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) need 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 that were explicitly sought by
[RFC2205]. Quoting from it: " In order to efficiently accommodate [RFC2205], which states, "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 simplest 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 admission control any error message to the sender in case of admission control
reject. reject.
o The motivation for adding sender error notification in case of o The motivation for adding sender error notification in the case of
receiver proxy lies in the fact that the actual receiver can no an RSVP Receiver Proxy lies in the fact that the actual receiver
longer synchronize the RSVP reservation with application state can no longer synchronize the RSVP reservation with application
(since the receiver does not participate in RSVP signaling), while state (since the receiver does not participate in RSVP signaling),
the sender can. This motivation does not apply in case of regular while the sender can. This motivation does not apply in the case
receiver. of a regular 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 of existing deployed systems should
unless there were a very strong motivation. not be changed 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 to provide a more efficient method than defined in this section aims to provide a more efficient method 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 allowing the failure notification to be sent directly upstream to
sender by the router where the failure occurs (as opposed to first the sender by the router where the failure occurs (as opposed to
travelling downstream towards the Receiver Proxy and then first traveling downstream towards the Receiver Proxy and then
travelling upstream from the Receiver Proxy to the sender, as traveling 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 without hop-by-hop RSVP o allowing the failure notification to travel without hop-by-hop
processing RSVP processing.
o ensure that such a notification is sent to senders that are o ensuring that such a notification is sent to senders that are
capable and willing to process it (i.e., to synchronize capable and willing to process it (i.e., to synchronize
reservation status with application) reservation status with application).
o ensure that such a notification is only sent in case the receiver o ensuring that such a notification is only sent in case the
is not itself capable and willing to do the synchronization with receiver is not itself capable and willing to do the
the application (i.e., because we are in the presence of a synchronization with the application (i.e., because we are in the
Receiver Proxy so that RSVP signaling is not visible to the presence of a Receiver Proxy so that RSVP signaling is not visible
receiver). 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
message that provides a mechanism to inform non-adjacent nodes of message that provides a mechanism to inform non-adjacent nodes of
events related to the RSVP reservation. The Notify message differs events related to the RSVP reservation. The Notify message differs
from the error messages defined in [RFC2205] (i.e., PathErr and from the error messages defined in [RFC2205] (i.e., PathErr and
ResvErr messages) in that it can be "targeted" to a node other than ResvErr messages) in that it can be "targeted" to a node other than
the immediate upstream or downstream neighbor and that it is a the immediate upstream or downstream neighbor and that it is a
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 this 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: contain either:
* either the address that was included in the Notify Request of * the address that was included in the Notify Request of the
the received Path message- a.k.a. The sender's address-. We received Path message, a.k.a. the sender's address. We refer
refer to this approach as the "Direct Notify". to this approach as the "Direct Notify" approach, or
* or an address of the Receiver Proxy. We refer to this approach * an address of the Receiver Proxy. We refer to this approach as
as the "Indirect Notify". the "Indirect Notify" approach.
o Upon receiving a downstream error notification (whether in the o Upon receiving a downstream error notification (whether in the
form of a Notify or a ResvErr or both), the RSVP Receiver Proxy: form of a Notify, ResvErr, or both), the RSVP Receiver Proxy:
* MUST generate a Notify message with upstream notification to * MUST generate a Notify message with upstream notification to
the corresponding sender, if the sender included a Notify the corresponding sender, if the sender included a Notify
Request object in its Path messages and if Indirect Request object in its Path messages and if Indirect
Notification is used. Notification is used.
* SHOULD generate a Notify message with upstream notification to * SHOULD generate a Notify message with upstream notification to
the corresponding sender, if the sender included a Notify the corresponding sender, if the sender included a Notify
Request object in its Path messages and if Direct Notification Request object in its Path messages and if Direct Notification
is used. The reason for this recommendation is that the is used. The reason for this recommendation is that the
failure node may not support Notify, so that even if Direct failure node may not support Notify, so that even if Direct
Notification was requested by the RSVP Receiver Proxy, the Notification was requested by the RSVP Receiver Proxy, the
sender may not actually have received a Notify from the failure sender may not actually have received a Notify from the failure
node: generating a Notify from the Receiver Proxy will node: generating a Notify from the Receiver Proxy will
accelerate sender notification, as compared to simply relying accelerate sender notification, as compared to simply relying
on PathErr, in this situation. In controlled environments on PathErr, in this situation. In controlled environments
where all the nodes are known to support Notify, the Receiver where all the nodes are known to support Notify, the Receiver
Proxy MAY be configured to not generate the Notify with Proxy MAY be configured to not generate the Notify with
upstream notification when Direct Notification is used, in upstream notification when Direct Notification is used, in
order to avoid duplication of Notify messages (i.e. The sender order to avoid duplication of Notify messages (i.e., the sender
receiving both a Notify from the failure node and from the receiving both a Notify from the failure node and from the
Receiver Proxy) Receiver Proxy).
As a result of these sender and Receiver Proxy behaviors, as per As a result of these sender and Receiver Proxy behaviors, as per
existing Notify procedures, if an RSVP router detects an error existing Notify procedures, if an RSVP router detects an error
relating to a Resv state (e.g., admission control rejection after IP relating to a Resv state (e.g., admission control rejection after IP
reroute), the RSVP router will send a Notify message (conveying the reroute), the RSVP router will send a Notify message (conveying the
downstream notification with the ResvErr error code) to the IP downstream notification with the ResvErr error code) to the IP
address contained in the Resv Notify Request object. If this address address contained in the Resv Notify Request object. If this address
has been set by the RSVP Receiver Proxy to the sender's 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. (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 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 own addresses (Indirect Notify), the Notify message is sent to the
Receiver Proxy that, in turn, will generate a Notify message directly RSVP Receiver Proxy that, in turn, will generate a Notify message
addressed to the sender. 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 Direct admission control failure, using sender notification via Direct
Notify, 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 |
|**********| |**********|
skipping to change at page 21, line 46 skipping to change at page 20, line 46
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 NotifyU = Notify message containing an upstream notification
Figure 4: Reservation Failure With Sender Notification via Direct Figure 4: Reservation Failure with Sender Notification
Notify via Direct 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 | |----|
| Proxy | | Proxy |
|**********| |**********|
skipping to change at page 23, line 46 skipping to change at page 21, line 46
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
Figure 5: Reservation Failure With Sender Notification via Indirect Figure 5: Reservation Failure with Sender Notification
Notify 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, admission control failure), the Receiver Proxy MUST generate example, admission control failure), the Receiver Proxy MUST generate
a Notify towards the sender. The Receiver Proxy MAY additionally a Notify towards the sender. The Receiver Proxy MAY additionally
generate a Notify upon local failures that 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 those described in
[RFC2205]. Appendix B of [RFC2205].
When the method of sender notification via Notify message is used, it When the method of sender notification via a Notify message is used,
is RECOMMENDED that the RSVP Receiver Proxy also issue a sender it 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 will reach the sender in all situations (e.g., even the notification will reach the sender in all situations (e.g., even
if some RSVP routers do not support the Notify procedure, or if a if some RSVP routers do not support the Notify procedure, or if a
Notify message gets dropped). However, for controlled environments Notify message gets dropped). However, for controlled environments
(e.g., where all RSVP routers are known to support Notify procedures) (e.g., where all RSVP routers are known to support Notify procedures)
and where it is desirable to minimize the volume of signaling, the and where it is desirable to minimize the volume of signaling, the
RSVP Receiver Proxy MAY rely exclusively on sender notification via RSVP Receiver Proxy MAY rely exclusively on sender notification via a
Notify message and thus not issue sender notification via PathErr Notify message and thus not issue sender notification via a PathErr
message. 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 sender that supports the procedures defined in this section may
include a Notify Request object in Path messages for a reservation include a Notify Request object in Path messages for a reservation
that happens to be controlled by an RSVP-capable receiver. This that happens to be controlled by an RSVP-capable receiver. This
document does not define, nor expect, any change in existing receiver document does not define, nor expect, any change in existing receiver
behavior. As a result, in this case, the sender will not receive behavior. As a result, in this case, the sender will not receive
Notify messages conveying downstream notifications. However, this is Notify messages conveying downstream notifications. However, this is
perfectly fine because the synchronization between the RSVP perfectly fine because the synchronization between the RSVP
reservation state and the application requirement can be performed by reservation state and the application requirement can be performed by
skipping to change at page 24, line 47 skipping to change at page 22, line 46
A sender that does not support the procedures defined in this section A sender that does not support the procedures defined in this section
might include a Notify Request object in Path messages for a might include a Notify Request object in Path messages for a
reservation simply because it is interested in getting upstream reservation simply because it is interested in getting upstream
notifications faster. If the reservation is controlled by an RSVP notifications faster. If the reservation is controlled by an RSVP
Receiver Proxy supporting the procedures defined in this section, the Receiver Proxy supporting the procedures defined in this section, the
sender will also receive unexpected Notify messages containing sender will also receive unexpected Notify messages containing
downstream notifications. It is expected that such a sender will downstream notifications. It is expected that such a sender will
simply naturally drop such downstream notifications as invalid. simply naturally drop such downstream notifications as invalid.
Because it is RECOMMENDED above that the RSVP Receiver Proxy also Because it is RECOMMENDED above that the RSVP Receiver Proxy also
issues sender notification via a PathErr message even when sender issue a sender notification via a PathErr message even when sender
notification is effected via a Notify message, the sender will still notification is effected via a Notify message, the sender will still
be notified of a 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 from
on the MANDATORY "sender notification via PathErr" method. It would, relying on the MANDATORY "sender notification via PathErr" method.
however, allow a sender supporting the "sender notification via It would, however, allow a sender supporting the "sender notification
Notify" method to take advantage of this OPTIONAL method. via Notify" method to take advantage of this OPTIONAL method.
With Direct Notification, the downstream notification generated by With Direct Notification, the downstream notification generated by
the RSVP router where the failure occurs is sent to the IP address the RSVP router where the failure occurs is sent to the IP address
contained in the Notification Request Object of the corresponding contained in the Notification Request Object of the corresponding
Resv message. In the presence of multiple senders towards the same Resv message. In the presence of multiple senders towards the same
session, it cannot be generally assumed that a separate Resv message 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 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 Resv message for all senders, and with FF the downstream router has
the choice of generating separate Resv messages or a single one). the choice of generating separate Resv messages or a single one).
Hence, in the presence of multiple senders, Direct Notification Hence, in the presence of multiple senders, Direct Notification
cannot guarantee notification of all affected senders. Therefore, cannot guarantee notification of all affected senders. Therefore,
Direct Notification is better suited to single sender applications. Direct Notification is better suited to single-sender applications.
With Indirect Notification, the RSVP Receiver Proxy can generate With Indirect Notification, the RSVP Receiver Proxy can generate
Notify messages with the same logic that is used to generate PathErr Notify messages with the same logic that is used to generate PathErr
messages in the "Sender Notification via PathErr" method (in fact messages in the "Sender Notification via PathErr" method (in fact,
those are conveying the same error information, only the Notify is those are conveying the same error information, only the Notify is
directly addressed to the sender while the PathErr travels hop-by- directly addressed to the sender while the PathErr travels hop-by-
hop). Therefore, operations of Indirect Notify method in the hop). Therefore, operations of the Indirect Notify method in the
presence of multiple senders is similar to that of the PathErr method 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 as discussed in Section 3.1: with FF or SE, a Notify MUST be sent to
be sent to the sender (respectively, the set of affected senders). the sender or the set of affected senders, respectively. With WF,
With WF, the RSVP Receiver Proxy SHOULD send a Notify to each sender, the RSVP Receiver Proxy SHOULD send a Notify to each sender, again
again resulting in a somewhat over-conservative behavior in the resulting in a somewhat overly conservative behavior in the presence
presence of multiple senders. of multiple senders.
4. Mechanisms for Maximizing the Reservation Span 4. Mechanisms for Maximizing the Reservation Span
This section defines extensions to RSVP procedures allowing an RSVP This section defines extensions to RSVP procedures allowing an RSVP
reservation to span as much as possible of the flow path, with any reservation to span as much of the flow path as possible, with any
arbitrary number of RSVP Receiver Proxies on the flow path and arbitrary number of RSVP Receiver Proxies on the flow path and
whether the receiver is RSVP capable or not. This facilitates whether or not the receiver is RSVP-capable. This facilitates
deployment and operations of Path-triggered RSVP Receiver Proxies deployment and operations of Path-Triggered RSVP Receiver Proxies
since it alleviates the topological constraints and/or configuration since it alleviates the topological constraints and/or configuration
load otherwise associated with Receiver Proxies (e.g. Make sure load otherwise associated with Receiver Proxies (e.g., make sure
there is no RSVP Receiver Proxy for a flow upstream of a given there is no RSVP Receiver Proxy for a flow upstream of a given
Receiver Proxy, ensure there is no Receiver Proxy for a flow if the Receiver Proxy, ensure there is no Receiver Proxy for a flow if the
receiver is RSVP capable). This also facilitates migration from an receiver is RSVP-capable). This also facilitates migration from an
RSVP deployment model based on Path-triggered Receiver Proxies to an RSVP deployment model based on Path-Triggered Receiver Proxies to an
end-to-end RSVP model, since receivers can gradually and end-to-end RSVP model, since receivers can gradually and
independently be upgraded to support RSVP and then instantaneously independently be upgraded to support RSVP and then instantaneously
benefit from end-to-end reservations. benefit from end-to-end reservations.
Section 4.1 defines a method that allows a Path-triggered Receiver Section 4.1 defines a method that allows a Path-Triggered Receiver
Proxy function to discover whether there is another Receiver Proxy or Proxy function to discover whether there is another Receiver Proxy or
an RSVP capable receiver downstream and then dynamically extend the an RSVP-capable receiver downstream and then dynamically extend the
span of the RSVP reservation downstream. A router implementation span of the RSVP reservation downstream. A router implementation
claiming compliance with this document SHOULD support the method claiming compliance with this document SHOULD support the method
defined in Section 4.1. defined in Section 4.1.
Section 4.2 defines a method that allows a sender to control whether Section 4.2 defines a method that allows a sender to control whether
an RSVP router supporting the Path-triggered Receiver Proxy function or not an RSVP router supporting the Path-Triggered Receiver Proxy
is to behave as a Receiver Proxy for a given flow or not. A router function is to behave as a Receiver Proxy for a given flow. A router
implementation claiming compliance with this document MAY support the implementation claiming compliance with this document MAY support the
method defined in Section 4.2. method defined in Section 4.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 4.1, or the method defined in use the method defined in Section 4.1, or the method defined in
Section 4.2, or possibly combine the two. Section 4.2, or possibly combine the two.
4.1. Dynamic Discovery of Downstream RSVP Functionality 4.1. Dynamic Discovery of Downstream RSVP Functionality
When generating a proxy Resv message upstream, a Receiver Proxy When generating a proxy Resv message upstream, a Receiver Proxy
supporting dynamic discovery of downstream RSVP functionality MUST supporting dynamic discovery of downstream RSVP functionality MUST
forward the Path message downstream instead of terminating it (unless forward the Path message downstream instead of terminating it (unless
dynamic discovery of downstream RSVP functionality is explicitely dynamic discovery of downstream RSVP functionality is explicitly
disabled). If the destination endpoint supports RSVP (or there is disabled). If the destination endpoint supports RSVP (or there is
another Receiver Proxy downstream), it will receive the Path and another Receiver Proxy downstream), it will receive the Path and
generate a Resv upstream. When this Resv message reaches the generate a Resv upstream. When this Resv message reaches the
Receiver Proxy, it recognizes the presence of a RSVP-capable receiver Receiver Proxy, it recognizes the presence of an RSVP-capable
(or of another RSVP Receiver Proxy) downstream and MUST internally receiver (or of another RSVP Receiver Proxy) downstream and MUST
converts its state from a proxied reservation to a regular midpoint internally convert its state from a proxied reservation to a regular
RSVP behavior. From then on, the RSVP router MUST behave as a midpoint RSVP behavior. From then on, the RSVP router MUST behave as
regular RSVP router for that reservation (i.e. As if the RSVP router a regular RSVP router for that reservation (i.e., as if the RSVP
never behaved as an RSVP receiver proxy for that flow). This method router never behaved as an RSVP Receiver Proxy for that flow). This
is illustrated in Figure 6. method is illustrated in Figure 6.
|****| *** |**********| |----| |****| *** |**********| |----|
| S |---------*r*---------| RSVP |---| R1 | | S |---------*r*---------| RSVP |---| R1 |
|****| *** | Receiver | |----| |****| *** | Receiver | |----|
| Proxy | | Proxy |
| | | |
| | |****| | | |****|
| |------------| R2 | | |------------| R2 |
|**********| |****| |**********| |****|
skipping to change at page 28, line 4 skipping to change at page 25, line 46
*** ***
*r* regular RSVP *r* regular RSVP
*** router *** router
(R1) = Path message contains a Session object whose destination is R1 (R1) = Path message contains a Session object whose destination is R1
***> media flow ***> media flow
==> segment of flow path protected by RSVP reservation ==> segment of flow path protected by RSVP reservation
Figure 6: Dynamic Discovery of Downstream RSVP Functionality Figure 6: Dynamic Discovery of Downstream RSVP Functionality
If there is no RSVP-capable receiver (or other Receiver Proxy) If there is no RSVP-capable receiver (or other Receiver Proxy)
downstream of the Receiver Proxy, then the Path messages sent by the downstream of the Receiver Proxy, then the Path messages sent by the
Receiver Proxy every RSVP refresh interval (e.g. 30 seconds by Receiver Proxy every RSVP refresh interval (e.g., 30 seconds by
default) will never be responded to. However, these messages consume default) will never be responded to. However, these messages consume
a small amount of bandwidth, and in addition would install some RSVP a small amount of bandwidth, and in addition would install some RSVP
state on RSVP-capable midpoint nodes downstream of the first Receiver state on RSVP-capable midpoint nodes downstream of the first Receiver
Proxy. This is seen as a very minor sub-optimality, however, to Proxy. This is seen as a very minor sub-optimality; however, to
mitigate this, the Receiver Proxy MAY tear down any unanswered mitigate this, the Receiver Proxy MAY tear down any unanswered
downstream Path state after a predetermined time (that SHOULD be downstream Path state after a predetermined time (that SHOULD be
greater or equal to the Path refresh interval), and MAY stop sending greater or equal to the Path refresh interval), and MAY stop sending
Path messages for the flow (or MAY only send them at much lower Path messages for the flow (or MAY only send them at much lower
frequency). frequency).
This approach only requires support of the behavior described in the This approach only requires support of the behavior described in the
previous paragraph and does not require any new RSVP extensions. previous paragraph and does not require any new RSVP extensions.
4.2. Receiver Proxy Control Policy Element 4.2. Receiver Proxy Control Policy Element
[RFC2750] defines extensions for supporting generic policy based [RFC2750] defines extensions for supporting generic policy-based
admission control in RSVP. These extensions include the standard admission control in RSVP. These extensions include the standard
format of POLICY_DATA objects and a description of RSVP handling of format of POLICY_DATA objects and a description of RSVP handling of
policy events. policy events.
The POLICY_DATA object contains one or more of Policy Elements, each The POLICY_DATA object contains one or more policy elements, each
representing a different (and perhaps orthogonal) policy. As an representing a different (and perhaps orthogonal) policy. As an
example, [RFC3181] specifies the Preemption Priority Policy Element. example, [RFC3181] specifies the preemption priority policy element.
The present document defines a new Policy Element called the Receiver This document defines a new policy element called the Receiver Proxy
Proxy Control Policy Element. The present document only defines the Control policy element. This document only defines the use of this
use of this Policy Element in Path messages and for unicast policy element in Path messages and for unicast reservations. Other
reservations. Other usage are outside the scope of the present usage is outside the scope of this document.
document.
The format of the Receiver Proxy Control Policy Element is as shown The format of the Receiver Proxy Control policy element is as shown
in Figure 7: in Figure 7:
0 0 0 1 1 2 2 3 0 0 0 1 1 2 2 3
0 . . . 7 8 . . . 5 6 . . . 3 4 . . . 1 0 . . . 7 8 . . . 5 6 . . . 3 4 . . . 1
+-------------+-------------+-------------+-------------+ +-------------+-------------+-------------+-------------+
| Length | P-Type=REC_PROXY_CONTROL | | Length | P-Type=REC_PROXY_CONTROL |
+-------------+-------------+-------------+-------------+ +-------------+-------------+-------------+-------------+
| Reserved |Control-Value| | Reserved |Control-Value|
+---------------------------+---------------------------+ +---------------------------+---------------------------+
Figure 7: Receiver Proxy Control Policy Element Figure 7: Receiver Proxy Control Policy Element
where: where:
o Length: 16 bits o Length: 16 bits
* Always 8. The overall length of the policy element, in bytes. * Always 8. The overall length of the policy element, in bytes.
o P-Type: 16 bits o P-Type: 16 bits
* REC_PROXY_CONTROL = To be allocated by IANA (see "IANA * REC_PROXY_CONTROL = 0x07 (see the "IANA Considerations"
Considerations" section) section).
o Reserved: 24 bits o Reserved: 24 bits
* SHALL be set to zero on transmit and SHALL be ignored on * SHALL be set to zero on transmit and SHALL be ignored on
reception reception.
o Control-Value: 8 bits (unsigned) o Control-Value: 8 bits (unsigned)
* 0 (Reserved). An RSVP Receiver Proxy that understands this * 0 (Reserved): An RSVP Receiver Proxy that understands this
policy element MUST ignore the policy element if its Control- policy element MUST ignore the policy element if its Control-
Value is set to that value. Value is set to that value.
* 1 (Receiver-Proxy-Needed): An Receiver Proxy that understands * 1 (Receiver-Proxy-Needed): An RSVP Receiver Proxy that
this policy element MUST attempt to insert itself as a Receiver understands this policy element MUST attempt to insert itself
Proxy for that flow if the corresponding Path message contains as a Receiver Proxy for that flow if the corresponding Path
this Control-Value. If the Receiver Proxy also supports message contains this Control-Value. If the Receiver Proxy
dynamic discovery of downstream RSVP functionality as specified also supports dynamic discovery of downstream RSVP
in Section 4.1, it MUST still send the Path message downstream functionality as specified in Section 4.1, it MUST still send
and attempt to extend the reservation downstream so that the the Path message downstream and attempt to extend the
reservation can be extended to the last Receiver Proxy). An reservation downstream so that the reservation can be extended
RSVP sender MAY insert the Receiver Proxy Control Policy to the last Receiver Proxy). An RSVP sender MAY insert the
Element with this Control-Value when it knows (say by other Receiver Proxy Control policy element with this Control-Value
means such as application-level signalling) that the receiver when it knows (say, by other means, such as application-level
is not RSVP capable. signaling) that the receiver is not RSVP-capable.
* 2 (Receiver-Proxy-Not-Needed): An Receiver Proxy that * 2 (Receiver-Proxy-Not-Needed): An RSVP Receiver Proxy that
understands this policy element MUST NOT attempt to insert understands this policy element MUST NOT attempt to insert
itself as a Receiver Proxy for that flow if the corresponding itself as a Receiver Proxy for that flow if the corresponding
Path message contains this Control-Value. An RSVP sender MAY Path message contains this Control-Value. An RSVP sender MAY
insert the Receiver Proxy Control Policy Element with this insert the Receiver Proxy Control policy element with this
Control-Value when it knows (say by other means such as Control-Value when it knows (say, by other means, such as
application-level signalling) that the receiver is RSVP application-level signaling) that the receiver is RSVP-capable.
capable.
Figure 8 illustrates the method based on the Receiver Proxy Control Figure 8 illustrates the method based on the Receiver Proxy Control
Policy Element and allowing a sender to control whether an RSVP policy element that allows a sender to control whether or not an RSVP
router supporting the Path-triggered Receiver Proxy function is to router supporting the Path-Triggered Receiver Proxy function is to
behave as a Receiver Proxy for a given flow or not. behave as a Receiver Proxy for a given flow.
|****| *** |**********| |----| |****| *** |**********| |----|
| S |---------*r*---------| RSVP |---| R1 | | S |---------*r*---------| RSVP |---| R1 |
|****| *** | Receiver | |----| |****| *** | Receiver | |----|
| Proxy | | Proxy |
| | | |
| | |****| | | |****|
| |------------| R2 | | |------------| R2 |
|**********| |****| |**********| |****|
skipping to change at page 31, line 6 skipping to change at page 28, line 41
|****| RSVP-capable |----| non-RSVP-capable |****| RSVP-capable |****| RSVP-capable |----| non-RSVP-capable |****| RSVP-capable
| S | Sender | R | Receiver | R | Receiver | S | Sender | R | Receiver | R | Receiver
|****| |----| |****| |****| |----| |****|
*** ***
*r* regular RSVP *r* regular RSVP
*** router *** router
(R1) = Path message contains a Session object whose destination is R1 (R1) = Path message contains a Session object whose destination is R1
(N) = Path message contains a Receiver Proxy Control Policy Element (N) = Path message contains a Receiver Proxy Control policy element
whose Control-Value is set to Receiver-Proxy-Needed whose Control-Value is set to Receiver-Proxy-Needed
(NN) = Path message contains a Receiver Proxy Control Policy Element (NN) = Path message contains a Receiver Proxy Control policy element
whose Control-Value is set to Receiver-Proxy-Not-Needed whose Control-Value is set to Receiver-Proxy-Not-Needed
***> media flow ***> media flow
==> segment of flow path protected by RSVP reservation ==> segment of flow path protected by RSVP reservation
Figure 8: Receiver Proxy Control by Sender Figure 8: Receiver Proxy Control by Sender
4.2.1. Default Handling 4.2.1. Default Handling
As specified in section 4.2 of [RFC2750], Policy Ignorant Nodes As specified in Section 4.2 of [RFC2750], Policy-Ignorant Nodes
(PINs) implement a default handling of POLICY_DATA objects ensuring (PINs) implement a default handling of POLICY_DATA objects ensuring
that those objects can traverse PIN nodes in transit from one Policy that those objects can traverse PINs in transit from one Policy
Enforcement Point (PEP) to another. This applies to the situations Enforcement Point (PEP) to another. This applies to the situations
where POLICY_DATA objects contain the Receiver Proxy Control Policy in which POLICY_DATA objects contain the Receiver Proxy Control
Element specified in this document, so that those can traverse PIN policy element specified in this document, so that those objects can
nodes. traverse PINs.
Section 4.2 of [RFC2750] also defines a similar default behavior for Section 4.2 of [RFC2750] also defines a similar default behavior for
policy-capable nodes that do not recognized a particular Policy policy-capable nodes that do not recognize a particular policy
Element. This applies to the Receiver Proxy Control Policy Element element. This applies to the Receiver Proxy Control policy element
specified in this document, so that those can traverse policy-capable specified in this document, so that messages carrying the element can
nodes that do not support this document. traverse policy-capable nodes that do not support the extensions
described in this document.
5. Security Considerations 5. Security Considerations
As this document defines extensions to RSVP, the security As this document defines extensions to RSVP, the security
considerations of RSVP apply. Those are discussed in [RFC2205], considerations of RSVP apply, which are discussed in [RFC2205],
[RFC4230] and [I-D.ietf-tsvwg-rsvp-security-groupkeying]. Approaches [RFC4230], and [SEC-GRP-KEY]. Approaches for addressing those
for addressing those concerns are discussed further below. concerns are discussed further below.
The RSVP Authentication mechanisms defined in [RFC2747] and [RFC3097] The RSVP authentication mechanisms defined in [RFC2747] and [RFC3097]
protect RSVP message integrity hop-by-hop and provide node protect RSVP message integrity hop-by-hop and provide node
authentication as well as replay protection, thereby protecting authentication as well as replay protection, thereby protecting
against corruption and spoofing of RSVP messages. These hop-by-hop against corruption and spoofing of RSVP messages. These hop-by-hop
integrity mechanisms can be used to protect RSVP reservations integrity mechanisms can be used to protect RSVP reservations
established using an RSVP receiver proxy in accordance with the established using an RSVP Receiver Proxy in accordance with this
present document. [I-D.ietf-tsvwg-rsvp-security-groupkeying] document. [SEC-GRP-KEY] discusses key types and key provisioning
discusses key types and key provisioning methods as well as their methods as well as their respective applicability to RSVP
respective applicability to RSVP authentication. RSVP Authentication authentication. RSVP authentication (defined in [RFC2747] and
(defined in [RFC2747] and [RFC3097]) SHOULD be supported by an [RFC3097]) SHOULD be supported by an implementation of this document.
implementation of the present document.
[I-D.ietf-tsvwg-rsvp-security-groupkeying] also discusses [SEC-GRP-KEY] also discusses applicability of IPsec mechanisms
applicability of IPsec mechanisms ([RFC4302], [RFC4303]) and ([RFC4302], [RFC4303]) and associated key provisioning methods for
associated key provisioning methods for security protection of RSVP. security protection of RSVP. This discussion applies to the
This discussion applies to the protection of RSVP in the presence of protection of RSVP in the presence of Path-Triggered RSVP Receiver
Path-triggered RSVP Receiver Proxies as defined in the present Proxies as defined in this document.
document.
A subset of RSVP messages are signaled with the router alert option A subset of RSVP messages are signaled with the IP router alert
([RFC2113],[RFC2711]). Based on the current security concerns option ([RFC2113], [RFC2711]). Based on the current security
associated with the use of the IP router alert option, the concerns associated with the use of the IP router alert option, the
applicability of RSVP (and therefore of the RSVP Proxy approaches applicability of RSVP (and therefore of the RSVP Proxy approaches
discussed in the present document) is limited to controlled discussed in this document) is limited to controlled environments
environments (i.e. Environments where the security risks associated (i.e., where the security risks associated with the use of the IP
with the use of the router alert option are understood and protected router alert option are understood and protected against). The
against). The security aspects and common practices around the use security aspects and common practices around the use of the current
of the current IP router alert option and consequences of using the IP router alert option, and consequences of using the IP router alert
IP router alert option by applications such as RSVP are discussed in option by applications such as RSVP, are discussed in detail in
details in [I-D.rahman-rtg-router-alert-considerations]. [RTR-ALERT].
When an RSVP receiver proxy is used, the RSVP reservation is no When an RSVP Receiver Proxy is used, the RSVP reservation is no
longer controlled by the receiver, but rather is controlled by the longer controlled by the receiver, but rather is controlled by the
receiver proxy (using hints received from the sender in the Path Receiver Proxy (using hints received from the sender in the Path
message) on behalf of the sender. Thus, the receiver proxy ought to message) on behalf of the sender. Thus, the Receiver Proxy ought to
be trusted by the end-systems to control the RSVP reservation be trusted by the end-systems to control the RSVP reservation
appropriately. However, basic RSVP operation already assumes a trust appropriately. However, basic RSVP operation already assumes a trust
model where end-systems trust RSVP nodes to appropriately perform model where end-systems trust RSVP nodes to appropriately perform
RSVP reservations. So the use of RSVP receiver proxy is not seen as RSVP reservations. So the use of an RSVP Receiver Proxy is not seen
introducing any significant additional security threat or as 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 in which the use of an RSVP Receiver
reduces the security risks. One example is where a network operator Proxy reduces the security risks. One example is where a network
relies on RSVP to perform resource reservation and admission control operator relies on RSVP to perform resource reservation and admission
within a network and where RSVP senders and RSVP routers are located control within a network and where RSVP senders and RSVP routers are
in the operator premises while the many RSVP receivers are located in located in the operator's premises, while the many RSVP receivers are
the operator's customers premises. Such an environment is further located in the operator's customers' premises. Such an environment
illustrated in "Annex A.1. RSVP-based VoD Admission Control in is further illustrated in Appendix A.1, "RSVP-Based VoD Admission
Broadband Aggregation Networks" of Control in Broadband Aggregation Networks", of [RFC5945]. From the
[I-D.ietf-tsvwg-rsvp-proxy-approaches]. From the operator's operator's perspective, the RSVP routers and RSVP senders are in
perspective, the RSVP routers and RSVP senders are in physically physically secured locations and therefore exposed to a lower risk of
secured locations and therefore exposed to a lower risk of being being tampered with, while the receivers are in locations that are
tampered with; While the receivers are in locations that are
physically unsecured and therefore subject to a higher risk of being physically unsecured and therefore subject to a higher risk of being
tampered with. The use of an RSVP receiver proxy function 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
discarding any RSVP message received from end-users. This provides a network, discarding any RSVP message received from end-users. This
very simple and effective protection of the RSVP reservation and provides a very simple and effective protection of the RSVP
admission control solution operating inside the operator's network. reservation and admission control solution operating inside the
operator's network.
5.1. Security Considerations for the Sender Notification via Notify 5.1. Security Considerations for the Sender Notification via Notify
Message Message
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 use of message can be sent in a non-hop-by-hop fashion that precludes the
RSVP hop-by-hop integrity and authentication model. The approaches use of the RSVP hop-by-hop integrity and authentication model. The
and considerations for addressing this issue presented in the approaches and considerations for addressing this issue presented in
Security Considerations section of [RFC3473] apply. In particular, the Security Considerations section of [RFC3473] apply. In
where the Notify messages are transmitted non-hop-by-hop and the same particular, where the Notify messages are transmitted non-hop-by-hop
level of security provided by [RFC2747] is desired, IPsec-based and the same level of security provided by [RFC2747] is desired,
integrity and authentication can be used ([RFC4302] or [RFC4303]). IPsec-based integrity and authentication can be used ([RFC4302] or
Alternatively, the sending of non-hop-by-hop Notify messages can be [RFC4303]). Alternatively, the sending of non-hop-by-hop Notify
disabled. Finally, [I-D.ietf-tsvwg-rsvp-security-groupkeying] messages can be disabled. Finally, [SEC-GRP-KEY] discusses the
discusses applicability of group keying for non-hop-by-hop Notify applicability of group keying for non-hop-by-hop Notify messages.
messages.
5.2. Security Considerations for the Receiver Proxy Control Policy 5.2. Security Considerations for the Receiver Proxy Control Policy
Element Element
This document also defines inSection 4.2 the optional Receiver Proxy This document also defines, in Section 4.2, the optional Receiver
Control Policy Element. Policy Elements are signaled by RSVP through Proxy Control policy element. Policy elements are signaled by RSVP
encapsulation in a Policy Data object as defined in [RFC2750]. through encapsulation in a Policy Data object as defined in
Therefore, like any other Policy Elements, the integrity of the [RFC2750]. Therefore, like any other policy elements, the integrity
Receiver Proxy Control Policy Element can be protected as discussed of the Receiver Proxy Control policy element can be protected as
in section 6 of [RFC2750] by two optional security mechanisms. discussed in Section 6 of [RFC2750] by two optional security
mechanisms.
The first mechanism relies on the RSVP Authentication discussed above The first mechanism relies on the RSVP authentication discussed above
that provides a chain of trust when all RSVP nodes are policy that provides a chain of trust when all RSVP nodes are policy
capable. With this mechanism, the INTEGRITY object is carried inside capable. With this mechanism, the INTEGRITY object is carried inside
RSVP messages. RSVP messages.
The second mechanism relies on the INTEGRITY object within the The second mechanism relies on the INTEGRITY object within the
POLICY_DATA object to guarantee integrity between RSVP Policy POLICY_DATA object to guarantee integrity between RSVP Policy
Enforcement Points (PEPs) that are not RSVP neighbors. This is Enforcement Points (PEPs) that are not RSVP neighbors. This is
useful only when some RSVP nodes are Policy Ignorant Nodes (PINs). useful only when some RSVP nodes are Policy-Ignorant Nodes (PINs).
The INTEGRITY object within the POLICY_DATA object MAY be supported The INTEGRITY object within the POLICY_DATA object MAY be supported
by an implementation of the present document. by an implementation of this document.
Details for computation of the content of the INTEGRITY object can be Details for the computation of the content of the INTEGRITY object
found in Appendix B of [RFC2750]. This states that the Policy can be found in Appendix B of [RFC2750]. This states that the Policy
Decision Point (PDP), at its discretion, and based on destination Decision Point (PDP), at its discretion, and based on destination
PEP/PDP or other criteria, selects an Authentication Key and the hash PEP/PDP or other criteria, selects an Authentication Key and the hash
algorithm to be used. Keys to be used between PDPs can be algorithm to be used. Keys to be used between PDPs can be
distributed manually or via standard key management protocol for distributed manually or via a standard key management protocol for
secure key distribution. secure key distribution.
Note that where non-RSVP hops may exist in between RSVP hops, as well Note that where non-RSVP hops may exist in between RSVP hops, as well
as where RSVP capable Policy Ignorant Nodes (PINs) may exist in as where RSVP-capable Policy-Ignorant Nodes (PINs) may exist in
between PEPs, it may be difficult for the PDP to determine what is between PEPs, it may be difficult for the PDP to determine what the
the destination PDP for a POLICY_DATA object contained in some RSVP destination PDP is for a POLICY_DATA object contained in some RSVP
messages (such as a Path message). This is because in those cases messages (such as a Path message). This is because in those cases,
the next PEP is not known at the time of forwarding the message. In the next PEP is not known at the time of forwarding the message. In
this situation, key shared across multiple PDPs may be used. This is this situation, a key shared across multiple PDPs may be used. This
conceptually similar to the use of key shared across multiple RSVP is conceptually similar to the use of a key shared across multiple
neighbors discussed in [I-D.ietf-tsvwg-rsvp-security-groupkeying]. RSVP neighbors, as discussed in [SEC-GRP-KEY]. We also observe that
We observe also that this issue may not exist in some deployment this issue may not exist in some deployment scenarios where a single
scenarios where a single (or low number of) PDP is used to control PDP (or a low number of PDPs) is used to control all the PEPs of a
all the PEPs of a region (such as an administrative domain). In such region (such as an administrative domain). In such scenarios, it may
scenarios, it may be easy for a PDP to determine what is the next hop be easy for a PDP to determine what the next-hop PDP is, even when
PDP, even when the next hop PEP is not known, simply by determining the next-hop PEP is not known, simply by determining what the next
what is the next region that will be traversed (say based on the region is that will be traversed (say, based on the destination
destination address). address).
6. IANA Considerations 6. IANA Considerations
6.1. RSVP Error Codes 6.1. RSVP Error Codes
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, IANA has updated the existing entries
updates the existing entries for these two Error Codes under the for these two error codes under the "Error Codes and Globally-Defined
"Error Codes and Globally-Defined Error Value Sub-Codes" registry. Error Value Sub-Codes" registry. Each entry refers to this document,
Each entry should refer to this document, in addition to referring to in addition to referring to [RFC2205]. Specifically, the entry for
[RFC2205]. Specifically, the entry for Error Code 1 and Error Code 2 Error Code 1 and Error Code 2 read:
should respectively read:
"
1 Admission Control Failure [RFC2205] [RFCXXX]
...
2 Policy Control Failure [RFC2205] [RFCXXX]
...
"
where [RFCXXX] refers to this document.
This document also requires that IANA allocates a new RSVP Error Code
"<TBD>: Unrecoverable Receiver Proxy Error", as discussed in
Section 3.1.2. This Error Code is to be allocated under the "Error
Codes and Globally-Defined Error Value Sub-Codes" registry. The
entry for this error code should read:
" 1 Admission Control Failure [RFC2205] [RFC5946]
TBD Unrecoverable Receiver Proxy Error [RFCXXX] 2 Policy Control Failure [RFC2205] [RFC5946]
The sixteen bits of the Error Value field are defined in [RFCXXX] IANA has also allocated a new RSVP Error Code "36;: Unrecoverable
Receiver Proxy Error", as discussed in Section 3.1.2. This error
code has been allocated under the "Error Codes and Globally-Defined
Error Value Sub-Codes" registry. The entry for this error code
reads:
" 36 Unrecoverable Receiver Proxy Error [RFC5946]
where [RFCXXX] refers to this document and TBD is the value to be The sixteen bits of the Error Value field are defined in [RFC5946]
allocated by IANA.
6.2. Policy Element 6.2. Policy Element
This document defines in Section 4.2 a new Policy Element called the This document defines, in Section 4.2, a new policy element called
Receiver Proxy Control Policy Element. As specified in [RFC2750], the Receiver Proxy Control policy element. As specified in
Standard RSVP Policy Elements (P-type values) are to be assigned by [RFC2750], standard RSVP policy elements (P-Type values) are to be
IANA as per "IETF Consensus" policy following the policies outlined assigned by IANA as per "IETF Consensus" policy following the
in [RFC2434] (this policy is now called "IETF Review" as per policies outlined in [RFC2434] (this policy is now called "IETF
[RFC5226]) . Review" as per [RFC5226]).
Thus, this document requires that IANA allocates one P-Type to the Thus, IANA has allocated one P-Type to the Receiver Proxy Control
Receiver Proxy Control Policy Element from the Standard RSVP Policy policy element from the standard RSVP policy element range.
Element range.
In Section 4.2, the present document defines a Control-Value field In Section 4.2, this document defines a Control-Value field inside
inside the Receiver Proxy Control Policy Element. IANA needs to the Receiver Proxy Control policy element. IANA has created the
create a registry for this field and allocate the following values: "Receiver Proxy Control Policy Element (P-Type 0x07) Control-Value
field" registry and allocated the following values:
o 0 : Reserved o 0 : Reserved
o 1 : Receiver-Proxy-Needed o 1 : Receiver-Proxy-Needed
o 2 : Receiver-Proxy-Not-Needed o 2 : Receiver-Proxy-Not-Needed
Following the policies outlined in [RFC5226], numbers in the range Following the policies outlined in [RFC5226], numbers in the range
3-127 are allocated according to the "IETF Review" policy, numbers in 3-127 are allocated according to the "IETF Review" policy, numbers in
the range 128-240 as "First Come First Served" and numbers between the range 128-240 are assigned on a "First Come First Served" basis,
241-255 are reserved for "Private Use". and numbers in the range 241-255 are reserved for "Private Use".
7. Acknowledgments 7. Acknowledgments
This document benefited from discussions with Carol Iturralde and This document benefited from discussions with Carol Iturralde and
Anca Zamfir. Lou Berger, Adrian Farrel and John Drake provided Anca Zamfir. Lou Berger, Adrian Farrel, and John Drake provided
review and guidance, in particular on the usage of the review and guidance, in particular on the usage of the
Path_State_Removed flag and of the Notify message, both borrowed from Path_State_Removed flag and of the Notify message, both borrowed from
[RFC3473]. We also thank Stephen Kent, Ken Carlberg and Tim Polk for [RFC3473]. We also thank Stephen Kent, Ken Carlberg, and Tim Polk
their valuable input and proposed enhancements. Finally we thank for their valuable input and proposed enhancements. Finally, we
Cullen Jennings, Magnus Westerlund and Robert Sparks for stimulating thank Cullen Jennings, Magnus Westerlund, and Robert Sparks for
the work on extensions maximizing the reservation span and stimulating the work on extensions maximizing the reservation span
facilitating migration from Proxy model to end-to-end RSVP model. and facilitating migration from the Proxy model to the end-to-end
RSVP model.
8. References 8. References
8.1. Normative References 8.1. Normative References
[RFC2113] Katz, D., "IP Router Alert Option", RFC 2113, [RFC2113] Katz, D., "IP Router Alert Option", RFC 2113,
February 1997. February 1997.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2205] Braden, B., Zhang, L., Berson, S., Herzog, S., and S. [RFC2205] Braden, B., Zhang, L., Berson, S., Herzog, S., and S.
Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 Jamin, "Resource ReSerVation Protocol (RSVP) -- Version
Functional Specification", RFC 2205, September 1997. 1 Functional Specification", RFC 2205, September 1997.
[RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing
IANA Considerations Section in RFCs", BCP 26, RFC 2434, an IANA Considerations Section in RFCs", BCP 26,
October 1998. RFC 2434, October 1998.
[RFC2711] Partridge, C. and A. Jackson, "IPv6 Router Alert Option", [RFC2711] Partridge, C. and A. Jackson, "IPv6 Router Alert
RFC 2711, October 1999. Option", RFC 2711, October 1999.
[RFC2747] Baker, F., Lindell, B., and M. Talwar, "RSVP Cryptographic [RFC2747] Baker, F., Lindell, B., and M. Talwar, "RSVP
Authentication", RFC 2747, January 2000. Cryptographic Authentication", RFC 2747, January 2000.
[RFC2750] Herzog, S., "RSVP Extensions for Policy Control", [RFC2750] Herzog, S., "RSVP Extensions for Policy Control",
RFC 2750, January 2000. RFC 2750, January 2000.
[RFC3097] Braden, R. and L. Zhang, "RSVP Cryptographic [RFC3097] Braden, R. and L. Zhang, "RSVP Cryptographic
Authentication -- Updated Message Type Value", RFC 3097, Authentication -- Updated Message Type Value",
April 2001. RFC 3097, April 2001.
[RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan,
and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP V., and G. Swallow, "RSVP-TE: Extensions to RSVP for
Tunnels", RFC 3209, December 2001. LSP 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, [RFC4302] Kent, S., "IP Authentication Header", RFC 4302,
December 2005. 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.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing
IANA Considerations Section in RFCs", BCP 26, RFC 5226, an IANA Considerations Section in RFCs", BCP 26,
May 2008. RFC 5226, May 2008.
8.2. Informative References 8.2. Informative References
[I-D.ietf-tsvwg-rsvp-proxy-approaches] [RFC3181] Herzog, S., "Signaled Preemption Priority Policy
Faucheur, F., Guillou, A., Manner, J., and D. Wing, "RSVP Element", RFC 3181, October 2001.
Proxy Approaches",
draft-ietf-tsvwg-rsvp-proxy-approaches-08 (work in
progress), October 2009.
[I-D.ietf-tsvwg-rsvp-security-groupkeying] [RFC4230] Tschofenig, H. and R. Graveman, "RSVP Security
Behringer, M. and F. Faucheur, "Applicability of Keying Properties", RFC 4230, December 2005.
Methods for RSVP Security",
draft-ietf-tsvwg-rsvp-security-groupkeying-05 (work in
progress), June 2009.
[I-D.rahman-rtg-router-alert-considerations] [RFC5945] Le Faucheur, F., Manner, J., Wing, D., and A. Guillou,
Faucheur, F., "IP Router Alert Considerations and Usage", "Resource Reservation Protocol (RSVP) Proxy
draft-rahman-rtg-router-alert-considerations-03 (work in Approaches", RFC 5945, October 2010.
progress), October 2009.
[RFC3181] Herzog, S., "Signaled Preemption Priority Policy Element", [RTR-ALERT] Le Faucheur, F., "IP Router Alert Considerations and
RFC 3181, October 2001. Usage", Work in Progress, October 2009.
[RFC4230] Tschofenig, H. and R. Graveman, "RSVP Security [SEC-GRP-KEY] Behringer, M. and F. Le Faucheur, "Applicability of
Properties", RFC 4230, December 2005. Keying Methods for RSVP Security", Work in Progress,
June 2010.
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
Email: flefauch@cisco.com EMail: flefauch@cisco.com
Jukka Manner Jukka Manner
Helsinki University of Technology (TKK) Aalto University
P.O. Box 3000 Department of Communications and Networking (Comnet)
Espoo FIN-02015 TKK P.O. Box 13000
FIN-00076 Aalto
Finland Finland
Phone: +358 9 470 22481
Phone: +358 9 451 2481 EMail: jukka.manner@tkk.fi
Email: jukka.manner@tkk.fi
URI: http://www.netlab.tkk.fi/~jmanner/ URI: http://www.netlab.tkk.fi/~jmanner/
Ashok Narayanan Ashok Narayanan
Cisco Systems Cisco Systems
300 Beaver Brook Road 300 Beaver Brook Road
Boxborough, MAS 01719 Boxborough, MA 01719
United States United States
EMail: ashokn@cisco.com
Email: ashokn@cisco.com
Allan Guillou Allan Guillou
SFR SFR
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@sfr.com
Email: allan.guillou@sfr.com
Hemant Malik Hemant Malik
Bharti Airtel Ltd. Bharti Airtel, Ltd.
4th Floor, Tower A, Unitech Cyber Park 4th Floor, Plot No. 16
Gurgaon, Sector 39, 122001 Udyog Vihar, Phase IV
Gurgaon, 122015
India India
EMail: Hemant.Malik@airtel.in
Email: Hemant.Malik@airtel.in
 End of changes. 204 change blocks. 
601 lines changed or deleted 563 lines changed or added

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