draft-ietf-ccamp-pc-spc-rsvpte-ext-01.txt   draft-ietf-ccamp-pc-spc-rsvpte-ext-02.txt 
CCAMP Working Group D. Caviglia CCAMP Working Group D. Caviglia
Internet-Draft D. Bramanti Internet-Draft D. Ceccarelli
Expires: January 16, 2009 Ericsson Expires: May 1, 2009 D. Bramanti
Ericsson
D. Li D. Li
Huawei Technologies Co., LTD. Huawei Technologies Co., LTD.
S. Bardalai S. Bardalai
Fujitsu Network Communications Inc Fujitsu Network Communications Inc
July 15, 2008 October 28, 2008
RSVP-TE Signaling Extension For The Conversion Between Permanent RSVP-TE Signaling Extension For The Conversion Between Permanent
Connections And Soft Permanent Connections In A GMPLS Enabled Transport Connections And Soft Permanent Connections In A GMPLS Enabled Transport
Network. Network.
draft-ietf-ccamp-pc-spc-rsvpte-ext-01.txt draft-ietf-ccamp-pc-spc-rsvpte-ext-02.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 42
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 January 16, 2009. This Internet-Draft will expire on May 1, 2009.
Abstract Abstract
We would like to dedicate this work to our friend and colleague Dino We would like to dedicate this work to our friend and colleague Dino
Bramanti, who passed away at the early age of 38. Dino has been Bramanti, who passed away at the early age of 38. Dino has been
involved in this work since its beginning. involved in this work since its beginning.
In a transport network scenario, where Data Plane connections In a transport network scenario, where Data Plane connections
controlled either by GMPLS Control Plane (Soft Permanent Connections controlled either by GMPLS Control Plane (Soft Permanent Connections
- SPC) or by Management System (Permanent Connections - PC) may - SPC) or by Management System (Permanent Connections - PC) may
skipping to change at page 2, line 45 skipping to change at page 2, line 46
9. RSVP Message Formats . . . . . . . . . . . . . . . . . . . . . 16 9. RSVP Message Formats . . . . . . . . . . . . . . . . . . . . . 16
10. Objects Modification . . . . . . . . . . . . . . . . . . . . . 17 10. Objects Modification . . . . . . . . . . . . . . . . . . . . . 17
10.1. Administrative Status Object . . . . . . . . . . . . . . . 17 10.1. Administrative Status Object . . . . . . . . . . . . . . . 17
10.2. Error Spec Object . . . . . . . . . . . . . . . . . . . . 18 10.2. Error Spec Object . . . . . . . . . . . . . . . . . . . . 18
11. Acknoledgments . . . . . . . . . . . . . . . . . . . . . . . . 19 11. Acknoledgments . . . . . . . . . . . . . . . . . . . . . . . . 19
12. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 19 12. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 19
13. Security Considerations . . . . . . . . . . . . . . . . . . . 20 13. Security Considerations . . . . . . . . . . . . . . . . . . . 20
14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20
15. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20 15. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20
15.1. Normative References . . . . . . . . . . . . . . . . . . . 20 15.1. Normative References . . . . . . . . . . . . . . . . . . . 20
15.2. Informa</artwork>tional References . . . . . . . . . . . . 20 15.2. Informational References . . . . . . . . . . . . . . . . . 21
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 21 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 21
Intellectual Property and Copyright Statements . . . . . . . . . . 23 Intellectual Property and Copyright Statements . . . . . . . . . . 23
1. Introduction 1. Introduction
In a typical traditional transport network scenario, Data Plane In a typical traditional transport network scenario, Data Plane
connections between two endpoints are controlled by means of a connections between two endpoints are controlled by means of a
Network Management System (NMS) operating within Management Plane Network Management System (NMS) operating within Management Plane
(MP). NMS/MP is the owner of such transport connections, being (MP). NMS/MP is the owner of such transport connections, being
responsible of their set up, tear down and maintenance. responsible of their set up, tear down and maintenance.
The adoption of a GMPLS Control Plane over networks that are already The adoption of a GMPLS Control Plane over networks that are already
in service - controlled by NMS at Management Plane level - introduces in service - controlled by NMS at Management Plane level - introduces
the need for a procedure able to coordinate a control handover of a the need for a procedure able to coordinate a control handover of a
generic data plane connection from MP to CP. generic data plane connection from MP to CP.
In addition, the control handover in the opposite direction, from CP In addition, the control handover in the opposite direction, from CP
to MP should be possible as well. The procedures described in this to MP SHOULD be possible as well. The procedures described in this
memo can be applied to any kind of LSP and network architecture. memo can be applied to any kind of LSP and network architecture.
2. Terminology 2. Terminology
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].
3. Motivation 3. Motivation
skipping to change at page 7, line 22 skipping to change at page 7, line 22
Moreover, each failure can be due to two different causes: Data Plane Moreover, each failure can be due to two different causes: Data Plane
failure or Communication Failure. A section for each combination failure or Communication Failure. A section for each combination
will be analyzed in the following. will be analyzed in the following.
5.2.1. MP to CP Handover Failure - Path Failure 5.2.1. MP to CP Handover Failure - Path Failure
5.2.1.1. MP to CP Handover Failure - Path Message and Data Plane 5.2.1.1. MP to CP Handover Failure - Path Message and Data Plane
Failure Failure
The handover procedure can fail due to different causes, but in any The handover procedure can fail due to different causes, but in any
case the network status but be immediately rollbacked to the one case the network status MUST be immediately rollbacked to the one
previous to the handover procedure. The failure can happen during previous to the handover procedure. The failure can happen during
the Path message or the Resv message forwarding. In this paragraph the Path message or the Resv message forwarding. In this paragraph
we will analyze the first case. we will analyze the first case.
| Path | | | | Path | | |
|---------------------->| Path | | |---------------------->| Path | |
| |----------------------X| | | |----------------------X| |
| | | | | | | |
| Path Err | | | | Path Err | | |
|<----------------------| | | |<----------------------| | |
| | | | | | | |
Ingress LER LSR A LSR B Egress LER Ingress LER LSR A LSR B Egress LER
If an error occurs in an LSR or a LER, the last node that has If an error occurs in an LSR or a LER, the last node that has
received the Path message MUST send a Path Error message in the received the Path message MUST send a Path Error message in the
upstream direction including an Error_Spec object and the Handover upstream direction including an Error_Spec object and the Handover
flag set. The upstream nodes MAY process the Error_Spec object. flag set. The Path Error message SHOULD have the Path_State_Removed
flag set and the upstream nodes MAY process the Error_Spec object.
5.2.1.2. MP to CP Handover Failure - Path Message and Communication 5.2.1.2. MP to CP Handover Failure - Path Message and Communication
failure failure
Other possible scenarios are shown in the following pictures and Other possible scenarios are shown in the following pictures and
consist on the unreachability of a node of the LSP. consist on the unreachability of a node of the LSP.
The below scenario postulates the usage of a reliable message The below scenario postulates the usage of a reliable message
delivery based on the mechanism defined in [RFC2961] delivery based on the mechanism defined in [RFC2961].
| Path | | | | Path | | |
|---------------------->| Path | | |---------------------->| Path | |
| |------------X | | | |------------X | |
| |------------X | | | |------------X | |
| | ... | | | | ... | |
| |------------X | | | |------------X | |
| | | | | | | |
| Path Err | | | | Path Err | | |
|<----------------------| | | |<----------------------| | |
| | | | | | | |
Ingress LER LSR A LSR B Egress LER Ingress LER LSR A LSR B Egress LER
The Path message sent from LSR A towards LSR B is lost or does not The Path message sent from LSR A towards LSR B is lost or does not
reach the destination for any reason. A reliable delivery mechanism reach the destination for any reason. A reliable delivery mechanism
is implemented, LSR A retransmits the Path Message for a configurable is implemented, LSR A retransmits the Path Message for a configurable
number of times, then, if no ack is received, a Path Error message is number of times, then, if no ack is received, a Path Error message
sent back to the ingress LER and the adoption procedure aborted. MUST be sent back to the ingress LER, the Path_State_Removed flag
SHOULD be set and the adoption procedure is aborted.
In the next scenario RSVP-TE messages are sent without reliable In the next scenario RSVP-TE messages are sent without reliable
message delivery, that is, no [RFC2961] MessageID procedure is used. message delivery, that is, no [RFC2961] MessageID procedure is used.
| Path | | | | Path | | |
|---------------------->| Path | | |---------------------->| Path | |
| |------------X | | | |------------X | |
| | | | | | | |
| | | | | | | |
|----TIMER EXPIRES------| | | |----TIMER EXPIRES------| | |
| Path Tear | | | | Path Tear | | |
|---------------------->| | | |---------------------->| | |
| | | | | | | |
Ingress LER LSR A LSR B Egress LER Ingress LER LSR A LSR B Egress LER
If the Resv Message is not received by the expiration of a timer set If the Resv Message is not received by the expiration of a timer set
by the ingress LER, the adoption procedure is again aborted and a by the ingress LER, the adoption procedure is again aborted and a
PathTear message MAY be sent in the downstream direction with the H PathTear message MAY be sent in the downstream direction with the H
bit set bit set.
5.2.2. MP to CP Handover Failure - Resv Error 5.2.2. MP to CP Handover Failure - Resv Error
5.2.2.1. MP to CP Handover Failure - Resv Error and Data Plane failure 5.2.2.1. MP to CP Handover Failure - Resv Error and Data Plane failure
In case a failure occurs during the Resv Message forwarding, things In case a failure occurs during the Resv Message forwarding, things
are quite different, because after the handover procedure an LSR is are quite different, because after the handover procedure an LSR is
not able to distinguish an LSP created by the Control Plane from an not able to distinguish an LSP created by the Control Plane from an
LSP created by the Management Plane and then moved to the Control LSP created by the Management Plane and then moved to the Control
Plane. Plane.
| Path | Path | Path | | Path | Path | Path |
|---------------------->|---------------------->|---------------------->| |---------------------->|---------------------->|---------------------->|
| | | Resv | | | | Resv |
| | Resv |<----------------------| | | Resv |<----------------------|
| |X----------------------| | | |X----------------------| |
| Path Err | Resv Err | | | Path Err | Path Tear | |
|<----------------------|---------------------->| Resv Err | |<----------------------|---------------------->| Path Tear |
| | |---------------------->| | | |---------------------->|
| | | | | | | |
Ingress LER LSR A LSR B Egress LER Ingress LER LSR A LSR B Egress LER
In the case shown in the above picture, the failure occurs in LSR A. In the case shown in the above picture, the failure occurs in LSR A.
A Resv Error message is sent in the downstream direction and a Path Considering to have a reliable message delivery mechanism, a Path
Error message is sent in the upstream direction. Tear message MUST be sent in the downstream direction and a Path
Error message MUST sent in the upstream direction and the
Path_State_Removed SHOULD flag should be set. The Path Err and Path
Tear messages remove the Path state established by the Path messages
along the nodes of the LSP and abort the adoption procedure.
Please note that the failure occurred after the handover procedure Please note that the failure occurred after the handover procedure
was successfully completed in LSR B. This means that LSR B is no was successfully completed in LSR B. This means that LSR B is no
longer able to know if the LSP was created by the Control Plane or a longer able to know if the LSP was created by the Control Plane or a
handover procedure took place. handover procedure took place.
Upon receiving a Resv Error message, LSR B would delete the LSP also Upon receiving a Path Tear message, LSR B would delete the LSP also
from the Data Plane point of view. To prevent this from happening, from the Data Plane point of view. To prevent this from happening,
LSR A MUST include an Error_Spec object into the Resv Error message LSR A MUST set the handover flag in the Path Tear message. The
setting the handover flag. The downstream nodes MUST process the downstream node move the LSP ownership back to the Management Plane
Error Spec object, move the LSP ownership back to the Management and MUST NOT modify the Data Plane.
Plane and MUST NOT modify the Data Plane.
5.2.2.2. MP to CP Handover Failure - Resv Error and Communication 5.2.2.2. MP to CP Handover Failure - Resv Error and Communication
failure failure
In case a Resv Message cannot reach one or more of the downstream In case a Resv Message cannot reach one or more of the downstream
nodes, the procedure is quite similar to the one previously seen nodes, the procedure is quite similar to the one previously seen
about the Path Message. Even in this case it is possible to about the Path Message. Even in this case it is possible to
distinguish two different scenarios. distinguish two different scenarios.
In the first scenario we consider the utilization of a reliable In the first scenario we consider the utilization of a reliable
skipping to change at page 9, line 48 skipping to change at page 10, line 4
In case a Resv Message cannot reach one or more of the downstream In case a Resv Message cannot reach one or more of the downstream
nodes, the procedure is quite similar to the one previously seen nodes, the procedure is quite similar to the one previously seen
about the Path Message. Even in this case it is possible to about the Path Message. Even in this case it is possible to
distinguish two different scenarios. distinguish two different scenarios.
In the first scenario we consider the utilization of a reliable In the first scenario we consider the utilization of a reliable
message delivery based on the mechanism defined in [RFC2961]. After message delivery based on the mechanism defined in [RFC2961]. After
a correct forwarding of the Path message along the nodes of the LSP, a correct forwarding of the Path message along the nodes of the LSP,
the Egress LSR sends a Resv message in the opposite direction. It the Egress LSR sends a Resv message in the opposite direction. It
might happen that the Resv message does not reach an LSR, say LSR A. might happen that the Resv message does not reach an LSR, say LSR A.
LSR B, after sending the Resv message again for a configurable number LSR B, after sending the Resv message again for a configurable number
of times, sends a Resv Error message in the downstream direction of times, MUST send a Path Tear message in the downstream direction
towards the Egress LER and a Path Error message in the upstream towards the Egress LER and a Path Error message (with the
direction towards the Ingress LER in order to inform the nodes of the Path_State_Removed flag set) in the upstream direction towards the
path that the adoption procedure has failed and that the LSP Ingress LER in order to inform the nodes of the path that the
ownership is to be moved back to the management plane. adoption procedure has failed and that the LSP ownership is to be
moved back to the management plane.
| Path | Path | Path | | Path | Path | Path |
|---------------------->|---------------------->|---------------------->| |---------------------->|---------------------->|---------------------->|
| | | Resv | | | | Resv |
| | Resv |<----------------------| | | Resv |<----------------------|
| | X-----------| | | | X-----------| |
| | X-----------| | | | X-----------| |
| | ... | | | | ... | |
| | X-----------| | | | X-----------| |
| | | | | | | |
| Path Err | Path Err | Resv Err | | Path Err | Path Err | Path Tear |
|<----------------------|<----------------------|---------------------->| |<----------------------|<----------------------|---------------------->|
| | | | | | | |
Ingress LER LSR A LSR B Egress LER Ingress LER LSR A LSR B Egress LER
Please note that the failure occurred after the handover procedure Please note that the failure occurred after the handover procedure
was successfully completed in the Egress LER. This means that it is was successfully completed in the Egress LER. This means that it is
no longer able to know if the LSP was created by the Control Plane or no longer able to know if the LSP was created by the Control Plane or
a handover procedure took place. a handover procedure took place.
Upon receiving a Resv Error message, the downstream nodes would Upon receiving a Path Tear message, the downstream nodes would delete
delete the LSP also from the Data Plane point of view. To prevent the LSP also from the Data Plane point of view. To prevent this from
this from happening, LSR B MUST include an Error_Spec object into the happening, the Path Tear message MUST include the Handover flag.
Resv Error message setting the Handover flag. The downstream nodes
MUST process the Error Spec object, move the LSP ownership back to
the Management Plane and MUST NOT modify the Data Plane.
Considering that the Resv message did not manage to reach LSR A, it Considering that the Resv message did not manage to reach LSR A, it
is highly probable that the Path Error would fail too. Due to this is highly probable that the Path Error would fail too. Due to this
fact, a configurable timer MUST be set on the Ingress LER after fact, a configurable timer MUST be set on the Ingress LER after
sending the path and on LSR A after forwanding it. When the timer sending the path and on LSR A after forwanding it. When the timer
expires, if no Resv or Path Error message is received, the handover expires, if no Resv or Path Error message is received, the handover
procedure MUST be aborted and the LSP ownership returned to the procedure MUST be aborted and the LSP ownership returned to the
Management Plane. Management Plane.
The following picture, on the other hand, shows the scenario in which The following picture, on the other hand, shows the scenario in which
skipping to change at page 18, line 24 skipping to change at page 18, line 24
the Path message. This will assures that the Resv message will the Path message. This will assures that the Resv message will
maintain the H flag set. maintain the H flag set.
10.2. Error Spec Object 10.2. Error Spec Object
It is possible that a failure, such as the lost of DCN connection or It is possible that a failure, such as the lost of DCN connection or
the restart of a node, occurs during the LSP ownership handing over. the restart of a node, occurs during the LSP ownership handing over.
In this case the LSP adoption MUST be interrupted and the ownership In this case the LSP adoption MUST be interrupted and the ownership
of the LSP MUST be moved back to the Plane it belonged to. It is of the LSP MUST be moved back to the Plane it belonged to. It is
important that the transaction failure MUST not affect the Data important that the transaction failure MUST not affect the Data
Plane. The LSP MUST be kept in place and no traffic hint MUST occur. Plane. The LSP MUST be kept in place and no traffic hit MUST occur.
The failure is signaled by Path and Resv Error Messages, which The failure is signaled by Path Error in the upstream direction and
include an Error_Spec_Object specifying the causes of the failure. Path Tear Messages in the downstream direction. The Path Error
messages include an Error_Spec_Object (the Path_State_Removed flag
SHOUL always be set) specifying the causes of the failure, while the
Path Tear messages, required in case of reliable recovery and
optional otherwise, include the handover flag to prevent the deletion
of the LSP from the Data Plane.
This memo introduces a new Flag and a new Error Code(with different This memo introduces a new Flag and a new Error Code(with different
Error Values) into the Error_Spec Object, defined in [RFC2205]. Error Values) into the Error_Spec Object, defined in [RFC2205].
* ERROR_SPEC class = 6. * ERROR_SPEC class = 6.
* IPv4 ERROR_SPEC object: Class = 6, C-Type = 1 * IPv4 ERROR_SPEC object: Class = 6, C-Type = 1
+-------------+-------------+-------------+-------------+ +-------------+-------------+-------------+-------------+
| IPv4 Error Node Address (4 bytes) | | IPv4 Error Node Address (4 bytes) |
+-------------+-------------+-------------+-------------+ +-------------+-------------+-------------+-------------+
skipping to change at page 19, line 15 skipping to change at page 19, line 20
* 0x01 = InPlace * 0x01 = InPlace
* 0x02 = NotGuilty * 0x02 = NotGuilty
Proposed new value (TBD) = HandOverFailure Proposed new value (TBD) = HandOverFailure
The new flag is "Handover Procedure Failure" and the actual value is The new flag is "Handover Procedure Failure" and the actual value is
(TBD by IANA). When this flag is set during an handover from (TBD by IANA). When this flag is set during an handover from
Management Plane to Control Plane, the receiver must delete the Management Plane to Control Plane, the receiver must delete the
Control Plane status associated with the LSP and move the ownership Control Plane status associated with the LSP and move the ownership
of the cross-connections back to the Management Plane. The proposed of the cross-connections back to the Management Plane.
Error Code is "Handover Procedure Failure", and its value is (TBD by
IANA)(33). For this Error Code the following Error Values are The proposed Error Code is "Handover Procedure Failure", and its
defined: 1 = Cross-connection mismatch 2 = DCN error value is (TBD by IANA)(33). For this Error Code the following Error
Values are defined:
1 = Cross-connection mismatch
2 = DCN error
11. Acknoledgments 11. Acknoledgments
We wish to thank Adrian Farrel for his editorial assistance and We wish to thank Adrian Farrel for his editorial assistance and
precious advices to prepare this draft for publication. We also wish precious advices to prepare this draft for publication. We also wish
to thank Nicola Ciulli, that contributed to initial stage of this to thank Nicola Ciulli, that contributed to initial stage of this
draft. draft.
12. Contributors 12. Contributors
Shan Zhu Shan Zhu
Fujitsu Network Communications Inc. Fujitsu Network Communications Inc.
2801 Telecom Parkway, 2801 Telecom Parkway,
Richardson, Texas 75082 Richardson, Texas 75082
USA USA
Email: Shan.Zhu@us.fujitsu.com Email: Shan.Zhu@us.fujitsu.com
Tel: +1-972-479-2041 Tel: +1-972-479-2041
Igor Bryskin Igor Bryskin
ADVA Optical Networking Inc ADVA Optical Networking Inc
skipping to change at page 19, line 44 skipping to change at page 20, line 19
Email: Shan.Zhu@us.fujitsu.com Email: Shan.Zhu@us.fujitsu.com
Tel: +1-972-479-2041 Tel: +1-972-479-2041
Igor Bryskin Igor Bryskin
ADVA Optical Networking Inc ADVA Optical Networking Inc
7926 Jones Branch Drive 7926 Jones Branch Drive
Suite 615 Suite 615
McLean, VA - 22102 McLean, VA - 22102
Email: ibryskin@advaoptical.com Email: ibryskin@advaoptical.com
Daniele Ceccarelli
Ericsson
Via A. Negrone 1/A
Genova-Sestri Ponente, Italy
Phone: +390106002515
Email: daniele.ceccarelli@ericsson.com
13. Security Considerations 13. Security Considerations
The procedures described in this document rely completely on RSVP-TE The procedures described in this document rely completely on RSVP-TE
messages and mechanism. The use of Handover Flag set in Admin Status messages and mechanism. The use of Handover Flag set in Admin Status
Object basically informs the receiving entity that no operations are Object basically informs the receiving entity that no operations are
to be done over Data Plane as consequence of such special signaling to be done over Data Plane as consequence of such special signaling
flow. Using specially flagged signaling messages we want to limit flow. Using specially flagged signaling messages we want to limit
the function of setup and tear down messages to Control Plane, making the function of setup and tear down messages to Control Plane, making
them not effective over related Data Plane resource usage. So, no them not effective over related Data Plane resource usage. So, no
additional or special issues are arisen by adopting this procedure, additional or special issues are arisen by adopting this procedure,
skipping to change at page 20, line 43 skipping to change at page 21, line 13
Engineering (RSVP-TE) Extensions", RFC 3473, January 2003. Engineering (RSVP-TE) Extensions", RFC 3473, January 2003.
[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.
[RFC2961] Berger, L., Gan, D., Swallow, G., Pan, P., Tommasi, F., [RFC2961] Berger, L., Gan, D., Swallow, G., Pan, P., Tommasi, F.,
and S. Molendini, "RSVP Refresh Overhead Reduction and S. Molendini, "RSVP Refresh Overhead Reduction
Extensions", RFC 2961, April 2001. Extensions", RFC 2961, April 2001.
15.2. Informa</artwork>tional References 15.2. Informational References
[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.
[RFC4606] Mannie, E. and D. Papadimitriou, "Generalized Multi- [RFC4606] Mannie, E. and D. Papadimitriou, "Generalized Multi-
Protocol Label Switching (GMPLS) Extensions for Protocol Label Switching (GMPLS) Extensions for
Synchronous Optical Network (SONET) and Synchronous Synchronous Optical Network (SONET) and Synchronous
Digital Hierarchy (SDH) Control", RFC 4606, August 2006. Digital Hierarchy (SDH) Control", RFC 4606, August 2006.
[RFC3471] Berger, L., "Generalized Multi-Protocol Label Switching [RFC3471] Berger, L., "Generalized Multi-Protocol Label Switching
skipping to change at page 21, line 36 skipping to change at page 22, line 4
Authors' Addresses Authors' Addresses
Diego Caviglia Diego Caviglia
Ericsson Ericsson
Via A. Negrone 1/A Via A. Negrone 1/A
Genova - Sestri Ponente Genova - Sestri Ponente
Italy Italy
Email: diego.caviglia@ericsson.com Email: diego.caviglia@ericsson.com
Daniele Ceccarelli
Ericsson
Via A. Negrone 1/A
Genova - Sestri Ponente
Italy
Email: daniele.ceccarelli@ericsson.com
Dino Bramanti Dino Bramanti
Ericsson Ericsson
Via Moruzzi 1 C/O Area Ricerca CNR Via Moruzzi 1 C/O Area Ricerca CNR
Pisa Pisa
Italy Italy
Email: dino.bramanti@ericsson.com Email: dino.bramanti@ericsson.com
Dan Li Dan Li
Huawei Technologies Co., LTD. Huawei Technologies Co., LTD.
Shenzhen 518129 Shenzhen 518129
Huawei Base, Bantian, Longgang Huawei Base, Bantian, Longgang
Italy Italy
Email: dan.li@huawei.com Email: dan.li@huawei.com
Snigdho Bardalai Snigdho Bardalai
Fujitsu Network Communications Inc Fujitsu Network Communications Inc
 End of changes. 27 change blocks. 
50 lines changed or deleted 66 lines changed or added

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