draft-ietf-tsvwg-rsvp-proxy-proto-10.txt   draft-ietf-tsvwg-rsvp-proxy-proto-11.txt 
TSVWG F. Le Faucheur TSVWG F. Le Faucheur
Internet-Draft Cisco Internet-Draft Cisco
Updates: 2205 (if approved) J. Manner Updates: 2205 (if approved) J. Manner
Intended status: Standards Track TKK Intended status: Standards Track TKK
Expires: April 29, 2010 A. Narayanan Expires: September 9, 2010 A. Narayanan
Cisco Cisco
A. Guillou A. Guillou
Neuf Neuf
H. Malik H. Malik
Bharti Bharti
October 26, 2009 March 8, 2010
RSVP Extensions for Path-Triggered RSVP Receiver Proxy RSVP Extensions for Path-Triggered RSVP Receiver Proxy
draft-ietf-tsvwg-rsvp-proxy-proto-10.txt draft-ietf-tsvwg-rsvp-proxy-proto-11.txt
Abstract
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
flows. With conventional RSVP, both the data sender and receiver of
a given flow take part in RSVP signaling. Yet, there are many use
cases where resource reservation is required, but the receiver, the
sender, or both, is not RSVP-capable. Where the receiver is not
RSVP-capable, an RSVP router may behave as an RSVP Receiver Proxy
thereby performing RSVP signaling on behalf of the receiver. This
allows resource reservations to be established on the segment of the
end-to-end path from the sender to the RSVP Receiver Proxy. However,
as discussed in the companion document presenting RSVP Proxy
approaches, RSVP extensions are needed to facilitate operations with
an RSVP Receiver Proxy whose signaling is triggered by receipt of
RSVP Path messages from the sender. This document specifies these
extensions.
Status of this Memo Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79. This document may contain material provisions of BCP 78 and BCP 79.
from IETF Documents or IETF Contributions published or made publicly
available before November 10, 2008. The person(s) controlling the
copyright in some of this material may not have granted the IETF
Trust the right to allow modifications of such material outside the
IETF Standards Process. Without obtaining an adequate license from
the person(s) controlling the copyright in such materials, this
document may not be modified outside the IETF Standards Process, and
derivative works of it may not be created outside the IETF Standards
Process, except to format it for publication as an RFC or to
translate it into languages other than English.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
skipping to change at page 1, line 42 skipping to change at page 2, line 4
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on April 29, 2010. This Internet-Draft will expire on September 9, 2010.
Copyright Notice Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents in effect on the date of Provisions Relating to IETF Documents
publication of this document (http://trustee.ietf.org/license-info). (http://trustee.ietf.org/license-info) in effect on the date of
Please review these documents carefully, as they describe your rights publication of this document. Please review these documents
and restrictions with respect to this document. carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
Abstract include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the BSD License.
RSVP signaling can be used to make end-to-end resource reservations This document may contain material from IETF Documents or IETF
in an IP network in order to guarantee the QoS required by certain Contributions published or made publicly available before November
flows. With conventional RSVP, both the data sender and receiver of 10, 2008. The person(s) controlling the copyright in some of this
a given flow take part in RSVP signaling. Yet, there are many use material may not have granted the IETF Trust the right to allow
cases where resource reservation is required, but the receiver, the modifications of such material outside the IETF Standards Process.
sender, or both, is not RSVP-capable. Where the receiver is not Without obtaining an adequate license from the person(s) controlling
RSVP-capable, an RSVP router may behave as an RSVP Receiver Proxy the copyright in such materials, this document may not be modified
thereby performing RSVP signaling on behalf of the receiver. This outside the IETF Standards Process, and derivative works of it may
allows resource reservations to be established on the segment of the not be created outside the IETF Standards Process, except to format
end-to-end path from the sender to the RSVP Receiver Proxy. However, it for publication as an RFC or to translate it into languages other
as discussed in the companion document presenting RSVP Proxy than English.
approaches, RSVP extensions are needed to facilitate operations with
an RSVP Receiver Proxy whose signaling is triggered by receipt of
RSVP Path messages from the sender. This document specifies these
extensions.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Conventions Used in This Document . . . . . . . . . . . . 8 1.1. Conventions Used in This Document . . . . . . . . . . . . 7
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 9 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 8
3. RSVP Extensions for Sender Notification . . . . . . . . . . . 10 3. RSVP Extensions for Sender Notification . . . . . . . . . . . 9
3.1. Sender Notification via PathErr Message . . . . . . . . . 13 3.1. Sender Notification via PathErr Message . . . . . . . . . 12
3.1.1. Composition of SESSION and Sender Descriptor . . . . . 16 3.1.1. Composition of SESSION and Sender Descriptor . . . . . 15
3.1.2. Composition of ERROR_SPEC . . . . . . . . . . . . . . 16 3.1.2. Composition of ERROR_SPEC . . . . . . . . . . . . . . 15
3.1.3. Use of Path_State_Removed Flag . . . . . . . . . . . . 17 3.1.3. Use of Path_State_Removed Flag . . . . . . . . . . . . 16
3.1.4. Use of PathErr by Regular Receivers . . . . . . . . . 18 3.1.4. Use of PathErr by Regular Receivers . . . . . . . . . 17
3.2. Sender Notification via Notify Message . . . . . . . . . . 19 3.2. Sender Notification via Notify Message . . . . . . . . . . 18
4. Mechanisms for Maximizing the Reservation Span . . . . . . . . 27 4. Mechanisms for Maximizing the Reservation Span . . . . . . . . 26
4.1. Dynamic Discovery of Downstream RSVP Functionality . . . . 27 4.1. Dynamic Discovery of Downstream RSVP Functionality . . . . 26
4.2. Receiver Proxy Control Policy Element . . . . . . . . . . 28 4.2. Receiver Proxy Control Policy Element . . . . . . . . . . 28
4.2.1. Default Handling . . . . . . . . . . . . . . . . . . . 29 4.2.1. Default Handling . . . . . . . . . . . . . . . . . . . 31
5. Security Considerations . . . . . . . . . . . . . . . . . . . 31 5. Security Considerations . . . . . . . . . . . . . . . . . . . 32
5.1. Security Considerations for the Sender Notification 5.1. Security Considerations for the Sender Notification
via Notify Message . . . . . . . . . . . . . . . . . . . . 32 via Notify Message . . . . . . . . . . . . . . . . . . . . 33
5.2. Security Considerations for the Receiver Proxy Control 5.2. Security Considerations for the Receiver Proxy Control
Policy Element . . . . . . . . . . . . . . . . . . . . . . 32 Policy Element . . . . . . . . . . . . . . . . . . . . . . 33
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 34 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 35
6.1. RSVP Error Codes . . . . . . . . . . . . . . . . . . . . . 34 6.1. RSVP Error Codes . . . . . . . . . . . . . . . . . . . . . 35
6.2. Policy Element . . . . . . . . . . . . . . . . . . . . . . 34 6.2. Policy Element . . . . . . . . . . . . . . . . . . . . . . 35
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 36 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 37
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 37 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 38
8.1. Normative References . . . . . . . . . . . . . . . . . . . 37 8.1. Normative References . . . . . . . . . . . . . . . . . . . 38
8.2. Informative References . . . . . . . . . . . . . . . . . . 38 8.2. Informative References . . . . . . . . . . . . . . . . . . 39
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 39 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 40
1. Introduction 1. Introduction
Guaranteed QoS for some applications with tight QoS requirements may Guaranteed QoS for some applications with tight QoS requirements may
be achieved by reserving resources in each node on the end-to-end be achieved by reserving resources in each node on the end-to-end
path. The main IETF protocol for these resource reservations is RSVP path. The main IETF protocol for these resource reservations is RSVP
specified in [RFC2205]. RSVP does not require that all intermediate specified in [RFC2205]. RSVP does not require that all intermediate
nodes support RSVP, but it assumes that both the sender and the nodes support RSVP, but it assumes that both the sender and the
receiver of the data flow support RSVP. However, there are receiver of the data flow support RSVP. However, there are
environments where it would be useful to be able to reserve resources environments where it would be useful to be able to reserve resources
skipping to change at page 11, line 5 skipping to change at page 10, line 5
from the receiver) was received on the downstream interface. from the receiver) was received on the downstream interface.
This includes performing admission control on the downstream This includes performing admission control on the downstream
interface, establishing a Resv state (in case of successful interface, establishing a Resv state (in case of successful
admission control) and forwarding the Resv message upstream, admission control) and forwarding the Resv message upstream,
sending periodic refreshes of the Resv message and tearing down sending periodic refreshes of the Resv message and tearing down
the reservation if the Path state is torn down. the reservation if the Path state is torn down.
Operation of the Path-Triggered Receiver Proxy in the case of a Operation of the Path-Triggered Receiver Proxy in the case of a
successful reservation is illustrated in Figure 1. successful reservation is illustrated in Figure 1.
|----| *** *** *** |----------| |----| |****| *** *** *** |**********| |----|
| S |--------*r*--------*r*--------*r*--------| RSVP |------| R | | S |--------*r*--------*r*--------*r*--------| RSVP |------| R |
|----| *** *** *** | Receiver | |----| |****| *** *** *** | Receiver | |----|
| Proxy | | Proxy |
|----------| |**********|
--Path---> --Path---> --Path---> --Path---> --Path---> --Path---> --Path---> --Path--->
<---Resv-- <---Resv-- <---Resv-- <---Resv-- <---Resv-- <---Resv-- <---Resv-- <---Resv--
===================RSVP===================> ===================RSVP===================>
************************************************************> ************************************************************>
|----| RSVP-capable |----| Non-RSVP-capable *** |****| RSVP-capable |----| Non-RSVP-capable ***
| S | Sender | R | Receiver *r* regular RSVP | S | Sender | R | Receiver *r* regular RSVP
|----| |----| *** router |****| |----| *** router
***> media flow ***> media flow
==> segment of flow path benefiting from an RSVP reservation ==> segment of flow path benefiting from an RSVP reservation
Figure 1: Successful Reservation Figure 1: Successful Reservation
We observe that, in the case of successful reservation, conventional We observe that, in the case of successful reservation, conventional
RSVP procedures ensure that the sender is notified of the successful RSVP procedures ensure that the sender is notified of the successful
reservation establishment. Thus, no extensions are required in the reservation establishment. Thus, no extensions are required in the
skipping to change at page 12, line 5 skipping to change at page 11, 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*--------*r*--------| RSVP |------| R | | S |--------*r*--------*r*--------*r*--------| RSVP |------| R |
|----| *** *** *** | Receiver | |----| |****| *** *** *** | Receiver | |----|
| Proxy | | Proxy |
|----------| |**********|
--Path---> --Path---> --Path---> --Path---> --Path---> --Path---> --Path---> --Path--->
<---Resv-- <---Resv-- <---Resv-- <---Resv--
-ResvErr-> -ResvErr-> -ResvErr-> -ResvErr->
===================RSVP===================> ===================RSVP===================>
************************************************************> ************************************************************>
|----| |----| *** |****| RSVP-capable |----| Non-RSVP-capable ***
| S | Sender | R | Receiver *r* regular RSVP | S | Sender | R | Receiver *r* regular RSVP
|----| |----| *** router |****| |----| *** router
***> media flow ***> media flow
==> segment of flow path benefiting from an RSVP reservation ==> segment of flow path benefiting from an RSVP reservation
Figure 2: Reservation Failure With Conventional RSVP Figure 2: Reservation Failure With Conventional RSVP
While the sender could infer reservation failure from the fact that While the sender could infer reservation failure from the fact that
it has not received a Resv message after a certain time, there are it has not received a Resv message after a certain time, there are
clear benefits in ensuring that the sender gets a prompt, explicit clear benefits in ensuring that the sender gets a prompt, explicit
skipping to change at page 14, line 5 skipping to change at page 13, 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 (i.e., the sender) of a failure to establish (or maintain) a TE
Tunnel Label Switch Path. Tunnel Label Switch Path.
Operation of the Path-Triggered RSVP Receiver Proxy in the case of an Operation of the Path-Triggered RSVP Receiver Proxy in the case of an
admission control failure, using sender notification via PathErr admission control failure, using sender notification via PathErr
Message, is illustrated in Figure 3. Message, is illustrated in Figure 3.
|----| *** *** *** |----------| |----| |****| *** *** *** |**********| |----|
| S |--------*r*--------*r*--------*r*--------| RSVP |------| R | | S |--------*r*--------*r*--------*r*--------| RSVP |------| R |
|----| *** *** *** | Receiver | |----| |****| *** *** *** | Receiver | |----|
| Proxy | | Proxy |
|----------| |**********|
--Path---> --Path---> --Path---> --Path---> --Path---> --Path---> --Path---> --Path--->
<---Resv-- <---Resv-- <---Resv-- <---Resv--
-ResvErr-> -ResvErr-> -ResvErr-> -ResvErr->
<-PathErr- <-PathErr- <-PathErr- <-PathErr- <-PathErr- <-PathErr- <-PathErr- <-PathErr-
===================RSVP===================> ===================RSVP===================>
************************************************************> ************************************************************>
|----| |----| *** |****| RSVP-capable |----| Non-RSVP-capable ***
| S | Sender | R | Receiver *r* regular RSVP | S | Sender | R | Receiver *r* regular RSVP
|----| |----| *** router |****| |----| *** router
***> media flow ***> media flow
==> segment of flow path benefiting from RSVP ==> segment of flow path benefiting from RSVP
(but not benefiting from a reservation in this case) (but not benefiting from a reservation in this case)
Figure 3: Reservation Failure With Sender Notification via PathErr Figure 3: Reservation Failure With Sender Notification via PathErr
The role of this PathErr is to notify the sender that the reservation The role of this PathErr is to notify the sender that the reservation
was not established or was torn down. This may be in the case of was not established or was torn down. This may be in the case of
skipping to change at page 22, line 5 skipping to change at page 21, line 5
(Direct Notify), the Notify message is sent directly to the sender. (Direct Notify), the Notify message is sent directly to the sender.
If this address has been set by the RSVP Receiver Proxy to one of its If this address has been set by the RSVP Receiver Proxy to one of its
address (Indirect Notify), the Notify message is sent to the RSVP address (Indirect Notify), the Notify message is sent to the RSVP
Receiver Proxy that, in turn, will generate a Notify message directly Receiver Proxy that, in turn, will generate a Notify message directly
addressed to the sender. addressed to the sender.
Operation of the Path-Triggered RSVP Receiver Proxy in the case of an Operation of the Path-Triggered RSVP Receiver Proxy in the case of an
admission control failure, using sender notification via Direct admission control failure, using sender notification via Direct
Notify, is illustrated in Figure 4. Notify, is illustrated in Figure 4.
|----| *** *** *** |----------| |----| |****| *** *** *** |**********| |----|
| S |--------*r*--------*r*--------*r*--------| RSVP |------| R | | S |--------*r*--------*r*--------*r*--------| RSVP |------| R |
|----| *** *** *** | Receiver | |----| |****| *** *** *** | Receiver | |----|
| Proxy | | Proxy |
|----------| |**********|
--Path*--> --Path*--> --Path*--> --Path*--> --Path*--> --Path*--> --Path*--> --Path*-->
<--Resv*-- <--Resv*-- <--Resv*-- <--Resv*--
<------NotifyD-------- <------NotifyD--------
-ResvErr-> -ResvErr-> -ResvErr-> -ResvErr->
<------------------NotifyU------------------ <------------------NotifyU------------------
<-PathErr- <-PathErr- <-PathErr- <-PathErr- <-PathErr- <-PathErr- <-PathErr- <-PathErr-
===================RSVP===================> ===================RSVP===================>
************************************************************> ************************************************************>
|----| |----| *** |****| RSVP-capable |----| Non-RSVP-capable ***
| S | Sender | R | Receiver *r* regular RSVP | S | Sender | R | Receiver *r* regular RSVP
|----| |----| *** router |****| |----| *** router
***> media flow ***> media flow
==> segment of flow path benefiting from RSVP ==> segment of flow path benefiting from RSVP
(but not benefiting from a reservation in this case) (but not benefiting from a reservation in this case)
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
skipping to change at page 24, line 5 skipping to change at page 23, line 5
NotifyU = Notify message containing an upstream notification NotifyU = Notify message containing an upstream notification
Figure 4: Reservation Failure With Sender Notification via Direct Figure 4: Reservation Failure With Sender Notification via Direct
Notify Notify
Operation of the Path-Triggered RSVP Receiver Proxy in the case of an Operation of the Path-Triggered RSVP Receiver Proxy in the case of an
admission control failure, using sender notification via Indirect admission control failure, using sender notification via Indirect
Notify, is illustrated in Figure 5. Notify, is illustrated in Figure 5.
|----| *** *** *** |----------| |----| |****| *** *** *** |**********| |----|
| S |--------*r*--------*r*--------*r*--------| RSVP |------| R | | S |--------*r*--------*r*--------*r*--------| RSVP |------| R |
|----| *** *** *** | Receiver | |----| |****| *** *** *** | Receiver | |----|
| Proxy | | Proxy |
|----------| |**********|
--Path*--> --Path*--> --Path*--> --Path*--> --Path*--> --Path*--> --Path*--> --Path*-->
<--Resv*-- <--Resv*-- <--Resv*-- <--Resv*--
-------NotifyD-------> -------NotifyD------->
<------------------NotifyU------------------ <------------------NotifyU------------------
-ResvErr-> -ResvErr-> -ResvErr-> -ResvErr->
<-PathErr- <-PathErr- <-PathErr- <-PathErr- <-PathErr- <-PathErr- <-PathErr- <-PathErr-
===================RSVP===================> ===================RSVP===================>
************************************************************> ************************************************************>
|----| |----| *** |****| RSVP-capable |----| Non-RSVP-capable ***
| S | Sender | R | Receiver *r* regular RSVP | S | Sender | R | Receiver *r* regular RSVP
|----| |----| *** router |****| |----| *** router
***> media flow ***> media flow
==> segment of flow path benefiting from RSVP ==> segment of flow path benefiting from RSVP
(but not benefiting from a reservation in this case) (but not benefiting from a reservation in this case)
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
skipping to change at page 27, line 43 skipping to change at page 26, line 43
method defined in Section 4.2. method defined in Section 4.2.
In a given network environment, a network administrator may elect to In a given network environment, a network administrator may elect to
use the method defined in Section 4.1, or the method defined in use the method defined in Section 4.1, or the method defined in
Section 4.2, or possibly combine the two. Section 4.2, or possibly combine the two.
4.1. Dynamic Discovery of Downstream RSVP Functionality 4.1. Dynamic Discovery of Downstream RSVP Functionality
When generating a proxy Resv message upstream, a Receiver Proxy When generating a proxy Resv message upstream, a Receiver Proxy
supporting dynamic discovery of downstream RSVP functionality MUST supporting dynamic discovery of downstream RSVP functionality MUST
forward the Path message downstream instead of terminating it. If forward the Path message downstream instead of terminating it (unless
the destination endpoint supports RSVP (or there is another Receiver dynamic discovery of downstream RSVP functionality is explicitely
Proxy downstream), it will receive the Path and generate a Resv disabled). If the destination endpoint supports RSVP (or there is
upstream. When this Resv reaches the Receiver Proxy, it recognizes another Receiver Proxy downstream), it will receive the Path and
the presence of a RSVP-capable receiver (or of another RSVP Receiver generate a Resv upstream. When this Resv message reaches the
Proxy) downstream and MUST internally converts its state from a Receiver Proxy, it recognizes the presence of a RSVP-capable receiver
proxied reservation to a regular midpoint RSVP behavior. From then (or of another RSVP Receiver Proxy) downstream and MUST internally
on, the RSVP router MUST behave as a regular RSVP router for that converts its state from a proxied reservation to a regular midpoint
reservation (i.e. As if the RSVP router never behaved as an RSVP RSVP behavior. From then on, the RSVP router MUST behave as a
receiver proxy for that flow). regular RSVP router for that reservation (i.e. As if the RSVP router
never behaved as an RSVP receiver proxy for that flow). This method
is illustrated in Figure 6.
|****| *** |**********| |----|
| S |---------*r*---------| RSVP |---| R1 |
|****| *** | Receiver | |----|
| Proxy |
| |
| | |****|
| |------------| R2 |
|**********| |****|
---Path---> --Path--->
(R1) (R1) \-------Path-->
/ (R1)
<--Resv--- <---Resv---
================RSVP===>
**************************************>
---Path---> --Path--->
(R2) (R2) \-------------Path---->
/ (R2)
<--Resv--- <---Resv---
<----Resv---
================RSVP===========================>
***********************************************>
|****| RSVP-capable |----| non-RSVP-capable |****| RSVP-capable
| S | Sender | R | Receiver | R | Receiver
|****| |----| |****|
***
*r* regular RSVP
*** router
(R1) = Path message contains a Session object whose destination is R1
***> media flow
==> segment of flow path protected by RSVP reservation
Figure 6: Dynamic Discovery of Downstream RSVP Functionality
If there is no RSVP-capable receiver (or other Receiver Proxy) If there is no RSVP-capable receiver (or other Receiver Proxy)
downstream of the Receiver Proxy, then the Path messages sent by the downstream of the Receiver Proxy, then the Path messages sent by the
Receiver Proxy every RSVP refresh interval (e.g. 30 seconds by Receiver Proxy every RSVP refresh interval (e.g. 30 seconds by
default) will never be responded to. However, these messages consume default) will never be responded to. However, these messages consume
a small amount of bandwidth, and in addition would install some RSVP a small amount of bandwidth, and in addition would install some RSVP
state on RSVP-capable midpoint nodes downstream of the first Receiver state on RSVP-capable midpoint nodes downstream of the first Receiver
Proxy. This is seen as a very minor sub-optimality, however, to Proxy. This is seen as a very minor sub-optimality, however, to
mitigate this, the Receiver Proxy MAY tear down any unanswered mitigate this, the Receiver Proxy MAY tear down any unanswered
downstream Path state after a predetermined time, and MAY stop downstream Path state after a predetermined time (that SHOULD be
sending Path messages for the flow (or MAY only send them at much greater or equal to the Path refresh interval), and MAY stop sending
lower frequency). Path messages for the flow (or MAY only send them at much lower
frequency).
This approach only requires support of the behavior described in the This approach only requires support of the behavior described in the
previous paragraph and does not require any new RSVP extensions. previous paragraph and does not require any new RSVP extensions.
4.2. Receiver Proxy Control Policy Element 4.2. Receiver Proxy Control Policy Element
[RFC2750] defines extensions for supporting generic policy based [RFC2750] defines extensions for supporting generic policy based
admission control in RSVP. These extensions include the standard admission control in RSVP. These extensions include the standard
format of POLICY_DATA objects and a description of RSVP handling of format of POLICY_DATA objects and a description of RSVP handling of
policy events. policy events.
skipping to change at page 28, line 38 skipping to change at page 28, line 40
representing a different (and perhaps orthogonal) policy. As an representing a different (and perhaps orthogonal) policy. As an
example, [RFC3181] specifies the Preemption Priority Policy Element. example, [RFC3181] specifies the Preemption Priority Policy Element.
The present document defines a new Policy Element called the Receiver The present document defines a new Policy Element called the Receiver
Proxy Control Policy Element. The present document only defines the Proxy Control Policy Element. The present document only defines the
use of this Policy Element in Path messages and for unicast use of this Policy Element in Path messages and for unicast
reservations. Other usage are outside the scope of the present reservations. Other usage are outside the scope of the present
document. document.
The format of the Receiver Proxy Control Policy Element is as shown The format of the Receiver Proxy Control Policy Element is as shown
in Figure 6: in Figure 7:
0 0 0 1 1 2 2 3 0 0 0 1 1 2 2 3
0 . . . 7 8 . . . 5 6 . . . 3 4 . . . 1 0 . . . 7 8 . . . 5 6 . . . 3 4 . . . 1
+-------------+-------------+-------------+-------------+ +-------------+-------------+-------------+-------------+
| Length | P-Type=REC_PROXY_CONTROL | | Length | P-Type=REC_PROXY_CONTROL |
+-------------+-------------+-------------+-------------+ +-------------+-------------+-------------+-------------+
| Reserved |Control-Value| | Reserved |Control-Value|
+---------------------------+---------------------------+ +---------------------------+---------------------------+
Figure 6: Receiver Proxy Control Policy Element Figure 7: Receiver Proxy Control Policy Element
where: where:
o Length: 16 bits o Length: 16 bits
* Always 8. The overall length of the policy element, in bytes. * Always 8. The overall length of the policy element, in bytes.
o P-Type: 16 bits o P-Type: 16 bits
* REC_PROXY_CONTROL = To be allocated by IANA (see "IANA * REC_PROXY_CONTROL = To be allocated by IANA (see "IANA
skipping to change at page 29, line 47 skipping to change at page 30, line 10
* 2 (Receiver-Proxy-Not-Needed): An Receiver Proxy that * 2 (Receiver-Proxy-Not-Needed): An Receiver Proxy that
understands this policy element MUST NOT attempt to insert understands this policy element MUST NOT attempt to insert
itself as a Receiver Proxy for that flow if the corresponding itself as a Receiver Proxy for that flow if the corresponding
Path message contains this Control-Value. An RSVP sender MAY Path message contains this Control-Value. An RSVP sender MAY
insert the Receiver Proxy Control Policy Element with this insert the Receiver Proxy Control Policy Element with this
Control-Value when it knows (say by other means such as Control-Value when it knows (say by other means such as
application-level signalling) that the receiver is RSVP application-level signalling) that the receiver is RSVP
capable. capable.
Figure 8 illustrates the method based on the Receiver Proxy Control
Policy Element and allowing a sender to control whether an RSVP
router supporting the Path-triggered Receiver Proxy function is to
behave as a Receiver Proxy for a given flow or not.
|****| *** |**********| |----|
| S |---------*r*---------| RSVP |---| R1 |
|****| *** | Receiver | |----|
| Proxy |
| |
| | |****|
| |------------| R2 |
|**********| |****|
---Path---> --Path--->
(R1/N) (R1/N)
<--Resv--- <---Resv---
================RSVP===>
**************************************>
---Path---> --Path---> ----Path---->
(R2/NN) (R2/NN) (R2/NN)
<--Resv--- <---Resv--- <----Resv----
================RSVP===========================>
***********************************************>
|****| RSVP-capable |----| non-RSVP-capable |****| RSVP-capable
| S | Sender | R | Receiver | R | Receiver
|****| |----| |****|
***
*r* regular RSVP
*** router
(R1) = Path message contains a Session object whose destination is R1
(N) = Path message contains a Receiver Proxy Control Policy Element
whose Control-Value is set to Receiver-Proxy-Needed
(NN) = Path message contains a Receiver Proxy Control Policy Element
whose Control-Value is set to Receiver-Proxy-Not-Needed
***> media flow
==> segment of flow path protected by RSVP reservation
Figure 8: Receiver Proxy Control by Sender
4.2.1. Default Handling 4.2.1. Default Handling
As specified in section 4.2 of [RFC2750], Policy Ignorant Nodes As specified in section 4.2 of [RFC2750], Policy Ignorant Nodes
(PINs) implement a default handling of POLICY_DATA objects ensuring (PINs) implement a default handling of POLICY_DATA objects ensuring
that those objects can traverse PIN nodes in transit from one Policy that those objects can traverse PIN nodes in transit from one Policy
Enforcement Point (PEP) to another. This applies to the situations Enforcement Point (PEP) to another. This applies to the situations
where POLICY_DATA objects contain the Receiver Proxy Control Policy where POLICY_DATA objects contain the Receiver Proxy Control Policy
Element specified in this document, so that those can traverse PIN Element specified in this document, so that those can traverse PIN
nodes. nodes.
skipping to change at page 37, line 9 skipping to change at page 38, line 9
[RFC3473]. We also thank Stephen Kent, Ken Carlberg and Tim Polk for [RFC3473]. We also thank Stephen Kent, Ken Carlberg and Tim Polk for
their valuable input and proposed enhancements. Finally we thank their valuable input and proposed enhancements. Finally we thank
Cullen Jennings, Magnus Westerlund and Robert Sparks for stimulating Cullen Jennings, Magnus Westerlund and Robert Sparks for stimulating
the work on extensions maximizing the reservation span and the work on extensions maximizing the reservation span and
facilitating migration from Proxy model to end-to-end RSVP model. facilitating migration from Proxy model to end-to-end RSVP model.
8. References 8. References
8.1. Normative References 8.1. Normative References
[I-D.ietf-tsvwg-rsvp-security-groupkeying]
Behringer, M. and F. Faucheur, "Applicability of Keying
Methods for RSVP Security",
draft-ietf-tsvwg-rsvp-security-groupkeying-05 (work in
progress), June 2009.
[RFC2113] Katz, D., "IP Router Alert Option", RFC 2113, [RFC2113] Katz, D., "IP Router Alert Option", RFC 2113,
February 1997. February 1997.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2205] Braden, B., Zhang, L., Berson, S., Herzog, S., and S. [RFC2205] Braden, B., Zhang, L., Berson, S., Herzog, S., and S.
Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1
Functional Specification", RFC 2205, September 1997. Functional Specification", RFC 2205, September 1997.
skipping to change at page 38, line 15 skipping to change at page 39, line 8
[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)",
RFC 4303, December 2005. RFC 4303, December 2005.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 5226, IANA Considerations Section in RFCs", BCP 26, RFC 5226,
May 2008. May 2008.
8.2. Informative References 8.2. Informative References
[I-D.ietf-tsvwg-rsvp-proxy-approaches] [I-D.ietf-tsvwg-rsvp-proxy-approaches]
Faucheur, F., Manner, J., Wing, D., and L. Faucheur, "RSVP Faucheur, F., Guillou, A., Manner, J., and D. Wing, "RSVP
Proxy Approaches", Proxy Approaches",
draft-ietf-tsvwg-rsvp-proxy-approaches-07 (work in draft-ietf-tsvwg-rsvp-proxy-approaches-08 (work in
progress), May 2009. progress), October 2009.
[I-D.ietf-tsvwg-rsvp-security-groupkeying]
Behringer, M. and F. Faucheur, "Applicability of Keying
Methods for RSVP Security",
draft-ietf-tsvwg-rsvp-security-groupkeying-05 (work in
progress), June 2009.
[I-D.rahman-rtg-router-alert-considerations] [I-D.rahman-rtg-router-alert-considerations]
Faucheur, F., "IP Router Alert Considerations and Usage", Faucheur, F., "IP Router Alert Considerations and Usage",
draft-rahman-rtg-router-alert-considerations-02 (work in draft-rahman-rtg-router-alert-considerations-03 (work in
progress), July 2009. progress), October 2009.
[RFC3181] Herzog, S., "Signaled Preemption Priority Policy Element", [RFC3181] Herzog, S., "Signaled Preemption Priority Policy Element",
RFC 3181, October 2001. RFC 3181, October 2001.
[RFC4230] Tschofenig, H. and R. Graveman, "RSVP Security [RFC4230] Tschofenig, H. and R. Graveman, "RSVP Security
Properties", RFC 4230, December 2005. Properties", RFC 4230, December 2005.
Authors' Addresses Authors' Addresses
Francois Le Faucheur Francois Le Faucheur
 End of changes. 43 change blocks. 
117 lines changed or deleted 221 lines changed or added

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