Network Working Group                                        S. Poretsky
 Internet Draft
Internet-Draft                                      Allot Communications
 Expires: September 08, 2009
Intended Status: status: Informational                Brent                                 B. Imhoff
Expires: January 14, 2010                               Juniper Networks

                                               March 08,
                                                           K. Michielsen
                                                           Cisco Systems
                                                           July 13, 2009

Terminology for Benchmarking Link-State IGP Data Plane Route Convergence

               <draft-ietf-bmwg-igp-dataplane-conv-term-17.txt>
               draft-ietf-bmwg-igp-dataplane-conv-term-18

Status of this Memo

   This Internet-Draft is submitted to IETF in full conformance with the
   provisions of BCP 78 and BCP 79.  This document may contain material
   from IETF Documents or IETF Contributions published or made publicly
   available before November 10, 2008.  The person(s) controlling the
   copyright in some of this material may not have granted the IETF
   Trust the right to allow modifications of such material outside the
   IETF Standards Process.  Without obtaining an adequate license from
   the person(s) controlling the copyright in such materials, this
   document may not be modified outside the IETF Standards Process, and
   derivative works of it may not be created outside the IETF Standards
   Process, except to format it for publication as an RFC or to
   translate it into languages other than English.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on September 8, 2009. January 14, 2010.

Copyright Notice

   Copyright (c) 2009 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents in effect on the date of
   publication of this document (http://trustee.ietf.org/license-info).
   Please review these documents carefully, as they describe your rights
   and restrictions with respect to this document.

ABSTRACT

Abstract

   This document describes the terminology for benchmarking Interior
   Gateway Protocol (IGP) Route Convergence.  The terminology is to be
   used for benchmarking IGP convergence time through externally
   observable (black box) data plane measurements.  The terminology can
   be applied to any link-state IGP, such as ISIS and OSPF.

                 Link-State IGP Data Plane Route Convergence

Table of Contents

   1.  Introduction and Scope........................................3 Scope . . . . . . . . . . . . . . . . . . . .  4
   2.  Existing Definitions .........................................4 . . . . . . . . . . . . . . . . . . . . .  4
   3.  Term Definitions..............................................4
        3.1 States
           3.1.1 Definitions . . . . . . . . . . . . . . . . . . . . . . .  4
     3.1.  Convergence Types  . . . . . . . . . . . . . . . . . . . .  5
       3.1.1.  Route Convergence....................................4
           3.1.2 Convergence  . . . . . . . . . . . . . . . . . .  5
       3.1.2.  Full Convergence.....................................5
           3.1.3 Network Convergence..................................5
           3.1.4 Route-Specific Convergence...........................6
           3.1.5 Stale Forwarding.....................................6
        3.2 Events
           3.2.1 Convergence Event....................................7
           3.2.2 . . . . . . . . . . . . . . . . . . .  5
       3.1.3.  Network Convergence Event Trigger............................7
           3.2.3  . . . . . . . . . . . . . . . . .  6
     3.2.  Instants . . . . . . . . . . . . . . . . . . . . . . . . .  6
       3.2.1.  Convergence Event Instant............................8
           3.2.4 Instant  . . . . . . . . . . . . . .  6
       3.2.2.  Convergence Recovery Instant.........................8
           3.2.5 Instant . . . . . . . . . . . . .  7
       3.2.3.  First Route Convergence Instant......................9
           3.2.6 Instant  . . . . . . . . . . .  7
     3.3.  Transitions  . . . . . . . . . . . . . . . . . . . . . . .  8
       3.3.1.  Convergence Event Transition.........................9
           3.2.7 Transition . . . . . . . . . . . . .  8
       3.3.2.  Convergence Recovery Transition......................10
           3.2.8 Nested Convergence Events............................10
        3.3 Transition  . . . . . . . . . . .  9
     3.4.  Interfaces
           3.3.1 . . . . . . . . . . . . . . . . . . . . . . . .  9
       3.4.1.  Local Interface......................................11
           3.3.2 Neighbor Interface...................................11
           3.3.3 Interface  . . . . . . . . . . . . . . . . . . .  9
       3.4.2.  Remote Interface.....................................11
           3.3.4 Interface . . . . . . . . . . . . . . . . . . . 10
       3.4.3.  Preferred Egress Interface...........................12
           3.3.5 Interface . . . . . . . . . . . . . . 10
       3.4.4.  Next-Best Egress Interface...........................12
        3.4 Interface . . . . . . . . . . . . . . 10
     3.5.  Benchmarking Method
           3.4.1 Packet Loss..........................................13
           3.4.2 Convergence Packet Loss..............................13
           3.4.3 Methods . . . . . . . . . . . . . . . . . . . 11
       3.5.1.  Rate-Derived Convergence Method......................14
           3.4.4 Method  . . . . . . . . . . . . . . . . . 11
       3.5.2.  Loss-Derived Convergence Method......................14
           3.4.5 Packet Sampling Interval.............................15
        3.5 Method  . . . . . . . . . . . . . . . . . 12
       3.5.3.  Route-Specific Loss-Derived Method . . . . . . . . . . 13
     3.6.  Benchmarks
           3.5.1 . . . . . . . . . . . . . . . . . . . . . . . . 15
       3.6.1.  Full Convergence Time................................17
           3.5.2 Time  . . . . . . . . . . . . . . . . 15
       3.6.2.  First Route Convergence Time.........................17
           3.5.3 Time . . . . . . . . . . . . . 15
       3.6.3.  Route-Specific Convergence Time......................17
           3.5.4 Time  . . . . . . . . . . . 16
       3.6.4.  Loss-Derived Convergence Time  . . . . . . . . . . . . 18
       3.6.5.  Route Loss of Connectivity Period  . . . . . . . . . . 19
       3.6.6.  Loss-Derived Loss of Connectivity Period . . . . . . . 20
     3.7.  Measurement Terms  . . . . . . . . . . . . . . . . . . . . 21
       3.7.1.  Convergence Event  . . . . . . . . . . . . . . . . . . 21
       3.7.2.  Packet Loss  . . . . . . . . . . . . . . . . . . . . . 21
       3.7.3.  Convergence Packet Loss  . . . . . . . . . . . . . . . 21
       3.7.4.  Connectivity Packet Loss . . . . . . . . . . . . . . . 22
       3.7.5.  Packet Sampling Interval . . . . . . . . . . . . . . . 23
       3.7.6.  Sustained Convergence Validation Time................18
           3.5.5 Reversion Time  . . . . . . . . 23
     3.8.  Miscellaneous Terms  . . . . . . . . . . . . . . . . . . . 24
       3.8.1.  Stale Forwarding . . . . . . . . . . . . . . . . . . . 24
       3.8.2.  Nested Convergence Time...........................19 Event . . . . . . . . . . . . . . . 24
   4. IANA Considerations...........................................19
     5.  Security Considerations.......................................19 Considerations  . . . . . . . . . . . . . . . . . . . 25
   5.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 25
   6. Acknowledgements..............................................20  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 25
   7. References....................................................20
     8. Author's Address..............................................21
                 Link-State IGP Data Plane Route Convergence  References . . . . . . . . . . . . . . . . . . . . . . . . . . 25
     7.1.  Normative References . . . . . . . . . . . . . . . . . . . 25
     7.2.  Informative References . . . . . . . . . . . . . . . . . . 26
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 26

1.  Introduction and Scope

   This draft describes the terminology for benchmarking Link-State
   Interior Gateway Protocol (IGP) Route Convergence.  The motivation and
   applicability for this benchmarking is provided in [Po07a]. [Po09a].  The
   methodology to be used for this benchmarking is described in [Po07m]. [Po09m].
   The purpose of this document is to introduce new terms required to
   complete execution of the IGP Route Convergence Methodology [Po07m].
   These terms apply to IPv4 and IPv6 traffic and IGPs.

   Convergence times are [Po09m].

   IGP convergence time is measured at the Tester on the data plane at the Tester by
   observing packet loss through the DUT.  The methodology and
   terminology to be used for benchmarking Route IGP Convergence can be
   applied to any IPv4 and IPv6 traffic and link-state IGP IGPs such as ISIS [Ca90] and
   [Ca90][Ho08], OSPF [Mo98].
   The data plane is measured to obtain black-box (externally
   observable) convergence benchmarking metrics.  When there is no
   packer loss observed in the data plane, the convergence time
   SHALL be reported as zero.

   An example of Route Convergence as observed [Mo98][Co08], and measured from the
   data plane is shown in Figure 1.  The graph in Figure 1 shows
   Forwarding Rate versus Time.  Time 0 on the X-axis is on the far
   right of the graph.  The Offered Load to the ingress interface of
   the DUT SHOULD equal the measured Throughput [Ba99][Ma98] of the DUT
   and the Forwarding Rate [Ma98] and Convergence Packet Loss is
   measured at the Preferred and Next-Best Egress interfaces of the DUT
   befire, during, and after a Convergence Event Trigger.  These
   components of the graph are defined in the Term Definitions section.

  Full Convergence-> Convergence     Convergence
                     Recovery       Event   Event    Time=
                     Instant        Instant Trigger  0sec
  Forwarding Rate=         ^              ^    ^     ^     Offered Load=
     Offered Load --> ------\    Packet   /----------- <--Max Throughput
                             \    Loss   /<----Convergence
           Convergence------->\         /      Event Transition
        Recovery Transition    \       /
                                \_____/<------Maximum Packet Loss
                                ^
                          First Route
                      Convergence Instant

        Y-axis = Forwarding Rate
        X-axis = Time (increases right to left to match commercial test
                       equipment displays)

                        Figure 1. Convergence Graph
                 Link-State IGP Data Plane Route Convergence

2.  Existing Definitions
   This document uses existing terminology defined others.

2.  Existing Definitions

   This document uses existing terminology defined in other BMWG work.
   Examples include, but are not limited to:

             Latency                   [Ref.[Ba91], section 3.8]

            Frame Loss Rate           [Ref.[Ba91],         [Ref.[Br91], section 3.6]
            Throughput                [Ref.[Ba91],              [Ref.[Br91], section 3.17]
            Offered Load            [Ref.[Ma98], section 3.5.2]
            Forwarding Rate         [Ref.[Ma98], section 3.6.1]
            Device Under Test (DUT) [Ref.[Ma98], section 3.1.1]
            System Under Test (SUT) [Ref.[Ma98], section 3.1.2]
            Out-of-order Packet     [Ref.[Po06], section 3.3.2]
            Duplicate Packet        [Ref.[Po06], section 3.3.3]
            Packet Reordering       [Ref.[Mo06], section 3.3]
            Stream                  [Ref.[Po06], section 3.3.2]
            Flow                    [Ref.[Po06], section 3.1.5]
            Forwarding Delay        [Ref.[Po06], section 3.2.4]
            Loss Period             [Ref.[Ko02], section 4]

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in BCP 14, RFC 2119
   [Br97].  RFC 2119 defines the use of these key words to help make the
   intent of standards track documents as clear as possible.  While this
   document uses these keywords, this document is not a standards track
   document.

3.  Term Definitions

 3.1 States
   3.1.1

3.1.  Convergence Types

3.1.1.  Route Convergence

   Definition:

   The action to update process of updating all components of the router with the
        most recent route change(s) router, including the
   Routing Information Base (RIB) and Forwarding Information Base (FIB),
   along with software and hardware tables, with the most recent route
   change(s) such that forwarding
        is successful for one or more a route entries. entry is successful on the
   Next-Best Egress Interface.

   Discussion:

   Route Convergence MUST occur after a Convergence Event.  Route
   Convergence can be observed externally by the rerouting of data
   traffic for a destination matching a route entry to the Next-best
   Egress Interface.  Also,
        completion  Completion of Route Convergence may or may not be
   sustained over time.

   Measurement Units: N/A

   Issues: None

   See Also:

   Network Convergence Convergence, Full Convergence Convergence, Convergence Event
                 Link-State IGP Data Plane Route Convergence

   3.1.2

3.1.2.  Full Convergence

   Definition:

   Route Convergence for an entire FIB all routes in which complete recovery
        from the Convergence Event is indicated by the DUT throughput
        equal to the offered load.

        Discussion:
        When benchmarking convergence, it is useful to measure the time to converge an entire FIB.  For example,

   Discussion:

   Full Convergence MUST occur after a Convergence Event Event.  Full
   Convergence can be produced for an OSPF table of
        5000 routes so that observed externally by the time to converge routes 1 through
        5000 is measured.  Completion rerouting of Full 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 Throughput Forwarding Rate of the data
   plane traffic on the Next-Best Egress Interface equals the
        offered load.

        Full Convergence MAY be measured using Rate-Derived Convergence
        Method or calculated using Loss-Derived Convergence Method. Offered
   Load.

   Completion of Full Convergence may or may not be sustained over time.  The
        Sustained Convergence Validation Time MUST be applied.

   Measurement Units: N/A
   Issues: None

   See Also:

   Network Convergence Convergence, Route Convergence, Convergence Event, Full
   Convergence Time, Convergence Event

   3.1.3 Recovery Instant

3.1.3.  Network Convergence

   Definition:
        The process of updating of all routing tables, including
        distributed FIBs,

   Full Convergence in all routers throughout the network.

   Discussion:

   Network Convergence requires completion of includes all Route Convergence operations for all
   routers in the network following a Convergence Event.

   Completion of Network Convergence can be observed by recovery of System Under Test (SUT) Throughput the
   network Forwarding Rate to equal the offered load, Offered Load, with no Stale
   Forwarding, and no Blenders [Ca01][Ci03].

   Completion of Network Convergence may or may not be sustained over
   time.

   Measurement Units: N/A

   Issues: None
                 Link-State IGP Data Plane Route Convergence

   See Also:

   Route Convergence Convergence, Full Convergence, Stale Forwarding

  3.1.4 Route-Specific

3.2.  Instants

3.2.1.  Convergence Event Instant

   Definition:
        Route

   The time instant that a Convergence for one or more specific route entries in
        the FIB in which recovery from Event occurs.

   Discussion:

   If the Convergence Event is
        indicated when data-plane causes instantaneous traffic for the flow [Po06] matching
        that route entry(ies) is routed to loss on the Next-Best
   Preferred Egress
        Interface.

        Discussion:
        When benchmarking convergence, it is sometimes useful to
        measure the time to converge a single flow [Po06] or group of
        flows to benchmark convergence time for one or a few route
        entries in the FIB instead of Interface, the entire FIB.  Route-Specific Convergence of a flow Event Instant is externally
   observable from the data plane when as the data plane traffic for instant that flow is routed the DUT begins to
   exhibit packet loss.

   The Tester SHOULD collect a timestamp on the Next-Best Egress Interface. Convergence Event
   Instant if it is not observable from the data plane.

   Measurement Units: N/A

   hh:mm:ss:nnn:uuu, where 'nnn' is milliseconds and 'uuu' is
   microseconds.

   Issues: None

   See Also:
        Full Convergence
        Route Convergence Convergence Event

   3.1.5 Stale Forwarding

3.2.2.  Convergence Recovery Instant

   Definition:
        Forwarding of traffic to route entries that no longer exist
        or to route entries with next-hops

   The time instant that are no longer preferred. Full Convergence has completed.

   Discussion:
        Stale Forwarding can

   The Full Convergence completed state MUST be caused by a maintained for an
   interval of duration equal to the Sustained Convergence Event and can
        manifest as a "black-hole" or microloop that produces packet
        loss.  Stale Forwarding can exist until Network Validation
   Time in order to validate the Convergence Recovery Instant.

   The Convergence Recovery Instant is
        completed.  Stale Forwarding cannot be observable from the data plane as
   the instant the DUT forwards traffic to all destinations over the
   Next-Best Egress Interface.

   When using the Rate-Derived Method, the Convergence Recovery Instant
   falls within the Packet Sampling Interval preceding the first
   interval where the observed with a single
        DUT. Forwarding Rate on the Next-Best Egress
   Interface equals the Offered Load.

   Measurement Units: N/A

   hh:mm:ss:nnn:uuu, where 'nnn' is milliseconds and 'uuu' is
   microseconds.

   Issues: None

   See Also:
        Network

   Sustained Convergence
                 Link-State IGP Data Plane Route Validation Time, Full Convergence

 3.2 Events

   3.2.1

3.2.3.  First Route Convergence Event Instant

   Definition:

   The occurrence of time instant the first route entry completes Route Convergence
   following a planned or unplanned event in Convergence Event

   Discussion:

   Any route may be the network first to complete Route Convergence.  The First
   Route Convergence Instant is observable from the data plane as the
   instant that results in a change in the egress interface of first packet is received from the Device
        Under Test (DUT) for routed packets.

        Discussion:
        Convergence Events include link loss, routing protocol session
        loss, router failure, configuration change, and better next-hop
        learned via a routing protocol. Next-Best Egress
   Interface.

   Measurement Units:
        N/A

   hh:mm:ss:nnn:uuu, where 'nnn' is milliseconds and 'uuu' is
   microseconds.

   Issues: None

   See Also: Route Convergence Packet Loss
        Convergence Event Instant

   3.2.2

3.3.  Transitions

3.3.1.  Convergence Event Trigger Transition

   Definition:
        An action taken by the Tester to produce

   A time interval following a Convergence Event.

        Discussion:
        The Convergence Event Trigger is introduced by in which Forwarding
   Rate on the Tester and Preferred Egress Interface gradually reduces to zero.

   Discussion:

   The Forwarding Rate during a Convergence Event Transition may not
   decrease linearly.

   The Forwarding Rate observed on all DUT egress interfaces may be indicated by link loss, routing protocol session loss,
        router failure, configuration change, or a better next-hop
        learned via a routing protocol introduced by may
   not decrease to zero.

   The Offered Load, the Tester. number of routes, and the Packet Sampling
   Interval influence the observations of the Convergence Event
   Transition using the Rate-Derived Method.  This is further discussed
   with the term "Rate-Derived Method".

   Measurement Units:
        N/A seconds

   Issues: None

   See Also:

   Convergence Event
        Convergence Packet Loss Event, Rate-Derived Method

3.3.2.  Convergence Recovery Instant
                 Link-State IGP Data Plane Route Convergence

   3.2.3 Convergence Event Instant Transition

   Definition:
        The

   A time instant that a interval following the First Route Convergence Event becomes observable Instant in
   which Forwarding Rate on the data plane. Next-Best Egress Interface gradually
   increases to equal the Offered Load.

   Discussion:

   The Forwarding Rate observed during a Convergence Event Instant is observable from Recovery Transition
   may not increase linearly.

   The Offered Load, the data
        plane as number of routes, and the precise time that Packet Sampling
   Interval influence the device under test begins
        to exhibit packet loss.  The Convergence Event Instant is
        produced by observations of the Convergence Event Trigger.  The Convergence
        Event Instant always occurs concurrent or subsequent to Recovery
   Transition using the
        Tester introducing Rate-Derived Method.  This is further discussed
   with the Convergence Event Trigger. term "Rate-Derived Method".

   Measurement Units:
        hh:mm:ss:nnn:uuu,
           where 'nnn' is milliseconds and 'uuu' is microseconds. seconds

   Issues: None

   See Also:
        Convergence Event
        Convergence Packet Loss
        Convergence Recovery Instant

   3.2.4 Convergence Recovery Instant

        Definition:
        The time instant that

   Full Convergence,First Route Convergence completion is
        observed.

        Discussion:
        Convergence Recovery Instant is measurable from Instant, Rate-Derived Method

3.4.  Interfaces

3.4.1.  Local Interface

   Definition:

   An interface on the data
        plane as DUT.

   Discussion:

   A failure of the precise time Local Interface indicates that the device under test completes
        Full Convergence.  The Convergence Recovery Instant MUST be
        maintained for an interval of duration equal to failure occurred
   directly on the Sustained
        Convergence Validation Time. DUT.

   Measurement Units:
        hh:mm:ss:nnn:uuu,
           where 'nnn' is milliseconds and 'uuu' is microseconds. N/A

   Issues: None

   See Also:
        Sustained Convergence Validation Time
        Convergence Packet Loss
        Convergence Event Instant
                 Link-State IGP Data Plane Route Convergence

   3.2.5 First Route Convergence Instant Remote Interface

3.4.2.  Remote Interface

   Definition:
        The time instant a first route entry has converged
        following

   An interface on a Convergence Event, as observed by receipt of
        the first packet from the Next-Best Egress Interface.

        Discussion:
        The First Route Convergence Instant is an indication neighboring router that the
        process to achieve Full Convergence has begun.  Any route may
        be the first is not directly connected
   to converge for First Route Convergence Instant.
        Measurement any interface on the data-plane enables DUT.

   Discussion:

   A failure of a Remote Interface indicates that the First Route
        Convergence Instant failure occurred
   on a neighbor router's interface that is not directly connected to be observed without any white-box
        information from
   the DUT.

   Measurement Units:
           hh:mm:ss:nnn:uuu,
             where 'nnn' is milliseconds and 'uuu' is microseconds. N/A

   Issues: None

   See Also:
        Route Convergence
        Full Convergence
        Stale Forwarding

   3.2.6 Convergence Event Transition Local Interface

3.4.3.  Preferred Egress Interface

   Definition:
        A time interval observed following a Convergence Event in which
        Throughput gradually reduces

   The outbound interface from the DUT for traffic routed to a minimum value. the
   preferred next-hop.

   Discussion:

   The Convergence Event Transition Preferred Egress Interface is best observed for Full
        Convergence.  The the egress packet rate observed during interface prior to a
   Convergence Event Transition may not decrease linearly and may
        not decrease to zero.  Both the offered load and the Packet
        Sampling Interval influence the observations of the Convergence
        Event Transition.  For example, it is possible that if the
        Convergence Event were to cause the Throughput [Ba91] to drop
        to zero then this may not be observed if the Packet Sampling
        Interval is set too high.  This is further discussed with the
        term "Packet Sampling Interval". Event.

   Measurement Units:
          seconds N/A

   Issues: None
                 Link-State IGP Data Plane Route Convergence

   See Also:
        Convergence Event
        Full Convergence
        Packet Sampling Interval

   3.2.7 Convergence Recovery Transition Next-Best Egress Interface

3.4.4.  Next-Best Egress Interface

   Definition:

   The characteristic of outbound interface from the DUT in which Throughput gradually
        increases for traffic routed to equal the offered load.

        Discussion:
        The Convergence Recovery Transition is second-
   best observed for
        Full Convergence. next-hop.

   Discussion:

   The Next-Best Egress Interface becomes the egress packet rate observed during interface after a
   Convergence Recovery Transition may not increase linearly.
        Both the offered load and the Packet Sampling Interval
        influence the observations Event.

   The Next-Best Egress Interface is of the Convergence Recovery
        Transition.  This is further discussed with same media type and link
   speed as the term
        "Packet Sampling Interval". Preferred Egress Interface.

   Measurement Units:
        seconds N/A

   Issues: None

   See Also:
        Full Convergence
        Packet Sampling Interval

   3.2.8 Nested Convergence Events Preferred Egress Interface

3.5.  Benchmarking Methods

3.5.1.  Rate-Derived Method

   Definition:

   The occurrence of a Convergence Event while the route
        table is converging method to calculate convergence time benchmarks from a prior Convergence Event. observing
   Forwarding Rate each Packet Sampling Interval.

   Discussion:
        The

   Figure 1 shows an example of the Forwarding Rate change in time
   during convergence as observed when using the Rate-Derived Method.

           ^                                      Convergence Events for a Nested
      Fwd  |                                      Recovery
      Rate |                                      Instant
           | Offered                                ^
           | Load --> ----------\                   /-----------
           |                     \                 /<--- Convergence Event
        MUST occur with different neighbors.  A common
        observation from a Nested
           |                      \     Packet    /      Recovery
           |       Convergence --->\     Loss    /       Transition
           |       Event will be
        the withdrawal            \           /
           |       Transition        \---------/ <-- Max Packet Loss
           |
           +--------------------------------------------------------->
                           ^                   ^                 time
                      Convergence         First Route
                      Event Instant       Convergence Instant

                 Figure 1: Rate-Derived Convergence Graph

   The Offered Load SHOULD consists of a single Stream [Po06].  If
   sending multiple Streams, the measured traffic rate statistics for
   all Streams MUST be added together.

   The destination addresses for the Offered Load MUST be distributed
   such that all routes in the FIB are matched and each route is offered
   an equal share of the total Offered Load.

   At least one packet per route in the FIB for all routes in the FIB
   MUST be offered to the DUT within each Packet Sampling Interval.

   The Offered Load, the number of routes, and the Packet Sampling
   Interval influence the observations for the Rate-Derived Method.  It
   may be difficult to identify the different convergence time instants
   in the Rate-Derived Convergence Graph.  For example, it is possible
   that a Convergence Event causes the Forwarding Rate to drop to zero,
   while this may not be observed in the Forwarding Rate measurements if
   the Packet Sampling Interval is too high.

   Metrics measured at the Packet Sampling Interval MUST include
   Forwarding Rate and packet loss.

   Rate-Derived Method is a RECOMMENDED method to measure convergence
   time benchmarks.

   To measure convergence time benchmarks for Convergence Events that do
   not cause instantaneous traffic loss for all routes at the
   Convergence Event Instant, the Tester SHOULD collect a timestamp of
   the Convergence Event Instant and the Tester SHOULD observe
   Forwarding Rate seperately on the Next-Best Egress Interface.

   Since the Rate-Derived Method does not distinguish between individual
   traffic destinations, it SHOULD NOT be used for any route specific
   measurements.  Therefor Rate-Derived Method SHOULD NOT be used to
   benchmark Route Loss of Connectivity Period.

   Measurement Units: N/A

   Issues: None

   See Also:

   Packet Sampling Interval, Convergence Event, Convergence Event
   Instant, Full Convergence

3.5.2.  Loss-Derived Method

   Definition:

   The method to calculate the Loss-Derived Convergence Time and Loss-
   Derived Loss of Connectivity Period benchmarks from the amount of
   packet loss.

   Discussion:

   The Offered Load SHOULD consists of a single Stream [Po06].  If
   sending multiple Streams, the measured traffic rate statistics for
   all Streams MUST be added together.

   The destination addresses for the Offered Load MUST be distributed
   such that all routes in the FIB are matched and each route is offered
   an equal share of the total Offered Load.

   Loss-Derived Method SHOULD always be combined with Rate-Derived
   Method in order to observe Full Convergence completion.  The total
   amount of Convergence Packet Loss is collected after Full Convergence
   completion.

   To measure convergence time and loss of connectivity benchmarks, the
   Tester SHOULD in general observe packet loss on all DUT egress
   interfaces (Connectivity Packet Loss).

   To measure convergence time benchmarks for Convergence Events that do
   not cause instantaneous traffic loss for all routes at the
   Convergence Event Instant, the Tester SHOULD collect a timestamp of
   the Convergence Event Instant and the Tester SHOULD observe packet
   loss seperately on the Next-Best Egress Interface (Convergence Packet
   Loss).

   Since Loss-Derived Method does not distinguish between traffic
   destinations and the packet loss statistics are only collected after
   Full Convergence completion, this method can only be used to measure
   average values over all routes.  For these reasons Loss-Derived
   Method can only be used to benchmark Loss-Derived Convergence Time
   and Loss-Derived Loss of Connectivity Period.

   Note that the Loss-Derived Method measures an average over all
   routes, including the routes that may not be impacted by the
   Convergence Event, such as routes via non-impacted members of ECMP or
   parallel links.

   Measurement Units: seconds

   Issues: None

   See Also:

   Loss-Derived Convergence Time, Loss-Derived Loss of Connectivity
   Period, Convergence Packet Loss

3.5.3.  Route-Specific Loss-Derived Method

   Definition:

   The method to calculate the Route-Specific Convergence Time benchmark
   from the amount of packet loss during convergence for a specific
   route entry.

   Discussion:

   To benchmark Route-Specific Convergence Time, the Tester provides an
   Offered Load that consists of multiple Streams [Po06].  Each Stream
   has a single destination address matching a different route entry,
   for every route entry in the FIB.  Convergence Packet Loss is
   measured for each Stream separately.

   Route-Specific Loss-Derived Method SHOULD always be combined with
   Rate-Derived Method in order to observe Full Convergence completion.
   The total amount of Convergence Packet Loss for each Stream is
   collected after Full Convergence completion.

   Route-Specific Loss-Derived Method is a RECOMMENDED method to measure
   convergence time benchmarks.

   To measure convergence time and loss of connectivity benchmarks, the
   Tester SHOULD in general observe packet loss on all DUT egress
   interfaces (Connectivity Packet Loss).

   To measure convergence time benchmarks for Convergence Events that do
   not cause instantaneous traffic loss for all routes from one neighbor while at the
        routes of another neighbor are being installed.

        Measurement Units: N/A

        Issues: None

        See Also:
   Convergence Event
                 Link-State IGP Data Plane Route Convergence

 3.3 Interfaces

   3.3.1 Local Interface

        Definition:
        An interface on Instant, the DUT.

        Discussion:
        A failure Tester SHOULD collect a timestamp of
   the Local Interface indicates that Convergence Event Instant and the failure
        occurred directly Tester SHOULD observe packet
   loss seperately on the DUT.

        Measurement Units: N/A

        Issues: None

        See Also:
        Neighbor Interface
        Remote Interface

   3.3.2 Neighbor Next-Best Egress Interface

        Definition:
        The interface on the neighbor router or tester that is
        directly linked (Convergence Packet
   Loss).

   Since Route-Specific Loss-Derived Method uses traffic streams to the DUT's Local Interface.

        Discussion:
        A failure of a Neighbor Interface indicates that a
        failure occurred on
   individual routes, it measures packet loss as it would be experienced
   by a neighbor router's interface that
        directly links the neighbor router network user.  For this reason Route-Specific Loss-Derived
   Method is RECOMMENDED to the DUT. measure Route-Specific Convergence Time
   benchmarks and Route Loss of Connectivity Period benchmarks.

   Measurement Units: N/A seconds

   Issues: None

   See Also:
        Local Interface
        Remote Interface

   3.3.3 Remote Interface

   Route-Specific Convergence Time, Route Loss of Connectivity Period,
   Convergence Packet Loss

3.6.  Benchmarks

3.6.1.  Full Convergence Time

   Definition:
        An interface on a neighboring router that is not directly
        connected to any interface on

   The time duration of the DUT. period between the Convergence Event Instant
   and the Convergence Recovery Instant as observed using the Rate-
   Derived Method.

   Discussion:
        A failure of a Remote Interface indicates that

   Using the failure
        occurred on a neighbor router's interface that is not
        directly connected to Rate-Derived Method, Full Convergence Time can be
   calculated as the DUT.

                 Link-State IGP Data Plane Route time difference between the Convergence Event
   Instant and the Convergence Recovery Instant, as shown in Equation 1.

        Full Convergence Time =
            Convergence Recovery Instant - Convergence

        Measurement Units:
        N/A

        Issues:
        None

        See Also:
        Local Interface
        Neighbor Interface

   3.3.4 Preferred Egress Interface

        Definition: Event Instant

                                Equation 1

   The outbound interface Convergence Event Instant can be derived from the DUT for traffic routed to Forwarding Rate
   observation or from a timestamp collected by the
        preferred next-hop.

        Discussion:
        The Preferred Egress Interface Tester.

   For the testcases described in [Po09m], it is expected that Full
   Convergence Time equals the egress interface prior maximum Route-Specific Convergence Time
   when benchmarking all routes in FIB using the Route-Specific Loss-
   Derived Method.

   It is not possible to a measure Full Convergence Event. Time using the Loss-
   Derived Method.

   Measurement Units:
        N/A seconds

   Issues: None

   See Also:
        Next-Best Egress Interface

   3.3.5 Next-Best Egress Interface

   Full Convergence, Rate-Derived Method, Route-Specific Loss-Derived
   Method

3.6.2.  First Route Convergence Time

   Definition:

   The outbound interface from the DUT for traffic routed to duration of the
        second-best next-hop.  It is period between the same media type Convergence Event Instant and link speed
   the First Route Convergence Instant as observed using the Preferred Egress Interface Rate-
   Derived Method.

   Discussion:
        The Next-Best Egress Interface becomes

   Using the egress interface
        after a Convergence Event.

        Measurement Units:
        N/A

        Issues: None

        See Also:
        Preferred Egress Interface
                 Link-State IGP Data Plane Rate-Derived Method, First Route Convergence
 3.4 Benchmarking Methods

   3.4.1  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 Time can be
   calculated as the term "Frame Loss Rate" time difference between the Convergence Event
   Instant and the First Route Convergence Instant, as defined in [Ba91].  The term "Frame Loss" is intended for
        Ethernet Frames while "Packet Loss" is intended for IP packets.
        Packet Loss shown with
   Equation 2.

      First Route Convergence Time =
          First Route Convergence Instant - Convergence Event Instant

                                Equation 2

   The Convergence Event Instant can be measured as a reduction in forwarded traffic derived from the Throughput [Ba91] of Forwarding Rate
   observation or from a timestamp collected by the DUT.

        Measurement units:
        Number of offered packets Tester.

   For the testcases described in [Po09m], it is expected that are First
   Route Convergence Time equals the minimum Route-Specific Convergence
   Time when benchmarking all routes in FIB using the Route-Specific
   Loss-Derived Method.

   It is not forwarded. possible to measure First Route Convergence Time using the
   Loss-Derived Method.

   Measurement Units: seconds

   Issues: None

   See Also:

   Rate-Derived Method, Route-Specific Loss-Derived Method, First Route
   Convergence Packet Loss

   3.4.2 Instant

3.6.3.  Route-Specific Convergence Packet Loss Time

   Definition:

   The number amount of packets lost due time it takes for Route Convergence to be completed for
   a Convergence Event
        until Full Convergence completes. specific route, as calculated from the amount of packet loss during
   convergence for a single route entry.

   Discussion:

   Route-Specific Convergence Packet Loss includes packets that were lost and
        packets that were delayed due to buffering.  The Convergence
        Packet Loss observed in a Packet Sampling Interval may or may
        not Time can only be equal to measured using the number of packets in Route-
   Specific Loss-Derived Method.

   If the offered load
        during applied Convergence Event causes instantaneous traffic loss
   for all routes at the interval following a Convergence Event (see Figure
        1).

        Measurement Units:
        number of packets

        Issues: None

        See Also: Instant, Connectivity Packet
   Loss
        Route Convergence
        Convergence Event should be observed.  Connectivity Packet Sampling Interval
                 Link-State IGP Data Plane Route Convergence

   3.4.3 Rate-Derived Convergence Method
        Definition:
        The method to calculate convergence time benchmarks from Loss is the
        amount of time that combined
   packet loss observed on Preferred Egress Interface and Next-Best
   Egress Interface.  When benchmarking Route-Specific Convergence Time,
   Connectivity Packet Loss is measured and Equation 3 is applied for
   each measured route.  The calculation is equal to Equation 7 in
   Section 3.6.5.

   Route-Specific Convergence Time =
      Connectivity Packet Loss persists upon
        occurrence of a for specific route/Offered Load per route

                                Equation 3

   If the applied Convergence Event.

        Rate-Derived Event does not cause instantaneous traffic
   loss for all routes at the Convergence Method can be calculated as Event Instant, then the time
        difference from Tester
   SHOULD collect a timestamp of the Convergence Event Instant to and the
   Tester SHOULD observe Convergence Recovery Instant, as shown with Packet Loss separately on the Next-
   Best Egress Interface.  When benchmarking Route-Specific Convergence
   Time, Convergence Packet Loss is measured and Equation 1.

        (Equation 1)
          Rate-Derived 4 is applied
   for each measured route.

   Route-Specific Convergence Method Time =
       Convergence Recovery Packet Loss for specific route/Offered Load per route
       - (Convergence Event Instant - start traffic instant)

                                Equation 4

   The Convergence Event Instant.

        Discussion:
        It is RECOMMENDED that the Rate-Derived Convergence Method Instant and start traffic instant SHOULD be
        measured when benchmarking convergence times.
   collected by the Tester.

   The Rate-Derived Route-Specific Convergence Method SHOULD Time benchmarks enable minimum,
   maximum, average, and median convergence time measurements to be measured with an Offered Load at
   reported by comparing the Throughput of results for the DUT.  At least one packet per different route
        in the FIB entries.
   It also enables benchmarking of convergence time when configuring a
   priority value for all routes in the FIB MUST route entry(ies).  Since multiple Route-Specific
   Convergence Times can be offered to the DUT
        within the Packet Sampling Interval.

        It measured it is possible to measure no packet loss, which results in a
        Rate-Derived Convergence Time benchmark have an array of zero.  Failure to
        achieve Full Convergence results in a Rate-Derived
   results.  The format for reporting Route-Specific Convergence Time benchmark of infinity. is
   provided in [Po09m].

   Measurement Units: seconds

   Issues: None

   See Also:

   Convergence Packet Loss
        Convergence Recovery Instant Event, Convergence Event Instant
        Full Packet Loss, Connectivity Packet Loss,
   Route Convergence

   3.4.4

3.6.4.  Loss-Derived Convergence Method
        Definition:
        The method to calculate convergence Time

   Definition:

   The average Route Convergence time benchmarks for all routes in FIB, as
   calculated from the amount of packet loss during convergence.

   Discussion:

   Loss-Derived Convergence Packet Loss. Time is measured using the Loss-Derived
   Method.

   If the applied Convergence
        Method can Event causes instantaneous traffic loss
   for all routes at the Convergence Event Instant, Connectivity Packet
   Loss should be calculated from observed.  Connectivity Packet Loss is the combined
   packet loss observed on Preferred Egress Interface and Next-Best
   Egress Interface.  When benchmarking Loss-Derived Convergence Time,
   Connectivity Packet Loss as shown
        with Equation 2. is measured and Equation 2 - 5 is applied.

                 Loss-Derived Convergence Method Time =
                Convergence Packets Loss / Offered
                     Connectivity Packet Loss/Offered Load
          where units are packets / packets/second = seconds
                 Link-State IGP Data Plane Route Convergence

        Discussion:
        Ideally,

                                Equation 5

   If the applied Convergence Event Transition and Convergence
        Recovery Transition are does not cause instantaneous so that the Rate-Derived
        Convergence Method = Loss-Derived Convergence Method.  However,
        router implementations are less than ideal.  Loss-Derived
        Convergence Method gives a better than actual result when
        converging many traffic
   loss for all routes simultaneously because it ignores at the
        transitions.  The Rate-Derived Convergence Method takes Event Instant, then the
        transitions into account.

        Equation 2 calculates Tester
   SHOULD collect a timestamp of the average convergence time over all
        routes to which packets have been sent. The average convergence
        time is often lower than Convergence Event Instant and the maximum convergence time
        over all routes, so it can produce a result that is faster than
   Tester SHOULD observe Convergence Packet Loss separately on the actual convergence time..  Therefore, Next-
   Best Egress Interface.  When benchmarking Loss-Derived Convergence Method
   Time, Convergence Packet Loss is not the preferred method to measure
        convergence benchmarks.  For these reasons the RECOMMENDED
        method to obtain a benchmark metric for convergence time measured and Equation 6 is the
        Rate-Derived applied.

         Loss-Derived Convergence Method. Time =
             Convergence Packet Loss/Offered Load
             - (Convergence Event Instant - start traffic instant)

                                Equation 6

   The Convergence Event Instant and start traffic instant SHOULD be
   collected by the Tester.

   Measurement Units: seconds

   Issues: None

   See Also:

   Convergence Packet Loss
        Rate-Derived Convergence Method
        Route-Specific Convergence
        Convergence Event Transition
        Convergence Recovery Transition

   3.4.5 Loss, Connectivity Packet Sampling Interval Loss, Route Convergence

3.6.5.  Route Loss of Connectivity Period

   Definition:

   The interval at which the tester (test equipment) polls to make
        measurements time duration of traffic loss for arriving packet flows.

        Discussion:
        At least one packet per a specific route in entry
   following a Convergence Event until Full Convergence completion, as
   observed using the FIB for all routes in Route-Specific Loss-Derived Method.

   Discussion:

   In general the
        FIB MUST be offered Route Loss of Connectivity Period is not equal to the
   Route-Specific Convergence Time.  If the DUT within continues to forward
   traffic to the Packet Sampling
        Interval.  Metrics measured at Preferred Egress Interface after the Packet Sampling Interval
        MUST include Forwarding Rate and Convergence Packet Loss.

        Packet Sampling Interval can influence Event
   is applied then the Route Loss of Connectivity Period will be smaller
   than the Route-Specific Convergence Graph. Time.  This is particularly true when implementations complete Full
        Convergence in less time than also specifically
   the Packet Sampling Interval. case after reversing a failure event.

   The
        Convergence Event Transition and Convergence Recovery Transition
                 Link-State IGP Data Plane Route Convergence

        can become exaggerated when the Packet Sampling Interval is too
        long.  In this condition, Loss of Connectivity Period may be equal to the Rate-Derived Route-
   Specific Convergence Method
        may produce Time, as a larger than actual convergence time.  In such
        cases characteristic of the Loss-Derived Convergence Method may produce
   Event, traffic for all routes starts dropping instantaneously on the
   Convergence Event Instant.  See discussion in [Po09m].

   For the testcases described in [Po09m] the Route Loss of Connectivity
   Period is expected to be a more
        accurate result. single Loss Period [Ko02].

   When benchmarking Route Loss of Connectivity Period, Connectivity
   Packet Loss is measured for each route and Equation 7 is applied for
   each measured route entry.  The recommended value calculation is equal to Equation 3 in
   Section 3.6.3.

   Route Loss of Connectivity Period =
      Connectivity Packet Loss for configuration specific route/Offered Load per route

                                Equation 7

   Route Loss of
        the Packet Sampling Interval is provided in [Po07m]. Connectivity Period SHOULD be measured using Route-
   Specific Loss-Derived Method.

   Measurement Units: seconds

   Issues: None

   See Also:

   Route-Specific Convergence Time, Route-Specific Loss-Derived Method,
   Connectivity Packet Loss
        Convergence Event Transition
        Convergence Recovery Transition

3.5 Benchmarks

   3.5.1 Full Convergence Time

3.6.6.  Loss-Derived Loss of Connectivity Period

   Definition:

   The amount of average time it takes duration of traffic loss for Full all routes following a
   Convergence to occur.

        Discussion: Event until Full Convergence Time can be determined completion, as observed
   using the Rate-Derived
        Convergence Method or Loss-Derived Convergence Method.  The
        Rate-Derived

   Discussion:

   In general the Loss-Derived Loss of Connectivity Period is not equal
   to the Loss-Derived Convergence Method Time.  If the DUT continues to
   forward traffic to the Preferred Egress Interface after the
   Convergence Event is RECOMMENDED.  When
        measuring Route-Specific applied then the Loss-Derived Loss of
   Connectivity Period will be smaller than the Loss-Derived Convergence Time, there
   Time.  This is also specifically the case after reversing a failure
   event.

   The Loss-Derived Loss of Connectivity Period may be
        conditions in which equal to the maximum Route Specific
   Loss-Derived Convergence Time
        can be reported if, as a characteristic of the Full
   Convergence Time.  Full Event, traffic for all routes starts dropping
   instantaneously on the Convergence
        may or may not Event Instant.  See discussion in
   [Po09m].

   For the testcases described in [Po09m] each route's Route Loss of
   Connectivity Period is expected to be sustained over time. a single Loss Period [Ko02].

   When benchmarking Loss-Derived Loss of Connectivity Period,
   Connectivity Packet Loss is measured for all routes and Equation 8 is
   applied.  The Sustained
        Convergence Validation Time MUST calculation is equal to Equation 5 in Section 3.6.4.

          Loss-Derived Loss of Connectivity Period =
             Connectivity Packet Loss for all routes/Offered Load

                                Equation 8

   Loss-Derived Loss of Connectivity Period SHOULD be applied. measured using
   Loss-Derived Method.

   Measurement Units: seconds

   Issues: None

   See Also:

   Loss-Derived Convergence Time, Loss-Derived Method, Connectivity
   Packet Loss

3.7.  Measurement Terms

3.7.1.  Convergence Event

   Definition:

   The occurrence of a planned or unplanned event in the network that
   will result in a change in the egress interface of the Device Under
   Test (DUT) for routed packets.

   Discussion:

   Convergence Events include but are not limited to link loss, routing
   protocol session loss, router failure, configuration change, and
   better next-hop learned via a routing protocol.

   Measurement Units:
        seconds N/A

   Issues: None

   See Also:
        Full Convergence
        Rate-Derived Convergence Method
        Loss-Derived Convergence Method

   3.5.2 First Route Convergence Time Event Instant

3.7.2.   Packet Loss

   Definition:

   The amount number of time for Convergence 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 until the
        convergence of is a first route entry on modified version of the Next-Best Egress
        Interface, term "Frame Loss Rate" as indicated by the First Route
   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
        Instant.

                 Link-State IGP Data Plane Route Packet Loss

3.7.3.  Convergence

        Discussion: Packet Loss

   Definition:

   The First Route Convergence Time benchmarking metric can be
        measured when benchmarking either Full number of packets lost due to a Convergence or
        Route-Specific Convergence.  When benchmarking Event until Full Convergence,
        First Route
   Convergence Time can be measured completes, as observed on the time
        difference from the Convergence Event Instant and the First
        Route Convergence Instant, as shown with Equation 4a.

        (Equation 4a)
        First Route Convergence Time =
        First Route Convergence Instant - Convergence Event Instant

        First Route Next-Best Egress Interface.

   Discussion:

   Convergence Time should be measured at the maximum
        Throughput of the DUT.  At least one packet per route in the FIB
        for all routes in the FIB MUST be offered to the DUT within the Packet Sampling Interval.  Failure Loss is observed on the Next-Best Egress
   Interface.  It only needs to achieve the First Route be observed for Convergence Instant results in a First Route Events that
   do not cause instantaneous traffic loss at Convergence Time
        benchmark Event Instant.

   Convergence Packet Loss includes packets that were lost and packets
   that were delayed due to buffering.  The magnitude of an acceptable
   Forwarding Delay is a parameter of infinity. the methodology.  If a maximum
   acceptable Forwarding Delay threshold is applied it MUST be reported.

   Measurement Units:
        seconds number of packets

   Issues: None

   See Also:

   Packet Loss, Full Convergence, Convergence Event, Connectivity Packet
   Loss

3.7.4.  Connectivity Packet Loss
        First Route Convergence Instant

   3.5.3 Route-Specific Convergence Time

   Definition:

   The amount of time it takes for Route-Specific Convergence to
        be completed as calculated from the amount number of Convergence
        Packet Loss for the flow associated packets lost due to a specific route.

        Route-Specific Convergence Time can be calculated from Event until Full
   Convergence completes.

   Discussion:

   Connectivity Packet Loss as shown with Equation 3.

        (Equation 3) Route-Specific Convergence Time = is observed on all DUT egress interfaces.

   Convergence Packets Packet Loss / Offered Load
          where units are includes packets / packets/second = seconds
                 Link-State IGP Data Plane Route Convergence

        Discussion:
        It is possible to provide an offered load that has flows
        matching every route entry in the FIB were lost and benchmarking
        Route-Specific Convergence Time for all route entries. packets
   that were delayed due to buffering.  The
        number magnitude of flows that can be measured an acceptable
   Forwarding Delay is dependent upon the flow
        measurement capabilities a parameter of the Tester.  When benchmarking
        Route-Specific Convergence, methodology.  If a maximum
   acceptable Forwarding Delay threshold is applied it MUST be reported.

   Measurement Units: number of packets

   Issues: None

   See Also:

   Packet Loss, Route Loss of Connectivity Period, Convergence Event,
   Convergence Packet Loss is measured
        for specific flow(s) and Equation 3 is applied

3.7.5.  Packet Sampling Interval

   Definition:

   The interval at which the Tester (test equipment) polls to make
   measurements for each flow.
        Each flow has a single destination address matching a different arriving packets.

   Discussion:

   At least one packet per route entry.  The fastest measurable convergence time is equal
        to in the time between two consecutive packets of a flow FIB for all routes MUST be
   offered
        by to the Tester.  In practice, DUT within the fastest measurable
        convergence time is Packet Sampling Interval.  Metrics
   measured at the Packet Sampling Interval of MUST include Forwarding Rate
   and received packets.

   Packet Sampling Interval can influence the Tester. Convergence Graph as
   observed with the Rate-Derived Method.  This is particularly true
   when implementations complete Full Convergence in less time than the
   Packet Sampling Interval.  The Route-Specific Convergence Time benchmarks enable minimum,
        maximum, average, Event Instant and median convergence time measurements to First
   Route Convergence Instant may not be
        reported by comparing the results for easily identifiable and the different route
        entries.  It also enables benchmarking of convergence time when
        configuring
   Rate-Derived Method may produce a priority larger than actual convergence
   time.

   The recommended value for route entry(ies).  Since
        multiple Route-Specific Convergence Times can be measured it is
        possible to have an array configuration of results.  The format for reporting
        Route-Specific Convergence Time the Packet Sampling
   Interval when using the Rate-Derived Method is provided in [Po07m]. [Po09m].
   For the other benchmark methods the value of the Packet Sampling
   Interval does not contribute to the measurement accuracy.

   Measurement Units: seconds

   Issues: None

   See Also:
        Convergence Event
        Convergence Packet Loss
        Route-Specific Convergence

   3.5.4 Rate-Derived Method

3.7.6.  Sustained Convergence Validation Time

   Definition:

   The amount of time for which the completion of Full Convergence is
   maintained without additional packet loss.

   Discussion:

   The purpose of the Sustained Convergence Validation Time is to
   produce Convergence convergence benchmarks protected against fluctuation in Throughput
   Forwarding Rate after the completion of Full Convergence is observed.
   The RECOMMENDED Sustained Convergence Validation Time to be used is 5
   seconds.  The BMWG selected 5 seconds based upon RFC 2544 [Ba99] [Br99]
   which recommends waiting 2 seconds for residual frames to arrive and
   5 seconds for DUT restabilization.

                 Link-State IGP Data Plane Route

   Measurement Units: seconds

   Issues: None

   See Also:

   Full Convergence, Convergence Recovery Instant

3.8.  Miscellaneous Terms

3.8.1.  Stale Forwarding

   Definition:

   Forwarding of traffic to route entries that no longer exist or to
   route entries with next-hops that are no longer preferred.

   Discussion:

   Stale Forwarding can be caused by a Convergence Event and can
   manifest as a "black-hole" or microloop that produces packet loss, or
   out-of-order packets, or delayed packets.  Stale Forwarding can exist
   until Network Convergence is completed.

   Measurement Units:
        seconds N/A

   Issues: None

   See Also:
        Full Convergence Network Convergence Recovery Instant

   3.5.5 Reversion

3.8.2.  Nested Convergence Time Event

   Definition:

   The amount occurrence of time for the DUT to complete Full a Convergence
        to the Preferred Egress Interface, instead of Event while the Next-Best
        Egress Interface, upon recovery route table is
   converging from a prior Convergence Event.

   Discussion:
        Reversion

   The Convergence Time is the amount of time Events for Full a Nested Convergence to the original egress interface.  This is
        achieved by recovering Event MUST occur with
   different neighbors.  A possible observation from the Convergence Event, such as
        restoring the failed link.  Reversion a Nested
   Convergence Time
        can Event will be measured using the Rate-Derived Convergence Method
        or Loss-Derived Convergence Method.  The Rate-Derived
        Convergence Method is RECOMMENDED.  It is possible to have the Reversion Convergence Time differ withdrawal of routes from one neighbor
   while the Full
        Convergence Time. routes of another neighbor are being installed.

   Measurement Units: seconds N/A
   Issues: None

   See Also:
        Preferred Egress Interface Convergence Event
        Rate-Derived Convergence Method

4. IANA Considerations

   This document requires no IANA considerations.

5.  Security Considerations

   Documents of this type do not directly affect the security of
   Internet or corporate networks as long as benchmarking is not
   performed on devices or systems connected to production networks.
   Security threats and how to counter these in SIP and the media layer
   is discussed in RFC3261, RFC3550, and RFC3711 and various other
   drafts.  This document attempts to formalize a set of common terminology
   methodology for benchmarking IGP convergence performance in a lab
   environment.

                 Link-State IGP Data Plane Route Convergence

5.  IANA Considerations

   This document requires no IANA considerations.

6.  Acknowledgements

   Thanks to Sue Hares, Al Morton, Kevin Dubray, Ron Bonica, David Ward,
   Kris Michielsen
   Peter De Vriendt and the BMWG for their contributions to this work.

7.  References
 7.1

7.1.  Normative References
   [Ba91]

   [Br91]   Bradner, S. S., "Benchmarking Terminology terminology for Network
         Interconnection Devices", RFC1242, network
            interconnection devices", RFC 1242, July 1991.

   [Ba99]

   [Br97]   Bradner, S., "Key words for use in RFCs to Indicate
            Requirement Levels", BCP 14, RFC 2119, March 1997.

   [Br99]   Bradner, S. and J. McQuaid, J., "Benchmarking Methodology for
            Network Interconnect Devices", RFC 2544, March 1999.

   [Br97] Bradner, S., "Key words for use in RFCs to Indicate

   [Ca90]   Callon, R., "Use of OSI IS-IS for Routing routing in TCP/IP and Dual
         Environments", dual
            environments", RFC 1195, December 1990.

   [Co08]   Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF for
            IPv6", RFC 5340, July 2008.

   [Ho08]   Hopps, C., "Routing IPv6 with IS-IS", RFC 5308,
            October 2008.

   [Ko02]   Koodli, R. and R. Ravikanth, "One-way Loss Pattern Sample
            Metrics", RFC 3357, August 2002.

   [Ma98]   Mandeville, R., "Benchmarking Terminology for LAN Switching
            Devices", RFC 2285, February 1998.

   [Mo98] Moy, J., "OSPF Version 2", RFC 2328, IETF, April 1998.

   [Mo06]   Morton, A., et al, 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.

   [Po06]   Poretsky, S., et al., Perser, J., Erramilli, S., and S. Khurana,
            "Terminology for Benchmarking Network-layer Traffic Control
            Mechanisms", RFC 4689,
         November October 2006.

   [Po07a]

   [Po09a]  Poretsky, S., "Benchmarking Applicability "Considerations for Benchmarking Link-State
            IGP Data Plane Route Convergence",
         draft-ietf-bmwg-igp-dataplane-conv-app-17, work
            draft-ietf-bmwg-igp-dataplane-conv-app-17 (work in progress,
            progress), March 2009.

   [Po07m]

   [Po09m]  Poretsky, S. and B. Imhoff, B., "Benchmarking Methodology for
            Link-State IGP Data Plane Route Convergence",
         draft-ietf-bmwg-igp-dataplane-conv-meth-17, work
            draft-ietf-bmwg-igp-dataplane-conv-meth-18 (work in progress,
         March
            progress), July 2009.

 7.2

7.2.  Informative References

   [Ca01] S.   Casner, C. S., Alaettinoglu, C., and C. Kuan, "A Fine-Grained
            View of High Performance Networking", NANOG 22, June 2001.

   [Ci03] L.   Ciavattone, A. L., Morton, A., and G. Ramachandran,
            "Standardized Active Measurements on a Tier 1 IP Backbone",
            IEEE Communications Magazine, pp90-97, Magazine p90-97, May 2003.

                 Link-State IGP Data Plane Route Convergence

8. Author's Address

Authors' Addresses

   Scott Poretsky
   Allot Communications
   67 South Bedford Street, Suite 400
   Burlington, MA  01803
   USA

   Phone: + 1 508 309 2179
   Email: sporetsky@allot.com

   Brent Imhoff
   Juniper Networks
   1194 North Mathilda Ave
   Sunnyvale, CA  94089
   USA

   Phone: + 1 314 378 2571
      EMail:
   Email: bimhoff@planetspork.com

   Kris Michielsen
   Cisco Systems
   6A De Kleetlaan
   Diegem, BRABANT  1831
   Belgium

   Email: kmichiel@cisco.com