draft-ietf-bmwg-igp-dataplane-conv-term-19.txt   draft-ietf-bmwg-igp-dataplane-conv-term-20.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: April 29, 2010 Juniper Networks Expires: September 9, 2010 Juniper Networks
K. Michielsen K. Michielsen
Cisco Systems Cisco Systems
October 26, 2009 March 8, 2010
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-19 draft-ietf-bmwg-igp-dataplane-conv-term-20
Abstract
This document describes the terminology for benchmarking Interior
Gateway Protocol (IGP) Route Convergence. The terminology is to be
used for benchmarking IGP convergence time through externally
observable (black box) data plane measurements. The terminology can
be applied to any link-state IGP, such as ISIS and OSPF.
Status of this Memo Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79. This document may contain material provisions of BCP 78 and BCP 79.
from IETF Documents or IETF Contributions published or made publicly
available before November 10, 2008. The person(s) controlling the
copyright in some of this material may not have granted the IETF
Trust the right to allow modifications of such material outside the
IETF Standards Process. Without obtaining an adequate license from
the person(s) controlling the copyright in such materials, this
document may not be modified outside the IETF Standards Process, and
derivative works of it may not be created outside the IETF Standards
Process, except to format it for publication as an RFC or to
translate it into languages other than English.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on April 29, 2010. This Internet-Draft will expire on September 9, 2010.
Copyright Notice 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. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents in effect on the date of Provisions Relating to IETF Documents
publication of this document (http://trustee.ietf.org/license-info). (http://trustee.ietf.org/license-info) in effect on the date of
Please review these documents carefully, as they describe your rights publication of this document. Please review these documents
and restrictions with respect to this document. carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
Abstract 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 This document may contain material from IETF Documents or IETF
Gateway Protocol (IGP) Route Convergence. The terminology is to be Contributions published or made publicly available before November
used for benchmarking IGP convergence time through externally 10, 2008. The person(s) controlling the copyright in some of this
observable (black box) data plane measurements. The terminology can material may not have granted the IETF Trust the right to allow
be applied to any link-state IGP, such as ISIS and OSPF. 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 Table of Contents
1. Introduction and Scope . . . . . . . . . . . . . . . . . . . . 4 1. Introduction and Scope . . . . . . . . . . . . . . . . . . . . 5
2. Existing Definitions . . . . . . . . . . . . . . . . . . . . . 4 2. Existing Definitions . . . . . . . . . . . . . . . . . . . . . 5
3. Term Definitions . . . . . . . . . . . . . . . . . . . . . . . 4 3. Term Definitions . . . . . . . . . . . . . . . . . . . . . . . 5
3.1. Convergence Types . . . . . . . . . . . . . . . . . . . . 5 3.1. Convergence Types . . . . . . . . . . . . . . . . . . . . 6
3.1.1. Route Convergence . . . . . . . . . . . . . . . . . . 5 3.1.1. Route Convergence . . . . . . . . . . . . . . . . . . 6
3.1.2. Full Convergence . . . . . . . . . . . . . . . . . . . 5 3.1.2. Full Convergence . . . . . . . . . . . . . . . . . . . 6
3.1.3. Network Convergence . . . . . . . . . . . . . . . . . 6 3.1.3. Network Convergence . . . . . . . . . . . . . . . . . 7
3.2. Instants . . . . . . . . . . . . . . . . . . . . . . . . . 6 3.2. Instants . . . . . . . . . . . . . . . . . . . . . . . . . 7
3.2.1. Traffic Start Instant . . . . . . . . . . . . . . . . 6 3.2.1. Traffic Start Instant . . . . . . . . . . . . . . . . 7
3.2.2. Convergence Event Instant . . . . . . . . . . . . . . 7 3.2.2. Convergence Event Instant . . . . . . . . . . . . . . 8
3.2.3. Convergence Recovery Instant . . . . . . . . . . . . . 7 3.2.3. Convergence Recovery Instant . . . . . . . . . . . . . 8
3.2.4. First Route Convergence Instant . . . . . . . . . . . 8 3.2.4. First Route Convergence Instant . . . . . . . . . . . 9
3.3. Transitions . . . . . . . . . . . . . . . . . . . . . . . 9 3.3. Transitions . . . . . . . . . . . . . . . . . . . . . . . 9
3.3.1. Convergence Event Transition . . . . . . . . . . . . . 9 3.3.1. Convergence Event Transition . . . . . . . . . . . . . 9
3.3.2. Convergence Recovery Transition . . . . . . . . . . . 9 3.3.2. Convergence Recovery Transition . . . . . . . . . . . 10
3.4. Interfaces . . . . . . . . . . . . . . . . . . . . . . . . 10 3.4. Interfaces . . . . . . . . . . . . . . . . . . . . . . . . 11
3.4.1. Local Interface . . . . . . . . . . . . . . . . . . . 10 3.4.1. Local Interface . . . . . . . . . . . . . . . . . . . 11
3.4.2. Remote Interface . . . . . . . . . . . . . . . . . . . 10 3.4.2. Remote Interface . . . . . . . . . . . . . . . . . . . 11
3.4.3. Preferred Egress Interface . . . . . . . . . . . . . . 11 3.4.3. Preferred Egress Interface . . . . . . . . . . . . . . 11
3.4.4. Next-Best Egress Interface . . . . . . . . . . . . . . 11 3.4.4. Next-Best Egress Interface . . . . . . . . . . . . . . 12
3.5. Benchmarking Methods . . . . . . . . . . . . . . . . . . . 11 3.5. Benchmarking Methods . . . . . . . . . . . . . . . . . . . 12
3.5.1. Rate-Derived Method . . . . . . . . . . . . . . . . . 11 3.5.1. Rate-Derived Method . . . . . . . . . . . . . . . . . 12
3.5.2. Loss-Derived Method . . . . . . . . . . . . . . . . . 13 3.5.2. Loss-Derived Method . . . . . . . . . . . . . . . . . 14
3.5.3. Route-Specific Loss-Derived Method . . . . . . . . . . 14 3.5.3. Route-Specific Loss-Derived Method . . . . . . . . . . 16
3.6. Benchmarks . . . . . . . . . . . . . . . . . . . . . . . . 15 3.6. Benchmarks . . . . . . . . . . . . . . . . . . . . . . . . 17
3.6.1. Full Convergence Time . . . . . . . . . . . . . . . . 15 3.6.1. Full Convergence Time . . . . . . . . . . . . . . . . 17
3.6.2. First Route Convergence Time . . . . . . . . . . . . . 16 3.6.2. First Route Convergence Time . . . . . . . . . . . . . 17
3.6.3. Route-Specific Convergence Time . . . . . . . . . . . 17 3.6.3. Route-Specific Convergence Time . . . . . . . . . . . 18
3.6.4. Loss-Derived Convergence Time . . . . . . . . . . . . 18 3.6.4. Loss-Derived Convergence Time . . . . . . . . . . . . 20
3.6.5. Route Loss of Connectivity Period . . . . . . . . . . 19 3.6.5. Route Loss of Connectivity Period . . . . . . . . . . 21
3.6.6. Loss-Derived Loss of Connectivity Period . . . . . . . 20 3.6.6. Loss-Derived Loss of Connectivity Period . . . . . . . 22
3.7. Measurement Terms . . . . . . . . . . . . . . . . . . . . 21 3.7. Measurement Terms . . . . . . . . . . . . . . . . . . . . 23
3.7.1. Convergence Event . . . . . . . . . . . . . . . . . . 21 3.7.1. Convergence Event . . . . . . . . . . . . . . . . . . 23
3.7.2. Packet Loss . . . . . . . . . . . . . . . . . . . . . 22 3.7.2. Packet Loss . . . . . . . . . . . . . . . . . . . . . 23
3.7.3. Convergence Packet Loss . . . . . . . . . . . . . . . 22 3.7.3. Convergence Packet Loss . . . . . . . . . . . . . . . 23
3.7.4. Connectivity Packet Loss . . . . . . . . . . . . . . . 23 3.7.4. Connectivity Packet Loss . . . . . . . . . . . . . . . 24
3.7.5. Packet Sampling Interval . . . . . . . . . . . . . . . 23 3.7.5. Packet Sampling Interval . . . . . . . . . . . . . . . 25
3.7.6. Sustained Convergence Validation Time . . . . . . . . 24 3.7.6. Sustained Convergence Validation Time . . . . . . . . 25
3.8. Miscellaneous Terms . . . . . . . . . . . . . . . . . . . 24 3.7.7. Forwarding Delay Threshold . . . . . . . . . . . . . . 26
3.8.1. Stale Forwarding . . . . . . . . . . . . . . . . . . . 24 3.8. Miscellaneous Terms . . . . . . . . . . . . . . . . . . . 26
3.8.2. Nested Convergence Event . . . . . . . . . . . . . . . 25 3.8.1. Stale Forwarding . . . . . . . . . . . . . . . . . . . 26
4. Security Considerations . . . . . . . . . . . . . . . . . . . 25 3.8.2. Nested Convergence Event . . . . . . . . . . . . . . . 27
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26 4. Security Considerations . . . . . . . . . . . . . . . . . . . 27
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 26 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 26 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 28
7.1. Normative References . . . . . . . . . . . . . . . . . . . 26 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 28
7.2. Informative References . . . . . . . . . . . . . . . . . . 27 7.1. Normative References . . . . . . . . . . . . . . . . . . . 28
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 27 7.2. Informative References . . . . . . . . . . . . . . . . . . 29
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 29
1. Introduction and Scope 1. Introduction and Scope
This draft describes the terminology for benchmarking Link-State This draft describes the terminology for benchmarking Link-State
Interior Gateway Protocol (IGP) Convergence. The motivation and Interior Gateway Protocol (IGP) Convergence. The motivation and
applicability for this benchmarking is provided in [Po09a]. The applicability for this benchmarking is provided in [Po09a]. The
methodology to be used for this benchmarking is described in [Po09m]. methodology to be used for this benchmarking is described in [Po09m].
The purpose of this document is to introduce new terms required to The purpose of this document is to introduce new terms required to
complete execution of the IGP Route Methodology [Po09m]. complete execution of the IGP Route Methodology [Po09m].
skipping to change at page 4, line 31 skipping to change at page 5, line 31
This document uses existing terminology defined in other BMWG work. This document uses existing terminology defined in other BMWG work.
Examples include, but are not limited to: Examples include, but are not limited to:
Frame Loss Rate [Ref.[Br91], section 3.6] 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.2] Out-of-Order Packet [Ref.[Po06], section 3.3.4]
Duplicate Packet [Ref.[Po06], section 3.3.3] Duplicate Packet [Ref.[Po06], section 3.3.5]
Packet Reordering [Ref.[Mo06], section 3.3] 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]
Jitter [Ref.[Po06], section 3.2.5]
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.
skipping to change at page 8, line 13 skipping to change at page 9, line 13
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 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 DUT forwards traffic to all destinations over the
Next-Best Egress Interface. Next-Best Egress Interface.
When using the Rate-Derived Method, the Convergence Recovery Instant
falls within the Packet Sampling Interval preceding the first
interval where the observed Forwarding Rate on the Next-Best Egress
Interface equals the Offered Load.
Measurement Units: Measurement Units:
hh:mm:ss:nnn:uuu, where 'nnn' is milliseconds and 'uuu' is hh:mm:ss:nnn:uuu, where 'nnn' is milliseconds and 'uuu' is
microseconds. microseconds.
Issues: None Issues: None
See Also: See Also:
Sustained Convergence Validation Time, Full Convergence Sustained Convergence Validation Time, Full Convergence
skipping to change at page 11, line 35 skipping to change at page 12, line 26
Definition: Definition:
The outbound interface from the DUT for traffic routed to the second- The outbound interface from the DUT for traffic routed to the second-
best next-hop. 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.
The Next-Best Egress Interface is of the same media type and link
speed as the Preferred Egress Interface.
Measurement Units: N/A Measurement Units: N/A
Issues: None Issues: None
See Also: Preferred Egress Interface See Also: Preferred Egress Interface
3.5. Benchmarking Methods 3.5. Benchmarking Methods
3.5.1. Rate-Derived Method 3.5.1. Rate-Derived Method
skipping to change at page 12, line 41 skipping to change at page 13, line 36
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.
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 The Offered Load, Jitter, the number of routes, and the Packet
Interval influence the observations for the Rate-Derived Method. It Sampling Interval influence the observations for the Rate-Derived
may be difficult to identify the different convergence time instants Method. It may be difficult to identify the different convergence
in the Rate-Derived Convergence Graph. For example, it is possible time instants in the Rate-Derived Convergence Graph. For example, it
that a Convergence Event causes the Forwarding Rate to drop to zero, is possible that a Convergence Event causes the Forwarding Rate to
while this may not be observed in the Forwarding Rate measurements if drop to zero, while this may not be observed in the Forwarding Rate
the Packet Sampling Interval is too large. 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 Metrics measured at the Packet Sampling Interval MUST include
Forwarding Rate and packet loss. Forwarding Rate and packet loss.
Rate-Derived Method is a RECOMMENDED method to measure convergence Rate-Derived Method is a RECOMMENDED method to measure convergence
time benchmarks. time benchmarks.
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 a timestamp of Convergence Event Instant, the Tester SHOULD collect a timestamp of
skipping to change at page 16, line 4 skipping to change at page 17, line 22
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.
Discussion: Discussion:
Using the Rate-Derived Method, Full Convergence Time can be Using the Rate-Derived Method, Full Convergence Time can be
calculated as the time difference between the Convergence Event 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 = Full Convergence Time =
Convergence Recovery Instant - Convergence Event Instant Convergence Recovery Instant - Convergence Event Instant
Equation 1 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 [Po09m], it is expected that Full For the testcases described in [Po09m], 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-
skipping to change at page 16, line 44 skipping to change at page 18, line 14
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:
Using the Rate-Derived Method, First Route Convergence Time can be Using the Rate-Derived Method, First Route Convergence Time can be
calculated as the time difference between the Convergence Event calculated as the time difference between the Convergence Event
Instant and the First Route Convergence Instant, as shown with Instant and the First Route Convergence Instant, as shown with
Equation 2. 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 2 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 [Po09m], it is expected that First For the testcases described in [Po09m], 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
skipping to change at page 17, line 41 skipping to change at page 19, line 10
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 packet loss observed on Preferred Egress Interface and Next-Best
Egress Interface. When benchmarking Route-Specific Convergence Time, Egress Interface. When benchmarking Route-Specific Convergence Time,
Connectivity Packet Loss is measured and Equation 3 is applied for Connectivity Packet Loss is measured and Equation 4 is applied for
each measured route. The calculation is equal to Equation 7 in each measured route. The calculation is equal to Equation 8 in
Section 3.6.5. 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 3 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 4 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 4 Equation 5
The Convergence Event Instant and Traffic Start Instant SHOULD be The Convergence Event Instant and Traffic Start Instant SHOULD be
collected by the Tester. 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
skipping to change at page 19, line 6 skipping to change at page 20, line 22
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 should be observed. Connectivity Packet Loss is the combined
packet loss observed on Preferred Egress Interface and Next-Best packet loss observed on Preferred Egress Interface and Next-Best
Egress Interface. When benchmarking Loss-Derived Convergence Time, Egress Interface. When benchmarking Loss-Derived Convergence Time,
Connectivity Packet Loss is measured and Equation 5 is applied. 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 5 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 separately on the Next-Best Egress Interface. When
benchmarking Loss-Derived Convergence Time, Convergence Packet Loss benchmarking Loss-Derived Convergence Time, Convergence Packet Loss
is measured and Equation 6 is applied. 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 6 Equation 7
The Convergence Event Instant and Traffic Start Instant SHOULD be The Convergence Event Instant and Traffic Start Instant SHOULD be
collected by the Tester. collected by the Tester.
Measurement Units: seconds Measurement Units: seconds
Issues: None Issues: None
See Also: See Also:
skipping to change at page 20, line 16 skipping to change at page 21, line 31
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 [Po09m]. Convergence Event Instant. See discussion in [Po09m].
For the testcases described in [Po09m] the Route Loss of Connectivity For the testcases described in [Po09m] the Route Loss of Connectivity
Period is expected to be a single Loss Period [Ko02]. 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 7 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 3 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 7 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
Issues: None Issues: None
See Also: See Also:
skipping to change at page 21, line 17 skipping to change at page 22, line 33
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
[Po09m]. [Po09m].
For the testcases described in [Po09m] each route's Route Loss of For the testcases described in [Po09m] 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 8 is Connectivity Packet Loss is measured for all routes and Equation 9 is
applied. The calculation is equal to Equation 5 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 8 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
Issues: None Issues: None
See Also: See Also:
skipping to change at page 22, line 45 skipping to change at page 24, line 12
The number of packets lost due to a Convergence Event until Full The number of packets lost due to a Convergence Event until Full
Convergence completes, as observed on the Next-Best Egress Interface. Convergence completes, as observed on the Next-Best Egress Interface.
Discussion: Discussion:
Convergence Packet Loss is observed on the Next-Best Egress Convergence Packet Loss is observed on the Next-Best Egress
Interface. It only needs to be observed for Convergence Events that Interface. It only needs to be observed for Convergence Events that
do not cause instantaneous traffic loss at Convergence Event Instant. do not cause instantaneous traffic loss at Convergence Event Instant.
Convergence Packet Loss includes packets that were lost and packets Convergence Packet Loss includes packets that were lost and packets
that were delayed due to buffering. The magnitude of an acceptable that were delayed due to buffering. The maximum acceptable
Forwarding Delay is a parameter of the methodology. If a maximum Forwarding Delay (Forwarding Delay Threshold) is a parameter of the
acceptable Forwarding Delay threshold is applied it MUST be reported. methodology, if it is applied it MUST be reported.
Measurement Units: number of packets Measurement Units: number of packets
Issues: None Issues: None
See Also: See Also:
Packet Loss, Full Convergence, Convergence Event, Connectivity Packet Packet Loss, Full Convergence, Convergence Event, Connectivity Packet
Loss Loss
3.7.4. Connectivity Packet Loss 3.7.4. Connectivity Packet Loss
Definition: Definition:
The number of packets lost due to a Convergence Event until Full The number of packets lost due to a Convergence Event until Full
skipping to change at page 23, line 20 skipping to change at page 24, line 36
Definition: Definition:
The number of packets lost due to a Convergence Event until Full The number of packets lost due to a Convergence Event until Full
Convergence completes. Convergence completes.
Discussion: Discussion:
Connectivity Packet Loss is observed on all DUT egress interfaces. Connectivity Packet Loss is observed on all DUT egress interfaces.
Convergence Packet Loss includes packets that were lost and packets Connectivity Packet Loss includes packets that were lost and packets
that were delayed due to buffering. The magnitude of an acceptable that were delayed due to buffering. The maximum acceptable
Forwarding Delay is a parameter of the methodology. If a maximum Forwarding Delay (Forwarding Delay Threshold) is a parameter of the
acceptable Forwarding Delay threshold is applied it MUST be reported. methodology, if it is applied it MUST be reported.
Measurement Units: number of packets Measurement Units: number of packets
Issues: None Issues: None
See Also: See Also:
Packet Loss, Route Loss of Connectivity Period, Convergence Event, Packet Loss, Route Loss of Connectivity Period, Convergence Event,
Convergence Packet Loss Convergence Packet Loss
skipping to change at page 24, line 8 skipping to change at page 25, line 27
Forwarding Rate and received packets. Forwarding Rate and received packets.
Packet Sampling Interval can influence the convergence graph as Packet Sampling Interval can influence the convergence graph as
observed with the Rate-Derived Method. This is particularly true observed with the Rate-Derived Method. This is particularly true
when implementations complete Full Convergence in less time than the when implementations complete Full Convergence in less time than the
Packet Sampling Interval. The Convergence Event Instant and First Packet Sampling Interval. The Convergence Event Instant and First
Route Convergence Instant may not be easily identifiable and the Route Convergence Instant may not be easily identifiable and the
Rate-Derived Method may produce a larger than actual convergence Rate-Derived Method may produce a larger than actual convergence
time. time.
The recommended value for configuration of the Packet Sampling Using a small Packet Sampling Interval in the presence of Jitter
Interval when using the Rate-Derived Method is provided in [Po09m]. [Po06] may cause fluctuations of the Forwarding Rate observation and
For the other benchmark methods the value of the Packet Sampling can prevent correct observation of the different convergence time
Interval does not contribute to the measurement accuracy. instants.
The value of the Packet Sampling Interval only contributes to the
measurement accuracy of the Rate-Derived 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 Measurement Units: seconds
Issues: None Issues: None
See Also: Rate-Derived Method See Also: Rate-Derived Method
3.7.6. Sustained Convergence Validation Time 3.7.6. 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 packet loss.
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 5 The RECOMMENDED Sustained Convergence Validation Time to be used is
seconds. The BMWG selected 5 seconds based upon RFC 2544 [Br99] 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 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. 5 seconds for DUT restabilization.
Measurement Units: seconds Measurement Units: seconds
Issues: None Issues: None
See Also: See Also:
Full Convergence, Convergence Recovery Instant 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. Miscellaneous Terms
3.8.1. Stale Forwarding 3.8.1. Stale Forwarding
Definition: Definition:
Forwarding of traffic to route entries that no longer exist or to Forwarding of traffic to route entries that no longer exist or to
route entries with next-hops that are no longer preferred. route entries with next-hops that are no longer preferred.
Discussion: Discussion:
skipping to change at page 26, line 20 skipping to change at page 28, line 17
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 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. References
7.1. Normative References 7.1. 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.
 End of changes. 41 change blocks. 
123 lines changed or deleted 175 lines changed or added

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