draft-ietf-bmwg-igp-dataplane-conv-term-18.txt   draft-ietf-bmwg-igp-dataplane-conv-term-19.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: January 14, 2010 Juniper Networks Expires: April 29, 2010 Juniper Networks
K. Michielsen K. Michielsen
Cisco Systems Cisco Systems
July 13, 2009 October 26, 2009
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-18 draft-ietf-bmwg-igp-dataplane-conv-term-19
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. This document may contain material
from IETF Documents or IETF Contributions published or made publicly from IETF Documents or IETF Contributions published or made publicly
available before November 10, 2008. The person(s) controlling the available before November 10, 2008. The person(s) controlling the
copyright in some of this material may not have granted the IETF copyright in some of this material may not have granted the IETF
Trust the right to allow modifications of such material outside the Trust the right to allow modifications of such material outside the
IETF Standards Process. Without obtaining an adequate license from IETF Standards Process. Without obtaining an adequate license from
skipping to change at page 1, line 45 skipping to change at page 1, line 45
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 January 14, 2010. This Internet-Draft will expire on April 29, 2010.
Copyright Notice Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the Copyright (c) 2009 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents in effect on the date of Provisions Relating to IETF Documents in effect on the date of
publication of this document (http://trustee.ietf.org/license-info). publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights Please review these documents carefully, as they describe your rights
skipping to change at page 2, line 30 skipping to change at page 2, line 30
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 . . . . . . . . . . . . . . . . . . . . 5
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.1.3. Network Convergence . . . . . . . . . . . . . . . . . 6
3.2. Instants . . . . . . . . . . . . . . . . . . . . . . . . . 6 3.2. Instants . . . . . . . . . . . . . . . . . . . . . . . . . 6
3.2.1. Convergence Event Instant . . . . . . . . . . . . . . 6 3.2.1. Traffic Start Instant . . . . . . . . . . . . . . . . 6
3.2.2. Convergence Recovery Instant . . . . . . . . . . . . . 7 3.2.2. Convergence Event Instant . . . . . . . . . . . . . . 7
3.2.3. First Route Convergence Instant . . . . . . . . . . . 7 3.2.3. Convergence Recovery Instant . . . . . . . . . . . . . 7
3.3. Transitions . . . . . . . . . . . . . . . . . . . . . . . 8 3.2.4. First Route Convergence Instant . . . . . . . . . . . 8
3.3.1. Convergence Event Transition . . . . . . . . . . . . . 8 3.3. Transitions . . . . . . . . . . . . . . . . . . . . . . . 9
3.3.1. Convergence Event Transition . . . . . . . . . . . . . 9
3.3.2. Convergence Recovery Transition . . . . . . . . . . . 9 3.3.2. Convergence Recovery Transition . . . . . . . . . . . 9
3.4. Interfaces . . . . . . . . . . . . . . . . . . . . . . . . 9 3.4. Interfaces . . . . . . . . . . . . . . . . . . . . . . . . 10
3.4.1. Local Interface . . . . . . . . . . . . . . . . . . . 9 3.4.1. Local Interface . . . . . . . . . . . . . . . . . . . 10
3.4.2. Remote Interface . . . . . . . . . . . . . . . . . . . 10 3.4.2. Remote Interface . . . . . . . . . . . . . . . . . . . 10
3.4.3. Preferred Egress Interface . . . . . . . . . . . . . . 10 3.4.3. Preferred Egress Interface . . . . . . . . . . . . . . 11
3.4.4. Next-Best Egress Interface . . . . . . . . . . . . . . 10 3.4.4. Next-Best Egress Interface . . . . . . . . . . . . . . 11
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 . . . . . . . . . . . . . . . . . 12 3.5.2. Loss-Derived Method . . . . . . . . . . . . . . . . . 13
3.5.3. Route-Specific Loss-Derived Method . . . . . . . . . . 13 3.5.3. Route-Specific Loss-Derived Method . . . . . . . . . . 14
3.6. Benchmarks . . . . . . . . . . . . . . . . . . . . . . . . 15 3.6. Benchmarks . . . . . . . . . . . . . . . . . . . . . . . . 15
3.6.1. Full Convergence Time . . . . . . . . . . . . . . . . 15 3.6.1. Full Convergence Time . . . . . . . . . . . . . . . . 15
3.6.2. First Route Convergence Time . . . . . . . . . . . . . 15 3.6.2. First Route Convergence Time . . . . . . . . . . . . . 16
3.6.3. Route-Specific Convergence Time . . . . . . . . . . . 16 3.6.3. Route-Specific Convergence Time . . . . . . . . . . . 17
3.6.4. Loss-Derived Convergence Time . . . . . . . . . . . . 18 3.6.4. Loss-Derived Convergence Time . . . . . . . . . . . . 18
3.6.5. Route Loss of Connectivity Period . . . . . . . . . . 19 3.6.5. Route Loss of Connectivity Period . . . . . . . . . . 19
3.6.6. Loss-Derived Loss of Connectivity Period . . . . . . . 20 3.6.6. Loss-Derived Loss of Connectivity Period . . . . . . . 20
3.7. Measurement Terms . . . . . . . . . . . . . . . . . . . . 21 3.7. Measurement Terms . . . . . . . . . . . . . . . . . . . . 21
3.7.1. Convergence Event . . . . . . . . . . . . . . . . . . 21 3.7.1. Convergence Event . . . . . . . . . . . . . . . . . . 21
3.7.2. Packet Loss . . . . . . . . . . . . . . . . . . . . . 21 3.7.2. Packet Loss . . . . . . . . . . . . . . . . . . . . . 22
3.7.3. Convergence Packet Loss . . . . . . . . . . . . . . . 21 3.7.3. Convergence Packet Loss . . . . . . . . . . . . . . . 22
3.7.4. Connectivity Packet Loss . . . . . . . . . . . . . . . 22 3.7.4. Connectivity Packet Loss . . . . . . . . . . . . . . . 23
3.7.5. Packet Sampling Interval . . . . . . . . . . . . . . . 23 3.7.5. Packet Sampling Interval . . . . . . . . . . . . . . . 23
3.7.6. Sustained Convergence Validation Time . . . . . . . . 23 3.7.6. Sustained Convergence Validation Time . . . . . . . . 24
3.8. Miscellaneous Terms . . . . . . . . . . . . . . . . . . . 24 3.8. Miscellaneous Terms . . . . . . . . . . . . . . . . . . . 24
3.8.1. Stale Forwarding . . . . . . . . . . . . . . . . . . . 24 3.8.1. Stale Forwarding . . . . . . . . . . . . . . . . . . . 24
3.8.2. Nested Convergence Event . . . . . . . . . . . . . . . 24 3.8.2. Nested Convergence Event . . . . . . . . . . . . . . . 25
4. Security Considerations . . . . . . . . . . . . . . . . . . . 25 4. Security Considerations . . . . . . . . . . . . . . . . . . . 25
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 25 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 26
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 25 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 26
7.1. Normative References . . . . . . . . . . . . . . . . . . . 25 7.1. Normative References . . . . . . . . . . . . . . . . . . . 26
7.2. Informative References . . . . . . . . . . . . . . . . . . 26 7.2. Informative References . . . . . . . . . . . . . . . . . . 27
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 26 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 27
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 35 skipping to change at page 4, line 35
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.2]
Duplicate Packet [Ref.[Po06], section 3.3.3] Duplicate Packet [Ref.[Po06], section 3.3.3]
Packet Reordering [Ref.[Mo06], section 3.3] Packet Reordering [Ref.[Mo06], section 3.3]
Stream [Ref.[Po06], section 3.3.2] Stream [Ref.[Po06], section 3.3.2]
Flow [Ref.[Po06], section 3.1.5]
Forwarding Delay [Ref.[Po06], section 3.2.4] Forwarding Delay [Ref.[Po06], section 3.2.4]
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 6, line 39 skipping to change at page 6, line 39
Measurement Units: N/A Measurement Units: N/A
Issues: None Issues: None
See Also: See Also:
Route Convergence, Full Convergence, Stale Forwarding Route Convergence, Full Convergence, Stale Forwarding
3.2. Instants 3.2. Instants
3.2.1. Convergence Event Instant 3.2.1. Traffic Start Instant
Definition:
The time instant the Tester sends out the first data packet to the
DUT.
Discussion:
If using the Loss-Derived Method or the Route-Specific Loss-Derived
Method to benchmark IGP convergence time, and the applied Convergence
Event does not cause instantaneous traffic loss for all routes at the
Convergence Event Instant then the Tester SHOULD collect a timestamp
on the Traffic Start Instant in order to measure the period of time
between the Traffic Start Instant and Convergence Event Instant.
Measurement Units:
hh:mm:ss:nnn:uuu, where 'nnn' is milliseconds and 'uuu' is
microseconds.
Issues: None
See Also:
Convergence Event Instant, Route-Specific Convergence Time, Loss-
Derived Convergence Time.
3.2.2. Convergence Event Instant
Definition: Definition:
The time instant that a Convergence Event occurs. The time instant that a Convergence Event occurs.
Discussion: Discussion:
If the Convergence Event causes instantaneous traffic loss on the If the Convergence Event causes instantaneous traffic loss on the
Preferred Egress Interface, the Convergence Event Instant is Preferred Egress Interface, the Convergence Event Instant is
observable from the data plane as the instant that the DUT begins to observable from the data plane as the instant that the DUT begins to
skipping to change at page 7, line 17 skipping to change at page 7, line 44
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: Convergence Event See Also: Convergence Event
3.2.2. 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 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 in order to validate the Convergence Recovery Instant.
skipping to change at page 7, line 49 skipping to change at page 8, line 29
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
3.2.3. 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 following a Convergence Event
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
skipping to change at page 11, line 28 skipping to change at page 12, line 10
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.
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.
^ Convergence ^ Traffic Convergence
Fwd | Recovery Fwd | Start Recovery
Rate | Instant Rate | Instant Instant
| Offered ^ | Offered ^ ^
| Load --> ----------\ /----------- | Load --> ----------\ /-----------
| \ /<--- Convergence | \ /<--- Convergence
| \ Packet / Recovery | \ Packet / Recovery
| Convergence --->\ Loss / Transition | Convergence --->\ Loss / Transition
| 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 consists of a single Stream [Po06]. If The Offered Load SHOULD consist of a single Stream [Po06]. If
sending multiple Streams, the measured traffic rate statistics for sending multiple Streams, the measured traffic rate statistics for
all Streams MUST be added together. 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 in the FIB are matched and each route is offered such that all routes or a statistically representative subset of all
an equal share of the total Offered Load. routes are matched and each of these routes is offered an equal share
of the Offered Load. It is RECOMMENDED to send traffic to all
routes, but a statistically representative subset of all routes can
be used if required.
At least one packet per route in the FIB for all routes in the FIB At least one packet per route for all routes matched in the Offered
MUST be offered to the DUT within each Packet Sampling Interval. Load MUST be offered to the DUT within each Packet Sampling Interval.
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 for the Rate-Derived Method. It Interval influence the observations for the Rate-Derived Method. It
may be difficult to identify the different convergence time instants may be difficult to identify the different convergence time instants
in the Rate-Derived Convergence Graph. For example, it is possible in the Rate-Derived Convergence Graph. For example, it is possible
that a Convergence Event causes the Forwarding Rate to drop to zero, that a Convergence Event causes the Forwarding Rate to drop to zero,
while this may not be observed in the Forwarding Rate measurements if while this may not be observed in the Forwarding Rate measurements if
the Packet Sampling Interval is too high. the Packet Sampling Interval is too large.
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
the Convergence Event Instant and the Tester SHOULD observe the Convergence Event Instant and the Tester SHOULD observe
Forwarding Rate seperately on the Next-Best Egress Interface. 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.
Measurement Units: N/A Measurement Units: N/A
Issues: None Issues: None
skipping to change at page 12, line 52 skipping to change at page 13, line 38
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 and Loss-
Derived Loss of Connectivity Period benchmarks from the amount of Derived Loss of Connectivity Period benchmarks from the amount of
packet loss. packet loss.
Discussion: Discussion:
The Offered Load SHOULD consists of a single Stream [Po06]. If The Offered Load SHOULD consist of a single Stream [Po06]. If
sending multiple Streams, the measured traffic rate statistics for sending multiple Streams, the measured traffic rate statistics for
all Streams MUST be added together. 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 in the FIB are matched and each route is offered such that all routes or a statistically representative subset of all
an equal share of the total Offered Load. routes are matched and each of these routes is offered an equal share
of the Offered Load. It is RECOMMENDED to send traffic to all
routes, but a statistically representative subset of all routes can
be used if required.
Loss-Derived Method SHOULD always be combined with Rate-Derived 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, the
Tester SHOULD in general observe packet loss on all DUT egress Tester SHOULD in general observe packet loss on all DUT egress
interfaces (Connectivity Packet Loss). interfaces (Connectivity Packet Loss).
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 timestamps of
the Convergence Event Instant and the Tester SHOULD observe packet the Start Traffic Instant and of the Convergence Event Instant, and
loss seperately on the Next-Best Egress Interface (Convergence Packet the Tester SHOULD observe packet loss separately on the Next-Best
Loss). Egress Interface (Convergence Packet Loss).
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 packet loss statistics are only collected after
Full Convergence completion, this method can only be used to measure Full Convergence completion, this method can only be used to measure
average values over all routes. For these reasons Loss-Derived average values over all routes. For these reasons Loss-Derived
Method can only be used to benchmark Loss-Derived Convergence Time Method can only be used to benchmark Loss-Derived Convergence Time
and Loss-Derived Loss of Connectivity Period. and Loss-Derived Loss of Connectivity Period.
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
skipping to change at page 14, line 14 skipping to change at page 14, line 50
The method to calculate the Route-Specific Convergence Time benchmark The method to calculate the Route-Specific Convergence Time benchmark
from the amount of packet loss during convergence for a specific from the amount of packet loss during convergence for a specific
route entry. 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 every route entry in the FIB. Convergence Packet Loss is for all routes or a statistically representative subset of all
measured for each Stream separately. routes. Convergence Packet Loss is measured for each Stream
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 for each Stream is
collected after Full Convergence completion. collected after Full Convergence completion.
Route-Specific Loss-Derived Method is a RECOMMENDED method to measure Route-Specific Loss-Derived Method is a RECOMMENDED method to measure
convergence time benchmarks. convergence time benchmarks.
To measure convergence time and loss of connectivity benchmarks, the To measure convergence time and loss of connectivity benchmarks, the
Tester SHOULD in general observe packet loss on all DUT egress Tester SHOULD in general observe packet loss on all DUT egress
interfaces (Connectivity Packet Loss). interfaces (Connectivity Packet Loss).
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 timestamps of
the Convergence Event Instant and the Tester SHOULD observe packet the Start Traffic Instant and of the Convergence Event Instant, and
loss seperately on the Next-Best Egress Interface (Convergence Packet the Tester SHOULD observe packet loss separately on the Next-Best
Loss). Egress Interface (Convergence Packet Loss).
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 measures packet loss as it would be experienced
by a network user. For this reason Route-Specific Loss-Derived by a network user. For this reason Route-Specific Loss-Derived
Method is RECOMMENDED to measure Route-Specific Convergence Time Method is RECOMMENDED to measure Route-Specific Convergence Time
benchmarks and Route Loss of Connectivity Period benchmarks. benchmarks and Route Loss of Connectivity Period benchmarks.
Measurement Units: seconds Measurement Units: seconds
Issues: None Issues: None
skipping to change at page 17, line 17 skipping to change at page 18, line 4
each measured route. The calculation is equal to Equation 7 in each measured route. The calculation is equal to Equation 7 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 3
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 a timestamp of the Convergence Event Instant and the SHOULD collect timestamps of the Traffic Start Instant and of the
Tester SHOULD observe Convergence Packet Loss separately on the Next- Convergence Event Instant, and the Tester SHOULD observe Convergence
Best Egress Interface. When benchmarking Route-Specific Convergence Packet Loss separately on the Next-Best Egress Interface. When
Time, Convergence Packet Loss is measured and Equation 4 is applied benchmarking Route-Specific Convergence Time, Convergence Packet Loss
for each measured route. is measured and Equation 4 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 - start traffic instant) - (Convergence Event Instant - Traffic Start Instant)
Equation 4 Equation 4
The Convergence Event Instant and start traffic 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
results. The format for reporting Route-Specific Convergence Time is results. The format for reporting Route-Specific Convergence Time is
provided in [Po09m]. provided in [Po09m].
skipping to change at page 18, line 31 skipping to change at page 19, line 15
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 5 is applied.
Loss-Derived Convergence Time = Loss-Derived Convergence Time =
Connectivity Packet Loss/Offered Load Connectivity Packet Loss/Offered Load
Equation 5 Equation 5
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 a timestamp of the Convergence Event Instant and the SHOULD collect timestamps of the Start Traffic Instant and of the
Tester SHOULD observe Convergence Packet Loss separately on the Next- Convergence Event Instant and the Tester SHOULD observe Convergence
Best Egress Interface. When benchmarking Loss-Derived Convergence Packet Loss separately on the Next-Best Egress Interface. When
Time, Convergence Packet Loss is measured and Equation 6 is applied. benchmarking Loss-Derived Convergence Time, Convergence Packet Loss
is measured and Equation 6 is applied.
Loss-Derived Convergence Time = Loss-Derived Convergence Time =
Convergence Packet Loss/Offered Load Convergence Packet Loss/Offered Load
- (Convergence Event Instant - start traffic instant) - (Convergence Event Instant - Traffic Start Instant)
Equation 6 Equation 6
The Convergence Event Instant and start traffic 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:
Convergence Packet Loss, Connectivity Packet Loss, Route Convergence Convergence Packet Loss, Connectivity Packet Loss, Route Convergence
skipping to change at page 19, line 23 skipping to change at page 20, line 8
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, 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 7 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 3 in
Section 3.6.3. Section 3.6.3.
skipping to change at page 21, line 41 skipping to change at page 22, line 25
The number of packets that should have been forwarded by a DUT under 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 a constant Offered Load that were not forwarded due to lack of
resources. resources.
Discussion: Discussion:
Packet Loss is a modified version of the term "Frame Loss Rate" as Packet Loss is a modified version of the term "Frame Loss Rate" as
defined in [Br91]. The term "Frame Loss" is intended for Ethernet defined in [Br91]. The term "Frame Loss" is intended for Ethernet
Frames while "Packet Loss" is intended for IP packets. Frames while "Packet Loss" is intended for IP packets.
Measurement units: Measurement units: Number of offered packets that are not forwarded.
Number of offered packets that are not forwarded.
Issues: None Issues: None
See Also: Convergence Packet Loss See Also: Convergence Packet Loss
3.7.3. 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 packets lost due to a Convergence Event until Full
skipping to change at page 23, line 14 skipping to change at page 23, line 43
3.7.5. Packet Sampling Interval 3.7.5. 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 in the FIB for all routes MUST be At least one packet per route for all routes matched in the Offered
offered to the DUT within the Packet Sampling Interval. Metrics Load MUST be offered to the DUT within the Packet Sampling Interval.
measured at the Packet Sampling Interval MUST include Forwarding Rate Metrics measured at the Packet Sampling Interval MUST include
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 The recommended value for configuration of the Packet Sampling
Interval when using the Rate-Derived Method is provided in [Po09m]. Interval when using the Rate-Derived Method is provided in [Po09m].
For the other benchmark methods the value of the Packet Sampling For the other benchmark methods the value of the Packet Sampling
skipping to change at page 23, line 52 skipping to change at page 24, line 33
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 5
seconds. The BMWG selected 5 seconds based upon RFC 2544 [Br99] seconds. The BMWG selected 5 seconds based upon RFC 2544 [Br99]
which recommends waiting 2 seconds for residual frames to arrive and which recommends waiting 2 seconds for residual frames to arrive
(this is the Forwarding Delay threshold for the last packet sent) and
5 seconds for DUT restabilization. 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
skipping to change at page 25, line 4 skipping to change at page 25, line 34
converging from a prior Convergence Event. converging from a prior Convergence Event.
Discussion: Discussion:
The Convergence Events for a Nested Convergence Event MUST occur with The Convergence Events for a Nested Convergence Event MUST occur with
different neighbors. A possible observation from a Nested different neighbors. A possible observation from a Nested
Convergence Event will be the withdrawal of routes from one neighbor Convergence Event will be the withdrawal of routes from one neighbor
while the routes of another neighbor are being installed. while the routes of another neighbor are being installed.
Measurement Units: N/A Measurement Units: N/A
Issues: None Issues: None
See Also: Convergence Event See Also: Convergence Event
4. Security Considerations 4. Security Considerations
Documents of this type do not directly affect the security of Benchmarking activities as described in this memo are limited to
Internet or corporate networks as long as benchmarking is not technology characterization using controlled stimuli in a laboratory
performed on devices or systems connected to production networks. environment, with dedicated address space and the constraints
Security threats and how to counter these in SIP and the media layer specified in the sections above.
is discussed in RFC3261, RFC3550, and RFC3711 and various other
drafts. This document attempts to formalize a set of common The benchmarking network topology will be an independent test setup
methodology for benchmarking IGP convergence performance in a lab and MUST NOT be connected to devices that may forward the test
environment. traffic into a production network, or misroute traffic to the test
management network.
Further, benchmarking is performed on a "black-box" basis, relying
solely on measurements observable external to the DUT/SUT.
Special capabilities SHOULD NOT exist in the DUT/SUT specifically for
benchmarking purposes. Any implications for network security arising
from the DUT/SUT SHOULD be identical in the lab and in production
networks.
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 and the BMWG for their contributions to this work.
 End of changes. 41 change blocks. 
87 lines changed or deleted 132 lines changed or added

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