draft-ietf-ccamp-gr-description-00.txt | draft-ietf-ccamp-gr-description-01.txt | |||
---|---|---|---|---|
Network Working Group Dan Li | Network Working Group Dan Li | |||
Internet Draft Jianhua Gao | Internet Draft Jianhua Gao | |||
Huawei | Huawei | |||
Arun Satyanarayana | Arun Satyanarayana | |||
Cisco | Cisco | |||
Intended Status: Informational | Intended Status: Informational | |||
Expires: February 2008 August, 2007 | Expires: May 2008 November, 2007 | |||
Description of the RSVP-TE Graceful Restart Procedures | Description of the RSVP-TE Graceful Restart Procedures | |||
draft-ietf-ccamp-gr-description-00.txt | draft-ietf-ccamp-gr-description-01.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 2, line 27 | skipping to change at page 2, line 27 | |||
the nodes restart is different. | the nodes restart is different. | |||
This document does not define any new processes or procedures. All | This document does not define any new processes or procedures. All | |||
protocol mechanisms are already defined in the referenced documents. | protocol mechanisms are already defined in the referenced documents. | |||
Table of Contents | Table of Contents | |||
1. Introduction.................................................3 | 1. Introduction.................................................3 | |||
2. Existing Procedures for Single Node Restart..................4 | 2. Existing Procedures for Single Node Restart..................4 | |||
2.1. Procedures defined in [RFC3473]............................4 | 2.1. Procedures defined in [RFC3473]............................4 | |||
2.2. Procedures defined in [GR-EXT].............................5 | 2.2. Procedures defined in [RFC5063]............................5 | |||
3. Multiple Node Restart Scenarios..............................5 | 3. Multiple Node Restart Scenarios..............................5 | |||
4. RSVP State...................................................6 | 4. RSVP State...................................................6 | |||
5. Procedures for Multiple Node Restart.........................7 | 5. Procedures for Multiple Node Restart.........................7 | |||
5.1. Procedures for the Normal Node.............................7 | 5.1. Procedures for the Normal Node.............................7 | |||
5.2. Procedures for the Restarting Node.........................7 | 5.2. Procedures for the Restarting Node.........................7 | |||
5.2.1. Procedures for Scenario 1................................7 | 5.2.1. Procedures for Scenario 1................................7 | |||
5.2.2. Procedures for Scenario 2................................9 | 5.2.2. Procedures for Scenario 2................................9 | |||
5.2.3. Procedures for scenario 3...............................10 | 5.2.3. Procedures for scenario 3...............................10 | |||
5.2.4. Procedures for scenario 4...............................11 | 5.2.4. Procedures for scenario 4...............................11 | |||
5.2.5. Procedures for scenario 5...............................11 | 5.2.5. Procedures for scenario 5...............................11 | |||
5.3. Consideration of Re-Use of Data Plane Resources...........12 | 5.3. Consideration of Re-Use of Data Plane Resources...........12 | |||
5.4. Consideration of Management Plane Intervention............12 | 5.4. Consideration of Management Plane Intervention............12 | |||
6. Security Considerations.....................................12 | 6. Clarification of Restarting Node Procedure..................12 | |||
7. IANA Considerations.........................................13 | 7. Security Considerations.....................................14 | |||
8. Acknowledgments.............................................13 | 8. IANA Considerations.........................................14 | |||
9. References..................................................13 | 9. Acknowledgments.............................................14 | |||
9.1. Normative References......................................13 | 10. References.................................................15 | |||
10. Authors' Addresses.........................................14 | 10.1. Normative References.....................................15 | |||
11. Full Copyright Statement...................................14 | 11. Authors' Addresses.........................................16 | |||
12. Intellectual Property Statement............................15 | 12. Full Copyright Statement...................................16 | |||
13. Intellectual Property Statement............................17 | ||||
1. Introduction | 1. Introduction | |||
The Hello message for the Resource Reservation Protocol (RSVP) has | The Hello message for the Resource Reservation Protocol (RSVP) has | |||
been defined to establish and maintain basic signaling node | been defined to establish and maintain basic signaling node | |||
adjacencies for Label Switching Routers (LSRs) participating in a | adjacencies for Label Switching Routers (LSRs) participating in a | |||
Multiprotocol Label Switching (MPLS) traffic engineered (TE) | Multiprotocol Label Switching (MPLS) traffic engineered (TE) | |||
network [RFC3209]. The Hello message has been extended for use in | network [RFC3209]. The Hello message has been extended for use in | |||
Generalized MPLS (GMPLS) network for state recovery of control | Generalized MPLS (GMPLS) network for state recovery of control | |||
channel or nodal faults through the exchange of the Restart | channel or nodal faults through the exchange of the Restart | |||
Capabilities object [RFC3473]. | Capabilities object [RFC3473]. | |||
GMPLS protocol definitions for RSVP [RFC3473] also allow a | GMPLS protocol definitions for RSVP [RFC3473] also allow a | |||
restarting node to learn the label that it previously allocated for | restarting node to learn the label that it previously allocated for | |||
use on a Label Switching Path (LSP) through the Recovery Label | use on a Label Switching Path (LSP) through the Recovery Label | |||
object carried on a Path message sent to a restarting node from its | object carried on a Path message sent to a restarting node from its | |||
upstream neighbor. | upstream neighbor. | |||
Further RSVP protocol extensions have been defined [GR-EXT] to | Further RSVP protocol extensions have been defined [RFC5063] to | |||
perform graceful restart and to enable a restarting node to recover | perform graceful restart and to enable a restarting node to recover | |||
full control plane state by exchanging RSVP messages with its | full control plane state by exchanging RSVP messages with its | |||
upstream and downstream neighbors. State previously transmitted to | upstream and downstream neighbors. State previously transmitted to | |||
the upstream neighbor (principally the downstream label) is | the upstream neighbor (principally the downstream label) is | |||
recovered from the upstream neighbor on a Path message (using the | recovered from the upstream neighbor on a Path message (using the | |||
Recovery Label object as described in [RFC3473]). State previously | Recovery Label object as described in [RFC3473]). State previously | |||
transmitted to the downstream neighbor (including the upstream | transmitted to the downstream neighbor (including the upstream | |||
label, interface identifiers, and the explicit route) is recovered | label, interface identifiers, and the explicit route) is recovered | |||
from the downstream neighbor using a RecoveryPath message. | from the downstream neighbor using a RecoveryPath message. | |||
[GR-EXT] also extends the Hello message to exchange information | [RFC5063] also extends the Hello message to exchange information | |||
about the ability to support the RecoveryPath message. | about the ability to support the RecoveryPath message. | |||
The examples and procedures in [RFC3473] and [GR-EXT] focus on the | The examples and procedures in [RFC3473] and [RFC5063] focus on the | |||
description of a single node restart when adjacent network nodes | description of a single node restart when adjacent network nodes | |||
are operative. Although the procedures are equally applicable to | are operative. Although the procedures are equally applicable to | |||
multi-node restarts, no detailed explanation is provided. | multi-node restarts, no detailed explanation is provided. | |||
This document provides and informational clarification of the | This document provides and informational clarification of the | |||
control plane procedures for a GMPLS network when there are | control plane procedures for a GMPLS network when there are | |||
multiple node failures, and describes how full control plane state | multiple node failures, and describes how full control plane state | |||
can be recovered in different scenarios where the order in which | can be recovered in different scenarios where the order in which | |||
the nodes restart is different. | the nodes restart is different. | |||
This document does not define any new processes or procedures. All | This document does not define any new processes or procedures. All | |||
protocol mechanisms already defined in [RFC3473] and [GR-EXT] are | protocol mechanisms already defined in [RFC3473] and [RFC5063] are | |||
definitive. | definitive. | |||
2. Existing Procedures for Single Node Restart | 2. Existing Procedures for Single Node Restart | |||
This section documents for information the existing procedures | This section documents for information the existing procedures | |||
defined in [RFC3473] and [GR-EXT]. Those documents are definitive, | defined in [RFC3473] and [RFC5063]. Those documents are definitive, | |||
and the description here is non-normative. It is provided for | and the description here is non-normative. It is provided for | |||
informational clarification only. | informational clarification only. | |||
2.1. Procedures defined in [RFC3473] | 2.1. Procedures defined in [RFC3473] | |||
In the case of nodal faults, the procedures for the restarting node | In the case of nodal faults, the procedures for the restarting node | |||
and the procedures for the neighbor of a restarting node are | and the procedures for the neighbor of a restarting node are | |||
applied to the corresponding nodes. These procedures described in | applied to the corresponding nodes. These procedures described in | |||
[RFC3473] are summarized as follows: | [RFC3473] are summarized as follows: | |||
skipping to change at page 5, line 5 | skipping to change at page 5, line 5 | |||
For the Neighbor of a restarting node: | For the Neighbor of a restarting node: | |||
1) Sends the Path message with RECOVERY_LABEL object containing a | 1) Sends the Path message with RECOVERY_LABEL object containing a | |||
label value corresponding to the label value received in the most | label value corresponding to the label value received in the most | |||
recently received corresponding Resv message; | recently received corresponding Resv message; | |||
2) Resumes refreshing Path state with the restarting node; | 2) Resumes refreshing Path state with the restarting node; | |||
3) Resumes refreshing Resv state with the restarting node. | 3) Resumes refreshing Resv state with the restarting node. | |||
2.2. Procedures defined in [GR-EXT] | 2.2. Procedures defined in [RFC5063] | |||
A new message is introduced in [GR-EXT] which is called the | A new message is introduced in [RFC5063] which is called the | |||
RecoveryPath message. The message is sent by the downstream | RecoveryPath message. The message is sent by the downstream | |||
neighbor of a restarting node to convey the contents of the last | neighbor of a restarting node to convey the contents of the last | |||
received Path message back to the restarting node. | received Path message back to the restarting node. | |||
The restarting node will receive the Path message with the | The restarting node will receive the Path message with the | |||
RECOVERY_LABEL object from its upstream neighbor, and/or the | RECOVERY_LABEL object from its upstream neighbor, and/or the | |||
RecoveryPath message from its downstream neighbor. The full RSVP | RecoveryPath message from its downstream neighbor. The full RSVP | |||
state of the restarting node can be recovered from these two | state of the restarting node can be recovered from these two | |||
messages. | messages. | |||
skipping to change at page 7, line 19 | skipping to change at page 7, line 19 | |||
the PSB is responsible for receiving a Path from upstream and | the PSB is responsible for receiving a Path from upstream and | |||
sending a Path to downstream. | sending a Path to downstream. | |||
Regardless of how the RSVP state is implemented, on recovery there | Regardless of how the RSVP state is implemented, on recovery there | |||
are two logical pieces of state to be recovered and these | are two logical pieces of state to be recovered and these | |||
correspond to the PSB and RSB. | correspond to the PSB and RSB. | |||
5. Procedures for Multiple Node Restart | 5. Procedures for Multiple Node Restart | |||
In this document, all the nodes are assumed to have the graceful | In this document, all the nodes are assumed to have the graceful | |||
restart capabilities which are described in [RFC3473] and [GR-EXT]. | restart capabilities which are described in [RFC3473] and [RFC5063]. | |||
5.1. Procedures for the Normal Node | 5.1. Procedures for the Normal Node | |||
When the downstream Normal node detects its neighbor restarting, it | When the downstream Normal node detects its neighbor restarting, it | |||
must send a RecoveryPath message for each LSP associated with the | must send a RecoveryPath message for each LSP associated with the | |||
restarting node for which it has previously sent a Resv message and | restarting node for which it has previously sent a Resv message and | |||
which has not been torn down. | which has not been torn down. | |||
When the upstream Normal node detects its neighbor restarting, it | When the upstream Normal node detects its neighbor restarting, it | |||
must send a Path message with RECOVERY_LABEL object containing a | must send a Path message with RECOVERY_LABEL object containing a | |||
label value corresponding to the label value received in the most | label value corresponding to the label value received in the most | |||
recently received corresponding Resv message. | recently received corresponding Resv message. | |||
This document does not modify the procedures for the Normal node | This document does not modify the procedures for the Normal node | |||
which are described in [RFC3473] and [GR-EXT]. | which are described in [RFC3473] and [RFC5063]. | |||
5.2. Procedures for the Restarting Node | 5.2. Procedures for the Restarting Node | |||
This document does not modify the procedures for the Restarting | This document does not modify the procedures for the Restarting | |||
node which are described in [RFC3473] and [GR-EXT]. | node which are described in [RFC3473] and [RFC5063]. | |||
5.2.1. Procedures for Scenario 1 | 5.2.1. Procedures for Scenario 1 | |||
After the Restarting node restarts, it starts a Recovery Timer. Any | After the Restarting node restarts, it starts a Recovery Timer. Any | |||
RSVP state that has not been resynchronized when the Recovery Timer | RSVP state that has not been resynchronized when the Recovery Timer | |||
expires, should be cleared. | expires, should be cleared. | |||
At the Restarting node (Node B in the example), full | At the Restarting node (Node B in the example), full | |||
resynchronization with the upstream neighbor (Node A) is possible | resynchronization with the upstream neighbor (Node A) is possible | |||
because Node A is a Normal node. The upstream Path information is | because Node A is a Normal node. The upstream Path information is | |||
skipping to change at page 8, line 16 | skipping to change at page 8, line 16 | |||
message received from Node A, but, obviously, some information | message received from Node A, but, obviously, some information | |||
(like the Recorded Route Object) will be missing from the new Resv | (like the Recorded Route Object) will be missing from the new Resv | |||
message generated by Node B, and can not be supplied until the | message generated by Node B, and can not be supplied until the | |||
downstream Delayed Restarting node (Node C) restarts and sends a | downstream Delayed Restarting node (Node C) restarts and sends a | |||
Resv. | Resv. | |||
After the upstream Path information and upstream Resv information | After the upstream Path information and upstream Resv information | |||
has been recovered by Node B, the normal refresh procedure with the | has been recovered by Node B, the normal refresh procedure with the | |||
upstream Node A should be started. | upstream Node A should be started. | |||
As per [GR-EXT], the Restarting node (Node B) would normally expect | As per [RFC5063], the Restarting node (Node B) would normally | |||
to receive a RecoveryPath message from its downstream neighbor | expect to receive a RecoveryPath message from its downstream | |||
(Node C). It would use this to recover the downstream Path | neighbor (Node C). It would use this to recover the downstream Path | |||
information, and would subsequently send a Path message to its | information, and would subsequently send a Path message to its | |||
downstream neighbor and receive a Resv message. But in this | downstream neighbor and receive a Resv message. But in this | |||
scenario, because the downstream neighbor has not restarted yet, | scenario, because the downstream neighbor has not restarted yet, | |||
Node B detects the communication with Node C is interrupted and | Node B detects the communication with Node C is interrupted and | |||
must wait before resynchronizing with its downstream neighbor. | must wait before resynchronizing with its downstream neighbor. | |||
In this case, the Restarting node (Node B) follows the procedures | In this case, the Restarting node (Node B) follows the procedures | |||
in section 9.3 of [RFC3473] and may run a Restart Timer to wait for | in section 9.3 of [RFC3473] and may run a Restart Timer to wait for | |||
the downstream neighbor (Node C) to restart. If its downstream | the downstream neighbor (Node C) to restart. If its downstream | |||
neighbor (Node C) has not restarted before the timer expires the | neighbor (Node C) has not restarted before the timer expires the | |||
skipping to change at page 11, line 21 | skipping to change at page 11, line 21 | |||
plane and the data plane on the nodes that are waiting for the | plane and the data plane on the nodes that are waiting for the | |||
failed device to restart. | failed device to restart. | |||
If the downstream Delayed Restarting node restarts after the | If the downstream Delayed Restarting node restarts after the | |||
cleanup of LSPs at Node C, the RecoveryPath message from Node D | cleanup of LSPs at Node C, the RecoveryPath message from Node D | |||
will be responded with a PathTear message. If the upstream Delayed | will be responded with a PathTear message. If the upstream Delayed | |||
Restarting node restarts after the cleanup of LSPs at Node C, the | Restarting node restarts after the cleanup of LSPs at Node C, the | |||
Path message from Node B will be treated as a new LSP setup request, | Path message from Node B will be treated as a new LSP setup request, | |||
but the setup will fail because Node D cannot be reached - Node C | but the setup will fail because Node D cannot be reached - Node C | |||
will respond with a PathErr message. Since this happens to Node B | will respond with a PathErr message. Since this happens to Node B | |||
during its restart processing, it should follow the rules of [GR- | during its restart processing, it should follow the rules of | |||
EXT] and tear down the LSP. | [RFC5063] and tear down the LSP. | |||
5.2.4. Procedures for scenario 4 | 5.2.4. Procedures for scenario 4 | |||
When the Ingress node (Node A) restarts, it does not know which | When the Ingress node (Node A) restarts, it does not know which | |||
LSPs it caused to be created. Usually, however, this information is | LSPs it caused to be created. Usually, however, this information is | |||
retrieved from the management plane or from the configuration | retrieved from the management plane or from the configuration | |||
requests stored in non-volatile form in the node in order to | requests stored in non-volatile form in the node in order to | |||
recover the LSP state. | recover the LSP state. | |||
Furthermore, if the downstream node (Node B) is a Normal node, | Furthermore, if the downstream node (Node B) is a Normal node, | |||
according to the procedures in [GR-EXT], the ingress will receive a | according to the procedures in [RFC5063], the ingress will receive | |||
RecoveryPath message and will understand that it was the ingress of | a RecoveryPath message and will understand that it was the ingress | |||
the LSP. | of the LSP. | |||
However, in this scenario, the downstream node is a Delayed | However, in this scenario, the downstream node is a Delayed | |||
Restarting node, so Node A must rely on the information from the | Restarting node, so Node A must rely on the information from the | |||
management plane or stored configuration, or it must wait for Node | management plane or stored configuration, or it must wait for Node | |||
B to restart. | B to restart. | |||
In the event that Node B never restarts, management plane | In the event that Node B never restarts, management plane | |||
intervention may be used at Node A to clean up any LSP state | intervention may be used at Node A to clean up any LSP state | |||
restored from the management plane or from local configuration. | restored from the management plane or from local configuration. | |||
skipping to change at page 12, line 38 | skipping to change at page 12, line 38 | |||
plane resources and to over-ride the control plane. In this context, | plane resources and to over-ride the control plane. In this context, | |||
the management plane must always be able to release data plane | the management plane must always be able to release data plane | |||
resources that were previously in place for use by control-plane | resources that were previously in place for use by control-plane | |||
established LSPs. Further, the management plane must always be able | established LSPs. Further, the management plane must always be able | |||
to instruct any control plane node to tear down any LSP. | to instruct any control plane node to tear down any LSP. | |||
Operators should be aware of the risks of misconnection that could | Operators should be aware of the risks of misconnection that could | |||
be caused by careless manipulation from the management plane of in- | be caused by careless manipulation from the management plane of in- | |||
use data plane resources. | use data plane resources. | |||
6. Security Considerations | 6. Clarification of Restarting Node Procedure | |||
According to the current graceful restart procedure [RFC3473], | ||||
after a node restarts its control plane, it needs its upstream node | ||||
to send PATH message with recovery label to synchronize its RSVP | ||||
state. If the restarted control plane becomes operational quickly, | ||||
the upstream node may not detect the restarting of downstream node | ||||
and therefore, may send a PATH message without recovery label | ||||
causing errors and unwanted connection deletion. | ||||
N1 N2 | ||||
| | | ||||
| X (Restart start) | ||||
| HELLO | | ||||
|--------------->| | ||||
| | | ||||
| SRefresh | | ||||
|--------------->| | ||||
| | | ||||
| HELLO | | ||||
|--------------->| | ||||
| | | ||||
| X (Restart complete) | ||||
| SRefresh | | ||||
|--------------->| | ||||
| NACK | | ||||
|<---------------| | ||||
| Path without | | ||||
| recovery label | | ||||
|--------------->| | ||||
| X (resoure allocation failed because the | ||||
| | resouces are in use) | ||||
| PathErr | | ||||
|<---------------| | ||||
| PathTear | | ||||
|--------------->| | ||||
X(CON deletion) X (XCON deletion) | ||||
| | | ||||
The sequence diagram above depicts one scenario where the LSP may | ||||
get deleted. | ||||
In this sequence N1 did not detect hello failure and continues | ||||
sending SRefreshes which may get NACK'ed by N2 once restart | ||||
completes because there is no Path state corresponding to the | ||||
SRefresh message. This NACK causes a Path refresh message to be | ||||
generated but there is no RECOVERY_LABEL because N1 did not yet | ||||
detect that N2 has restarted as hello exchanges have not yet | ||||
started. The Path message is treated as "new" and fails to allocate | ||||
the resources because they are still in use. This causes a PathErr | ||||
message to be generated which may lead to the tear down of the LSP. | ||||
To resolve the aforementioned problem, the following procedures are | ||||
proposed and are meant to work together with the recovery | ||||
procedures documented in [RFC3473]. Here, it is assumed that the | ||||
restarting node and the neighboring node(s) support Hello extension | ||||
as documented in [RFC3209] and recovery procedures documented in | ||||
[RFC3473]. | ||||
After a node restarts its control plane, it should ignore and | ||||
silently drop all RSVP-TE messages, except hello messages, it | ||||
receives from any neighbor to which, no HELLO session has been | ||||
established. | ||||
The restarting node should follow [RFC3209] to establish Hello | ||||
sessions with its neighbors, after its control plane becomes | ||||
operational. | ||||
The restarting node resumes processing of RSVP-TE messages sent | ||||
from each neighbor to which the Hello session has been established. | ||||
7. Security Considerations | ||||
This document clarifies the procedures to be performed on RSVP | This document clarifies the procedures to be performed on RSVP | |||
agents that neighbor one or more restarting RSVP agents. In the | agents that neighbor one or more restarting RSVP agents. In the | |||
case of the control plane in general, and the RSVP agent in | case of the control plane in general, and the RSVP agent in | |||
particular, where one or more nodes carrying one or more LSPs are | particular, where one or more nodes carrying one or more LSPs are | |||
restarted due to external attacks, the procedures defined in [GR- | restarted due to external attacks, the procedures defined in | |||
EXT] and described in this document provide the ability for the | [RFC5063] and described in this document provide the ability for | |||
restarting RSVP agents to recover the RSVP state in each restarting | the restarting RSVP agents to recover the RSVP state in each | |||
node corresponding to the LSPs, with the least possible | restarting node corresponding to the LSPs, with the least possible | |||
perturbation to the rest of the network. Ideally, only the | perturbation to the rest of the network. Ideally, only the | |||
neighboring RSVP agents should notice the restart and hence need to | neighboring RSVP agents should notice the restart and hence need to | |||
perform additional processing. This allows for a network with | perform additional processing. This allows for a network with | |||
active LSPs to recover LSP state gracefully from an external attack, | active LSPs to recover LSP state gracefully from an external attack, | |||
without perturbing the data/forwarding plane state. | without perturbing the data/forwarding plane state. | |||
7. IANA Considerations | 8. IANA Considerations | |||
This document defines no new protocols or extensions and makes no | This document defines no new protocols or extensions and makes no | |||
requests to IANA for registry management. | requests to IANA for registry management. | |||
8. Acknowledgments | 9. Acknowledgments | |||
We would like to thank Adrian Farrel, Dimitri Papadimitriou, and | We would like to thank Adrian Farrel, Dimitri Papadimitriou, and | |||
Lou Berger for their useful comments. | Lou Berger for their useful comments. | |||
9. References | 10. References | |||
9.1. Normative References | 10.1. Normative References | |||
[RFC2209] R. Braden, L. Zhang, "Resource ReSerVation Protocol | [RFC2209] R. Braden, L. Zhang, "Resource ReSerVation Protocol (RSVP) | |||
(RSVP) -- Version 1 Message Processing Rules", RFC 2209, | -- Version 1 Message Processing Rules", RFC 2209, September | |||
September 1997. | 1997. | |||
[RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, | [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., | |||
V., and G. Swallow, "RSVP-TE: Extensions to RSVP for | and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP | |||
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 | Engineering (RSVP-TE) Extensions", RFC 3473, January 2003. | |||
2003. | ||||
[GR-EXT] A. Satyanarayana, R. Rahman, "Extensions to GMPLS RSVP | [RFC5063] A. Satyanarayana, R. Rahman, "Extensions to GMPLS RSVP | |||
Graceful Restart", Internet Draft, work in progress, | Graceful Restart", RFC 5063, September 2007. | |||
draft-ietf-ccamp-rsvp-restart-ext-08.txt, January 2007. | ||||
10. Authors' Addresses | 11. Authors' Addresses | |||
Dan Li | Dan Li | |||
Huawei Technologies Co., Ltd. | Huawei Technologies Co., Ltd. | |||
F3-5-B R&D Center, Huawei Base, | F3-5-B R&D Center, Huawei Base, | |||
Bantian, Longgang District | Bantian, Longgang District | |||
Shenzhen 518129 P.R.China | Shenzhen 518129 P.R.China | |||
Phone: +86-755-28972910 | Phone: +86-755-28972910 | |||
Email: danli@huawei.com | Email: danli@huawei.com | |||
skipping to change at page 14, line 33 | skipping to change at page 16, line 33 | |||
Email: gjhhit@huawei.com | Email: gjhhit@huawei.com | |||
Arun Satyanarayana | Arun Satyanarayana | |||
Cisco Systems, Inc. | Cisco Systems, Inc. | |||
170 West Tasman Dr. | 170 West Tasman Dr. | |||
San Jose, CA 95134, USA | San Jose, CA 95134, USA | |||
Phone: +1 408 853-3206 | Phone: +1 408 853-3206 | |||
Email: asatyana@cisco.com | Email: asatyana@cisco.com | |||
11. Full Copyright Statement | Snigdho C. Bardalai | |||
Fujitsu Network Communications, Inc. | ||||
2801 Telecom Parkway, | ||||
Richardson, Texas 75082 | ||||
United States of America | ||||
Phone: +1 972 479 2951 | ||||
Email: snigdho.bardalai@us.fujitsu.com | ||||
12. 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 | This document and the information contained herein are provided on | |||
an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE | an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE | |||
REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE | REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE | |||
IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL | IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL | |||
WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY | WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY | |||
WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE | WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE | |||
ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS | ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS | |||
FOR A PARTICULAR PURPOSE. | FOR A PARTICULAR PURPOSE. | |||
12. Intellectual Property Statement | 13. Intellectual Property Statement | |||
The IETF takes no position regarding the validity or scope of any | The IETF takes no position regarding the validity or scope of any | |||
Intellectual Property Rights or other rights that might be claimed | Intellectual Property Rights or other rights that might be claimed | |||
to pertain to the implementation or use of the technology described | to pertain to the implementation or use of the technology described | |||
in this document or the extent to which any license under such | in this document or the extent to which any license under such | |||
rights might or might not be available; nor does it represent that | rights might or might not be available; nor does it represent that | |||
it has made any independent effort to identify any such rights. | it has made any independent effort to identify any such rights. | |||
Information on the procedures with respect to rights in RFC | Information on the procedures with respect to rights in RFC | |||
documents can be found in BCP 78 and BCP 79. | documents can be found in BCP 78 and BCP 79. | |||
End of changes. 30 change blocks. | ||||
52 lines changed or deleted | 131 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/ |