Terminology for
Benchmarking Link-State IGP Data Plane Route ConvergenceAllot Communications67 South Bedford Street, Suite 400BurlingtonMA01803USA+ 1 508 309 2179sporetsky@allot.comJuniper Networks1194 North Mathilda AveSunnyvaleCA94089USA+ 1 314 378 2571bimhoff@planetspork.comCisco Systems6A De KleetlaanDiegemBRABANT1831Belgiumkmichiel@cisco.com
Benchmarking Working Group
This document describes the terminology for benchmarking Interior
Gateway Protocol (IGP) Route Convergence. The terminology is to be used
for benchmarking IGP convergence time through externally observable
(black box) data plane measurements. The terminology can be applied to
any link-state IGP, such as ISIS and OSPF.This draft describes the terminology for benchmarking Link-State
Interior Gateway Protocol (IGP) Convergence. The motivation and
applicability for this benchmarking is provided in . The methodology to be used for this benchmarking
is described in . The purpose of this
document is to introduce new terms required to complete execution of the
IGP Route Methodology .IGP convergence time is measured on the data plane at the Tester by
observing packet loss through the DUT. The methodology and terminology
to be used for benchmarking IGP Convergence can be applied to IPv4 and
IPv6 traffic and link-state IGPs such as ISIS , OSPF , and others.This document uses existing terminology defined in other BMWG work.
Examples include, but are not limited to:Frame Loss Rate[Ref., section 3.6]Throughput[Ref., section 3.17]Offered Load[Ref., section 3.5.2]Forwarding Rate[Ref., section 3.6.1]Device Under Test (DUT)[Ref., section 3.1.1]System Under Test (SUT)[Ref., section 3.1.2]Out-of-order Packet[Ref., section 3.3.2]Duplicate Packet[Ref., section 3.3.3]Packet Reordering[Ref., section 3.3]Stream[Ref., section 3.3.2]Forwarding Delay[Ref., section 3.2.4]Loss Period[Ref., section 4]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 BCP 14, RFC 2119 . RFC 2119 defines the use of these key words to
help make the intent of standards track documents as clear as possible.
While this document uses these keywords, this document is not a
standards track document.Definition:The process of updating all components of the router, including
the Routing Information Base (RIB) and Forwarding Information Base
(FIB), along with software and hardware tables, with the most recent
route change(s) such that forwarding for a route entry is successful
on the Next-Best Egress Interface.Discussion:Route Convergence MUST occur after a Convergence Event. Route
Convergence can be observed externally by the rerouting of data
traffic for a destination matching a route entry to the Next-best
Egress Interface. Completion of Route Convergence may or may not be
sustained over time.Measurement Units: N/AIssues: NoneSee Also:Network Convergence, Full Convergence, Convergence EventDefinition:Route Convergence for all routes in the FIB.Discussion:Full Convergence MUST occur after a Convergence Event. Full
Convergence can be observed externally by the rerouting of data
traffic to destinations matching all route entries to the Next-best
Egress Interface. Completion of Full Convergence is externally
observable from the data plane when the Forwarding Rate of the data
plane traffic on the Next-Best Egress Interface equals the Offered
Load.Completion of Full Convergence may or may not be sustained over
time.Measurement Units: N/AIssues: NoneSee Also:Network Convergence, Route Convergence, Convergence Event, Full
Convergence Time, Convergence Recovery InstantDefinition:Full Convergence in all routers throughout the network.Discussion:Network Convergence includes all Route Convergence operations for
all routers in the network following a Convergence Event.Completion of Network Convergence can be observed by recovery of
the network Forwarding Rate to equal the Offered Load, with no Stale
Forwarding, and no Blenders .Completion of Network Convergence may or may not be sustained
over time.Measurement Units: N/AIssues: NoneSee Also:Route Convergence, Full Convergence, Stale ForwardingDefinition:The time instant the Tester sends out the first data packet to
the DUT.Discussion:If using the Loss-Derived Method or the Route-Specific
Loss-Derived Method to benchmark IGP convergence time, and the
applied Convergence Event does not cause instantaneous traffic loss
for all routes at the Convergence Event Instant then the Tester
SHOULD collect a timestamp on the Traffic Start Instant in order to
measure the period of time between the Traffic Start Instant and
Convergence Event Instant.Measurement Units:hh:mm:ss:nnn:uuu, where 'nnn' is milliseconds and 'uuu' is
microseconds.Issues: NoneSee Also:Convergence Event Instant, Route-Specific Convergence Time,
Loss-Derived Convergence Time.Definition:The time instant that a Convergence Event occurs.Discussion:If the Convergence Event causes instantaneous traffic loss on the
Preferred Egress Interface, the Convergence Event Instant is
observable from the data plane as the instant that the DUT begins to
exhibit packet loss.The Tester SHOULD collect a timestamp on the Convergence Event
Instant if it is not observable from the data plane.Measurement Units:hh:mm:ss:nnn:uuu, where 'nnn' is milliseconds and 'uuu' is
microseconds.Issues: NoneSee Also: Convergence EventDefinition:The time instant that Full Convergence has completed.Discussion:The Full Convergence completed state MUST be maintained for an
interval of duration equal to the Sustained Convergence Validation
Time in order to validate the Convergence Recovery Instant.The Convergence Recovery Instant is observable from the data
plane as the instant the DUT forwards traffic to all destinations
over the Next-Best Egress Interface.When using the Rate-Derived Method, the Convergence Recovery
Instant falls within the Packet Sampling Interval preceding the
first interval where the observed Forwarding Rate on the Next-Best
Egress Interface equals the Offered Load.Measurement Units:hh:mm:ss:nnn:uuu, where 'nnn' is milliseconds and 'uuu' is
microseconds.Issues: NoneSee Also:Sustained Convergence Validation Time, Full ConvergenceDefinition:The time instant the first route entry completes Route
Convergence following a Convergence EventDiscussion:Any route may be the first to complete Route Convergence. The
First Route Convergence Instant is observable from the data plane as
the instant that the first packet is received from the Next-Best
Egress Interface.Measurement Units:hh:mm:ss:nnn:uuu, where 'nnn' is milliseconds and 'uuu' is
microseconds.Issues: NoneSee Also: Route ConvergenceDefinition:A time interval following a Convergence Event in which Forwarding
Rate on the Preferred Egress Interface gradually reduces to
zero.Discussion:The Forwarding Rate during a Convergence Event Transition may not
decrease linearly.The Forwarding Rate observed on all DUT egress interfaces may or
may not decrease to zero.The Offered Load, the number of routes, and the Packet Sampling
Interval influence the observations of the Convergence Event
Transition using the Rate-Derived Method. This is further discussed
with the term "Rate-Derived Method".Measurement Units: secondsIssues: NoneSee Also:Convergence Event, Rate-Derived MethodDefinition:A time interval following the First Route Convergence Instant in
which Forwarding Rate on the Next-Best Egress Interface gradually
increases to equal the Offered Load.Discussion:The Forwarding Rate observed during a Convergence Recovery
Transition may not increase linearly.The Offered Load, the number of routes, and the Packet Sampling
Interval influence the observations of the Convergence Recovery
Transition using the Rate-Derived Method. This is further discussed
with the term "Rate-Derived Method".Measurement Units: secondsIssues: NoneSee Also:Full Convergence,First Route Convergence Instant, Rate-Derived
MethodDefinition:An interface on the DUT.Discussion:A failure of the Local Interface indicates that the failure
occurred directly on the DUT.Measurement Units: N/AIssues: NoneSee Also: Remote InterfaceDefinition:An interface on a neighboring router that is not directly
connected to any interface on the DUT.Discussion:A failure of a Remote Interface indicates that the failure
occurred on a neighbor router's interface that is not directly
connected to the DUT.Measurement Units: N/AIssues: NoneSee Also: Local InterfaceDefinition:The outbound interface from the DUT for traffic routed to the
preferred next-hop.Discussion:The Preferred Egress Interface is the egress interface prior to a
Convergence Event.Measurement Units: N/AIssues: NoneSee Also: Next-Best Egress InterfaceDefinition:The outbound interface from the DUT for traffic routed to the
second-best next-hop.Discussion:The Next-Best Egress Interface becomes the egress interface after
a Convergence Event.The Next-Best Egress Interface is of the same media type and link
speed as the Preferred Egress Interface.Measurement Units: N/AIssues: NoneSee Also: Preferred Egress InterfaceDefinition:The method to calculate convergence time benchmarks from
observing Forwarding Rate each Packet Sampling Interval.Discussion: shows an example of the Forwarding
Rate change in time during convergence as observed when using the
Rate-Derived Method.The Offered Load SHOULD consist of a single Stream . If sending multiple Streams, the measured
traffic rate statistics for all Streams MUST be added together.The destination addresses for the Offered Load MUST be
distributed such that all routes or a statistically representative
subset of all routes are matched and each of these routes is offered
an equal share of the Offered Load. It is RECOMMENDED to send
traffic to all routes, but a statistically representative subset of
all routes can be used if required.At least one packet per route for all routes matched in the
Offered Load MUST be offered to the DUT within each Packet Sampling
Interval.The Offered Load, the number of routes, and the Packet Sampling
Interval influence the observations for the Rate-Derived Method. It
may be difficult to identify the different convergence time instants
in the Rate-Derived Convergence Graph. For example, it is possible
that a Convergence Event causes the Forwarding Rate to drop to zero,
while this may not be observed in the Forwarding Rate measurements
if the Packet Sampling Interval is too large.Metrics measured at the Packet Sampling Interval MUST include
Forwarding Rate and packet loss.Rate-Derived Method is a RECOMMENDED method to measure
convergence time benchmarks.To measure convergence time benchmarks for Convergence Events
that do not cause instantaneous traffic loss for all routes at the
Convergence Event Instant, the Tester SHOULD collect a timestamp of
the Convergence Event Instant and the Tester SHOULD observe
Forwarding Rate separately on the Next-Best Egress Interface.Since the Rate-Derived Method does not distinguish between
individual traffic destinations, it SHOULD NOT be used for any route
specific measurements. Therefor Rate-Derived Method SHOULD NOT be
used to benchmark Route Loss of Connectivity Period.Measurement Units: N/AIssues: NoneSee Also:Packet Sampling Interval, Convergence Event, Convergence Event
Instant, Full ConvergenceDefinition:The method to calculate the Loss-Derived Convergence Time and
Loss-Derived Loss of Connectivity Period benchmarks from the amount
of packet loss.Discussion:The Offered Load SHOULD consist of a single Stream . If sending multiple Streams, the measured
traffic rate statistics for all Streams MUST be added together.The destination addresses for the Offered Load MUST be
distributed such that all routes or a statistically representative
subset of all routes are matched and each of these routes is offered
an equal share of the Offered Load. It is RECOMMENDED to send
traffic to all routes, but a statistically representative subset of
all routes can be used if required.Loss-Derived Method SHOULD always be combined with Rate-Derived
Method in order to observe Full Convergence completion. The total
amount of Convergence Packet Loss is collected after Full
Convergence completion.To measure convergence time and loss of connectivity benchmarks,
the Tester SHOULD in general observe packet loss on all DUT egress
interfaces (Connectivity Packet Loss).To measure convergence time benchmarks for Convergence Events
that do not cause instantaneous traffic loss for all routes at the
Convergence Event Instant, the Tester SHOULD collect timestamps of
the Start Traffic Instant and of the Convergence Event Instant, and
the Tester SHOULD observe packet loss separately on the Next-Best
Egress Interface (Convergence Packet Loss).Since Loss-Derived Method does not distinguish between traffic
destinations and the packet loss statistics are only collected after
Full Convergence completion, this method can only be used to measure
average values over all routes. For these reasons Loss-Derived
Method can only be used to benchmark Loss-Derived Convergence Time
and Loss-Derived Loss of Connectivity Period.Note that the Loss-Derived Method measures an average over all
routes, including the routes that may not be impacted by the
Convergence Event, such as routes via non-impacted members of ECMP
or parallel links.Measurement Units: secondsIssues: NoneSee Also:Loss-Derived Convergence Time, Loss-Derived Loss of Connectivity
Period, Convergence Packet LossDefinition:The method to calculate the Route-Specific Convergence Time
benchmark from the amount of packet loss during convergence for a
specific route entry.Discussion:To benchmark Route-Specific Convergence Time, the Tester provides
an Offered Load that consists of multiple Streams . Each Stream has a single destination address
matching a different route entry, for all routes or a statistically
representative subset of all routes. Convergence Packet Loss is
measured for each Stream separately.Route-Specific Loss-Derived Method SHOULD always be combined with
Rate-Derived Method in order to observe Full Convergence completion.
The total amount of Convergence Packet Loss for each Stream is
collected after Full Convergence completion.Route-Specific Loss-Derived Method is a RECOMMENDED method to
measure convergence time benchmarks.To measure convergence time and loss of connectivity benchmarks,
the Tester SHOULD in general observe packet loss on all DUT egress
interfaces (Connectivity Packet Loss).To measure convergence time benchmarks for Convergence Events
that do not cause instantaneous traffic loss for all routes at the
Convergence Event Instant, the Tester SHOULD collect timestamps of
the Start Traffic Instant and of the Convergence Event Instant, and
the Tester SHOULD observe packet loss separately on the Next-Best
Egress Interface (Convergence Packet Loss).Since Route-Specific Loss-Derived Method uses traffic streams to
individual routes, it measures packet loss as it would be
experienced by a network user. For this reason Route-Specific
Loss-Derived Method is RECOMMENDED to measure Route-Specific
Convergence Time benchmarks and Route Loss of Connectivity Period
benchmarks.Measurement Units: secondsIssues: NoneSee Also:Route-Specific Convergence Time, Route Loss of Connectivity
Period, Convergence Packet LossDefinition:The time duration of the period between the Convergence Event
Instant and the Convergence Recovery Instant as observed using the
Rate-Derived Method.Discussion:Using the Rate-Derived Method, Full Convergence Time can be
calculated as the time difference between the Convergence Event
Instant and the Convergence Recovery Instant, as shown in Equation
1.The Convergence Event Instant can be derived from the Forwarding
Rate observation or from a timestamp collected by the Tester.For the testcases described in , it
is expected that Full Convergence Time equals the maximum
Route-Specific Convergence Time when benchmarking all routes in FIB
using the Route-Specific Loss-Derived Method.It is not possible to measure Full Convergence Time using the
Loss-Derived Method.Measurement Units: secondsIssues: NoneSee Also:Full Convergence, Rate-Derived Method, Route-Specific
Loss-Derived MethodDefinition:The duration of the period between the Convergence Event Instant
and the First Route Convergence Instant as observed using the
Rate-Derived Method.Discussion:Using the Rate-Derived Method, First Route Convergence Time can
be calculated as the time difference between the Convergence Event
Instant and the First Route Convergence Instant, as shown with
Equation 2.The Convergence Event Instant can be derived from the Forwarding
Rate observation or from a timestamp collected by the Tester.For the testcases described in , it
is expected that First Route Convergence Time equals the minimum
Route-Specific Convergence Time when benchmarking all routes in FIB
using the Route-Specific Loss-Derived Method.It is not possible to measure First Route Convergence Time using
the Loss-Derived Method.Measurement Units: secondsIssues: NoneSee Also:Rate-Derived Method, Route-Specific Loss-Derived Method, First
Route Convergence InstantDefinition:The amount of time it takes for Route Convergence to be completed
for a specific route, as calculated from the amount of packet loss
during convergence for a single route entry.Discussion:Route-Specific Convergence Time can only be measured using the
Route-Specific Loss-Derived Method.If the applied Convergence Event causes instantaneous traffic
loss for all routes at the Convergence Event Instant, Connectivity
Packet Loss should be observed. Connectivity Packet Loss is the
combined packet loss observed on Preferred Egress Interface and
Next-Best Egress Interface. When benchmarking Route-Specific
Convergence Time, Connectivity Packet Loss is measured and Equation
3 is applied for each measured route. The calculation is equal to
Equation 7 in .If the applied Convergence Event does not cause instantaneous
traffic loss for all routes at the Convergence Event Instant, then
the Tester SHOULD collect timestamps of the Traffic Start Instant
and of the Convergence Event Instant, and the Tester SHOULD observe
Convergence Packet Loss separately on the Next-Best Egress
Interface. When benchmarking Route-Specific Convergence Time,
Convergence Packet Loss is measured and Equation 4 is applied for
each measured route.The Convergence Event Instant and Traffic Start Instant SHOULD be
collected by the Tester.The Route-Specific Convergence Time benchmarks enable minimum,
maximum, average, and median convergence time measurements to be
reported by comparing the results for the different route entries.
It also enables benchmarking of convergence time when configuring a
priority value for route entry(ies). Since multiple Route-Specific
Convergence Times can be measured it is possible to have an array of
results. The format for reporting Route-Specific Convergence Time is
provided in .Measurement Units: secondsIssues: NoneSee Also:Convergence Event, Convergence Packet Loss, Connectivity Packet
Loss, Route ConvergenceDefinition:The average Route Convergence time for all routes in FIB, as
calculated from the amount of packet loss during convergence.Discussion:Loss-Derived Convergence Time is measured using the Loss-Derived
Method.If the applied Convergence Event causes instantaneous traffic
loss for all routes at the Convergence Event Instant, Connectivity
Packet Loss should be observed. Connectivity Packet Loss is the
combined packet loss observed on Preferred Egress Interface and
Next-Best Egress Interface. When benchmarking Loss-Derived
Convergence Time, Connectivity Packet Loss is measured and Equation
5 is applied.If the applied Convergence Event does not cause instantaneous
traffic loss for all routes at the Convergence Event Instant, then
the Tester SHOULD collect timestamps of the Start Traffic Instant
and of the Convergence Event Instant and the Tester SHOULD observe
Convergence Packet Loss separately on the Next-Best Egress
Interface. When benchmarking Loss-Derived Convergence Time,
Convergence Packet Loss is measured and Equation 6 is applied.The Convergence Event Instant and Traffic Start Instant SHOULD be
collected by the Tester.Measurement Units: secondsIssues: NoneSee Also:Convergence Packet Loss, Connectivity Packet Loss, Route
ConvergenceDefinition:The time duration of traffic loss for a specific route entry
following a Convergence Event until Full Convergence completion, as
observed using the Route-Specific Loss-Derived Method.Discussion:In general the Route Loss of Connectivity Period is not equal to
the Route-Specific Convergence Time. If the DUT continues to forward
traffic to the Preferred Egress Interface after the Convergence
Event is applied then the Route Loss of Connectivity Period will be
smaller than the Route-Specific Convergence Time. This is also
specifically the case after reversing a failure event.The Route Loss of Connectivity Period may be equal to the
Route-Specific Convergence Time if, as a characteristic of the
Convergence Event, traffic for all routes starts dropping
instantaneously on the Convergence Event Instant. See discussion in
.For the testcases described in the
Route Loss of Connectivity Period is expected to be a single Loss
Period .When benchmarking Route Loss of Connectivity Period, Connectivity
Packet Loss is measured for each route and Equation 7 is applied for
each measured route entry. The calculation is equal to Equation 3 in
.Route Loss of Connectivity Period SHOULD be measured using
Route-Specific Loss-Derived Method.Measurement Units: secondsIssues: NoneSee Also:Route-Specific Convergence Time, Route-Specific Loss-Derived
Method, Connectivity Packet LossDefinition:The average time duration of traffic loss for all routes
following a Convergence Event until Full Convergence completion, as
observed using the Loss-Derived Method.Discussion:In general the Loss-Derived Loss of Connectivity Period is not
equal to the Loss-Derived Convergence Time. If the DUT continues to
forward traffic to the Preferred Egress Interface after the
Convergence Event is applied then the Loss-Derived Loss of
Connectivity Period will be smaller than the Loss-Derived
Convergence Time. This is also specifically the case after reversing
a failure event.The Loss-Derived Loss of Connectivity Period may be equal to the
Loss-Derived Convergence Time if, as a characteristic of the
Convergence Event, traffic for all routes starts dropping
instantaneously on the Convergence Event Instant. See discussion in
.For the testcases described in each
route's Route Loss of Connectivity Period is expected to be a single
Loss Period .When benchmarking Loss-Derived Loss of Connectivity Period,
Connectivity Packet Loss is measured for all routes and Equation 8
is applied. The calculation is equal to Equation 5 in .Loss-Derived Loss of Connectivity Period SHOULD be measured using
Loss-Derived Method.Measurement Units: secondsIssues: NoneSee Also:Loss-Derived Convergence Time, Loss-Derived Method, Connectivity
Packet LossDefinition:The occurrence of a planned or unplanned event in the network
that will result in a change in the egress interface of the Device
Under Test (DUT) for routed packets.Discussion:Convergence Events include but are not limited to link loss,
routing protocol session loss, router failure, configuration change,
and better next-hop learned via a routing protocol.Measurement Units: N/AIssues: NoneSee Also: Convergence Event InstantDefinition:The number of packets that should have been forwarded by a DUT
under a constant Offered Load that were not forwarded due to lack of
resources.Discussion:Packet Loss is a modified version of the term "Frame Loss Rate"
as defined in . The term "Frame Loss" is
intended for Ethernet Frames while "Packet Loss" is intended for IP
packets.Measurement units: Number of offered packets that are not
forwarded.Issues: NoneSee Also: Convergence Packet LossDefinition:The number of packets lost due to a Convergence Event until Full
Convergence completes, as observed on the Next-Best Egress
Interface.Discussion:Convergence Packet Loss is observed on the Next-Best Egress
Interface. It only needs to be observed for Convergence Events that
do not cause instantaneous traffic loss at Convergence Event
Instant.Convergence Packet Loss includes packets that were lost and
packets that were delayed due to buffering. The magnitude of an
acceptable Forwarding Delay is a parameter of the methodology. If a
maximum acceptable Forwarding Delay threshold is applied it MUST be
reported.Measurement Units: number of packetsIssues: NoneSee Also:Packet Loss, Full Convergence, Convergence Event, Connectivity
Packet LossDefinition:The number of packets lost due to a Convergence Event until Full
Convergence completes.Discussion:Connectivity Packet Loss is observed on all DUT egress
interfaces.Convergence Packet Loss includes packets that were lost and
packets that were delayed due to buffering. The magnitude of an
acceptable Forwarding Delay is a parameter of the methodology. If a
maximum acceptable Forwarding Delay threshold is applied it MUST be
reported.Measurement Units: number of packetsIssues: NoneSee Also:Packet Loss, Route Loss of Connectivity Period, Convergence
Event, Convergence Packet LossDefinition:The interval at which the Tester (test equipment) polls to make
measurements for arriving packets.Discussion:At least one packet per route for all routes matched in the
Offered Load MUST be offered to the DUT within the Packet Sampling
Interval. Metrics measured at the Packet Sampling Interval MUST
include Forwarding Rate and received packets.Packet Sampling Interval can influence the convergence graph as
observed with the Rate-Derived Method. This is particularly true
when implementations complete Full Convergence in less time than the
Packet Sampling Interval. The Convergence Event Instant and First
Route Convergence Instant may not be easily identifiable and the
Rate-Derived Method may produce a larger than actual convergence
time.The recommended value for configuration of the Packet Sampling
Interval when using the Rate-Derived Method is provided in . For the other benchmark methods the value of
the Packet Sampling Interval does not contribute to the measurement
accuracy.Measurement Units: secondsIssues: NoneSee Also: Rate-Derived MethodDefinition:The amount of time for which the completion of Full Convergence
is maintained without additional packet loss.Discussion:The purpose of the Sustained Convergence Validation Time is to
produce convergence benchmarks protected against fluctuation in
Forwarding Rate after the completion of Full Convergence is
observed. The RECOMMENDED Sustained Convergence Validation Time to
be used is 5 seconds. The BMWG selected 5 seconds based upon RFC
2544 which recommends waiting 2 seconds
for residual frames to arrive (this is the Forwarding Delay
threshold for the last packet sent) and 5 seconds for DUT
restabilization.Measurement Units: secondsIssues: NoneSee Also:Full Convergence, Convergence Recovery InstantDefinition:Forwarding of traffic to route entries that no longer exist or to
route entries with next-hops that are no longer preferred.Discussion:Stale Forwarding can be caused by a Convergence Event and can
manifest as a "black-hole" or microloop that produces packet loss,
or out-of-order packets, or delayed packets. Stale Forwarding can
exist until Network Convergence is completed.Measurement Units: N/AIssues: NoneSee Also: Network ConvergenceDefinition:The occurrence of a Convergence Event while the route table is
converging from a prior Convergence Event.Discussion:The Convergence Events for a Nested Convergence Event MUST occur
with different neighbors. A possible observation from a Nested
Convergence Event will be the withdrawal of routes from one neighbor
while the routes of another neighbor are being installed.Measurement Units: N/AIssues: NoneSee Also: Convergence EventBenchmarking activities as described in this memo are limited to
technology characterization using controlled stimuli in a laboratory
environment, with dedicated address space and the constraints specified
in the sections above.The benchmarking network topology will be an independent test setup
and MUST NOT be connected to devices that may forward the test traffic
into a production network, or misroute traffic to the test management
network.Further, benchmarking is performed on a "black-box" basis, relying
solely on measurements observable external to the DUT/SUT.Special capabilities SHOULD NOT exist in the DUT/SUT specifically for
benchmarking purposes. Any implications for network security arising
from the DUT/SUT SHOULD be identical in the lab and in production
networks.This document requires no IANA considerations.Thanks to Sue Hares, Al Morton, Kevin Dubray, Ron Bonica, David Ward,
Peter De Vriendt and the BMWG for their contributions to this work.Benchmarking terminology
for network interconnection devicesHarvard University33 Kirkland StreetWilliam James Hall 1232CambridgeMA02138US+1 617 495 3864SOB@HARVARD.HARVARD.EDUThis memo discusses and defines a number of terms that are used
in describing performance benchmarking tests and the results of
such tests. The terms defined in this memo will be used in
additional memos to define specific benchmarking tests and the
suggested format to be used in reporting the results of each of
the tests. This memo is a product of the Benchmarking Methodology
Working Group (BMWG) of the Internet Engineering Task Force
(IETF).Key words for use in RFCs to Indicate
Requirement LevelsHarvard University1350 Mass. Ave.CambridgeMA 02138- +1 617 495 3864sob@harvard.edu
General
keywordIn many standards track documents several words are used to
signify the requirements in the specification. These words are
often capitalized. This document defines these words as they
should be interpreted in IETF documents. Authors who follow these
guidelines should incorporate this phrase near the beginning of
their document: 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.Note that the force of these words is modified by the
requirement level of the document in which they are used.Benchmarking Methodology
for Network Interconnect DevicesHarvard University1350 Mass. AveRoom 813CambridgeMA02138US+1 617 495 3864+1 617 496 8500sob@harvard.eduNetScout Systems4 Westford Tech Park DriveWestfordMA01886US+1 978 614 4116+1 978 614 4004mcquaidj@netscout.comThis document discusses and defines a number of tests that may
be used to describe the performance characteristics of a network
interconnecting device. In addition to defining the tests this
document also describes specific formats for reporting the results
of the tests. Appendix A lists the tests and conditions that we
believe should be included for specific cases and gives additional
information about testing practices. Appendix B is a reference
listing of maximum frame rates to be used with specific frame
sizes on various media and Appendix C gives some examples of frame
formats to be used in testing.Use of OSI
IS-IS for routing in TCP/IP and dual environmentsDigital Equipment Corporation (DEC)550 King StreetLKG 1-2/A19LittletonMA01460-1289US+1 508 486 5009This RFC specifies an integrated routing protocol, based on the
OSI Intra-Domain IS-IS Routing Protocol, which may be used as an
interior gateway protocol (IGP) to support TCP/IP as well as OSI.
This allows a single routing protocol to be used to support pure
IP environments, pure OSI environments, and dual environments.
This specification was developed by the IS-IS working group of the
Internet Engineering Task Force.The OSI IS-IS protocol has reached a mature state, and is ready
for implementation and operational use. The most recent version of
the OSI IS-IS protocol is contained in ISO DP 10589. The proposed
standard for using IS-IS for support of TCP/IP will therefore make
use of this version (with a minor bug correction, as discussed in
Annex B). We expect that future versions of this proposed standard
will upgrade to the final International Standard version of IS-IS
when available.Comments should be sent to "isis@merit.edu".Benchmarking Terminology
for LAN Switching DevicesEuropean Network Laboratories (ENL)2rue Helene Boucher78286 Guyancourt CedexFrance+ 33 1 39 44 12 05+ 33 1 39 44 12 06bob.mandeville@eunet.fr
Operations
local area networkBenchmarkingOSPF Version 2Ascend Communications, Inc.1 Robbins RoadWestfordMA01886978-952-1367978-392-2075jmoy@casc.com
Routing
open shortest-path first protocolroutingOSPFThis memo documents version 2 of the OSPF protocol. OSPF is a
link-state routing protocol. It is designed to be run internal to
a single Autonomous System. Each OSPF router maintains an
identical database describing the Autonomous System's topology.
From this database, a routing table is calculated by constructing
a shortest- path tree.OSPF recalculates routes quickly in the face of topological
changes, utilizing a minimum of routing protocol traffic. OSPF
provides support for equal-cost multipath. An area routing
capability is provided, enabling an additional level of routing
protection and a reduction in routing protocol traffic. In
addition, all OSPF routing protocol exchanges are
authenticated.The differences between this memo and RFC 2178 are explained in
Appendix G. All differences are backward-compatible in nature.
Implementations of this memo and of RFCs 2178, 1583, and 1247 will
interoperate.Please send comments to ospf@gated.cornell.edu.Terminology for Benchmarking Network-layer Traffic Control
MechanismsThis document describes terminology for the benchmarking of
devices that implement traffic control using packet classification
based on defined criteria. The terminology is to be applied to
measurements made on the data plane to evaluate IP traffic control
mechanisms. Rules for packet classification can be based on any
field in the IP header, such as the Differentiated Services Code
Point (DSCP), or any field in the packet payload, such as port
number. This memo provides information for the Internet
community.Benchmarking Methodology for Link-State IGP Data Plane Route
ConvergenceThis document describes the methodology for benchmarking
Interior Gateway Protocol (IGP) Route Convergence. The methodology
is to be used for benchmarking IGP convergence time through
externally observable (black box) data plane measurements. The
methodology can be applied to any link-state IGP, such as ISIS and
OSPF. Link-State IGP Data Plane Route ConvergenceConsiderations for Benchmarking Link-State IGP Data Plane
Route ConvergenceThis document discusses considerations for benchmarking
Interior Gateway Protocol (IGP) Route Convergence for any
link-state IGP, such as Intermediate System-Intermediate System
(ISIS) and Open-Shorted Path first (OSPF). A companion methodology
document is to be used for benchmarking IGP convergence time
through externally observable (black box) data plane measurements.
A companionOSPF for IPv6This document describes the modifications to OSPF to support
version 6 of the Internet Protocol (IPv6). The fundamental
mechanisms of OSPF (flooding, Designated Router (DR) election,
area support, Short Path First (SPF) calculations, etc.) remain
unchanged. However, some changes have been necessary, either due
to changes in protocol semantics between IPv4 and IPv6, or simply
to handle the increased address size of IPv6. These modifications
will necessitate incrementing the protocol version from version 2
to version 3. OSPF for IPv6 is also referred to as OSPF version 3
(OSPFv3).</t><t> Changes between OSPF for IPv4, OSPF
Version 2, and OSPF for IPv6 as described herein include the
following. Addressing semantics have been removed from OSPF
packets and the basic Link State Advertisements (LSAs). New LSAs
have been created to carry IPv6 addresses and prefixes. OSPF now
runs on a per-link basis rather than on a per-IP-subnet basis.
Flooding scope for LSAs has been generalized. Authentication has
been removed from the OSPF protocol and instead relies on IPv6's
Authentication Header and Encapsulating Security Payload
(ESP).</t><t> Even with larger IPv6 addresses, most
packets in OSPF for IPv6 are almost as compact as those in OSPF
for IPv4. Most fields and packet- size limitations present in OSPF
for IPv4 have been relaxed. In addition, option handling has been
made more flexible.</t><t> All of OSPF for IPv4's
optional capabilities, including demand circuit support and
Not-So-Stubby Areas (NSSAs), are also supported in OSPF for IPv6.
[STANDARDS TRACK]Routing IPv6 with IS-ISThis document specifies a method for exchanging IPv6 routing
information using the IS-IS routing protocol. The described method
utilizes two new TLVs: a reachability TLV and an interface address
TLV to distribute the necessary IPv6 information throughout a
routing domain. Using this method, one can route IPv6 along with
IPv4 and OSI using a single intra-domain routing protocol.
[STANDARDS TRACK]Packet Reordering MetricsOne-way Loss Pattern Sample MetricsA Fine-Grained View of High Performance NetworkingStandardized Active Measurements on a Tier 1 IP
Backbone