draft-ietf-ospf-restart-00.txt   draft-ietf-ospf-restart-01.txt 
Network Working Group Alex Zinin Network Working Group Alex Zinin
Internet Draft Abhay Roy Internet Draft Abhay Roy
Expiration Date: July 2001 Liem Nguyen Expiration Date: September 2001 Liem Nguyen
File name: draft-ietf-ospf-restart-00.txt Cisco Systems File name: draft-ietf-ospf-restart-01.txt Cisco Systems
November 2000 February 2001
OSPF Restart Signaling OSPF Restart Signaling
draft-ietf-ospf-restart-00.txt draft-ietf-ospf-restart-01.txt
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026. all provisions of Section 10 of RFC2026.
Internet Drafts are working documents of the Internet Engineering Internet Drafts are working documents of the Internet Engineering
Task Force (IETF), its Areas, and its Working Groups. Note that other Task Force (IETF), its Areas, and its Working Groups. Note that other
groups may also distribute working documents as Internet Drafts. groups may also distribute working documents as Internet Drafts.
skipping to change at page 2, line 24 skipping to change at page 2, line 24
yet and the absence of some router-IDs in the Hello packets should be yet and the absence of some router-IDs in the Hello packets should be
ignored. ignored.
2 Proposed solution 2 Proposed solution
A new bit, called RS (restart signal) is introduced into Extended 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 Options TLV in the LLS block (see [LLS]). The value of this bit is
TBD (temporarily used value is 0x00000002, see Figure 1 below). TBD (temporarily used value is 0x00000002, see Figure 1 below).
+---+---+---+---+---+---+---+- -+---+---+---+---+---+---+---+---+ +---+---+---+---+---+---+---+- -+---+---+---+---+---+---+---+---+
| * | * | * | * | * | * | * |...| * | * | * | * | * | * | RS| OR| | * | * | * | * | * | * | * |...| * | * | * | * | * | * | RS| LR|
+---+---+---+---+---+---+---+- -+---+---+---+---+---+---+---+---+ +---+---+---+---+---+---+---+- -+---+---+---+---+---+---+---+---+
Figure 1. Bits in Extended Options TLV Figure 1. Bits in Extended Options TLV
OSPF routers should set the RS-bit in the EO-TLV attached to a Hello 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 when this is not clear that all neighbors are listed in this
packet, but the restarting router wants them to preserve their packet, but the restarting router wants them to preserve their
adjacencies. The RS-bit may not be set in Hello packets longer than adjacencies. The RS-bit may not be set in Hello packets longer than
RouterDeadInterval seconds. RouterDeadInterval seconds.
For a definition of the OR bit, see [OOB]. For a definition of the LR bit, see [OOB].
2.2 Receiving Hello Packets with RS-bit set 2.1 Receiving Hello Packets with RS-bit set
When an OSPF router receives a Hello packet, containing the LLS block 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 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 two-way connectivity check with the announcing neighbor (i.e., the
router should not generate a 1-WayReceived event for the neighbor if 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 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 described in 10.5 of [OSPF]), provided that the neighbor FSM for this
neighbor is in the Full state. neighbor is in the Full state.
It is also recommended that a unicast Hello is sent back to the The router should also send a unicast Hello back to the sender in
sender in reply to a Hello packet with RS bit set. This is to speed reply to a Hello packet with RS bit set. This is to speed up
up learning of previously known neighbors. When sending such a reply 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. packet, care must be taken to ensure that the RS bit is clear in it.
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 3 Compatibility Issues
The described technique requires cooperation from neighboring The described technique requires cooperation from neighboring
routers. However, if neighbors do not support this technique, they routers. However, if neighbors do not support this technique, they
will just reset the adjacency. will just reset the adjacency.
4 Security Considerations 4 Security Considerations
The described technique does not introduce any new security issues The described technique does not introduce any new security issues
into OSPF protocol. into OSPF protocol.
5 Acknowledgements 5 Acknowledgements
The authors would like to thank Russ White, Don Slice, and Alvaro The authors would like to thank John Moy, Russ White, Don Slice, and
Retana for their valuable comments. Alvaro Retana for their valuable comments.
6 References 6 References
[OSPF]J. Moy. OSPF version 2. Technical Report RFC 2328, Internet [OSPF]J. Moy. OSPF version 2. Technical Report RFC 2328, Internet
Engineering Task Force, 1998. ftp://ftp.isi.edu/in- Engineering Task Force, 1998. ftp://ftp.isi.edu/in-
notes/rfc2328.txt. notes/rfc2328.txt.
[LLS] Zinin, Friedman, Roy, Nguyen, Yeung, "OSPF Link-local Signal- [LLS] Zinin, Friedman, Roy, Nguyen, Yeung, "OSPF Link-local Signal-
ing", draft-ietf-ospf-lls-00.txt, Work in progress. ing", draft-ietf-ospf-lls-00.txt, Work in progress.
 End of changes. 

This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/