OSPF Out-of-Band Link State Database (LSDB) Resynchronization
draft-nguyen-ospf-oob-resync-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 Out-of-band LSDB resynchronization
                  draft-nguyen-ospf-oob-resync-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 Out-of-band LSDB resynchronization    October 2006

Abstract

   OSPF is a link-state intra-domain routing protocol used in IP
   networks.  LSDB synchronization in OSPF is achieved via two methods--
   initial LSDB synchronization when an OSPF router has just been
   connected to the network and asynchronous flooding that ensures
   continuous LSDB synchronization in the presence of topology changes
   after the initial procedure was completed.  It may sometime be
   necessary for OSPF routers to resynchronize their LSDBs.  OSPF
   standard, however, does not allow routers to do so without actually
   changing the topology view of the network.

   This memo describes a vendor specific mechanism to perform such form
   of out-of-band LSDB synchronization.  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 Out-of-band LSDB resynchronization    October 2006

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
     1.1.  Requirements notation  . . . . . . . . . . . . . . . . . .  4
   2.  Proposed Solution  . . . . . . . . . . . . . . . . . . . . . .  5
     2.1.  The LR bit . . . . . . . . . . . . . . . . . . . . . . . .  5
     2.2.  OSPF Neighbor Data Structure . . . . . . . . . . . . . . .  5
     2.3.  Hello Packets  . . . . . . . . . . . . . . . . . . . . . .  6
     2.4.  DBD Packets  . . . . . . . . . . . . . . . . . . . . . . .  6
     2.5.  Neighbor State Treatment . . . . . . . . . . . . . . . . .  8
     2.6.  Initiating OOB LSDB Resynchronization  . . . . . . . . . .  9
   3.  Backward Compatibility . . . . . . . . . . . . . . . . . . . . 10
   4.  Security Considerations  . . . . . . . . . . . . . . . . . . . 11
   5.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 12
   6.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 13
     6.1.  Normative References . . . . . . . . . . . . . . . . . . . 13
     6.2.  Informative References . . . . . . . . . . . . . . . . . . 13
   Appendix A.  Acknowledgments . . . . . . . . . . . . . . . . . . . 14
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15
   Intellectual Property and Copyright Statements . . . . . . . . . . 16

Nguyen, et al.           Expires April 29, 2007                 [Page 3]
Internet-Draft   OSPF Out-of-band LSDB resynchronization    October 2006

1.  Introduction

   According to the OSPF standard [RFC2328], after two OSPF routers have
   established an adjacency (the neighbor FSMs have reached Full state),
   routers announce the adjacency states in their router-LSAs.
   Asynchronous flooding algorithm ensures routers' LSDBs stay in sync
   in the presence of topology changes.  However, if routers need (for
   some reason) to resynchronize their LSDBs, they cannot do that
   without actually putting the neighbor FSMs into the ExStart state.
   This effectively causes the adjacencies to be removed from the
   router-LSAs, which may not be acceptable if the desire is to prevent
   routing table flaps during database resynchronization.  In this
   document, we provide the means for so-called out-of-band (OOB) LSDB
   resynchronization.

   The described mechanism can be used in a number of situations
   including those where the routers are picking the adjacencies up
   after a reload.  The process of adjacency preemption is outside the
   scope of this document.  Only the details related to LSDB
   resynchronization are mentioned herein.

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 Out-of-band LSDB resynchronization    October 2006

2.  Proposed Solution

   With this Out-Of-Band Resynchronization Solution, the format of the
   OSPF Database Description packet is changed to include a new R-bit
   indicating OOB LSDB resynchronization.  All DBD packets sent during
   the OOB resynchronization procedure are sent with the R-bit set.

   Also, two new fields are added to the neighbor data structure.  The
   first field indicates neighbor's OOB resynchronization capability.
   The second indicates that OOB LSDB resynchronization is in process.
   The latter field allows OSPF implementations to utilize the existing
   neighbor FSM code.

   A bit is occupied in the Extended Options TLV (see [LLS]).  Routers
   set this bit to indicate their capability to support the described
   technique.

2.1.  The LR bit

   A new bit, called LR (LR stands for LSDB Resynchronization) is
   introduced to the LLS Extended Options TLV (see [LLS]).  The value of
   the bit is 0x00000001; see Figure 1.  See the "IANA Considerations"
   section of [LLS] for more information on the Extended Options bit
   definitions.  Routers set LR bit to announce OOB LSDB
   resynchronization capability.

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

                        Figure 1. The Options field

   Routers supporting the OOB LSDB resynchronization technique set the
   LR bit in the EO-TLV in the LLS block attached to both Hello and DBD
   packets.  Note that no bit is set in the standard OSPF Options field,
   neither in OSPF packets, nor in LSAs.

2.2.  OSPF Neighbor Data Structure

   A field is introduced into OSPF neighbor data structure, as described
   below.  The name of the field is OOBResync and it is a flag
   indicating that the router is currently performing OOB LSDB
   resynchronization with the neighbor.

   OOBResync flag is set when the router is initiating the OOB LSDB
   resynchronization (see Section 2.6 for more details).

Nguyen, et al.           Expires April 29, 2007                 [Page 5]
Internet-Draft   OSPF Out-of-band LSDB resynchronization    October 2006

   Routers clear OOBResync flag on the following conditions:

   o  The neighbor data structure is first created

   o  The neighbor FSM transitions to any state lower than ExStart

   o  The neighbor FSM transitions to ExStart state because a DBD packet
      with R-bit clear has been received

   o  The neighbor FSM reaches state Full.

   Note that OOBResync flag may have TRUE value only if the neighbor FSM
   is in states ExStart, Exchange, or Loading.  As indicated above, if
   the FSM transitions to any other state, the OOBResync flag should be
   cleared.

   It is important to mention that operation of OSPF neighbor FSM is not
   changed by this document.  However, depending on the state of the
   OOBResync flag, the router sends either normal DBD packets or DBD
   packets with the R-bit set.

2.3.  Hello Packets

   Routers capable of performing OOB LSDB resynchronization should
   always set the LR bit in their Hello packets.

2.4.  DBD Packets

   Routers supporting the described technique should always set the LR
   bit in the DBD packets.  Since the Options field of the initial DBD
   packet is stored in corresponding neighbor data structure, the LR bit
   may be used later to check if a neighbor is capable of performing OOB
   LSDB resynchronization.

   The format of type-2 (DBD) OSPF packets is changed to include a flag
   indicating OOB LSDB resynchronization procedure.  Figure 2
   illustrates the new packet format.

Nguyen, et al.           Expires April 29, 2007                 [Page 6]
Internet-Draft   OSPF Out-of-band LSDB resynchronization    October 2006

        0                   1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |   Version #   |       2       |         Packet length         |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                          Router ID                            |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                           Area ID                             |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |           Checksum            |             AuType            |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                       Authentication                          |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                       Authentication                          |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |         Interface MTU         |    Options    |0|0|0|0|R|I|M|MS
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                     DD sequence number                        |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                                                               |
       +-                                                             -+
       |                                                               |
       +-                      An LSA Header                          -+
       |                                                               |
       +-                                                             -+
       |                                                               |
       +-                                                             -+
       |                                                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                              ...                              |

                       Figure 2. Modified DBD packet

   The R-bit in OSPF type-2 packets is set when the OOBResync flag for
   the specific neighbor is set to TRUE.  If a DBD packets with R-bit
   clear is received for a neighbor with active OOBResync flag, the OOB
   LSDB resynchronization process is cancelled and normal LSDB
   synchronization procedure is initiated.

   When a DBD packet is received with R-bit set and the sender is known
   to be OOB-incapable, the packet should be dropped and a SeqNumber-
   Mismatch event should be generated for the neighbor.

   Processing of DBD packets is modified as follows.

Nguyen, et al.           Expires April 29, 2007                 [Page 7]
Internet-Draft   OSPF Out-of-band LSDB resynchronization    October 2006

   1.  If the OOBResync flag for the neighbor is set (the LSDB
       resynchronization process has been started) and received DBD
       packet does not have the R bit set, ignore the packet and gen-
       erate a SeqNumberMismatch event for the neighbor FSM.

   2.  Otherwise, if OOBResync flag for the neighbor is clear and
       received DBD packet has the R bit set, perform the following
       steps:

       *  If the neighbor FSM is in state Full and bits I, M, and MS are
          set in the DBD packet, set the OOBResync flag for the
          neighbor, put the FSM in ExStart state and continue process-
          ing the DBD packet as described in [RFC2328].

       *  Otherwise, ignore received DBD packet (no OOB DBD packets are
          allowed with OOBResync flag clear and FSM in state other than
          Full.)  Also, if the state of the FSM is Exchange or higher,
          generate a SeqNumberMismatch event for the neighbor FSM.

   3.  Otherwise, process the DBD packet as described in [RFC2328].

   During normal processing of the initial OOB DBD packet (with bits R,
   I, M, and MS set), if the receiving router is selected to be the Mas-
   ter, it may speed up the resynchronization process by immediately
   replying to the received packet.

   It is also necessary to limit the time an adjacency can spend in
   ExStart, Exchange, and Loading states with OOBResync flag set to a
   finite period of time (e.g., by limiting the number of times DBD and
   link state request packets can be retransmitted).  If the adjacency
   does not proceed to Full state before the timeout, it is indicative
   that the neighboring router cannot resynchronize its LSDB with the
   local router.  The requesting router may decide to stop trying to
   resynchronize the LSDB over this adjacency (if, for example, it can
   be resynchronized via another neighbor on the same segment) or to
   resynchronize using the legacy method by clearing the OOBResync flag
   and leaving the FSM in ExStart state.  The neighboring router may
   decide to cancel the OOB procedure for the neighbor.

2.5.  Neighbor State Treatment

   OSPF implementation supporting the described technique should modify
   the logic consulting the state of a neighbor FSM as described below.

   o  FSM state transitioning from and to the Full state with OOBResync
      flag set should not cause origination of a new version of router-
      LSA or network-LSA.

Nguyen, et al.           Expires April 29, 2007                 [Page 8]
Internet-Draft   OSPF Out-of-band LSDB resynchronization    October 2006

   o  Any explicit checks for the Full state of a neighbor FSM for the
      purposes other than LSDB synchronization and flooding should treat
      states ExStart, Exchange, and Loading as state Full, pro- vided
      that OOBResync flag is set for the neighbor.  (Flooding and
      MaxAge-LSA-specific procedures should not check the state of
      OOBResync flag, but should continue consulting only the FSM
      state.)

2.6.  Initiating OOB LSDB Resynchronization

   To initiate out-of-band LSDB resynchronization, the router must first
   make sure that the corresponding neighbor supports this technology
   (by checking the LR bit in Options field of the neighbor data struc-
   ture).  If the neighboring router is capable, the OOBResync flag for
   the neighbor should be set to TRUE and the FSM state should be forced
   to ExStart.

Nguyen, et al.           Expires April 29, 2007                 [Page 9]
Internet-Draft   OSPF Out-of-band LSDB resynchronization    October 2006

3.  Backward Compatibility

   Because OOB-capable routers explicitly indicate their capability by
   setting the corresponding bit in the Options field, no DBD packets
   with R-bit set are sent to OOB-incapable routers.

   The LR bit itself is transparent for OSPF implementations and does
   not affect communication between routers.

Nguyen, et al.           Expires April 29, 2007                [Page 10]
Internet-Draft   OSPF Out-of-band LSDB resynchronization    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 11]
Internet-Draft   OSPF Out-of-band LSDB resynchronization    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 12]
Internet-Draft   OSPF Out-of-band LSDB resynchronization    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.

Nguyen, et al.           Expires April 29, 2007                [Page 13]
Internet-Draft   OSPF Out-of-band LSDB resynchronization    October 2006

Appendix A.  Acknowledgments

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

Nguyen, et al.           Expires April 29, 2007                [Page 14]
Internet-Draft   OSPF Out-of-band LSDB resynchronization    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 15]
Internet-Draft   OSPF Out-of-band LSDB resynchronization    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 16]