Network Working Group Ina Minei
INTERNET DRAFT Rahul Aggarwal
Expiration Date: August 2004 Juniper Networks
Albert Tian
Redback Networks
LDP graceful restart for planned outages
draft-minei-mpls-ldp-planned-restart-00.txt
Status of this Memo
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/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
Copyright Notice
Copyright (C) The Internet Society 2003. All Rights Reserved.
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 oppossed
to both planned and unplanned restart).
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 [RFC2119].
draft-minei-mpls-ldp-planned-restart-00.txt [Page 1]
Internet Draft draft-minei-mpls-ldp-planned-restart-00.txt February 2004
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.
2. LDP extensions
A new Optional Parameter is defined for use in notification messages.
Optional Parameter Type Length Value
GR Data TLV TBD 16 see below
The type of the GR(Graceful Restart) Data TLV is not yet assigned,
but will be such that the U-bit is 1 and the F-bit is 0. Thus, an
LSR receiving this TLV and which doesn't support it, will simply
ignore the TLV, but process the message that carried it.
The value field of the GR Data TLV contains an FT Session TLV as
draft-minei-mpls-ldp-planned-restart-00.txt [Page 2]
Internet Draft draft-minei-mpls-ldp-planned-restart-00.txt February 2004
defined in RFC 3479. The values filled in the FT Session TLV follow
the requirements from RFC 3478.
The GR Data optional parameter will only show up in notification
messages with Shutdown Status Code. By virtue of the settings of the
U and F bits in the GR Data TLV, an LSR receiving a shutdown
notification with the optional GR Data TLV parameter, which does not
support it, will ignore the GR Data TLV paramter but process the
notification.
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.
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 GR
Data TLV. The values filled in the FT Session TLV included in the GR
Data TLV MUST be as follows: a) the Reconnect Time is 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 is zero.
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,
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 GR Data 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.
draft-minei-mpls-ldp-planned-restart-00.txt [Page 3]
Internet Draft draft-minei-mpls-ldp-planned-restart-00.txt February 2004
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 init time is zero)
4. Security considerations
The security considerations pertaining to the original LDP protocol
[RFC3036] remain relevant.
5. Intellectual Property Considerations
Juniper Networks may have intellectual property rights claimed in
regard to some of the specification contained in this document.
6. 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.
7. 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)"
draft-minei-mpls-ldp-planned-restart-00.txt [Page 4]
Internet Draft draft-minei-mpls-ldp-planned-restart-00.txt February 2004
8. Authors' Addresses
Ina Minei
Juniper Networks
1194 N.Mathilda Ave
Sunnyvale, CA 94089
e-mail: ina@juniper.net
phone: 408.745.2000
Rahul Aggarwal
Juniper Networks
1194 N.Mathilda Ave
Sunnyvale, CA 94089
e-mail: rahul@juniper.net
phone: 408.745.2000
Albert Tian
Redback Networks, Inc.
300 Holger Way
San Jose, CA 95134
Email: tian@redback.com
draft-minei-mpls-ldp-planned-restart-00.txt [Page 5]