summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc4811.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc4811.txt')
-rw-r--r--doc/rfc/rfc4811.txt563
1 files changed, 563 insertions, 0 deletions
diff --git a/doc/rfc/rfc4811.txt b/doc/rfc/rfc4811.txt
new file mode 100644
index 0000000..014b93a
--- /dev/null
+++ b/doc/rfc/rfc4811.txt
@@ -0,0 +1,563 @@
+
+
+
+
+
+
+Network Working Group L. Nguyen
+Request for Comments: 4811 A. Roy
+Category: Informational Cisco Systems
+ A. Zinin
+ Alcatel-Lucent
+ March 2007
+
+
+ OSPF Out-of-Band Link State Database (LSDB) Resynchronization
+
+Status of This Memo
+
+ This memo provides information for the Internet community. It does
+ not specify an Internet standard of any kind. Distribution of this
+ memo is unlimited.
+
+Copyright Notice
+
+ Copyright (C) The IETF Trust (2007).
+
+Abstract
+
+ OSPF is a link-state intra-domain routing protocol used in IP
+ networks. Link State Database (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. The 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 a
+ form of out-of-band LSDB synchronization. The mechanism described in
+ this document was proposed before Graceful OSPF Restart, as described
+ in RFC 3623, 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. Informational [Page 1]
+
+RFC 4811 OSPF Out-of-Band LSDB Resynchronization March 2007
+
+
+Table of Contents
+
+ 1. Introduction ....................................................2
+ 2. Proposed Solution ...............................................2
+ 2.1. The LR-Bit .................................................3
+ 2.2. OSPF Neighbor Data Structure ...............................3
+ 2.3. Hello Packets ..............................................4
+ 2.4. DBD Packets ................................................4
+ 2.5. Neighbor State Treatment ...................................7
+ 2.6. Initiating OOB LSDB Resynchronization ......................7
+ 3. Backward Compatibility ..........................................7
+ 4. Security Considerations .........................................7
+ 5. IANA Considerations .............................................7
+ 6. References ......................................................8
+ 6.1. Normative References .......................................8
+ 6.2. Informative References .....................................8
+ Appendix A. Acknowledgements ......................................9
+
+1. Introduction
+
+ According to the OSPF standard [RFC2328], after two OSPF routers have
+ established an adjacency (the neighbor Finite State Machines (FSMs)
+ have reached Full state), routers announce the adjacency states in
+ their router-Link State Advertisements (LSAs). Asynchronous flooding
+ algorithm ensures that 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 up the adjacencies
+ 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
+
+ With this Out-of-Band Resynchronization Solution, the format of the
+ OSPF Database Description (DBD) 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.
+
+
+
+
+
+Nguyen, et al. Informational [Page 2]
+
+RFC 4811 OSPF Out-of-Band LSDB Resynchronization March 2007
+
+
+ Also, two new fields are added to the neighbor data structure. The
+ first field indicates a 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 (EO) TLV (see [RFC4813]).
+ 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 [RFC4813]). The
+ value of the bit is 0x00000001; see Figure 1. See the "IANA
+ Considerations" section of [RFC4813] for more information on the
+ Extended Options bit definitions. Routers set the 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.
+
+ The OOBResync flag is set when the router is initiating OOB LSDB
+ resynchronization (see Section 2.6 for more details).
+
+ Routers clear the 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 the ExStart state because a DBD
+ packet with the R-bit clear has been received.
+
+
+
+Nguyen, et al. Informational [Page 3]
+
+RFC 4811 OSPF Out-of-Band LSDB Resynchronization March 2007
+
+
+ o The neighbor FSM reaches the state Full.
+
+ Note that the OOBResync flag may have a 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 the 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 the OOB LSDB resynchronization procedure. Figure 2
+ illustrates the new packet format.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Nguyen, et al. Informational [Page 4]
+
+RFC 4811 OSPF Out-of-Band LSDB Resynchronization March 2007
+
+
+ 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 the R-
+ bit clear is received for a neighbor with active OOBResync flag, the
+ OOB LSDB resynchronization process is canceled and normal LSDB
+ synchronization procedure is initiated.
+
+ When a DBD packet is received with the 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.
+
+
+
+
+
+
+
+
+
+Nguyen, et al. Informational [Page 5]
+
+RFC 4811 OSPF Out-of-Band LSDB Resynchronization March 2007
+
+
+ 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 the received DBD
+ packet does not have the R-bit set, ignore the packet and
+ generate a SeqNumberMismatch event for the neighbor FSM.
+
+ 2. Otherwise, if the OOBResync flag for the neighbor is clear and
+ the 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
+ processing 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
+ Master, 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.
+
+
+
+
+
+
+
+
+
+
+
+Nguyen, et al. Informational [Page 6]
+
+RFC 4811 OSPF Out-of-Band LSDB Resynchronization March 2007
+
+
+2.5. Neighbor State Treatment
+
+ An 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 the
+ 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,
+ provided that OOBResync flag is set for the neighbor. (Flooding
+ and MaxAge-LSA-specific procedures should not check the state of
+ the 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 the Options field of the neighbor data
+ structure). 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. Backward Compatibility
+
+ Because OOB-capable routers explicitly indicate their capability by
+ setting the corresponding bit in the Options field, no DBD packets
+ with the 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.
+
+4. Security Considerations
+
+ The described technique does not introduce any new security issues
+ into the OSPF protocol.
+
+5. IANA Considerations
+
+ Please refer to the "IANA Considerations" section of [RFC4813] for
+ more information on the Extended Options bit definitions.
+
+
+
+
+
+
+Nguyen, et al. Informational [Page 7]
+
+RFC 4811 OSPF Out-of-Band LSDB Resynchronization March 2007
+
+
+6. References
+
+6.1. Normative References
+
+ [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998.
+
+ [RFC3623] Moy, J., Pillay-Esnault, P., and A. Lindem, "Graceful OSPF
+ Restart", RFC 3623, November 2003.
+
+6.2. Informative References
+
+ [RFC4813] Friedman, B., Nguyen, L., Roy, A., Yeung, D., and A.
+ Zinin, "OSPF Link-Local Signaling", RFC 4813, March 2007.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Nguyen, et al. Informational [Page 8]
+
+RFC 4811 OSPF Out-of-Band LSDB Resynchronization March 2007
+
+
+Appendix A. Acknowledgments
+
+ The authors would like to thank Acee Lindem, Russ White, Don Slice,
+ and Alvaro Retana for their valuable comments.
+
+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-Lucent
+ Mountain View, CA
+ USA
+ EMail: alex.zinin@alcatel-lucent.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Nguyen, et al. Informational [Page 9]
+
+RFC 4811 OSPF Out-of-Band LSDB Resynchronization March 2007
+
+
+Full Copyright Statement
+
+ Copyright (C) The IETF Trust (2007).
+
+ 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, THE IETF TRUST 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.
+
+Acknowledgement
+
+ Funding for the RFC Editor function is currently provided by the
+ Internet Society.
+
+
+
+
+
+
+
+Nguyen, et al. Informational [Page 10]
+