[Docs] [txt|pdf] [Tracker] [Email] [Diff1] [Diff2] [Nits] [IPR]

Versions: 00 01 02 03 04 05 06 RFC 4812

Network Working Group                               Alex Zinin (Alcatel)
Internet Draft                                 Abhay Roy (Cisco Systems)
Expiration Date: March 2005                  Liem Nguyen (Cisco Systems)
File name: draft-nguyen-ospf-restart-05.txt


                         OSPF Restart Signaling

                    draft-nguyen-ospf-restart-05.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
and may be updated, replaced, or obsoleted by other documents at any
time.  It is inappropriate to use Internet-Drafts as reference material
or to cite them other than as ``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 describes a vendor
specific mechanism that allows OSPF routers to inform their neighbors
about the restart process.  Note that this mechanism requires support
from neighboring routers.










draft-nguyen-ospf-lls-05.txt                                    [Page 1]

Internet Draft      draft-nguyen-ospf-restart-05.txt      September 2004


1. Motivation

   While performing a graceful restart of OSPF software [OSPF], routers
   need to prevent their neighbors from resetting 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. Restart Signaling 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
   is 0x00000002; see Figure 1 below.


     +---+---+---+---+---+---+---+- -+---+---+---+---+---+---+---+---+
     | * | * | * | * | * | * | * |...| * | * | * | * | * | * | RS| LR|
     +---+---+---+---+---+---+---+- -+---+---+---+---+---+---+---+---+

                  Figure 1. Bits in Extended Options TLV


   For a definition of the LR bit, see [OOB].


2.1. Sending Hello Packets with the RS-bit set

   OSPF routers should set the RS-bit in the EO-TLV attached to a Hello
   packet when it is not known that all neighbors are listed in this
   packet, but the restarting router wants them to preserve their
   adjacencies. The RS-bit must not be set in Hello packets longer than
   RouterDeadInterval seconds.











draft-nguyen-ospf-lls-05.txt                                    [Page 2]

Internet Draft      draft-nguyen-ospf-restart-05.txt      September 2004


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.

   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.

   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.

   Two or more routers on the same segment cannot have Hello packets
   with the RS-bit set at the same time, as can be the case when two or
   more routers restart at about the same time.  In such scenario, the
   routers should clear the RestartState flag, cancel the ResyncTimeout
   timer, and generate a 1-WayReceived event.



2.3. 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
   option is provided on the neighboring routers that instructs the OSPF



draft-nguyen-ospf-lls-05.txt                                    [Page 3]

Internet Draft      draft-nguyen-ospf-restart-05.txt      September 2004


   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 Alvaro Retana for their valuable comments.


6. Intellectual Property Rights Considerations

   The IETF has been notified of intellectual property rights claimed in
   regard to some or all of the specification contained in this
   document.  For more information consult the online list of claimed
   rights.

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights 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; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat 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



draft-nguyen-ospf-lls-05.txt                                    [Page 4]

Internet Draft      draft-nguyen-ospf-restart-05.txt      September 2004


   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at ietf-
   ipr@ietf.org.


7. Normative References

   [OSPF] Moy, J., "OSPF Version 2", RFC 2328, April 1998.

   [LLS]  Zinin, A., Friedman, B., Roy, A., Nguyen, L. and D. Yeung,
          "OSPF Link-local Signaling", Work in progress, September 2004

   [OOB]  Zinin, A., Roy, A. and L. Nguyen,
          "OSPF Out-of-band LSDB resynchronization", Work in progress,
          September 2004



8. Author Information



   Alex Zinin
   Alcatel
   Sunnyvale, CA
   USA
   E-mail: zinin@psg.com

   Abhay Roy
   Cisco Systems
   170 W. Tasman Dr.
   San Jose,CA 95134
   USA
   E-mail: akr@cisco.com

   Liem Nguyen
   7025 Kit Creek Rd.
   Research Triangle Park, NC 27709
   USA
   E-mail: lhnguyen@cisco.com






draft-nguyen-ospf-lls-05.txt                                    [Page 5]


Html markup produced by rfcmarkup 1.107, available from http://tools.ietf.org/tools/rfcmarkup/