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.

 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.

 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.

 Compatibility Issues

   The described technique requires cooperation from neighboring
   routers. However, if neighbors do not support this technique, they
   will just reset the adjacency.

 Security Considerations

   The described technique does not introduce any new security issues
   into OSPF protocol.


 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.

 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.


 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]