OSPF Restart Signaling
draft-nguyen-ospf-restart-06

Network Working Group                                          L. Nguyen
Internet-Draft                                                    A. Roy
Intended status: Informational                             Cisco Systems
Expires: April 29, 2007                                         A. Zinin
                                                                 Alcatel
                                                        October 26, 2006

                         OSPF Restart Signaling
                    draft-nguyen-ospf-restart-06.txt

Status of this Memo

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, in accordance with Section 6 of BCP 79.

   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.

   This Internet-Draft will expire on April 29, 2007.

Copyright Notice

   Copyright (C) The Internet Society (2006).

Nguyen, et al.           Expires April 29, 2007                 [Page 1]
Internet-Draft           OSPF Restart Signaling             October 2006

Abstract

   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.  The
   mechanism described in this document was proposed before Graceful
   OSPF Restart [RFC3623] came into existence.  It is implemented/
   supported by at least one major vendor and is currently deployed in
   the field.  The purpose of this document is to capture the details of
   this mechanism for public use.  This mechanism is not an IETF
   standard.

Nguyen, et al.           Expires April 29, 2007                 [Page 2]
Internet-Draft           OSPF Restart Signaling             October 2006

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
     1.1.  Requirements notation  . . . . . . . . . . . . . . . . . .  4
   2.  Proposed Solution  . . . . . . . . . . . . . . . . . . . . . .  5
     2.1.  Sending Hello Packets with the RS-bit set  . . . . . . . .  5
     2.2.  Receiving Hello Packets with RS-bit set  . . . . . . . . .  5
     2.3.  Insuring topology stability  . . . . . . . . . . . . . . .  6
   3.  Backward Compatibility . . . . . . . . . . . . . . . . . . . .  7
   4.  Security Considerations  . . . . . . . . . . . . . . . . . . .  8
   5.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . .  9
   6.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 10
     6.1.  Normative References . . . . . . . . . . . . . . . . . . . 10
     6.2.  Informative References . . . . . . . . . . . . . . . . . . 10
   Appendix A.  Acknowledgments . . . . . . . . . . . . . . . . . . . 11
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12
   Intellectual Property and Copyright Statements . . . . . . . . . . 13

Nguyen, et al.           Expires April 29, 2007                 [Page 3]
Internet-Draft           OSPF Restart Signaling             October 2006

1.  Introduction

   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.

1.1.  Requirements notation

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC2119 [RFC2119].

Nguyen, et al.           Expires April 29, 2007                 [Page 4]
Internet-Draft           OSPF Restart Signaling             October 2006

2.  Proposed Solution

   With this 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 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.

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 [RFC2328]), 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.

Nguyen, et al.           Expires April 29, 2007                 [Page 5]
Internet-Draft           OSPF Restart Signaling             October 2006

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

Nguyen, et al.           Expires April 29, 2007                 [Page 6]
Internet-Draft           OSPF Restart Signaling             October 2006

3.  Backward Compatibility

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

Nguyen, et al.           Expires April 29, 2007                 [Page 7]
Internet-Draft           OSPF Restart Signaling             October 2006

4.  Security Considerations

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

Nguyen, et al.           Expires April 29, 2007                 [Page 8]
Internet-Draft           OSPF Restart Signaling             October 2006

5.  IANA Considerations

   Please refer to the "IANA Considerations" section of [LLS] for more
   information on the Extended Options bit definitions.

Nguyen, et al.           Expires April 29, 2007                 [Page 9]
Internet-Draft           OSPF Restart Signaling             October 2006

6.  References

6.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFC's to Indicate
              Requirement Levels", RFC 2119, March 1997.

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

   [RFC3623]  Moy, J., Pillay-Esnault, P., and A. Lindem, "Graceful OSPF
              Restart", RFC 3623, November 2003.

6.2.  Informative References

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

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

Nguyen, et al.           Expires April 29, 2007                [Page 10]
Internet-Draft           OSPF Restart Signaling             October 2006

Appendix A.  Acknowledgments

   The authors would like to thank John Moy, Russ White, Don Slice, and
   Alvaro Retana for their valuable comments.

Nguyen, et al.           Expires April 29, 2007                [Page 11]
Internet-Draft           OSPF Restart Signaling             October 2006

Authors' Addresses

   Liem Nguyen
   Cisco Systems
   225 West Tasman Drive
   San Jose, CA  95134
   USA

   Email: lhnguyen@cisco.com

   Abhay Roy
   Cisco Systems
   225 West Tasman Drive
   San Jose, CA  95134
   USA

   Email: akr@cisco.com

   Alex Zinin
   Alcatel
   Sunnyvale, CA
   USA

   Email: zinin@psg.com

Nguyen, et al.           Expires April 29, 2007                [Page 12]
Internet-Draft           OSPF Restart Signaling             October 2006

Full Copyright Statement

   Copyright (C) The Internet Society (2006).

   This document is subject to the rights, licenses and restrictions
   contained in BCP 78, and except as set forth therein, the authors
   retain all their rights.

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Intellectual Property

   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 implementers or users of this
   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.

Acknowledgment

   Funding for the RFC Editor function is provided by the IETF
   Administrative Support Activity (IASA).

Nguyen, et al.           Expires April 29, 2007                [Page 13]