draft-ietf-bmwg-ospfconv-term-07.txt   draft-ietf-bmwg-ospfconv-term-08.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: July 2004 University of California Expiration Date: November 2004 University of California
File Name: draft-bmwg-ospfconv-term-07.txt January 2004 File Name: draft-bmwg-ospfconv-term-08.txt May 2004
OSPF Benchmarking Terminology and Concepts OSPF Benchmarking Terminology and Concepts
draft-ietf-bmwg-ospfconv-term-07.txt draft-ietf-bmwg-ospfconv-term-08.txt
1. Status of this Memo 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.
Internet Drafts are draft documents valid for a maximum of six Internet Drafts are draft documents valid for a maximum of six
months. Internet Drafts may be updated, replaced, or obsoleted by months. Internet Drafts may be updated, replaced, or obsoleted by
other documents at any time. It is not appropriate to use Internet other documents at any time. It is not appropriate to use Internet
Drafts as reference material or to cite them other than as a "working Drafts as reference material or to cite them other than as a "working
draft" or "work in progress". draft" or "work in progress".
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http//www.ietf.org/ietf/1id-abstracts.txt http//www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http//www.ietf.org/shadow.html. http//www.ietf.org/shadow.html.
2. Abstract Copyright Notice
Copyright (C) The Internet Society (2002). All Rights Reserved.
Abstract
This draft explains the terminology and concepts used in OSPF This draft explains the terminology and concepts used in OSPF
benchmarking. While some of these terms may be defined elsewhere, and benchmarking. While some of these terms may be defined elsewhere, and
we will refer the reader to those definitions in some cases, we also we will refer the reader to those definitions in some cases, we also
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 1. Specification of Requirements
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119].
2. 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. Common Definitions 3. Common Definitions
Definitions in this section are well known industry and benchmarking Definitions in this section are well known industry and benchmarking
terms which may be defined elsewhere. terms which may be defined elsewhere.
o White Box (Internal) Measurements o White Box (Internal) Measurements
- Definition - Definition
White Box measurements are measurements reported and col- White Box measurements are measurements reported and col-
lected on the Device Under Test (DUT) itself. lected on the Device Under Test (DUT) itself.
- Discussion - Discussion
These measurement rely on output and event recording, These measurement rely on output and event recording, along
along with the clocking and timestamping available on the with the clocking and timestamping available on the DUT
DUT itself. Taking measurements on the DUT may impact the 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 processor
sor loading, memory utilization, and timing factors. Some loading, memory utilization, and timing factors. Some dev-
devices may not have the required output readily available ices may not have the required output readily available for
for taking internal measurements, as well. taking internal measurements, as well.
Note: White box measurements can be influenced by the Note: White box 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
should be compared to external measurements to verify and be compared to external measurements to verify and validate
validate them. them.
Because of the potential for variations in collection and Because of the potential for variations in collection and
presentation methods across different DUTs, white box presentation methods across different DUTs, white box
measurements MUST NOT be used as a basis of comparison in measurements MUST NOT be used as a basis of comparison in
benchmarks. This has been a guiding principal of Bench- benchmarks. This has been a guiding principal of Bench-
marking Methodology Working Group. marking Methodology Working Group.
o Black Box (External) Measurements o Black Box (External) Measurements
- Definition - Definition
Black Box measurements infer the performance of the DUT Black Box measurements infer the performance of the DUT
through observation of its communications with other dev- through observation of its communications with other dev-
ices. ices.
- Discussion - Discussion
One example of a black box measurement is when a down- One example of a black box measurement is when a downstream
stream device receives complete routing information from device receives complete routing information from the DUT,
the DUT, it can be inferred that the DUT has transmitted it can be inferred that the DUT has transmitted all the
all the routing information available. External measure- routing information available. External measurements of
ments of internal operations may suffer in that they internal operations may suffer in that they include not
include not just the protocol action times, but also pro- just the protocol action times, but also propagation
pagation delays, queuing delays, and other such factors. delays, queuing delays, and other such factors.
For the purposes of [BENCHMARK], 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
- Measurements assessing communications (usually in combina- - Measurements assessing communications (usually in combina-
tion with internal operations) between two or more DUTs. tion with internal operations) between two or more DUTs.
Multi-device measurements may be internal or external. Multi-device measurements may be internal or external.
5. Terms Defined Elsewhere 4. Terms Defined Elsewhere
Terms in this section are defined elsewhere, and included only to Terms in this section are defined elsewhere, and included only to
include a discussion of those terms in reference to [BENCHMARK]. 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
than a broadcast link of the same speed because it does a broadcast link of the same speed because it does not have
not have the overhead of DR election. Point-to-point links the overhead of DR election. Point-to-point links can be
can be either numbered or unnumbered. However in the con- either numbered or unnumbered. However in the context of
text of [BENCHMARK] and [OSPF], the two can be regarded [BENCHMARK] and [OSPF], the two can be regarded the same.
the same.
o Broadcast Link o Broadcast Link
- Definition - Definition
See [OSPF], Section 1.2. See [OSPF], Section 1.2.
- Discussion - Discussion
The adjacency formation time on a broadcast link can be The adjacency formation time on a broadcast link can be
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 LSA to be convergence, it may take more time for an LSA to be flooded
flooded from one DR-other router to another DR-other from one DR-other router to another DR-other router,
router, because the LSA has to be first processed at the because the LSA has to be first processed at the DR.
DR.
o Shortest Path First Execution 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 Some implementations may force two intervals, the SPF hold
time and the SPF delay, between successive SPF calcula- time and the SPF delay, between successive SPF calcula-
skipping to change at page 5, line 5 skipping to change at page 5, line 18
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 Some implementations may force two intervals, the SPF hold
time and the SPF delay, between successive SPF calcula- time and the SPF delay, between successive SPF calcula-
tions. If an SPF hold time exists, it should be subtracted tions. If an SPF hold time exists, it should be subtracted
from the total SPF execution time. If an SPF delay exists, from the total SPF execution time. If an SPF delay exists,
it should be noted in the test results. it should be noted in the test results.
o Measurement Units - 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 35 skipping to change at page 6, line 7
given in [OSPF-SCALING]. given in [OSPF-SCALING].
o Router Dead interval o Router Dead interval
- Definition - Definition
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 Router-
RouterDeadInterval field. The router dead interval should DeadInterval field. The router dead interval should be some mul-
be some multiple of the HelloInterval (say 4 times the tiple of the HelloInterval (say 4 times the hello interval), and
hello interval), and must be the same for all routers must be the same for all routers attached to a common network.
attached to a common network.
6. Concepts 5. Concepts
6.1. The Meaning of Single Router Control Plane Convergence 5.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
skipping to change at page 6, line 35 skipping to change at page 6, line 42
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 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.
6.2. Measuring Convergence 5.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
rib reflecting the new shortest path tree. reflecting the new shortest path tree.
6.3. Types of Network Events 5.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
new link coming up on the device, build any necessarily adja- link coming up on the device, build any necessarily adjacencies,
cencies, synchronize its database, and perform all other synchronize its database, and perform all other needed actions
needed actions to converge. to converge.
o Initialization o Initialization
The time needed for an OSPF implementation to be initialized, The time needed for an OSPF implementation to be initialized,
recognize any links across which OSPF must run, build any recognize any links across which OSPF must run, build any needed
needed adjacencies, synchronize its database, and perform adjacencies, synchronize its database, and perform other actions
other actions needed to converge. needed to converge.
o Adjacency Down o Adjacency Down
The time needed for an OSPF implementation to recognize a The time needed for an OSPF implementation to recognize a link
link down/adjacency loss based on hello timers alone, propo- down/adjacency loss based on hello timers alone, propogate any
gate any information as necessary to its remaining adjacen- information as necessary to its remaining adjacencies, and per-
cies, and perform other actions needed to converge. form 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
link down based on layer 2 provided information, propogate down based on layer 2 provided information, propogate any infor-
any information as needed to its remaining adjacencies, and mation as needed to its remaining adjacencies, and perform other
perform other actions needed to converge. actions needed to converge.
6. Security Considerations
This doecument does not modify the underlying security considerations
in [OSPF].
7. 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), Scott Poretsky Kevin Dubray, (kdubray@juniper.net), Scott Poretsky
(sporetsky@avici.com), and Randy Bush (randy@psg.com) for their dis- (sporetsky@avici.com), and Randy Bush (randy@psg.com) for their dis-
cussion, ideas, and support. cussion, ideas, and support.
8. Normative References 8. Normative References
[BENCHMARK] [BENCHMARK]
Manral, V., "Benchmarking Basic OSPF Single Router Control Plane Manral, V., "Benchmarking Basic OSPF Single Router Control Plane
Convergence", draft-bmwg-ospfconv-intraarea-05, March 2003 Convergence", draft-bmwg-ospfconv-intraarea-08, May 2004.
[OSPF]Moy, J., "OSPF Version 2", RFC 2328, April 1998. [OSPF]Moy, J., "OSPF Version 2", RFC 2328, April 1998.
9. Informative References 9. Informative References
[OSPF-SCALING] [OSPF-SCALING]
Choudhury, Gagan L., Editor, "Prioritized Treatment of Specific Choudhury, Gagan L., Editor, "Prioritized Treatment of Specific
OSPF Packets and Congestion Avoidance", draft-ietf-ospf- OSPF Packets and Congestion Avoidance", draft-ietf-ospf-
scalability-06.txt, August 2003. scalability-06.txt, August 2003.
 End of changes. 

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