draft-ietf-tsvwg-rsvp-proxy-proto-02.txt   draft-ietf-tsvwg-rsvp-proxy-proto-03.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 13, 2008 University of Helsinki Expires: April 17, 2008 University of Helsinki
A. Narayanan A. Narayanan
Cisco Cisco
A. Guillou A. Guillou
Neuf Neuf
H. Malik H. Malik
Bharti Bharti
October 11, 2007 October 15, 2007
RSVP Extensions for Path-Triggered RSVP Receiver Proxy RSVP Extensions for Path-Triggered RSVP Receiver Proxy
draft-ietf-tsvwg-rsvp-proxy-proto-02.txt draft-ietf-tsvwg-rsvp-proxy-proto-03.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 13, 2008. This Internet-Draft will expire on April 17, 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 20 skipping to change at page 3, line 20
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 . . . . . . . . . . . . . . . . . . . 19
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22
6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 23 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 23
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 24 7. Normative References . . . . . . . . . . . . . . . . . . . . . 24
7.1. Normative References . . . . . . . . . . . . . . . . . . . 24
7.2. Informative References . . . . . . . . . . . . . . . . . . 24
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 25 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 25
Intellectual Property and Copyright Statements . . . . . . . . . . 27 Intellectual Property and Copyright Statements . . . . . . . . . . 27
1. Introduction 1. Introduction
Guaranteed QoS for some applications with tight Qos requirements may Guaranteed QoS for some applications with tight Qos requirements may
be achieved by reserving resources in each node on the end-to-end be achieved by reserving resources in each node on the end-to-end
path. The main IETF protocol for these resource reservations is RSVP path. The main IETF protocol for these resource reservations is RSVP
specified in [RFC2205]. RSVP does not require that all intermediate specified in [RFC2205]. RSVP does not require that all intermediate
nodes support RSVP, but it assumes that both the sender and the nodes support RSVP, but it assumes that both the sender and the
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]. That document also [I-D.ietf-tsvwg-rsvp-proxy-approaches-02.txt]. 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 5, line 15 skipping to change at page 5, line 15
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 explicitely pointed out in presence of an RSVP Receiver Proxy. As explicitly pointed out in the
the text above, those apply equally whether RSVP signaling is text above, those apply equally whether RSVP signaling is initiated
initiated by a regular RSVP sender or by an RSVP Sender Proxy (with by a regular RSVP sender or by an RSVP Sender Proxy (with some means
some means to synchronize reservation state with application level to synchronize reservation state with application level requirements
requirements that are outside the scope of this document). For that are outside the scope of this document). For readability, the
readability, the rest of this document discusses operation assuming a rest of this document discusses operation assuming a regular RSVP
regular RSVP sender; however, such operation is equallly applicable sender; however, such operation is equally applicable where an RSVP
where an RSVP Sender Proxy is used to initiated RSVP signaling on Sender Proxy is used to initiated RSVP signaling on behalf of a non-
behalf of a non-RSVP-capable sender. 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
[I-D.ietf-tsvwg-rsvp-proxy-approaches] and is used extensively in the [I-D.ietf-tsvwg-rsvp-proxy-approaches-02.txt] and is used extensively
present document: in the 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], with the As discussed in [I-D.ietf-tsvwg-rsvp-proxy-approaches-02.txt], with
Path-Triggered RSVP Receiver Proxy approach, the RSVP router may be the Path-Triggered RSVP Receiver Proxy approach, the RSVP router may
configured to use receipt of a regular RSVP Path message as the be 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 9, line 35 skipping to change at page 9, line 35
***> media flow ***> media flow
==> segment of flow path protected by RSVP reservation ==> segment of flow path protected by RSVP reservation
Figure 2: Reservation Failure With Conventional RSVP Figure 2: Reservation Failure With Conventional RSVP
While the sender could infer reservation failure from the fact that While the sender could infer reservation failure from the fact that
it has not received a Resv message after a certain time, there are it has not received a Resv message after a certain time, there are
clear benefits in ensuring that the sender gets a prompt explicit clear benefits in ensuring that the sender gets a prompt explicit
notification in case of reservation failure. This includes faster notification in case of reservation failure. This includes faster
enduser notification at application layer (e.g. busy signal), faster end-user notification at application layer (e.g. busy signal), faster
application level reaction (e.g. application level rerouting), as application level reaction (e.g. application level rerouting), as
well as faster release of application-level resources. well as faster release of application-level resources.
Section 3.1 defines a method which can be used to achieve sender Section 3.1 defines a method which can be used to achieve sender
notification of reservation failure. A router implementation notification of reservation failure. A router implementation
claiming compliance with this document MUST support the method claiming compliance with this document MUST support the method
defined in Section 3.1. defined in Section 3.1.
Section 3.2 defines another method which can be used to achieve Section 3.2 defines another method which can be used to achieve
sender notification of reservation failure. A router implementation sender notification of reservation failure. A router implementation
skipping to change at page 13, line 12 skipping to change at page 13, line 12
the failed reservation, into the PathErr. For Fixed-Filter (FF) the failed reservation, into the PathErr. For Fixed-Filter (FF)
style reservations, the Receiver Proxy MUST insert a <sender style reservations, the Receiver Proxy MUST insert a <sender
descriptor> corresponding to the failed reservation, into the descriptor> corresponding to the failed reservation, into the
PathErr. This is equal to the <flow descriptor> in the ResvErr PathErr. This is equal to the <flow descriptor> in the ResvErr
received by the Receiver Proxy. For Shared-Explicit (SE) style received by the Receiver Proxy. For Shared-Explicit (SE) style
reservations, the Receiver Proxy MUST insert a <sender descriptor> reservations, the Receiver Proxy MUST insert a <sender descriptor>
corresponding to the sender triggering the failed reservation, into corresponding to the sender triggering the failed reservation, into
the PathErr. This is equal to the <flow descriptor> in the ResvErr the PathErr. This is equal to the <flow descriptor> in the ResvErr
received by the Receiver Proxy. If multiple <flow descriptors> could received by the Receiver Proxy. If multiple <flow descriptors> could
not be admitted at a midpoint node, that node would generate multiple not be admitted at a midpoint node, that node would generate multiple
ResvErrs messages towards the receiver as per Section 3.1.8 of ResvErr messages towards the receiver as per Section 3.1.8 of
[RFC2205]. Each ResvErr would contain a <flow descriptor> that [RFC2205]. Each ResvErr would contain a <flow descriptor> that
matches a specific sender. The Receiver Proxy MUST generate a matches a specific sender. The Receiver Proxy MUST generate a
PathErr for each ResvErr received, towards the corresponding sender. PathErr for each ResvErr received, towards the corresponding sender.
3.1.2. Composition of ERROR_SPEC 3.1.2. Composition of ERROR_SPEC
The Receiver Proxy MUST compose the ERROR_SPEC to be inserted into The Receiver Proxy MUST compose the ERROR_SPEC to be inserted into
the PathErr as follows: the PathErr as follows:
1. If the Receiver Proxy receives a ResvErr with any of these error 1. If the Receiver Proxy receives a ResvErr with any of these error
skipping to change at page 15, line 47 skipping to change at page 15, line 47
[RFC2205]. Quoting from it: " In order to efficiently accommodate [RFC2205]. Quoting from it: " In order to efficiently accommodate
large groups, dynamic group membership, and heterogeneous receiver large groups, dynamic group membership, and heterogeneous receiver
requirements, RSVP makes receivers responsible for requesting a requirements, RSVP makes receivers responsible for requesting a
specific QoS". But even for the most simple single_sender/ specific QoS". But even for the most simple single_sender/
single_receiver reservations, the current receiver-driven model single_receiver reservations, the current receiver-driven model
reduces signaling load and per-hop RSVP processing by not sending reduces signaling load and per-hop RSVP processing by not sending
any error message to the sender in case of CAC reject. any error message to the sender in case of CAC reject.
o the motivation for adding sender error notification in case of o the motivation for adding sender error notification in case of
receiver proxy lies in the fact that the actual receiver can no receiver proxy lies in the fact that the actual receiver can no
lomger synchronize RSVP reservation with application state (since longer synchronize RSVP reservation with application state (since
the receiver does not participate in RSVP signaling), while the the receiver does not participate in RSVP signaling), while the
sender can. This motivation does not apply in case of regular sender can. This motivation does not apply in case of regular
receiver. receiver.
o there is a lot of existing code and deployed systems successfully o there is a lot of existing code and deployed systems successfully
working under the current [RFC2205] model in the absence of proxy working under the current [RFC2205] model in the absence of proxy
today. The current behavior should not be changed for those today. The current behavior should not be changed for those
unless there were a very strong motivation. unless there were a very strong motivation.
3.2. Sender Notification via Notify Message 3.2. Sender Notification via Notify Message
skipping to change at page 19, line 49 skipping to change at page 19, line 49
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. It
might also be possible, in the future, to adapt a multicast dynamic might also be possible, in the future, to adapt a multicast dynamic
group key distribution method (e.g. from IETF Multicast Security group key distribution method (e.g. from IETF Multicast Security
Working Group) for dynamic key distribution among RSVP nodes. This Working Group) for dynamic key distribution among RSVP nodes. This
is discussed in [I-D.behringer-tsvwg-rsvp-security-groupkeying]. For is discussed in
[I-D.behringer-tsvwg-rsvp-security-groupkeying-00.txt]. For
situations where RSVP is being used for unicast flows across domain situations where RSVP is being used for unicast flows across domain
boundaries, it is not currently clear how one might provide automated boundaries, it is not currently clear how one might provide automated
key management. 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. In the future,
confidentiality solutions may be developed for the case where there confidentiality solutions may be developed for the case where there
skipping to change at page 20, line 34 skipping to change at page 20, line 35
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 [I-D.ietf-tsvwg-rsvp-proxy-approaches]. Aggregation Networks" of
From the operator's perspective, the RSVP routers and RSVP senders [I-D.ietf-tsvwg-rsvp-proxy-approaches-02.txt]. From the operator's
are in physically secured locations and therefore exposed to a lower perspective, the RSVP routers and RSVP senders are in physically
risk of being tampered with; While the receivers are in locations secured locations and therefore exposed to a lower risk of being
which are physically unsecured and therefore subject to a higher risk tampered with; While the receivers are in locations which are
of being tampered with. The use of an RSVP receiver proxy function physically unsecured and therefore subject to a higher risk of being
tampered with. The use of an RSVP receiver proxy function
effectively increases the security of the operator's reservation and 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
skipping to change at page 23, line 8 skipping to change at page 23, line 8
The sixteen bits of the Error Value field are defined in [RFCXXX] The sixteen bits of the Error Value field are defined in [RFCXXX]
" "
where [RFCXXX] refers to this document and TBD is the value to be 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
Amca Zamfir. Anca Zamfir. Lou Berger, Adrian Farrel and John Drake provided
review and guidance, in particular on the usage of the
Path_State_Removed flag and of the Notify message, both borrowed from
[RFC3473]. We also thank Ken Carlberg for his complete review of the
document and suggestions.
7. References 7. Normative References
7.1. Normative References [I-D.behringer-tsvwg-rsvp-security-groupkeying-00.txt]
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]
Le Faucheur, F., Manner, J., Wing, D., and A. Guillou,
"RSVP Proxy Approaches", September 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 24, line 34 skipping to change at page 25, line 5
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, "A Framework for RSVP
Security Using Dynamic Group Keying", July 2007.
[I-D.ietf-tsvwg-rsvp-proxy-approaches]
Le Faucheur, F., Manner, J., Wing, D., and A. Guillou,
"RSVP Proxy Approaches", July 2007.
Authors' Addresses Authors' Addresses
Francois Le Faucheur Francois Le Faucheur
Cisco Systems Cisco Systems
Greenside, 400 Avenue de Roumanille Greenside, 400 Avenue de Roumanille
Sophia Antipolis 06410 Sophia Antipolis 06410
France France
Phone: +33 4 97 23 26 19 Phone: +33 4 97 23 26 19
Email: flefauch@cisco.com Email: flefauch@cisco.com
skipping to change at page 26, line 10 skipping to change at page 26, line 10
Boulogne-Billancourt, 92659 Boulogne-Billancourt, 92659
France France
Email: allan.guillou@neufcegetel.fr Email: allan.guillou@neufcegetel.fr
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: Hermant.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 (2007).
This document is subject to the rights, licenses and restrictions This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors contained in BCP 78, and except as set forth therein, the authors
retain all their rights. retain all their rights.
This document and the information contained herein are provided on an This document and the information contained herein are provided on an
 End of changes. 19 change blocks. 
46 lines changed or deleted 46 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/