Network Working Group Ina Minei
INTERNET DRAFT Rahul Aggarwal
Expiration Date: April 2005 Juniper Networks
Albert Tian
Redback Networks
Vasile Radoaca
Nortel Networks, Inc.
Jason Rusmisel
Alcatel
LDP graceful restart for planned outages
draft-minei-mpls-ldp-planned-restart-01.txt
Status of this Memo
By submitting this Internet-Draft, we certify that any applicable patent
or other IPR claims of which we are aware have been disclosed, or will
be disclosed, and any of which we become aware will be disclosed, in
accordance with RFC 3668.
This document is an Internet-Draft and is in full conformance with all
provisions of Section 10 of RFC2026.
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.
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
Abstract
This document proposes an enhancement to the LDP graceful restart
procedures defined in RFC 3478. The proposed extension allows operators
to apply graceful restart only when the restart is planned (as opposed
to both planned and unplanned restart).
Conventions used in this document
draft-minei-mpls-ldp-planned-restart-01.txt [Page 1]
Internet Draft draft-minei-mpls-ldp-planned-restart-01.txt October 2004
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 [RFC2119].
1. Introduction
Graceful restart assumes that the restarting LSR could preserve its
MPLS forwarding state across the restart of its control plane. Under
this assumption, RFC 3478 describes the procedures used in order to
avoid perturbing the LSPs going through the LSR whose control plane
restarted.
In a nutshell, to achieve graceful restart, both the behaviour of the
restarting LSR (LSRA) and of the neighbor of the restarting LSR
(LSRB) is changed. Most importantly for this discussion, LSRB needs
to maintain the session with LSRA, and help LSRA recover its state
from before the restart. To accomplish this, LSRB needs to know 1) if
LSRA is graceful restart capable, 2) what is the upper bound on the
time it will take LSRA to reestablish the peering and 3) what is the
time that LSRB needs to maintain LSRA's stale state.
The graceful restart capabilities and parameters are negotiated in
the Fault Tolerant (FT) Session TLV optional parameter in the session
initialization message [RFC3479]. Thus, a change in the graceful
restart capabilities requires resetting the LDP session, since the
new information needs to be signaled in a new initialization message.
A control plane restart may be an unplanned event such as a router
crash, or a planned event, such as planned downtime. An operator may
choose to use graceful restart selectively, for planned restarts
only, for example in order to achieve smooth software upgrades.
However, if toggling the graceful functionality resets the session,
the usefulness of graceful restart in such scenarios is defeated.
The proposed extension allows operators to apply graceful restart
only when the restart is planned, without having to reset the session
first. From a functionality point of view, the extensions described
in this document add the capability to do controlled shutdown and
restart of the control plane described in [RFC3479], to LSRs running
the graceful restart procedures described in [RFC3478]. This
capability is attractive to network operators since: a) it allows in-
service software upgrades for networks where graceful restart is not
part of the normal operation mode and b) it allows network operators
to gain experience and confidence with graceful restart in a
controlled environment.
draft-minei-mpls-ldp-planned-restart-01.txt [Page 2]
Internet Draft draft-minei-mpls-ldp-planned-restart-01.txt October 2004
2. LDP extensions
The FT Session TLV defined in RFC 3479 is added as an Optional
Parameter for use in notification messages.
The FT Session TLV is used in notification messages with Shutdown
Status Code. By virtue of the settings of the U and F bits in the FT
Session TLV, an LSR receiving a shutdown notification with the
optional FT Session TLV parameter, which does not support it, will
ignore the FT Session TLV parameter but process the notification.
The values filled in the FT Session TLV follow the requirements from
RFC 3478.
A new flag P is defined for use in the FT Session TLV that is
exchanged in the initialization message. The new flag is part of the
"Flags" field of the FT Session TLV and is used to indicate whether
the LSR supports graceful restart for planned outages, as described
in this draft. The value of the flag is not yet assigned.
The P flag is only used in conjunction with the L flag, when using
the FT Session TLV as described in [RFC3478].
Using the P flag, the LSR determines which of its neighbors supports
the extensions described in this document. This knowledge is not
needed for the correct operation of the extensions described here.
However, it brings value from a network operations point of view.
Before issuing a planned restart, the network operator will want to
verify that all the neighbors of the restarting LSR can provide the
behavior described in this document. Thus, the operator can determine
if he will get the expected benefits of doing a planned restart.
Rather than individually checking all neighbors, the operator can
obtain this information from the LSR that is the candidate for
planned restart.
3. Operation
In the discussion below, LSRA is the restarting LSR, and LSRB is the
neighbor of LSRA. The goal is for LSRA to do graceful restart only
for planned restarts, and do ungraceful restarts in all other cases.
Both LSRA and LSRB set the P flag in the FT Session TLV that is
exchanged at session initialization time, to indicate that they
support the extensions described in this document.
draft-minei-mpls-ldp-planned-restart-01.txt [Page 3]
Internet Draft draft-minei-mpls-ldp-planned-restart-01.txt October 2004
3.1. Changes for the LSR doing a planned restart
When performing a planned restart, LSRA MUST send a notification
message with Shutdown Status Code and with optional parameter FT
Session TLV. The values in the FT Session TLV are: a) the Reconnect
Time MUST be non-zero and long enough to allow the LDP component on
LSRA to reach the stage where it can exchange LDP messages, b) the
Recovery Time MUST be zero, and c) The P bit SHOULD be set.
The values filled in the FT Session TLV in the initialization message
MUST be set as follows: a) the Reconnect Time is zero, b) the
Recovery Time is set according to whether LSRA could preserve its
state after the restart, and c) the P bit is set.
3.2. Changes for the neighbor of the LSR doing a planned restart
When the neighbor LSRB receives a notification with Shutdown Status
Code and with the optional parameter FT Session TLV, LSRB SHOULD do
the following:
Read the values in the FT Session TLV and update the graceful restart
state for the session as if these values were received in the
initialization message. From this point on, LSRB will do the
appropriate graceful restart procedures as defined in RFC 3478.
The procedures above yield the following behaviour:
If the neighbor doesn't support graceful restart helper mode -
ungraceful restart will take place.
If the neighbor supports graceful restart helper mode, then there are
two cases: a) the neighbor supports the extensions defined here -
graceful restart will be performed, assuming LSRA could maintain its
state across the restart. b) the neighbor doesn't support the
extensions defined here - ungraceful restart will be performed (since
the reconnect time advertised at initialization time is zero)
draft-minei-mpls-ldp-planned-restart-01.txt [Page 4]
Internet Draft draft-minei-mpls-ldp-planned-restart-01.txt October 2004
4. Security considerations
The security considerations pertaining to the original LDP protocol
[RFC3036] remain relevant.
5. Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights 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; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat 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 on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at ietf-
ipr@ietf.org.
6. Full Copyright Statement
Copyright (C) The Internet Society (2004). 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.
Additional copyright notices are not permitted in IETF Documents
except in the case where such document is the product of a joint
development effort between the IETF and another standards development
organization or the document is a republication of the work of
another standards organization. Such exceptions must be approved on
an individual basis by the IAB.
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,
draft-minei-mpls-ldp-planned-restart-01.txt [Page 5]
Internet Draft draft-minei-mpls-ldp-planned-restart-01.txt October 2004
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.
7. Acknowledgments
This work is the outcome of discussions with Kireeti Kompella, Yakov
Rekhter and Arthi Ayyangar. The authors would like to thank them for
their suggestions and insight.
8. References
8.1. Normative References
[RFC1700] Reynolds, J., Postel, J., "Assigned numbers", RFC 1700,
October 1994
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", RFC 2119, March 1997.
[RFC3036] Andersson, Doolan, Feldman, Fredette, Thomas, "LDP
Specification", RFC 3036, January 2001
[RFC3478] Leelanivas M., Rekhter Y., Aggarwal R., "Graceful Restart
Mechanism for Label Distribution Protocol"
[RFC3479] Farrel A., " Fault Tolerance for the Label Distribution
Protocol (LDP)"
9. Authors' Addresses
draft-minei-mpls-ldp-planned-restart-01.txt [Page 6]
Internet Draft draft-minei-mpls-ldp-planned-restart-01.txt October 2004
Ina Minei
Juniper Networks
1194 N.Mathilda Ave
Sunnyvale, CA 94089
e-mail: ina@juniper.net
Rahul Aggarwal
Juniper Networks
1194 N.Mathilda Ave
Sunnyvale, CA 94089
e-mail: rahul@juniper.net
Albert Tian
Redback Networks, Inc.
300 Holger Way
San Jose, CA 95134
Email: tian@redback.com
Vasile Radoaca
Nortel Networks
600 Technology Park Drive
Billerica, MA 01821 USA
Email: vasile@nortelnetworks.com
Jason Rusmisel
Alcatel
600 March Road,
Kanata, Ontario,
Canada, K2K 2E6
Email: jason.rusmisel@alcatel.com
draft-minei-mpls-ldp-planned-restart-01.txt [Page 7]