[Docs] [txt|pdf] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]
Versions: 00 01
Network Working Group Alex Zinin
Internet Draft Abhay Roy
Expiration Date: September 2001 Liem Nguyen
File name: draft-ietf-ospf-restart-01.txt Cisco Systems
February 2001
OSPF Restart Signaling
draft-ietf-ospf-restart-01.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. Internet Drafts may be updated, replaced, or obsoleted by
other documents at any time. It is not appropriate to use Internet
Drafts as reference material or to cite them other than as a "working
draft" or "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.
Abstract
OSPF is a link-state intra-domain routing protocol used in IP
networks. Routers find new and detect unreachable neighbors via Hello
subprotocol. Hello OSPF packets are also used to ensure two-way
connectivity within time. When a router restarts its OSPF software,
it may not know its neighbors. If such a router sends a hello packet
on an interface, its neighbors are going to reset the adjacency,
which may not be desirable in certain conditions. This memo provides
a mechanism that allows OSPF routers to inform their neighbors about
the restart process. Note that this mechanism requires support from
neighboring routers.
1 Motivation
Zinin, Roy, Nguyen [Page 1]
INTERNET DRAFT OSPF Restart Signaling February 2001
While performing a graceful restart of OSPF software [OSPF], routers
need to prevent their neigbors from reseting their adjacencies.
However, after a reload, routers may not be aware of the neighbors
they had adjacencies with in their previous incarnations. If such a
router sends a Hello packet on an interface and this packet does not
list some neighbors, those neighbors will reset the adjacency with
restarting router.
This document describes a technique that allows restarting routers to
inform their neighbors that they may not know about some neighbors
yet and the absence of some router-IDs in the Hello packets should be
ignored.
2 Proposed solution
A new bit, called RS (restart signal) is introduced into Extended
Options TLV in the LLS block (see [LLS]). The value of this bit is
TBD (temporarily used value is 0x00000002, see Figure 1 below).
+---+---+---+---+---+---+---+- -+---+---+---+---+---+---+---+---+
| * | * | * | * | * | * | * |...| * | * | * | * | * | * | RS| LR|
+---+---+---+---+---+---+---+- -+---+---+---+---+---+---+---+---+
Figure 1. Bits in Extended Options TLV
OSPF routers should set the RS-bit in the EO-TLV attached to a Hello
packet when this is not clear that all neighbors are listed in this
packet, but the restarting router wants them to preserve their
adjacencies. The RS-bit may not be set in Hello packets longer than
RouterDeadInterval seconds.
For a definition of the LR bit, see [OOB].
2.1 Receiving Hello Packets with RS-bit set
When an OSPF router receives a Hello packet, containing the LLS block
with the EO-TLV which has the RS-bit set, the router should skip the
two-way connectivity check with the announcing neighbor (i.e., the
router should not generate a 1-WayReceived event for the neighbor if
it does not find its own router ID in the list of neighbors as
described in 10.5 of [OSPF]), provided that the neighbor FSM for this
neighbor is in the Full state.
The router should also send a unicast Hello back to the sender in
reply to a Hello packet with RS bit set. This is to speed up
learning of previously known neighbors. When sending such a reply
packet, care must be taken to ensure that the RS bit is clear in it.
Zinin, Roy, Nguyen [Page 2]
INTERNET DRAFT OSPF Restart Signaling February 2001
Two additional fields are introduced in the neighbor data structure:
RestartState flag and ResyncTimeout timer. RestartState flag
indicates that a Hello packet with RS-bit set has been received and
the local router expects its neighbor to go through the LSDB
resynchronization procedure using [OOB]. ResyncTimeout is a single-
shot timer limiting the delay between the first seen Hello packet
with RS-bit set and initialization of the LSDB resynchronization
procedure. The length of ResyncTimeout timer is RouterDeadInterval
seconds.
When a Hello packet with RS-bit set is received and RestartState flag
is not set for the neighbor, the router sets RestartState flag and
starts ResyncTimeout timer. If ResyncTimeout expires, RestartState
flag is cleared and a 1-WayReceived event is generated for the
neighbor. If, while ResyncTimeout timer is running, the neighbor
starts LSDB resynchronization procedure using [OOB], ResyncTimeout
timer is cancelled. The router also clears RestartState flag on
completion of the LSDB resynchronization process.
2.2 Insuring topology stability
Under certain circumstances it might be desirable to stop announcing
the restarting router as fully adjacent if this may lead to possible
routing loops. In order to provide this functionality, a configurable
oprion is provided on the neighboring routers that instructs the OSPF
process to follow the logics described below.
When an OSPF router schedules a routing table calculation due to a
change in the contents of its LSDB, it should also reset all
adjacencies with restarting routers (those with RestartState set to
TRUE) by clearing the RestartState neighbor flags, canceling
ResyncTimeout timers (if running), and generating the 1-WayReceived
events for the neighbor FSMs.
3 Compatibility Issues
The described technique requires cooperation from neighboring
routers. However, if neighbors do not support this technique, they
will just reset the adjacency.
4 Security Considerations
The described technique does not introduce any new security issues
into OSPF protocol.
5 Acknowledgements
The authors would like to thank John Moy, Russ White, Don Slice, and
Zinin, Roy, Nguyen [Page 3]
INTERNET DRAFT OSPF Restart Signaling February 2001
Alvaro Retana for their valuable comments.
6 References
[OSPF]J. Moy. OSPF version 2. Technical Report RFC 2328, Internet
Engineering Task Force, 1998. ftp://ftp.isi.edu/in-
notes/rfc2328.txt.
[LLS] Zinin, Friedman, Roy, Nguyen, Yeung, "OSPF Link-local Signal-
ing", draft-ietf-ospf-lls-00.txt, Work in progress.
[OOB] Zinin, Roy, Nguyen, "OSPF Out-of-band LSDB resynchronization",
draft-ietf-ospf-oob-resync-00.txt, Work in progress.
7 Authors' addresses
Alex Zinin Abhay Roy
Cisco Systems Cisco Systems
150 W. Tasman Dr. 170 W. Tasman Dr.
San Jose,CA 95134 San Jose,CA 95134
USA USA
E-mail: azinin@cisco.com E-mail: akr@cisco.com
Liem Nguyen
7025 Kit Creek Rd.
Research Triangle Park, NC 27709
USA
e-mail: lhnguyen@cisco.com
Zinin, Roy, Nguyen [Page 4]
Html markup produced by rfcmarkup 1.129d, available from
https://tools.ietf.org/tools/rfcmarkup/