Network Working Group Alex Zinin Internet Draft Abhay Roy Expiration Date: July 2001 Liem Nguyen File name: draft-ietf-ospf-oob-resync-00.txt Cisco Systems November 2000 OSPF Out-of-band LSDB resynchronization draft-ietf-ospf-oob-resync-00.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. 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 mechanism to perform such form of out-of-band LSDB synchronization. 1 Motivation Zinin, Roy, Nguyen [Page 1]
INTERNET DRAFT OSPF OOB LSDB Resync November 2000 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 in some cases. 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. 2 Proposed solution A new OSPF packet type (type 6) is introduced. The function of the packet is identical to that of OSPF DBD packet, except that it is specifically dedicated for OOB LSDB resynchronization. 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 OR bit A new bit, called OR (OR stands for Out-of-band Resynchronization) is introduced to the LLS Extended Options TLV (see [LLS]). The value of the bit is TBD (0x00000001 is the temporarily used value, see Figure 1). Routers set OR bit to announce OOB LSDB resynchronization capability. +---+---+---+---+---+---+---+- -+---+---+---+---+---+---+---+---+ | * | * | * | * | * | * | * |...| * | * | * | * | * | * | * | OR| +---+---+---+---+---+---+---+- -+---+---+---+---+---+---+---+---+ Figure 1. The Options field Zinin, Roy, Nguyen [Page 2]
INTERNET DRAFT OSPF OOB LSDB Resync November 2000 Routers supporting the OOB LSDB resynchronization technique set the OR bit in the EO-TLV in the LLS block attached to Hello and DBD packets. Note that no bit is set in the 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.7 for more details). 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 reaches state Full Note that OOBResync flag may be set to TRUE 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 legacy (type-2), or OOB (type-6) DBD packets. 2.3 Hello Packets Routers capable of performing OOB LSDB resynchronization should always set the OR bit in their Hello packets. 2.4 Type-2 DBD Packets Routers supporting the described technique should always set the OR bit in the DBD packets. Since the Options field of the initial DBD packet is stored in corresponding neighbor data structure, the OR bit may be used later to check if a neighbor is capable of performing OOB LSB resynchronization. 2.5 Type-6 DBD Packets Zinin, Roy, Nguyen [Page 3]
INTERNET DRAFT OSPF OOB LSDB Resync November 2000 The format of type-6 DBD packets is identical to the format of type-2 DBD packets, except that the type field is set to value of 6. Type-6 packets are sent instead of type-2 packets when the OOBResync flag for the specific neighbor is set to TRUE. Type-2 packets are considered to be invalid if OOBResync flag is set for the neighbor. When a type-6 DBD packet is received and stored value of the Options field for that neighbor does have OR bit set, the packet should be dropped and a SeqNumberMismatch event should be generated for the neighbor. Note also, that When a type 2 or type 6 OSPF packet is received and saved for later detection of a duplicate packet, the packet type should be stored as well. Processing of type-6 DBD packets is performed as follows. o If bits I, M, and MS are set and the state of the neighbor FSM is Full and OOBResync flag is not set, the packet is accepted, the OOBResync flag is set and the FSM is put into ExStart state. o Otherwise, if OOBResync flag is set and the state of the neigh- bor FSM is ExStart, Exchange, or Loading, the packet is pro- cessed just like a type 2 packet. o Otherwise, if neighbor state is Full and the receiving router was the Slave in the LSDB exchange process, it must be ready to identify duplicate DDs of both packet types (type 2 and type 6) from the master and resend the acknowledging packet. o Otherwise (the OOBResync flag is off, or the state is not Full, or the packet is not a duplicate), a SeqNumberMismatch is gen- erated for the neighbor FSM that causes transition to state ExStart. It is also necessary to limit the time an adjacency can spend in ExStart state with OOBResync flag set to RouterDeadInterval seconds. If the adjacency does not go out of this state before the timer fires, the neighboring router does not process type-6 packets prop- erly. The requesting router may decide to stop trying to resynchron- ize the LSDB over this adjacency (if, for example, it can be resyn- chronized via another neighbor on the same segment) or to resynchron- ize using the legacy method by clearing the OOBResync flag and leav- ing the FSM in ExStart state. Zinin, Roy, Nguyen [Page 4]
INTERNET DRAFT OSPF OOB LSDB Resync November 2000 2.6 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. 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.7 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 OR 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. 3 Compatibility Issues Because OOB-capable routers explicitly indicate their capability by setting the corresponding bit in the Options field, no packets of the new type are sent to OOB-incapable routers. The OR bit itself is transparent for OSPF routers and does not affect communication between routers. 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 Zinin, Roy, Nguyen [Page 5]
INTERNET DRAFT OSPF OOB LSDB Resync November 2000 [RFC2328] 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 Signaling", draft-ietf-ospf-lls-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 USA e-mail: lhnguyen@cisco.com Zinin, Roy, Nguyen [Page 6]
