Network Working Group Internet-Draft Mitchell Erblich March 2, 2006 Category: Experimental Fast Initial OSPFv2 LSDB Synchronization for BMA draft-erblich-fast-init-lsdb-synch-bma-00.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. Copyright Notice Copyright (C) The Internet Society (2006). All Rights Reserved. ABSTRACT This memo documents a feature that significantly decreases the initial LSDB synchronization time in Broadcast Multiple Access (BMA) environments. This implementation only requires a single OSPF speaker per psuedo-node to support this functionality. These changes are implicitly supported within the OSPFv2 protocol. This memo is not intended to serve as a model for any other implementation. 1. Introduction OSPFv2 BMA environments uses the designated router (DR) to increase the efficiency of LSA exchanges. However, OSPFv2 specifies a RouterDeadInterval second wait time when no DR is known and a interface comes up before a DR is elected. The wait-time is the bottleneck that restricts initial LSDB synchronization. This memo transparently uses a implied functionality within the OSPFv2 specification to remove this constraint. All other routers without modification within the local link must accept this modification. The implied assumption of priority and then router-id for DR and backup DR (BDR) election assumes that priority will be set based on the capability of the router. Then after a given time frame all capable routers will have booted and generated a hello. To support a router's interface entering an existing BMA environment where a DR has already been elected, a received hello specifying that a DR election has already taken place is required to be accepted. 2. Changes to the OSPFv2 Implementation To extend the OSPFv2 specification, upon interface bringup, the interface changes into a passive mode and normally processes input hello packets. It uses these hellos to determine whether a DR has been specified. The passive interface mode has been in other implementations and allows snooping while it prevents us to transmit hellos or any other OSPF control packets. Given hellos that are in the multiple second interval, statistically seeing a hello from an existing router within a few seconds increases dramatically as the number of OSPF speaking routers increase on an interface. If no DR has been seen in the hello field within a configurable wait-time, we then assume that no DR has been elected for this psuedo-node. We can then safely transmit a hello with the seen neighbors and declare ourselves the DR. To allow a deterministic means of selecting routers in this manner, each type of router should have a different configured priority if more than 1 router for a link can declare itself DR. It is also suggested that no wait-time is actually needed when the interface comes up and that re-election will select one of two or more DR declared routers by normal DR election. This secondary functionally allows a OSPF speaking router to take over DR responsibilities. However, depending on the current data flow through that part of the network, local disruptions can occur. Additionally, the DR re-election process will cause additional LSAs to be flooded and SPF computations to occur which will effect routing outside the link area. However, if a router is introduced into a transit network, then a network and router LSAs would be flooded anyway, then possible changed DR-other / DR adjacency reformations becomes a major concern. The changes to minimize these effects are outside the scope of this memo. 3. Security Considerations The function described in this document does not create any new security issues for the OSPF protocol. Security considerations for the base OSPF protocol are covered in [OSPF]. 4. References [OSPF] Moy, J., "OSPF Version 2", RFC 2328, April 1998. 5. Author's Address Mitchell Erblich erblichs@earthlink.net Intellectual Property Statement 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. Disclaimer of Validity 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. 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.