draft-ietf-tsvwg-rsvp-proxy-proto-00.txt   draft-ietf-tsvwg-rsvp-proxy-proto-01.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: August 28, 2007 University of Helsinki Expires: December 28, 2007 University of Helsinki
A. Narayanan A. Narayanan
Cisco Cisco
February 24, 2007 A. Guillou
Neuf
H. Malik
Bharti
June 26, 2007
RSVP Extensions for Path-Triggered RSVP Receiver Proxy RSVP Extensions for Path-Triggered RSVP Receiver Proxy
draft-ietf-tsvwg-rsvp-proxy-proto-00.txt draft-ietf-tsvwg-rsvp-proxy-proto-01.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 37 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 August 28, 2007. This Internet-Draft will expire on December 28, 2007.
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
a given flow take part in RSVP signaling. Yet, there are many use a given flow take part in RSVP signaling. Yet, there are many use
cases where resource reservation is required, but the receiver, the cases where resource reservation is required, but the receiver, the
sender, or both, is not RSVP-capable. Where the receiver is not sender, or both, is not RSVP-capable. Where the receiver is not
RSVP-capable, an RSVP router may behave as an RSVP Receiver Proxy RSVP-capable, an RSVP router may behave as an RSVP Receiver Proxy
thereby performing RSVP signaling on behalf of the receiver. This thereby performing RSVP signaling on behalf of the receiver. This
allows resource reservations to be established on the segment of the allows resource reservations to be established on the segment of the
end-to-end path from the sender to the RSVP Receiver Proxy. However, end-to-end path from the sender to the RSVP Receiver Proxy. However,
as discussed in the companion document presenting RSVP Proxy as discussed in the companion document presenting RSVP Proxy
Approaches, RSVP extensions are needed to facilitate operations with approaches, RSVP extensions are needed to facilitate operations with
an RSVP Receiver Proxy whose signaling is triggered by receipt of an RSVP Receiver Proxy whose signaling is triggered by receipt of
RSVP Path messages from the sender. This document specifies these RSVP Path messages from the sender. This document specifies these
extensions. extensions.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 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 . . . . . . . . . 9
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 . . . . . . . . . . . . . . 12 3.1.2. Composition of ERROR_SPEC . . . . . . . . . . . . . . 13
4. Security Considerations . . . . . . . . . . . . . . . . . . . 14 3.1.3. Use of Path_State_Removed Flag . . . . . . . . . . . . 14
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 3.1.4. Use of PathErr by Regular Receivers . . . . . . . . . 15
6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 16 3.2. Sender Notification via Notify Message . . . . . . . . . . 15
7. Normative References . . . . . . . . . . . . . . . . . . . . . 17 4. Security Considerations . . . . . . . . . . . . . . . . . . . 18
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20
Intellectual Property and Copyright Statements . . . . . . . . . . 19 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 21
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 22
7.1. Normative References . . . . . . . . . . . . . . . . . . . 22
7.2. Informative References . . . . . . . . . . . . . . . . . . 22
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 23
Intellectual Property and Copyright Statements . . . . . . . . . . 25
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, however 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. There are environments where
it would be useful to be able to reserve resources for a flow on at it would be useful to be able to reserve resources for a flow on at
least a subset of the flow path even when the sender or the receiver least a subset of the flow path even when the sender or the receiver
(or both) is not RSVP-capable. (or both) is not RSVP-capable.
Since either the data sender or receiver may be unaware of RSVP, Since either the data sender or receiver may be unaware of RSVP,
there are two distinct use cases. In the first case, an entity in there are two distinct use cases. In the first case, an entity in
the network must operate on behalf of the data sender, generate an the network must operate on behalf of the data sender, generate RSVP
RSVP Path message, and eventually receive, process and sink a Resv Path messages, and eventually receive, process and sink Resv
message. 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
latter case, an entity in the network must receive a Path message second case, an entity in the network must receive Path messages sent
sent by a data sender (or by an RSVP Sender Proxy), and reply to it by a data sender (or by an RSVP Sender Proxy), and reply to those
with a Resv message on behalf of the data receiver(s). We refer to with Resv messages generated on behalf of the data receiver(s). We
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, tear down the RSVP reservation to
satisfy application requirements). 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
skipping to change at page 8, line 19 skipping to change at page 8, line 19
|----------| |----------|
*************************************************************> *************************************************************>
===================RSVP======================> ===================RSVP======================>
---Path---> ----Path----> ---Path----> ---Path---> ----Path----> ---Path---->
<--Resv---> <---Resv----- <--Resv---- <--Resv---> <---Resv----- <--Resv----
|----| RSVP-capable |----| Non-RSCP-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
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
succesful reservation establishment. successful reservation establishment.
However, in case of reservation failure, conventional RSVP procedures However, in case of reservation failure, conventional RSVP procedures
only ensure that the receiver (or the RSVP Receiver Proxy) is only ensure that the receiver (or the RSVP Receiver Proxy) is
notified of the reservation failure. Specifically, in case of an notified of the reservation failure. Specifically, in case of an
admission control rejection on a regular RSVP router, a ResvErr admission control rejection on a regular RSVP router, a ResvErr
message is sent downstream towards the receiver. In the presence of message is sent downstream towards the receiver. In the presence of
an RSVP Receiver Proxy, if we simply follow conventional RSVP an RSVP Receiver Proxy, if we simply follow conventional RSVP
procedures, this means that the RSVP Receiver Proxy is notified of procedures, this means that the RSVP Receiver Proxy is notified of
the reservation failure, but the sender does 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*---------| RSVP |----------| R |
|----| *** *** | Receiver | |----| |----| *** *** | Receiver | |----|
| Proxy | | Proxy |
|----------| |----------|
skipping to change at page 9, line 40 skipping to change at page 9, line 40
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.
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. An implementation of this
document MUST support the method defined in Section 3.1. document MUST support the method defined in Section 3.1.
Section 3.2 defines another method which can be used to achieve
sender notification of reservation failure. An implementation of
this document MAY support the method defined in Section 3.2.
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
order to notify the sender about a reservation failure is not
completely new. It is borrowed from [RFC3209] where it has been
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
(i.e. the sender) of a failure to 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 PathErr
Message, is illustrated in Figure 3. Message, is illustrated in Figure 3.
|----| *** *** |----------| |----| |----| *** *** |----------| |----|
| S |---------*r*----------*r*---------| RSVP |----------| R | | S |---------*r*----------*r*---------| RSVP |----------| R |
|----| *** *** | Receiver | |----| |----| *** *** | Receiver | |----|
| Proxy | | Proxy |
|----------| |----------|
skipping to change at page 10, line 37 skipping to change at page 11, line 31
<--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 Figure 3: Reservation Failure With Sender Notification via PathErr
The role of this PathErr is to notify the sender that the reservation The role of this PathErr is to notify the sender that the reservation
was not established or was torn down. This may be in the case of was not established or was torn down. This may be in the case of
receipt of a ResvErr, or because of local failure on the Receiver receipt of a ResvErr, or because of local failure on the Receiver
Proxy. On receipt of a ResvErr, in all situations where the Proxy. On receipt of a ResvErr, in all situations where the
reservation cannot be installed, the Receiver Proxy MUST generate a reservation cannot be installed, the Receiver Proxy MUST generate a
PathErr towards the sender. For local failures on the Receiver Proxy PathErr towards the sender. For local failures on the Receiver Proxy
node, if a similar failure on an RSVP midpoint would cause the node, if a similar failure on an RSVP midpoint would cause the
generation of a ResvErr (for example, CAC failure), the Receiver generation of a ResvErr (for example, CAC failure), the Receiver
Proxy MUST generate a PathErr towards the sender. The Receiver Proxy Proxy MUST generate a PathErr towards the sender. The Receiver Proxy
MAY additionally generate a PathErr upon local failures which would MAY additionally generate a PathErr upon local failures which would
not ordinarily cause generation of a ResvErr message, such as not ordinarily cause generation of a ResvErr message, such as
described in Appendix B of [RFC2205]. The PathErr generated by the described in Appendix B of [RFC2205].
Receiver Proxy corresponds to the sender(s) which triggered
generation of Resv messages that failed. For Fixed-Filter (FF) style The PathErr generated by the Receiver Proxy corresponds to the
reservations, the Receiver Proxy sends a PathErr towards the (single) sender(s) which triggered generation of Resv messages that failed.
sender matching the failed reservation. For Shared-Explicit (SE) For Fixed-Filter (FF) style reservations, the Receiver Proxy sends a
style reservations, the Receiver Proxy sends the PathErr(s) towards PathErr towards the (single) sender matching the failed reservation.
the set of senders which triggered reservations that failed. This
may be a subset of senders sharing the same reservation, in which For Shared-Explicit (SE) style reservations, the Receiver Proxy sends
case the remaining senders would have their reservation intact and the PathErr(s) towards the set of senders which triggered
would not receive a PathErr. In both cases, the rules described in reservations that failed. This may be a subset of senders sharing
Section 3.1.8 of [RFC2205] for generating flow descriptors in the same reservation, in which case the remaining senders would have
ResvErrs, also apply for generating sender descriptors in PathErrs. their reservation intact and would not receive a PathErr. In both
cases, the rules described in Section 3.1.8 of [RFC2205] for
generating flow descriptors in ResvErr messages, also apply for
generating sender descriptors in PathErr messages.
For Wildcard-Filter (WF) style reservations, it is not possible for For Wildcard-Filter (WF) style reservations, it is not possible for
the receiver to know which sender caused the reservation failure. the receiver to know which sender caused the reservation failure.
Therefore, the procedures described in this section do not apply to Therefore, the procedures described in this section do not apply to
WF-style reservations. WF-style reservations.
The procedures described in this section apply to both unicast and The procedures described in this section apply to both unicast and
multicast sessions. However, for a multicast session, it is possible multicast sessions. However, for a multicast session, it is possible
that reservation failure (e.g. admission control failure) in a node that reservation failure (e.g. admission control failure) in a node
close to a sender may cause ResvErr messages to be sent to a large close to a sender may cause ResvErr messages to be sent to a large
skipping to change at page 12, line 18 skipping to change at page 13, line 12
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
reservations, the Receiver Proxy MUST insert a <sender descriptor> reservations, the Receiver Proxy MUST insert a <sender descriptor>
corresponding to the sender triggering the failed reservation, into corresponding to the sender triggering the failed reservation, into
the PathErr. This is equal to the <flow descriptor> in the ResvErr the PathErr. This is equal to the <flow descriptor> in the ResvErr
received by the Receiver Proxy. If multiple <flow descriptors> could received by the Receiver Proxy. If multiple <flow descriptors> could
not be admitted at a midpoint node, that node would generate multiple not be admitted at a midpoint node, that node would generate multiple
ResvErrs towards the receiver as per Section 3.1.8 of [RFC2205]. ResvErrs messages towards the receiver as per Section 3.1.8 of
Each ResvErr would contain a <flow descriptor> that matches a [RFC2205]. Each ResvErr would contain a <flow descriptor> that
specific sender. The Receiver Proxy MUST generate a PathErr for each matches a specific sender. The Receiver Proxy MUST generate a
ResvErr received, towards the corresponding sender. PathErr for each ResvErr received, towards the corresponding sender.
3.1.2. Composition of ERROR_SPEC 3.1.2. Composition of ERROR_SPEC
The Receiver Proxy MUST compose the ERROR_SPEC to be inserted into The Receiver Proxy MUST compose the ERROR_SPEC to be inserted into
the PathErr as follows: the PathErr as follows:
1. If the Receiver Proxy receives a ResvErr with any of these error 1. If the Receiver Proxy receives a ResvErr with any of these error
codes: "Code 1 - Admission Control Failure" or "Code 2 - Policy codes: "Code 1 - Admission Control Failure" or "Code 2 - Policy
Control Failure" then the Receiver Proxy copies the error code Control Failure" then the Receiver Proxy copies the error code
and value from the ERROR_SPEC in the ResvErr, into the ERROR_SPEC and value from the ERROR_SPEC in the ResvErr, into the ERROR_SPEC
of the PathErr message. The error node in the PathErr MUST be of the PathErr message. The error node in the PathErr MUST be
set to the address of the Receiver Proxy. This procedure MUST set to the address of the Receiver Proxy. This procedure MUST
also be followed for a local error on the Receiver Proxy that also be followed for a local error on the Receiver Proxy that
would ordinarily cause a midpoint to generate a ResvErr with one would ordinarily cause a midpoint to generate a ResvErr with one
of the above codes. 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 other than the ones listed in 1 above, it composes a new
ERROR_SPEC with error code "<TBD>: Unrecoverable Receiver Proxy ERROR_SPEC with error code "<TBD-See IANA Considerations
error" and error value "<TBD>". The error node in the PathErr section>: Unrecoverable Receiver Proxy Error". The error node in
MUST be set to the address of the Receiver Proxy. This procedure the PathErr MUST be set to the address of the Receiver Proxy.
MUST also be followed for a local error on the Receiver Proxy This procedure MUST also be followed for a local error on the
that would ordinarily cause a midpoint to generate a ResvErr with Receiver Proxy that would ordinarily cause a midpoint to generate
any error code except in 1) above, or if the Receiver Proxy a ResvErr with any error code except than those listed in 1
generates a PathErr for a local error which ordinarily would not above, or if the Receiver Proxy generates a PathErr for a local
cause generation of a ResvErr. In some cases it may be error which ordinarily would not cause generation of a ResvErr.
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 which could not process the message it generates cannot be forwarded by the same node which
Resv. Nevertheless, the procedures above MUST be followed. Use could not process the Resv. Nevertheless, the procedures above
of extensions such as the Notify message defined in [RFC3473] may MUST be followed. For the error code "<TBD-See IANA
be investigated in the future to address this issue. Considerations section>: Unrecoverable Receiver Proxy Error", the
16 bits of the Error Value field are:
* hhhh hhhh llll llll
where the bits are:
* 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
by the sender.
* 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
code received in the ResvErr ERROR_SPEC (or, in case the
Receiver Proxy generated the PathErr without having received a
ResvErr, to the error code value that would have been included
by the Receiver Proxy in the ERROR_SPEC in similar conditions
if it was to generate a ResvErr). This error value MAY be
used by the sender to further interpret the reason of the
reservation failure.
* hhhh hhhh = any other value: reserved.
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
ERROR_SPEC of the PathErr.
3.1.3. Use of Path_State_Removed Flag
[RFC3473] defines an optional behavior whereby a node forwarding a
PathErr message can remove the Path State associated with the PathErr
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
some situations to expedite release of resources and minimise
signaling load.
By default, the RSVP Receiver Proxy MUST not include the
Path_State_Removed flag in the ERROR_SPEC of the PathErr message.
This ensures predictable operations in all environments including
those where some RSVP routers do not understand the
Path_State_Removed flag.
Optionally, the RSVP Receiver Proxy MAY support a configurable mode
whereby the RSVP Receiver Proxy includes the Path_State_Removed flag
in the ERROR_SPEC of the PathErr message and removes its local Path
state. This can be used in environments where all RSVP routers are
known to support the Path_State_Removed flag thereby reliably
achieving expedited resource release.
3.1.4. Use of PathErr by Regular Receivers
Note that while this document specifies that an RSVP Receiver Proxy
generates a PathErr upstream in case of reservation failure, this
document does NOT propose that the same be done by regular receivers.
In other words, this document does NOT propose to modify the behavior
of regular receivers as currently specified in [RFC2205]. The
rationale for this includes the following:
o when the receiver is RSVP capable, the current receiver-driven
model of [RFC2205] is fully applicable because the receiver can
synchronise RSVP reservation state and application state (since it
participates in both). The sender(s) needs not be aware of the
RSVP reservation state. Thus, we can retain the benefits of
receiver-driven operations which were explicitly sought by
[RFC2205]. Quoting from it: " In order to efficiently accommodate
large groups, dynamic group membership, and heterogeneous receiver
requirements, RSVP makes receivers responsible for requesting a
specific QoS". But even for the most simple single_sender/
single_receiver reservations, the current receiver-driven model
reduces signaling load and per-hop RSVP processing by not sending
any error message to the sender in case of CAC reject.
o the motivation for adding sender error notification in case of
receiver proxy lies in the fact that the actual receiver can no
lomger synchronize RSVP reservation with application state (since
the receiver does not participate in RSVP signaling), while the
sender can. This motivation does not apply in case of regular
receiver.
o there is a lot of existing code and deployed systems successfully
working under the current [RFC2205] model in the absence of proxy
today. The current behavior should not be changed for those
unless there were a very strong motivation.
3.2. Sender Notification via Notify Message
The optional method for sender notification of reservation failure
defined in this section aims at providing a more efficient method
than the one defined in Section 3.1. Its objectives include :
o allow the failure notification to be sent directly upstream to the
sender by the router where the failure occurs (as opposed to first
travelling downstream towards the Receiver Proxy and then
travelling upstream from the Receiver Proxy to the sender, as
effectively happens with the method defined in Section 3.1)
o allow the failure notification to travel directly to the sender
without hop-by-hop RSVP processing
o ensure that such a notification is only sent to senders which are
capable and willing to process it (i.e. to synchronize reservation
status with application)
o ensure that such a notification is only sent in case the receiver
is not itself capable and willing to do the synchronisation with
the application (i.e. because we are in the presence of a receiver
proxy so that RSVP signaling is not visible to the receiver)
Note, however, that such benefits come at the cost of more
sophistication and of a requirement for RSVP routers and senders to
support the Notify messages and procedures defined in [RFC3473].
[RFC3473] defines (in section "4.3 Notify Messages") the Notify
message that provides a mechanism to inform non-adjacent nodes of
events related to the RSVP reservation. The Notify message differs
from the currently defined error messages (i.e., PathErr and ResvErr
messages) in that it can be "targeted" to a node other than the
immediate upstream or downstream neighbor and that it is a
generalized notification mechanism. Notify messages are normally
generated only after a Notify Request object has been received.
In order to achieve sender notification of reservation failure in the
context of the present document:
o an RSVP sender interested in being notified of reservation failure
MUST include a Notify Request object (containing the sender's IP
address) in the Path messages it generates
o Upon receiving a Path message with a Notify Request object, the
RSVP Receiver Proxy MUST include a Notify Request object in the
Resv messages it generates. This Notify Request object MUST
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
address of the Receiver Proxy.
As a result, as per existing Notify procedures, if an RSVP router
detects an error relating to a Resv state (e.g. Admission Control
rejection after IP reroute), the RSVP router will send a Notify
message (conveying the Resv Err code) to the IP address contained in
the Resv Notify Request object. Since this address has been set to
the sender's address by the Receiver Proxy, the Notify message is
sent directly to the sender.
Operation of the Path-Triggered RSVP Receiver Proxy in the case of an
admission control failure, using sender notification via Notify
Message, is illustrated in Figure 4.
|----| *** *** |----------| |----|
| S |---------*r*----------*r*---------| RSVP |----------| R |
|----| *** *** | Receiver | |----|
| Proxy |
|----------|
*************************************************************>
===================RSVP======================>
---Path*--> ----Path*---> ---Path*--->
<---Resv*--- <--Resv*----
<--Notify--
---ResvErr---> --ResvErr--->
|----| |----| ***
| S | Sender | R | Receiver *r* regular RSVP
|----| |----| *** router
***> media flow
==> segment of flow path protected by RSVP reservation
Path* = Path message containing a Notify Request object
with sender IP Address
Resv* = Resv message containing a Notify Request object
with sender IP address
Figure 4: Reservation Failure With Sender Notification via Notify
For local failures on the Receiver Proxy node, if a similar failure
on an RSVP midpoint would cause the generation of a ResvErr (for
example, CAC failure), the Receiver Proxy MUST generate a Notify
towards the sender. The Receiver Proxy MAY additionally generate a
Notify upon local failures which would not ordinarily cause
generation of a ResvErr message, such as described in Appendix B of
[RFC2205].
4. Security Considerations 4. Security Considerations
To be added. To ensure the integrity of the associated reservation and admission
control mechanisms, the RSVP Authentication mechanisms defined in
[RFC2747] and [RFC3097] may be used. These protect RSVP message
integrity hop-by-hop and provide node authentication as well as
replay protection, thereby protecting against corruption and spoofing
of RSVP messages. These hop-by-hop integrity mechanisms can be used
to protect the RSVP reservations established using an RSVP receiver
proxy in accordance with the present document.
[RFC2747] discusses several approaches for key distribution. First,
the RSVP Authentication shared keys can be distributed manually.
This is the base option and its support is mandated for any
implementation. However, in some environments, this approach may
become a burden if keys frequently change over time. Alternatively,
a standard key management protocol for secure key distribution can be
used. However, existing key distribution protocols may not be
appropriate in all environments because of the complexity or
operational burden they involve.
The use of RSVP Authentication in parts of the network where there
may be one or more IP hops in between two RSVP neighbors raises an
additional challenge. This is because, with some RSVP messages such
as a Path message, an RSVP router does not know the RSVP next hop for
that message at the time of forwarding it. In fact, part of the role
of a Path message is precisely to discover the RSVP next hop (and to
dynamically re-discover it when it changes, say because of a routing
change). Hence, the RSVP router may not know which security
association to use when forwarding such a message. In that
situation, one approach is to share the same RSVP Authentication
shared key across all the RSVP routers of a part of the network where
there may be RSVP neighbors with IP hops in between. For example,
all the RSVP routers of an administrative domain (including the
receiver proxys) could share the same RSVP Authentication key, while
different per-neighbor keys could be used between any RSVP router
pair straddling the boundary between two administrative domains that
have agreed to use RSVP signaling.
When the same RSVP Authentication shared key is to be shared among
multiple RSVP neighbors, manual key distribution may be used. It
might also be possible, in the future, to adapt a multicast dynamic
group key distribution method (e.g. from IETF Multicast Security
Working Group) for dynamic key distribution among RSVP nodes. This
is discussed in [I-D.behringer-tsvwg-rsvp-security-groupkeying]. For
situations where RSVP is being used for unicast flows across domain
boundaries, it is not currently clear how one might provide automated
key management.
The RSVP Authentication mechanisms do not provide confidentiality.
If confidentiality is required, IPsec ESP ([RFC4303]) may be used,
although it imposes the burden of key distribution. It also faces
the additional issue discussed for key management above in the case
where there can be IP hops in between RSVP hops. In the future,
confidentiality solutions may be developed for the case where there
can be IP hops in between RSVP hops, perhaps again by adapting
confidentiality solutions developed by the IETF MSEC Working Group.
Such confidentiality solutions for RSVP are outside the scope of this
document.
When an RSVP receiver proxy is used, the RSVP reservation is no
longer controlled by the receiver, but rather is controlled by the
receiver proxy (using hints received from the sender in the Path
message) on behalf of the sender. Thus, the receiver proxy ought to
be trusted by the end-systems to control the RSVP reservation
appropriately. However, basic RSVP operation already assumes a trust
model where end-systems trust RSVP nodes to appropriately perform
RSVP reservations. So the use of RSVP receiver proxy is not seen as
introducing any significant additional security threat or as
modifying the RSVP trust model.
In fact, there are situations where the use of RSVP receiver proxy
reduces the security risks. One example is where a network operator
relies on RSVP to perform resource reservation and admission control
within a network and where RSVP senders and RSVP routers are located
in the operator premises while the many RSVP receivers are located in
the operator's customers premises. Such an environment is further
illustrated in "Annex A.1. RSVP-based VoD CAC in Broadband
Aggregation Networks" of [I-D.ietf-tsvwg-rsvp-proxy-approaches].
From the operator's perspective, the RSVP routers and RSVP senders
are in physically secured locations and therefore exposed to a lower
risk of being tampered with; While the receivers are in locations
which are physically unsecured and therefore subject to a higher risk
of being tampered with. The use of an RSVP receiver proxy function
effectively increases the security of the operator's reservation and
admission control solution by completely excluding receivers from its
operation. Filters can be placed at the edge of the operator network
discarding any RSVP message received from end-users. This provides a
very simple and effective protection of the RSVP reservation and
admission control solution operating inside the operator's network.
5. IANA Considerations 5. IANA Considerations
This document requires that IANA allocates a new RSVP Error Code Since, as discussed in Section 3.1.2, this document allows two Error
"<TBD>: Unrecoverable Receiver Proxy error" as discussed in Codes to be used in PathErr messages while [RFC2205] only specified
Section 3.1.2. their use in ResvErr messages, this document requires that IANA
updates the existing entries for these two Error Codes under the
"Error Codes and Globally-Defined Error Value Sub-Codes" registry.
Each entry should refer to this document, in addition to referring to
[RFC2205]. Specifically, the entry for Error Code 1 and Error Code 2
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:
"
TBD Unrecoverable Receiver Proxy Error [RFCXXX]
The sixteen bits of the Error Value field are defined in [RFCXXX]
"
where [RFCXXX] refers to this document and TBD is the value to be
allocated by IANA.
6. Acknowledgments 6. Acknowledgments
This document benefited from discussions with Carol Iturralde and This document benefited from discussions with Carol Iturralde and
Amca Zamfir. Amca Zamfir.
7. Normative References 7. References
[I-D.ietf-tsvwg-rsvp-proxy-approaches] 7.1. Normative References
Le Faucheur, L., "RSVP Proxy Approaches", February 2007.
[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 1
Functional Specification", RFC 2205, September 1997. Functional Specification", RFC 2205, September 1997.
[RFC2747] Baker, F., Lindell, B., and M. Talwar, "RSVP Cryptographic
Authentication", RFC 2747, January 2000.
[RFC3097] Braden, R. and L. Zhang, "RSVP Cryptographic
Authentication -- Updated Message Type Value", RFC 3097,
April 2001.
[RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V.,
and G. Swallow, "RSVP-TE: Extensions to RSVP for 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.
[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)",
RFC 4303, December 2005.
7.2. Informative References
[I-D.behringer-tsvwg-rsvp-security-groupkeying]
Behringer, M., Le Faucheur, F., and F. Baker, "A Framework
for RSVP Security Using Dynamic Group Keying", July 2007.
[I-D.ietf-tsvwg-rsvp-proxy-approaches]
Le Faucheur, F., Manner, J., Wing, D., and A. Guillou,
"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
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
skipping to change at page 18, line 26 skipping to change at page 23, line 26
Jukka Manner Jukka Manner
University of Helsinki University of Helsinki
P.O. Box 68 P.O. Box 68
University of Helsinki FIN-00014 University of Helsinki University of Helsinki FIN-00014 University of Helsinki
Finland Finland
Phone: +358 9 191 51298 Phone: +358 9 191 51298
Email: jmanner@cs.helsinki.fi Email: jmanner@cs.helsinki.fi
URI: http://www.cs.helsinki.fi/u/jmanner/ URI: http://www.cs.helsinki.fi/u/jmanner/
Ashok Narayan Ashok Narayanan
Cisco Systems Cisco Systems
300 Beaver Brook Road 300 Beaver Brook Road
Boxborough, MAS 01719 Boxborough, MAS 01719
United States United States
Email: ashokn@cisco.com Email: ashokn@cisco.com
Allan Guillou
Neuf Cegetel
40-42 Quai du Point du Jour
Boulogne-Billancourt, 92659
France
Email: allan.guillou@neufcegetel.fr
Hemant Malik
Bharti Airtel Ltd.
4th Floor, Tower A, Unitech Cyber Park
Gurgaon, Sector 39, 122001
India
Email: Hermant.Malik@airtel.in
Full Copyright Statement Full Copyright Statement
Copyright (C) The IETF Trust (2007). Copyright (C) The IETF Trust (2007).
This document is subject to the rights, licenses and restrictions This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors contained in BCP 78, and except as set forth therein, the authors
retain all their rights. retain all their rights.
This document and the information contained herein are provided on an This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
 End of changes. 24 change blocks. 
63 lines changed or deleted 433 lines changed or added

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