draft-ietf-bmwg-ospfconv-term-03.txt   draft-ietf-bmwg-ospfconv-term-04.txt 
Network Working Group Vishwas Manral Network Working Group Vishwas Manral
Internet Draft Netplane Systems Internet Draft Netplane Systems
Russ White Russ White
Cisco Systems Cisco Systems
Aman Shaikh Aman Shaikh
Expiration Date: September 2003 University of California Expiration Date: September 2003 University of California
File Name: draft-ietf-bmwg-ospfconv-term-03.txt March 2003 File Name: draft-ietf- bmwg-ospfconv-term-04.txt March 2003
OSPF Benchmarking Terminology and Concepts OSPF Benchmarking Terminology and Concepts
draft-ietf-bmwg-ospfconv-term-03.txt draft-ietf-bmwg-ospfconv-term-04.txt
1. Status of this Memo 1. Status of this Memo
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026. all provisions of Section 10 of RFC2026.
Internet Drafts are working documents of the Internet Engineering Internet Drafts are working documents of the Internet Engineering
Task Force (IETF), its Areas, and its Working Groups. Note that other Task Force (IETF), its Areas, and its Working Groups. Note that other
groups may also distribute working documents as Internet Drafts. groups may also distribute working documents as Internet Drafts.
skipping to change at page 2, line 12 skipping to change at page 2, line 12
include discussions concerning these terms as they relate include discussions concerning these terms as they relate
specifically to the tasks involved in benchmarking the OSPF protocol. specifically to the tasks involved in benchmarking the OSPF protocol.
3. Motivation 3. Motivation
This draft is a companion to [BENCHMARK], which describes basic Open This draft is a companion to [BENCHMARK], which describes basic Open
Shortest Path First [OSPF] testing methods. This draft explains Shortest Path First [OSPF] testing methods. This draft explains
terminology and concepts used in OSPF Testing Framework Drafts, such terminology and concepts used in OSPF Testing Framework Drafts, such
as [BENCHMARK]. as [BENCHMARK].
4. Definitions 4. Common Definitions
Definitions in this section are well known industry and benchmarking
terms which may be defined elsewhere.
o Internal Measurements o Internal Measurements
- Definition - Definition
Also known as White Box Measurements; internal measure- Internal measurements are measurements taken on the Device
ments are measurements taken on the Device Under Test Under Test (DUT) itself; also known as White Box Measure-
(DUT) itself. ments.
- Discussion - Discussion
These measurement rely on output and event recording, These measurement rely on output and event recording,
along with the clocking and timestamping available on the along with the clocking and timestamping available on the
DUT itself. Taking measurements on the DUT may impact the DUT itself. Taking measurements on the DUT may impact the
actual outcome of the test, since it can increase proces- actual outcome of the test, since it can increase proces-
sor loading, memory utilization, and timing factors. Some sor loading, memory utilization, and timing factors. Some
devices may not have the required output readily available devices may not have the required output readily available
for taking internal measurements, as well. for taking internal measurements, as well.
skipping to change at page 2, line 42 skipping to change at page 2, line 45
Note: Internal measurements can be influenced by the Note: Internal measurements can be influenced by the
vendor's implementation of the various timers and process- vendor's implementation of the various timers and process-
ing models. Whenever possible, internal measurements ing models. Whenever possible, internal measurements
should be compared to external measurements to verify and should be compared to external measurements to verify and
validate them. validate them.
o External Measurements o External Measurements
- Definition - Definition
Also known as Black Box Measurements; external measure- External measurements infer the performance of the DUT
ments infer the performance of the DUT through observation through observation of its communications with other
of its communications with other devices. devices; also known as Black Box Measurements.
- Discussion - Discussion
One example of an external measurement is when a down- One example of an external measurement is when a down-
stream device receives complete routing information from stream device receives complete routing information from
the DUT, it can be inferred that the DUT has transmitted the DUT, it can be inferred that the DUT has transmitted
all the routing information available. External measure- all the routing information available. External measure-
ments suffer in that they include not just the protocol ments suffer in that they include not just the protocol
action times, but also propagation delays, queuing delays, action times, but also propagation delays, queuing delays,
and other such factors. and other such factors.
For the purposes of this paper, external techniques are For the purposes of [BENCHMARK], external techniques are
more readily applicable. more readily applicable.
o Multi-device Measurements o Multi-device Measurements
- Definition - Definition
Multi-device measurements require the measurement of Multi-device measurements require the measurement of
events occurring on multiple devices within the testbed. events occurring on multiple devices within the testbed.
- Discussion - Discussion
skipping to change at page 3, line 41 skipping to change at page 4, line 5
cessing the event. cessing the event.
These sorts of measurements are the most problematic, and These sorts of measurements are the most problematic, and
are to be avoided where possible, since the timestamps of are to be avoided where possible, since the timestamps of
the devices in the test bed must be synchronized within the devices in the test bed must be synchronized within
milliseconds for the test results to be meaningful. Given milliseconds for the test results to be meaningful. Given
the state of network time protocol implementation, expect- the state of network time protocol implementation, expect-
ing the timestamps on several devices to be within mil- ing the timestamps on several devices to be within mil-
liseconds of each other is highly optimistic. liseconds of each other is highly optimistic.
5. Terms Defined Elsewhere
Terms in this section are defined elsewhere, and included only to
include a discussion of those terms in reference to [BENCHMARK].
o Point-to-Point links o Point-to-Point links
- Definition - Definition
See [OSPF], Section 1.2. See [OSPF], Section 1.2.
- Discussion - Discussion
A point-to-point link can take lesser time to converge A point-to-point link can take lesser time to converge
than a broadcast link of the same speed because it does than a broadcast link of the same speed because it does
skipping to change at page 4, line 33 skipping to change at page 4, line 44
more than that on a point-to-point link of the same speed, more than that on a point-to-point link of the same speed,
because DR election has to take place. All routers on a because DR election has to take place. All routers on a
broadcast network form adjacency with the DR and BDR. broadcast network form adjacency with the DR and BDR.
Async flooding also takes place thru the DR. In context of Async flooding also takes place thru the DR. In context of
convergence, it may take more time for an LSU to be convergence, it may take more time for an LSU to be
flooded from one DR-other router to another DR-other flooded from one DR-other router to another DR-other
router, because the LSA has to be first processed at the router, because the LSA has to be first processed at the
DR. DR.
o Shortest Path First Time o Shortest Path First Execution Time
- Definition - Definition
The time taken by a router to complete the SPF process, as The time taken by a router to complete the SPF process, as
described in [OSPF]. described in [OSPF].
- Discussion - Discussion
This does not include the time taken by the router to give This does not include the time taken by the router to give
routes to the forwarding engine. routes to the forwarding engine.
Some implementations may force two intervals, the SPF hold
time and the SPF delay, between successive SPF calcula-
tions. If an SPF hold time exists, it should be subtracted
from the total SPF execution time. If an SPF delay exists,
it should be noted in the test results.
o Measurement Units o Measurement Units
The SPF time is generally measured in milliseconds. The SPF time is generally measured in milliseconds.
o Hello Interval o Hello Interval
- Definition - Definition
See [OSPF], Section 7.1. See [OSPF], Section 7.1.
- Discussion - Discussion
skipping to change at page 5, line 38 skipping to change at page 6, line 14
See [OSPF], Section 7.1. See [OSPF], Section 7.1.
- Discussion - Discussion
This is advertised in the router's Hello Packets in the This is advertised in the router's Hello Packets in the
RouterDeadInterval field. The router dead interval should RouterDeadInterval field. The router dead interval should
be some multiple of the HelloInterval (say 4 times the be some multiple of the HelloInterval (say 4 times the
hello interval), and must be the same for all routers hello interval), and must be the same for all routers
attached to a common network. attached to a common network.
o Incremental SPF 6. Concepts
- Definition
The ability to recalculate a small portion of the SPF
tree, rather than the entire SPF tree, on receiving
notification of a change in the network topology.
- Discussion
At worst, incremental SPF should perform no worse than a
full SPF. In better situations, an incremental SPF run
will rebuild the SPF tree in much shorter time than a full
SPF run.
5. Concepts
5.1. The Meaning of Control Plane Convergence 6.1. The Meaning of Single Router Control Plane Convergence
A network is termed to be converged when all of the devices within A network is termed to be converged when all of the devices within
the network have a loop free path to each possible destination. Since the network have a loop free path to each possible destination. Since
we are not testing network convergence, but performance for a partic- we are not testing network convergence, but performance for a partic-
ular device within a network, however, this definition needs to be ular device within a network, however, this definition needs to be
narrowed somewhat to fit within a single device view. narrowed somewhat to fit within a single device view.
In this case, convergence will mean the point in time when the DUT In this case, convergence will mean the point in time when the DUT
has performed all actions needed to react to the change in topology has performed all actions needed to react to the change in topology
represented by the test condition; for instance, an OSPF device must represented by the test condition; for instance, an OSPF device must
flood any new information it has received, rebuild its shortest path flood any new information it has received, rebuild its shortest path
first (SPF) tree, and install any new paths or destinations in the first (SPF) tree, and install any new paths or destinations in the
local routing information base (RIB, or routing table). local routing information base (RIB, or routing table).
Note that the word convergence has two distinct meanings; the process Note that the word convergence has two distinct meanings; the process
of a group of individuals meeting the same place, and the process of of a group of individuals meeting the same place, and the process of
a single individual meeting in the same place as an existing group. a single individual meeting in the same place as an existing group.
This work focuses on the second meaning of the word, so we consider This work focuses on the second meaning of the word, so we consider
the time required for a single device to adapt to a network change to the time required for a single device to adapt to a network change to
be SR-Convergence, or Single Router Convergence. be Single Router Convergence.
This concept does not include the time required for the control plane This concept does not include the time required for the control plane
of the device to transfer the information required to forward packets of the device to transfer the information required to forward packets
to the data plane, nor the amount of time between the data plane to the data plane, nor the amount of time between the data plane
receiving that information and being able to actually forward receiving that information and being able to actually forward
traffic. traffic.
5.2. Measuring Convergence 6.2. Measuring Convergence
Obviously, there are several elements to convergence, even under the Obviously, there are several elements to convergence, even under the
definition given above for a single device, including (but not lim- definition given above for a single device, including (but not lim-
ited to): ited to):
o The time it takes for the DUT to pass the information about a o The time it takes for the DUT to pass the information about a
network event on to its neighbors. network event on to its neighbors.
o The time it takes for the DUT to process information about a o The time it takes for the DUT to process information about a
network event and calculate a new Shortest Path Tree (SPT). network event and calculate a new Shortest Path Tree (SPT).
o The time it takes for the DUT to make changes in its local o The time it takes for the DUT to make changes in its local
rib reflecting the new shortest path tree. rib reflecting the new shortest path tree.
5.3. Types of Network Events 6.3. Types of Network Events
A network event is an event which causes a change in the network A network event is an event which causes a change in the network
topology. topology.
o Link or Neighbor Device Up o Link or Neighbor Device Up
The time needed for an OSPF implementation to recoginize a The time needed for an OSPF implementation to recoginize a
new link coming up on the device, build any necessarily adja- new link coming up on the device, build any necessarily adja-
cencies, synchronize its database, and perform all other cencies, synchronize its database, and perform all other
needed actions to converge. needed actions to converge.
skipping to change at page 8, line 12 skipping to change at page 8, line 12
gate any information as necessary to its remaining adjacen- gate any information as necessary to its remaining adjacen-
cies, and perform other actions needed to converge. cies, and perform other actions needed to converge.
o Link Down o Link Down
The time needed for an OSPF implementation to recognize a The time needed for an OSPF implementation to recognize a
link down based on layer 2 provided information, propogate link down based on layer 2 provided information, propogate
any information as needed to its remaining adjacencies, and any information as needed to its remaining adjacencies, and
perform other actions needed to converge. perform other actions needed to converge.
6. Acknowedgements 7. Acknowedgements
The authors would like to thank Howard Berkowitz (hcb@clark.net), The authors would like to thank Howard Berkowitz (hcb@clark.net),
Kevin Dubray, (kdubray@juniper.net), and Randy Bush (randy@psg.com) Kevin Dubray, (kdubray@juniper.net), Scott Poretsky
for their discussion, ideas, and support. (sporetsky@avici.com), and Randy Bush (randy@psg.com) for their dis-
cussion, ideas, and support.
7. Normative References 8. Normative References
[BENCHMARK] [BENCHMARK]
Manral, V., "Benchmarking Methodology for Basic OSPF Convergence", Manral, V., "Benchmarking Basic OSPF Single Router Control Plane
draft-bmwg-ospfconv-intraarea-04, March 2003 Convergence", draft-bmwg-ospfconv-intraarea-05, March 2003
[OSPF]Moy, J., "OSPF Version 2", RFC 2328, April 1998. [OSPF]Moy, J., "OSPF Version 2", RFC 2328, April 1998.
8. Informative References 9. Informative References
[CONGESTION] [CONGESTION]
Ash, J., "Proposed Mechanisms for Congestion Control/Failure Ash, J., "Proposed Mechanisms for Congestion Control/Failure
Recovery in OSPF & ISIS Networks", October, 2001 Recovery in OSPF & ISIS Networks", October, 2001
[MARKING] [MARKING]
Choudhury, G., et al, "Explicit Marking and Prioritized Treatment Choudhury, G., et al, "Explicit Marking and Prioritized Treatment
of Specific IGP Packets for Faster IGP Convergence and Improved of Specific IGP Packets for Faster IGP Convergence and Improved
Network Scalability and Stability", draft-ietf-ospf-scalability, Network Scalability and Stability", draft-ietf-ospf-scalability,
April 2002 April 2002
9. Authors' Addresses 10. Authors' Addresses
Vishwas Manral, Vishwas Manral,
Netplane Systems, Netplane Systems,
189 Prashasan Nagar, 189 Prashasan Nagar,
Road number 72, Road number 72,
Jubilee Hills, Jubilee Hills,
Hyderabad. Hyderabad.
vmanral@netplane.com vmanral@netplane.com
 End of changes. 

This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/