[Search] [txt|pdfized|bibtex] [Tracker] [WG] [Email] [Nits]
Versions: 00 01                                                         
Network Working Group                                         Alex Zinin
Internet Draft                                                 Abhay Roy
Expiration Date: July 2001                                   Liem Nguyen
File name: draft-ietf-ospf-restart-00.txt                  Cisco Systems
                                                           November 2000

                         OSPF Restart Signaling

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

   The list of Internet-Draft Shadow Directories can be accessed at

   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            November 2000

   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

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| OR|
     +---+---+---+---+---+---+---+- -+---+---+---+---+---+---+---+---+

                  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 OR bit, see [OOB].

2.2 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.

   It is also recommended that a unicast Hello is sent 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            November 2000

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 Russ White, Don Slice, and 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-

   [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
        e-mail: lhnguyen@cisco.com

Zinin, Roy, Nguyen                                              [Page 3]