 1/draftietfbmwgigpdataplaneconvterm19.txt 20100308 21:10:53.000000000 +0100
+++ 2/draftietfbmwgigpdataplaneconvterm20.txt 20100308 21:10:53.000000000 +0100
@@ 1,124 +1,131 @@
Network Working Group S. Poretsky
InternetDraft Allot Communications
Intended status: Informational B. Imhoff
Expires: April 29, 2010 Juniper Networks
+Expires: September 9, 2010 Juniper Networks
K. Michielsen
Cisco Systems
 October 26, 2009
+ March 8, 2010
Terminology for Benchmarking LinkState IGP Data Plane Route Convergence
 draftietfbmwgigpdataplaneconvterm19
+ draftietfbmwgigpdataplaneconvterm20
+
+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 linkstate IGP, such as ISIS and OSPF.
Status of this Memo
This InternetDraft is submitted to IETF in full conformance with the
 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.
+ provisions of BCP 78 and BCP 79.
InternetDrafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet
Drafts.
InternetDrafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use InternetDrafts as reference
material or to cite them other than as "work in progress."
The list of current InternetDrafts can be accessed at
http://www.ietf.org/ietf/1idabstracts.txt.
The list of InternetDraft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
 This InternetDraft will expire on April 29, 2010.
+ This InternetDraft will expire on September 9, 2010.
Copyright Notice
 Copyright (c) 2009 IETF Trust and the persons identified as the
+ Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
 Provisions Relating to IETF Documents in effect on the date of
 publication of this document (http://trustee.ietf.org/licenseinfo).
 Please review these documents carefully, as they describe your rights
 and restrictions with respect to this document.

Abstract
+ Provisions Relating to IETF Documents
+ (http://trustee.ietf.org/licenseinfo) in effect on the date of
+ publication of this document. Please review these documents
+ carefully, as they describe your rights and restrictions with respect
+ to this document. Code Components extracted from this document must
+ include Simplified BSD License text as described in Section 4.e of
+ the Trust Legal Provisions and are provided without warranty as
+ described in the BSD License.
 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 linkstate IGP, such as ISIS and OSPF.
+ 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.
Table of Contents
 1. Introduction and Scope . . . . . . . . . . . . . . . . . . . . 4
 2. Existing Definitions . . . . . . . . . . . . . . . . . . . . . 4
 3. Term Definitions . . . . . . . . . . . . . . . . . . . . . . . 4
 3.1. Convergence Types . . . . . . . . . . . . . . . . . . . . 5
 3.1.1. Route Convergence . . . . . . . . . . . . . . . . . . 5
 3.1.2. Full Convergence . . . . . . . . . . . . . . . . . . . 5
 3.1.3. Network Convergence . . . . . . . . . . . . . . . . . 6
 3.2. Instants . . . . . . . . . . . . . . . . . . . . . . . . . 6
 3.2.1. Traffic Start Instant . . . . . . . . . . . . . . . . 6
 3.2.2. Convergence Event Instant . . . . . . . . . . . . . . 7
 3.2.3. Convergence Recovery Instant . . . . . . . . . . . . . 7
 3.2.4. First Route Convergence Instant . . . . . . . . . . . 8
+ 1. Introduction and Scope . . . . . . . . . . . . . . . . . . . . 5
+ 2. Existing Definitions . . . . . . . . . . . . . . . . . . . . . 5
+ 3. Term Definitions . . . . . . . . . . . . . . . . . . . . . . . 5
+ 3.1. Convergence Types . . . . . . . . . . . . . . . . . . . . 6
+ 3.1.1. Route Convergence . . . . . . . . . . . . . . . . . . 6
+ 3.1.2. Full Convergence . . . . . . . . . . . . . . . . . . . 6
+ 3.1.3. Network Convergence . . . . . . . . . . . . . . . . . 7
+ 3.2. Instants . . . . . . . . . . . . . . . . . . . . . . . . . 7
+ 3.2.1. Traffic Start Instant . . . . . . . . . . . . . . . . 7
+ 3.2.2. Convergence Event Instant . . . . . . . . . . . . . . 8
+ 3.2.3. Convergence Recovery Instant . . . . . . . . . . . . . 8
+ 3.2.4. First Route Convergence Instant . . . . . . . . . . . 9
3.3. Transitions . . . . . . . . . . . . . . . . . . . . . . . 9
3.3.1. Convergence Event Transition . . . . . . . . . . . . . 9
 3.3.2. Convergence Recovery Transition . . . . . . . . . . . 9
 3.4. Interfaces . . . . . . . . . . . . . . . . . . . . . . . . 10
 3.4.1. Local Interface . . . . . . . . . . . . . . . . . . . 10
 3.4.2. Remote Interface . . . . . . . . . . . . . . . . . . . 10
+ 3.3.2. Convergence Recovery Transition . . . . . . . . . . . 10
+ 3.4. Interfaces . . . . . . . . . . . . . . . . . . . . . . . . 11
+ 3.4.1. Local Interface . . . . . . . . . . . . . . . . . . . 11
+ 3.4.2. Remote Interface . . . . . . . . . . . . . . . . . . . 11
3.4.3. Preferred Egress Interface . . . . . . . . . . . . . . 11
 3.4.4. NextBest Egress Interface . . . . . . . . . . . . . . 11
 3.5. Benchmarking Methods . . . . . . . . . . . . . . . . . . . 11
 3.5.1. RateDerived Method . . . . . . . . . . . . . . . . . 11
 3.5.2. LossDerived Method . . . . . . . . . . . . . . . . . 13
 3.5.3. RouteSpecific LossDerived Method . . . . . . . . . . 14
 3.6. Benchmarks . . . . . . . . . . . . . . . . . . . . . . . . 15
 3.6.1. Full Convergence Time . . . . . . . . . . . . . . . . 15
 3.6.2. First Route Convergence Time . . . . . . . . . . . . . 16
 3.6.3. RouteSpecific Convergence Time . . . . . . . . . . . 17
 3.6.4. LossDerived Convergence Time . . . . . . . . . . . . 18
 3.6.5. Route Loss of Connectivity Period . . . . . . . . . . 19
 3.6.6. LossDerived Loss of Connectivity Period . . . . . . . 20
 3.7. Measurement Terms . . . . . . . . . . . . . . . . . . . . 21
 3.7.1. Convergence Event . . . . . . . . . . . . . . . . . . 21
 3.7.2. Packet Loss . . . . . . . . . . . . . . . . . . . . . 22
 3.7.3. Convergence Packet Loss . . . . . . . . . . . . . . . 22
 3.7.4. Connectivity Packet Loss . . . . . . . . . . . . . . . 23
 3.7.5. Packet Sampling Interval . . . . . . . . . . . . . . . 23
 3.7.6. Sustained Convergence Validation Time . . . . . . . . 24
 3.8. Miscellaneous Terms . . . . . . . . . . . . . . . . . . . 24
 3.8.1. Stale Forwarding . . . . . . . . . . . . . . . . . . . 24
 3.8.2. Nested Convergence Event . . . . . . . . . . . . . . . 25
 4. Security Considerations . . . . . . . . . . . . . . . . . . . 25
 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26
 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 26
 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 26
 7.1. Normative References . . . . . . . . . . . . . . . . . . . 26
 7.2. Informative References . . . . . . . . . . . . . . . . . . 27
 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 27
+ 3.4.4. NextBest Egress Interface . . . . . . . . . . . . . . 12
+ 3.5. Benchmarking Methods . . . . . . . . . . . . . . . . . . . 12
+ 3.5.1. RateDerived Method . . . . . . . . . . . . . . . . . 12
+ 3.5.2. LossDerived Method . . . . . . . . . . . . . . . . . 14
+ 3.5.3. RouteSpecific LossDerived Method . . . . . . . . . . 16
+ 3.6. Benchmarks . . . . . . . . . . . . . . . . . . . . . . . . 17
+ 3.6.1. Full Convergence Time . . . . . . . . . . . . . . . . 17
+ 3.6.2. First Route Convergence Time . . . . . . . . . . . . . 17
+ 3.6.3. RouteSpecific Convergence Time . . . . . . . . . . . 18
+ 3.6.4. LossDerived Convergence Time . . . . . . . . . . . . 20
+ 3.6.5. Route Loss of Connectivity Period . . . . . . . . . . 21
+ 3.6.6. LossDerived Loss of Connectivity Period . . . . . . . 22
+ 3.7. Measurement Terms . . . . . . . . . . . . . . . . . . . . 23
+ 3.7.1. Convergence Event . . . . . . . . . . . . . . . . . . 23
+ 3.7.2. Packet Loss . . . . . . . . . . . . . . . . . . . . . 23
+ 3.7.3. Convergence Packet Loss . . . . . . . . . . . . . . . 23
+ 3.7.4. Connectivity Packet Loss . . . . . . . . . . . . . . . 24
+ 3.7.5. Packet Sampling Interval . . . . . . . . . . . . . . . 25
+ 3.7.6. Sustained Convergence Validation Time . . . . . . . . 25
+ 3.7.7. Forwarding Delay Threshold . . . . . . . . . . . . . . 26
+ 3.8. Miscellaneous Terms . . . . . . . . . . . . . . . . . . . 26
+ 3.8.1. Stale Forwarding . . . . . . . . . . . . . . . . . . . 26
+ 3.8.2. Nested Convergence Event . . . . . . . . . . . . . . . 27
+ 4. Security Considerations . . . . . . . . . . . . . . . . . . . 27
+ 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28
+ 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 28
+ 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 28
+ 7.1. Normative References . . . . . . . . . . . . . . . . . . . 28
+ 7.2. Informative References . . . . . . . . . . . . . . . . . . 29
+ Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 29
1. Introduction and Scope
This draft describes the terminology for benchmarking LinkState
Interior Gateway Protocol (IGP) Convergence. The motivation and
applicability for this benchmarking is provided in [Po09a]. The
methodology to be used for this benchmarking is described in [Po09m].
The purpose of this document is to introduce new terms required to
complete execution of the IGP Route Methodology [Po09m].
@@ 132,25 +139,26 @@
This document uses existing terminology defined in other BMWG work.
Examples include, but are not limited to:
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]
System Under Test (SUT) [Ref.[Ma98], section 3.1.2]
 Outoforder Packet [Ref.[Po06], section 3.3.2]
 Duplicate Packet [Ref.[Po06], section 3.3.3]
+ OutofOrder Packet [Ref.[Po06], section 3.3.4]
+ Duplicate Packet [Ref.[Po06], section 3.3.5]
Packet Reordering [Ref.[Mo06], section 3.3]
Stream [Ref.[Po06], section 3.3.2]
Forwarding Delay [Ref.[Po06], section 3.2.4]
+ Jitter [Ref.[Po06], section 3.2.5]
Loss Period [Ref.[Ko02], 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
[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
document uses these keywords, this document is not a standards track
document.
@@ 299,25 +307,20 @@
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
NextBest Egress Interface.
 When using the RateDerived Method, the Convergence Recovery Instant
 falls within the Packet Sampling Interval preceding the first
 interval where the observed Forwarding Rate on the NextBest Egress
 Interface equals the Offered Load.

Measurement Units:
hh:mm:ss:nnn:uuu, where 'nnn' is milliseconds and 'uuu' is
microseconds.
Issues: None
See Also:
Sustained Convergence Validation Time, Full Convergence
@@ 462,23 +465,20 @@
Definition:
The outbound interface from the DUT for traffic routed to the second
best nexthop.
Discussion:
The NextBest Egress Interface becomes the egress interface after a
Convergence Event.
 The NextBest Egress Interface is of the same media type and link
 speed as the Preferred Egress Interface.

Measurement Units: N/A
Issues: None
See Also: Preferred Egress Interface
3.5. Benchmarking Methods
3.5.1. RateDerived Method
@@ 516,28 +516,49 @@
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.
+ For maximum accuracy the value for the Packet Sampling Interval
+ SHOULD be as small as possible, but the presence of Jitter [Po06] may
+ enforce using a larger Packet Sampling Interval.
 The Offered Load, the number of routes, and the Packet Sampling
 Interval influence the observations for the RateDerived Method. It
 may be difficult to identify the different convergence time instants
 in the RateDerived 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.
+ The Offered Load, Jitter, the number of routes, and the Packet
+ Sampling Interval influence the observations for the RateDerived
+ Method. It may be difficult to identify the different convergence
+ time instants in the RateDerived 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.
+
+ Jitter causes fluctuations in the number of received packets during
+ each Packet Sampling Interval. To account for the presence of Jitter
+ in determining if a convergence instant has been reached, Jitter
+ SHOULD be observed during each Packet Sampling Interval. The minimum
+ and maximum number of packets expected in a Packet Sampling Interval
+ in presence of Jitter can be calculated with Equation 1.
+
+ number of packets expected in a Packet Sampling Interval
+ in presence of Jitter
+ = expected number of packets without Jitter
+ +/(max Jitter during Packet Sampling Interval * Offered Load)
+
+ Equation 1
+
+ To determine if a convergence instant has been reached the number of
+ packets received in a Packet Sampling Interval is compared with the
+ range of expected number of packets calculated in Equation 1.
Metrics measured at the Packet Sampling Interval MUST include
Forwarding Rate and packet loss.
RateDerived 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
@@ 674,26 +695,26 @@
Definition:
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 RateDerived 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.
+ Instant and the Convergence Recovery Instant, as shown in Equation 2.
Full Convergence Time =
Convergence Recovery Instant  Convergence Event Instant
 Equation 1
+ 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 Full
Convergence Time equals the maximum RouteSpecific Convergence Time
when benchmarking all routes in FIB using the RouteSpecific Loss
Derived Method.
It is not possible to measure Full Convergence Time using the Loss
@@ 714,26 +735,26 @@
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 RateDerived 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.
+ Equation 3.
First Route Convergence Time =
First Route Convergence Instant  Convergence Event Instant
 Equation 2
+ Equation 3
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 RouteSpecific Convergence
Time when benchmarking all routes in FIB using the RouteSpecific
LossDerived Method.
It is not possible to measure First Route Convergence Time using the
@@ 759,42 +780,42 @@
Discussion:
RouteSpecific Convergence Time can only be measured using the Route
Specific LossDerived 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 NextBest
Egress Interface. When benchmarking RouteSpecific Convergence Time,
 Connectivity Packet Loss is measured and Equation 3 is applied for
 each measured route. The calculation is equal to Equation 7 in
+ Connectivity Packet Loss is measured and Equation 4 is applied for
+ each measured route. The calculation is equal to Equation 8 in
Section 3.6.5.
RouteSpecific Convergence Time =
Connectivity Packet Loss for specific route/Offered Load per route
 Equation 3
+ Equation 4
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 NextBest Egress Interface. When
benchmarking RouteSpecific Convergence Time, Convergence Packet Loss
 is measured and Equation 4 is applied for each measured route.
+ is measured and Equation 5 is applied for each measured route.
RouteSpecific Convergence Time =
Convergence Packet Loss for specific route/Offered Load per route
 (Convergence Event Instant  Traffic Start Instant)
 Equation 4
+ Equation 5
The Convergence Event Instant and Traffic Start Instant SHOULD be
collected by the Tester.
The RouteSpecific 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 RouteSpecific
Convergence Times can be measured it is possible to have an array of
@@ 820,40 +841,40 @@
Discussion:
LossDerived Convergence Time is measured using the LossDerived
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 NextBest
Egress Interface. When benchmarking LossDerived Convergence Time,
 Connectivity Packet Loss is measured and Equation 5 is applied.
+ Connectivity Packet Loss is measured and Equation 6 is applied.
LossDerived Convergence Time =
Connectivity Packet Loss/Offered Load
 Equation 5
+ Equation 6
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 NextBest Egress Interface. When
benchmarking LossDerived Convergence Time, Convergence Packet Loss
 is measured and Equation 6 is applied.
+ is measured and Equation 7 is applied.
LossDerived Convergence Time =
Convergence Packet Loss/Offered Load
 (Convergence Event Instant  Traffic Start Instant)
 Equation 6
+ Equation 7
The Convergence Event Instant and Traffic Start Instant SHOULD be
collected by the Tester.
Measurement Units: seconds
Issues: None
See Also:
@@ 878,28 +899,28 @@
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 [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
+ Packet Loss is measured for each route and Equation 8 is applied for
+ each measured route entry. The calculation is equal to Equation 4 in
Section 3.6.3.
Route Loss of Connectivity Period =
Connectivity Packet Loss for specific route/Offered Load per route
 Equation 7
+ Equation 8
Route Loss of Connectivity Period SHOULD be measured using Route
Specific LossDerived Method.
Measurement Units: seconds
Issues: None
See Also:
@@ 927,27 +948,27 @@
The LossDerived Loss of Connectivity Period may be equal to the
LossDerived 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 LossDerived 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.
+ Connectivity Packet Loss is measured for all routes and Equation 9 is
+ applied. The calculation is equal to Equation 6 in Section 3.6.4.
LossDerived Loss of Connectivity Period =
Connectivity Packet Loss for all routes/Offered Load
 Equation 8
+ Equation 9
LossDerived Loss of Connectivity Period SHOULD be measured using
LossDerived Method.
Measurement Units: seconds
Issues: None
See Also:
@@ 1003,27 +1024,28 @@
The number of packets lost due to a Convergence Event until Full
Convergence completes, as observed on the NextBest Egress Interface.
Discussion:
Convergence Packet Loss is observed on the NextBest 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.
+ that were delayed due to buffering. The maximum acceptable
+ Forwarding Delay (Forwarding Delay Threshold) is a parameter of the
+ methodology, if it is applied it MUST be reported.
Measurement Units: number of packets
Issues: None
+
See Also:
Packet Loss, Full Convergence, Convergence Event, Connectivity Packet
Loss
3.7.4. Connectivity Packet Loss
Definition:
The number of packets lost due to a Convergence Event until Full
@@ 1026,24 +1048,24 @@
Definition:
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.
+ Connectivity Packet Loss includes packets that were lost and packets
+ that were delayed due to buffering. The maximum acceptable
+ Forwarding Delay (Forwarding Delay Threshold) is a parameter of the
+ methodology, if it is applied it MUST be reported.
Measurement Units: number of packets
Issues: None
See Also:
Packet Loss, Route Loss of Connectivity Period, Convergence Event,
Convergence Packet Loss
@@ 1062,57 +1084,86 @@
Forwarding Rate and received packets.
Packet Sampling Interval can influence the convergence graph as
observed with the RateDerived 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
RateDerived Method may produce a larger than actual convergence
time.
 The recommended value for configuration of the Packet Sampling
 Interval when using the RateDerived Method is provided in [Po09m].
 For the other benchmark methods the value of the Packet Sampling
 Interval does not contribute to the measurement accuracy.
+ Using a small Packet Sampling Interval in the presence of Jitter
+ [Po06] may cause fluctuations of the Forwarding Rate observation and
+ can prevent correct observation of the different convergence time
+ instants.
+
+ The value of the Packet Sampling Interval only contributes to the
+ measurement accuracy of the RateDerived Method. For maximum
+ accuracy the value for the Packet Sampling Interval SHOULD be as
+ small as possible, but the presence of Jitter may enforce using a
+ larger Packet Sampling Interval.
Measurement Units: seconds
Issues: None
See Also: RateDerived Method
3.7.6. Sustained Convergence Validation Time
Definition:
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 [Br99]
+ The RECOMMENDED Sustained Convergence Validation Time to be used is
+ the time to send 5 consecutive packets to each destination with a
+ minimum of 5 seconds. The BMWG selected 5 seconds based upon [Br99]
which recommends waiting 2 seconds for residual frames to arrive
 (this is the Forwarding Delay threshold for the last packet sent) and
+ (this is the Forwarding Delay Threshold for the last packet sent) and
5 seconds for DUT restabilization.
Measurement Units: seconds
Issues: None
See Also:
Full Convergence, Convergence Recovery Instant
+3.7.7. Forwarding Delay Threshold
+
+ Definition:
+
+ The maximum Forwarding Delay for a packet to be accepted.
+
+ Discussion:
+
+ Applying a Forwarding Delay Threshold allows to consider packets with
+ a too large Forwarding Delay as being lost, as is required for some
+ applications (e.g. voice, video, etc.). The Forwarding Delay
+ Threshold is a parameter of the methodology, if it is applied it MUST
+ be reported.
+
+ Measurement Units: seconds
+
+ Issues: None
+
+ See Also:
+
+ Convergence Packet Loss, Connectivity Packet Loss
+
3.8. Miscellaneous Terms
3.8.1. Stale Forwarding
Definition:
Forwarding of traffic to route entries that no longer exist or to
route entries with nexthops that are no longer preferred.
Discussion:
@@ 1168,21 +1219,22 @@
from the DUT/SUT SHOULD be identical in the lab and in production
networks.
5. IANA Considerations
This document requires no IANA considerations.
6. Acknowledgements
Thanks to Sue Hares, Al Morton, Kevin Dubray, Ron Bonica, David Ward,
 Peter De Vriendt and the BMWG for their contributions to this work.
+ Peter De Vriendt, Anuj Dewagan and the BMWG for their contributions
+ to this work.
7. References
7.1. Normative References
[Br91] Bradner, S., "Benchmarking terminology for network
interconnection devices", RFC 1242, July 1991.
[Br97] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.