Section 6.4, above, may be subtracted from the results of this test
to provide just the convergence time across a broadcast network.
Note that although all the other tests in this document include route
calculation time in the convergence time, as described in [TERM],
this test may not include route calculation time in the resulting
measured convergence time, because initial route calculation may
occur after the first network LSA is flooded.
6.6. Initial Convergence Time on a Broadcast Network, Test 2
o Using reference topology 3 (Broadcast Network), begin with the DUT
connected to the network with OSPF enabled. OSPF should be
enabled on R1, but the broadcast link should be disabled.
o Enable the broadcast link between R1 and the DUT. Note the time
of the first hello transmitted by the DUT with a designated router
listed.
o Note the time when the first network LSA is flooded by the DUT at
R1.
o The time difference between the first hello with a designated
router lists and the first network LSA is the period required by
the DUT to converge on this new topology.
6.7. Link Down with Layer 2 Detection
o Using reference topology 4 (Parallel Links), begin with OSPF in
the Full state between the generator and the DUT. Both links
should be point-to-point links with the ability to notify the
operating system immediately upon link failure.
o Disable link 1; this should be done in such a way that the
keepalive timers at the data link layer will have no impact on the
DUT recognizing the link failure (the operating system in the DUT
should recognize this link failure immediately). Disconnecting
the cable on the generator end would be one possibility; shutting
the link down would be another.
o Note the time of the link failure on the generator.
o At the generator, note the time of the receipt of the new router
LSA from the DUT notifying the generator of the link 2 failure.
The difference in the time between the initial link failure and
the receipt of the LSA on the generator across link 2 should be
taken as the time required for an OSPF implementation to recognize
and process a link failure, including the time required to
generate and flood an LSA describing the link down event to an
adjacent neighbor.
6.8. Link Down with Layer 3 Detection
o Using reference topology 4 (Parallel Links), begin with OSPF in
the Full state between the generator and the DUT.
o Disable OSPF processing on link 1 from the generator. This should
be done in such a way that it does not affect link status; the DUT
MUST note the failure of the adjacency through the dead interval.
o At the generator, note the time of the receipt of the new router
LSA from the DUT notifying the generator of the link 2 failure.
The difference in the time between the initial link failure and the
receipt of the LSA on the generator across link 2 should be taken as
the time required for an OSPF implementation to recognize and process
an adjacency failure.
7. Security Considerations
This document does not modify the underlying security considerations
in [OSPF].
8. Acknowledgements
Thanks to Howard Berkowitz (hcb@clark.net) for his encouragement and
support. Thanks also to Alex Zinin (zinin@psg.net), Gurpreet Singh
(Gurpreet.Singh@SpirentCom.com), and Yasuhiro Ohara
(yasu@sfc.wide.ad.jp) for their comments.
9. Normative References
[OSPF] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April
1998.
[TERM] Manral, V., White, R., and A. Shaikh, "OSPF
Benchmarking Terminology and Concepts", RFC 4062,
April 2005.
[CONSIDERATIONS] Manral, V., White, R., and A. Shaikh,
"Considerations When Using Basic OSPF Convergence
Benchmarks", RFC 4063, April 2005.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
10. Informative References
[INTERCONNECT] Bradner, S. and J. McQuaid, "Benchmarking
Methodology for Network Interconnect Devices", RFC
2544, March 1999.
[FIB-TERM] Trotter, G., "Terminology for Forwarding Information
Base (FIB) based Router Performance", RFC 3222,
December 2001.
[BLACKBOX] Shaikh, A. and Greenberg, A., "Experience in Black-
box OSPF measurement", Proc. ACM SIGCOMM Internet
Measurement Workshop (IMW), November 2001
Authors’ Addresses
Vishwas Manral
SiNett Corp,
Ground Floor,
Embassy Icon Annexe,
2/1, Infantry Road,
Bangalore, India
EMail: vishwas@sinett.com
Russ White
Cisco Systems, Inc.
7025 Kit Creek Rd.
Research Triangle Park, NC 27709
EMail: riw@cisco.com
Aman Shaikh
AT&T Labs (Research)
180 Park Av, PO Box 971
Florham Park, NJ 07932
EMail: ashaikh@research.att.com
Full Copyright Statement
Copyright (C) The Internet Society (2005).
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 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.