sanity of its forwarding table(s) across an unplanned restart. In
any event, implementors providing the option to recover gracefully
from unplanned outages must allow a network operator to turn the
option off.
In contrast to the procedure for planned restart/reloads that was
described in Section 2.1, a router attempting graceful restart after
an unplanned outage must originate grace-LSAs *after* its control
software resumes operation. The following points must be observed
during this grace-LSA origination.
o The grace-LSAs must be originated and be sent *before* the
restarted router sends any OSPF Hello Packets. On broadcast
networks, this LSA must be flooded to the AllSPFRouters multicast
address (224.0.0.5) since the restarting router is not aware of
its previous DR state.
o The grace-LSAs are encapsulated in Link State Update Packets and
sent out to all interfaces, even though the restarted router has
no adjacencies and no knowledge of previous adjacencies.
o To improve the probability that grace-LSAs will be delivered, an
implementation may send them multiple times (see for example the
Robustness Variable in [8]).
o The restart reason in the grace-LSAs must be set to 0 (unknown) or
3 (switch to redundant control processor). This enables the
neighbors to decide whether they want to help the router through
an unplanned restart.
6. Interaction with Traffic Engineering
The operation of the Traffic Engineering Extensions to OSPF [4]
during OSPF Graceful Restart is specified in [6].
7. Possible Future Work
Devise a less conservative algorithm for graceful restart helper
termination that provides a comparable level of black hole and
routing loop avoidance.
8. Intellectual Property Rights Notice
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 implementors 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.
9. References
9.1. Normative References
[1] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998.
[2] Coltun, R., "The OSPF Opaque LSA Option", RFC 2370, July 1998.
9.2. Informative References
[3] Murphy, S., Badger, M. and B. Wellington, "OSPF with Digital
Signatures", RFC 2154, June 1997.
[4] Katz, D., Kompella, K. and D. Yeung, "Traffic Engineering (TE)
Extensions to OSPF Version 2", RFC 3630, September 2003.
[5] Murphy, P., "The OSPF Not-So-Stubby Area (NSSA) Option", RFC
3101, January 2003.
[6] Kompella, K., et al., "Routing Extensions in Support of
Generalized MPLS", Work in Progress.
[7] Moy, J., "Extending OSPF to Support Demand Circuits", RFC 1793,
April 1995.
[8] Cain, B., Deering, S., Kouvelas, I., Fenner, B. and A.
Thyagarajan, "Internet Group Management Protocol, Version 3", RFC
3376, October 2002.
A. Grace-LSA Format
The grace-LSA is a link-local scoped Opaque-LSA [2], having an Opaque
Type of 3 and an Opaque ID equal to 0. Grace-LSAs are originated by
a router that wishes to execute a graceful restart of its OSPF
software. A grace-LSA requests that the router’s neighbors aid in
its graceful restart by continuing to advertise the router as fully
adjacent during a specified grace period.
Each grace-LSA has an LS age field set to 0 when the LSA is first
originated; the current value of the LS age then indicates how long
ago the restarting router made its request. The body of the LSA is
TLV-encoded. The TLV-encoded information includes the length of the
grace period, the reason for the graceful restart and, when the
grace-LSA is associated with a broadcast, NBMA or Point-to-MultiPoint
network segment, the IP interface address of the restarting router.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS age | Options | 9 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 3 | 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Advertising Router |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS sequence number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS checksum | length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+- TLVs -+
| ... |
The format of the TLVs within the body of a grace-LSA is the same as
the format used by the Traffic Engineering Extensions to OSPF [4].
The LSA payload consists of one or more nested Type/Length/Value
(TLV) triplets. The format of each TLV is:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Length field defines the length of the value portion in octets
(thus a TLV with no value portion would have a length of zero). The
TLV is padded to four-octet alignment; padding is not included in the
length field (so a three octet value would have a length of three,
but the total size of the TLV would be eight octets). Nested TLVs
are also 32-bit aligned. For example, a one byte value would have
the length field set to 1, and three bytes of padding would be added
to the end of the value portion of the TLV. Unrecognized types are
ignored.
The following is the list of TLVs that can appear in the body of a
grace-LSA:
o Grace Period (Type=1, length=4). The number of seconds that the
router’s neighbors should continue to advertise the router as
fully adjacent, regardless of the state of database
synchronization between the router and its neighbors. Since this
time period began when grace-LSA’s LS age was equal to 0, the
grace period terminates when either:
a) the LS age of the grace-LSA exceeds the value of a Grace Period
or
b) the grace-LSA is flushed. See Section 3.2 for other conditions
that terminate graceful restart.
This TLV must always appear in a grace-LSA.
o Graceful restart reason (Type=2, length=1). Encodes the reason
for the router restart as one of the following: 0 (unknown), 1
(software restart), 2 (software reload/upgrade) or 3 (switch to
redundant control processor). This TLV must always appear in a
grace-LSA.
o IP interface address (Type=3, length=4). The router’s IP
interface address on the subnet associated with the grace-LSA.
Required on broadcast, NBMA and Point-to-MultiPoint segments,
where the helper uses the IP interface address to identify the
restarting router (see Section 3.1).
DoNotAge is never set in a grace-LSA, even if the grace-LSA is
flooded over a demand circuit [7]. This is because the grace-LSA’s
LS age field is used to calculate the duration of the grace period.
Grace-LSAs have link-local scope because they only need to be seen by
the router’s direct neighbors.
Additional Grace-LSA TLVs must be described in an Internet Draft and
will be subject to the expert review of the OSPF Working Group.
B. Configurable Parameters
OSPF graceful restart parameters are suggested below. Section B.1
contains a minimum subset of parameters that should be supported.
B.2 includes some additional configuration parameters that an
implementation may choose to support.
B.1. Global Parameters (Minimum subset)
RestartSupport
The router’s level of support for OSPF graceful restart.
Allowable values are none, planned restart only, and
planned/unplanned.
RestartInterval
The graceful restart interval in seconds. The range is from 1 to
1800 seconds, with a suggested default of 120 seconds.
B.2. Global Parameters (Optional)
RestartHelperSupport
The router’s support for acting as an OSPF restart helper.
Allowable values are none, planned restart only, and
planned/unplanned.
RestartHelperStrictLSAChecking
Indicates whether or not an OSPF restart helper should terminate
graceful restart when there is a change to an LSA that would be
flooded to the restarting router or when there is a changed LSA on
the restarting router’s retransmission list when graceful restart
is initiated. The suggested default is enabled.
Security Considerations
One of the ways to attack a link-state protocol such as OSPF is to
inject false LSAs into, or corrupt existing LSAs in, the link-state
database. Injecting a false grace-LSA would allow an attacker to
spoof a router that, in reality, has been withdrawn from service.
The standard way to prevent such corruption of the link-state
database is to secure OSPF protocol exchanges using the cryptographic
authentication specified in [1]. An even stronger way of securing
link-state database contents has been proposed in [3].
When cryptographic authentication [1] is used on the restarting
router the preservation of received sequence numbers in non-volatile
storage is not mandatory. There is a risk that a replayed Hello
packet could cause neighbor state for a deceased neighbor to be
created. However, the risk is no greater than during normal
operation.
Acknowledgments
The authors wish to thank John Drake, Vishwas Manral, Kent Wong, and
Don Goodspeed for their helpful comments. We also wish to thank Alex
Zinin and Bill Fenner for their thorough review.
Authors’ Addresses
J. Moy
Sycamore Networks, Inc.
150 Apollo Drive
Chelmsford, MA 01824
Phone: (978) 367-2505
Fax: (978) 256-4203
EMail: jmoy@sycamorenet.com
Padma Pillay-Esnault
Juniper Networks
1194 N, Mathilda Avenue
Sunnyvale, CA 94089-1206
EMail: padma@juniper.net
Acee Lindem
Redback Networks
102 Carric Bend Court
Cary, NC 27519
EMail: acee@redback.com
Full Copyright Statement
Copyright (C) The Internet Society (2003). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assignees.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS 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.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.