draft-ietf-bmwg-igp-dataplane-conv-term-17.txt   draft-ietf-bmwg-igp-dataplane-conv-term-18.txt 
Network Working Group S. Poretsky
Internet Draft Allot Communications
Expires: September 08, 2009
Intended Status: Informational Brent Imhoff
Juniper Networks
March 08, 2009
Terminology for Benchmarking Network Working Group S. Poretsky
Link-State IGP Data Plane Route Convergence Internet-Draft Allot Communications
Intended status: Informational B. Imhoff
Expires: January 14, 2010 Juniper Networks
K. Michielsen
Cisco Systems
July 13, 2009
<draft-ietf-bmwg-igp-dataplane-conv-term-17.txt> Terminology for Benchmarking Link-State IGP Data Plane Route Convergence
draft-ietf-bmwg-igp-dataplane-conv-term-18
Status of this Memo Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79. This document may contain material
from IETF Documents or IETF Contributions published or made publicly
available before November 10, 2008. The person(s) controlling the
copyright in some of this material may not have granted the IETF
Trust the right to allow modifications of such material outside the
IETF Standards Process. Without obtaining an adequate license from
the person(s) controlling the copyright in such materials, this
document may not be modified outside the IETF Standards Process, and
derivative works of it may not be created outside the IETF Standards
Process, except to format it for publication as an RFC or to
translate it into languages other than English.
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 Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
skipping to change at page 1, line 31 skipping to change at page 1, line 41
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "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.
This Internet-Draft will expire on September 8, 2009. This Internet-Draft will expire on January 14, 2010.
Copyright Notice Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the Copyright (c) 2009 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents in effect on the date of Provisions Relating to IETF Documents in effect on the date of
publication of this document (http://trustee.ietf.org/license-info). publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights Please review these documents carefully, as they describe your rights
and restrictions with respect to this document. and restrictions with respect to this document.
ABSTRACT Abstract
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.
Link-State IGP Data Plane Route Convergence 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.
Table of Contents Table of Contents
1. Introduction and Scope........................................3
2. Existing Definitions .........................................4 1. Introduction and Scope . . . . . . . . . . . . . . . . . . . . 4
3. Term Definitions..............................................4 2. Existing Definitions . . . . . . . . . . . . . . . . . . . . . 4
3.1 States 3. Term Definitions . . . . . . . . . . . . . . . . . . . . . . . 4
3.1.1 Route Convergence....................................4 3.1. Convergence Types . . . . . . . . . . . . . . . . . . . . 5
3.1.2 Full Convergence.....................................5 3.1.1. Route Convergence . . . . . . . . . . . . . . . . . . 5
3.1.3 Network Convergence..................................5 3.1.2. Full Convergence . . . . . . . . . . . . . . . . . . . 5
3.1.4 Route-Specific Convergence...........................6 3.1.3. Network Convergence . . . . . . . . . . . . . . . . . 6
3.1.5 Stale Forwarding.....................................6 3.2. Instants . . . . . . . . . . . . . . . . . . . . . . . . . 6
3.2 Events 3.2.1. Convergence Event Instant . . . . . . . . . . . . . . 6
3.2.1 Convergence Event....................................7 3.2.2. Convergence Recovery Instant . . . . . . . . . . . . . 7
3.2.2 Convergence Event Trigger............................7 3.2.3. First Route Convergence Instant . . . . . . . . . . . 7
3.2.3 Convergence Event Instant............................8 3.3. Transitions . . . . . . . . . . . . . . . . . . . . . . . 8
3.2.4 Convergence Recovery Instant.........................8 3.3.1. Convergence Event Transition . . . . . . . . . . . . . 8
3.2.5 First Route Convergence Instant......................9 3.3.2. Convergence Recovery Transition . . . . . . . . . . . 9
3.2.6 Convergence Event Transition.........................9 3.4. Interfaces . . . . . . . . . . . . . . . . . . . . . . . . 9
3.2.7 Convergence Recovery Transition......................10 3.4.1. Local Interface . . . . . . . . . . . . . . . . . . . 9
3.2.8 Nested Convergence Events............................10 3.4.2. Remote Interface . . . . . . . . . . . . . . . . . . . 10
3.3 Interfaces 3.4.3. Preferred Egress Interface . . . . . . . . . . . . . . 10
3.3.1 Local Interface......................................11 3.4.4. Next-Best Egress Interface . . . . . . . . . . . . . . 10
3.3.2 Neighbor Interface...................................11 3.5. Benchmarking Methods . . . . . . . . . . . . . . . . . . . 11
3.3.3 Remote Interface.....................................11 3.5.1. Rate-Derived Method . . . . . . . . . . . . . . . . . 11
3.3.4 Preferred Egress Interface...........................12 3.5.2. Loss-Derived Method . . . . . . . . . . . . . . . . . 12
3.3.5 Next-Best Egress Interface...........................12 3.5.3. Route-Specific Loss-Derived Method . . . . . . . . . . 13
3.4 Benchmarking Method 3.6. Benchmarks . . . . . . . . . . . . . . . . . . . . . . . . 15
3.4.1 Packet Loss..........................................13 3.6.1. Full Convergence Time . . . . . . . . . . . . . . . . 15
3.4.2 Convergence Packet Loss..............................13 3.6.2. First Route Convergence Time . . . . . . . . . . . . . 15
3.4.3 Rate-Derived Convergence Method......................14 3.6.3. Route-Specific Convergence Time . . . . . . . . . . . 16
3.4.4 Loss-Derived Convergence Method......................14 3.6.4. Loss-Derived Convergence Time . . . . . . . . . . . . 18
3.4.5 Packet Sampling Interval.............................15 3.6.5. Route Loss of Connectivity Period . . . . . . . . . . 19
3.5 Benchmarks 3.6.6. Loss-Derived Loss of Connectivity Period . . . . . . . 20
3.5.1 Full Convergence Time................................17 3.7. Measurement Terms . . . . . . . . . . . . . . . . . . . . 21
3.5.2 First Route Convergence Time.........................17 3.7.1. Convergence Event . . . . . . . . . . . . . . . . . . 21
3.5.3 Route-Specific Convergence Time......................17 3.7.2. Packet Loss . . . . . . . . . . . . . . . . . . . . . 21
3.5.4 Sustained Convergence Validation Time................18 3.7.3. Convergence Packet Loss . . . . . . . . . . . . . . . 21
3.5.5 Reversion Convergence Time...........................19 3.7.4. Connectivity Packet Loss . . . . . . . . . . . . . . . 22
4. IANA Considerations...........................................19 3.7.5. Packet Sampling Interval . . . . . . . . . . . . . . . 23
5. Security Considerations.......................................19 3.7.6. Sustained Convergence Validation Time . . . . . . . . 23
6. Acknowledgements..............................................20 3.8. Miscellaneous Terms . . . . . . . . . . . . . . . . . . . 24
7. References....................................................20 3.8.1. Stale Forwarding . . . . . . . . . . . . . . . . . . . 24
8. Author's Address..............................................21 3.8.2. Nested Convergence Event . . . . . . . . . . . . . . . 24
Link-State IGP Data Plane Route Convergence 4. Security Considerations . . . . . . . . . . . . . . . . . . . 25
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 25
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 25
7.1. Normative References . . . . . . . . . . . . . . . . . . . 25
7.2. Informative References . . . . . . . . . . . . . . . . . . 26
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 26
1. Introduction and Scope 1. Introduction and Scope
This draft describes the terminology for benchmarking Interior This draft describes the terminology for benchmarking Link-State
Gateway Protocol (IGP) Route Convergence. The motivation and Interior Gateway Protocol (IGP) Convergence. The motivation and
applicability for this benchmarking is provided in [Po07a]. The applicability for this benchmarking is provided in [Po09a]. The
methodology to be used for this benchmarking is described in [Po07m]. methodology to be used for this benchmarking is described in [Po09m].
The purpose of this document is to introduce new terms required to The purpose of this document is to introduce new terms required to
complete execution of the IGP Route Convergence Methodology [Po07m]. complete execution of the IGP Route Methodology [Po09m].
These terms apply to IPv4 and IPv6 traffic and IGPs.
Convergence times are measured at the Tester on the data plane by IGP convergence time is measured on the data plane at the Tester by
observing packet loss through the DUT. The methodology and observing packet loss through the DUT. The methodology and
terminology to be used for benchmarking Route Convergence can be terminology to be used for benchmarking IGP Convergence can be
applied to any link-state IGP such as ISIS [Ca90] and OSPF [Mo98]. applied to IPv4 and IPv6 traffic and link-state IGPs such as ISIS
The data plane is measured to obtain black-box (externally [Ca90][Ho08], OSPF [Mo98][Co08], and others.
observable) convergence benchmarking metrics. When there is no
packer loss observed in the data plane, the convergence time
SHALL be reported as zero.
An example of Route Convergence as observed and measured from the
data plane is shown in Figure 1. The graph in Figure 1 shows
Forwarding Rate versus Time. Time 0 on the X-axis is on the far
right of the graph. The Offered Load to the ingress interface of
the DUT SHOULD equal the measured Throughput [Ba99][Ma98] of the DUT
and the Forwarding Rate [Ma98] and Convergence Packet Loss is
measured at the Preferred and Next-Best Egress interfaces of the DUT
befire, during, and after a Convergence Event Trigger. These
components of the graph are defined in the Term Definitions section.
Full Convergence-> Convergence Convergence
Recovery Event Event Time=
Instant Instant Trigger 0sec
Forwarding Rate= ^ ^ ^ ^ Offered Load=
Offered Load --> ------\ Packet /----------- <--Max Throughput
\ Loss /<----Convergence
Convergence------->\ / Event Transition
Recovery Transition \ /
\_____/<------Maximum Packet Loss
^
First Route
Convergence Instant
Y-axis = Forwarding Rate
X-axis = Time (increases right to left to match commercial test
equipment displays)
Figure 1. Convergence Graph
Link-State IGP Data Plane Route Convergence
2. Existing Definitions 2. Existing Definitions
This document uses existing terminology defined in other BMWG
work. Examples include, but are not limited to:
Latency [Ref.[Ba91], section 3.8] This document uses existing terminology defined in other BMWG work.
Frame Loss Rate [Ref.[Ba91], section 3.6] Examples include, but are not limited to:
Throughput [Ref.[Ba91], section 3.17]
Frame Loss Rate [Ref.[Br91], section 3.6]
Throughput [Ref.[Br91], section 3.17]
Offered Load [Ref.[Ma98], section 3.5.2]
Forwarding Rate [Ref.[Ma98], section 3.6.1]
Device Under Test (DUT) [Ref.[Ma98], section 3.1.1] Device Under Test (DUT) [Ref.[Ma98], section 3.1.1]
System Under Test (SUT) [Ref.[Ma98], section 3.1.2] System Under Test (SUT) [Ref.[Ma98], section 3.1.2]
Out-of-order Packet [Ref.[Po06], section 3.3.2] Out-of-order Packet [Ref.[Po06], section 3.3.2]
Duplicate Packet [Ref.[Po06], section 3.3.3] Duplicate Packet [Ref.[Po06], section 3.3.3]
Packet Reordering [Ref.[Mo06], section 3.3] Packet Reordering [Ref.[Mo06], section 3.3]
Stream [Ref.[Po06], section 3.3.2]
Flow [Ref.[Po06], section 3.1.5]
Forwarding Delay [Ref.[Po06], section 3.2.4]
Loss Period [Ref.[Ko02], section 4]
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in BCP 14, RFC 2119 document are to be interpreted as described in BCP 14, RFC 2119
[Br97]. RFC 2119 defines the use of these key words to help make the [Br97]. RFC 2119 defines the use of these key words to help make the
intent of standards track documents as clear as possible. While this intent of standards track documents as clear as possible. While this
document uses these keywords, this document is not a standards track document uses these keywords, this document is not a standards track
document. document.
3. Term Definitions 3. Term Definitions
3.1 States 3.1. Convergence Types
3.1.1 Route Convergence
3.1.1. Route Convergence
Definition: Definition:
The action to update all components of the router with the
most recent route change(s) including the Routing The process of updating all components of the router, including the
Information Base (RIB) and Forwarding Information Base (FIB), Routing Information Base (RIB) and Forwarding Information Base (FIB),
along with software and hardware tables, such that forwarding along with software and hardware tables, with the most recent route
is successful for one or more route entries. change(s) such that forwarding for a route entry is successful on the
Next-Best Egress Interface.
Discussion: Discussion:
Route Convergence MUST occur after a Convergence Event.
Route Convergence can be observed externally by the rerouting Route Convergence MUST occur after a Convergence Event. Route
of data traffic to the Next-best Egress Interface. Also, Convergence can be observed externally by the rerouting of data
completion of Route Convergence may or may not be sustained traffic for a destination matching a route entry to the Next-best
over time. Egress Interface. Completion of Route Convergence may or may not be
sustained over time.
Measurement Units: N/A Measurement Units: N/A
Issues: None Issues: None
See Also: See Also:
Network Convergence
Full Convergence
Convergence Event
Link-State IGP Data Plane Route Convergence
3.1.2 Full Convergence Network Convergence, Full Convergence, Convergence Event
3.1.2. Full Convergence
Definition: Definition:
Route Convergence for an entire FIB in which complete recovery
from the Convergence Event is indicated by the DUT throughput Route Convergence for all routes in the FIB.
equal to the offered load.
Discussion: Discussion:
When benchmarking convergence, it is useful to measure
the time to converge an entire FIB. For example,
a Convergence Event can be produced for an OSPF table of
5000 routes so that the time to converge routes 1 through
5000 is measured. Completion of Full Convergence is externally
observable from the data plane when the Throughput of the data
plane traffic on the Next-Best Egress Interface equals the
offered load.
Full Convergence MAY be measured using Rate-Derived Convergence Full Convergence MUST occur after a Convergence Event. Full
Method or calculated using Loss-Derived Convergence Method. Convergence can be observed externally by the rerouting of data
Full Convergence may or may not be sustained over time. The traffic to destinations matching all route entries to the Next-best
Sustained Convergence Validation Time MUST be applied. 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.
Measurement Units: N/A Completion of Full Convergence may or may not be sustained over time.
Measurement Units: N/A
Issues: None Issues: None
See Also: See Also:
Network Convergence
Route Convergence
Convergence Event
3.1.3 Network Convergence Network Convergence, Route Convergence, Convergence Event, Full
Convergence Time, Convergence Recovery Instant
3.1.3. Network Convergence
Definition: Definition:
The process of updating of all routing tables, including
distributed FIBs, in all routers throughout the network. Full Convergence in all routers throughout the network.
Discussion: Discussion:
Network Convergence requires completion of all Route
Convergence operations for all routers in the network following Network Convergence includes all Route Convergence operations for all
a Convergence Event. Completion of Network Convergence can be routers in the network following a Convergence Event.
observed by recovery of System Under Test (SUT) Throughput to
equal the offered load, with no Stale Forwarding, and no Completion of Network Convergence can be observed by recovery of the
Blenders [Ca01][Ci03]. network Forwarding Rate to equal the Offered Load, with no Stale
Forwarding, and no Blenders [Ca01][Ci03].
Completion of Network Convergence may or may not be sustained over
time.
Measurement Units: N/A Measurement Units: N/A
Issues: None Issues: None
Link-State IGP Data Plane Route Convergence
See Also: See Also:
Route Convergence
Stale Forwarding
3.1.4 Route-Specific Convergence Route Convergence, Full Convergence, Stale Forwarding
3.2. Instants
3.2.1. Convergence Event Instant
Definition: Definition:
Route Convergence for one or more specific route entries in
the FIB in which recovery from the Convergence Event is The time instant that a Convergence Event occurs.
indicated when data-plane traffic for the flow [Po06] matching
that route entry(ies) is routed to the Next-Best Egress
Interface.
Discussion: Discussion:
When benchmarking convergence, it is sometimes useful to
measure the time to converge a single flow [Po06] or group of
flows to benchmark convergence time for one or a few route
entries in the FIB instead of the entire FIB. Route-Specific
Convergence of a flow is externally observable from the data
plane when the data plane traffic for that flow is routed to
the Next-Best Egress Interface.
Measurement Units: N/A 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: None Issues: None
See Also: See Also: Convergence Event
Full Convergence
Route Convergence 3.2.2. Convergence Recovery Instant
Convergence Event
3.1.5 Stale Forwarding
Definition: Definition:
Forwarding of traffic to route entries that no longer exist
or to route entries with next-hops that are no longer preferred. The time instant that Full Convergence has completed.
Discussion: Discussion:
Stale Forwarding can be caused by a Convergence Event and can
manifest as a "black-hole" or microloop that produces packet
loss. Stale Forwarding can exist until Network Convergence is
completed. Stale Forwarding cannot be observed with a single
DUT.
Measurement Units: N/A 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: None Issues: None
See Also: See Also:
Network Convergence
Link-State IGP Data Plane Route Convergence
3.2 Events Sustained Convergence Validation Time, Full Convergence
3.2.1 Convergence Event 3.2.3. First Route Convergence Instant
Definition: Definition:
The occurrence of a planned or unplanned event in the network
that results in a change in the egress interface of the Device The time instant the first route entry completes Route Convergence
Under Test (DUT) for routed packets. following a Convergence Event
Discussion: Discussion:
Convergence Events include link loss, routing protocol session
loss, router failure, configuration change, and better next-hop Any route may be the first to complete Route Convergence. The First
learned via a routing protocol. 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: Measurement Units:
N/A
Issues: hh:mm:ss:nnn:uuu, where 'nnn' is milliseconds and 'uuu' is
None microseconds.
See Also: Issues: None
Convergence Packet Loss
Convergence Event Instant
3.2.2 Convergence Event Trigger See Also: Route Convergence
3.3. Transitions
3.3.1. Convergence Event Transition
Definition: Definition:
An action taken by the Tester to produce a Convergence Event.
A time interval following a Convergence Event in which Forwarding
Rate on the Preferred Egress Interface gradually reduces to zero.
Discussion: Discussion:
The Convergence Event Trigger is introduced by the Tester and
may be indicated by link loss, routing protocol session loss,
router failure, configuration change, or a better next-hop
learned via a routing protocol introduced by the Tester.
Measurement Units: The Forwarding Rate during a Convergence Event Transition may not
N/A decrease linearly.
Issues: The Forwarding Rate observed on all DUT egress interfaces may or may
None 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: seconds
Issues: None
See Also: See Also:
Convergence Event
Convergence Packet Loss
Convergence Recovery Instant
Link-State IGP Data Plane Route Convergence
3.2.3 Convergence Event Instant Convergence Event, Rate-Derived Method
3.3.2. Convergence Recovery Transition
Definition: Definition:
The time instant that a Convergence Event becomes observable in
the data plane. 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: Discussion:
Convergence Event Instant is observable from the data
plane as the precise time that the device under test begins
to exhibit packet loss. The Convergence Event Instant is
produced by the Convergence Event Trigger. The Convergence
Event Instant always occurs concurrent or subsequent to the
Tester introducing the Convergence Event Trigger.
Measurement Units: The Forwarding Rate observed during a Convergence Recovery Transition
hh:mm:ss:nnn:uuu, may not increase linearly.
where 'nnn' is milliseconds and 'uuu' is microseconds.
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: seconds
Issues: None Issues: None
See Also: See Also:
Convergence Event
Convergence Packet Loss
Convergence Recovery Instant
3.2.4 Convergence Recovery Instant Full Convergence,First Route Convergence Instant, Rate-Derived Method
3.4. Interfaces
3.4.1. Local Interface
Definition: Definition:
The time instant that Full Convergence completion is
observed. An interface on the DUT.
Discussion: Discussion:
Convergence Recovery Instant is measurable from the data
plane as the precise time that the device under test completes
Full Convergence. The Convergence Recovery Instant MUST be
maintained for an interval of duration equal to the Sustained
Convergence Validation Time.
Measurement Units: A failure of the Local Interface indicates that the failure occurred
hh:mm:ss:nnn:uuu, directly on the DUT.
where 'nnn' is milliseconds and 'uuu' is microseconds.
Issues: Measurement Units: N/A
None
See Also: Issues: None
Sustained Convergence Validation Time
Convergence Packet Loss See Also: Remote Interface
Convergence Event Instant
Link-State IGP Data Plane Route Convergence 3.4.2. Remote Interface
3.2.5 First Route Convergence Instant
Definition: Definition:
The time instant a first route entry has converged
following a Convergence Event, as observed by receipt of An interface on a neighboring router that is not directly connected
the first packet from the Next-Best Egress Interface. to any interface on the DUT.
Discussion: Discussion:
The First Route Convergence Instant is an indication that the
process to achieve Full Convergence has begun. Any route may
be the first to converge for First Route Convergence Instant.
Measurement on the data-plane enables the First Route
Convergence Instant to be observed without any white-box
information from the DUT.
Measurement Units: A failure of a Remote Interface indicates that the failure occurred
hh:mm:ss:nnn:uuu, on a neighbor router's interface that is not directly connected to
where 'nnn' is milliseconds and 'uuu' is microseconds. the DUT.
Issues: Measurement Units: N/A
None
See Also: Issues: None
Route Convergence
Full Convergence See Also: Local Interface
Stale Forwarding
3.4.3. Preferred Egress Interface
3.2.6 Convergence Event Transition
Definition: Definition:
A time interval observed following a Convergence Event in which
Throughput gradually reduces to a minimum value. The outbound interface from the DUT for traffic routed to the
preferred next-hop.
Discussion: Discussion:
The Convergence Event Transition is best observed for Full
Convergence. The egress packet rate observed during a
Convergence Event Transition may not decrease linearly and may
not decrease to zero. Both the offered load and the Packet
Sampling Interval influence the observations of the Convergence
Event Transition. For example, it is possible that if the
Convergence Event were to cause the Throughput [Ba91] to drop
to zero then this may not be observed if the Packet Sampling
Interval is set too high. This is further discussed with the
term "Packet Sampling Interval".
Measurement Units: The Preferred Egress Interface is the egress interface prior to a
seconds Convergence Event.
Measurement Units: N/A
Issues: None Issues: None
Link-State IGP Data Plane Route Convergence
See Also: See Also: Next-Best Egress Interface
Convergence Event
Full Convergence
Packet Sampling Interval
3.2.7 Convergence Recovery Transition 3.4.4. Next-Best Egress Interface
Definition: Definition:
The characteristic of the DUT in which Throughput gradually
increases to equal the offered load. The outbound interface from the DUT for traffic routed to the second-
best next-hop.
Discussion: Discussion:
The Convergence Recovery Transition is best observed for
Full Convergence. The egress packet rate observed during
a Convergence Recovery Transition may not increase linearly.
Both the offered load and the Packet Sampling Interval
influence the observations of the Convergence Recovery
Transition. This is further discussed with the term
"Packet Sampling Interval".
Measurement Units: The Next-Best Egress Interface becomes the egress interface after a
seconds Convergence Event.
The Next-Best Egress Interface is of the same media type and link
speed as the Preferred Egress Interface.
Measurement Units: N/A
Issues: None Issues: None
See Also: See Also: Preferred Egress Interface
Full Convergence
Packet Sampling Interval
3.2.8 Nested Convergence Events 3.5. Benchmarking Methods
3.5.1. Rate-Derived Method
Definition: Definition:
The occurrence of a Convergence Event while the route
table is converging from a prior Convergence Event. The method to calculate convergence time benchmarks from observing
Forwarding Rate each Packet Sampling Interval.
Discussion: Discussion:
The Convergence Events for a Nested Convergence Event
MUST occur with different neighbors. A common Figure 1 shows an example of the Forwarding Rate change in time
observation from a Nested Convergence Event will be during convergence as observed when using the Rate-Derived Method.
the withdrawal of routes from one neighbor while the
routes of another neighbor are being installed. ^ Convergence
Fwd | Recovery
Rate | Instant
| Offered ^
| Load --> ----------\ /-----------
| \ /<--- Convergence
| \ Packet / Recovery
| Convergence --->\ Loss / Transition
| Event \ /
| Transition \---------/ <-- Max Packet Loss
|
+--------------------------------------------------------->
^ ^ time
Convergence First Route
Event Instant Convergence Instant
Figure 1: Rate-Derived Convergence Graph
The Offered Load SHOULD consists of a single Stream [Po06]. 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 in the FIB are matched and each route is offered
an equal share of the total Offered Load.
At least one packet per route in the FIB for all routes in the FIB
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 high.
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 seperately 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/A Measurement Units: N/A
Issues: None Issues: None
See Also: See Also:
Convergence Event
Link-State IGP Data Plane Route Convergence
3.3 Interfaces Packet Sampling Interval, Convergence Event, Convergence Event
Instant, Full Convergence
3.3.1 Local Interface 3.5.2. Loss-Derived Method
Definition: Definition:
An interface on the DUT.
The method to calculate the Loss-Derived Convergence Time and Loss-
Derived Loss of Connectivity Period benchmarks from the amount of
packet loss.
Discussion: Discussion:
A failure of the Local Interface indicates that the failure
occurred directly on the DUT.
Measurement Units: N/A The Offered Load SHOULD consists of a single Stream [Po06]. 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 in the FIB are matched and each route is offered
an equal share of the total Offered Load.
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 a timestamp of
the Convergence Event Instant and the Tester SHOULD observe packet
loss seperately 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: seconds
Issues: None Issues: None
See Also: See Also:
Neighbor Interface
Remote Interface
3.3.2 Neighbor Interface Loss-Derived Convergence Time, Loss-Derived Loss of Connectivity
Period, Convergence Packet Loss
3.5.3. Route-Specific Loss-Derived Method
Definition: Definition:
The interface on the neighbor router or tester that is
directly linked to the DUT's Local Interface. The method to calculate the Route-Specific Convergence Time benchmark
from the amount of packet loss during convergence for a specific
route entry.
Discussion: Discussion:
A failure of a Neighbor Interface indicates that a
failure occurred on a neighbor router's interface that
directly links the neighbor router to the DUT.
Measurement Units: N/A To benchmark Route-Specific Convergence Time, the Tester provides an
Offered Load that consists of multiple Streams [Po06]. Each Stream
has a single destination address matching a different route entry,
for every route entry in the FIB. 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 a timestamp of
the Convergence Event Instant and the Tester SHOULD observe packet
loss seperately 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: seconds
Issues: None Issues: None
See Also: See Also:
Local Interface
Remote Interface
3.3.3 Remote Interface Route-Specific Convergence Time, Route Loss of Connectivity Period,
Convergence Packet Loss
3.6. Benchmarks
3.6.1. Full Convergence Time
Definition: Definition:
An interface on a neighboring router that is not directly
connected to any interface on the DUT. The time duration of the period between the Convergence Event Instant
and the Convergence Recovery Instant as observed using the Rate-
Derived Method.
Discussion: 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.
Link-State IGP Data Plane Route Convergence 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.
Measurement Units: Full Convergence Time =
N/A Convergence Recovery Instant - Convergence Event Instant
Issues: Equation 1
None
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 [Po09m], 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: seconds
Issues: None
See Also: See Also:
Local Interface
Neighbor Interface
3.3.4 Preferred Egress Interface Full Convergence, Rate-Derived Method, Route-Specific Loss-Derived
Method
3.6.2. First Route Convergence Time
Definition: Definition:
The outbound interface from the DUT for traffic routed to the
preferred next-hop. The duration of the period between the Convergence Event Instant and
the First Route Convergence Instant as observed using the Rate-
Derived Method.
Discussion: Discussion:
The Preferred Egress Interface is the egress interface prior
to a Convergence Event.
Measurement Units: Using the Rate-Derived Method, First Route Convergence Time can be
N/A calculated as the time difference between the Convergence Event
Instant and the First Route Convergence Instant, as shown with
Equation 2.
Issues: First Route Convergence Time =
None First Route Convergence Instant - Convergence Event Instant
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 [Po09m], 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: seconds
Issues: None
See Also: See Also:
Next-Best Egress Interface
3.3.5 Next-Best Egress Interface Rate-Derived Method, Route-Specific Loss-Derived Method, First Route
Convergence Instant
3.6.3. Route-Specific Convergence Time
Definition: Definition:
The outbound interface from the DUT for traffic routed to the
second-best next-hop. It is the same media type and link speed The amount of time it takes for Route Convergence to be completed for
as the Preferred Egress Interface a specific route, as calculated from the amount of packet loss during
convergence for a single route entry.
Discussion: Discussion:
The Next-Best Egress Interface becomes the egress interface
after a Convergence Event.
Measurement Units: Route-Specific Convergence Time can only be measured using the Route-
N/A 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
Section 3.6.5.
Route-Specific Convergence Time =
Connectivity Packet Loss for specific route/Offered Load per route
Equation 3
If 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 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.
Route-Specific Convergence Time =
Convergence Packet Loss for specific route/Offered Load per route
- (Convergence Event Instant - start traffic instant)
Equation 4
The Convergence Event Instant and start traffic 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 [Po09m].
Measurement Units: seconds
Issues: None Issues: None
See Also: See Also:
Preferred Egress Interface
Link-State IGP Data Plane Route Convergence
3.4 Benchmarking Methods
3.4.1 Packet Loss Convergence Event, Convergence Packet Loss, Connectivity Packet Loss,
Route Convergence
3.6.4. Loss-Derived Convergence Time
Definition: Definition:
The number of packets that should have been forwarded
by a DUT under a constant offered load that were The average Route Convergence time for all routes in FIB, as
not forwarded due to lack of resources. calculated from the amount of packet loss during convergence.
Discussion: Discussion:
Packet Loss is a modified version of the term "Frame Loss Rate"
as defined in [Ba91]. The term "Frame Loss" is intended for
Ethernet Frames while "Packet Loss" is intended for IP packets.
Packet Loss can be measured as a reduction in forwarded traffic
from the Throughput [Ba91] of the DUT.
Measurement units: Loss-Derived Convergence Time is measured using the Loss-Derived
Number of offered packets that are not forwarded. 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.
Loss-Derived Convergence Time =
Connectivity Packet Loss/Offered Load
Equation 5
If 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 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.
Loss-Derived Convergence Time =
Convergence Packet Loss/Offered Load
- (Convergence Event Instant - start traffic instant)
Equation 6
The Convergence Event Instant and start traffic instant SHOULD be
collected by the Tester.
Measurement Units: seconds
Issues: None Issues: None
See Also: See Also:
Convergence Packet Loss
3.4.2 Convergence Packet Loss Convergence Packet Loss, Connectivity Packet Loss, Route Convergence
3.6.5. Route Loss of Connectivity Period
Definition: Definition:
The number of packets lost due to a Convergence Event
until Full Convergence completes. 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: Discussion:
Convergence Packet Loss includes packets that were lost and
packets that were delayed due to buffering. The Convergence
Packet Loss observed in a Packet Sampling Interval may or may
not be equal to the number of packets in the offered load
during the interval following a Convergence Event (see Figure
1).
Measurement Units: In general the Route Loss of Connectivity Period is not equal to the
number of packets 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, as a characteristic of the Convergence
Event, traffic for all routes starts dropping instantaneously on the
Convergence Event Instant. See discussion in [Po09m].
For the testcases described in [Po09m] the Route Loss of Connectivity
Period is expected to be a single Loss Period [Ko02].
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
Section 3.6.3.
Route Loss of Connectivity Period =
Connectivity Packet Loss for specific route/Offered Load per route
Equation 7
Route Loss of Connectivity Period SHOULD be measured using Route-
Specific Loss-Derived Method.
Measurement Units: seconds
Issues: None Issues: None
See Also: See Also:
Packet Loss
Route Convergence
Convergence Event
Packet Sampling Interval
Link-State IGP Data Plane Route Convergence
3.4.3 Rate-Derived Convergence Method Route-Specific Convergence Time, Route-Specific Loss-Derived Method,
Definition: Connectivity Packet Loss
The method to calculate convergence time benchmarks from the
amount of time that Convergence Packet Loss persists upon
occurrence of a Convergence Event.
Rate-Derived Convergence Method can be calculated as the time 3.6.6. Loss-Derived Loss of Connectivity Period
difference from the Convergence Event Instant to the
Convergence Recovery Instant, as shown with Equation 1.
(Equation 1) Definition:
Rate-Derived Convergence Method =
Convergence Recovery Instant - Convergence Event Instant. 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: Discussion:
It is RECOMMENDED that the Rate-Derived Convergence Method be
measured when benchmarking convergence times. The Rate-Derived
Convergence Method SHOULD be measured with an Offered Load at
the Throughput of the DUT. At least one packet per route
in the FIB for all routes in the FIB MUST be offered to the DUT
within the Packet Sampling Interval.
It is possible to measure no packet loss, which results in a In general the Loss-Derived Loss of Connectivity Period is not equal
Rate-Derived Convergence Time benchmark of zero. Failure to to the Loss-Derived Convergence Time. If the DUT continues to
achieve Full Convergence results in a Rate-Derived Convergence forward traffic to the Preferred Egress Interface after the
Time benchmark of infinity. 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.
Measurement Units: The Loss-Derived Loss of Connectivity Period may be equal to the
seconds 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
[Po09m].
For the testcases described in [Po09m] each route's Route Loss of
Connectivity Period is expected to be a single Loss Period [Ko02].
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 Section 3.6.4.
Loss-Derived Loss of Connectivity Period =
Connectivity Packet Loss for all routes/Offered Load
Equation 8
Loss-Derived Loss of Connectivity Period SHOULD be measured using
Loss-Derived Method.
Measurement Units: seconds
Issues: None Issues: None
See Also: See Also:
Convergence Packet Loss
Convergence Recovery Instant
Convergence Event Instant
Full Convergence
3.4.4 Loss-Derived Convergence Method Loss-Derived Convergence Time, Loss-Derived Method, Connectivity
Packet Loss
3.7. Measurement Terms
3.7.1. Convergence Event
Definition: Definition:
The method to calculate convergence time benchmarks from the
amount of Convergence Packet Loss. Loss-Derived Convergence
Method can be calculated from Convergence Packet Loss as shown
with Equation 2.
Equation 2 - The occurrence of a planned or unplanned event in the network that
Loss-Derived Convergence Method = will result in a change in the egress interface of the Device Under
Convergence Packets Loss / Offered Load Test (DUT) for routed packets.
where units are packets / packets/second = seconds
Link-State IGP Data Plane Route Convergence
Discussion: Discussion:
Ideally, the Convergence Event Transition and Convergence
Recovery Transition are instantaneous so that the Rate-Derived
Convergence Method = Loss-Derived Convergence Method. However,
router implementations are less than ideal. Loss-Derived
Convergence Method gives a better than actual result when
converging many routes simultaneously because it ignores the
transitions. The Rate-Derived Convergence Method takes the
transitions into account.
Equation 2 calculates the average convergence time over all Convergence Events include but are not limited to link loss, routing
routes to which packets have been sent. The average convergence protocol session loss, router failure, configuration change, and
time is often lower than the maximum convergence time better next-hop learned via a routing protocol.
over all routes, so it can produce a result that is faster than
the actual convergence time.. Therefore, Loss-Derived
Convergence Method is not the preferred method to measure
convergence benchmarks. For these reasons the RECOMMENDED
method to obtain a benchmark metric for convergence time is the
Rate-Derived Convergence Method.
Measurement Units: Measurement Units: N/A
seconds
Issues: None Issues: None
See Also: See Also: Convergence Event Instant
Convergence Packet Loss
Rate-Derived Convergence Method 3.7.2. Packet Loss
Route-Specific Convergence
Convergence Event Transition
Convergence Recovery Transition
3.4.5 Packet Sampling Interval
Definition: Definition:
The interval at which the tester (test equipment) polls to make
measurements for arriving packet flows. 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: Discussion:
At least one packet per route in the FIB for all routes in the
FIB MUST be offered to the DUT within the Packet Sampling
Interval. Metrics measured at the Packet Sampling Interval
MUST include Forwarding Rate and Convergence Packet Loss.
Packet Sampling Interval can influence the Convergence Graph. Packet Loss is a modified version of the term "Frame Loss Rate" as
This is particularly true when implementations complete Full defined in [Br91]. The term "Frame Loss" is intended for Ethernet
Convergence in less time than the Packet Sampling Interval. The Frames while "Packet Loss" is intended for IP packets.
Convergence Event Transition and Convergence Recovery Transition
Link-State IGP Data Plane Route Convergence
can become exaggerated when the Packet Sampling Interval is too Measurement units:
long. In this condition, the Rate-Derived Convergence Method
may produce a larger than actual convergence time. In such
cases the Loss-Derived Convergence Method may produce a more
accurate result. The recommended value for configuration of
the Packet Sampling Interval is provided in [Po07m].
Measurement Units: seconds Number of offered packets that are not forwarded.
Issues: None Issues: None
See Also: See Also: Convergence Packet Loss
Convergence Packet Loss
Convergence Event Transition
Convergence Recovery Transition
3.5 Benchmarks
3.5.1 Full Convergence Time 3.7.3. Convergence Packet Loss
Definition: Definition:
The amount of time it takes for Full Convergence to occur.
The number of packets lost due to a Convergence Event until Full
Convergence completes, as observed on the Next-Best Egress Interface.
Discussion: Discussion:
Full Convergence Time can be determined using the Rate-Derived
Convergence Method or Loss-Derived Convergence Method. The
Rate-Derived Convergence Method is RECOMMENDED. When
measuring Route-Specific Convergence Time, there may be
conditions in which the maximum Route Specific Convergence Time
can be reported as the Full Convergence Time. Full Convergence
may or may not be sustained over time. The Sustained
Convergence Validation Time MUST be applied.
Measurement Units: Convergence Packet Loss is observed on the Next-Best Egress
seconds 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 packets
Issues: None Issues: None
See Also: See Also:
Full Convergence
Rate-Derived Convergence Method
Loss-Derived Convergence Method
3.5.2 First Route Convergence Time Packet Loss, Full Convergence, Convergence Event, Connectivity Packet
Loss
3.7.4. Connectivity Packet Loss
Definition: Definition:
The amount of time for Convergence Packet Loss until the
convergence of a first route entry on the Next-Best Egress
Interface, as indicated by the First Route Convergence
Instant.
Link-State IGP Data Plane Route Convergence The number of packets lost due to a Convergence Event until Full
Convergence completes.
Discussion: Discussion:
The First Route Convergence Time benchmarking metric can be
measured when benchmarking either Full Convergence or
Route-Specific Convergence. When benchmarking Full Convergence,
First Route Convergence Time can be measured as the time
difference from the Convergence Event Instant and the First
Route Convergence Instant, as shown with Equation 4a.
(Equation 4a) Connectivity Packet Loss is observed on all DUT egress interfaces.
First Route Convergence Time =
First Route Convergence Instant - Convergence Event Instant
First Route Convergence Time should be measured at the maximum Convergence Packet Loss includes packets that were lost and packets
Throughput of the DUT. At least one packet per route in the FIB that were delayed due to buffering. The magnitude of an acceptable
for all routes in the FIB MUST be offered to the DUT within the Forwarding Delay is a parameter of the methodology. If a maximum
Packet Sampling Interval. Failure to achieve the First Route acceptable Forwarding Delay threshold is applied it MUST be reported.
Convergence Instant results in a First Route Convergence Time
benchmark of infinity.
Measurement Units: Measurement Units: number of packets
seconds
Issues: None Issues: None
See Also: See Also:
Packet Loss, Route Loss of Connectivity Period, Convergence Event,
Convergence Packet Loss Convergence Packet Loss
First Route Convergence Instant
3.5.3 Route-Specific Convergence Time 3.7.5. Packet Sampling Interval
Definition: Definition:
The amount of time it takes for Route-Specific Convergence to
be completed as calculated from the amount of Convergence
Packet Loss for the flow associated to a specific route.
Route-Specific Convergence Time can be calculated from
Convergence Packet Loss as shown with Equation 3.
(Equation 3) Route-Specific Convergence Time = The interval at which the Tester (test equipment) polls to make
Convergence Packets Loss / Offered Load measurements for arriving packets.
where units are packets / packets/second = seconds
Link-State IGP Data Plane Route Convergence
Discussion: Discussion:
It is possible to provide an offered load that has flows
matching every route entry in the FIB and benchmarking
Route-Specific Convergence Time for all route entries. The
number of flows that can be measured is dependent upon the flow
measurement capabilities of the Tester. When benchmarking
Route-Specific Convergence, Convergence Packet Loss is measured
for specific flow(s) and Equation 3 is applied for each flow.
Each flow has a single destination address matching a different
route entry. The fastest measurable convergence time is equal
to the time between two consecutive packets of a flow offered
by the Tester. In practice, the fastest measurable
convergence time is the Packet Sampling Interval of the Tester.
The Route-Specific Convergence Time benchmarks enable minimum, At least one packet per route in the FIB for all routes MUST be
maximum, average, and median convergence time measurements to be offered to the DUT within the Packet Sampling Interval. Metrics
reported by comparing the results for the different route measured at the Packet Sampling Interval MUST include Forwarding Rate
entries. It also enables benchmarking of convergence time when and received packets.
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 [Po07m].
Measurement Units: Packet Sampling Interval can influence the Convergence Graph as
seconds 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.
Issues: The recommended value for configuration of the Packet Sampling
None Interval when using the Rate-Derived Method is provided in [Po09m].
For the other benchmark methods the value of the Packet Sampling
Interval does not contribute to the measurement accuracy.
See Also: Measurement Units: seconds
Convergence Event
Convergence Packet Loss Issues: None
Route-Specific Convergence
See Also: Rate-Derived Method
3.7.6. Sustained Convergence Validation Time
3.5.4 Sustained Convergence Validation Time
Definition: Definition:
The amount of time for which the completion of Full
Convergence is maintained without additional packet loss. The amount of time for which the completion of Full Convergence is
maintained without additional packet loss.
Discussion: Discussion:
The purpose of the Sustained Convergence Validation Time is to
produce Convergence benchmarks protected against fluctuation
in Throughput 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 [Ba99] which recommends waiting 2 seconds
for residual frames to arrive and 5 seconds for DUT
restabilization.
Link-State IGP Data Plane Route Convergence 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 [Br99]
which recommends waiting 2 seconds for residual frames to arrive and
5 seconds for DUT restabilization.
Measurement Units: Measurement Units: seconds
seconds
Issues: None Issues: None
See Also: See Also:
Full Convergence
Convergence Recovery Instant
3.5.5 Reversion Convergence Time Full Convergence, Convergence Recovery Instant
3.8. Miscellaneous Terms
3.8.1. Stale Forwarding
Definition: Definition:
The amount of time for the DUT to complete Full Convergence
to the Preferred Egress Interface, instead of the Next-Best Forwarding of traffic to route entries that no longer exist or to
Egress Interface, upon recovery from a Convergence Event. route entries with next-hops that are no longer preferred.
Discussion: Discussion:
Reversion Convergence Time is the amount of time for Full
Convergence to the original egress interface. This is
achieved by recovering from the Convergence Event, such as
restoring the failed link. Reversion Convergence Time
can be measured using the Rate-Derived Convergence Method
or Loss-Derived Convergence Method. The Rate-Derived
Convergence Method is RECOMMENDED. It is possible to have
the Reversion Convergence Time differ from the Full
Convergence Time.
Measurement Units: seconds 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/A
Issues: None Issues: None
See Also: See Also: Network Convergence
Preferred Egress Interface
Convergence Event
Rate-Derived Convergence Method
4. IANA Considerations 3.8.2. Nested Convergence Event
This document requires no IANA considerations. Definition:
5. Security Considerations 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/A
Issues: None
See Also: Convergence Event
4. Security Considerations
Documents of this type do not directly affect the security of Documents of this type do not directly affect the security of
Internet or corporate networks as long as benchmarking is not Internet or corporate networks as long as benchmarking is not
performed on devices or systems connected to production networks. performed on devices or systems connected to production networks.
Security threats and how to counter these in SIP and the media Security threats and how to counter these in SIP and the media layer
layer is discussed in RFC3261, RFC3550, and RFC3711 and various is discussed in RFC3261, RFC3550, and RFC3711 and various other
other drafts. This document attempts to formalize a set of drafts. This document attempts to formalize a set of common
common terminology for benchmarking IGP convergence performance methodology for benchmarking IGP convergence performance in a lab
in a lab environment. environment.
Link-State IGP Data Plane Route Convergence 5. IANA Considerations
This document requires no IANA considerations.
6. Acknowledgements 6. Acknowledgements
Thanks to Sue Hares, Al Morton, Kevin Dubray, Ron Bonica, David Ward, Thanks to Sue Hares, Al Morton, Kevin Dubray, Ron Bonica, David Ward,
Kris Michielsen and the BMWG for their contributions to this work. Peter De Vriendt and the BMWG for their contributions to this work.
7. References 7. References
7.1 Normative References
[Ba91] Bradner, S. "Benchmarking Terminology for Network
Interconnection Devices", RFC1242, July 1991.
[Ba99] Bradner, S. and McQuaid, J., "Benchmarking 7.1. Normative References
Methodology for Network Interconnect Devices",
RFC 2544, March 1999. [Br91] Bradner, S., "Benchmarking terminology for network
interconnection devices", RFC 1242, July 1991.
[Br97] Bradner, S., "Key words for use in RFCs to Indicate [Br97] Bradner, S., "Key words for use in RFCs to Indicate
[Ca90] Callon, R., "Use of OSI IS-IS for Routing in TCP/IP and Dual Requirement Levels", BCP 14, RFC 2119, March 1997.
Environments", RFC 1195, December 1990.
[Ma98] Mandeville, R., "Benchmarking Terminology for LAN [Br99] Bradner, S. and J. McQuaid, "Benchmarking Methodology for
Switching Devices", RFC 2285, February 1998. Network Interconnect Devices", RFC 2544, March 1999.
[Mo98] Moy, J., "OSPF Version 2", RFC 2328, IETF, April 1998. [Ca90] Callon, R., "Use of OSI IS-IS for routing in TCP/IP and dual
environments", RFC 1195, December 1990.
[Mo06] Morton, A., et al, "Packet Reordering Metrics", RFC 4737, [Co08] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF for
November 2006. IPv6", RFC 5340, July 2008.
[Po06] Poretsky, S., et al., "Terminology for Benchmarking [Ho08] Hopps, C., "Routing IPv6 with IS-IS", RFC 5308,
Network-layer Traffic Control Mechanisms", RFC 4689, October 2008.
[Ko02] Koodli, R. and R. Ravikanth, "One-way Loss Pattern Sample
Metrics", RFC 3357, August 2002.
[Ma98] Mandeville, R., "Benchmarking Terminology for LAN Switching
Devices", RFC 2285, February 1998.
[Mo06] Morton, A., Ciavattone, L., Ramachandran, G., Shalunov, S.,
and J. Perser, "Packet Reordering Metrics", RFC 4737,
November 2006. November 2006.
[Po07a] Poretsky, S., "Benchmarking Applicability for Link-State [Mo98] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998.
[Po06] Poretsky, S., Perser, J., Erramilli, S., and S. Khurana,
"Terminology for Benchmarking Network-layer Traffic Control
Mechanisms", RFC 4689, October 2006.
[Po09a] Poretsky, S., "Considerations for Benchmarking Link-State
IGP Data Plane Route Convergence", IGP Data Plane Route Convergence",
draft-ietf-bmwg-igp-dataplane-conv-app-17, work in progress, draft-ietf-bmwg-igp-dataplane-conv-app-17 (work in
March 2009. progress), March 2009.
[Po07m] Poretsky, S. and Imhoff, B., "Benchmarking Methodology for [Po09m] Poretsky, S. and B. Imhoff, "Benchmarking Methodology for
Link-State IGP Data Plane Route Convergence", Link-State IGP Data Plane Route Convergence",
draft-ietf-bmwg-igp-dataplane-conv-meth-17, work in progress, draft-ietf-bmwg-igp-dataplane-conv-meth-18 (work in
March 2009. progress), July 2009.
7.2 Informative References 7.2. Informative References
[Ca01] S. Casner, C. Alaettinoglu, and C. Kuan, "A Fine-Grained View
of High Performance Networking", NANOG 22, June 2001.
[Ci03] L. Ciavattone, A. Morton, and G. Ramachandran, "Standardized [Ca01] Casner, S., Alaettinoglu, C., and C. Kuan, "A Fine-Grained
Active Measurements on a Tier 1 IP Backbone", IEEE View of High Performance Networking", NANOG 22, June 2001.
Communications Magazine, pp90-97, May 2003.
Link-State IGP Data Plane Route Convergence [Ci03] Ciavattone, L., Morton, A., and G. Ramachandran,
"Standardized Active Measurements on a Tier 1 IP Backbone",
IEEE Communications Magazine p90-97, May 2003.
8. Author's Address Authors' Addresses
Scott Poretsky Scott Poretsky
Allot Communications Allot Communications
67 South Bedford Street, Suite 400 67 South Bedford Street, Suite 400
Burlington, MA 01803 Burlington, MA 01803
USA USA
Phone: + 1 508 309 2179 Phone: + 1 508 309 2179
Email: sporetsky@allot.com Email: sporetsky@allot.com
Brent Imhoff Brent Imhoff
Juniper Networks Juniper Networks
1194 North Mathilda Ave 1194 North Mathilda Ave
Sunnyvale, CA 94089 Sunnyvale, CA 94089
USA USA
Phone: + 1 314 378 2571 Phone: + 1 314 378 2571
EMail: bimhoff@planetspork.com Email: bimhoff@planetspork.com
Kris Michielsen
Cisco Systems
6A De Kleetlaan
Diegem, BRABANT 1831
Belgium
Email: kmichiel@cisco.com
 End of changes. 207 change blocks. 
628 lines changed or deleted 832 lines changed or added

This html diff was produced by rfcdiff 1.35. The latest version is available from http://tools.ietf.org/tools/rfcdiff/