draft-ietf-tsvwg-rsvp-proxy-proto-03.txt   draft-ietf-tsvwg-rsvp-proxy-proto-04.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: April 17, 2008 University of Helsinki Expires: June 16, 2008 University of Helsinki
A. Narayanan A. Narayanan
Cisco Cisco
A. Guillou A. Guillou
Neuf Neuf
H. Malik H. Malik
Bharti Bharti
October 15, 2007 December 14, 2007
RSVP Extensions for Path-Triggered RSVP Receiver Proxy RSVP Extensions for Path-Triggered RSVP Receiver Proxy
draft-ietf-tsvwg-rsvp-proxy-proto-03.txt draft-ietf-tsvwg-rsvp-proxy-proto-04.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 April 17, 2008. This Internet-Draft will expire on June 16, 2008.
Copyright Notice Copyright Notice
Copyright (C) The IETF Trust (2007). Copyright (C) The IETF Trust (2007).
Abstract Abstract
RSVP signaling can be used to make end-to-end resource reservations RSVP signaling can be used to make end-to-end resource reservations
in an IP network in order to guarantee the QoS required by certain in an IP network in order to guarantee the QoS required by certain
flows. With conventional RSVP, both the data sender and receiver of flows. With conventional RSVP, both the data sender and receiver of
skipping to change at page 3, line 17 skipping to change at page 3, line 17
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 . . . . . . . . . 10 3.1. Sender Notification via PathErr Message . . . . . . . . . 10
3.1.1. Composition of SESSION and <Sender descriptor> . . . . 12 3.1.1. Composition of SESSION and <Sender descriptor> . . . . 12
3.1.2. Composition of ERROR_SPEC . . . . . . . . . . . . . . 13 3.1.2. Composition of ERROR_SPEC . . . . . . . . . . . . . . 13
3.1.3. Use of Path_State_Removed Flag . . . . . . . . . . . . 14 3.1.3. Use of Path_State_Removed Flag . . . . . . . . . . . . 14
3.1.4. Use of PathErr by Regular Receivers . . . . . . . . . 15 3.1.4. Use of PathErr by Regular Receivers . . . . . . . . . 15
3.2. Sender Notification via Notify Message . . . . . . . . . . 16 3.2. Sender Notification via Notify Message . . . . . . . . . . 16
4. Security Considerations . . . . . . . . . . . . . . . . . . . 19 4. Security Considerations . . . . . . . . . . . . . . . . . . . 20
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23
6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 23 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 24
7. Normative References . . . . . . . . . . . . . . . . . . . . . 24 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 25
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 25 7.1. Normative References . . . . . . . . . . . . . . . . . . . 25
Intellectual Property and Copyright Statements . . . . . . . . . . 27 7.2. Informative References . . . . . . . . . . . . . . . . . . 25
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 26
Intellectual Property and Copyright Statements . . . . . . . . . . 28
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 4, line 28 skipping to change at page 4, line 28
are two distinct RSVP Proxy cases. In the first case, an entity in are two distinct RSVP Proxy cases. In the first case, an entity in
the network must operate on behalf of the data sender, generate RSVP the network must operate on behalf of the data sender, generate RSVP
Path messages, and eventually receive, process and sink Resv Path messages, and eventually receive, process and sink Resv
messages. We refer to this entity as the RSVP Sender Proxy. In the messages. We refer to this entity as the RSVP Sender Proxy. In the
second case, an entity in the network must receive Path messages sent second case, an entity in the network must receive Path messages sent
by a data sender (or by an RSVP Sender Proxy), and reply to those by a data sender (or by an RSVP Sender Proxy), and reply to those
with Resv messages generated on behalf of the data receiver(s). We with Resv messages generated on behalf of the data receiver(s). We
refer to this entity as the RSVP Receiver Proxy. refer to this entity as the RSVP Receiver Proxy.
RSVP Proxy approaches are presented in RSVP Proxy approaches are presented in
[I-D.ietf-tsvwg-rsvp-proxy-approaches-02.txt]. 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
uses the RSVP Path messages generated by the sender (or RSVP Sender uses the RSVP Path messages generated by the sender (or RSVP Sender
Proxy) as the cue for establishing the RSVP reservation on behalf of Proxy) as the cue for establishing the RSVP reservation on behalf of
the non-RSVP-capable receiver. The RSVP Receiver Proxy is the non-RSVP-capable receiver. The RSVP Receiver Proxy is
skipping to change at page 6, line 8 skipping to change at page 6, line 8
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
[I-D.ietf-tsvwg-rsvp-proxy-approaches-02.txt] and is used extensively [I-D.ietf-tsvwg-rsvp-proxy-approaches] and is used extensively in the
in the present document: present document:
o RSVP-capable (or RSVP-aware): supporting the RSVP protocol as per o RSVP-capable (or RSVP-aware): supporting the RSVP protocol as per
[RFC2205] [RFC2205]
o RSVP Receiver Proxy: an RSVP-capable router performing, on behalf o RSVP Receiver Proxy: an RSVP-capable router performing, on behalf
of a receiver, the RSVP operations which would normally be of a receiver, the RSVP operations which would normally be
performed by an RSVP-capable receiver if end-to-end RSVP signaling performed by an RSVP-capable receiver if end-to-end RSVP signaling
was used. Note that while RSVP is used upstream of the RSVP was used. Note that while RSVP is used upstream of the RSVP
Receiver Proxy, RSVP is not used downstream of the RSVP Receiver Receiver Proxy, RSVP is not used downstream of the RSVP Receiver
Proxy. Proxy.
skipping to change at page 7, line 13 skipping to change at page 7, line 13
[RFC2205]. [RFC2205].
3. RSVP Extensions for Sender Notification 3. RSVP Extensions for Sender Notification
This section defines extensions to RSVP procedures allowing sender This section defines extensions to RSVP procedures allowing sender
notification of reservation failure. This facilitates notification of reservation failure. This facilitates
synchronization by the sender between RSVP reservation and synchronization by the sender between RSVP reservation and
application requirements in scenarios involving a Path-Triggered RSVP application requirements in scenarios involving a Path-Triggered RSVP
Receiver Proxy. Receiver Proxy.
As discussed in [I-D.ietf-tsvwg-rsvp-proxy-approaches-02.txt], with As discussed in [I-D.ietf-tsvwg-rsvp-proxy-approaches], with the
the Path-Triggered RSVP Receiver Proxy approach, the RSVP router may Path-Triggered RSVP Receiver Proxy approach, the RSVP router may be
be configured to use receipt of a regular RSVP Path message as the configured to use receipt of a regular RSVP Path message as the
trigger for RSVP Receiver Proxy behavior. On receipt of the RSVP trigger for RSVP Receiver Proxy behavior. On receipt of the RSVP
Path message, the RSVP Receiver Proxy: Path message, the RSVP Receiver Proxy:
1. establishes the RSVP Path state as per regular RSVP processing 1. establishes the RSVP Path state as per regular RSVP processing
2. identifies the downstream interface towards the receiver 2. identifies the downstream interface towards the receiver
3. sinks the Path message 3. sinks the Path message
4. behaves as if a Resv message (whose details are discussed below) 4. behaves as if a Resv message (whose details are discussed below)
skipping to change at page 16, line 32 skipping to change at page 16, line 32
o allow the failure notification to travel directly to the sender o allow the failure notification to travel directly to the sender
without hop-by-hop RSVP processing without hop-by-hop RSVP processing
o ensure that such a notification is only sent to senders which are o ensure that such a notification is only sent to senders which are
capable and willing to process it (i.e. to synchronize reservation capable and willing to process it (i.e. to synchronize reservation
status with application) status with application)
o ensure that such a notification is only sent in case the receiver o ensure that such a notification is only sent in case the receiver
is not itself capable and willing to do the synchronisation with is not itself capable and willing to do the synchronisation with
the application (i.e. because we are in the presence of a receiver the application (i.e. because we are in the presence of a receiver
proxy so that RSVP signaling is not visible to the receiver) proxy so that RSVP signaling is not visible to the receiver).
Note, however, that such benefits come at the cost of more Note, however, that such benefits come at the cost of :
sophistication and of a requirement for RSVP routers and senders to
support the Notify messages and procedures defined in [RFC3473]. o a requirement for RSVP routers and senders to support the Notify
messages and procedures defined in [RFC3473]
o a requirement for senders to process Notify messages traveling
upstream but conveying a downstream notification.
[RFC3473] defines (in section "4.3 Notify Messages") the Notify [RFC3473] defines (in section "4.3 Notify Messages") the Notify
message that provides a mechanism to inform non-adjacent nodes of message that provides a mechanism to inform non-adjacent nodes of
events related to the RSVP reservation. The Notify message differs events related to the RSVP reservation. The Notify message differs
from the error messages defined in [RFC2205] (i.e., PathErr and from the error messages defined in [RFC2205] (i.e., PathErr and
ResvErr messages) in that it can be "targeted" to a node other than ResvErr messages) in that it can be "targeted" to a node other than
the immediate upstream or downstream neighbor and that it is a the immediate upstream or downstream neighbor and that it is a
generalized notification mechanism. Notify messages are normally generalized notification mechanism. Notify messages are normally
generated only after a Notify Request object has been received. generated only after a Notify Request object has been received.
skipping to change at page 18, line 15 skipping to change at page 18, line 15
|----| *** *** *** |----------| |----| |----| *** *** *** |----------| |----|
| S |--------*r*--------*r*--------*r*--------| RSVP |------| R | | S |--------*r*--------*r*--------*r*--------| RSVP |------| R |
|----| *** *** *** | Receiver | |----| |----| *** *** *** | Receiver | |----|
| Proxy | | Proxy |
|----------| |----------|
************************************************************> ************************************************************>
===================RSVP===================> ===================RSVP===================>
--Path---> --Path---> --Path---> --Path---> --Path*--> --Path*--> --Path*--> --Path*-->
<---Resv-- <---Resv-- <--Resv*-- <--Resv*--
<------Notify------- <------Notify-------
-ResvErr-> -ResvErr-> -ResvErr-> -ResvErr->
|----| |----| *** |----| |----| ***
| S | Sender | R | Receiver *r* regular RSVP | S | Sender | R | Receiver *r* regular RSVP
|----| |----| *** router |----| |----| *** router
***> media flow ***> media flow
skipping to change at page 19, line 5 skipping to change at page 18, line 48
Figure 4: Reservation Failure With Sender Notification via Notify Figure 4: Reservation Failure With Sender Notification via Notify
For local failures on the Receiver Proxy node, if a similar failure For local failures on the Receiver Proxy node, if a similar failure
on an RSVP midpoint would cause the generation of a ResvErr (for on an RSVP midpoint would cause the generation of a ResvErr (for
example, CAC failure), the Receiver Proxy MUST generate a Notify example, CAC failure), the Receiver Proxy MUST generate a Notify
towards the sender. The Receiver Proxy MAY additionally generate a towards the sender. The Receiver Proxy MAY additionally generate a
Notify upon local failures which would not ordinarily cause Notify upon local failures which would not ordinarily cause
generation of a ResvErr message, such as described in Appendix B of generation of a ResvErr message, such as described in Appendix B of
[RFC2205]. [RFC2205].
When the method of sender notification via Notify message is used, it
is RECOMMENDED that the RSVP Receiver Proxy also issues sender
notification via a PathErr message. This maximizes the chances that
the notification reaches the sender in all situations (e.g. even if
some RSVP routers do not support the Notify procedure, or if a Notify
message gets dropped). However, for controlled environments (e.g.
where all RSVP routers are known to support Notify procedures) and
where it is desirable to minimize the volume of signaling, the RSVP
Receiver Proxy MAY rely exclusively on sender notification via Notify
message and thus not issue sender notification via PathErr message.
4. Security Considerations 4. Security Considerations
To ensure the integrity of the associated reservation and admission To ensure the integrity of the associated reservation and admission
control mechanisms, the RSVP Authentication mechanisms defined in control mechanisms, the RSVP Authentication mechanisms defined in
[RFC2747] and [RFC3097] may be used. These protect RSVP message [RFC2747] and [RFC3097] may be used. Those protect RSVP message
integrity hop-by-hop and provide node authentication as well as integrity hop-by-hop and provide node authentication as well as
replay protection, thereby protecting against corruption and spoofing replay protection, thereby protecting against corruption and spoofing
of RSVP messages. These hop-by-hop integrity mechanisms can be used of RSVP messages. These hop-by-hop integrity mechanisms can be used
to protect the RSVP reservations established using an RSVP receiver to protect the RSVP reservations established using an RSVP receiver
proxy in accordance with the present document. proxy in accordance with the present document.
[RFC2747] discusses several approaches for key distribution. First, [RFC2747] discusses several approaches for key distribution. First,
the RSVP Authentication shared keys can be distributed manually. the RSVP Authentication shared keys can be distributed manually.
This is the base option and its support is mandated for any This is the base option and its support is mandated for any
implementation. However, in some environments, this approach may implementation. However, in some environments, this approach may
skipping to change at page 19, line 45 skipping to change at page 20, line 45
situation, one approach is to share the same RSVP Authentication situation, one approach is to share the same RSVP Authentication
shared key across all the RSVP routers of a part of the network where 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, there may be RSVP neighbors with IP hops in between. For example,
all the RSVP routers of an administrative domain (including the all the RSVP routers of an administrative domain (including the
receiver proxys) could share the same RSVP Authentication key, while receiver proxys) could share the same RSVP Authentication key, while
different per-neighbor keys could be used between any RSVP router different per-neighbor keys could be used between any RSVP router
pair straddling the boundary between two administrative domains that pair straddling the boundary between two administrative domains that
have agreed to use RSVP signaling. have agreed to use RSVP signaling.
When the same RSVP Authentication shared key is to be shared among When the same RSVP Authentication shared key is to be shared among
multiple RSVP neighbors, manual key distribution may be used. It multiple RSVP neighbors, manual key distribution may be used.
might also be possible, in the future, to adapt a multicast dynamic [I-D.behringer-tsvwg-rsvp-security-groupkeying] also discusses
group key distribution method (e.g. from IETF Multicast Security applicability of dynamic group key distribution method for dynamic
Working Group) for dynamic key distribution among RSVP nodes. This update of such shared keys among RSVP routers.
is discussed in
[I-D.behringer-tsvwg-rsvp-security-groupkeying-00.txt]. 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. The RSVP Authentication mechanisms do not provide confidentiality.
If confidentiality is required, IPsec ESP ([RFC4303]) may be used, If confidentiality is required, IPsec ESP ([RFC4303]) may be used,
although it imposes the burden of key distribution. It also faces although it imposes the burden of key distribution. It also faces
the additional issue discussed for key management above in the case the additional issue discussed for key management above in the case
where there can be IP hops in between RSVP hops. In the future, where there can be IP hops in between RSVP hops.
confidentiality solutions may be developed for the case where there [I-D.behringer-tsvwg-rsvp-security-groupkeying] discusses
can be IP hops in between RSVP hops, perhaps again by adapting applicability of various keying methods for applying IPsec encryption
confidentiality solutions developed by the IETF MSEC Working Group. and authentication to RSVP, including use of group keys and dynamic
Such confidentiality solutions for RSVP are outside the scope of this group key distribution.
document.
When an RSVP receiver proxy is used, the RSVP reservation is no When an RSVP receiver proxy is used, the RSVP reservation is no
longer controlled by the receiver, but rather is controlled by the longer controlled by the receiver, but rather is controlled by the
receiver proxy (using hints received from the sender in the Path receiver proxy (using hints received from the sender in the Path
message) on behalf of the sender. Thus, the receiver proxy ought to message) on behalf of the sender. Thus, the receiver proxy ought to
be trusted by the end-systems to control the RSVP reservation be trusted by the end-systems to control the RSVP reservation
appropriately. However, basic RSVP operation already assumes a trust appropriately. However, basic RSVP operation already assumes a trust
model where end-systems trust RSVP nodes to appropriately perform model where end-systems trust RSVP nodes to appropriately perform
RSVP reservations. So the use of RSVP receiver proxy is not seen as RSVP reservations. So the use of RSVP receiver proxy is not seen as
introducing any significant additional security threat or as introducing any significant additional security threat or as
modifying the RSVP trust model. modifying the RSVP trust model.
In fact, there are situations where the use of RSVP receiver proxy In fact, there are situations where the use of RSVP receiver proxy
reduces the security risks. One example is where a network operator reduces the security risks. One example is where a network operator
relies on RSVP to perform resource reservation and admission control relies on RSVP to perform resource reservation and admission control
within a network and where RSVP senders and RSVP routers are located within a network and where RSVP senders and RSVP routers are located
in the operator premises while the many RSVP receivers are located in in the operator premises while the many RSVP receivers are located in
the operator's customers premises. Such an environment is further the operator's customers premises. Such an environment is further
illustrated in "Annex A.1. RSVP-based VoD CAC in Broadband illustrated in "Annex A.1. RSVP-based VoD CAC in Broadband
Aggregation Networks" of Aggregation Networks" of [I-D.ietf-tsvwg-rsvp-proxy-approaches].
[I-D.ietf-tsvwg-rsvp-proxy-approaches-02.txt]. From the operator's From the operator's perspective, the RSVP routers and RSVP senders
perspective, the RSVP routers and RSVP senders are in physically are in physically secured locations and therefore exposed to a lower
secured locations and therefore exposed to a lower risk of being risk of being tampered with; While the receivers are in locations
tampered with; While the receivers are in locations which are which are physically unsecured and therefore subject to a higher risk
physically unsecured and therefore subject to a higher risk of being of being tampered with. The use of an RSVP receiver proxy function
tampered with. The use of an RSVP receiver proxy function
effectively increases the security of the operator's reservation and effectively increases the security of the operator's reservation and
admission control solution by completely excluding receivers from its admission control solution by completely excluding receivers from its
operation. Filters can be placed at the edge of the operator network operation. Filters can be placed at the edge of the operator network
discarding any RSVP message received from end-users. This provides a discarding any RSVP message received from end-users. This provides a
very simple and effective protection of the RSVP reservation and very simple and effective protection of the RSVP reservation and
admission control solution operating inside the operator's network. admission control solution operating inside the operator's network.
This document defines in Section 3.2 an optional method relying on This document defines in Section 3.2 an optional method relying on
the use of the Notify message specified in [RFC3473]. The Notify the use of the Notify message specified in [RFC3473]. The Notify
message can be sent in a non-hop-by-hop fashion that precludes RSVP's message can be sent in a non-hop-by-hop fashion that precludes RSVP's
hop-by-hop integrity and authentication model. The approaches and hop-by-hop integrity and authentication model. The approaches and
considerations for addressing this issue presented in the Security considerations for addressing this issue presented in the Security
Considerations section of [RFC3473] apply. In particular, where the Considerations section of [RFC3473] apply. In particular, where the
Notify messages are transmitted non-hop-by-hop and the same level of Notify messages are transmitted non-hop-by-hop and the same level of
security provided by [RFC2747] is desired, the standard IPsec based security provided by [RFC2747] is desired, the standard IPsec based
integrity and authentication can be used. Alternatively, the sending integrity and authentication can be used. Alternatively, the sending
of non-hop-by-hop Notify messages can be disabled. of non-hop-by-hop Notify messages can be disabled. Finally,
[I-D.behringer-tsvwg-rsvp-security-groupkeying] discusses
applicability of group keying for non-hop-by-hop Notify messages.
5. IANA Considerations 5. IANA Considerations
Since, as discussed in Section 3.1.2, this document allows two Error Since, as discussed in Section 3.1.2, this document allows two Error
Codes to be used in PathErr messages while [RFC2205] only specified Codes to be used in PathErr messages while [RFC2205] only specified
their use in ResvErr messages, this document requires that IANA their use in ResvErr messages, this document requires that IANA
updates the existing entries for these two Error Codes under the updates the existing entries for these two Error Codes under the
"Error Codes and Globally-Defined Error Value Sub-Codes" registry. "Error Codes and Globally-Defined Error Value Sub-Codes" registry.
Each entry should refer to this document, in addition to referring to Each entry should refer to this document, in addition to referring to
[RFC2205]. Specifically, the entry for Error Code 1 and Error Code 2 [RFC2205]. Specifically, the entry for Error Code 1 and Error Code 2
skipping to change at page 23, line 11 skipping to change at page 24, line 11
where [RFCXXX] refers to this document and TBD is the value to be where [RFCXXX] refers to this document and TBD is the value to be
allocated by IANA. 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
Anca Zamfir. Lou Berger, Adrian Farrel and John Drake provided Anca Zamfir. Lou Berger, Adrian Farrel and John Drake provided
review and guidance, in particular on the usage of the review and guidance, in particular on the usage of the
Path_State_Removed flag and of the Notify message, both borrowed from Path_State_Removed flag and of the Notify message, both borrowed from
[RFC3473]. We also thank Ken Carlberg for his complete review of the [RFC3473]. We also thank Ken Carlberg for his valuable input.
document and suggestions.
7. Normative References 7. References
[I-D.behringer-tsvwg-rsvp-security-groupkeying-00.txt] 7.1. Normative References
Behringer, M. and F. Le Faucheur, "A Framework for RSVP
Security Using Dynamic Group Keying", July 2007.
[I-D.ietf-tsvwg-rsvp-proxy-approaches-02.txt] [I-D.ietf-tsvwg-rsvp-proxy-approaches]
Le Faucheur, F., Manner, J., Wing, D., and A. Guillou, Le Faucheur, F., Manner, J., Wing, D., and A. Guillou,
"RSVP Proxy Approaches", September 2007. "RSVP Proxy Approaches", December 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 [RFC2747] Baker, F., Lindell, B., and M. Talwar, "RSVP Cryptographic
Authentication", RFC 2747, January 2000. Authentication", RFC 2747, January 2000.
skipping to change at page 25, line 5 skipping to change at page 25, line 38
and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP
Tunnels", RFC 3209, December 2001. 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)", [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)",
RFC 4303, December 2005. RFC 4303, December 2005.
7.2. Informative References
[I-D.behringer-tsvwg-rsvp-security-groupkeying]
Behringer, M. and F. Le Faucheur, "Applicability of Keying
Methods for RSVP Security", November 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
 End of changes. 24 change blocks. 
54 lines changed or deleted 69 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/