draft-ietf-bmwg-igp-dataplane-conv-term-22.txt   draft-ietf-bmwg-igp-dataplane-conv-term-23.txt 
Network Working Group S. Poretsky Network Working Group S. Poretsky
Internet-Draft Allot Communications Internet-Draft Allot Communications
Intended status: Informational B. Imhoff Intended status: Informational B. Imhoff
Expires: May 12, 2011 Juniper Networks Expires: August 13, 2011 Juniper Networks
K. Michielsen K. Michielsen
Cisco Systems Cisco Systems
November 8, 2010 February 16, 2011
Terminology for Benchmarking Link-State IGP Data Plane Route Convergence Terminology for Benchmarking Link-State IGP Data Plane Route Convergence
draft-ietf-bmwg-igp-dataplane-conv-term-22 draft-ietf-bmwg-igp-dataplane-conv-term-23
Abstract Abstract
This document describes the terminology for benchmarking Interior This document describes the terminology for benchmarking link-state
Gateway Protocol (IGP) Route Convergence. The terminology is to be Interior Gateway Protocol (IGP) route convergence. The terminology
used for benchmarking IGP convergence time through externally is to be used for benchmarking IGP convergence time through
observable (black box) data plane measurements. The terminology can externally observable (black box) data plane measurements. The
be applied to any link-state IGP, such as ISIS and OSPF. terminology can be applied to any link-state IGP, such as
Intermediate System to Intermediate System (IS-IS) and Open Shortest
Path First (OSPF).
Status of this Memo Status of this Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
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."
This Internet-Draft will expire on May 12, 2011. This Internet-Draft will expire on August 13, 2011.
Copyright Notice Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the Copyright (c) 2011 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 Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
skipping to change at page 2, line 25 skipping to change at page 3, line 10
outside the IETF Standards Process, and derivative works of it may outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other it for publication as an RFC or to translate it into languages other
than English. than English.
Table of Contents Table of Contents
1. Introduction and Scope . . . . . . . . . . . . . . . . . . . . 4 1. Introduction and Scope . . . . . . . . . . . . . . . . . . . . 4
2. Existing Definitions . . . . . . . . . . . . . . . . . . . . . 4 2. Existing Definitions . . . . . . . . . . . . . . . . . . . . . 4
3. Term Definitions . . . . . . . . . . . . . . . . . . . . . . . 4 3. Term Definitions . . . . . . . . . . . . . . . . . . . . . . . 4
3.1. Convergence Types . . . . . . . . . . . . . . . . . . . . 5 3.1. Convergence Types . . . . . . . . . . . . . . . . . . . . 4
3.1.1. Route Convergence . . . . . . . . . . . . . . . . . . 5 3.1.1. Route Convergence . . . . . . . . . . . . . . . . . . 5
3.1.2. Full Convergence . . . . . . . . . . . . . . . . . . . 5 3.1.2. Full Convergence . . . . . . . . . . . . . . . . . . . 5
3.1.3. Network Convergence . . . . . . . . . . . . . . . . . 6
3.2. Instants . . . . . . . . . . . . . . . . . . . . . . . . . 6 3.2. Instants . . . . . . . . . . . . . . . . . . . . . . . . . 6
3.2.1. Traffic Start Instant . . . . . . . . . . . . . . . . 6 3.2.1. Traffic Start Instant . . . . . . . . . . . . . . . . 6
3.2.2. Convergence Event Instant . . . . . . . . . . . . . . 7 3.2.2. Convergence Event Instant . . . . . . . . . . . . . . 6
3.2.3. Convergence Recovery Instant . . . . . . . . . . . . . 7 3.2.3. Convergence Recovery Instant . . . . . . . . . . . . . 7
3.2.4. First Route Convergence Instant . . . . . . . . . . . 8 3.2.4. First Route Convergence Instant . . . . . . . . . . . 7
3.3. Transitions . . . . . . . . . . . . . . . . . . . . . . . 8 3.3. Transitions . . . . . . . . . . . . . . . . . . . . . . . 8
3.3.1. Convergence Event Transition . . . . . . . . . . . . . 8 3.3.1. Convergence Event Transition . . . . . . . . . . . . . 8
3.3.2. Convergence Recovery Transition . . . . . . . . . . . 9 3.3.2. Convergence Recovery Transition . . . . . . . . . . . 9
3.4. Interfaces . . . . . . . . . . . . . . . . . . . . . . . . 10 3.4. Interfaces . . . . . . . . . . . . . . . . . . . . . . . . 9
3.4.1. Local Interface . . . . . . . . . . . . . . . . . . . 10 3.4.1. Local Interface . . . . . . . . . . . . . . . . . . . 9
3.4.2. Remote Interface . . . . . . . . . . . . . . . . . . . 10 3.4.2. Remote Interface . . . . . . . . . . . . . . . . . . . 9
3.4.3. Preferred Egress Interface . . . . . . . . . . . . . . 10 3.4.3. Preferred Egress Interface . . . . . . . . . . . . . . 10
3.4.4. Next-Best Egress Interface . . . . . . . . . . . . . . 11 3.4.4. Next-Best Egress Interface . . . . . . . . . . . . . . 10
3.5. Benchmarking Methods . . . . . . . . . . . . . . . . . . . 11 3.5. Benchmarking Methods . . . . . . . . . . . . . . . . . . . 11
3.5.1. Rate-Derived Method . . . . . . . . . . . . . . . . . 11 3.5.1. Rate-Derived Method . . . . . . . . . . . . . . . . . 11
3.5.2. Loss-Derived Method . . . . . . . . . . . . . . . . . 14 3.5.2. Loss-Derived Method . . . . . . . . . . . . . . . . . 13
3.5.3. Route-Specific Loss-Derived Method . . . . . . . . . . 15 3.5.3. Route-Specific Loss-Derived Method . . . . . . . . . . 14
3.6. Benchmarks . . . . . . . . . . . . . . . . . . . . . . . . 16 3.6. Benchmarks . . . . . . . . . . . . . . . . . . . . . . . . 15
3.6.1. Full Convergence Time . . . . . . . . . . . . . . . . 16 3.6.1. Full Convergence Time . . . . . . . . . . . . . . . . 15
3.6.2. First Route Convergence Time . . . . . . . . . . . . . 17 3.6.2. First Route Convergence Time . . . . . . . . . . . . . 16
3.6.3. Route-Specific Convergence Time . . . . . . . . . . . 18 3.6.3. Route-Specific Convergence Time . . . . . . . . . . . 17
3.6.4. Loss-Derived Convergence Time . . . . . . . . . . . . 19 3.6.4. Loss-Derived Convergence Time . . . . . . . . . . . . 18
3.6.5. Route Loss of Connectivity Period . . . . . . . . . . 20 3.6.5. Route Loss of Connectivity Period . . . . . . . . . . 19
3.6.6. Loss-Derived Loss of Connectivity Period . . . . . . . 21 3.6.6. Loss-Derived Loss of Connectivity Period . . . . . . . 20
3.7. Measurement Terms . . . . . . . . . . . . . . . . . . . . 22 3.7. Measurement Terms . . . . . . . . . . . . . . . . . . . . 21
3.7.1. Convergence Event . . . . . . . . . . . . . . . . . . 22 3.7.1. Convergence Event . . . . . . . . . . . . . . . . . . 21
3.7.2. Packet Loss . . . . . . . . . . . . . . . . . . . . . 22 3.7.2. Convergence Packet Loss . . . . . . . . . . . . . . . 21
3.7.3. Convergence Packet Loss . . . . . . . . . . . . . . . 23 3.7.3. Connectivity Packet Loss . . . . . . . . . . . . . . . 22
3.7.4. Connectivity Packet Loss . . . . . . . . . . . . . . . 23 3.7.4. Packet Sampling Interval . . . . . . . . . . . . . . . 22
3.7.5. Packet Sampling Interval . . . . . . . . . . . . . . . 24 3.7.5. Sustained Convergence Validation Time . . . . . . . . 23
3.7.6. Sustained Convergence Validation Time . . . . . . . . 25 3.7.6. Forwarding Delay Threshold . . . . . . . . . . . . . . 24
3.7.7. Forwarding Delay Threshold . . . . . . . . . . . . . . 25 3.8. Miscellaneous Terms . . . . . . . . . . . . . . . . . . . 24
3.8. Miscellaneous Terms . . . . . . . . . . . . . . . . . . . 26 3.8.1. Impaired Packet . . . . . . . . . . . . . . . . . . . 24
3.8.1. Stale Forwarding . . . . . . . . . . . . . . . . . . . 26 4. Security Considerations . . . . . . . . . . . . . . . . . . . 24
3.8.2. Nested Convergence Event . . . . . . . . . . . . . . . 26 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25
4. Security Considerations . . . . . . . . . . . . . . . . . . . 27 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 25
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27 7. Normative References . . . . . . . . . . . . . . . . . . . . . 25
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 27 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 26
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 27
7.1. Normative References . . . . . . . . . . . . . . . . . . . 27
7.2. Informative References . . . . . . . . . . . . . . . . . . 28
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 28
1. Introduction and Scope 1. Introduction and Scope
This draft describes the terminology for benchmarking Link-State This document is a companion to [Po11m] which the methodology to be
Interior Gateway Protocol (IGP) Convergence. The motivation and used for benchmarking link-state Interior Gateway Protocol (IGP)
applicability for this benchmarking is provided in [Po09a]. The Convergence by observing the data plane. The purpose of this
methodology to be used for this benchmarking is described in [Po10m]. document is to introduce new terms required to complete execution of
The purpose of this document is to introduce new terms required to the Link-State IGP Data Plane Route Convergence methodology [Po11m].
complete execution of the IGP Route Methodology [Po10m].
IGP convergence time is measured on the data plane at the Tester by IGP convergence time is measured by observing the dataplane through
observing packet loss through the DUT. The methodology and the Device Under Test (DUT) at the Tester. The methodology and
terminology to be used for benchmarking IGP Convergence can be terminology to be used for benchmarking IGP Convergence can be
applied to IPv4 and IPv6 traffic and link-state IGPs such as ISIS applied to IPv4 and IPv6 traffic and link-state IGPs such as
[Ca90][Ho08], OSPF [Mo98][Co08], and others. Intermediate System to Intermediate System (IS-IS) [Ca90][Ho08], Open
Shortest Path First (OSPF) [Mo98][Co08], and others.
2. Existing Definitions 2. Existing Definitions
This document uses existing terminology defined in other BMWG work. This document uses existing terminology defined in other IETF
Examples include, but are not limited to: documents. Examples include, but are not limited to:
Frame Loss Rate [Ref.[Br91], section 3.6]
Throughput [Ref.[Br91], section 3.17] Throughput [Ref.[Br91], section 3.17]
Offered Load [Ref.[Ma98], section 3.5.2] Offered Load [Ref.[Ma98], section 3.5.2]
Forwarding Rate [Ref.[Ma98], section 3.6.1] 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.4] Out-of-Order Packet [Ref.[Po06], section 3.3.4]
Duplicate Packet [Ref.[Po06], section 3.3.5] Duplicate Packet [Ref.[Po06], section 3.3.5]
Packet Reordering [Ref.[Mo06], section 3.3]
Stream [Ref.[Po06], section 3.3.2] Stream [Ref.[Po06], section 3.3.2]
Forwarding Delay [Ref.[Po06], section 3.2.4] Forwarding Delay [Ref.[Po06], section 3.2.4]
IP Packet Delay Variation (IPDV) [Ref.[De02], section 1.2] IP Packet Delay Variation (IPDV) [Ref.[De02], section 1.2]
Loss Period [Ref.[Ko02], section 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. Convergence Types
3.1. Convergence Types
3.1.1. Route Convergence 3.1.1. Route Convergence
Definition: Definition:
The process of updating all components of the router, including the The process of updating all components of the router, including the
Routing Information Base (RIB) and Forwarding Information Base (FIB), Routing Information Base (RIB) and Forwarding Information Base (FIB),
along with software and hardware tables, with the most recent route along with software and hardware tables, with the most recent route
change(s) such that forwarding for a route entry is successful on the change(s) such that forwarding for a route entry is successful on the
Next-Best Egress Interface. Next-Best Egress Interface [Section 3.4.4].
Discussion: Discussion:
Route Convergence MUST occur after a Convergence Event. Route In general IGP convergence does not necessarily result in a change in
Convergence can be observed externally by the rerouting of data forwarding. But the test cases in [Po11m] are specified such that
traffic for a destination matching a route entry to the Next-best the IGP convergence results in a change of egress interface for the
Egress Interface. Completion of Route Convergence may or may not be measurement dataplane traffic. Due to this property of the test case
sustained over time. specifications, Route Convergence can be observed externally by the
rerouting of the measurement dataplane traffic to the Next-best
Egress Interface [Section 3.4.4].
Measurement Units: N/A Measurement Units: N/A
Issues: None
See Also: See Also:
Network Convergence, Full Convergence, Convergence Event Next-Best Egress Interface, Full Convergence
3.1.2. Full Convergence 3.1.2. Full Convergence
Definition: Definition:
Route Convergence for all routes in the FIB. Route Convergence for all routes in the Forwarding Information Base
(FIB).
Discussion:
Full Convergence MUST occur after a Convergence Event. Full
Convergence can be observed externally by the rerouting of data
traffic to destinations matching all route entries to the Next-best
Egress Interface. Completion of Full Convergence is externally
observable from the data plane when the Forwarding Rate of the data
plane traffic on the Next-Best Egress Interface equals the Offered
Load.
Completion of Full Convergence may or may not be sustained over time.
Measurement Units: N/A
Issues: None
See Also:
Network Convergence, Route Convergence, Convergence Event, Full
Convergence Time, Convergence Recovery Instant
3.1.3. Network Convergence
Definition:
Full Convergence in all routers throughout the network.
Discussion: Discussion:
Network Convergence includes all Route Convergence operations for all In general IGP convergence does not necessarily result in a change in
routers in the network following a Convergence Event. forwarding. But the test cases in [Po11m] are specified such that
the IGP convergence results in a change of egress interface for the
Completion of Network Convergence can be observed by recovery of the measurement dataplane traffic. Due to this property of the test
network Forwarding Rate to equal the Offered Load, with no Stale cases specifications, Full Convergence can be observed externally by
Forwarding, and no Blenders [Ca01][Ci03]. the rerouting of the measurement dataplane traffic to the Next-best
Egress Interface [Section 3.4.4].
Completion of Network Convergence may or may not be sustained over
time.
Measurement Units: N/A Measurement Units: N/A
Issues: None
See Also: See Also:
Route Convergence, Full Convergence, Stale Forwarding Next-Best Egress Interface, Route Convergence
3.2. Instants 3.2. Instants
3.2.1. Traffic Start Instant 3.2.1. Traffic Start Instant
Definition: Definition:
The time instant the Tester sends out the first data packet to the The time instant the Tester sends out the first data packet to the
DUT. Device Under Test (DUT).
Discussion: Discussion:
If using the Loss-Derived Method or the Route-Specific Loss-Derived If using the Loss-Derived Method [Section 3.5.2] or the Route-
Method to benchmark IGP convergence time, and the applied Convergence Specific Loss-Derived Method [Section 3.5.3] to benchmark IGP
Event does not cause instantaneous traffic loss for all routes at the convergence time, and the applied Convergence Event [Section 3.7.1]
Convergence Event Instant then the Tester SHOULD collect a timestamp does not cause instantaneous traffic loss for all routes at the
on the Traffic Start Instant in order to measure the period of time Convergence Event Instant [Section 3.2.2] then the Tester SHOULD
between the Traffic Start Instant and Convergence Event Instant. collect a timestamp on the Traffic Start Instant in order to measure
the period of time between the Traffic Start Instant and Convergence
Event Instant.
Measurement Units: Measurement Units:
hh:mm:ss:nnn:uuu, where 'nnn' is milliseconds and 'uuu' is seconds (and fractions), reported with resolution sufficient to
microseconds. distinguish between different instants
Issues: None
See Also: See Also:
Convergence Event Instant, Route-Specific Convergence Time, Loss- Loss-Derived Method, Route-Specific Loss-Derived Method, Convergence
Derived Convergence Time. Event, Convergence Event Instant
3.2.2. Convergence Event Instant 3.2.2. Convergence Event Instant
Definition: Definition:
The time instant that a Convergence Event occurs. The time instant that a Convergence Event [Section 3.7.1] occurs.
Discussion: Discussion:
If the Convergence Event causes instantaneous traffic loss on the If the Convergence Event [Section 3.7.1] causes instantaneous traffic
Preferred Egress Interface, the Convergence Event Instant is loss on the Preferred Egress Interface [Section 3.4.3], the
observable from the data plane as the instant that the DUT begins to Convergence Event Instant is observable from the data plane as the
exhibit packet loss. instant that no more packets are received on the Preferred Egress
Interface.
The Tester SHOULD collect a timestamp on the Convergence Event The Tester SHOULD collect a timestamp on the Convergence Event
Instant if it is not observable from the data plane. Instant if it the Convergence Event does not cause instantaneous
traffic loss on the Preferred Egress Interface [Section 3.4.3].
Measurement Units: Measurement Units:
hh:mm:ss:nnn:uuu, where 'nnn' is milliseconds and 'uuu' is seconds (and fractions), reported with resolution sufficient to
microseconds. distinguish between different instants
Issues: None See Also:
See Also: Convergence Event Convergence Event, Preferred Egress Interface
3.2.3. Convergence Recovery Instant 3.2.3. Convergence Recovery Instant
Definition: Definition:
The time instant that Full Convergence has completed. The time instant that Full Convergence [Section 3.1.2] has completed.
Discussion: Discussion:
The Full Convergence completed state MUST be maintained for an The Full Convergence completed state MUST be maintained for an
interval of duration equal to the Sustained Convergence Validation interval of duration equal to the Sustained Convergence Validation
Time in order to validate the Convergence Recovery Instant. Time [Section 3.7.5] in order to validate the Convergence Recovery
Instant.
The Convergence Recovery Instant is observable from the data plane as The Convergence Recovery Instant is observable from the data plane as
the instant the DUT forwards traffic to all destinations over the the instant the Device Under Test (DUT) forwards traffic to all
Next-Best Egress Interface. destinations over the Next-Best Egress Interface [Section 3.4.4]
without impairments.
Measurement Units: Measurement Units:
hh:mm:ss:nnn:uuu, where 'nnn' is milliseconds and 'uuu' is seconds (and fractions), reported with resolution sufficient to
microseconds. distinguish between different instants
Issues: None
See Also: See Also:
Sustained Convergence Validation Time, Full Convergence Sustained Convergence Validation Time, Full Convergence, Next-Best
Egress Interface
3.2.4. First Route Convergence Instant 3.2.4. First Route Convergence Instant
Definition: Definition:
The time instant the first route entry completes Route Convergence The time instant the first route entry completes Route Convergence
following a Convergence Event [Section 3.1.1]
Discussion: Discussion:
Any route may be the first to complete Route Convergence. The First Any route may be the first to complete Route Convergence. The First
Route Convergence Instant is observable from the data plane as the Route Convergence Instant is observable from the data plane as the
instant that the first packet is received from the Next-Best Egress instant that the first packet that is not an Impaired Packet
Interface. [Section 3.8.1] is received from the Next-Best Egress Interface
[Section 3.4.4] or, for the test cases with Equal Cost Multi-Path
(ECMP) or Parallel Links, the instant that the Forwarding Rate on the
Next-Best Egress Interface [Section 3.4.4] starts to increase.
Measurement Units: Measurement Units:
hh:mm:ss:nnn:uuu, where 'nnn' is milliseconds and 'uuu' is seconds (and fractions), reported with resolution sufficient to
microseconds. distinguish between different instants
Issues: None See Also:
See Also: Route Convergence Route Convergence, Impaired Packet, Next-Best Egress Interface
3.3. Transitions 3.3. Transitions
3.3.1. Convergence Event Transition 3.3.1. Convergence Event Transition
Definition: Definition:
A time interval following a Convergence Event in which Forwarding A time interval following a Convergence Event [Section 3.7.1] in
Rate on the Preferred Egress Interface gradually reduces to zero. which Forwarding Rate on the Preferred Egress Interface
[Section 3.4.3] gradually reduces to zero.
Discussion: Discussion:
The Forwarding Rate during a Convergence Event Transition may not The Forwarding Rate during a Convergence Event Transition may or may
decrease linearly. not decrease linearly.
The Forwarding Rate observed on all DUT egress interfaces may or may The Forwarding Rate observed on the Device Under Test (DUT) egress
not decrease to zero. interface(s) may or may not decrease to zero.
The Offered Load, the number of routes, and the Packet Sampling The Offered Load, the number of routes, and the Packet Sampling
Interval influence the observations of the Convergence Event Interval [Section 3.7.4] influence the observations of the
Transition using the Rate-Derived Method. This is further discussed Convergence Event Transition using the Rate-Derived Method
with the term "Rate-Derived Method". [Section 3.5.1].
Measurement Units: seconds
Issues: None Measurement Units: seconds (and fractions)
See Also: See Also:
Convergence Event, Rate-Derived Method Convergence Event, Preferred Egress Interface, Packet Sampling
Interva, Rate-Derived Method
3.3.2. Convergence Recovery Transition 3.3.2. Convergence Recovery Transition
Definition: Definition:
A time interval following the First Route Convergence Instant in A time interval following the First Route Convergence Instant
which Forwarding Rate on the Next-Best Egress Interface gradually [Section 3.4.4] in which Forwarding Rate on the Device Under Test
increases to equal the Offered Load. (DUT) egress interface(s) gradually increases to equal the Offered
Load.
Discussion: Discussion:
The Forwarding Rate observed during a Convergence Recovery Transition The Forwarding Rate observed during a Convergence Recovery Transition
may not increase linearly. may or may not increase linearly.
The Offered Load, the number of routes, and the Packet Sampling The Offered Load, the number of routes, and the Packet Sampling
Interval influence the observations of the Convergence Recovery Interval [Section 3.7.4] influence the observations of the
Transition using the Rate-Derived Method. This is further discussed Convergence Recovery Transition using the Rate-Derived Method
with the term "Rate-Derived Method". [Section 3.5.1].
Measurement Units: seconds
Issues: None Measurement Units: seconds (and fractions)
See Also: See Also:
Full Convergence,First Route Convergence Instant, Rate-Derived Method First Route Convergence Instant, Packet Sampling Interva, Rate-
Derived Method
3.4. Interfaces 3.4. Interfaces
3.4.1. Local Interface 3.4.1. Local Interface
Definition: Definition:
An interface on the DUT. An interface on the Device Under Test (DUT).
Discussion: Discussion:
A failure of the Local Interface indicates that the failure occurred A failure of a Local Interface indicates that the failure occurred
directly on the DUT. directly on the Device Under Test (DUT).
Measurement Units: N/A Measurement Units: N/A
Issues: None
See Also: Remote Interface See Also: Remote Interface
3.4.2. Remote Interface 3.4.2. Remote Interface
Definition: Definition:
An interface on a neighboring router that is not directly connected An interface on a neighboring router that is not directly connected
to any interface on the DUT. to any interface on the Device Under Test (DUT).
Discussion: Discussion:
A failure of a Remote Interface indicates that the failure occurred A failure of a Remote Interface indicates that the failure occurred
on a neighbor router's interface that is not directly connected to on a neighbor router's interface that is not directly connected to
the DUT. the Device Under Test (DUT).
Measurement Units: N/A Measurement Units: N/A
Issues: None
See Also: Local Interface See Also: Local Interface
3.4.3. Preferred Egress Interface 3.4.3. Preferred Egress Interface
Definition: Definition:
The outbound interface from the DUT for traffic routed to the The outbound interface from the Device Under Test (DUT) for traffic
preferred next-hop. routed to the preferred next-hop.
Discussion: Discussion:
The Preferred Egress Interface is the egress interface prior to a The Preferred Egress Interface is the egress interface prior to a
Convergence Event. Convergence Event [Section 3.7.1].
Measurement Units: N/A Measurement Units: N/A
Issues: None See Also: Convergence Event, Next-Best Egress Interface
See Also: Next-Best Egress Interface
3.4.4. Next-Best Egress Interface 3.4.4. Next-Best Egress Interface
Definition: Definition:
The outbound interface from the DUT for traffic routed to the second- The outbound interface or set of outbound interfaces in an Equal Cost
best next-hop. Multipath (ECMP) set or parallel link set of the Device Under Test
(DUT) for traffic routed to the second-best next-hop.
Discussion: Discussion:
The Next-Best Egress Interface becomes the egress interface after a The Next-Best Egress Interface becomes the egress interface after a
Convergence Event. Convergence Event [Section 3.4.4].
Measurement Units: N/A For the test cases in [Po11m] using test topologies with an ECMP set
or parallel link set, the term Preferred Egress Interface refers to
all members of the link set.
Issues: None Measurement Units: N/A
See Also: Preferred Egress Interface See Also: Convergence Event, Preferred Egress Interface
3.5. Benchmarking Methods 3.5. Benchmarking Methods
3.5.1. Rate-Derived Method 3.5.1. Rate-Derived Method
Definition: Definition:
The method to calculate convergence time benchmarks from observing The method to calculate convergence time benchmarks from observing
Forwarding Rate each Packet Sampling Interval. Forwarding Rate each Packet Sampling Interval [Section 3.7.4].
Discussion: Discussion:
Figure 1 shows an example of the Forwarding Rate change in time Figure 1 shows an example of the Forwarding Rate change in time
during convergence as observed when using the Rate-Derived Method. during convergence as observed when using the Rate-Derived Method.
^ Traffic Convergence ^ Traffic Convergence
Fwd | Start Recovery Fwd | Start Recovery
Rate | Instant Instant Rate | Instant Instant
| Offered ^ ^ | Offered ^ ^
skipping to change at page 12, line 23 skipping to change at page 11, line 37
| Event \ / | Event \ /
| Transition \---------/ <-- Max Packet Loss | Transition \---------/ <-- Max Packet Loss
| |
+---------------------------------------------------------> +--------------------------------------------------------->
^ ^ time ^ ^ time
Convergence First Route Convergence First Route
Event Instant Convergence Instant Event Instant Convergence Instant
Figure 1: Rate-Derived Convergence Graph Figure 1: Rate-Derived Convergence Graph
The Offered Load SHOULD consist of a single Stream [Po06]. If To enable collecting statistics of Out-of-Order Packets per flow (See
sending multiple Streams, the measured traffic rate statistics for [Th00], Section 3) the Offered Load SHOULD consist of multiple
all Streams MUST be added together. Streams [Po06] and each Stream SHOULD consist of a single flow . If
sending multiple Streams, the measured traffic statistics for all
Streams MUST be added together.
The destination addresses for the Offered Load MUST be distributed The destination addresses for the Offered Load MUST be distributed
such that all routes or a statistically representative subset of all such that all routes or a statistically representative subset of all
routes are matched and each of these routes is offered an equal share 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 of the Offered Load. It is RECOMMENDED to send traffic to all
routes, but a statistically representative subset of all routes can routes, but a statistically representative subset of all routes can
be used if required. be used if required.
At least one packet per route for all routes matched in the Offered 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. Load MUST be offered to the DUT within each Packet Sampling Interval.
skipping to change at page 13, line 29 skipping to change at page 12, line 47
If packets are going over multiple ECMP members and one or more of If packets are going over multiple ECMP members and one or more of
the members has failed then the number of received packets during the members has failed then the number of received packets during
each Packet Sampling Interval may vary, even excluding presence of each Packet Sampling Interval may vary, even excluding presence of
IPDV. To prevent fluctuation of the number of received packets IPDV. To prevent fluctuation of the number of received packets
during each Packet Sampling Interval for this reason, the Packet during each Packet Sampling Interval for this reason, the Packet
Sampling Interval duration SHOULD be a whole multiple of the time Sampling Interval duration SHOULD be a whole multiple of the time
between two consecutive packets sent to the same destination. between two consecutive packets sent to the same destination.
Metrics measured at the Packet Sampling Interval MUST include Metrics measured at the Packet Sampling Interval MUST include
Forwarding Rate and packet loss. Forwarding Rate and Impaired Packet count.
Rate-Derived Method is a RECOMMENDED method to measure convergence
time benchmarks.
To measure convergence time benchmarks for Convergence Events that do To measure convergence time benchmarks for Convergence Events
not cause instantaneous traffic loss for all routes at the [Section 3.7.1] that do not cause instantaneous traffic loss for all
Convergence Event Instant, the Tester SHOULD collect a timestamp of routes at the Convergence Event Instant, the Tester SHOULD collect a
the Convergence Event Instant and the Tester SHOULD observe timestamp of the Convergence Event Instant [Section 3.2.2] and the
Forwarding Rate separately on the Next-Best Egress Interface. Tester SHOULD observe Forwarding Rate separately on the Next-Best
Egress Interface.
Since the Rate-Derived Method does not distinguish between individual Since the Rate-Derived Method does not distinguish between individual
traffic destinations, it SHOULD NOT be used for any route specific traffic destinations, it SHOULD NOT be used for any route specific
measurements. Therefor Rate-Derived Method SHOULD NOT be used to measurements. Therefor Rate-Derived Method SHOULD NOT be used to
benchmark Route Loss of Connectivity Period. benchmark Route Loss of Connectivity Period [Section 3.6.5].
Measurement Units: N/A Measurement Units: N/A
Issues: None
See Also: See Also:
Packet Sampling Interval, Convergence Event, Convergence Event Packet Sampling Interval, Convergence Event, Convergence Event
Instant, Full Convergence Instant, Next-Best Egress Interface, Route Loss of Connectivity
Period
3.5.2. Loss-Derived Method 3.5.2. Loss-Derived Method
Definition: Definition:
The method to calculate the Loss-Derived Convergence Time and Loss- The method to calculate the Loss-Derived Convergence Time
Derived Loss of Connectivity Period benchmarks from the amount of [Section 3.6.4] and Loss-Derived Loss of Connectivity Period
packet loss. [Section 3.6.6] benchmarks from the amount of Impaired Packets
[Section 3.8.1].
Discussion: Discussion:
The Offered Load SHOULD consist of a single Stream [Po06]. If To enable collecting statistics of Out-of-Order Packets per flow (See
sending multiple Streams, the measured traffic rate statistics for [Th00], Section 3) the Offered Load SHOULD consist of multiple
all Streams MUST be added together. Streams [Po06] and each Stream SHOULD consist of a single flow . If
sending multiple Streams, the measured traffic statistics for all
Streams MUST be added together.
The destination addresses for the Offered Load MUST be distributed The destination addresses for the Offered Load MUST be distributed
such that all routes or a statistically representative subset of all such that all routes or a statistically representative subset of all
routes are matched and each of these routes is offered an equal share 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 of the Offered Load. It is RECOMMENDED to send traffic to all
routes, but a statistically representative subset of all routes can routes, but a statistically representative subset of all routes can
be used if required. be used if required.
Loss-Derived Method SHOULD always be combined with Rate-Derived Loss-Derived Method SHOULD always be combined with Rate-Derived
Method in order to observe Full Convergence completion. The total Method in order to observe Full Convergence completion. The total
amount of Convergence Packet Loss is collected after Full Convergence amount of Convergence Packet Loss is collected after Full Convergence
completion. completion.
To measure convergence time and loss of connectivity benchmarks, the To measure convergence time and loss of connectivity benchmarks for
Tester SHOULD in general observe packet loss on all DUT egress Convergence Events that cause instantaneous traffic loss for all
interfaces (Connectivity Packet Loss). routes at the Convergence Event Instant, the Tester SHOULD observe
Impaired Packet count on all DUT egress interfaces (see Connectivity
Packet Loss [Section 3.7.3]).
To measure convergence time benchmarks for Convergence Events that do To measure convergence time benchmarks for Convergence Events that do
not cause instantaneous traffic loss for all routes at the not cause instantaneous traffic loss for all routes at the
Convergence Event Instant, the Tester SHOULD collect timestamps of Convergence Event Instant, the Tester SHOULD collect timestamps of
the Start Traffic Instant and of the Convergence Event Instant, and the Start Traffic Instant and of the Convergence Event Instant, and
the Tester SHOULD observe packet loss separately on the Next-Best the Tester SHOULD observe Impaired Packet count separately on the
Egress Interface (Convergence Packet Loss). Next-Best Egress Interface (See Convergence Packet Loss
[Section 3.7.2]).
Since Loss-Derived Method does not distinguish between traffic Since Loss-Derived Method does not distinguish between traffic
destinations and the packet loss statistics are only collected after destinations and the Impaired Packet statistics are only collected
Full Convergence completion, this method can only be used to measure after Full Convergence completion, this method can only be used to
average values over all routes. For these reasons Loss-Derived measure average values over all routes. For these reasons Loss-
Method can only be used to benchmark Loss-Derived Convergence Time Derived Method can only be used to benchmark Loss-Derived Convergence
and Loss-Derived Loss of Connectivity Period. Time [Section 3.6.4] and Loss-Derived Loss of Connectivity Period
[Section 3.6.6].
Note that the Loss-Derived Method measures an average over all Note that the Loss-Derived Method measures an average over all
routes, including the routes that may not be impacted by the routes, including the routes that may not be impacted by the
Convergence Event, such as routes via non-impacted members of ECMP or Convergence Event, such as routes via non-impacted members of ECMP or
parallel links. parallel links.
Measurement Units: seconds Measurement Units: N/A
Issues: None
See Also: See Also:
Loss-Derived Convergence Time, Loss-Derived Loss of Connectivity Loss-Derived Convergence Time, Loss-Derived Loss of Connectivity
Period, Convergence Packet Loss Period, Connectivity Packet Loss, Convergence Packet Loss
3.5.3. Route-Specific Loss-Derived Method 3.5.3. Route-Specific Loss-Derived Method
Definition: Definition:
The method to calculate the Route-Specific Convergence Time benchmark The method to calculate the Route-Specific Convergence Time
from the amount of packet loss during convergence for a specific [Section 3.6.3] benchmark from the amount of Impaired Packets
route entry. [Section 3.8.1] during convergence for a specific route entry.
Discussion: Discussion:
To benchmark Route-Specific Convergence Time, the Tester provides an To benchmark Route-Specific Convergence Time, the Tester provides an
Offered Load that consists of multiple Streams [Po06]. Each Stream Offered Load that consists of multiple Streams [Po06]. Each Stream
has a single destination address matching a different route entry, has a single destination address matching a different route entry,
for all routes or a statistically representative subset of all for all routes or a statistically representative subset of all
routes. Convergence Packet Loss is measured for each Stream routes. Each Stream SHOULD consist of a single flow (See [Th00],
Section 3). Convergence Packet Loss is measured for each Stream
separately. separately.
Route-Specific Loss-Derived Method SHOULD always be combined with Route-Specific Loss-Derived Method SHOULD always be combined with
Rate-Derived Method in order to observe Full Convergence completion. Rate-Derived Method in order to observe Full Convergence completion.
The total amount of Convergence Packet Loss for each Stream is The total amount of Convergence Packet Loss [Section 3.7.2] for each
collected after Full Convergence completion. Stream is collected after Full Convergence completion.
Route-Specific Loss-Derived Method is a RECOMMENDED method to measure Route-Specific Loss-Derived Method is the RECOMMENDED method to
convergence time benchmarks. measure convergence time benchmarks.
To measure convergence time and loss of connectivity benchmarks, the To measure convergence time and loss of connectivity benchmarks for
Tester SHOULD in general observe packet loss on all DUT egress Convergence Events that cause instantaneous traffic loss for all
interfaces (Connectivity Packet Loss). routes at the Convergence Event Instant, the Tester SHOULD observe
Impaired Packet count on all DUT egress interfaces (see Connectivity
Packet Loss [Section 3.7.3]).
To measure convergence time benchmarks for Convergence Events that do To measure convergence time benchmarks for Convergence Events that do
not cause instantaneous traffic loss for all routes at the not cause instantaneous traffic loss for all routes at the
Convergence Event Instant, the Tester SHOULD collect timestamps of Convergence Event Instant, the Tester SHOULD collect timestamps of
the Start Traffic Instant and of the Convergence Event Instant, and the Start Traffic Instant and of the Convergence Event Instant, and
the Tester SHOULD observe packet loss separately on the Next-Best the Tester SHOULD observe packet loss separately on the Next-Best
Egress Interface (Convergence Packet Loss). Egress Interface (See Convergence Packet Loss [Section 3.7.2]).
Since Route-Specific Loss-Derived Method uses traffic streams to Since Route-Specific Loss-Derived Method uses traffic streams to
individual routes, it measures packet loss as it would be experienced individual routes, it observes Impaired Packet count as it would be
by a network user. For this reason Route-Specific Loss-Derived experienced by a network user. For this reason Route-Specific Loss-
Method is RECOMMENDED to measure Route-Specific Convergence Time Derived Method is RECOMMENDED to measure Route-Specific Convergence
benchmarks and Route Loss of Connectivity Period benchmarks. Time benchmarks and Route Loss of Connectivity Period benchmarks.
Measurement Units: seconds
Issues: None Measurement Units: N/A
See Also: See Also:
Route-Specific Convergence Time, Route Loss of Connectivity Period, Route-Specific Convergence Time, Route Loss of Connectivity Period,
Convergence Packet Loss Connectivity Packet Loss, Convergence Packet Loss
3.6. Benchmarks 3.6. Benchmarks
3.6.1. Full Convergence Time 3.6.1. Full Convergence Time
Definition: Definition:
The time duration of the period between the Convergence Event Instant The time duration of the period between the Convergence Event Instant
and the Convergence Recovery Instant as observed using the Rate- and the Convergence Recovery Instant as observed using the Rate-
Derived Method. Derived Method.
skipping to change at page 16, line 44 skipping to change at page 16, line 17
Instant and the Convergence Recovery Instant, as shown in Equation 2. Instant and the Convergence Recovery Instant, as shown in Equation 2.
Full Convergence Time = Full Convergence Time =
Convergence Recovery Instant - Convergence Event Instant Convergence Recovery Instant - Convergence Event Instant
Equation 2 Equation 2
The Convergence Event Instant can be derived from the Forwarding Rate The Convergence Event Instant can be derived from the Forwarding Rate
observation or from a timestamp collected by the Tester. observation or from a timestamp collected by the Tester.
For the testcases described in [Po10m], it is expected that Full For the test cases described in [Po11m], it is expected that Full
Convergence Time equals the maximum Route-Specific Convergence Time Convergence Time equals the maximum Route-Specific Convergence Time
when benchmarking all routes in FIB using the Route-Specific Loss- when benchmarking all routes in FIB using the Route-Specific Loss-
Derived Method. Derived Method.
It is not possible to measure Full Convergence Time using the Loss- It is not possible to measure Full Convergence Time using the Loss-
Derived Method. Derived Method.
Measurement Units: seconds Measurement Units: seconds (and fractions)
Issues: None
See Also: See Also:
Full Convergence, Rate-Derived Method, Route-Specific Loss-Derived Full Convergence, Rate-Derived Method, Route-Specific Loss-Derived
Method Method, Convergence Event Instant, Convergence Recovery Instant
3.6.2. First Route Convergence Time 3.6.2. First Route Convergence Time
Definition: Definition:
The duration of the period between the Convergence Event Instant and The duration of the period between the Convergence Event Instant and
the First Route Convergence Instant as observed using the Rate- the First Route Convergence Instant as observed using the Rate-
Derived Method. Derived Method.
Discussion: Discussion:
skipping to change at page 17, line 34 skipping to change at page 17, line 6
Equation 3. Equation 3.
First Route Convergence Time = First Route Convergence Time =
First Route Convergence Instant - Convergence Event Instant First Route Convergence Instant - Convergence Event Instant
Equation 3 Equation 3
The Convergence Event Instant can be derived from the Forwarding Rate The Convergence Event Instant can be derived from the Forwarding Rate
observation or from a timestamp collected by the Tester. observation or from a timestamp collected by the Tester.
For the testcases described in [Po10m], it is expected that First For the test cases described in [Po11m], it is expected that First
Route Convergence Time equals the minimum Route-Specific Convergence Route Convergence Time equals the minimum Route-Specific Convergence
Time when benchmarking all routes in FIB using the Route-Specific Time when benchmarking all routes in FIB using the Route-Specific
Loss-Derived Method. Loss-Derived Method.
It is not possible to measure First Route Convergence Time using the It is not possible to measure First Route Convergence Time using the
Loss-Derived Method. Loss-Derived Method.
Measurement Units: seconds Measurement Units: seconds (and fractions)
Issues: None
See Also: See Also:
Rate-Derived Method, Route-Specific Loss-Derived Method, First Route Rate-Derived Method, Route-Specific Loss-Derived Method, Convergence
Convergence Instant Event Instant, First Route Convergence Instant
3.6.3. Route-Specific Convergence Time 3.6.3. Route-Specific Convergence Time
Definition: Definition:
The amount of time it takes for Route Convergence to be completed for The amount of time it takes for Route Convergence to be completed for
a specific route, as calculated from the amount of packet loss during a specific route, as calculated from the amount of Impaired Packets
convergence for a single route entry. [Section 3.8.1] during convergence for a single route entry.
Discussion: Discussion:
Route-Specific Convergence Time can only be measured using the Route- Route-Specific Convergence Time can only be measured using the Route-
Specific Loss-Derived Method. Specific Loss-Derived Method.
If the applied Convergence Event causes instantaneous traffic loss If the applied Convergence Event causes instantaneous traffic loss
for all routes at the Convergence Event Instant, Connectivity Packet for all routes at the Convergence Event Instant, Connectivity Packet
Loss should be observed. Connectivity Packet Loss is the combined Loss should be observed. Connectivity Packet Loss is the combined
packet loss observed on Preferred Egress Interface and Next-Best Impaired Packet count observed on Preferred Egress Interface and
Egress Interface. When benchmarking Route-Specific Convergence Time, Next-Best Egress Interface. When benchmarking Route-Specific
Connectivity Packet Loss is measured and Equation 4 is applied for Convergence Time, Connectivity Packet Loss is measured and Equation 4
each measured route. The calculation is equal to Equation 8 in is applied for each measured route. The calculation is equal to
Section 3.6.5. Equation 8 in Section 3.6.5.
Route-Specific Convergence Time = Route-Specific Convergence Time =
Connectivity Packet Loss for specific route/Offered Load per route Connectivity Packet Loss for specific route/Offered Load per route
Equation 4 Equation 4
If the applied Convergence Event does not cause instantaneous traffic If the applied Convergence Event does not cause instantaneous traffic
loss for all routes at the Convergence Event Instant, then the Tester loss for all routes at the Convergence Event Instant, then the Tester
SHOULD collect timestamps of the Traffic Start Instant and of the SHOULD collect timestamps of the Traffic Start Instant and of the
Convergence Event Instant, and the Tester SHOULD observe Convergence Convergence Event Instant, and the Tester SHOULD observe Convergence
Packet Loss separately on the Next-Best Egress Interface. When Packet Loss separately on the Next-Best Egress Interface. When
benchmarking Route-Specific Convergence Time, Convergence Packet Loss benchmarking Route-Specific Convergence Time, Convergence Packet Loss
is measured and Equation 5 is applied for each measured route. is measured and Equation 5 is applied for each measured route.
Route-Specific Convergence Time = Route-Specific Convergence Time =
Convergence Packet Loss for specific route/Offered Load per route Convergence Packet Loss for specific route/Offered Load per route
- (Convergence Event Instant - Traffic Start Instant) - (Convergence Event Instant - Traffic Start Instant)
Equation 5 Equation 5
The Convergence Event Instant and Traffic Start Instant SHOULD be
collected by the Tester.
The Route-Specific Convergence Time benchmarks enable minimum, The Route-Specific Convergence Time benchmarks enable minimum,
maximum, average, and median convergence time measurements to be maximum, average, and median convergence time measurements to be
reported by comparing the results for the different route entries. reported by comparing the results for the different route entries.
It also enables benchmarking of convergence time when configuring a It also enables benchmarking of convergence time when configuring a
priority value for route entry(ies). Since multiple Route-Specific priority value for route entry(ies). Since multiple Route-Specific
Convergence Times can be measured it is possible to have an array of Convergence Times can be measured it is possible to have an array of
results. The format for reporting Route-Specific Convergence Time is results. The format for reporting Route-Specific Convergence Time is
provided in [Po10m]. provided in [Po11m].
Measurement Units: seconds
Issues: None Measurement Units: seconds (and fractions)
See Also: See Also:
Convergence Event, Convergence Packet Loss, Connectivity Packet Loss, Route-Specific Loss-Derived Method, Convergence Event, Convergence
Event Instant, Convergence Packet Loss, Connectivity Packet Loss,
Route Convergence Route Convergence
3.6.4. Loss-Derived Convergence Time 3.6.4. Loss-Derived Convergence Time
Definition: Definition:
The average Route Convergence time for all routes in FIB, as The average Route Convergence time for all routes in the Forwarding
calculated from the amount of packet loss during convergence. Information Base (FIB), as calculated from the amount of Impaired
Packets [Section 3.8.1] during convergence.
Discussion: Discussion:
Loss-Derived Convergence Time is measured using the Loss-Derived Loss-Derived Convergence Time is measured using the Loss-Derived
Method. Method.
If the applied Convergence Event causes instantaneous traffic loss If the applied Convergence Event causes instantaneous traffic loss
for all routes at the Convergence Event Instant, Connectivity Packet for all routes at the Convergence Event Instant, Connectivity Packet
Loss should be observed. Connectivity Packet Loss is the combined Loss [Section 3.7.3] should be observed. Connectivity Packet Loss is
packet loss observed on Preferred Egress Interface and Next-Best the combined Impaired Packet count observed on Preferred Egress
Egress Interface. When benchmarking Loss-Derived Convergence Time, Interface and Next-Best Egress Interface. When benchmarking Loss-
Connectivity Packet Loss is measured and Equation 6 is applied. Derived Convergence Time, Connectivity Packet Loss is measured and
Equation 6 is applied.
Loss-Derived Convergence Time = Loss-Derived Convergence Time =
Connectivity Packet Loss/Offered Load Connectivity Packet Loss/Offered Load
Equation 6 Equation 6
If the applied Convergence Event does not cause instantaneous traffic If the applied Convergence Event does not cause instantaneous traffic
loss for all routes at the Convergence Event Instant, then the Tester loss for all routes at the Convergence Event Instant, then the Tester
SHOULD collect timestamps of the Start Traffic Instant and of the SHOULD collect timestamps of the Start Traffic Instant and of the
Convergence Event Instant and the Tester SHOULD observe Convergence Convergence Event Instant and the Tester SHOULD observe Convergence
Packet Loss separately on the Next-Best Egress Interface. When Packet Loss [Section 3.7.2] separately on the Next-Best Egress
benchmarking Loss-Derived Convergence Time, Convergence Packet Loss Interface. When benchmarking Loss-Derived Convergence Time,
is measured and Equation 7 is applied. Convergence Packet Loss is measured and Equation 7 is applied.
Loss-Derived Convergence Time = Loss-Derived Convergence Time =
Convergence Packet Loss/Offered Load Convergence Packet Loss/Offered Load
- (Convergence Event Instant - Traffic Start Instant) - (Convergence Event Instant - Traffic Start Instant)
Equation 7 Equation 7
The Convergence Event Instant and Traffic Start Instant SHOULD be Measurement Units: seconds (and fractions)
collected by the Tester.
Measurement Units: seconds
Issues: None
See Also: See Also:
Convergence Packet Loss, Connectivity Packet Loss, Route Convergence Convergence Packet Loss, Connectivity Packet Loss, Route Convergence,
Loss-Derived Method
3.6.5. Route Loss of Connectivity Period 3.6.5. Route Loss of Connectivity Period
Definition: Definition:
The time duration of traffic loss for a specific route entry The time duration of packet impairments for a specific route entry
following a Convergence Event until Full Convergence completion, as following a Convergence Event until Full Convergence completion, as
observed using the Route-Specific Loss-Derived Method. observed using the Route-Specific Loss-Derived Method.
Discussion: Discussion:
In general the Route Loss of Connectivity Period is not equal to the In general the Route Loss of Connectivity Period is not equal to the
Route-Specific Convergence Time. If the DUT continues to forward Route-Specific Convergence Time. If the DUT continues to forward
traffic to the Preferred Egress Interface after the Convergence Event traffic to the Preferred Egress Interface after the Convergence Event
is applied then the Route Loss of Connectivity Period will be smaller is applied then the Route Loss of Connectivity Period will be smaller
than the Route-Specific Convergence Time. This is also specifically than the Route-Specific Convergence Time. This is also specifically
the case after reversing a failure event. the case after reversing a failure event.
The Route Loss of Connectivity Period may be equal to the Route- The Route Loss of Connectivity Period may be equal to the Route-
Specific Convergence Time if, as a characteristic of the Convergence Specific Convergence Time if, as a characteristic of the Convergence
Event, traffic for all routes starts dropping instantaneously on the Event, traffic for all routes starts dropping instantaneously on the
Convergence Event Instant. See discussion in [Po10m]. Convergence Event Instant. See discussion in [Po11m].
For the testcases described in [Po10m] the Route Loss of Connectivity For the test cases described in [Po11m] the Route Loss of
Period is expected to be a single Loss Period [Ko02]. Connectivity Period is expected to be a single Loss Period [Ko02].
When benchmarking Route Loss of Connectivity Period, Connectivity When benchmarking Route Loss of Connectivity Period, Connectivity
Packet Loss is measured for each route and Equation 8 is applied for 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 each measured route entry. The calculation is equal to Equation 4 in
Section 3.6.3. Section 3.6.3.
Route Loss of Connectivity Period = Route Loss of Connectivity Period =
Connectivity Packet Loss for specific route/Offered Load per route Connectivity Packet Loss for specific route/Offered Load per route
Equation 8 Equation 8
Route Loss of Connectivity Period SHOULD be measured using Route- Route Loss of Connectivity Period SHOULD be measured using Route-
Specific Loss-Derived Method. Specific Loss-Derived Method.
Measurement Units: seconds Measurement Units: seconds (and fractions)
Issues: None
See Also: See Also:
Route-Specific Convergence Time, Route-Specific Loss-Derived Method, Route-Specific Convergence Time, Route-Specific Loss-Derived Method,
Connectivity Packet Loss Connectivity Packet Loss
3.6.6. Loss-Derived Loss of Connectivity Period 3.6.6. Loss-Derived Loss of Connectivity Period
Definition: Definition:
The average time duration of traffic loss for all routes following a The average time duration of packet impairments for all routes
Convergence Event until Full Convergence completion, as observed following a Convergence Event until Full Convergence completion, as
using the Loss-Derived Method. observed using the Loss-Derived Method.
Discussion: Discussion:
In general the Loss-Derived Loss of Connectivity Period is not equal In general the Loss-Derived Loss of Connectivity Period is not equal
to the Loss-Derived Convergence Time. If the DUT continues to to the Loss-Derived Convergence Time. If the DUT continues to
forward traffic to the Preferred Egress Interface after the forward traffic to the Preferred Egress Interface after the
Convergence Event is applied then the Loss-Derived Loss of Convergence Event is applied then the Loss-Derived Loss of
Connectivity Period will be smaller than the Loss-Derived Convergence Connectivity Period will be smaller than the Loss-Derived Convergence
Time. This is also specifically the case after reversing a failure Time. This is also specifically the case after reversing a failure
event. event.
The Loss-Derived Loss of Connectivity Period may be equal to the The Loss-Derived Loss of Connectivity Period may be equal to the
Loss-Derived Convergence Time if, as a characteristic of the Loss-Derived Convergence Time if, as a characteristic of the
Convergence Event, traffic for all routes starts dropping Convergence Event, traffic for all routes starts dropping
instantaneously on the Convergence Event Instant. See discussion in instantaneously on the Convergence Event Instant. See discussion in
[Po10m]. [Po11m].
For the testcases described in [Po10m] each route's Route Loss of For the test cases described in [Po11m] each route's Route Loss of
Connectivity Period is expected to be a single Loss Period [Ko02]. Connectivity Period is expected to be a single Loss Period [Ko02].
When benchmarking Loss-Derived Loss of Connectivity Period, When benchmarking Loss-Derived Loss of Connectivity Period,
Connectivity Packet Loss is measured for all routes and Equation 9 is 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. applied. The calculation is equal to Equation 6 in Section 3.6.4.
Loss-Derived Loss of Connectivity Period = Loss-Derived Loss of Connectivity Period =
Connectivity Packet Loss for all routes/Offered Load Connectivity Packet Loss for all routes/Offered Load
Equation 9 Equation 9
Loss-Derived Loss of Connectivity Period SHOULD be measured using Loss-Derived Loss of Connectivity Period SHOULD be measured using
Loss-Derived Method. Loss-Derived Method.
Measurement Units: seconds Measurement Units: seconds (and fractions)
Issues: None
See Also: See Also:
Loss-Derived Convergence Time, Loss-Derived Method, Connectivity Loss-Derived Convergence Time, Loss-Derived Method, Connectivity
Packet Loss Packet Loss
3.7. Measurement Terms 3.7. Measurement Terms
3.7.1. Convergence Event 3.7.1. Convergence Event
Definition: Definition:
The occurrence of a planned or unplanned event in the network that The occurrence of an event in the network that will result in a
will result in a change in the egress interface of the Device Under change in the egress interface of the Device Under Test (DUT) for
Test (DUT) for routed packets. routed packets.
Discussion: Discussion:
Convergence Events include but are not limited to link loss, routing All test cases in [Po11m] are defined such that a Convergence Event
protocol session loss, router failure, configuration change, and results in a change of egress interface of the DUT. Local or remote
better next-hop learned via a routing protocol. triggers that cause a route calculation which does not result in a
change in forwarding are not considered.
Measurement Units: N/A Measurement Units: N/A
Issues: None
See Also: Convergence Event Instant See Also: Convergence Event Instant
3.7.2. Packet Loss 3.7.2. Convergence Packet Loss
Definition:
The number of packets that should have been forwarded by a DUT under
a constant Offered Load that were not forwarded due to lack of
resources.
Discussion:
Packet Loss is a modified version of the term "Frame Loss Rate" as
defined in [Br91]. The term "Frame Loss" is intended for Ethernet
Frames while "Packet Loss" is intended for IP packets.
Measurement units: Number of offered packets that are not forwarded.
Issues: None
See Also: Convergence Packet Loss
3.7.3. Convergence Packet Loss
Definition: Definition:
The number of packets lost due to a Convergence Event until Full The number of Impaired Packets [Section 3.8.1] as observed on the
Convergence completes, as observed on the Next-Best Egress Interface. Next-Best Egress Interface of the DUT during convergence.
Discussion: Discussion:
Convergence Packet Loss is observed on the Next-Best Egress An Impaired Packet is considered as a lost packet.
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 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 Measurement Units: number of packets
Issues: None
See Also: See Also:
Packet Loss, Full Convergence, Convergence Event, Connectivity Packet Connectivity Packet Loss
Loss
3.7.4. Connectivity Packet Loss 3.7.3. Connectivity Packet Loss
Definition: Definition:
The number of packets lost due to a Convergence Event until Full The number of Impaired Packets observed on all DUT egress interfaces
Convergence completes. during convergence.
Discussion: Discussion:
Connectivity Packet Loss is observed on all DUT egress interfaces. An Impaired Packet is considered as a lost packet. Connectivity
Packet Loss is equal to Convergence Packet Loss if the Convergence
Connectivity Packet Loss includes packets that were lost and packets Event causes instantaneous traffic loss for all egress interfaces of
that were delayed due to buffering. The maximum acceptable the DUT except for the Next-Best Egress Interface.
Forwarding Delay (Forwarding Delay Threshold) is a parameter of the
methodology, if it is applied it MUST be reported.
Measurement Units: number of packets Measurement Units: number of packets
Issues: None
See Also: See Also:
Packet Loss, Route Loss of Connectivity Period, Convergence Event,
Convergence Packet Loss Convergence Packet Loss
3.7.5. Packet Sampling Interval 3.7.4. Packet Sampling Interval
Definition: Definition:
The interval at which the Tester (test equipment) polls to make The interval at which the Tester (test equipment) polls to make
measurements for arriving packets. measurements for arriving packets.
Discussion: Discussion:
At least one packet per route for all routes matched in the Offered At least one packet per route for all routes matched in the Offered
Load MUST be offered to the DUT within the Packet Sampling Interval. Load MUST be offered to the DUT within the Packet Sampling Interval.
skipping to change at page 24, line 52 skipping to change at page 23, line 19
may cause fluctuations of the Forwarding Rate observation and can may cause fluctuations of the Forwarding Rate observation and can
prevent correct observation of the different convergence time prevent correct observation of the different convergence time
instants. instants.
The value of the Packet Sampling Interval only contributes to the The value of the Packet Sampling Interval only contributes to the
measurement accuracy of the Rate-Derived Method. For maximum measurement accuracy of the Rate-Derived Method. For maximum
accuracy the value for the Packet Sampling Interval SHOULD be as accuracy the value for the Packet Sampling Interval SHOULD be as
small as possible, but the presence of IPDV may enforce using a small as possible, but the presence of IPDV may enforce using a
larger Packet Sampling Interval. larger Packet Sampling Interval.
Measurement Units: seconds Measurement Units: seconds (and fractions)
Issues: None
See Also: Rate-Derived Method See Also: Rate-Derived Method
3.7.6. Sustained Convergence Validation Time 3.7.5. Sustained Convergence Validation Time
Definition: Definition:
The amount of time for which the completion of Full Convergence is The amount of time for which the completion of Full Convergence is
maintained without additional packet loss. maintained without additional Impaired Packets being observed.
Discussion: Discussion:
The purpose of the Sustained Convergence Validation Time is to The purpose of the Sustained Convergence Validation Time is to
produce convergence benchmarks protected against fluctuation in produce convergence benchmarks protected against fluctuation in
Forwarding Rate after the completion of Full Convergence is observed. Forwarding Rate after the completion of Full Convergence is observed.
The RECOMMENDED Sustained Convergence Validation Time to be used is The RECOMMENDED Sustained Convergence Validation Time to be used is
the time to send 5 consecutive packets to each destination with a the time to send 5 consecutive packets to each destination with a
minimum of 5 seconds. The BMWG selected 5 seconds based upon [Br99] minimum of 5 seconds. The Benchmarking Methodology Working Group
which recommends waiting 2 seconds for residual frames to arrive (BMWG) selected 5 seconds based upon [Br99] which recommends waiting
(this is the Forwarding Delay Threshold for the last packet sent) and 2 seconds for residual frames to arrive (this is the Forwarding Delay
5 seconds for DUT restabilization. Threshold for the last packet sent) and 5 seconds for DUT
restabilization.
Measurement Units: seconds
Issues: None Measurement Units: seconds (and fractions)
See Also: See Also:
Full Convergence, Convergence Recovery Instant Full Convergence, Convergence Recovery Instant
3.7.7. Forwarding Delay Threshold 3.7.6. Forwarding Delay Threshold
Definition: Definition:
The maximum waiting time threshold used to distinguish between The maximum waiting time threshold used to distinguish between
packets with very long delay and lost packets that will never arrive. packets with very long delay and lost packets that will never arrive.
Discussion: Discussion:
Applying a Forwarding Delay Threshold allows to consider packets with Applying a Forwarding Delay Threshold allows to consider packets with
a too large Forwarding Delay as being lost, as is required for some a too large Forwarding Delay as being lost, as is required for some
applications (e.g. voice, video, etc.). The Forwarding Delay applications (e.g. voice, video, etc.). The Forwarding Delay
Threshold is a parameter of the methodology, if it is applied it MUST Threshold is a parameter of the methodology, and it MUST be reported.
be reported. [Br99] recommends waiting 2 seconds for residual frames to arrive.
Measurement Units: seconds Measurement Units: seconds (and fractions)
Issues: None
See Also: See Also:
Convergence Packet Loss, Connectivity Packet Loss Convergence Packet Loss, Connectivity Packet Loss
3.8. Miscellaneous Terms 3.8. Miscellaneous Terms
3.8.1. Stale Forwarding 3.8.1. Impaired Packet
Definition: Definition:
Forwarding of traffic to route entries that no longer exist or to A packet that experienced at least one of the following impairments:
route entries with next-hops that are no longer preferred. loss, excessive Forwarding Delay, corruption, duplication,
reordering.
Discussion: Discussion:
Stale Forwarding can be caused by a Convergence Event and can A lost packet, a packet with a Forwarding Delay exceeding the
manifest as a "black-hole" or microloop that produces packet loss, or Forwarding Delay Threshold, a corrupted packet, a Duplicate Packet
out-of-order packets, or delayed packets. Stale Forwarding can exist [Po06], and an Out-of-Order Packet [Po06] are Impaired Packets.
until Network Convergence is completed.
Measurement Units: N/A
Issues: None
See Also: Network Convergence
3.8.2. Nested Convergence Event
Definition:
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 Packet ordering is observed for each individual flow (See [Th00],
different neighbors. A possible observation from a Nested Section 3) of the Offered Load.
Convergence Event will be the withdrawal of routes from one neighbor
while the routes of another neighbor are being installed.
Measurement Units: N/A Measurement Units: N/A
Issues: None See Also: Forwarding Delay Threshold
See Also: Convergence Event
4. Security Considerations 4. Security Considerations
Benchmarking activities as described in this memo are limited to Benchmarking activities as described in this memo are limited to
technology characterization using controlled stimuli in a laboratory technology characterization using controlled stimuli in a laboratory
environment, with dedicated address space and the constraints environment, with dedicated address space and the constraints
specified in the sections above. specified in the sections above.
The benchmarking network topology will be an independent test setup The benchmarking network topology will be an independent test setup
and MUST NOT be connected to devices that may forward the test and MUST NOT be connected to devices that may forward the test
skipping to change at page 27, line 32 skipping to change at page 25, line 28
from the DUT/SUT SHOULD be identical in the lab and in production from the DUT/SUT SHOULD be identical in the lab and in production
networks. networks.
5. IANA Considerations 5. IANA Considerations
This document requires no 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,
Peter De Vriendt, Anuj Dewagan and the BMWG for their contributions Peter De Vriendt, Anuj Dewagan, Adrian Farrel, Stewart Bryant,
to this work. Francis Dupont, and the Benchmarking Methodology Working Group for
their contributions to this work.
7. References
7.1. Normative References 7. Normative References
[Br91] Bradner, S., "Benchmarking terminology for network [Br91] Bradner, S., "Benchmarking terminology for network
interconnection devices", RFC 1242, July 1991. 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
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[Br99] Bradner, S. and J. McQuaid, "Benchmarking Methodology for [Br99] Bradner, S. and J. McQuaid, "Benchmarking Methodology for
Network Interconnect Devices", RFC 2544, March 1999. Network Interconnect Devices", RFC 2544, March 1999.
skipping to change at page 28, line 21 skipping to change at page 26, line 18
[Ho08] Hopps, C., "Routing IPv6 with IS-IS", RFC 5308, [Ho08] Hopps, C., "Routing IPv6 with IS-IS", RFC 5308,
October 2008. October 2008.
[Ko02] Koodli, R. and R. Ravikanth, "One-way Loss Pattern Sample [Ko02] Koodli, R. and R. Ravikanth, "One-way Loss Pattern Sample
Metrics", RFC 3357, August 2002. Metrics", RFC 3357, August 2002.
[Ma98] Mandeville, R., "Benchmarking Terminology for LAN Switching [Ma98] Mandeville, R., "Benchmarking Terminology for LAN Switching
Devices", RFC 2285, February 1998. Devices", RFC 2285, February 1998.
[Mo06] Morton, A., Ciavattone, L., Ramachandran, G., Shalunov, S.,
and J. Perser, "Packet Reordering Metrics", RFC 4737,
November 2006.
[Mo98] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998. [Mo98] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998.
[Po06] Poretsky, S., Perser, J., Erramilli, S., and S. Khurana, [Po06] Poretsky, S., Perser, J., Erramilli, S., and S. Khurana,
"Terminology for Benchmarking Network-layer Traffic Control "Terminology for Benchmarking Network-layer Traffic Control
Mechanisms", RFC 4689, October 2006. Mechanisms", RFC 4689, October 2006.
[Po09a] Poretsky, S., "Considerations for Benchmarking Link-State [Po11m] Poretsky, S., Imhoff, B., and K. Michielsen, "Benchmarking
IGP Data Plane Route Convergence",
draft-ietf-bmwg-igp-dataplane-conv-app-17 (work in
progress), March 2009.
[Po10m] Poretsky, S., Imhoff, B., and K. Michielsen, "Benchmarking
Methodology for Link-State IGP Data Plane Route Methodology for Link-State IGP Data Plane Route
Convergence", draft-ietf-bmwg-igp-dataplane-conv-meth-20 Convergence", draft-ietf-bmwg-igp-dataplane-conv-meth-23
(work in progress), March 2010. (work in progress), January 2011.
7.2. Informative References
[Ca01] Casner, S., Alaettinoglu, C., and C. Kuan, "A Fine-Grained
View of High Performance Networking", NANOG 22, June 2001.
[Ci03] Ciavattone, L., Morton, A., and G. Ramachandran, [Th00] Thaler, D. and C. Hopps, "Multipath Issues in Unicast and
"Standardized Active Measurements on a Tier 1 IP Backbone", Multicast Next-Hop Selection", RFC 2991, November 2000.
IEEE Communications Magazine p90-97, May 2003.
Authors' Addresses 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
 End of changes. 155 change blocks. 
431 lines changed or deleted 318 lines changed or added

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