draft-ietf-tsvwg-rsvp-proxy-proto-04.txt   draft-ietf-tsvwg-rsvp-proxy-proto-05.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: June 16, 2008 University of Helsinki Expires: October 27, 2008 University of Helsinki
A. Narayanan A. Narayanan
Cisco Cisco
A. Guillou A. Guillou
Neuf Neuf
H. Malik H. Malik
Bharti Bharti
December 14, 2007 April 25, 2008
RSVP Extensions for Path-Triggered RSVP Receiver Proxy RSVP Extensions for Path-Triggered RSVP Receiver Proxy
draft-ietf-tsvwg-rsvp-proxy-proto-04.txt draft-ietf-tsvwg-rsvp-proxy-proto-05.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 June 16, 2008. This Internet-Draft will expire on October 27, 2008.
Copyright Notice
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
skipping to change at page 4, line 18 skipping to change at page 4, line 18
be achieved by reserving resources in each node on the end-to-end be achieved by reserving resources in each node on the end-to-end
path. The main IETF protocol for these resource reservations is RSVP path. The main IETF protocol for these resource reservations is RSVP
specified in [RFC2205]. RSVP does not require that all intermediate specified in [RFC2205]. RSVP does not require that all intermediate
nodes support RSVP, but it assumes that both the sender and the nodes support RSVP, but it assumes that both the sender and the
receiver of the data flow support RSVP. However, there are receiver of the data flow support RSVP. However, there are
environments where it would be useful to be able to reserve resources environments where it would be useful to be able to reserve resources
for a flow (at least a subset of the flow path) even when the sender for a flow (at least a subset of the flow path) even when the sender
or the receiver (or both) is not RSVP-capable. or the receiver (or both) is not RSVP-capable.
Since both the data sender and receiver may be unaware of RSVP, there Since both the data sender and receiver may be unaware of RSVP, there
are two distinct RSVP Proxy cases. In the first case, an entity in are two types of RSVP Proxies. In the first case, an entity in the
the network must operate on behalf of the data sender, generate RSVP network needs to operate RSVP on behalf of the data sender and thus
Path messages, and eventually receive, process and sink Resv generate RSVP Path messages, and eventually receive, process and sink
messages. We refer to this entity as the RSVP Sender Proxy. In the Resv messages. We refer to this entity as the RSVP Sender Proxy. In
second case, an entity in the network must receive Path messages sent the second case, an entity in the network need to operate RSVP on
by a data sender (or by an RSVP Sender Proxy), and reply to those behalf of the receiver and thus receive Path messages sent by a data
with Resv messages generated on behalf of the data receiver(s). We sender (or by an RSVP Sender Proxy), and reply to those with Resv
refer to this entity as the RSVP Receiver Proxy. messages generated on behalf of the data receiver(s). We 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 and tear down the RSVP reservation (e.g. when to establish, maintain and tear down the RSVP reservation
to satisfy application requirements). to satisfy application requirements).
One RSVP Proxy approach is referred to as the Path-Triggered RSVP One RSVP Proxy approach is referred to as the Path-Triggered RSVP
Receiver Proxy approach. With this approach, the RSVP Receiver Proxy Receiver Proxy approach. With this approach, the RSVP Receiver Proxy
skipping to change at page 5, line 15 skipping to change at page 5, line 16
some notifications about reservation state (notably the error message some notifications about reservation state (notably the error message
sent in case of admission control rejection of the reservation) are sent in case of admission control rejection of the reservation) are
only sent towards the receiver and therefore, in our case, sunk by only sent towards the receiver and therefore, in our case, sunk by
the RSVP Receiver Proxy. This document specifies extension to RSVP the RSVP Receiver Proxy. This document specifies extension to RSVP
procedures allowing such notifications to be also conveyed towards procedures allowing such notifications to be also conveyed towards
the sender. This facilitates synchronization by the sender (or RSVP the sender. This facilitates synchronization by the sender (or RSVP
Sender Proxy) between RSVP reservation and application requirements Sender Proxy) between RSVP reservation and application requirements
in scenarios involving a Path-Triggered RSVP receiver Proxy. in scenarios involving a Path-Triggered RSVP receiver Proxy.
This document discusses extension to facilitate operations in the This document discusses extension to facilitate operations in the
presence of an RSVP Receiver Proxy. As explicitly pointed out in the presence of a Path-triggered RSVP Receiver Proxy. As explicitly
text above, those apply equally whether RSVP signaling is initiated pointed out in the text above, those apply equally whether RSVP
by a regular RSVP sender or by an RSVP Sender Proxy (with some means signaling is initiated by a regular RSVP sender or by an RSVP Sender
to synchronize reservation state with application level requirements Proxy (with some means to synchronize reservation state with
that are outside the scope of this document). For readability, the application level requirements that are outside the scope of this
rest of this document discusses operation assuming a regular RSVP document). For readability, the rest of this document discusses
sender; however, such operation is equally applicable where an RSVP operation assuming a regular RSVP sender; however, such operation is
Sender Proxy is used to initiated RSVP signaling on behalf of a non- equally applicable where an RSVP Sender Proxy is used to initiated
RSVP-capable sender. RSVP signaling on behalf of a non-RSVP-capable sender.
1.1. Conventions Used in This Document 1.1. Conventions Used in This Document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
2. Terminology 2. Terminology
The following terminology is borrowed from The following terminology is borrowed from
skipping to change at page 6, line 30 skipping to change at page 6, line 30
o RSVP Sender Proxy: an RSVP-capable router performing, on behalf of o RSVP Sender Proxy: an RSVP-capable router performing, on behalf of
a sender, the RSVP operations which would normally be performed by a sender, the RSVP operations which would normally be performed by
an RSVP-capable sender if end-to-end RSVP signaling was used. an RSVP-capable sender if end-to-end RSVP signaling was used.
Note that while RSVP is used downstream of the RSVP Sender Proxy, Note that while RSVP is used downstream of the RSVP Sender Proxy,
RSVP is not used upstream of the RSVP Sender Proxy. RSVP is not used upstream of the RSVP Sender Proxy.
o Regular RSVP Router: an RSVP-capable router which is not behaving o Regular RSVP Router: an RSVP-capable router which is not behaving
as a RSVP Receiver Proxy nor as a RSVP Sender Proxy. as a RSVP Receiver Proxy nor as a RSVP Sender Proxy.
o Note that the roles of RSVP Receiver Proxy, RSVP Sender Proxy, Note that the roles of RSVP Receiver Proxy, RSVP Sender Proxy,
Regular RSVP Router are all relative to one unidirectional flow. Regular RSVP Router are all relative to one unidirectional flow. A
A given router may act as the RSVP Receiver Proxy for a flow, as given router may act as the RSVP Receiver Proxy for a flow, as the
the RSVP Sender Proxy for another flow and as a Regular RSVP RSVP Sender Proxy for another flow and as a Regular RSVP router for
router for yet another flow. yet another flow.
The following terminology is also used in the present document: The following terminology is also used in the present document:
o Regular RSVP Sender: an RSVP-capable host behaving as the sender o Regular RSVP Sender: an RSVP-capable host behaving as the sender
for the considered flow and participating in RSVP signaling in for the considered flow and participating in RSVP signaling in
accordance with the sender behavior specified in [RFC2205]. accordance with the sender behavior specified in [RFC2205].
o Regular RSVP Receiver: an RSVP-capable host behaving as the o Regular RSVP Receiver: an RSVP-capable host behaving as the
receiver for the considered flow and participating in RSVP receiver for the considered flow and participating in RSVP
signaling in accordance with the receiver behavior specified in signaling in accordance with the receiver behavior specified in
skipping to change at page 8, line 11 skipping to change at page 8, line 11
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 |
|----------| |----------|
************************************************************>
===================RSVP===================>
--Path---> --Path---> --Path---> --Path---> --Path---> --Path---> --Path---> --Path--->
<---Resv-- <---Resv-- <---Resv-- <---Resv-- <---Resv-- <---Resv-- <---Resv-- <---Resv--
===================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 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 11 skipping to change at page 9, line 11
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 |
|----------| |----------|
************************************************************>
===================RSVP===================>
--Path---> --Path---> --Path---> --Path---> --Path---> --Path---> --Path---> --Path--->
<---Resv-- <---Resv-- <---Resv-- <---Resv--
-ResvErr-> -ResvErr-> -ResvErr-> -ResvErr->
===================RSVP===================>
************************************************************>
|----| |----| *** |----| |----| ***
| S | Sender | R | Receiver *r* regular RSVP | S | Sender | R | Receiver *r* regular RSVP
|----| |----| *** router |----| |----| *** router
***> media flow ***> media flow
==> segment of flow path 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
skipping to change at page 11, line 11 skipping to change at page 11, line 11
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 |
|----------| |----------|
************************************************************>
===================RSVP===================>
--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===================>
************************************************************>
|----| |----| *** |----| |----| ***
| 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 to be protected by RSVP reservation
(but not protected in this case since reservation failed)
Figure 3: Reservation Failure With Sender Notification via PathErr Figure 3: Reservation Failure With Sender Notification via PathErr
The role of this PathErr is to notify the sender that the reservation The role of this PathErr is to notify the sender that the reservation
was not established or was torn down. This may be in the case of was not established or was torn down. This may be in the case of
receipt of a ResvErr, or because of local failure on the Receiver receipt of a ResvErr, or because of local failure on the Receiver
Proxy. On receipt of a ResvErr, in all situations where the Proxy. On receipt of a ResvErr, in all situations where the
reservation cannot be installed, the Receiver Proxy MUST generate a reservation cannot be installed, the Receiver Proxy MUST generate a
PathErr towards the sender. For local failures on the Receiver Proxy PathErr towards the sender. For local failures on the Receiver Proxy
node, if a similar failure on an RSVP midpoint would cause the node, if a similar failure on an RSVP midpoint would cause the
skipping to change at page 14, line 42 skipping to change at page 14, line 42
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 This section discusses aspects of the use of the Path_State_Removed
flag that are specific to the RSVP Receiver Proxy. In any other flag that are specific to the RSVP Receiver Proxy. In any other
aspects, the Path_State_Removed flag operates as per [RFC3473]. aspects, the Path_State_Removed flag operates as per [RFC3473].
By default, the RSVP Receiver Proxy MUST not include the By default, the RSVP Receiver Proxy MUST NOT include the
Path_State_Removed flag in the ERROR_SPEC of the PathErr message. Path_State_Removed flag in the ERROR_SPEC of the PathErr message.
This ensures predictable operations in all environments including This ensures predictable operations in all environments including
those where some RSVP routers do not understand the those where some RSVP routers do not understand the
Path_State_Removed flag. Path_State_Removed flag.
Optionally, the RSVP Receiver Proxy MAY support an optional mode that The RSVP Receiver Proxy MAY support an OPTIONAL mode to be activated
can be activated by configuration whereby the RSVP Receiver Proxy by configuration whereby the RSVP Receiver Proxy includes the
includes the Path_State_Removed flag in the ERROR_SPEC of the PathErr Path_State_Removed flag in the ERROR_SPEC of the PathErr message and
message and removes its local Path state. Where all routers on the removes its local Path state. Where all routers on the path of a
path of a reservation support the Path_State_Removed flag, its use reservation support the Path_State_Removed flag, its use will indeed
will indeed result in expedited resource release and reduced result in expedited resource release and reduced signaling. However,
signaling. However, if there is one (or more) "old" router on the if there is one (or more) RSVP router on the path of the reservation
path of the reservation that does not support the Path_State_Removed that does not support the Path_State_Removed flag (we refer to such a
flag, its use will actually result in slower resource release and router as an "old RSVP router"), the use of the Path_State_Removed
increased signaling. This is because the Path_State_Removed flag flag will actually result in slower resource release and increased
will be propagated upstream by an "old" router (even if it does not signaling. This is because the Path_State_Removed flag will be
propagated upstream by an old RSVP router (even if it does not
understand it and does not tear its Path state). Thus, the sender understand it and does not tear its Path state). Thus, the sender
will not send a Path Tear and the "old" router will only release its will not send a Path Tear and the old RSVP router will only release
Path state through refresh time-out. A network administrator needs its Path state through refresh time-out. A network administrator
to keep these considerations in mind when deciding whether to needs to keep these considerations in mind when deciding whether to
activate the use of the Path_State_Removed flag on the RSVP Receiver activate the use of the Path_State_Removed flag on the RSVP Receiver
Proxy. In a controlled environment where all routers are known to Proxy. In a controlled environment where all routers are known to
support the Path_State_Removed flag, its use can be safely activated support the Path_State_Removed flag, its use can be safely activated
on the RSVP Receiver Proxy. In other environments, the network on the RSVP Receiver Proxy. In other environments, the network
administrator needs to assess whether the improvement achieved with administrator needs to assess whether the improvement achieved with
some reservations outweighs the degradation experienced by other some reservations outweighs the degradation experienced by other
reservations. reservations.
3.1.4. Use of PathErr by Regular Receivers 3.1.4. Use of PathErr by Regular Receivers
skipping to change at page 18, line 11 skipping to change at page 18, line 11
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*--------*r*--------| RSVP |------| R | | S |--------*r*--------*r*--------*r*--------| RSVP |------| R |
|----| *** *** *** | Receiver | |----| |----| *** *** *** | Receiver | |----|
| Proxy | | Proxy |
|----------| |----------|
************************************************************>
===================RSVP===================>
--Path*--> --Path*--> --Path*--> --Path*--> --Path*--> --Path*--> --Path*--> --Path*-->
<--Resv*-- <--Resv*-- <--Resv*-- <--Resv*--
<------Notify------- <------Notify-------
-ResvErr-> -ResvErr-> -ResvErr-> -ResvErr->
===================RSVP===================>
************************************************************>
|----| |----| *** |----| |----| ***
| S | Sender | R | Receiver *r* regular RSVP | S | Sender | R | Receiver *r* regular RSVP
|----| |----| *** router |----| |----| *** router
***> media flow ***> media flow
==> segment of flow path protected by RSVP reservation ==> segment of flow path to be protected by RSVP reservation
(but not protected in this case since reservation failed)
Path* = Path message containing a Notify Request object 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 Notify = Notify message
Figure 4: Reservation Failure With Sender Notification via Notify Figure 4: Reservation Failure With Sender Notification via Notify
skipping to change at page 28, line 7 skipping to change at page 28, line 7
Hemant Malik Hemant Malik
Bharti Airtel Ltd. Bharti Airtel Ltd.
4th Floor, Tower A, Unitech Cyber Park 4th Floor, Tower A, Unitech Cyber Park
Gurgaon, Sector 39, 122001 Gurgaon, Sector 39, 122001
India India
Email: Hemant.Malik@airtel.in Email: Hemant.Malik@airtel.in
Full Copyright Statement Full Copyright Statement
Copyright (C) The IETF Trust (2007). Copyright (C) The IETF Trust (2008).
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
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
skipping to change at page 28, line 44 skipping to change at line 986
attempt made to obtain a general license or permission for the use of attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr. http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at this standard. Please address the information to the IETF at
ietf-ipr@ietf.org. ietf-ipr@ietf.org.
Acknowledgment
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
 End of changes. 22 change blocks. 
64 lines changed or deleted 64 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/