Internet DRAFT - draft-jian-ccamp-multinodes-rsvp-restart
draft-jian-ccamp-multinodes-rsvp-restart
Network Working Group JiangWeilian(ZTE Corporation)
FengJun(ZTE Corporation)
Internet-Draft CuiYing(ZTE Corporation)
Expires: May 20, 2006 KongYong(ZTE Corporation)
LuoJian(ZTE Corporation)
November 20, 2005
Mechanism of multiple adjacent nodes RSVP
graceful restart Simultaneously
draft-jian-ccamp-multinodes-rsvp-restart-00
Status of this Memo
This document is an Internet-Draft and is subject to all provisions
of Section 5 of RFC3209, Section 9 of RFC3473.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as
Internet-Drafts.
By submitting this Internet-Draft, each author represents that any
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
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other
documents at any time. It is inappropriate to use Internet-Drafts
as reference material or to cite them other than as "work in
progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/1id-abstracts.html
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
This Internet-Draft will expire on May 20, 2006.
Copyright Notice
Copyright (C) The Internet Society (2005). All Rights Reserved.
Luojian Expires: May 2006 [Page 1]
Internet-Draft draft-jian-ccamp-multinodes-rsvp-restart-00 Oct. 2005
Abstract
Based on the RSVP graceful restart defined in the RFC3473, RFC3209,
Node ID RSVP Hello:A Clarification Statement (draft-ietf-ccamp-rsvp
-node-id-based-hello-02) and the Extensions to GMPLS RSVP Graceful
Restart (draft-ietf-ccamp-rsvp-restart-ext-05), this document puts
forward extension to solve the problem for the restart node to
actively inform RSVP graceful restart to the neighbor, and further
provides the relevant mechanism to support recovery processing of
RSVP graceful restart at simultaneous restart of multiple adjacent
nodes.
Table of Contents
1. Conventions used in this document. . . . . . . . . . . . . . 3
2. Terms and abbreviation . . . . . . . . . . . . . . . . . . . 3
3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 3
4. Actively Informing Neighbor
of RSVP GR Capability by Restarted Node . . . . . . . . . . . 4
4.1 Adopting Multicast Address . . . . . . . . . . . . . . . . . 4
4.2 Adopting Hot Backup . . . . . . . . . . . . . . . . . . . . . 5
5. RSVP GR Processing at Simultaneous Restart
of Multiple Adjacent Nodes . . . . . . . . . . . . . . . . 5
5.1 Multiple Adjacent Restart Nodes are Intermediate
Nodes of the Tunnel . . . . . . . . . . . . . . . . . . . . . 5
5.2 Multiple Adjacent Restart Nodes Contain
Tunnel Tail Node . . . . . . . . . . . . . . . . . . . . . . 7
5.3 Multiple Adjacent Restart Nodes Contain
Tunnel Head Node. . . . . . . . . . . . .. . . . . . . . . 7
5.4 Multiple Adjacent Restart Nodes Contain
All the Tunnel Nodes. . . . . . . . . . . . . . . . . . . . . 9
6. References . . . . . . . . . . . . . . . . . . . . . . . . 9
Luojian Expires: May 2006 [Page 2]
Internet-Draft draft-jian-ccamp-multinodes-rsvp-restart-00 Oct. 2005
1 Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in
this document are to be interpreted as described in [RFC-2119].
2 Terms and abbreviation
Suppose the reader is familiar with terms defined in [RFC3209],
[RFC3473].
3 Overview
In the RSVP Graceful Restart defined in Section 9 of RFC3473, the
Hello mechanism defined by RFC3209 is extended to support GR
(Graceful Restart) capability informing and fault detection between
RSVP neighbors. It aims to define Resatrt_Cap object for Hello
extension to carry GR capability parameter and inform it to the
neighbor through Hello message interaction.
The Hello mechanism defined by RFC3209 defines the message
destination address and source address as the inter-neighbor
interface IP address in turn. In draft-ietf-ccamp-rsvp-node-id-based
-hello-02, the extension defines that the destination address and
source address of Hello message supporting GR are TE RouterID of
respective nodes.
Then, the restart node is usually at a passive position. Only after
it receives the RSVP GR Hello message from the neighbor, will it
inform the neighbor of its GR capability b returning the ACK message.
For restart of a single node, GR capability informing in the passive
mode is also acceptable.
If multiple adjacent nodes restart at the same time, however, these
nodes cannot learn about the GR capability from each other. This
document puts forward the solution of using the multicast address as
destination address or adopting the hot backup technology to
implement active informing of restarted node RSVP GR capability, and
further provides the relevant mechanism to support recovery
processing of RSVP GR at simultaneous restart of multiple adjacent
nodes.
Luojian Expires: May 2006 [Page 3]
Internet-Draft draft-jian-ccamp-multinodes-rsvp-restart-00 Oct. 2005
4 Actively Informing Neighbor of RSVP GR Capability by Restarted Node
4.1 Adopting Multicast Address
After the node restarts and makes sure it supports RSVP GR Recovery,
it can periodically send the GR HELLO message outward in the 1/2
RecoveryTime through all the RSVP interfaces to inform its GR
capability. Main field data composing the GR HELLO request message:
The destination IP address is multicast address (IPv4: 224.0.0.2;
IPv6: FF02:0:0:0:0:0:0:2).
The source IP address is the local TE RouterID.
The source instance value is the created value (the neighbors
under different interfaces can be the same).
The destination instance value is 0.
The Restart time value of Restart_Cap object is the local
configuration value.
The Recovery time of Restart_Cap object is the local configuration
value.
The R digit value of Capability object is 1 (it indicates the node
supports receiving of the RecoveryPath message).
The T digit value of Capability object is 1 (it indicates the node
supports sending of the RecoveryPath message).
The S digit value of Capability object is 0 (it indicates the node
does not support abstract refreshing message; for support, it can
be set as 1).
The Reserved digit value of Capability object is 0.
When the neighbor receives the GR HELLO request message with this
destination address as multicast address, it can first use the
informed source RouterID as the neighbor RouterID and local RouterID
to query if the corresponding HELLO instance exists:
If the instance does not exist, it will create a corresponding
instance, save the GR capability parameter informed by the peer,
and confirms restart of the peer node based on the fact that the
destination IP address is the multicast address. According to the
informed GR capability parameter, it confirms that the peer is in
the Recovery stage, replies the ACK message to the restart
neighbor based on its GR capability, and then creates the
corresponding Recovery Timer.
Luojian Expires: May 2006 [Page 4]
Internet-Draft draft-jian-ccamp-multinodes-rsvp-restart-00 Oct. 2005
If the instance exists, it will save the GR capability parameter
informed by the peer, and reply the ACK message to the restart
neighbor based on its GR capability.
After receiving the ACK reply message from the neighbor, the restart
node can create the corresponding GR Hello instance in accordance
with the information in the message. By now, the GR Hello relation
between the restart node and neighbor node is reestablished.
If the destination IP address of the GR HELLO request message
received by the restart node from its neighbor is also the multicast
address, it means that the neighbor node is also a restart node. In
this case, it similarly creates a corresponding instance, saves the
GR capability parameter informed by the peer, confirms that the peer
node is restarted and in the Recovery stage, and creates the
corresponding Recovery Timer.
After 1/2RecoveryTime, the restart node must stop sending of the GR
Hello message with the destination IP address as multicast address.
In stead, it just implements GR Hello communication according to the
created GR Hello instance.
4.2 Adopting Hot Backup
If the node conducts hot backup of key data for the established GR
HELLO instance, such as the neighbor RouterID, local RouterID, source
instance value, destination instance value, outgoing interface and
the next-hop address.
Then, the restart node, after hot backup switching and restart, can
get the hot backup GR HELLO instance data before restart, and
actively constitute a GR Hello instance based on these data to send
a new GR Hello message to inform the neighbor. Then, it
reestablishes the GR HELLO relation with the neighbor node.
5 RSVP GR Processing at Simultaneous Restart of Multiple Adjacent Nodes
Suppose Tunnel1 is established along with the LSR1-LSR2-LSR3-LSR4
path. LSR1, LSR2, LSR3 and LSR4 all support RSVP GR, and all the
nodes support sending and receiving of the Recovery Path message.
5.1 Multiple Adjacent Restart Nodes are Intermediate Nodes of the Tunnel
Suppose LSR2 and LSR3 start at the same time.
LSR1 and LSR4 enter the Restart stage, and they send the GR Hello
message to LSR2 and LSR3 in turn.
Luojian Expires: May 2006 [Page 5]
Internet-Draft draft-jian-ccamp-multinodes-rsvp-restart-00 October 2005
After the LSR2 and LSR3 restart, they will enter the GR Recovery
stage according to the configuration. With the method described in
Section 4, a GR Hello relation can be set up between LSR2 and LSR3,
and they can learn that the peer party is in the GR Recovery stage.
At the same time, LSR1 and LSR4 will send the GR Hello request
message to LSR2 and LSR3 in turn, and LSR2 and LSR3 will create
the corresponding GR HELLO instance, respond to the request messages
from LSR1 and LSR4, inform the peer party of support to GR, and then
enter the Recovery stage together.
After that, LSR1 will send the Path message with Recovery Label
object to LSR2. (if sending and receiving of RecoveryPath message are
supported, LSR4 will also send the RecoveryPath message to LSR3).
After receiving the Path message with Recovery Label object, LSR2
will check if the corresponding PSB exists. Suppose it cannot be
found, but the corresponding entry is found from the MPLS forwarding
table, LSR2 will create the corresponding PSB.
However, because the GR Hello relation has been established between
LSR2 and LSR3, and they learn that the peer part is in the GR
Recovery stage, then LSR2 can send the Path message carrying Recovery
Label object to LSR3. Here, the outgoing label and outgoing interface
are obtained by query of the forwarding table, and the next-hop
address can be obtained through the ERO object of Path message sent
upstream.
After receiving the Path message carrying Recovery Label object from
the restart node LSR2, LSR3 will find out if the corresponding PSB
exists according to the received Path message. Suppose it is not
found, but the corresponding entry is found from the MPLS forwarding
table. Then, LSR3 creates the corresponding PSB, constitutes the
Path message containing Suggested Label object and sends it to the
downstream LSR4.
After receiving the Path refreshing message containing Suggested
Label object from the restart node LSR3, LSR4 resolves the incoming
label of LSP for recovery through the Suggested_Label object in
the Path message. Then, it matches the corresponding RSB, refreshes
(clears) the stale flag for the corresponding forwarding table
entry, and triggers the corresponding Resv message to send it to
LSR3.
LSR3 receives the Resv message from LSR4, creates RSB and associates
the corresponding PSB. Now, both the incoming label and outgoing
label are refreshed. LSR3 clears the stale flag for the corresponding
forwarding entry and sends the Resv message to LSR2.
Luojian Expires: May 2006 [Page 6]
Internet-Draft draft-jian-ccamp-multinodes-rsvp-restart-00 October 2005
LSR2 receives the Resv message from LSR3, creates RSB and associates
the corresponding PSB. Now, both the incoming label and outgoing
label are refreshed. LSR2 clears the stale flag for the corresponding
forwarding entry and sends the Resv message to LSR1.
LSR1 receives the Resv message, refreshes RSB, and clears the stale
flag of relevant protocol state. Now, Tunnel1 is completely
recovered.
5.2 Multiple Adjacent Restart Nodes Contain Tunnel Tail Node
Suppose LSR2, LSR3 and LSR4 start at the same time.
LSR1 enters the Restart stage, and it sends the GR Hello message to
LSR2.
After LSR2, LSR3 and LSR4 all restart, they will enter the GR
Recovery stage according to the configuration. With the method
described in Section 4, a GR Hello relation can be set up between
LSR2, LSR3 and LSR4, and they can learn that the peer party is in
the GR Recovery stage.
At the same time, LSR1 will send the GR Hello request message to
LSR2, and LSR2 will create the corresponding GR HELLO instance,
respond to the request messages from LSR1, inform the peer party of
support to GR, and then enter the Recovery stage together.
After that, LSR1 will send the Path message with Recovery Label
object to LSR2.
The following handing is the same as the description in Section
5.1. The Path message is sent to LSR3. After handing by LSR3, the
Path carrying Recovery Label object is sent to LSR4, instead of the
Path message carrying Suggested Label object.
Then, LSR4 sends the Resv message upstream, and each hop is
recovered in turn along with the upstream path till LSR1. Finally,
Tunnel1 is completely recovered.
5.3 Multiple Adjacent Restart Nodes Contain Tunnel Head Node
Suppose LSR1, LSR2 and LSR3 start at the same time.
LSR4 enters the Restart stage, and it sends the GR Hello message to
LSR3.
After LSR1, LSR2 and LSR3 all restart, they will enter the GR
Recovery stage according to the configuration. With the method
described in Section 4, a GR Hello relation can be set up between
LSR1, LSR2 and LSR3, and they can learn that the peer party is in
the GR Recovery stage.
Luojian Expires: May 2006 [Page 7]
Internet-Draft draft-jian-ccamp-multinodes-rsvp-restart-00 October 2005
At the same time, LSR4 will send the GR Hello request message to
LSR3, and LSR3 will create the corresponding GR HELLO instance,
respond to the request messages from LSR4, inform the peer party of
support to GR, and then enter the Recovery stage together.
After that, only LSR4 will send the Recovery Path message to LSR3.
(therefore, we suppose all the nodes support sending and receiving
of the Recovery Path message.)
When receiving the RecoveryPath message from the assistant node
LSR4, LSR3 will find out if the corresponding PSB exists according
to the received PATH message. Suppose it is not found, but the
corresponding entry is found from the MPLS forwarding table. Then,
LSR3 creates the corresponding PSB (possibly the original Path
message should have the RRO object, which can be used to get the
previous-hop address and recover the ERO containing the previous-hop
address), and constitutes the Path message containing Suggested Label
object to send it to the downstream LSR4 and wait for the Resv
message from LSR4.
After receiving the Path refreshing message containing Suggested
Label object from the restart node LSR3, LSR4 resolves the incoming
label of LSP for recovery through the Suggested_Label object in the
Path message. Then, it matches the corresponding RSB, refreshes
(clears) the stale mark for the corresponding forwarding table entry,
and triggers the corresponding Resv message to send it to LSR3.
After receiving the Resv message from LSR4, LSR3 creates the
corresponding RSB, and refreshes (clears) the stale flag for the
corresponding forwarding table entry. Then, LSR3 will send the
Recovery Path message to LSR2.
The same as handling of LSR3, LSR2, after receiving the RecoveryPath
message from LSR3, will create the corresponding PSB, constitute the
Path message containing Suggested Label object to send it to the
downstream LSR3 and wait for the Resv message from LSR3.
After receiving the Resv message from LSR3, LSR2 creates the
corresponding RSB, and refreshes (clears) the stale flag for the
corresponding forwarding table entry. Then, LSR2 will send the
Recovery Path message to LSR1.
Similarly, LSR1 creates the corresponding PSB and RSB, and refreshes
(clears) the stale flag for the corresponding forwarding table entry.
Now, Tunnel1 is completely recovered.
Luojian Expires: May 2006 [Page 8]
Internet-Draft draft-jian-ccamp-multinodes-rsvp-restart-00 October 2005
5.4 Multiple Adjacent Restart Nodes Contain All the Tunnel Nodes
Suppose LSR1, LSR2, LSR3 and LSR4 start at the same time.
After LSR1, LSR2, LSR3 and LSR4 all restart, they will enter the GR
Recovery stage according to the configuration. With the method
described in Section 4, a GR Hello relation can be set up between
LSR1, LSR2, LSR3 and LSR4, and they can learn that the peer party is
in the GR Recovery stage.
However, none of the four LSRs has the Tunnel1 protocol state data
before restart, so they cannot constitute any recovery Path message
to be sent to the neighbor. In this case, Tunnel1 can only wait for
reestablishment of LSR1 after the GR Recovery stage ends.
6 References
[RFC3209] Awduche, D., et al., "Extensions to RSVP for LSP
Tunnels", December 2001.
[RFC3473] Berger, L., et al., "Generalized Multi-Protocol Label
Switching (GMPLS) Signaling Resource ReserVation
Protocol-Traffic Engineering (RSVP-TE) Extensions",
January 2003.
[RFC1112] Deering, S., "Host Extensions for IP Multicasting",
Stanford University, August 1989.
[RFC2375] Hinden, R., et al., "IPv6 Multicast Address Assignments",
July 1998.
IANA ˇ°INTERNET MULTICAST ADDRESSESˇ±, September 2005
[draft-ietf-ccamp-rsvp-node-id-based-hello-02]
Zafar Ali, et al.,"Node ID based RSVP Hello: A
Clarification Statement", September 2005.
[draft-ietf-ccamp-rsvp-restart-ext-05]
Satyanarayana, et al., "Extension to GMPLS RSVP Graceful
Restart", September 2005.
Luojian Expires: May 2006 [Page 9]
Internet-Draft draft-jian-ccamp-multinodes-rsvp-restart-00 October 2005
Authors Addresses
JiangWeilian
No.68 Zijinghua Road, Yuhuatai District
Nanjing, China
Phone: +86-025-52871644
Email: jiang.weilian@zte.com.cn
FengJun
No.68 Zijinghua Road, Yuhuatai District
Nanjing, China
Phone: +86-025-52871631
Email: feng.jun99@zte.com.cn
CuiYing
No.68 Zijinghua Road, Yuhuatai District
Nanjing, China
Phone: +86-025-52871631
Email: cui.ying@zte.com.cn
KongYong
No.68 Zijinghua Road, Yuhuatai District
Nanjing, China
Phone: +86-025-52871177
Email: kong.yong@zte.com.cn
LuoJian
No.68 Zijinghua Road, Yuhuatai District
Nanjing, China
Phone: +86-025-51803814
Email: luo.jian@zte.com.cn
Comments are solicited and should be addressed to the working
group's mailing list at ccamp@ops.ietf.org and/or the author(s).
Luojian Expires: May 2006 [Page 10]
Internet-Draft draft-jian-ccamp-multinodes-rsvp-restart-00 October 2005
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
intellectual property or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; neither does it represent that it
has made any effort to identify any such rights. Information on the
IETF's procedures with respect to rights in standards-track and
standards-related documentation can be found in BCP-11. Copies of
claims of rights made available for publication and any assurances of
licenses to be made available, or the result of an attempt made to
obtain a general license or permission for the use of such
proprietary rights by implementers or users of this specification can
be obtained from the IETF Secretariat.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights, which may cover technology that may be required to practice
this standard. Please address the information to the IETF Executive
Director.
Disclaimer of Validity
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Full Copyright Statement
Copyright (C) The Internet Society (2005).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
Acknowledgments
The authors would like to thank XuZhijun, DuKe, ZhuXinhua,
ChenJianye and all the other people who have contributed to this
draft, and also would like to thank all the future participants for
their comments and suggestions.
Luojian Expires: May 2006 [Page 11]
Internet-Draft draft-jian-ccamp-multinodes-rsvp-restart-00 October 2005
