Network Working Group V. Manral
Request for Comments: 4063 SiNett Corp.
Category: Informational R. White
AT&T Labs (Research)
Considerations When Using Basic OSPF Convergence Benchmarks
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 (C) The Internet Society (2005).
This document discusses the applicability of various tests for
measuring single router control plane convergence, specifically in
regard to the Open Shortest First (OSPF) protocol. There are two
general sections in this document, the first discusses advantages and
limitations of specific OSPF convergence tests, and the second
discusses more general pitfalls to be considered when routing
protocol convergence is tested.
There is a growing interest in testing single router control plane
convergence for routing protocols, and many people are looking at
testing methodologies that can provide information on how long it
takes for a network to converge after various network events occur.
It is important to consider the framework within which any given
convergence test is executed when one attempts to apply the results
of the testing, since the framework can have a major impact on the
results. For instance, determining when a network is converged, what
parts of the router's operation are considered within the testing,
and other such things will have a major impact on the apparent
performance that routing protocols provide.
Manral, et al. Informational [Page 1]RFC 4063 Considerations in OSPF Benchmarking April 2005
This document describes in detail various benefits and pitfalls of
tests described in [BENCHMARK]. It also explains how such
measurements can be useful for providers and the research community.
NOTE: In this document, the word "convergence" refers to single
router control plane convergence [TERM].
2. Advantages of Such Measurement
o To be able to compare the iterations of a protocol
implementation. It is often useful to be able to compare the
performance of two iterations of a given implementation of a
protocol in order to determine where improvements have been made
and where further improvements can be made.
o To understand, given a set of parameters (network conditions),
how a particular implementation on a particular device will
perform. For instance, if you were trying to decide the
processing power (size of device) required in a certain location
within a network, you could emulate the conditions that will
exist at that point in the network and use the test described to
measure the performance of several different routers. The
results of these tests can provide one possible data point for
an intelligent decision.
If the device being tested is to be deployed in a running
network, using routes taken from the network where the equipment
is to be deployed rather than some generated topology in these
tests will yield results that are closer to the real performance
of the device. Care should be taken to emulate or take routes
from the actual location in the network where the device will be
(or would be) deployed. For instance, one set of routes may be
taken from an ABR, one set from an area 0 only router, various
sets from stub area, another set from various normal areas, etc.
o To measure the performance of an OSPF implementation in a wide
variety of scenarios.
o To be used as parameters in OSPF simulations by researchers. It
may sometimes be required for certain kinds of research to
measure the individual delays of each parameter within an OSPF
implementation. These delays can be measured using the methods
defined in [BENCHMARK].
o To help optimize certain configurable parameters. It may
sometimes be helpful for operators to know the delay required
for individual tasks in order to optimize the resource usage in
the network. For example, if the processing time on a router is