File: rfc6414.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 (1845 lines) | stat: -rw-r--r-- 73,096 bytes
parent folder | download | duplicates (2)
<pre>Internet Engineering Task Force (IETF)                       S. Poretsky
Request for Comments: 6414                          Allot Communications
Category: Informational                                       R. Papneja
ISSN: 2070-1721                                                   Huawei
                                                              J. Karthik
                                                             S. Vapiwala
                                                           Cisco Systems
                                                           November 2011


          <span class="h1">Benchmarking Terminology for Protection Performance</span>

Abstract

   This document provides common terminology and metrics for
   benchmarking the performance of sub-IP layer protection mechanisms.
   The performance benchmarks are measured at the IP layer; protection
   may be provided at the sub-IP layer.  The benchmarks and terminology
   can be applied in methodology documents for different sub-IP layer
   protection mechanisms such as Automatic Protection Switching (APS),
   Virtual Router Redundancy Protocol (VRRP), Stateful High Availability
   (HA), and Multiprotocol Label Switching Fast Reroute (MPLS-FRR).

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/rfc6414">http://www.rfc-editor.org/info/rfc6414</a>.













<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="./rfc6414">RFC 6414</a>            Benchmarking Terms for Protection      November 2011</span>


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
   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.

Table of Contents

   <a href="#section-1">1</a>. Introduction ....................................................<a href="#page-4">4</a>
      <a href="#section-1.1">1.1</a>. Scope ......................................................<a href="#page-4">4</a>
      <a href="#section-1.2">1.2</a>. General Model ..............................................<a href="#page-5">5</a>
   <a href="#section-2">2</a>. Existing Definitions ............................................<a href="#page-8">8</a>
   <a href="#section-3">3</a>. Test Considerations .............................................<a href="#page-9">9</a>
      <a href="#section-3.1">3.1</a>. Paths ......................................................<a href="#page-9">9</a>
           <a href="#section-3.1.1">3.1.1</a>. Path ................................................<a href="#page-9">9</a>
           <a href="#section-3.1.2">3.1.2</a>. Working Path .......................................<a href="#page-10">10</a>
           <a href="#section-3.1.3">3.1.3</a>. Primary Path .......................................<a href="#page-10">10</a>
           <a href="#section-3.1.4">3.1.4</a>. Protected Primary Path .............................<a href="#page-11">11</a>
           <a href="#section-3.1.5">3.1.5</a>. Backup Path ........................................<a href="#page-11">11</a>
           <a href="#section-3.1.6">3.1.6</a>. Standby Backup Path ................................<a href="#page-12">12</a>
           <a href="#section-3.1.7">3.1.7</a>. Dynamic Backup Path ................................<a href="#page-12">12</a>
           <a href="#section-3.1.8">3.1.8</a>. Disjoint Paths .....................................<a href="#page-13">13</a>
           <a href="#section-3.1.9">3.1.9</a>. Point of Local Repair (PLR) ........................<a href="#page-13">13</a>
           <a href="#section-3.1.10">3.1.10</a>. Shared Risk Link Group (SRLG) .....................<a href="#page-14">14</a>
      <a href="#section-3.2">3.2</a>. Protection ................................................<a href="#page-14">14</a>
           <a href="#section-3.2.1">3.2.1</a>. Link Protection ....................................<a href="#page-14">14</a>
           <a href="#section-3.2.2">3.2.2</a>. Node Protection ....................................<a href="#page-15">15</a>



<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="./rfc6414">RFC 6414</a>            Benchmarking Terms for Protection      November 2011</span>


           <a href="#section-3.2.3">3.2.3</a>. Path Protection ....................................<a href="#page-15">15</a>
           <a href="#section-3.2.4">3.2.4</a>. Backup Span ........................................<a href="#page-16">16</a>
           <a href="#section-3.2.5">3.2.5</a>. Local Link Protection ..............................<a href="#page-16">16</a>
           <a href="#section-3.2.6">3.2.6</a>. Redundant Node Protection ..........................<a href="#page-17">17</a>
           <a href="#section-3.2.7">3.2.7</a>. State Control Interface ............................<a href="#page-17">17</a>
           <a href="#section-3.2.8">3.2.8</a>. Protected Interface ................................<a href="#page-18">18</a>
      <a href="#section-3.3">3.3</a>. Protection Switching ......................................<a href="#page-18">18</a>
           <a href="#section-3.3.1">3.3.1</a>. Protection-Switching System ........................<a href="#page-18">18</a>
           <a href="#section-3.3.2">3.3.2</a>. Failover Event .....................................<a href="#page-19">19</a>
           <a href="#section-3.3.3">3.3.3</a>. Failure Detection ..................................<a href="#page-19">19</a>
           <a href="#section-3.3.4">3.3.4</a>. Failover ...........................................<a href="#page-20">20</a>
           <a href="#section-3.3.5">3.3.5</a>. Restoration ........................................<a href="#page-20">20</a>
           <a href="#section-3.3.6">3.3.6</a>. Reversion ..........................................<a href="#page-21">21</a>
      <a href="#section-3.4">3.4</a>. Nodes .....................................................<a href="#page-22">22</a>
           <a href="#section-3.4.1">3.4.1</a>. Protection-Switching Node ..........................<a href="#page-22">22</a>
           <a href="#section-3.4.2">3.4.2</a>. Non-Protection-Switching Node ......................<a href="#page-22">22</a>
           <a href="#section-3.4.3">3.4.3</a>. Headend Node .......................................<a href="#page-23">23</a>
           <a href="#section-3.4.4">3.4.4</a>. Backup Node ........................................<a href="#page-23">23</a>
           <a href="#section-3.4.5">3.4.5</a>. Merge Node .........................................<a href="#page-24">24</a>
           <a href="#section-3.4.6">3.4.6</a>. Primary Node .......................................<a href="#page-24">24</a>
           <a href="#section-3.4.7">3.4.7</a>. Standby Node .......................................<a href="#page-25">25</a>
      <a href="#section-3.5">3.5</a>. Benchmarks ................................................<a href="#page-26">26</a>
           <a href="#section-3.5.1">3.5.1</a>. Failover Packet Loss ...............................<a href="#page-26">26</a>
           <a href="#section-3.5.2">3.5.2</a>. Reversion Packet Loss ..............................<a href="#page-26">26</a>
           <a href="#section-3.5.3">3.5.3</a>. Failover Time ......................................<a href="#page-27">27</a>
           <a href="#section-3.5.4">3.5.4</a>. Reversion Time .....................................<a href="#page-27">27</a>
           <a href="#section-3.5.5">3.5.5</a>. Additive Backup Delay ..............................<a href="#page-28">28</a>
      <a href="#section-3.6">3.6</a>. Failover Time Calculation Methods .........................<a href="#page-28">28</a>
           <a href="#section-3.6.1">3.6.1</a>. Time-Based Loss Method (TBLM) ......................<a href="#page-29">29</a>
           <a href="#section-3.6.2">3.6.2</a>. Packet-Loss-Based Method (PLBM) ....................<a href="#page-29">29</a>
           <a href="#section-3.6.3">3.6.3</a>. Timestamp-Based Method (TBM) .......................<a href="#page-30">30</a>
   <a href="#section-4">4</a>. Security Considerations ........................................<a href="#page-31">31</a>
   <a href="#section-5">5</a>. References .....................................................<a href="#page-32">32</a>
      <a href="#section-5.1">5.1</a>. Normative References ......................................<a href="#page-32">32</a>
      <a href="#section-5.2">5.2</a>. Informative References ....................................<a href="#page-32">32</a>
   <a href="#section-6">6</a>. Acknowledgments ................................................<a href="#page-32">32</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="./rfc6414">RFC 6414</a>            Benchmarking Terms for Protection      November 2011</span>


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

   The IP network layer provides route convergence to protect data
   traffic against planned and unplanned failures in the Internet.  Fast
   convergence times are critical to maintain reliable network
   connectivity and performance.  Convergence Events [<a href="#ref-6" title="&quot;Terminology for Benchmarking Link-State IGP Data Plane Route Convergence&quot;">6</a>] are recognized
   at the IP Layer so that Route Convergence [<a href="#ref-6" title="&quot;Terminology for Benchmarking Link-State IGP Data Plane Route Convergence&quot;">6</a>] occurs.  Technologies
   that function at sub-IP layers can be enabled to provide further
   protection of IP traffic by providing the failure recovery at the
   sub-IP layers so that the outage is not observed at the IP layer.
   Such sub-IP protection technologies include, but are not limited to,
   High Availability (HA) stateful failover, Virtual Router Redundancy
   Protocol (VRRP) [<a href="#ref-8" title="&quot;Virtual Router Redundancy Protocol (VRRP) Version 3 for IPv4 and IPv6&quot;">8</a>], Automatic Link Protection (APS) for SONET/SDH,
   Resilient Packet Ring (RPR) for Ethernet, and Fast Reroute for
   Multiprotocol Label Switching (MPLS-FRR) [<a href="#ref-9" title="&quot;Fast Reroute Extensions to RSVP-TE for LSP Tunnels&quot;">9</a>].

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

   Benchmarking terminology was defined for IP-layer convergence in [<a href="#ref-6" title="&quot;Terminology for Benchmarking Link-State IGP Data Plane Route Convergence&quot;">6</a>].
   Different terminology and methodologies specific to benchmarking sub-
   IP layer protection mechanisms are required.  The metrics for
   benchmarking the performance of sub-IP protection mechanisms are
   measured at the IP layer, so that the results are always measured in
   reference to IP and independent of the specific protection mechanism
   being used.  The purpose of this document is to provide a single
   terminology for benchmarking sub-IP protection mechanisms.

   A common terminology for sub-IP layer protection mechanism
   benchmarking enables different implementations of a protection
   mechanism to be benchmarked and evaluated.  In addition,
   implementations of different protection mechanisms can be benchmarked
   and evaluated.  It is intended that there can exist unique
   methodology documents for each sub-IP protection mechanism based upon
   this common terminology document.  The terminology can be applied to
   methodologies that benchmark sub-IP protection mechanism performance
   with a single stream of traffic or multiple streams of traffic.  The
   traffic flow may be unidirectional or bidirectional as to be
   indicated in the methodology.













<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="./rfc6414">RFC 6414</a>            Benchmarking Terms for Protection      November 2011</span>


<span class="h3"><a class="selflink" id="section-1.2" href="#section-1.2">1.2</a>.  General Model</span>

   The sequence of events to benchmark the performance of sub-IP
   protection mechanisms is as follows:

   1. Failover Event - Primary Path fails
   2. Failure Detection - Failover Event is detected
   3. Failover - Backup Path becomes the Working Path due to Failover
      Event
   4. Restoration - Primary Path recovers from a Failover Event
   5. Reversion (optional) - Primary Path becomes the Working Path

   These terms are further defined in this document.

   Figures 1 through 5 show models that MAY be used when benchmarking
   sub-IP protection mechanisms, which MUST use a Protection-Switching
   System that consists of a minimum of two Protection-Switching Nodes,
   an Ingress Node known as the Headend Node and an Egress Node known as
   the Merge Node.  The Protection-Switching System MUST include either
   a Primary Path and Backup Path, as shown in Figures 1 through 4, or a
   Primary Node and Standby Node, as shown in Figure 5.  A Protection-
   Switching System may provide link protection, node protection, path
   protection, local link protection, and high availability, as shown in
   Figures 1 through 5, respectively.  A Failover Event occurs along the
   Primary Path or at the Primary Node.  The Working Path is the Primary
   Path prior to the Failover Event and the Backup Path after the
   Failover Event.  A Tester is set outside the two paths or nodes as it
   sends and receives IP traffic along the Working Path.  The tester
   MUST record the IP packet sequence numbers, departure time, and
   arrival time so that the metrics of Failover Time, Additive Latency,
   Packet Reordering, Duplicate Packets, and Reversion Time can be
   measured.  The Tester may be a single device or a test system.  If
   Reversion is supported, then the Working Path is the Primary Path
   after Restoration (Failure Recovery) of the Primary Path.

   Link Protection, as shown in Figure 1, provides protection when a
   Failover Event occurs on the link between two nodes along the Primary
   Path.  Node Protection, as shown in Figure 2, provides protection
   when a Failover Event occurs at a Node along the Primary Path.  Path
   Protection, as shown in Figure 3, provides protection for link or
   node failures for multiple hops along the Primary Path.  Local Link
   Protection, as shown in Figure 4, provides sub-IP protection of a
   link between two nodes, without a Backup Node.  An example of such a
   sub-IP protection mechanism is SONET APS.  High Availability
   Protection, as shown in Figure 5, provides protection of a Primary
   Node with a redundant Standby Node.  State Control is provided
   between the Primary and Standby Nodes.  Failure of the Primary Node




<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="./rfc6414">RFC 6414</a>            Benchmarking Terms for Protection      November 2011</span>


   is detected at the sub-IP layer to force traffic to switch to the
   Standby Node, which has state maintained for zero or minimal packet
   loss.

                      +-----------+
       +--------------|  Tester   |&lt;-----------------------+
       |              +-----------+                        |
       | IP Traffic        | Failover           IP Traffic |
       |                   |  Event                        |
       |     ------------  |                 ----------    |
       +---&gt;|  Ingress/  | V                | Egress/  |---+
            |Headend Node|------------------|Merge Node|  Primary
             ------------                    ----------    Path
                |                                ^
                |         ---------              |  Backup
                +--------| Backup  |-------------+   Path
                         |  Node   |
                          ---------

   Figure 1.  System Under Test (SUT) for Sub-IP Link Protection

                            +-----------+
       +--------------------|  Tester   |&lt;-----------------+
       |                    +-----------+                  |
       | IP Traffic               | Failover    IP Traffic |
       |                          | Event                  |
       |                          V                        |
       |     ------------      --------      ----------    |
       +---&gt;|  Ingress/  |    |Midpoint|    | Egress/  |---+
            |Headend Node|----|  Node  |----|Merge Node|  Primary
             ------------      --------      ----------    Path
                |                                ^
                |         ---------              |  Backup
                +--------| Backup  |-------------+   Path
                         |  Node   |
                          ---------

   Figure 2.  System Under Test (SUT) for Sub-IP Node Protection













<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="./rfc6414">RFC 6414</a>            Benchmarking Terms for Protection      November 2011</span>


                                +-----------+
    +---------------------------|  Tester   |&lt;----------------------+
    |                           +-----------+                       |
    | IP Traffic                      | Failover         IP Traffic |
    |                                 | Event                       |
    |                Primary Path     |                             |
    |     ------------      --------  |  --------     ----------    |
    +---&gt;|  Ingress/  |    |Midpoint| V |Midpoint|   | Egress/  |---+
         |Headend Node|----|  Node  |---|  Node  |---|Merge Node|
          ------------      --------     --------     ----------
                |                                         ^
                |         ---------      --------         | Backup
                +--------| Backup  |----| Backup |--------+  Path
                         |  Node   |    |  Node  |
                          ---------      --------

   Figure 3.  System Under Test (SUT) for Sub-IP Path Protection

                                  +-----------+
             +--------------------|  Tester   |&lt;-------------------+
             |                    +-----------+                    |
             | IP Traffic               | Failover      IP Traffic |
             |                          | Event                    |
             |              Primary     |                          |
             |    +--------+  Path      v            +--------+    |
             |    |        |------------------------&gt;|        |    |
             +---&gt;| Ingress|                         | Egress |----+
                  |  Node  |- - - - - - - - - - - - &gt;|  Node  |
                  +--------+      Backup Path        +--------+
                  |                                           |
                  |            IP-Layer Forwarding            |
                  +&lt;-----------------------------------------&gt;+

   Figure 4.  System Under Test (SUT) for Sub-IP Local Link Protection

















<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="./rfc6414">RFC 6414</a>            Benchmarking Terms for Protection      November 2011</span>


                            +-----------+
          +-----------------|  Tester   |&lt;--------------------+
          |                 +-----------+                     |
          | IP Traffic            | Failover       IP Traffic |
          |                       | Event                     |
          |                       V                           |
          |     ---------      --------      ----------       |
          +---&gt;| Ingress |    |Primary |    | Egress/  |------+
               |   Node  |----|  Node  |----|Merge Node|  Primary
                ---------      --------      ----------    Path
                   |        State |Control       ^
                   |    Interface |(Optional)    |
                   |          ---------          |
                   +---------| Standby |---------+
                             |  Node   |
                              ---------

                 Figure 5.  System Under Test (SUT)
                for Sub-IP Redundant Node Protection

   Some protection-switching technologies may use a series of steps that
   differ from the general model.  The specific differences SHOULD be
   highlighted in each technology-specific methodology.  Note that some
   protection-switching technologies are endowed with the ability to re-
   optimize the working path after a node or link failure.

<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 BMWG work.
   Examples include, but are not limited to:

      Latency                   [<a href="#ref-2" title="&quot;Benchmarking Terminology for Network Interconnection Devices&quot;">2</a>], Section 3.8
      Frame Loss Rate           [<a href="#ref-2" title="&quot;Benchmarking Terminology for Network Interconnection Devices&quot;">2</a>], Section 3.6
      Throughput                [<a href="#ref-2" title="&quot;Benchmarking Terminology for Network Interconnection Devices&quot;">2</a>], Section 3.17
      Device Under Test (DUT)   [<a href="#ref-3" title="&quot;Benchmarking Terminology for LAN Switching Devices&quot;">3</a>], Section 3.1.1
      System Under Test (SUT)   [<a href="#ref-3" title="&quot;Benchmarking Terminology for LAN Switching Devices&quot;">3</a>], Section 3.1.2
      Offered Load              [<a href="#ref-3" title="&quot;Benchmarking Terminology for LAN Switching Devices&quot;">3</a>], Section 3.5.2
      Out-of-order Packet       [<a href="#ref-4" title="&quot;Terminology for Benchmarking Network-layer Traffic Control Mechanisms&quot;">4</a>], Section 3.3.4
      Duplicate Packet          [<a href="#ref-4" title="&quot;Terminology for Benchmarking Network-layer Traffic Control Mechanisms&quot;">4</a>], Section 3.3.5
      Forwarding Delay          [<a href="#ref-4" title="&quot;Terminology for Benchmarking Network-layer Traffic Control Mechanisms&quot;">4</a>], Section 3.2.4
      Jitter                    [<a href="#ref-4" title="&quot;Terminology for Benchmarking Network-layer Traffic Control Mechanisms&quot;">4</a>], Section 3.2.5
      Packet Loss               [<a href="#ref-6" title="&quot;Terminology for Benchmarking Link-State IGP Data Plane Route Convergence&quot;">6</a>], Section 3.5
      Packet Reordering         [<a href="#ref-7" title="&quot;Packet Reordering Metrics&quot;">7</a>], Section 3.3

   This document has the following frequently used acronyms:

      DUT  Device Under Test
      SUT  System Under Test



<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="./rfc6414">RFC 6414</a>            Benchmarking Terms for Protection      November 2011</span>


   This document adopts the definition format in <a href="./rfc1242#section-2">Section&nbsp;2 of RFC 1242</a>
   [<a href="#ref-2" title="&quot;Benchmarking Terminology for Network Interconnection Devices&quot;">2</a>].  Terms defined in this document are capitalized when used within
   this document.

   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-5" title="&quot;Key words for use in RFCs to Indicate Requirement Levels&quot;">5</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="h2"><a class="selflink" id="section-3" href="#section-3">3</a>.  Test Considerations</span>

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

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

   Definition:
      A unidirectional sequence of nodes &lt;R1, ..., Rn&gt; and links
      &lt;L12,... L(n-1)n&gt; with the following properties:

      a. R1 is the ingress node and forwards IP packets, which input
         into DUT/SUT, to R2 as sub-IP frames over link L12.

      b. Ri is a node which forwards data frames to R(i+1) over Link
         Li(i+1) for all i, 1&lt;i&lt;n-1, based on information in the sub-IP
         layer.

      c. Rn is the egress node, and it outputs sub-IP frames from
         DUT/SUT as IP packets.  L(n-1)n is the link between the R(n-1)
         and Rn.

   Discussion:
      The path is defined in the sub-IP layer in this document, unlike
      an IP path in <a href="./rfc2026">RFC 2026</a> [<a href="#ref-1" title="&quot;The Internet Standards Process -- Revision 3&quot;">1</a>].  One path may be regarded as being
      equivalent to one IP link between two IP nodes, i.e., R1 and Rn.
      The two IP nodes may have multiple paths for protection.  A packet
      will travel on only one path between the nodes.  Packets belonging
      to a microflow [<a href="#ref-10" title="&quot;Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers&quot;">10</a>] will traverse one or more paths.  The path is
      unidirectional.  For example, the link between R1 and R2 in the
      direction from R1 to R2 is L12.  For traffic flowing in the
      reverse direction from R2 to R1, the link is L21.  Example paths
      are the SONET/SDH path and the label switched path for MPLS.

   Measurement Units:
      n/a





<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="./rfc6414">RFC 6414</a>            Benchmarking Terms for Protection      November 2011</span>


   Issues:
      "A bidirectional path", which transmits traffic in both directions
      along the same nodes, consists of two unidirectional paths.
      Therefore, the two unidirectional paths belonging to "one
      bidirectional path" will be treated independently when
      benchmarking for "a bidirectional path".

   See Also:
      Working Path
      Primary Path
      Backup Path

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

   Definition:
      The path that the DUT/SUT is currently using to forward packets.

   Discussion:
      A Primary Path is the Working Path before occurrence of a Failover
      Event.  A Backup Path shall become the Working Path after a
      Failover Event.

   Measurement Units:
      n/a

   Issues:
      None.

   See Also:
      Path
      Primary Path
      Backup Path

<span class="h4"><a class="selflink" id="section-3.1.3" href="#section-3.1.3">3.1.3</a>.  Primary Path</span>

   Definition:
      The preferred point-to-point path for forwarding traffic between
      two or more nodes.

   Discussion:
      The Primary Path is the Path that traffic traverses prior to a
      Failover Event.

   Measurement Units:
      n/a

   Issues:
      None.



<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="./rfc6414">RFC 6414</a>            Benchmarking Terms for Protection      November 2011</span>


   See Also:
      Path
      Failover Event

<span class="h4"><a class="selflink" id="section-3.1.4" href="#section-3.1.4">3.1.4</a>.  Protected Primary Path</span>

   Definition:
      A Primary Path that is protected with a Backup Path.

   Discussion:
      A Protected Primary Path must include at least one Protection-
      Switching Node.

   Measurement Units:
      n/a

   Issues:
      None.

   See Also:
      Path
      Primary Path

<span class="h4"><a class="selflink" id="section-3.1.5" href="#section-3.1.5">3.1.5</a>.  Backup Path</span>

   Definition:
      A path that exists to carry data traffic only if a Failover Event
      occurs on a Primary Path.

   Discussion:
      The Backup Path shall become the Working Path upon a Failover
      Event.  A Path may have one or more Backup Paths.  A Backup Path
      may protect one or more Primary Paths.  There are various types of
      Backup Paths:

      a. dedicated recovery Backup Path (1+1) or (1:1), which has 100%
         redundancy for a specific ordinary path

      b. shared Backup Path (1:N), which is dedicated to the protection
         for more than one specific Primary Path

      c. associated shared Backup Path (M:N) for which a specific set of
         Backup Paths protects a specific set of more than one Primary
         Path







<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="./rfc6414">RFC 6414</a>            Benchmarking Terms for Protection      November 2011</span>


      A Backup Path may be signaled or unsignaled.  The Backup Path must
      be created prior to the Failover Event.  The Backup Path generally
      originates at the point of local repair (PLR) and terminates at a
      node along a primary path.

   Measurement Units:
      n/a

   Issues:
      None.

   See Also:
      Path
      Working Path
      Primary Path

<span class="h4"><a class="selflink" id="section-3.1.6" href="#section-3.1.6">3.1.6</a>.  Standby Backup Path</span>

   Definition:
      A Backup Path that is established prior to a Failover Event to
      protect a Primary Path.

   Discussion:
      The Standby Backup Path and Dynamic Backup Path provide
      protection, but are established at different times.

   Measurement Units:
      n/a

   Issues:
      None.

   See Also:
      Backup Path
      Primary Path
      Failover Event

<span class="h4"><a class="selflink" id="section-3.1.7" href="#section-3.1.7">3.1.7</a>.  Dynamic Backup Path</span>

   Definition:
      A Backup Path that is established upon occurrence of a Failover
      Event.

   Discussion:
      The Standby Backup Path and Dynamic Backup Path provide
      protection, but are established at different times.





<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="./rfc6414">RFC 6414</a>            Benchmarking Terms for Protection      November 2011</span>


   Measurement Units:
      n/a

   Issues:
      None.

   See Also:
      Backup Path
      Standby Backup Path
      Failover Event

<span class="h4"><a class="selflink" id="section-3.1.8" href="#section-3.1.8">3.1.8</a>.  Disjoint Paths</span>

   Definition:
      A pair of paths that do not share a common link or nodes.

   Discussion:
      Two paths are disjoint if they do not share a common node or link
      other than the ingress and egress.

   Measurement Units:
      n/a

   Issues:
      None.

   See Also:
      Path
      Primary Path
      SRLG

<span class="h4"><a class="selflink" id="section-3.1.9" href="#section-3.1.9">3.1.9</a>.  Point of Local Repair (PLR)</span>

   Definition:
      A node capable of Failover along the Primary Path that is also the
      ingress node for the Backup Path to protect another node or link.

   Discussion:
      Any node along the Primary Path from the ingress node to the
      penultimate node may be a PLR.  The PLR may use a single Backup
      Path for protecting one or more Primary Paths.  There can be
      multiple PLRs along a Primary Path.  The PLR must be an ingress to
      a Backup Path.  The PLR can be any node along the Primary Path
      except the egress node of the Primary Path.  The PLR may
      simultaneously be a Headend Node when it is serving the role as
      ingress to the Primary Path and the Backup Path.  If the PLR is
      also the Headend Node, then the Backup Path is a Disjoint Path
      from the ingress to the Merge Node.



<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="./rfc6414">RFC 6414</a>            Benchmarking Terms for Protection      November 2011</span>


   Measurement Units:
      n/a

   Issues:
      None.

   See Also:
      Primary Path
      Backup Path
      Failover

<span class="h4"><a class="selflink" id="section-3.1.10" href="#section-3.1.10">3.1.10</a>.  Shared Risk Link Group (SRLG)</span>

   Definition:
      SRLG is a set of links that share the same risk (physical or
      logical) within a network.

   Discussion:
      SRLG is considered the set of links to be avoided when the primary
      and secondary paths are considered disjoint.  The SRLG will fail
      as a group if the shared resource (physical or anything abstract
      such as software version) fails.

   Measurement Units:
      n/a

   Issues:
      None.

   See Also:
      Path Primary Path

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

<span class="h4"><a class="selflink" id="section-3.2.1" href="#section-3.2.1">3.2.1</a>.  Link Protection</span>

   Definition:
      A Backup Path that is signaled to at least one Backup Node to
      protect for failure of interfaces and links along a Primary Path.

   Discussion:
      Link Protection may or may not protect the entire Primary Path.
      Link Protection is shown in Figure 1.

   Measurement Units:
      n/a





<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="./rfc6414">RFC 6414</a>            Benchmarking Terms for Protection      November 2011</span>


   Issues:
      None.

   See Also:
      Primary Path Backup Path

<span class="h4"><a class="selflink" id="section-3.2.2" href="#section-3.2.2">3.2.2</a>.  Node Protection</span>

   Definition:
      A Backup Path that is signaled to at least one Backup Node to
      protect for failure of interfaces, links, and nodes along a
      Primary Path.

   Discussion:
      Node Protection may or may not protect the entire Primary Path.
      Node Protection also provides Link Protection.  Node Protection is
      shown in Figure 2.

   Measurement Units:
      n/a

   Issues:
      None.

   See Also:
      Link Protection

<span class="h4"><a class="selflink" id="section-3.2.3" href="#section-3.2.3">3.2.3</a>.  Path Protection</span>

   Definition:
      A Backup Path that is signaled to at least one Backup Node to
      provide protection along the entire Primary Path.

   Discussion:
      Path Protection provides Node Protection and Link Protection for
      every node and link along the Primary Path.  A Backup Path
      providing Path Protection may have the same ingress node as the
      Primary Path.  Path Protection is shown in Figure 3.

   Measurement Units:
      n/a

   Issues:
      None.







<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="./rfc6414">RFC 6414</a>            Benchmarking Terms for Protection      November 2011</span>


   See Also:
      Primary Path
      Backup Path
      Node Protection
      Link Protection

<span class="h4"><a class="selflink" id="section-3.2.4" href="#section-3.2.4">3.2.4</a>.  Backup Span</span>

   Definition:
      The number of hops used by a Backup Path.

   Discussion:
      The Backup Span is an integer obtained by counting the number of
      nodes along the Backup Path.

   Measurement Units:
      number of nodes

   Issues:
      None.

   See Also:
      Primary Path
      Backup Path

<span class="h4"><a class="selflink" id="section-3.2.5" href="#section-3.2.5">3.2.5</a>.  Local Link Protection</span>

   Definition:
      A Backup Path that is a redundant path between two nodes and does
      not use a Backup Node.

   Discussion:
      Local Link Protection must be provided as a Backup Path between
      two nodes along the Primary Path without the use of a Backup Node.
      Local Link Protection is provided by Protection-Switching Systems
      such as SONET APS.  Local Link Protection is shown in Figure 4.

   Measurement Units:
      n/a

   Issues:
      None.

   See Also:
      Backup Path
      Backup Node





<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="./rfc6414">RFC 6414</a>            Benchmarking Terms for Protection      November 2011</span>


<span class="h4"><a class="selflink" id="section-3.2.6" href="#section-3.2.6">3.2.6</a>.  Redundant Node Protection</span>

   Definition:
      A Protection-Switching System with a Primary Node protected by a
      Standby Node along the Primary Path.

   Discussion:
      Redundant Node Protection is provided by Protection-Switching
      Systems such as VRRP and HA.  The protection mechanisms occur at
      sub-IP layers to switch traffic from a Primary Node to Backup Node
      upon a Failover Event at the Primary Node.  Traffic continues to
      traverse the Primary Path through the Standby Node.  The failover
      may be stateful, in which the state information may be exchanged
      in-band or over an out-of-band State Control Interface.  The
      Standby Node may be active or passive.  Redundant Node Protection
      is shown in Figure 5.

   Measurement Units:
      n/a

   Issues:
      None.

   See Also:
      Primary Path
      Primary Node
      Standby Node

<span class="h4"><a class="selflink" id="section-3.2.7" href="#section-3.2.7">3.2.7</a>.  State Control Interface</span>

   Definition:
      An out-of-band control interface used to exchange state
      information between the Primary Node and Standby Node.

   Discussion:
      The State Control Interface may be used for Redundant Node
      Protection.  The State Control Interface should be out-of-band.
      It is possible to have Redundant Node Protection in which there is
      no state control or state control is provided in-band.  The State
      Control Interface between the Primary and Standby Node may be one
      or more hops.

   Measurement Units:
      n/a

   Issues:
      None.




<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="./rfc6414">RFC 6414</a>            Benchmarking Terms for Protection      November 2011</span>


   See Also:
      Primary Node
      Standby Node

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

   Definition:
      An interface along the Primary Path that is protected by a Backup
      Path.

   Discussion:
      A Protected Interface is an interface protected by a Protection-
      Switching System that provides Link Protection, Node Protection,
      Path Protection, Local Link Protection, and Redundant Node
      Protection.

   Measurement Units:
      n/a

   Issues:
      None.

   See Also:
      Primary Path
      Backup Path

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

<span class="h4"><a class="selflink" id="section-3.3.1" href="#section-3.3.1">3.3.1</a>.  Protection-Switching System</span>

   Definition:
      A DUT/SUT that is capable of Failure Detection and Failover from a
      Primary Path to a Backup Path or Standby Node when a Failover
      Event occurs.

   Discussion:
      The Protection-Switching System must include either a Primary Path
      and Backup Path, as shown in Figures 1 through 4, or a Primary
      Node and Standby Node, as shown in Figure 5.  The Backup Path may
      be a Standby Backup Path or a Dynamic Backup Path.  The
      Protection-Switching System includes the mechanisms for both
      Failure Detection and Failover.

   Measurement Units:
      n/a

   Issues:
      None.



<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="./rfc6414">RFC 6414</a>            Benchmarking Terms for Protection      November 2011</span>


   See Also:
      Primary Path Backup Path Failover

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

   Definition:
      The occurrence of a planned or unplanned action in the network
      that results in a change in the Path that data traffic traverses.

   Discussion:
      Failover Events include, but are not limited to, link failure and
      router failure.  Routing changes are considered Convergence Events
      [<a href="#ref-6" title="&quot;Terminology for Benchmarking Link-State IGP Data Plane Route Convergence&quot;">6</a>] and are not Failover Events.  This restricts Failover Events
      to sub-IP layers.  Failover may be at the PLR or at the ingress.
      If the failover is at the ingress, it is generally on a disjoint
      path from the ingress to egress.

      Failover Events may result from failures such as link failure or
      router failure.  The change in path after Failover may have a
      Backup Span of one or more nodes.  Failover Events are
      distinguished from routing changes and Convergence Events [<a href="#ref-6" title="&quot;Terminology for Benchmarking Link-State IGP Data Plane Route Convergence&quot;">6</a>] by
      the detection of the failure and subsequent protection switching
      at a sub-IP layer.  Failover occurs at a PLR or Primary Node.

   Measurement Units:
      n/a

   Issues:
      None.

   See Also:
      Path
      Failure Detection
      Disjoint Path

<span class="h4"><a class="selflink" id="section-3.3.3" href="#section-3.3.3">3.3.3</a>.  Failure Detection</span>

   Definition:
      The process to identify at a sub-IP layer a Failover Event at a
      Primary Node or along the Primary Path.

   Discussion:
      Failure Detection occurs at the Primary Node or ingress node of
      the Primary Path.  Failure Detection occurs via a sub-IP mechanism
      such as detection of a link down event or timeout for receipt of a
      control packet.  A failure may be completely isolated.  A failure





<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="./rfc6414">RFC 6414</a>            Benchmarking Terms for Protection      November 2011</span>


      may affect a set of links that share a single SRLG (e.g., port
      with many sub-interfaces).  A failure may affect multiple links
      that are not part of the SRLG.

   Measurement Units:
      n/a

   Issues:
      None.

   See Also:
      Primary Path

<span class="h4"><a class="selflink" id="section-3.3.4" href="#section-3.3.4">3.3.4</a>.  Failover</span>

   Definition:
      The process to switch data traffic from the protected Primary Path
      to the Backup Path upon Failure Detection of a Failover Event.

   Discussion:
      Failover to a Backup Path provides Link Protection, Node
      Protection, or Path Protection.  Failover is complete when Packet
      Loss [<a href="#ref-6" title="&quot;Terminology for Benchmarking Link-State IGP Data Plane Route Convergence&quot;">6</a>], Out-of-order Packets [<a href="#ref-4" title="&quot;Terminology for Benchmarking Network-layer Traffic Control Mechanisms&quot;">4</a>], and Duplicate Packets [<a href="#ref-4" title="&quot;Terminology for Benchmarking Network-layer Traffic Control Mechanisms&quot;">4</a>] are
      no longer observed.  Forwarding Delay [<a href="#ref-4" title="&quot;Terminology for Benchmarking Network-layer Traffic Control Mechanisms&quot;">4</a>] may continue to be
      observed.

   Measurement Units:
      n/a

   Issues:
      None.

   See Also:
      Primary Path Backup Path Failover Event

<span class="h4"><a class="selflink" id="section-3.3.5" href="#section-3.3.5">3.3.5</a>.  Restoration</span>

   Definition:
      The state of failover recovery in which the Primary Path has
      recovered from a Failover Event, but is not yet forwarding packets
      because the Backup Path remains the Working Path.

   Discussion:
      Restoration must occur while the Backup Path is the Working Path.
      The Backup Path is maintained as the Working Path during
      Restoration.  Restoration produces a Primary Path that is





<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="./rfc6414">RFC 6414</a>            Benchmarking Terms for Protection      November 2011</span>


      recovered from failure, but is not yet forwarding traffic.
      Traffic is still being forwarded by the Backup Path functioning as
      the Working Path.

   Measurement Units:
      n/a

   Issues:
      None.

   See Also:
      Primary Path
      Failover Event
      Failure Recovery
      Working Path
      Backup Path

<span class="h4"><a class="selflink" id="section-3.3.6" href="#section-3.3.6">3.3.6</a>.  Reversion</span>

   Definition:
      The state of failover recovery in which the Primary Path has
      become the Working Path so that it is forwarding packets.

   Discussion:
      Protection-Switching Systems may or may not support Reversion.
      Reversion, if supported, must occur after Restoration.  Packet
      forwarding on the Primary Path resulting from Reversion may occur
      either fully or partially over the Primary Path.  A potential
      problem with Reversion is the discontinuity in end-to-end delay
      when the Forwarding Delays [<a href="#ref-4" title="&quot;Terminology for Benchmarking Network-layer Traffic Control Mechanisms&quot;">4</a>] along the Primary Path and Backup
      Path are different, possibly causing Out-of-order Packets [<a href="#ref-4" title="&quot;Terminology for Benchmarking Network-layer Traffic Control Mechanisms&quot;">4</a>],
      Duplicate Packets [<a href="#ref-4" title="&quot;Terminology for Benchmarking Network-layer Traffic Control Mechanisms&quot;">4</a>], and increased Jitter [<a href="#ref-4" title="&quot;Terminology for Benchmarking Network-layer Traffic Control Mechanisms&quot;">4</a>].

   Measurement Units:
      n/a

   Issues:
      None.

   See Also:
      Protection-Switching System
      Working Path
      Primary Path








<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="./rfc6414">RFC 6414</a>            Benchmarking Terms for Protection      November 2011</span>


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

<span class="h4"><a class="selflink" id="section-3.4.1" href="#section-3.4.1">3.4.1</a>.  Protection-Switching Node</span>

   Definition:
      A node that is capable of participating in a Protection Switching
      System.

   Discussion:
      The Protection-Switching Node may be an ingress or egress for a
      Primary Path or Backup Path, such as used for MPLS Fast Reroute
      configurations.  The Protection-Switching Node may provide
      Redundant Node Protection as a Primary Node in a Redundant chassis
      configuration with a Standby Node, such as used for VRRP and HA
      configurations.

   Measurement Units:
      n/a

   Issues:
      None.

   See Also:
      Protection-Switching System

<span class="h4"><a class="selflink" id="section-3.4.2" href="#section-3.4.2">3.4.2</a>.  Non-Protection-Switching Node</span>

   Definition:
      A node that is not capable of participating in a Protection
      Switching System, but may exist along the Primary Path or Backup
      Path.

   Discussion:
      None.

   Measurement Units:
      n/a

   Issues:
      None.

   See Also:
      Protection-Switching System
      Primary Path
      Backup Path






<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="./rfc6414">RFC 6414</a>            Benchmarking Terms for Protection      November 2011</span>


<span class="h4"><a class="selflink" id="section-3.4.3" href="#section-3.4.3">3.4.3</a>.  Headend Node</span>

   Definition:
      The ingress node of the Primary Path.

   Discussion:
      The Headend Node may also be a PLR when it is serving in the dual
      role as the ingress to the Backup Path.

   Measurement Units:
      n/a

   Issues:
      None.

   See Also:
      Primary Path
      PLR
      Failover

<span class="h4"><a class="selflink" id="section-3.4.4" href="#section-3.4.4">3.4.4</a>.  Backup Node</span>

   Definition:
      A node along the Backup Path.

   Discussion:
      The Backup Node can be any node along the Backup Path.  There may
      be one or more Backup Nodes along the Backup Path.  A Backup Node
      may be the ingress, midpoint, or egress of the Backup Path.  If
      the Backup Path has only one Backup Node, then that Backup Node is
      the ingress and egress of the Backup Path.

   Measurement Units:
      n/a

   Issues:
      None.

   See Also:
      Backup Path











<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="./rfc6414">RFC 6414</a>            Benchmarking Terms for Protection      November 2011</span>


<span class="h4"><a class="selflink" id="section-3.4.5" href="#section-3.4.5">3.4.5</a>.  Merge Node</span>

   Definition:
      A node along the Primary Path where Backup Path terminates.

   Discussion:
      The Merge Node can be any node along the Primary Path except the
      ingress node of the Primary Path.  There can be multiple Merge
      Nodes along a Primary Path.  A Merge Node can be the egress node
      for a single Backup Path or multiple Backup Paths.  The Merge Node
      must be the egress to the Backup Path.  The Merge Node may also be
      the egress of the Primary Path or Point of Local Repair (PLR).

   Measurement Units:
      n/a

   Issues:
      None.

   See Also:
      Primary Path
      Backup Path
      PLR
      Failover

<span class="h4"><a class="selflink" id="section-3.4.6" href="#section-3.4.6">3.4.6</a>.  Primary Node</span>

   Definition:
      A node along the Primary Path that is capable of Failover to a
      redundant Standby Node.

   Discussion:
      The Primary Node may be used for Protection-Switching Systems that
      provide Redundant Node Protection, such as VRRP and HA.

   Measurement Units:
      n/a

   Issues:
      None.

   See Also:
      Protection-Switching System Redundant Node Protection Standby Node








<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="./rfc6414">RFC 6414</a>            Benchmarking Terms for Protection      November 2011</span>


<span class="h4"><a class="selflink" id="section-3.4.7" href="#section-3.4.7">3.4.7</a>.  Standby Node</span>

   Definition:
      A redundant node to a Primary Node; it forwards traffic along the
      Primary Path upon Failure Detection of the Primary Node.

   Discussion:
      The Standby Node must be used for Protection-Switching Systems
      that provide Redundant Node Protection, such as VRRP and HA.  The
      Standby Node must provide protection along the same Primary Path.
      If the failover is to a Disjoint Path, then it is a Backup Node.
      The Standby Node may be configured for 1:1 or N:1 protection.

      The communication between the Primary Node and Standby Node may be
      in-band or across an out-of-band State Control Interface.  The
      Standby Node may be geographically dispersed from the Primary
      Node.  When geographically dispersed, the number of hops of
      separation may increase failover time.

      The Standby Node may be passive or active.  The Passive Standby
      Node is not offered traffic and does not forward traffic until
      Failure Detection of the Primary Node.  Upon Failure Detection of
      the Primary Node, traffic offered to the Primary Node is instead
      offered to the Passive Standby Node.  The Active Standby Node is
      offered traffic and forwards traffic along the Primary Path while
      the Primary Node is also active.  Upon Failure Detection of the
      Primary Node, traffic offered to the Primary Node is switched to
      the Active Standby Node.

   Measurement Units:
      n/a

   Issues:
      None.

   See Also:
      Primary Node
      State Control Interface













<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="./rfc6414">RFC 6414</a>            Benchmarking Terms for Protection      November 2011</span>


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

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

   Definition:
      The amount of packet loss produced by a Failover Event until
      Failover completes, where the measurement begins when the last
      unimpaired packet is received by the Tester on the Protected
      Primary Path and ends when the first unimpaired packet is received
      by the Tester on the Backup Path.

   Discussion:
      Packet loss can be observed as a reduction of forwarded traffic
      from the maximum forwarding rate.  Failover Packet Loss includes
      packets that were lost, reordered, or delayed.  Failover Packet
      Loss may reach 100% of the offered load.

   Measurement Units:
      Number of Packets

   Issues:
      None.

   See Also:
      Failover Event
      Failover

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

   Definition:
      The amount of packet loss produced by Reversion, where the
      measurement begins when the last unimpaired packet is received by
      the Tester on the Backup Path and ends when the first unimpaired
      packet is received by the Tester on the Protected Primary Path.

   Discussion:
      Packet loss can be observed as a reduction of forwarded traffic
      from the maximum forwarding rate.  Reversion Packet Loss includes
      packets that were lost, reordered, or delayed.  Reversion Packet
      Loss may reach 100% of the offered load.

   Measurement Units:
      Number of Packets

   Issues:
      None.





<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="./rfc6414">RFC 6414</a>            Benchmarking Terms for Protection      November 2011</span>


   See Also:
      Reversion

<span class="h4"><a class="selflink" id="section-3.5.3" href="#section-3.5.3">3.5.3</a>.  Failover Time</span>

   Definition:
      The amount of time it takes for Failover to successfully complete.

   Discussion:
      Failover Time can be calculated using the Time-Based Loss Method
      (TBLM), Packet-Loss-Based Method (PLBM), or Timestamp-Based Method
      (TBM).  It is RECOMMENDED that the TBM is used.

   Measurement Units:
      milliseconds

   Issues:
      None.

   See Also:
      Failover
      Failover Time
      Time-Based Loss Method (TBLM)
      Packet-Loss-Based Method (PLBM)
      Timestamp-Based Method (TBM)

<span class="h4"><a class="selflink" id="section-3.5.4" href="#section-3.5.4">3.5.4</a>.  Reversion Time</span>

   Definition:
      The amount of time it takes for Reversion to complete so that the
      Primary Path is restored as the Working Path.

   Discussion:
      Reversion Time can be calculated using the Time-Based Loss Method
      (TBLM), Packet-Loss-Based Method (PLBM), or Timestamp-Based Method
      (TBM).  It is RECOMMENDED that the TBM is used.

   Measurement Units:
      milliseconds

   Issues:
      None.

   See Also:
      Reversion
      Primary Path
      Working Path
      Reversion Packet Loss



<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="./rfc6414">RFC 6414</a>            Benchmarking Terms for Protection      November 2011</span>


      Time-Based Loss Method (TBLM)
      Packet-Loss-Based Method (PLBM)
      Timestamp-Based Method (TBM)

<span class="h4"><a class="selflink" id="section-3.5.5" href="#section-3.5.5">3.5.5</a>.  Additive Backup Delay</span>

   Definition:
      The amount of increased Forwarding Delay [<a href="#ref-4" title="&quot;Terminology for Benchmarking Network-layer Traffic Control Mechanisms&quot;">4</a>] resulting from data
      traffic traversing the Backup Path instead of the Primary Path.

   Discussion:
      Additive Backup Delay is calculated using Equation 1 as shown
      below:

      (Equation 1)
      Additive Backup Delay =
                Forwarding Delay(Backup Path) -
                Forwarding Delay(Primary Path)

   Measurement Units:
      milliseconds

   Issues:
      Additive Backup Latency may be a negative result.  This is
      theoretically possible but could be indicative of a sub-optimum
      network configuration.

   See Also:
      Primary Path
      Backup Path
      Primary Path Latency
      Backup Path Latency

<span class="h3"><a class="selflink" id="section-3.6" href="#section-3.6">3.6</a>.  Failover Time Calculation Methods</span>

   The following Methods may be assessed on a per-flow basis using at
   least 16 flows spread over the routing table (using more flows is
   better).  Otherwise, the impact of a prefix-dependency in the
   implementation of a particular protection technology could be missed.
   However, the test designer must be aware of the number of packets per
   second sent to each prefix, as this establishes sampling of the path
   and the time resolution for measurement of Failover time on a per-
   flow basis.








<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="./rfc6414">RFC 6414</a>            Benchmarking Terms for Protection      November 2011</span>


<span class="h4"><a class="selflink" id="section-3.6.1" href="#section-3.6.1">3.6.1</a>.  Time-Based Loss Method (TBLM)</span>

   Definition:
      The method to calculate Failover Time (or Reversion Time) using a
      time scale on the Tester to measure the interval of Failover
      Packet Loss.

   Discussion:
      The Tester must provide statistics that show the duration of
      failure on a time scale based on occurrence of packet loss on a
      time scale.  This is indicated by the duration of non-zero packet
      loss.  The TBLM includes failure detection time and time for data
      traffic to begin traversing the Backup Path.  Failover Time and
      Reversion Time are calculated using the TBLM as shown in Equation
      2:

      (Equation 2)
          (Equation 2a)
          TBLM Failover Time = Time(Failover) - Time(Failover Event)

          (Equation 2b)
          TBLM Reversion Time = Time(Reversion) - Time(Restoration)

      Where

      Time(Failover) = Time on the tester at the receipt of the first
      unimpaired packet at egress node after the backup path became the
      working path

      Time(Failover Event) = Time on the tester at the receipt of the
      last unimpaired packet at egress node on the primary path before
      failure

   Measurement Units:
      milliseconds

   Issues:
      None.

   See Also:
      Failover
      Packet-Loss-Based Method

<span class="h4"><a class="selflink" id="section-3.6.2" href="#section-3.6.2">3.6.2</a>.  Packet-Loss-Based Method (PLBM)</span>

   Definition:
      The method used to calculate Failover Time (or Reversion Time)
      from the amount of Failover Packet Loss.



<span class="grey">Poretsky, et al.              Informational                    [Page 29]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-30" ></span>
<span class="grey"><a href="./rfc6414">RFC 6414</a>            Benchmarking Terms for Protection      November 2011</span>


   Discussion:
      PLBM includes failure detection time and time for data traffic to
      begin traversing the Backup Path.  Failover Time can be calculated
      using PLBM from the amount of Failover Packet Loss as shown below
      in Equation 3.  Note: If traffic is sent to more than 1
      destination, PLBM gives the average loss over the measured
      destinations.

      (Equation 3)
           (Equation 3a)
           PLBM Failover Time =
              (Number of packets lost / Offered Load rate) * 1000)

           (Equation 3b)
           PLBM Restoration Time =
              (Number of packets lost / Offered Load rate) * 1000)

           Units are packets/(packets/second) = seconds

   Measurement Units:
      milliseconds

   Issues:
      None.

   See Also:
      Failover Time-Based Loss Method

<span class="h4"><a class="selflink" id="section-3.6.3" href="#section-3.6.3">3.6.3</a>.  Timestamp-Based Method (TBM)</span>

   Definition:
      The method to calculate Failover Time (or Reversion Time) using a
      time scale to quantify the interval between unimpaired packets
      arriving in the test stream.

   Discussion:
      The purpose of this method is to quantify the duration of failure
      or reversion on a time scale based on the observation of
      unimpaired packets.  The TBM is calculated from Equation 2 with
      the values obtained from the timestamp in the packet payload,
      rather than from the Tester clock (which are used with the TBLM).

      Unimpaired packets are normal packets that are not lost,
      reordered, or duplicated.  A reordered packet is defined in
      Section 3.3 of [<a href="#ref-7" title="&quot;Packet Reordering Metrics&quot;">7</a>].  A duplicate packet is defined in <a href="#section-3.3.5">Section</a>
      <a href="#section-3.3.5">3.3.5</a> of [<a href="#ref-4" title="&quot;Terminology for Benchmarking Network-layer Traffic Control Mechanisms&quot;">4</a>].  Unimpaired packets may be detected by checking a





<span class="grey">Poretsky, et al.              Informational                    [Page 30]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-31" ></span>
<span class="grey"><a href="./rfc6414">RFC 6414</a>            Benchmarking Terms for Protection      November 2011</span>


      sequence number in the payload, where the sequence number equals
      the next expected number for an unimpaired packet.  A sequence gap
      or sequence reversal indicates impaired packets.

      For calculating Failover Time, the TBM includes failure detection
      time and time for data traffic to begin traversing the Backup
      Path.  For calculating Reversion Time, the TBM includes Reversion
      Time and time for data traffic to begin traversing the Primary
      Path.

   Measurement Units:
      milliseconds

   Issues:
      None.

   See Also:
      Failover
      Failover Time
      Reversion
      Reversion Time

<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="grey">Poretsky, et al.              Informational                    [Page 31]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-32" ></span>
<span class="grey"><a href="./rfc6414">RFC 6414</a>            Benchmarking Terms for Protection      November 2011</span>


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

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

   [<a id="ref-1">1</a>]  Bradner, S., "The Internet Standards Process -- Revision 3", <a href="https://www.rfc-editor.org/bcp/bcp9">BCP</a>
        <a href="https://www.rfc-editor.org/bcp/bcp9">9</a>, <a href="./rfc2026">RFC 2026</a>, October 1996.

   [<a id="ref-2">2</a>]  Bradner, S., "Benchmarking Terminology for Network
        Interconnection Devices", <a href="./rfc1242">RFC 1242</a>, July 1991.

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

   [<a id="ref-4">4</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-5">5</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-6">6</a>]  Poretsky, S., Imhoff, B., and K. Michielsen, "Terminology for
        Benchmarking Link-State IGP Data Plane Route Convergence", <a href="./rfc6412">RFC</a>
        <a href="./rfc6412">6412</a>, November 2011.

   [<a id="ref-7">7</a>]  Morton, A., Ciavattone, L., Ramachandran, G., Shalunov, S., and
        J. Perser, "Packet Reordering Metrics", <a href="./rfc4737">RFC 4737</a>, November 2006.

   [<a id="ref-8">8</a>]  Nadas, S., Ed., "Virtual Router Redundancy Protocol (VRRP)
        Version 3 for IPv4 and IPv6", <a href="./rfc5798">RFC 5798</a>, March 2010.

<span class="h3"><a class="selflink" id="section-5.2" href="#section-5.2">5.2</a>.  Informative References</span>

   [<a id="ref-9">9</a>]  Pan, P., Ed., Swallow, G., Ed., and A. Atlas, Ed., "Fast Reroute
        Extensions to RSVP-TE for LSP Tunnels", <a href="./rfc4090">RFC 4090</a>, May 2005.

   [<a id="ref-10">10</a>] Nichols, K., Blake, S., Baker, F., and D. Black, "Definition of
        the Differentiated Services Field (DS Field) in the IPv4 and
        IPv6 Headers", <a href="./rfc2474">RFC 2474</a>, December 1998.

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

   We would like thank the BMWG and particularly Al Morton and Curtis
   Villamizar for their reviews, comments, and contributions to this
   work.







<span class="grey">Poretsky, et al.              Informational                    [Page 32]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-33" ></span>
<span class="grey"><a href="./rfc6414">RFC 6414</a>            Benchmarking Terms for Protection      November 2011</span>


Authors' Addresses

   Scott Poretsky
   Allot Communications
   300 TradeCenter
   Woburn, MA  01801
   USA
   Phone: + 1 508 309 2179
   EMail: sporetsky@allot.com

   Rajiv Papneja
   Huawei Technologies
   2330 Central Expressway
   Santa Clara, CA  95050
   USA
   Phone: +1 571 926 8593
   EMail: rajiv.papneja@huawei.com

   Jay Karthik
   Cisco Systems
   300 Beaver Brook Road
   Boxborough, MA  01719
   USA
   Phone: +1 978 936 0533
   EMail: jkarthik@cisco.com

   Samir Vapiwala
   Cisco System
   300 Beaver Brook Road
   Boxborough, MA  01719
   USA
   Phone: +1 978 936 1484
   EMail: svapiwal@cisco.com


















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