draft-ietf-tsvwg-rsvp-proxy-proto-01.txt   draft-ietf-tsvwg-rsvp-proxy-proto-02.txt 
TSVWG F. Le Faucheur TSVWG F. Le Faucheur
Internet-Draft Cisco Internet-Draft Cisco
Intended status: Standards Track J. Manner Intended status: Standards Track J. Manner
Expires: December 28, 2007 University of Helsinki Expires: April 13, 2008 University of Helsinki
A. Narayanan A. Narayanan
Cisco Cisco
A. Guillou A. Guillou
Neuf Neuf
H. Malik H. Malik
Bharti Bharti
June 26, 2007 October 11, 2007
RSVP Extensions for Path-Triggered RSVP Receiver Proxy RSVP Extensions for Path-Triggered RSVP Receiver Proxy
draft-ietf-tsvwg-rsvp-proxy-proto-01.txt draft-ietf-tsvwg-rsvp-proxy-proto-02.txt
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 41 skipping to change at page 1, line 41
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on December 28, 2007. This Internet-Draft will expire on April 13, 2008.
Copyright Notice Copyright Notice
Copyright (C) The IETF Trust (2007). Copyright (C) The IETF Trust (2007).
Abstract Abstract
RSVP signaling can be used to make end-to-end resource reservations RSVP signaling can be used to make end-to-end resource reservations
in an IP network in order to guarantee the QoS required by certain in an IP network in order to guarantee the QoS required by certain
flows. With conventional RSVP, both the data sender and receiver of flows. With conventional RSVP, both the data sender and receiver of
skipping to change at page 3, line 11 skipping to change at page 3, line 11
an RSVP Receiver Proxy whose signaling is triggered by receipt of an RSVP Receiver Proxy whose signaling is triggered by receipt of
RSVP Path messages from the sender. This document specifies these RSVP Path messages from the sender. This document specifies these
extensions. extensions.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Conventions Used in This Document . . . . . . . . . . . . 5 1.1. Conventions Used in This Document . . . . . . . . . . . . 5
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6
3. RSVP Extensions for Sender Notification . . . . . . . . . . . 7 3. RSVP Extensions for Sender Notification . . . . . . . . . . . 7
3.1. Sender Notification via PathErr Message . . . . . . . . . 9 3.1. Sender Notification via PathErr Message . . . . . . . . . 10
3.1.1. Composition of SESSION and <Sender descriptor> . . . . 12 3.1.1. Composition of SESSION and <Sender descriptor> . . . . 12
3.1.2. Composition of ERROR_SPEC . . . . . . . . . . . . . . 13 3.1.2. Composition of ERROR_SPEC . . . . . . . . . . . . . . 13
3.1.3. Use of Path_State_Removed Flag . . . . . . . . . . . . 14 3.1.3. Use of Path_State_Removed Flag . . . . . . . . . . . . 14
3.1.4. Use of PathErr by Regular Receivers . . . . . . . . . 15 3.1.4. Use of PathErr by Regular Receivers . . . . . . . . . 15
3.2. Sender Notification via Notify Message . . . . . . . . . . 15 3.2. Sender Notification via Notify Message . . . . . . . . . . 16
4. Security Considerations . . . . . . . . . . . . . . . . . . . 18 4. Security Considerations . . . . . . . . . . . . . . . . . . . 19
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22
6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 21 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 23
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 22 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 24
7.1. Normative References . . . . . . . . . . . . . . . . . . . 22 7.1. Normative References . . . . . . . . . . . . . . . . . . . 24
7.2. Informative References . . . . . . . . . . . . . . . . . . 22 7.2. Informative References . . . . . . . . . . . . . . . . . . 24
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 23 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 25
Intellectual Property and Copyright Statements . . . . . . . . . . 25 Intellectual Property and Copyright Statements . . . . . . . . . . 27
1. Introduction 1. Introduction
Guaranteed QoS for some applications with tight Qos requirements may Guaranteed QoS for some applications with tight Qos requirements may
be achieved by reserving resources in each node on the end-to-end be achieved by reserving resources in each node on the end-to-end
path. The main IETF protocol for these resource reservations is RSVP path. The main IETF protocol for these resource reservations is RSVP
specified in [RFC2205]. RSVP does not require that all intermediate specified in [RFC2205]. RSVP does not require that all intermediate
nodes support RSVP, however 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. There are environments where receiver of the data flow support RSVP. However, there are
it would be useful to be able to reserve resources for a flow on at environments where it would be useful to be able to reserve resources
least a subset of the flow path even when the sender or the receiver for a flow (at least a subset of the flow path) even when the sender
(or both) is not RSVP-capable. or the receiver (or both) is not RSVP-capable.
Since either the data sender or receiver may be unaware of RSVP, Since both the data sender and receiver may be unaware of RSVP, there
there are two distinct use cases. In the first case, an entity in are two distinct RSVP Proxy cases. In the first case, an entity in
the network must operate on behalf of the data sender, generate RSVP the network must operate on behalf of the data sender, generate RSVP
Path messages, and eventually receive, process and sink Resv Path messages, and eventually receive, process and sink Resv
messages. We refer to this entity as the RSVP Sender Proxy. In the messages. We refer to this entity as the RSVP Sender Proxy. In the
second case, an entity in the network must receive Path messages sent second case, an entity in the network must receive Path messages sent
by a data sender (or by an RSVP Sender Proxy), and reply to those by a data sender (or by an RSVP Sender Proxy), and reply to those
with Resv messages generated on behalf of the data receiver(s). We with Resv messages generated on behalf of the data receiver(s). We
refer to this entity as the RSVP Receiver Proxy. refer to this entity as the RSVP Receiver Proxy.
RSVP Proxy approaches are presented in RSVP Proxy approaches are presented in
[I-D.ietf-tsvwg-rsvp-proxy-approaches]. That document also [I-D.ietf-tsvwg-rsvp-proxy-approaches]. That document also
discusses, for each approach, how the reservations controlled by the discusses, for each approach, how the reservations controlled by the
RSVP Proxy can be synchronised with the application requirements RSVP Proxy can be synchronised with the application requirements
(e.g. when to establish, maintain, tear down the RSVP reservation to (e.g. when to establish, maintain and tear down the RSVP reservation
satisfy application requirements). to satisfy application requirements).
One RSVP Proxy approach is referred to as the Path-Triggered RSVP One RSVP Proxy approach is referred to as the Path-Triggered RSVP
Receiver Proxy approach. With this approach, the RSVP Receiver Proxy Receiver Proxy approach. With this approach, the RSVP Receiver Proxy
uses the RSVP Path messages generated by the sender as the cue for uses the RSVP Path messages generated by the sender (or RSVP Sender
establishing the RSVP reservation on behalf of the non-RSVP-capable Proxy) as the cue for establishing the RSVP reservation on behalf of
receiver. The RSVP Receiver Proxy is effectively acting as a slave the non-RSVP-capable receiver. The RSVP Receiver Proxy is
making reservations (on behalf of the receiver) under the sender's effectively acting as an intermediary making reservations (on behalf
control. This changes somewhat the usual RSVP reservation model of the receiver) under the sender's control (or RSVP Sender Proxy's
control). This changes somewhat the usual RSVP reservation model
where reservations are normally controlled by receivers. Such a where reservations are normally controlled by receivers. Such a
change greatly facilitates operations in the scenario of interest change greatly facilitates operations in the scenario of interest
here, which is where the receiver is not RSVP-capable. Indeed it here, which is where the receiver is not RSVP-capable. Indeed it
allows the RSVP Receiver Proxy to remain application unaware by allows the RSVP Receiver Proxy to remain application unaware by
taking advantage of the application awareness and RSVP awareness of taking advantage of the application awareness and RSVP awareness of
the sender. the sender (or RSVP Sender Proxy).
Since the synchronisation between RSVP reservation and application Since the synchronisation between RSVP reservation and application
requirement is now effectively performed by the sender, it is requirement is now effectively performed by the sender (or RSVP
important that the sender is aware of the reservation state. Sender Proxy), it is important that the sender (or RSVP Sender Proxy)
However, as conventional RSVP assumes that the reservation is to be is aware of the reservation state. However, as conventional RSVP
controlled by the receiver, some notifications about reservation assumes that the reservation is to be controlled by the receiver,
state (notably the error message sent in case of admission control some notifications about reservation state (notably the error message
rejection of the reservation) are only sent to the receiver. This sent in case of admission control rejection of the reservation) are
document specifies extension to RSVP procedures allowing such only sent towards the receiver and therefore, in our case, sunk by
notifications to be also conveyed to the sender. This facilitates the RSVP Receiver Proxy. This document specifies extension to RSVP
synchronization by the sender between RSVP reservation and procedures allowing such notifications to be also conveyed towards
application requirements in scenarios involving a Path-Triggered RSVP the sender. This facilitates synchronization by the sender (or RSVP
receiver Proxy. Sender Proxy) between RSVP reservation and application requirements
in scenarios involving a Path-Triggered RSVP receiver Proxy.
This document discusses extension to facilitate operations in the
presence of an RSVP Receiver Proxy. As explicitely pointed out in
the text above, those apply equally whether RSVP signaling is
initiated by a regular RSVP sender or by an RSVP Sender Proxy (with
some means to synchronize reservation state with application level
requirements that are outside the scope of this document). For
readability, the rest of this document discusses operation assuming a
regular RSVP sender; however, such operation is equallly applicable
where an RSVP Sender Proxy is used to initiated RSVP signaling on
behalf of a non-RSVP-capable sender.
1.1. Conventions Used in This Document 1.1. Conventions Used in This Document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
2. Terminology 2. Terminology
RSVP-capable (or RSVP-aware): which supports the RSVP protocol as per The following terminology is borrowed from
[I-D.ietf-tsvwg-rsvp-proxy-approaches] and is used extensively in the
present document:
o RSVP-capable (or RSVP-aware): supporting the RSVP protocol as per
[RFC2205] [RFC2205]
RSVP Receiver Proxy: an RSVP-capable router performing, on behalf of o RSVP Receiver Proxy: an RSVP-capable router performing, on behalf
a receiver, the RSVP operations which would normally be performed by of a receiver, the RSVP operations which would normally be
an RSVP-capable receiver if end-to-end RSVP signaling was used. Note performed by an RSVP-capable receiver if end-to-end RSVP signaling
that while RSVP is used upstream of the RSVP Receiver Proxy, RSVP is was used. Note that while RSVP is used upstream of the RSVP
not used downstream of the RSVP Receiver Proxy. Receiver Proxy, RSVP is not used downstream of the RSVP Receiver
Proxy.
RSVP Sender Proxy: an RSVP-capable router performing, on behalf of a o RSVP Sender Proxy: an RSVP-capable router performing, on behalf of
sender, the RSVP operations which would normally be performed by an a sender, the RSVP operations which would normally be performed by
RSVP-capable sender if end-to-end RSVP signaling was used. Note that an RSVP-capable sender if end-to-end RSVP signaling was used.
while RSVP is used downstream of the RSVP Sender Proxy, RSVP is not Note that while RSVP is used downstream of the RSVP Sender Proxy,
used upstream of the RSVP Sender Proxy. RSVP is not used upstream of the RSVP Sender Proxy.
Regular RSVP Router: an RSVP-capable router which is not behaving as o Regular RSVP Router: an RSVP-capable router which is not behaving
a RSVP Receiver Proxy nor as a RSVP Sender Proxy. as a RSVP Receiver Proxy nor as a RSVP Sender Proxy.
Note that the roles of RSVP Receiver Proxy, RSVP Sender Proxy, o Note that the roles of RSVP Receiver Proxy, RSVP Sender Proxy,
Regular RSVP Router are all relative to one unidirectional flow. A Regular RSVP Router are all relative to one unidirectional flow.
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
RSVP Sender Proxy for another flow and as a Regular RSVP router for the RSVP Sender Proxy for another flow and as a Regular RSVP
yet another flow. router for yet another flow.
The following terminology is also used in the present document:
o Regular RSVP Sender: an RSVP-capable host behaving as the sender
for the considered flow and participating in RSVP signaling in
accordance with the sender behavior specified in [RFC2205].
o Regular RSVP Receiver: an RSVP-capable host behaving as the
receiver for the considered flow and participating in RSVP
signaling in accordance with the receiver behavior specified in
[RFC2205].
3. RSVP Extensions for Sender Notification 3. RSVP Extensions for Sender Notification
This section defines extensions to RSVP procedures allowing This section defines extensions to RSVP procedures allowing sender
notification of the sender 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 [I-D.ietf-tsvwg-rsvp-proxy-approaches], with the
Path-Triggered RSVP Receiver Proxy approach, the RSVP router may be Path-Triggered RSVP Receiver Proxy approach, the RSVP router may be
configured to use receipt of a regular RSVP Path message as the configured to use receipt of a regular RSVP Path message as the
trigger for RSVP Receiver Proxy behavior. On receipt of the RSVP trigger for RSVP Receiver Proxy behavior. On receipt of the RSVP
Path message, the RSVP Receiver Proxy: Path message, the RSVP Receiver Proxy:
1. establishes the RSVP Path state as per regular RSVP processing 1. establishes the RSVP Path state as per regular RSVP processing
2. identifies the downstream interface towards the receiver 2. identifies the downstream interface towards the receiver
skipping to change at page 8, line 5 skipping to change at page 8, line 5
was received on the downstream interface. This includes was received on the downstream interface. This includes
performing admission control on the downstream interface, performing admission control on the downstream interface,
establishing a Resv state (in case of successful admission establishing a Resv state (in case of successful admission
control) and forwarding the Resv message upstream, sending control) and forwarding the Resv message upstream, sending
periodic refreshes of the Resv message and tearing down the periodic refreshes of the Resv message and tearing down the
reservation if the Path state is torn down. 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*---------| RSVP |----------| R | | S |--------*r*--------*r*--------*r*--------| RSVP |------| R |
|----| *** *** | Receiver | |----| |----| *** *** *** | Receiver | |----|
| Proxy | | Proxy |
|----------| |----------|
*************************************************************> ************************************************************>
===================RSVP======================> ===================RSVP===================>
---Path---> ----Path----> ---Path----> --Path---> --Path---> --Path---> --Path--->
<--Resv---> <---Resv----- <--Resv---- <---Resv-- <---Resv-- <---Resv-- <---Resv--
|----| RSVP-capable |----| Non-RSVP-capable *** |----| RSVP-capable |----| Non-RSVP-capable ***
| S | Sender | R | Receiver *r* regular RSVP | S | Sender | R | Receiver *r* regular RSVP
|----| |----| *** router |----| |----| *** router
***> media flow ***> media flow
==> segment of flow path protected by RSVP reservation ==> segment of flow path protected by RSVP reservation
Figure 1: Successful Reservation Figure 1: Successful Reservation
skipping to change at page 9, line 5 skipping to change at page 9, line 5
notified of the reservation failure. Specifically, in case of an notified of the reservation failure. Specifically, in case of an
admission control rejection on a regular RSVP router, a ResvErr admission control rejection on a regular RSVP router, a ResvErr
message is sent downstream towards the receiver. In the presence of message is sent downstream towards the receiver. In the presence of
an RSVP Receiver Proxy, if we simply follow conventional RSVP an RSVP Receiver Proxy, if we simply follow conventional RSVP
procedures, this means that the RSVP Receiver Proxy is notified of procedures, this means that the RSVP Receiver Proxy is notified of
the reservation failure, but the sender is not. Operation of the the reservation failure, but the sender is not. Operation of the
Path-Triggered RSVP Receiver Proxy in the case of an admission Path-Triggered RSVP Receiver Proxy in the case of an admission
control failure, assuming conventional RSVP procedures, is control failure, assuming conventional RSVP procedures, is
illustrated in Figure 2. illustrated in Figure 2.
|----| *** *** |----------| |----| |----| *** *** *** |----------| |----|
| S |---------*r*----------*r*---------| RSVP |----------| R | | S |--------*r*--------*r*--------*r*--------| RSVP |------| R |
|----| *** *** | Receiver | |----| |----| *** *** *** | Receiver | |----|
| Proxy | | Proxy |
|----------| |----------|
*************************************************************> ************************************************************>
===================RSVP======================> ===================RSVP===================>
---Path---> ----Path----> ---Path----> --Path---> --Path---> --Path---> --Path--->
<---Resv----- <--Resv------ <---Resv-- <---Resv--
---ResvErr---> --ResvErr---> -ResvErr-> -ResvErr->
|----| |----| *** |----| |----| ***
| S | Sender | R | Receiver *r* regular RSVP | S | Sender | R | Receiver *r* regular RSVP
|----| |----| *** router |----| |----| *** router
***> media flow ***> media flow
==> segment of flow path protected by RSVP reservation ==> segment of flow path protected by RSVP reservation
Figure 2: Reservation Failure With Conventional RSVP Figure 2: Reservation Failure With Conventional RSVP
While the sender could infer reservation failure from the fact that While the sender could infer reservation failure from the fact that
it has not received a Resv message after a certain time, there are it has not received a Resv message after a certain time, there are
clear benefits in ensuring that the sender gets a prompt explicit clear benefits in ensuring that the sender gets a prompt explicit
notification in case of reservation failure. notification in case of reservation failure. This includes faster
enduser notification at application layer (e.g. busy signal), faster
application level reaction (e.g. application level rerouting), as
well as faster release of application-level resources.
Section 3.1 defines a method which can be used to achieve sender Section 3.1 defines a method which can be used to achieve sender
notification of reservation failure. An implementation of this notification of reservation failure. A router implementation
document MUST support the method defined in Section 3.1. claiming compliance with this document MUST support the method
defined in Section 3.1.
Section 3.2 defines another method which can be used to achieve Section 3.2 defines another method which can be used to achieve
sender notification of reservation failure. An implementation of sender notification of reservation failure. A router implementation
this document MAY support the method defined in Section 3.2. claiming compliance with this document MAY support the method defined
in Section 3.2.
In a given network environment, a network administrator may elect to
use the method defined in Section 3.1, or the method defined in
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
skipping to change at page 11, line 5 skipping to change at page 11, line 5
completely new. It is borrowed from [RFC3209] where it has been completely new. It is borrowed from [RFC3209] where it has been
introduced in order to achieve a similar requirement, which is to introduced in order to achieve a similar requirement, which is to
allow an MPLS TE Label Switch Router to notify the TE Tunnel Head-end allow an MPLS TE Label Switch Router to notify the TE Tunnel Head-end
(i.e. the sender) of a failure to establish (or maintain) a TE Tunnel (i.e. the sender) of a failure to establish (or maintain) a TE Tunnel
Label Switch Path. Label Switch Path.
Operation of the Path-Triggered RSVP Receiver Proxy in the case of an Operation of the Path-Triggered RSVP Receiver Proxy in the case of an
admission control failure, using sender notification via PathErr admission control failure, using sender notification via PathErr
Message, is illustrated in Figure 3. Message, is illustrated in Figure 3.
|----| *** *** |----------| |----| |----| *** *** *** |----------| |----|
| S |---------*r*----------*r*---------| RSVP |----------| R | | S |--------*r*--------*r*--------*r*--------| RSVP |------| R |
|----| *** *** | Receiver | |----| |----| *** *** *** | Receiver | |----|
| Proxy | | Proxy |
|----------| |----------|
*************************************************************> ************************************************************>
===================RSVP======================> ===================RSVP===================>
---Path---> ----Path----> ---Path----> --Path---> --Path---> --Path---> --Path--->
<---Resv----- <--Resv------ <---Resv-- <---Resv--
---ResvErr---> --ResvErr---> -ResvErr-> -ResvErr->
<--PathErr- <--PathErr--- <--PathErr--- <-PathErr- <-PathErr- <-PathErr- <-PathErr-
|----| |----| *** |----| |----| ***
| S | Sender | R | Receiver *r* regular RSVP | S | Sender | R | Receiver *r* regular RSVP
|----| |----| *** router |----| |----| *** router
***> media flow ***> media flow
==> segment of flow path protected by RSVP reservation ==> segment of flow path protected by RSVP reservation
Figure 3: Reservation Failure With Sender Notification via PathErr Figure 3: Reservation Failure With Sender Notification via PathErr
skipping to change at page 12, line 45 skipping to change at page 12, line 45
2. Errors which the sender has no control over. For these errors, 2. Errors which the sender has no control over. For these errors,
it is sufficient to notify the sender that the reservation was it is sufficient to notify the sender that the reservation was
not set up successfully. An example of this is "Class 13: not set up successfully. An example of this is "Class 13:
Unknown Object", because the sender has no control over the Unknown Object", because the sender has no control over the
objects inserted into the reservation by the Receiver Proxy. objects inserted into the reservation by the Receiver Proxy.
The PathErr message generated by the Receiver Proxy has the same The PathErr message generated by the Receiver Proxy has the same
format as regular PathErr messages defined in [RFC2205]. The format as regular PathErr messages defined in [RFC2205]. The
SESSION, ERROR_SPEC and sender descriptor are composed by the SESSION, ERROR_SPEC and sender descriptor are composed by the
Receiver Proxy as specified in the following subsections. The Receiver Proxy as specified in the following subsections. The
Receiver Proxy MAY reflect back to the sender in the PathErr any Receiver Proxy MAY reflect back towards the sender in the PathErr any
POLICY_DATA objects received in the ResvErr. POLICY_DATA objects received in the ResvErr.
3.1.1. Composition of SESSION and <Sender descriptor> 3.1.1. Composition of SESSION and <Sender descriptor>
The Receiver Proxy MUST insert the SESSION object corresponding to The Receiver Proxy MUST insert the SESSION object corresponding to
the failed reservation, into the PathErr. For Fixed-Filter (FF) the failed reservation, into the PathErr. For Fixed-Filter (FF)
style reservations, the Receiver Proxy MUST insert a <sender style reservations, the Receiver Proxy MUST insert a <sender
descriptor> corresponding to the failed reservation, into the descriptor> corresponding to the failed reservation, into the
PathErr. This is equal to the <flow descriptor> in the ResvErr PathErr. This is equal to the <flow descriptor> in the ResvErr
received by the Receiver Proxy. For Shared-Explicit (SE) style received by the Receiver Proxy. For Shared-Explicit (SE) style
skipping to change at page 14, line 38 skipping to change at page 14, line 38
3.1.3. Use of Path_State_Removed Flag 3.1.3. Use of Path_State_Removed Flag
[RFC3473] defines an optional behavior whereby a node forwarding a [RFC3473] defines an optional behavior whereby a node forwarding a
PathErr message can remove the Path State associated with the PathErr PathErr message can remove the Path State associated with the PathErr
message and indicate so by including the Path_State_Removed flag in message and indicate so by including the Path_State_Removed flag in
the ERROR_SPEC object of the PathErr message. This can be used in the ERROR_SPEC object of the PathErr message. This can be used in
some situations to expedite release of resources and minimise some situations to expedite release of resources and minimise
signaling load. signaling load.
This section discusses aspects of the use of the Path_State_Removed
flag that are specific to the RSVP Receiver Proxy. In any other
aspects, the Path_State_Removed flag operates as per [RFC3473].
By default, the RSVP Receiver Proxy MUST not include the By default, the RSVP Receiver Proxy MUST not include the
Path_State_Removed flag in the ERROR_SPEC of the PathErr message. Path_State_Removed flag in the ERROR_SPEC of the PathErr message.
This ensures predictable operations in all environments including This ensures predictable operations in all environments including
those where some RSVP routers do not understand the those where some RSVP routers do not understand the
Path_State_Removed flag. Path_State_Removed flag.
Optionally, the RSVP Receiver Proxy MAY support a configurable mode Optionally, the RSVP Receiver Proxy MAY support an optional mode that
whereby the RSVP Receiver Proxy includes the Path_State_Removed flag can be activated by configuration whereby the RSVP Receiver Proxy
in the ERROR_SPEC of the PathErr message and removes its local Path includes the Path_State_Removed flag in the ERROR_SPEC of the PathErr
state. This can be used in environments where all RSVP routers are message and removes its local Path state. Where all routers on the
known to support the Path_State_Removed flag thereby reliably path of a reservation support the Path_State_Removed flag, its use
achieving expedited resource release. will indeed result in expedited resource release and reduced
signaling. However, if there is one (or more) "old" router on the
path of the reservation that does not support the Path_State_Removed
flag, its use will actually result in slower resource release and
increased signaling. This is because the Path_State_Removed flag
will be propagated upstream by an "old" router (even if it does not
understand it and does not tear its Path state). Thus, the sender
will not send a Path Tear and the "old" router will only release its
Path state through refresh time-out. A network administrator needs
to keep these considerations in mind when deciding whether to
activate the use of the Path_State_Removed flag on the RSVP Receiver
Proxy. In a controlled environment where all routers are known to
support the Path_State_Removed flag, its use can be safely activated
on the RSVP Receiver Proxy. In other environments, the network
administrator needs to assess whether the improvement achieved with
some reservations outweighs the degradation experienced by other
reservations.
3.1.4. Use of PathErr by Regular Receivers 3.1.4. Use of PathErr by Regular Receivers
Note that while this document specifies that an RSVP Receiver Proxy Note that while this document specifies that an RSVP Receiver Proxy
generates a PathErr upstream in case of reservation failure, this generates a PathErr upstream in case of reservation failure, this
document does NOT propose that the same be done by regular receivers. document does NOT propose that the same be done by regular receivers.
In other words, this document does NOT propose to modify the behavior In other words, this document does NOT propose to modify the behavior
of regular receivers as currently specified in [RFC2205]. The of regular receivers as currently specified in [RFC2205]. The
rationale for this includes the following: rationale for this includes the following:
skipping to change at page 15, line 42 skipping to change at page 16, line 12
sender can. This motivation does not apply in case of regular sender can. This motivation does not apply in case of regular
receiver. receiver.
o there is a lot of existing code and deployed systems successfully o there is a lot of existing code and deployed systems successfully
working under the current [RFC2205] model in the absence of proxy working under the current [RFC2205] model in the absence of proxy
today. The current behavior should not be changed for those today. The current behavior should not be changed for those
unless there were a very strong motivation. unless there were a very strong motivation.
3.2. Sender Notification via Notify Message 3.2. Sender Notification via Notify Message
The optional method for sender notification of reservation failure The OPTIONAL method for sender notification of reservation failure
defined in this section aims at providing a more efficient method defined in this section aims at providing a more efficient method
than the one defined in Section 3.1. Its objectives include : than the one defined in Section 3.1. Its objectives include :
o allow the failure notification to be sent directly upstream to the o allow the failure notification to be sent directly upstream to the
sender by the router where the failure occurs (as opposed to first sender by the router where the failure occurs (as opposed to first
travelling downstream towards the Receiver Proxy and then travelling downstream towards the Receiver Proxy and then
travelling upstream from the Receiver Proxy to the sender, as travelling upstream from the Receiver Proxy to the sender, as
effectively happens with the method defined in Section 3.1) effectively happens with the method defined in Section 3.1)
o allow the failure notification to travel directly to the sender o allow the failure notification to travel directly to the sender
without hop-by-hop RSVP processing without hop-by-hop RSVP processing
o ensure that such a notification is only sent to senders which are o ensure that such a notification is only sent to senders which are
capable and willing to process it (i.e. to synchronize reservation capable and willing to process it (i.e. to synchronize reservation
status with application) status with application)
o ensure that such a notification is only sent in case the receiver o ensure that such a notification is only sent in case the receiver
is not itself capable and willing to do the synchronisation with is not itself capable and willing to do the synchronisation with
the application (i.e. because we are in the presence of a receiver the application (i.e. because we are in the presence of a receiver
skipping to change at page 16, line 23 skipping to change at page 16, line 41
the application (i.e. because we are in the presence of a receiver the application (i.e. because we are in the presence of a receiver
proxy so that RSVP signaling is not visible to the receiver) proxy so that RSVP signaling is not visible to the receiver)
Note, however, that such benefits come at the cost of more Note, however, that such benefits come at the cost of more
sophistication and of a requirement for RSVP routers and senders to sophistication and of a requirement for RSVP routers and senders to
support the Notify messages and procedures defined in [RFC3473]. support the Notify messages and procedures defined in [RFC3473].
[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 currently defined error messages (i.e., PathErr and ResvErr from the error messages defined in [RFC2205] (i.e., PathErr and
messages) in that it can be "targeted" to a node other than the ResvErr messages) in that it can be "targeted" to a node other than
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
are specific to the RSVP Receiver Proxy. In any other aspects, the
Notify message operates as per [RFC3473].
In order to achieve sender notification of reservation failure in the In order to achieve sender notification of reservation failure in the
context of the present document: context of the present document:
o an RSVP sender interested in being notified of reservation failure o an RSVP sender interested in being notified of reservation failure
MUST include a Notify Request object (containing the sender's IP MUST include a Notify Request object (containing the sender's IP
address) in the Path messages it generates address) in the Path messages it generates
o Upon receiving a Path message with a Notify Request object, the o Upon receiving a Path message with a Notify Request object, the
RSVP Receiver Proxy MUST include a Notify Request object in the RSVP Receiver Proxy MUST include a Notify Request object in the
Resv messages it generates. This Notify Request object MUST Resv messages it generates. This Notify Request object MUST
contain the address that was included in the Notify Request of the contain the address that was included in the Notify Request of the
received Path message- a.k.a. the sender's address- and not an received Path message- a.k.a. the sender's address- and not an
address of the Receiver Proxy. address of the Receiver Proxy.
As a result, as per existing Notify procedures, if an RSVP router As a result, as per existing Notify procedures, if an RSVP router
detects an error relating to a Resv state (e.g. Admission Control detects an error relating to a Resv state (e.g. Admission Control
rejection after IP reroute), the RSVP router will send a Notify rejection after IP reroute), the RSVP router will send a Notify
message (conveying the Resv Err code) to the IP address contained in message (conveying the Resv Err code) to the IP address contained in
the Resv Notify Request object. Since this address has been set to the Resv Notify Request object. Since this address has been set to
the sender's address by the Receiver Proxy, the Notify message is the sender's address by the Receiver Proxy, the Notify message is
sent directly to the sender. sent to the sender.
Operation of the Path-Triggered RSVP Receiver Proxy in the case of an Operation of the Path-Triggered RSVP Receiver Proxy in the case of an
admission control failure, using sender notification via Notify admission control failure, using sender notification via Notify
Message, is illustrated in Figure 4. Message, is illustrated in Figure 4.
|----| *** *** |----------| |----| |----| *** *** *** |----------| |----|
| S |---------*r*----------*r*---------| RSVP |----------| R | | S |--------*r*--------*r*--------*r*--------| RSVP |------| R |
|----| *** *** | Receiver | |----| |----| *** *** *** | Receiver | |----|
| Proxy | | Proxy |
|----------| |----------|
*************************************************************> ************************************************************>
===================RSVP======================> ===================RSVP===================>
---Path*--> ----Path*---> ---Path*---> --Path---> --Path---> --Path---> --Path--->
<---Resv*--- <--Resv*---- <---Resv-- <---Resv--
<--Notify-- <------Notify-------
---ResvErr---> --ResvErr---> -ResvErr-> -ResvErr->
|----| |----| *** |----| |----| ***
| S | Sender | R | Receiver *r* regular RSVP | S | Sender | R | Receiver *r* regular RSVP
|----| |----| *** router |----| |----| *** router
***> media flow ***> media flow
==> segment of flow path protected by RSVP reservation ==> segment of flow path protected by RSVP reservation
Path* = Path message containing a Notify Request object Path* = Path message containing a Notify Request object
with sender IP Address with sender IP Address
Resv* = Resv message containing a Notify Request object Resv* = Resv message containing a Notify Request object
with sender IP address with sender IP address
Notify = Notify message
Figure 4: Reservation Failure With Sender Notification via Notify Figure 4: Reservation Failure With Sender Notification via Notify
For local failures on the Receiver Proxy node, if a similar failure For local failures on the Receiver Proxy node, if a similar failure
on an RSVP midpoint would cause the generation of a ResvErr (for on an RSVP midpoint would cause the generation of a ResvErr (for
example, CAC failure), the Receiver Proxy MUST generate a Notify example, CAC failure), the Receiver Proxy MUST generate a Notify
towards the sender. The Receiver Proxy MAY additionally generate a towards the sender. The Receiver Proxy MAY additionally generate a
Notify upon local failures which would not ordinarily cause Notify upon local failures which would not ordinarily cause
generation of a ResvErr message, such as described in Appendix B of generation of a ResvErr message, such as described in Appendix B of
[RFC2205]. [RFC2205].
skipping to change at page 20, line 5 skipping to change at page 20, line 47
risk of being tampered with; While the receivers are in locations risk of being tampered with; While the receivers are in locations
which are physically unsecured and therefore subject to a higher risk which are physically unsecured and therefore subject to a higher risk
of being tampered with. The use of an RSVP receiver proxy function of being tampered with. The use of an RSVP receiver proxy function
effectively increases the security of the operator's reservation and effectively increases the security of the operator's reservation and
admission control solution by completely excluding receivers from its admission control solution by completely excluding receivers from its
operation. Filters can be placed at the edge of the operator network operation. Filters can be placed at the edge of the operator network
discarding any RSVP message received from end-users. This provides a discarding any RSVP message received from end-users. This provides a
very simple and effective protection of the RSVP reservation and very simple and effective protection of the RSVP reservation and
admission control solution operating inside the operator's network. admission control solution operating inside the operator's network.
This document defines in Section 3.2 an optional method relying on
the use of the Notify message specified in [RFC3473]. The Notify
message can be sent in a non-hop-by-hop fashion that precludes RSVP's
hop-by-hop integrity and authentication model. The approaches and
considerations for addressing this issue presented in the Security
Considerations section of [RFC3473] apply. In particular, where the
Notify messages are transmitted non-hop-by-hop and the same level of
security provided by [RFC2747] is desired, the standard IPsec based
integrity and authentication can be used. Alternatively, the sending
of non-hop-by-hop Notify messages can be disabled.
5. IANA Considerations 5. IANA Considerations
Since, as discussed in Section 3.1.2, this document allows two Error Since, as discussed in Section 3.1.2, this document allows two Error
Codes to be used in PathErr messages while [RFC2205] only specified Codes to be used in PathErr messages while [RFC2205] only specified
their use in ResvErr messages, this document requires that IANA their use in ResvErr messages, this document requires that IANA
updates the existing entries for these two Error Codes under the updates the existing entries for these two Error Codes under the
"Error Codes and Globally-Defined Error Value Sub-Codes" registry. "Error Codes and Globally-Defined Error Value Sub-Codes" registry.
Each entry should refer to this document, in addition to referring to Each entry should refer to this document, in addition to referring to
[RFC2205]. Specifically, the entry for Error Code 1 and Error Code 2 [RFC2205]. Specifically, the entry for Error Code 1 and Error Code 2
should respectively read: should respectively read:
skipping to change at page 22, line 37 skipping to change at page 24, line 37
[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.
[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)",
RFC 4303, December 2005. RFC 4303, December 2005.
7.2. Informative References 7.2. Informative References
[I-D.behringer-tsvwg-rsvp-security-groupkeying] [I-D.behringer-tsvwg-rsvp-security-groupkeying]
Behringer, M., Le Faucheur, F., and F. Baker, "A Framework Behringer, M. and F. Le Faucheur, "A Framework for RSVP
for RSVP Security Using Dynamic Group Keying", July 2007. Security Using Dynamic Group Keying", July 2007.
[I-D.ietf-tsvwg-rsvp-proxy-approaches] [I-D.ietf-tsvwg-rsvp-proxy-approaches]
Le Faucheur, F., Manner, J., Wing, D., and A. Guillou, Le Faucheur, F., Manner, J., Wing, D., and A. Guillou,
"RSVP Proxy Approaches", July 2007. "RSVP Proxy Approaches", July 2007.
Authors' Addresses Authors' Addresses
Francois Le Faucheur Francois Le Faucheur
Cisco Systems Cisco Systems
Greenside, 400 Avenue de Roumanille Greenside, 400 Avenue de Roumanille
 End of changes. 57 change blocks. 
113 lines changed or deleted 189 lines changed or added

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