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-oob-resync-05.txt OSPF Out-of-band LSDB resynchronization draft-nguyen-ospf-oob-resync-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. 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. draft-nguyen-ospf-lls-05.txt [Page 1] Internet Draft draft-nguyen-ospf-oob-resync-05.txt September 2004 1. Motivation 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. 2. 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 TBD (0x00000001 is the temporarily used value, 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. draft-nguyen-ospf-lls-05.txt [Page 2] Internet Draft draft-nguyen-ospf-oob-resync-05.txt September 2004 +---+---+---+---+---+---+---+- -+---+---+---+---+---+---+---+---+ | * | * | * | * | * | * | * |...| * | * | * | * | * | * | * | 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). 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. draft-nguyen-ospf-lls-05.txt [Page 3] Internet Draft draft-nguyen-ospf-oob-resync-05.txt September 2004 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. 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 -+ | | +- -+ | | +- -+ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... | draft-nguyen-ospf-lls-05.txt [Page 4] Internet Draft draft-nguyen-ospf-oob-resync-05.txt September 2004 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. 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: o 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]. o 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 draft-nguyen-ospf-lls-05.txt [Page 5] Internet Draft draft-nguyen-ospf-oob-resync-05.txt September 2004 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. 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. 3. Compatibility Issues 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. draft-nguyen-ospf-lls-05.txt [Page 6] Internet Draft draft-nguyen-ospf-oob-resync-05.txt September 2004 4. Security Considerations The described technique does not introduce any new security issues into OSPF protocol. 5. Acknowledgements The authors would like to thank Acee Lindem, 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 docu- ment. 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 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. draft-nguyen-ospf-lls-05.txt [Page 7] Internet Draft draft-nguyen-ospf-oob-resync-05.txt September 2004 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 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 8]