File: rfc6412.html

package info (click to toggle)
doc-rfc 20230121-1
links: PTS, VCS
area: non-free
in suites: bookworm, forky, sid, trixie
size: 1,609,944 kB
file content (1621 lines) | stat: -rw-r--r-- 69,221 bytes
parent folder | download | duplicates (2)
<pre>Internet Engineering Task Force (IETF)                       S. Poretsky
Request for Comments: 6412                          Allot Communications
Category: Informational                                        B. Imhoff
ISSN: 2070-1721                                              F5 Networks
                                                           K. Michielsen
                                                           Cisco Systems
                                                           November 2011


Terminology for Benchmarking Link-State IGP Data-Plane Route Convergence

Abstract

   This document describes the terminology for benchmarking link-state
   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 IS-IS and
   OSPF.

Status of This Memo

   This document is not an Internet Standards Track specification; it is
   published for informational purposes.

   This document is a product of the Internet Engineering Task Force
   (IETF).  It represents the consensus of the IETF community.  It has
   received public review and has been approved for publication by the
   Internet Engineering Steering Group (IESG).  Not all documents
   approved by the IESG are a candidate for any level of Internet
   Standard; see <a href="./rfc5741#section-2">Section&nbsp;2 of RFC 5741</a>.

   Information about the current status of this document, any errata,
   and how to provide feedback on it may be obtained at
   <a href="http://www.rfc-editor.org/info/rfc6412">http://www.rfc-editor.org/info/rfc6412</a>.

Copyright Notice

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

   This document is subject to <a href="https://www.rfc-editor.org/bcp/bcp78">BCP 78</a> and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (<a href="http://trustee.ietf.org/license-info">http://trustee.ietf.org/license-info</a>) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must




<span class="grey">Poretsky, et al.              Informational                     [Page 1]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-2" ></span>
<span class="grey"><a href="./rfc6412">RFC 6412</a>          IGP Convergence Benchmark Terminology    November 2011</span>


   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

   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.




































<span class="grey">Poretsky, et al.              Informational                     [Page 2]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-3" ></span>
<span class="grey"><a href="./rfc6412">RFC 6412</a>          IGP Convergence Benchmark Terminology    November 2011</span>


Table of Contents

   <a href="#section-1">1</a>.  Introduction and Scope . . . . . . . . . . . . . . . . . . . .  <a href="#page-4">4</a>
   <a href="#section-2">2</a>.  Existing Definitions . . . . . . . . . . . . . . . . . . . . .  <a href="#page-4">4</a>
   <a href="#section-3">3</a>.  Term Definitions . . . . . . . . . . . . . . . . . . . . . . .  <a href="#page-5">5</a>
     <a href="#section-3.1">3.1</a>.  Convergence Types  . . . . . . . . . . . . . . . . . . . .  <a href="#page-5">5</a>
       <a href="#section-3.1.1">3.1.1</a>.  Route Convergence  . . . . . . . . . . . . . . . . . .  <a href="#page-5">5</a>
       <a href="#section-3.1.2">3.1.2</a>.  Full Convergence . . . . . . . . . . . . . . . . . . .  <a href="#page-5">5</a>
     <a href="#section-3.2">3.2</a>.  Instants . . . . . . . . . . . . . . . . . . . . . . . . .  <a href="#page-6">6</a>
       <a href="#section-3.2.1">3.2.1</a>.  Traffic Start Instant  . . . . . . . . . . . . . . . .  <a href="#page-6">6</a>
       <a href="#section-3.2.2">3.2.2</a>.  Convergence Event Instant  . . . . . . . . . . . . . .  <a href="#page-6">6</a>
       <a href="#section-3.2.3">3.2.3</a>.  Convergence Recovery Instant . . . . . . . . . . . . .  <a href="#page-7">7</a>
       <a href="#section-3.2.4">3.2.4</a>.  First Route Convergence Instant  . . . . . . . . . . .  <a href="#page-8">8</a>
     <a href="#section-3.3">3.3</a>.  Transitions  . . . . . . . . . . . . . . . . . . . . . . .  <a href="#page-8">8</a>
       <a href="#section-3.3.1">3.3.1</a>.  Convergence Event Transition . . . . . . . . . . . . .  <a href="#page-8">8</a>
       <a href="#section-3.3.2">3.3.2</a>.  Convergence Recovery Transition  . . . . . . . . . . .  <a href="#page-9">9</a>
     <a href="#section-3.4">3.4</a>.  Interfaces . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-10">10</a>
       <a href="#section-3.4.1">3.4.1</a>.  Local Interface  . . . . . . . . . . . . . . . . . . . <a href="#page-10">10</a>
       <a href="#section-3.4.2">3.4.2</a>.  Remote Interface . . . . . . . . . . . . . . . . . . . <a href="#page-10">10</a>
       <a href="#section-3.4.3">3.4.3</a>.  Preferred Egress Interface . . . . . . . . . . . . . . <a href="#page-10">10</a>
       <a href="#section-3.4.4">3.4.4</a>.  Next-Best Egress Interface . . . . . . . . . . . . . . <a href="#page-11">11</a>
     <a href="#section-3.5">3.5</a>.  Benchmarking Methods . . . . . . . . . . . . . . . . . . . <a href="#page-11">11</a>
       <a href="#section-3.5.1">3.5.1</a>.  Rate-Derived Method  . . . . . . . . . . . . . . . . . <a href="#page-11">11</a>
       <a href="#section-3.5.2">3.5.2</a>.  Loss-Derived Method  . . . . . . . . . . . . . . . . . <a href="#page-14">14</a>
       <a href="#section-3.5.3">3.5.3</a>.  Route-Specific Loss-Derived Method . . . . . . . . . . <a href="#page-15">15</a>
     <a href="#section-3.6">3.6</a>.  Benchmarks . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-17">17</a>
       <a href="#section-3.6.1">3.6.1</a>.  Full Convergence Time  . . . . . . . . . . . . . . . . <a href="#page-17">17</a>
       <a href="#section-3.6.2">3.6.2</a>.  First Route Convergence Time . . . . . . . . . . . . . <a href="#page-18">18</a>
       <a href="#section-3.6.3">3.6.3</a>.  Route-Specific Convergence Time  . . . . . . . . . . . <a href="#page-18">18</a>
       <a href="#section-3.6.4">3.6.4</a>.  Loss-Derived Convergence Time  . . . . . . . . . . . . <a href="#page-20">20</a>
       <a href="#section-3.6.5">3.6.5</a>.  Route Loss of Connectivity Period  . . . . . . . . . . <a href="#page-21">21</a>
       <a href="#section-3.6.6">3.6.6</a>.  Loss-Derived Loss of Connectivity Period . . . . . . . <a href="#page-22">22</a>
     <a href="#section-3.7">3.7</a>.  Measurement Terms  . . . . . . . . . . . . . . . . . . . . <a href="#page-23">23</a>
       <a href="#section-3.7.1">3.7.1</a>.  Convergence Event  . . . . . . . . . . . . . . . . . . <a href="#page-23">23</a>
       <a href="#section-3.7.2">3.7.2</a>.  Convergence Packet Loss  . . . . . . . . . . . . . . . <a href="#page-23">23</a>
       <a href="#section-3.7.3">3.7.3</a>.  Connectivity Packet Loss . . . . . . . . . . . . . . . <a href="#page-24">24</a>
       <a href="#section-3.7.4">3.7.4</a>.  Packet Sampling Interval . . . . . . . . . . . . . . . <a href="#page-24">24</a>
       <a href="#section-3.7.5">3.7.5</a>.  Sustained Convergence Validation Time  . . . . . . . . <a href="#page-25">25</a>
       <a href="#section-3.7.6">3.7.6</a>.  Forwarding Delay Threshold . . . . . . . . . . . . . . <a href="#page-26">26</a>
     <a href="#section-3.8">3.8</a>.  Miscellaneous Terms  . . . . . . . . . . . . . . . . . . . <a href="#page-26">26</a>
       <a href="#section-3.8.1">3.8.1</a>.  Impaired Packet  . . . . . . . . . . . . . . . . . . . <a href="#page-26">26</a>
   <a href="#section-4">4</a>.  Security Considerations  . . . . . . . . . . . . . . . . . . . <a href="#page-27">27</a>
   <a href="#section-5">5</a>.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-27">27</a>
   <a href="#section-6">6</a>.  Normative References . . . . . . . . . . . . . . . . . . . . . <a href="#page-27">27</a>







<span class="grey">Poretsky, et al.              Informational                     [Page 3]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-4" ></span>
<span class="grey"><a href="./rfc6412">RFC 6412</a>          IGP Convergence Benchmark Terminology    November 2011</span>


<span class="h2"><a class="selflink" id="section-1" href="#section-1">1</a>.  Introduction and Scope</span>

   This document is a companion to [<a href="#ref-Po11m" title="&quot;Benchmarking Methodology for Link-State IGP Data-Plane Route Convergence&quot;">Po11m</a>], which contains the
   methodology to be used for benchmarking link-state Interior Gateway
   Protocol (IGP) convergence by observing the data plane.  The purpose
   of this document is to introduce new terms required to complete
   execution of the Link-State IGP Data-Plane Route Convergence
   methodology [<a href="#ref-Po11m" title="&quot;Benchmarking Methodology for Link-State IGP Data-Plane Route Convergence&quot;">Po11m</a>].

   IGP convergence time is measured by observing the data plane through
   the Device Under Test (DUT) at the Tester.  The methodology and
   terminology to be used for benchmarking IGP convergence can be
   applied to IPv4 and IPv6 traffic and link-state IGPs such as
   Intermediate System to Intermediate System (IS-IS) [<a href="#ref-Ca90" title="&quot;Use of OSI IS-IS for routing in TCP/IP and dual environments&quot;">Ca90</a>][Ho08], Open
   Shortest Path First (OSPF) [<a href="#ref-Mo98" title="&quot;OSPF Version 2&quot;">Mo98</a>] [<a href="#ref-Co08" title="&quot;OSPF for IPv6&quot;">Co08</a>], and others.

<span class="h2"><a class="selflink" id="section-2" href="#section-2">2</a>.  Existing Definitions</span>

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

          Throughput                       [<a href="#ref-Br91" title="&quot;Benchmarking terminology for network interconnection devices&quot;">Br91</a>], Section 3.17
          Offered Load                     [<a href="#ref-Ma98" title="&quot;Benchmarking Terminology for LAN Switching Devices&quot;">Ma98</a>], Section 3.5.2
          Forwarding Rate                  [<a href="#ref-Ma98" title="&quot;Benchmarking Terminology for LAN Switching Devices&quot;">Ma98</a>], Section 3.6.1
          Device Under Test (DUT)          [<a href="#ref-Ma98" title="&quot;Benchmarking Terminology for LAN Switching Devices&quot;">Ma98</a>], Section 3.1.1
          System Under Test (SUT)          [<a href="#ref-Ma98" title="&quot;Benchmarking Terminology for LAN Switching Devices&quot;">Ma98</a>], Section 3.1.2
          Out-of-Order Packet              [<a href="#ref-Po06" title="&quot;Terminology for Benchmarking Network-layer Traffic Control Mechanisms&quot;">Po06</a>], Section 3.3.4
          Duplicate Packet                 [<a href="#ref-Po06" title="&quot;Terminology for Benchmarking Network-layer Traffic Control Mechanisms&quot;">Po06</a>], Section 3.3.5
          Stream                           [<a href="#ref-Po06" title="&quot;Terminology for Benchmarking Network-layer Traffic Control Mechanisms&quot;">Po06</a>], Section 3.3.2
          Forwarding Delay                 [<a href="#ref-Po06" title="&quot;Terminology for Benchmarking Network-layer Traffic Control Mechanisms&quot;">Po06</a>], Section 3.2.4
          IP Packet Delay Variation (IPDV) [<a href="#ref-De02" title="&quot;IP Packet Delay Variation Metric for IP Performance Metrics (IPPM)&quot;">De02</a>], Section 1.2
          Loss Period                      [<a href="#ref-Ko02" title="&quot;One-way Loss Pattern Sample Metrics&quot;">Ko02</a>], Section 4

   The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in <a href="https://www.rfc-editor.org/bcp/bcp14">BCP 14</a>, <a href="./rfc2119">RFC 2119</a>
   [<a href="#ref-Br97" title="&quot;Key words for use in RFCs to Indicate Requirement Levels&quot;">Br97</a>].  <a href="./rfc2119">RFC 2119</a> defines the use of these keywords 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.











<span class="grey">Poretsky, et al.              Informational                     [Page 4]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-5" ></span>
<span class="grey"><a href="./rfc6412">RFC 6412</a>          IGP Convergence Benchmark Terminology    November 2011</span>


<span class="h2"><a class="selflink" id="section-3" href="#section-3">3</a>.  Term Definitions</span>

<span class="h3"><a class="selflink" id="section-3.1" href="#section-3.1">3.1</a>.  Convergence Types</span>

<span class="h4"><a class="selflink" id="section-3.1.1" href="#section-3.1.1">3.1.1</a>.  Route Convergence</span>

   Definition:

      The process of updating all components of the 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 for a route entry is
      successful on the Next-Best Egress Interface (<a href="#section-3.4.4">Section 3.4.4</a>).

   Discussion:

      In general, IGP convergence does not necessarily result in a
      change in forwarding.  But the test cases in [<a href="#ref-Po11m" title="&quot;Benchmarking Methodology for Link-State IGP Data-Plane Route Convergence&quot;">Po11m</a>] are specified
      such that the IGP convergence results in a change of egress
      interface for the measurement data-plane traffic.  Due to this
      property of the test case specifications, Route Convergence can be
      observed externally by the rerouting of the measurement data-plane
      traffic to the Next-Best Egress Interface (<a href="#section-3.4.4">Section 3.4.4</a>).

   Measurement Units:

      N/A

   See Also:

      Next-Best Egress Interface, Full Convergence

<span class="h4"><a class="selflink" id="section-3.1.2" href="#section-3.1.2">3.1.2</a>.  Full Convergence</span>

   Definition:

      Route Convergence for all routes in the Forwarding Information
      Base (FIB).

   Discussion:

      In general, IGP convergence does not necessarily result in a
      change in forwarding.  But the test cases in [<a href="#ref-Po11m" title="&quot;Benchmarking Methodology for Link-State IGP Data-Plane Route Convergence&quot;">Po11m</a>] are specified
      such that the IGP convergence results in a change of egress
      interface for the measurement data-plane traffic.  Due to this
      property of the test cases specifications, Full Convergence can be
      observed externally by the rerouting of the measurement data-plane
      traffic to the Next-Best Egress Interface (<a href="#section-3.4.4">Section 3.4.4</a>).



<span class="grey">Poretsky, et al.              Informational                     [Page 5]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-6" ></span>
<span class="grey"><a href="./rfc6412">RFC 6412</a>          IGP Convergence Benchmark Terminology    November 2011</span>


   Measurement Units:

      N/A

   See Also:

      Next-Best Egress Interface, Route Convergence

<span class="h3"><a class="selflink" id="section-3.2" href="#section-3.2">3.2</a>.  Instants</span>

<span class="h4"><a class="selflink" id="section-3.2.1" href="#section-3.2.1">3.2.1</a>.  Traffic Start Instant</span>

   Definition:

      The time instant the Tester sends out the first data packet to the
      DUT.

   Discussion:

      If using the Loss-Derived Method (<a href="#section-3.5.2">Section 3.5.2</a>) or the Route-
      Specific Loss-Derived Method (<a href="#section-3.5.3">Section 3.5.3</a>) to benchmark IGP
      convergence time, and the applied Convergence Event
      (<a href="#section-3.7.1">Section 3.7.1</a>) does not cause instantaneous traffic loss for all
      routes at the Convergence Event Instant (<a href="#section-3.2.2">Section 3.2.2</a>), 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:

      seconds (and fractions), reported with resolution sufficient to
      distinguish between different instants

   See Also:

      Loss-Derived Method, Route-Specific Loss-Derived Method,
      Convergence Event, Convergence Event Instant

<span class="h4"><a class="selflink" id="section-3.2.2" href="#section-3.2.2">3.2.2</a>.  Convergence Event Instant</span>

   Definition:

      The time instant that a Convergence Event (<a href="#section-3.7.1">Section 3.7.1</a>) occurs.








<span class="grey">Poretsky, et al.              Informational                     [Page 6]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-7" ></span>
<span class="grey"><a href="./rfc6412">RFC 6412</a>          IGP Convergence Benchmark Terminology    November 2011</span>


   Discussion:

      If the Convergence Event (<a href="#section-3.7.1">Section 3.7.1</a>) causes instantaneous
      traffic loss on the Preferred Egress Interface (<a href="#section-3.4.3">Section 3.4.3</a>),
      the Convergence Event Instant is observable from the data plane as
      the instant that no more packets are received on the Preferred
      Egress Interface.

      The Tester SHOULD collect a timestamp on the Convergence Event
      Instant if the Convergence Event does not cause instantaneous
      traffic loss on the Preferred Egress Interface (<a href="#section-3.4.3">Section 3.4.3</a>).

   Measurement Units:

      seconds (and fractions), reported with resolution sufficient to
      distinguish between different instants

   See Also:

      Convergence Event, Preferred Egress Interface

<span class="h4"><a class="selflink" id="section-3.2.3" href="#section-3.2.3">3.2.3</a>.  Convergence Recovery Instant</span>

   Definition:

      The time instant that Full Convergence (<a href="#section-3.1.2">Section 3.1.2</a>) has
      completed.

   Discussion:

      The Full Convergence completed state MUST be maintained for an
      interval of duration equal to the Sustained Convergence Validation
      Time (<a href="#section-3.7.5">Section 3.7.5</a>) in order to validate the Convergence Recovery
      Instant.

      The Convergence Recovery Instant is observable from the data plane
      as the instant the DUT forwards traffic to all destinations over
      the Next-Best Egress Interface (<a href="#section-3.4.4">Section 3.4.4</a>) without
      impairments.

   Measurement Units:

      seconds (and fractions), reported with resolution sufficient to
      distinguish between different instants







<span class="grey">Poretsky, et al.              Informational                     [Page 7]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-8" ></span>
<span class="grey"><a href="./rfc6412">RFC 6412</a>          IGP Convergence Benchmark Terminology    November 2011</span>


   See Also:

      Sustained Convergence Validation Time, Full Convergence, Next-Best
      Egress Interface

<span class="h4"><a class="selflink" id="section-3.2.4" href="#section-3.2.4">3.2.4</a>.  First Route Convergence Instant</span>

   Definition:

      The time instant the first route entry completes Route Convergence
      (<a href="#section-3.1.1">Section 3.1.1</a>)

   Discussion:

      Any route may be the first to complete Route Convergence.  The
      First Route Convergence Instant is observable from the data plane
      as the instant that the first packet that is not an Impaired
      Packet (<a href="#section-3.8.1">Section 3.8.1</a>) is received from the Next-Best Egress
      Interface (<a href="#section-3.4.4">Section 3.4.4</a>) or, for the test cases with Equal Cost
      Multi-Path (ECMP) or Parallel Links, the instant that the
      Forwarding Rate on the Next-Best Egress Interface (<a href="#section-3.4.4">Section 3.4.4</a>)
      starts to increase.

   Measurement Units:

      seconds (and fractions), reported with resolution sufficient to
      distinguish between different instants

   See Also:

      Route Convergence, Impaired Packet, Next-Best Egress Interface

<span class="h3"><a class="selflink" id="section-3.3" href="#section-3.3">3.3</a>.  Transitions</span>

<span class="h4"><a class="selflink" id="section-3.3.1" href="#section-3.3.1">3.3.1</a>.  Convergence Event Transition</span>

   Definition:

      A time interval following a Convergence Event (<a href="#section-3.7.1">Section 3.7.1</a>) in
      which the Forwarding Rate on the Preferred Egress Interface
      (<a href="#section-3.4.3">Section 3.4.3</a>) gradually reduces to zero.

   Discussion:

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





<span class="grey">Poretsky, et al.              Informational                     [Page 8]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-9" ></span>
<span class="grey"><a href="./rfc6412">RFC 6412</a>          IGP Convergence Benchmark Terminology    November 2011</span>


      The Forwarding Rate observed on the DUT egress interface(s) may or
      may not decrease to zero.

      The Offered Load, the number of routes, and the Packet Sampling
      Interval (<a href="#section-3.7.4">Section 3.7.4</a>) influence the observations of the
      Convergence Event Transition using the Rate-Derived Method
      (<a href="#section-3.5.1">Section 3.5.1</a>).

   Measurement Units:

      seconds (and fractions)

   See Also:

      Convergence Event, Preferred Egress Interface, Packet Sampling
      Interval, Rate-Derived Method

<span class="h4"><a class="selflink" id="section-3.3.2" href="#section-3.3.2">3.3.2</a>.  Convergence Recovery Transition</span>

   Definition:

      A time interval following the First Route Convergence Instant
      (<a href="#section-3.4.4">Section 3.4.4</a>) in which the Forwarding Rate on the DUT egress
      interface(s) gradually increases to equal to the Offered Load.

   Discussion:

      The Forwarding Rate observed during a Convergence Recovery
      Transition may or may not increase linearly.

      The Offered Load, the number of routes, and the Packet Sampling
      Interval (<a href="#section-3.7.4">Section 3.7.4</a>) influence the observations of the
      Convergence Recovery Transition using the Rate-Derived Method
      (<a href="#section-3.5.1">Section 3.5.1</a>).

   Measurement Units:

      seconds (and fractions)

   See Also:

      First Route Convergence Instant, Packet Sampling Interval, Rate-
      Derived Method








<span class="grey">Poretsky, et al.              Informational                     [Page 9]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-10" ></span>
<span class="grey"><a href="./rfc6412">RFC 6412</a>          IGP Convergence Benchmark Terminology    November 2011</span>


<span class="h3"><a class="selflink" id="section-3.4" href="#section-3.4">3.4</a>.  Interfaces</span>

<span class="h4"><a class="selflink" id="section-3.4.1" href="#section-3.4.1">3.4.1</a>.  Local Interface</span>

   Definition:

      An interface on the DUT.

   Discussion:

      A failure of a Local Interface indicates that the failure occurred
      directly on the DUT.

   Measurement Units:

      N/A

   See Also:

      Remote Interface

<span class="h4"><a class="selflink" id="section-3.4.2" href="#section-3.4.2">3.4.2</a>.  Remote Interface</span>

   Definition:

      An interface on a neighboring router that is not directly
      connected to any interface on the DUT.

   Discussion:

      A failure of a Remote Interface indicates that the failure
      occurred on a neighbor router's interface that is not directly
      connected to the DUT.

   Measurement Units:

      N/A

   See Also:

      Local Interface

<span class="h4"><a class="selflink" id="section-3.4.3" href="#section-3.4.3">3.4.3</a>.  Preferred Egress Interface</span>

   Definition:

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



<span class="grey">Poretsky, et al.              Informational                    [Page 10]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-11" ></span>
<span class="grey"><a href="./rfc6412">RFC 6412</a>          IGP Convergence Benchmark Terminology    November 2011</span>


   Discussion:

      The Preferred Egress Interface is the egress interface prior to a
      Convergence Event (<a href="#section-3.7.1">Section 3.7.1</a>).

   Measurement Units:

      N/A

   See Also:

      Convergence Event, Next-Best Egress Interface

<span class="h4"><a class="selflink" id="section-3.4.4" href="#section-3.4.4">3.4.4</a>.  Next-Best Egress Interface</span>

   Definition:

      The outbound interface or set of outbound interfaces in an Equal
      Cost Multipath (ECMP) set or parallel link set of the Device Under
      Test (DUT) for traffic routed to the second-best next-hop.

   Discussion:

      The Next-Best Egress Interface becomes the egress interface after
      a Convergence Event (<a href="#section-3.4.4">Section 3.4.4</a>).

      For the test cases in [<a href="#ref-Po11m" title="&quot;Benchmarking Methodology for Link-State IGP Data-Plane Route Convergence&quot;">Po11m</a>] using test topologies with an ECMP
      set or parallel link set, the term Preferred Egress Interface
      refers to all members of the link set.

   Measurement Units:

      N/A

   See Also:

      Convergence Event, Preferred Egress Interface

<span class="h3"><a class="selflink" id="section-3.5" href="#section-3.5">3.5</a>.  Benchmarking Methods</span>

<span class="h4"><a class="selflink" id="section-3.5.1" href="#section-3.5.1">3.5.1</a>.  Rate-Derived Method</span>

   Definition:

      The method to calculate convergence time benchmarks from observing
      the Forwarding Rate each Packet Sampling Interval (<a href="#section-3.7.4">Section 3.7.4</a>).





<span class="grey">Poretsky, et al.              Informational                    [Page 11]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-12" ></span>
<span class="grey"><a href="./rfc6412">RFC 6412</a>          IGP Convergence Benchmark Terminology    November 2011</span>


   Discussion:

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

           ^         Traffic                      Convergence
      Fwd  |         Start                        Recovery
      Rate |         Instant                      Instant
           | Offered  ^                             ^
           | Load --&gt; ----------\                   /-----------
           |                     \                 /&lt;--- Convergence
           |                      \     Packet    /      Recovery
           |       Convergence ---&gt;\     Loss    /       Transition
           |       Event            \           /
           |       Transition        \---------/ &lt;-- Max Packet Loss
           |
           +---------------------------------------------------------&gt;
                           ^                   ^                 time
                      Convergence         First Route
                      Event Instant       Convergence Instant

                   Figure 1: Rate-Derived Convergence Graph

      To enable collecting statistics of Out-of-Order Packets per flow
      (see [<a href="#ref-Th00" title="&quot;Multipath Issues in Unicast and Multicast Next-Hop Selection&quot;">Th00</a>], Section 3), the Offered Load SHOULD consist of
      multiple Streams [<a href="#ref-Po06" title="&quot;Terminology for Benchmarking Network-layer Traffic Control Mechanisms&quot;">Po06</a>], and each Stream SHOULD consist of a
      single flow .  If sending multiple Streams, the measured traffic
      statistics for all Streams MUST be added together.

      The destination addresses for the Offered Load MUST be distributed
      such that all routes or a statistically representative subset of
      all routes are matched and each of these routes is offered an
      equal share of the Offered Load.  It is RECOMMENDED to send
      traffic to all routes, but a statistically representative subset
      of all routes can be used if required.

      At least one packet per route for all routes matched in the
      Offered Load MUST be offered to the DUT within each Packet
      Sampling Interval.  For maximum accuracy, the value of the Packet
      Sampling Interval SHOULD be as small as possible, but the presence
      of IP Packet Delay Variation (IPDV) [<a href="#ref-De02" title="&quot;IP Packet Delay Variation Metric for IP Performance Metrics (IPPM)&quot;">De02</a>] may require that a
      larger Packet Sampling Interval be used.

      The Offered Load, IPDV, 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,




<span class="grey">Poretsky, et al.              Informational                    [Page 12]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-13" ></span>
<span class="grey"><a href="./rfc6412">RFC 6412</a>          IGP Convergence Benchmark Terminology    November 2011</span>


      it is possible that a Convergence Event causes the Forwarding Rate
      to drop to zero, while this may not be observed in the Forwarding
      Rate measurements if the Packet Sampling Interval is too large.

      IPDV causes fluctuations in the number of received packets during
      each Packet Sampling Interval.  To account for the presence of
      IPDV in determining if a convergence instant has been reached,
      Forwarding Delay SHOULD be observed during each Packet Sampling
      Interval.  The minimum and maximum number of packets expected in a
      Packet Sampling Interval in presence of IPDV can be calculated
      with Equation 1.

    number of packets expected in a Packet Sampling Interval
      in presence of IP Packet Delay Variation
        = expected number of packets without IP Packet Delay Variation
          +/-( (maxDelay - minDelay) * Offered Load)
    where minDelay and maxDelay indicate (respectively) the minimum and
    maximum Forwarding Delay of packets received during the Packet
    Sampling Interval

                                Equation 1

      To determine if a convergence instant has been reached, the number
      of packets received in a Packet Sampling Interval is compared with
      the range of expected number of packets calculated in Equation 1.

      If packets are going over multiple ECMP members and one or more of
      the members has failed, then the number of received packets during
      each Packet Sampling Interval may vary, even excluding presence of
      IPDV.  To prevent fluctuation of the number of received packets
      during each Packet Sampling Interval for this reason, the Packet
      Sampling Interval duration SHOULD be a whole multiple of the time
      between two consecutive packets sent to the same destination.

      Metrics measured at the Packet Sampling Interval MUST include
      Forwarding Rate and Impaired Packet count.

      To measure convergence time benchmarks for Convergence Events
      (<a href="#section-3.7.1">Section 3.7.1</a>) 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
      (<a href="#section-3.2.2">Section 3.2.2</a>), and the Tester SHOULD observe Forwarding Rate
      separately on the Next-Best Egress Interface.








<span class="grey">Poretsky, et al.              Informational                    [Page 13]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-14" ></span>
<span class="grey"><a href="./rfc6412">RFC 6412</a>          IGP Convergence Benchmark Terminology    November 2011</span>


      Since the Rate-Derived Method does not distinguish between
      individual traffic destinations, it SHOULD NOT be used for any
      route specific measurements.  Therefore, the Rate-Derived Method
      SHOULD NOT be used to benchmark Route Loss of Connectivity Period
      (<a href="#section-3.6.5">Section 3.6.5</a>).

   Measurement Units:

      N/A

   See Also:

      Packet Sampling Interval, Convergence Event, Convergence Event
      Instant, Next-Best Egress Interface, Route Loss of Connectivity
      Period

<span class="h4"><a class="selflink" id="section-3.5.2" href="#section-3.5.2">3.5.2</a>.  Loss-Derived Method</span>

   Definition:

      The method to calculate the Loss-Derived Convergence Time
      (<a href="#section-3.6.4">Section 3.6.4</a>) and Loss-Derived Loss of Connectivity Period
      (<a href="#section-3.6.6">Section 3.6.6</a>) benchmarks from the amount of Impaired Packets
      (<a href="#section-3.8.1">Section 3.8.1</a>).

   Discussion:

      To enable collecting statistics of Out-of-Order Packets per flow
      (see [<a href="#ref-Th00" title="&quot;Multipath Issues in Unicast and Multicast Next-Hop Selection&quot;">Th00</a>], Section 3), the Offered Load SHOULD consist of
      multiple Streams [<a href="#ref-Po06" title="&quot;Terminology for Benchmarking Network-layer Traffic Control Mechanisms&quot;">Po06</a>], and each Stream SHOULD consist of a
      single flow .  If sending multiple Streams, the measured traffic
      statistics for all Streams MUST be added together.

      The destination addresses for the Offered Load MUST be distributed
      such that all routes or a statistically representative subset of
      all routes are matched and each of these routes is offered an
      equal share of the Offered Load.  It is RECOMMENDED to send
      traffic to all routes, but a statistically representative subset
      of all routes can be used if required.

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







<span class="grey">Poretsky, et al.              Informational                    [Page 14]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-15" ></span>
<span class="grey"><a href="./rfc6412">RFC 6412</a>          IGP Convergence Benchmark Terminology    November 2011</span>


      To measure convergence time and loss of connectivity benchmarks
      for Convergence Events that cause instantaneous traffic loss for
      all routes at the Convergence Event Instant, the Tester SHOULD
      observe the Impaired Packet count on all DUT egress interfaces
      (see Connectivity Packet Loss (<a href="#section-3.7.3">Section 3.7.3</a>)).

      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 timestamps of
      the Start Traffic Instant and of the Convergence Event Instant,
      and the Tester SHOULD observe Impaired Packet count separately on
      the Next-Best Egress Interface (see Convergence Packet Loss
      (<a href="#section-3.7.2">Section 3.7.2</a>)).

      Since Loss-Derived Method does not distinguish between traffic
      destinations and the Impaired Packet 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 (<a href="#section-3.6.4">Section 3.6.4</a>) and Loss-Derived Loss of
      Connectivity Period (<a href="#section-3.6.6">Section 3.6.6</a>).

      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:

      N/A

   See Also:

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

<span class="h4"><a class="selflink" id="section-3.5.3" href="#section-3.5.3">3.5.3</a>.  Route-Specific Loss-Derived Method</span>

   Definition:

      The method to calculate the Route-Specific Convergence Time
      (<a href="#section-3.6.3">Section 3.6.3</a>) benchmark from the amount of Impaired Packets
      (<a href="#section-3.8.1">Section 3.8.1</a>) during convergence for a specific route entry.








<span class="grey">Poretsky, et al.              Informational                    [Page 15]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-16" ></span>
<span class="grey"><a href="./rfc6412">RFC 6412</a>          IGP Convergence Benchmark Terminology    November 2011</span>


   Discussion:

      To benchmark Route-Specific Convergence Time, the Tester provides
      an Offered Load that consists of multiple Streams [<a href="#ref-Po06" title="&quot;Terminology for Benchmarking Network-layer Traffic Control Mechanisms&quot;">Po06</a>].  Each
      Stream has a single destination address matching a different route
      entry, for all routes or a statistically representative subset of
      all routes.  Each Stream SHOULD consist of a single flow (see
      [<a href="#ref-Th00" title="&quot;Multipath Issues in Unicast and Multicast Next-Hop Selection&quot;">Th00</a>], Section 3).  Convergence Packet Loss is measured for each
      Stream separately.

      Route-Specific Loss-Derived Method SHOULD always be combined with
      the Rate-Derived Method in order to observe Full Convergence
      completion.  The total amount of Convergence Packet Loss
      (<a href="#section-3.7.2">Section 3.7.2</a>) for each Stream is collected after Full
      Convergence completion.

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

      To measure convergence time and loss of connectivity benchmarks
      for Convergence Events that cause instantaneous traffic loss for
      all routes at the Convergence Event Instant, the Tester SHOULD
      observe Impaired Packet count on all DUT egress interfaces (see
      Connectivity Packet Loss (<a href="#section-3.7.3">Section 3.7.3</a>)).

      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 timestamps of
      the Start Traffic Instant and of the Convergence Event Instant,
      and the Tester SHOULD observe packet loss separately on the Next-
      Best Egress Interface (see Convergence Packet Loss
      (<a href="#section-3.7.2">Section 3.7.2</a>)).

      Since Route-Specific Loss-Derived Method uses traffic streams to
      individual routes, it observes Impaired Packet count as it would
      be experienced by a network user.  For this reason, Route-Specific
      Loss-Derived Method is RECOMMENDED to measure Route-Specific
      Convergence Time benchmarks and Route Loss of Connectivity Period
      benchmarks.

   Measurement Units:

      N/A

   See Also:

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



<span class="grey">Poretsky, et al.              Informational                    [Page 16]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-17" ></span>
<span class="grey"><a href="./rfc6412">RFC 6412</a>          IGP Convergence Benchmark Terminology    November 2011</span>


<span class="h3"><a class="selflink" id="section-3.6" href="#section-3.6">3.6</a>.  Benchmarks</span>

<span class="h4"><a class="selflink" id="section-3.6.1" href="#section-3.6.1">3.6.1</a>.  Full Convergence Time</span>

   Definition:

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

   Discussion:

      Using the Rate-Derived Method, Full Convergence Time can be
      calculated as the time difference between the Convergence Event
      Instant and the Convergence Recovery Instant, as shown in Equation
      2.

        Full Convergence Time =
            Convergence Recovery Instant - Convergence Event Instant

                                Equation 2

      The Convergence Event Instant can be derived from the Forwarding
      Rate observation or from a timestamp collected by the Tester.

      For the test cases described in [<a href="#ref-Po11m" title="&quot;Benchmarking Methodology for Link-State IGP Data-Plane Route Convergence&quot;">Po11m</a>], it is expected that Full
      Convergence Time equals the maximum Route-Specific Convergence
      Time when benchmarking all routes in the FIB using the Route-
      Specific Loss-Derived Method.

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

   Measurement Units:

      seconds (and fractions)

   See Also:

      Full Convergence, Rate-Derived Method, Route-Specific Loss-Derived
      Method, Convergence Event Instant, Convergence Recovery Instant










<span class="grey">Poretsky, et al.              Informational                    [Page 17]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-18" ></span>
<span class="grey"><a href="./rfc6412">RFC 6412</a>          IGP Convergence Benchmark Terminology    November 2011</span>


<span class="h4"><a class="selflink" id="section-3.6.2" href="#section-3.6.2">3.6.2</a>.  First Route Convergence Time</span>

   Definition:

      The duration of the period between the Convergence Event Instant
      and the First Route Convergence Instant as observed using the
      Rate-Derived Method.

   Discussion:

      Using the Rate-Derived Method, First Route Convergence Time can be
      calculated as the time difference between the Convergence Event
      Instant and the First Route Convergence Instant, as shown with
      Equation 3.

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

                                Equation 3

      The Convergence Event Instant can be derived from the Forwarding
      Rate observation or from a timestamp collected by the Tester.

      For the test cases described in [<a href="#ref-Po11m" title="&quot;Benchmarking Methodology for Link-State IGP Data-Plane Route Convergence&quot;">Po11m</a>], it is expected that First
      Route Convergence Time equals the minimum Route-Specific
      Convergence Time when benchmarking all routes in the FIB using the
      Route-Specific Loss-Derived Method.

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

   Measurement Units:

      seconds (and fractions)

   See Also:

      Rate-Derived Method, Route-Specific Loss-Derived Method,
      Convergence Event Instant, First Route Convergence Instant

<span class="h4"><a class="selflink" id="section-3.6.3" href="#section-3.6.3">3.6.3</a>.  Route-Specific Convergence Time</span>

   Definition:

      The amount of time it takes for Route Convergence to be completed
      for a specific route, as calculated from the amount of Impaired
      Packets (<a href="#section-3.8.1">Section 3.8.1</a>) during convergence for a single route
      entry.



<span class="grey">Poretsky, et al.              Informational                    [Page 18]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-19" ></span>
<span class="grey"><a href="./rfc6412">RFC 6412</a>          IGP Convergence Benchmark Terminology    November 2011</span>


   Discussion:

      Route-Specific Convergence Time can only be measured using the
      Route-Specific Loss-Derived Method.

      If the applied Convergence Event causes instantaneous traffic loss
      for all routes at the Convergence Event Instant, Connectivity
      Packet Loss should be observed.  Connectivity Packet Loss is the
      combined Impaired Packet count observed on Preferred Egress
      Interface and Next-Best Egress Interface.  When benchmarking
      Route-Specific Convergence Time, Connectivity Packet Loss is
      measured, and Equation 4 is applied for each measured route.  The
      calculation is equal to Equation 8 in <a href="#section-3.6.5">Section 3.6.5</a>.

   Route-Specific Convergence Time =
    Connectivity Packet Loss for specific route / Offered Load per route

                                Equation 4

      If the applied Convergence Event does not cause instantaneous
      traffic loss for all routes at the Convergence Event Instant, then
      the Tester SHOULD collect timestamps of the Traffic Start Instant
      and of the Convergence Event Instant, and the Tester SHOULD
      observe Convergence Packet Loss separately on the Next-Best Egress
      Interface.  When benchmarking Route-Specific Convergence Time,
      Convergence Packet Loss is measured, and Equation 5 is applied for
      each measured route.

   Route-Specific Convergence Time =
     Convergence Packet Loss for specific route / Offered Load per route
     - (Convergence Event Instant - Traffic Start Instant)

                                Equation 5

      The Route-Specific Convergence Time benchmarks enable minimum,
      maximum, average, and median convergence time measurements to be
      reported by comparing the results for the different route entries.
      It also enables benchmarking of convergence time when configuring
      a priority value for the route entry or entries.  Since multiple
      Route-Specific Convergence Times can be measured, it is possible
      to have an array of results.  The format for reporting Route-
      Specific Convergence Time is provided in [<a href="#ref-Po11m" title="&quot;Benchmarking Methodology for Link-State IGP Data-Plane Route Convergence&quot;">Po11m</a>].

   Measurement Units:

      seconds (and fractions)





<span class="grey">Poretsky, et al.              Informational                    [Page 19]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-20" ></span>
<span class="grey"><a href="./rfc6412">RFC 6412</a>          IGP Convergence Benchmark Terminology    November 2011</span>


   See Also:

      Route-Specific Loss-Derived Method, Convergence Event, Convergence
      Event Instant, Convergence Packet Loss, Connectivity Packet Loss,
      Route Convergence

<span class="h4"><a class="selflink" id="section-3.6.4" href="#section-3.6.4">3.6.4</a>.  Loss-Derived Convergence Time</span>

   Definition:

      The average Route Convergence time for all routes in the
      Forwarding Information Base (FIB), as calculated from the amount
      of Impaired Packets (<a href="#section-3.8.1">Section 3.8.1</a>) during convergence.

   Discussion:

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

      If the applied Convergence Event causes instantaneous traffic loss
      for all routes at the Convergence Event Instant, Connectivity
      Packet Loss (<a href="#section-3.7.3">Section 3.7.3</a>) should be observed.  Connectivity
      Packet Loss is the combined Impaired Packet count observed on
      Preferred Egress Interface and Next-Best Egress Interface.  When
      benchmarking Loss-Derived Convergence Time, Connectivity Packet
      Loss is measured, and Equation 6 is applied.

                Loss-Derived Convergence Time =
                    Connectivity Packet Loss / Offered Load

                                Equation 6

      If the applied Convergence Event does not cause instantaneous
      traffic loss for all routes at the Convergence Event Instant, then
      the Tester SHOULD collect timestamps of the Start Traffic Instant
      and of the Convergence Event Instant, and the Tester SHOULD
      observe Convergence Packet Loss (<a href="#section-3.7.2">Section 3.7.2</a>) separately on the
      Next-Best Egress Interface.  When benchmarking Loss-Derived
      Convergence Time, Convergence Packet Loss is measured and Equation
      7 is applied.


         Loss-Derived Convergence Time =
             Convergence Packet Loss / Offered Load
             - (Convergence Event Instant - Traffic Start Instant)

                                Equation 7




<span class="grey">Poretsky, et al.              Informational                    [Page 20]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-21" ></span>
<span class="grey"><a href="./rfc6412">RFC 6412</a>          IGP Convergence Benchmark Terminology    November 2011</span>


   Measurement Units:

      seconds (and fractions)

   See Also:

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

<span class="h4"><a class="selflink" id="section-3.6.5" href="#section-3.6.5">3.6.5</a>.  Route Loss of Connectivity Period</span>

   Definition:

      The time duration of packet impairments for a specific route entry
      following a Convergence Event until Full Convergence completion,
      as observed using the Route-Specific Loss-Derived Method.

   Discussion:

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

      The Route Loss of Connectivity Period may be equal to the Route-
      Specific Convergence Time if, as a characteristic of the
      Convergence Event, traffic for all routes starts dropping
      instantaneously on the Convergence Event Instant.  See discussion
      in [<a href="#ref-Po11m" title="&quot;Benchmarking Methodology for Link-State IGP Data-Plane Route Convergence&quot;">Po11m</a>].

      For the test cases described in [<a href="#ref-Po11m" title="&quot;Benchmarking Methodology for Link-State IGP Data-Plane Route Convergence&quot;">Po11m</a>], the Route Loss of
      Connectivity Period is expected to be a single Loss Period [<a href="#ref-Ko02" title="&quot;One-way Loss Pattern Sample Metrics&quot;">Ko02</a>].

      When benchmarking the Route Loss of Connectivity Period,
      Connectivity Packet Loss is measured for each route, and Equation
      8 is applied for each measured route entry.  The calculation is
      equal to Equation 4 in <a href="#section-3.6.3">Section 3.6.3</a>.

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

                                Equation 8

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



<span class="grey">Poretsky, et al.              Informational                    [Page 21]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-22" ></span>
<span class="grey"><a href="./rfc6412">RFC 6412</a>          IGP Convergence Benchmark Terminology    November 2011</span>


   Measurement Units:

      seconds (and fractions)

   See Also:

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

<span class="h4"><a class="selflink" id="section-3.6.6" href="#section-3.6.6">3.6.6</a>.  Loss-Derived Loss of Connectivity Period</span>

   Definition:

      The average time duration of packet impairments for all routes
      following a Convergence Event until Full Convergence completion,
      as observed using the Loss-Derived Method.

   Discussion:

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

      The Loss-Derived Loss of Connectivity Period may be equal to the
      Loss-Derived Convergence Time if, as a characteristic of the
      Convergence Event, traffic for all routes starts dropping
      instantaneously on the Convergence Event Instant.  See discussion
      in [<a href="#ref-Po11m" title="&quot;Benchmarking Methodology for Link-State IGP Data-Plane Route Convergence&quot;">Po11m</a>].

      For the test cases described in [<a href="#ref-Po11m" title="&quot;Benchmarking Methodology for Link-State IGP Data-Plane Route Convergence&quot;">Po11m</a>], each route's Route Loss
      of Connectivity Period is expected to be a single Loss Period
      [<a href="#ref-Ko02" title="&quot;One-way Loss Pattern Sample Metrics&quot;">Ko02</a>].

      When benchmarking the Loss-Derived Loss of Connectivity Period,
      Connectivity Packet Loss is measured for all routes, and Equation
      9 is applied.  The calculation is equal to Equation 6 in
      <a href="#section-3.6.4">Section 3.6.4</a>.

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

                                Equation 9





<span class="grey">Poretsky, et al.              Informational                    [Page 22]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-23" ></span>
<span class="grey"><a href="./rfc6412">RFC 6412</a>          IGP Convergence Benchmark Terminology    November 2011</span>


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

   Measurement Units:

      seconds (and fractions)

   See Also:

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

<span class="h3"><a class="selflink" id="section-3.7" href="#section-3.7">3.7</a>.  Measurement Terms</span>

<span class="h4"><a class="selflink" id="section-3.7.1" href="#section-3.7.1">3.7.1</a>.  Convergence Event</span>

   Definition:

      The occurrence of an event in the network that will result in a
      change in the egress interface of the DUT for routed packets.

   Discussion:

      All test cases in [<a href="#ref-Po11m" title="&quot;Benchmarking Methodology for Link-State IGP Data-Plane Route Convergence&quot;">Po11m</a>] are defined such that a Convergence
      Event results in a change of egress interface of the DUT.  Local
      or remote triggers that cause a route calculation that does not
      result in a change in forwarding are not considered.

   Measurement Units:

      N/A

   See Also:

      Convergence Event Instant

<span class="h4"><a class="selflink" id="section-3.7.2" href="#section-3.7.2">3.7.2</a>.  Convergence Packet Loss</span>

   Definition:

      The number of Impaired Packets (<a href="#section-3.8.1">Section 3.8.1</a>) as observed on the
      Next-Best Egress Interface of the DUT during convergence.

   Discussion:

      An Impaired Packet is considered as a lost packet.





<span class="grey">Poretsky, et al.              Informational                    [Page 23]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-24" ></span>
<span class="grey"><a href="./rfc6412">RFC 6412</a>          IGP Convergence Benchmark Terminology    November 2011</span>


   Measurement Units:

      number of packets

   See Also:

      Connectivity Packet Loss

<span class="h4"><a class="selflink" id="section-3.7.3" href="#section-3.7.3">3.7.3</a>.  Connectivity Packet Loss</span>

   Definition:

      The number of Impaired Packets observed on all DUT egress
      interfaces during convergence.

   Discussion:

      An Impaired Packet is considered as a lost packet.  Connectivity
      Packet Loss is equal to Convergence Packet Loss if the Convergence
      Event causes instantaneous traffic loss for all egress interfaces
      of the DUT except for the Next-Best Egress Interface.

   Measurement Units:

      number of packets

   See Also:

      Convergence Packet Loss

<span class="h4"><a class="selflink" id="section-3.7.4" href="#section-3.7.4">3.7.4</a>.  Packet Sampling Interval</span>

   Definition:

      The interval at which the Tester (test equipment) polls to make
      measurements for arriving packets.

   Discussion:

      At least one packet per route for all routes matched in the
      Offered Load MUST be offered to the DUT within the Packet Sampling
      Interval.  Metrics measured at the Packet Sampling Interval MUST
      include Forwarding Rate and received packets.

      Packet Sampling Interval can influence the 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 Convergence Event Instant and



<span class="grey">Poretsky, et al.              Informational                    [Page 24]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-25" ></span>
<span class="grey"><a href="./rfc6412">RFC 6412</a>          IGP Convergence Benchmark Terminology    November 2011</span>


      First Route Convergence Instant may not be easily identifiable,
      and the Rate-Derived Method may produce a larger than actual
      convergence time.

      Using a small Packet Sampling Interval in the presence of IPDV
      [<a href="#ref-De02" title="&quot;IP Packet Delay Variation Metric for IP Performance Metrics (IPPM)&quot;">De02</a>] may cause fluctuations of the Forwarding Rate observation
      and can prevent correct observation of the different convergence
      time instants.

      The value of the Packet Sampling Interval only contributes to the
      measurement accuracy of the Rate-Derived Method.  For maximum
      accuracy, the value for the Packet Sampling Interval SHOULD be as
      small as possible, but the presence of IPDV may enforce using a
      larger Packet Sampling Interval.

   Measurement Units:

      seconds (and fractions)

   See Also:

      Rate-Derived Method

<span class="h4"><a class="selflink" id="section-3.7.5" href="#section-3.7.5">3.7.5</a>.  Sustained Convergence Validation Time</span>

   Definition:

      The amount of time for which the completion of Full Convergence is
      maintained without additional Impaired Packets being observed.

   Discussion:

      The purpose of the Sustained Convergence Validation Time is to
      produce convergence benchmarks protected against fluctuation in
      Forwarding Rate after the completion of Full Convergence is
      observed.  The RECOMMENDED Sustained Convergence Validation Time
      to be used is the time to send 5 consecutive packets to each
      destination with a minimum of 5 seconds.  The Benchmarking
      Methodology Working Group (BMWG) selected 5 seconds based upon
      [<a href="#ref-Br99" title="&quot;Benchmarking Methodology for Network Interconnect Devices&quot;">Br99</a>], 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.

   Measurement Units:

      seconds (and fractions)





<span class="grey">Poretsky, et al.              Informational                    [Page 25]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-26" ></span>
<span class="grey"><a href="./rfc6412">RFC 6412</a>          IGP Convergence Benchmark Terminology    November 2011</span>


   See Also:

      Full Convergence, Convergence Recovery Instant

<span class="h4"><a class="selflink" id="section-3.7.6" href="#section-3.7.6">3.7.6</a>.  Forwarding Delay Threshold</span>

   Definition:

      The maximum waiting time threshold used to distinguish between
      packets with very long delay and lost packets that will never
      arrive.

   Discussion:

      Applying a Forwarding Delay Threshold allows packets with a too
      large Forwarding Delay to be considered lost, as is required for
      some applications (e.g. voice, video, etc.).  The Forwarding Delay
      Threshold is a parameter of the methodology, and it MUST be
      reported.  [<a href="#ref-Br99" title="&quot;Benchmarking Methodology for Network Interconnect Devices&quot;">Br99</a>] recommends waiting 2 seconds for residual frames
      to arrive.

   Measurement Units:

      seconds (and fractions)

   See Also:

      Convergence Packet Loss, Connectivity Packet Loss

<span class="h3"><a class="selflink" id="section-3.8" href="#section-3.8">3.8</a>.  Miscellaneous Terms</span>

<span class="h4"><a class="selflink" id="section-3.8.1" href="#section-3.8.1">3.8.1</a>.  Impaired Packet</span>

   Definition:

      A packet that experienced at least one of the following
      impairments: loss, excessive Forwarding Delay, corruption,
      duplication, reordering.

   Discussion:

      A lost packet, a packet with a Forwarding Delay exceeding the
      Forwarding Delay Threshold, a corrupted packet, a Duplicate Packet
      [<a href="#ref-Po06" title="&quot;Terminology for Benchmarking Network-layer Traffic Control Mechanisms&quot;">Po06</a>], and an Out-of-Order Packet [<a href="#ref-Po06" title="&quot;Terminology for Benchmarking Network-layer Traffic Control Mechanisms&quot;">Po06</a>] are Impaired Packets.

      Packet ordering is observed for each individual flow (see [<a href="#ref-Th00" title="&quot;Multipath Issues in Unicast and Multicast Next-Hop Selection&quot;">Th00</a>],
      Section 3) of the Offered Load.




<span class="grey">Poretsky, et al.              Informational                    [Page 26]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-27" ></span>
<span class="grey"><a href="./rfc6412">RFC 6412</a>          IGP Convergence Benchmark Terminology    November 2011</span>


   Measurement Units:

      N/A

   See Also:

      Forwarding Delay Threshold

<span class="h2"><a class="selflink" id="section-4" href="#section-4">4</a>.  Security Considerations</span>

   Benchmarking activities as described in this memo are limited to
   technology characterization using controlled stimuli in a laboratory
   environment, with dedicated address space and the constraints
   specified in the sections above.

   The benchmarking network topology will be an independent test setup
   and MUST NOT be connected to devices that may forward the test
   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.

<span class="h2"><a class="selflink" id="section-5" href="#section-5">5</a>.  Acknowledgements</span>

   Thanks to Sue Hares, Al Morton, Kevin Dubray, Ron Bonica, David Ward,
   Peter De Vriendt, Anuj Dewagan, Adrian Farrel, Stewart Bryant,
   Francis Dupont, and the Benchmarking Methodology Working Group for
   their contributions to this work.

<span class="h2"><a class="selflink" id="section-6" href="#section-6">6</a>.  Normative References</span>

   [<a id="ref-Br91">Br91</a>]   Bradner, S., "Benchmarking terminology for network
            interconnection devices", <a href="./rfc1242">RFC 1242</a>, July 1991.

   [<a id="ref-Br97">Br97</a>]   Bradner, S., "Key words for use in RFCs to Indicate
            Requirement Levels", <a href="https://www.rfc-editor.org/bcp/bcp14">BCP 14</a>, <a href="./rfc2119">RFC 2119</a>, March 1997.

   [<a id="ref-Br99">Br99</a>]   Bradner, S. and J. McQuaid, "Benchmarking Methodology for
            Network Interconnect Devices", <a href="./rfc2544">RFC 2544</a>, March 1999.

   [<a id="ref-Ca90">Ca90</a>]   Callon, R., "Use of OSI IS-IS for routing in TCP/IP and dual
            environments", <a href="./rfc1195">RFC 1195</a>, December 1990.



<span class="grey">Poretsky, et al.              Informational                    [Page 27]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-28" ></span>
<span class="grey"><a href="./rfc6412">RFC 6412</a>          IGP Convergence Benchmark Terminology    November 2011</span>


   [<a id="ref-Co08">Co08</a>]   Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF for
            IPv6", <a href="./rfc5340">RFC 5340</a>, July 2008.

   [<a id="ref-De02">De02</a>]   Demichelis, C. and P. Chimento, "IP Packet Delay Variation
            Metric for IP Performance Metrics (IPPM)", <a href="./rfc3393">RFC 3393</a>,
            November 2002.

   [<a id="ref-Ho08">Ho08</a>]   Hopps, C., "Routing IPv6 with IS-IS", <a href="./rfc5308">RFC 5308</a>,
            October 2008.

   [<a id="ref-Ko02">Ko02</a>]   Koodli, R. and R. Ravikanth, "One-way Loss Pattern Sample
            Metrics", <a href="./rfc3357">RFC 3357</a>, August 2002.

   [<a id="ref-Ma98">Ma98</a>]   Mandeville, R., "Benchmarking Terminology for LAN Switching
            Devices", <a href="./rfc2285">RFC 2285</a>, February 1998.

   [<a id="ref-Mo98">Mo98</a>]   Moy, J., "OSPF Version 2", STD 54, <a href="./rfc2328">RFC 2328</a>, April 1998.

   [<a id="ref-Po06">Po06</a>]   Poretsky, S., Perser, J., Erramilli, S., and S. Khurana,
            "Terminology for Benchmarking Network-layer Traffic Control
            Mechanisms", <a href="./rfc4689">RFC 4689</a>, October 2006.

   [<a id="ref-Po11m">Po11m</a>]  Poretsky, S., Imhoff, B., and K. Michielsen, "Benchmarking
            Methodology for Link-State IGP Data-Plane Route
            Convergence", <a href="./rfc6413">RFC 6413</a>, November 2011.

   [<a id="ref-Th00">Th00</a>]   Thaler, D. and C. Hopps, "Multipath Issues in Unicast and
            Multicast Next-Hop Selection", <a href="./rfc2991">RFC 2991</a>, November 2000.























<span class="grey">Poretsky, et al.              Informational                    [Page 28]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-29" ></span>
<span class="grey"><a href="./rfc6412">RFC 6412</a>          IGP Convergence Benchmark Terminology    November 2011</span>


Authors' Addresses

   Scott Poretsky
   Allot Communications
   300 TradeCenter
   Woburn, MA  01801
   USA

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


   Brent Imhoff
   F5 Networks
   401 Elliott Avenue West
   Seattle, WA  98119
   USA

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


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

   EMail: kmichiel@cisco.com






















Poretsky, et al.              Informational                    [Page 29]
</pre>