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.