RFC 6414

Benchmarking Terminology for Protection Performance

📅 published November 2011, from ietf

Benchmarking Terminology for Protection Performance 🎀

Okay bestie, this RFC is from the IETF and it's the Informational kind, so it's sharing knowledge, not setting a rule. It was written by S. Poretsky of Allot Communications, R. Papneja of Huawei, and J. Karthik and S. Vapiwala, who are both at Cisco Systems. It came out in November 2011 as RFC 6414 and has ISSN 2070-1721. It doesn't list anything it obsoletes or updates, so it's a standalone vibe. ✨

Abstract 💜

Okay so this doc gives us a shared vocab and metrics for benchmarking how well sub-IP layer protection mechanisms perform 💅. The measurements happen at the IP layer, even though the protection itself can happen lower down. The terms and benchmarks are meant to be used in methodology docs for different sub-IP protection mechanisms, like Automatic Protection Switching (APS), Virtual Router Redundancy Protocol (VRRP), Stateful High Availability (HA), and Multiprotocol Label Switching Fast Reroute (MPLS-FRR). It's giving "everyone speaks the same language" 🦋

Status of This Memo 🌸

Not an Internet Standards Track spec! It's just published for info 🧚

This is an IETF product, so it reflects what the IETF community agreed on. It got public review and the Internet Engineering Steering Group (IESG) approved it for publication. Not every IESG-approved doc is up for any level of Internet Standard, so check Section 2 of RFC 5741 for that stuff 🫶

For the current status, any errata, and how to send feedback, go to http://www.rfc-editor.org/info/rfc6414. 💖

Copyright Notice 🌈

This doc is covered by BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) as they stood when it was published. Read those carefully, because they spell out your rights and restrictions for this doc. Code Components pulled out of this doc have to include the Simplified BSD License text, as described in Section 4.e of the Trust Legal Provisions, and they come with no warranty, same as that license says 💀

This doc might include stuff from IETF Documents or IETF Contributions that was published or made public before November 10, 2008. The folks who hold the copyright on some of that material might not have given the IETF Trust permission to allow changes outside the IETF Standards Process. So without a proper license from them, you can't modify this doc outside the IETF Standards Process, and you can't make derivative works of it outside that process either. The only exceptions are formatting it for publication as an RFC or translating it into languages other than English 🙈

Table of Contents 📚

   1. Introduction ....................................................4
      1.1. Scope ......................................................4
      1.2. General Model ..............................................5
   2. Existing Definitions ............................................8
   3. Test Considerations .............................................9
      3.1. Paths ......................................................9
           3.1.1. Path ................................................9
           3.1.2. Working Path .......................................10
           3.1.3. Primary Path .......................................10
           3.1.4. Protected Primary Path .............................11
           3.1.5. Backup Path ........................................11
           3.1.6. Standby Backup Path ................................12
           3.1.7. Dynamic Backup Path ................................12
           3.1.8. Disjoint Paths .....................................13
           3.1.9. Point of Local Repair (PLR) ........................13
           3.1.10. Shared Risk Link Group (SRLG) .....................14
      3.2. Protection ................................................14
           3.2.1. Link Protection ....................................14
           3.2.2. Node Protection ....................................15
           3.2.3. Path Protection ....................................15
           3.2.4. Backup Span ........................................16
           3.2.5. Local Link Protection ..............................16
           3.2.6. Redundant Node Protection ..........................17
           3.2.7. State Control Interface ............................17
           3.2.8. Protected Interface ................................18
      3.3. Protection Switching ......................................18
           3.3.1. Protection-Switching System ........................18
           3.3.2. Failover Event .....................................19
           3.3.3. Failure Detection ..................................19
           3.3.4. Failover ...........................................20
           3.3.5. Restoration ........................................20
           3.3.6. Reversion ..........................................21
      3.4. Nodes .....................................................22
           3.4.1. Protection-Switching Node ..........................22
           3.4.2. Non-Protection-Switching Node ......................22
           3.4.3. Headend Node .......................................23
           3.4.4. Backup Node ........................................23
           3.4.5. Merge Node .........................................24
           3.4.6. Primary Node .......................................24
           3.4.7. Standby Node .......................................25
      3.5. Benchmarks ................................................26
           3.5.1. Failover Packet Loss ...............................26
           3.5.2. Reversion Packet Loss ..............................26
           3.5.3. Failover Time ......................................27
           3.5.4. Reversion Time .....................................27
           3.5.5. Additive Backup Delay ..............................28
      3.6. Failover Time Calculation Methods .........................28
           3.6.1. Time-Based Loss Method (TBLM) ......................29
           3.6.2. Packet-Loss-Based Method (PLBM) ....................29
           3.6.3. Timestamp-Based Method (TBM) .......................30
   4. Security Considerations ........................................31
   5. References .....................................................32
      5.1. Normative References ......................................32
      5.2. Informative References ....................................32
   6. Acknowledgments ................................................32

1. Introduction 🦋

Okay so the IP network layer handles route convergence to protect data traffic from planned and unplanned failures on the Internet. Fast convergence is literally critical for keeping connectivity and performance reliable 😭 Convergence Events [6] get recognized at the IP layer so that Route Convergence [6] can happen.

Then there are sub-IP layer technologies that can add extra protection for IP traffic. They do the failure recovery down at the sub-IP layers, so the outage never shows up at the IP layer, which is iconic 👑 These include, but aren't limited to, High Availability (HA) stateful failover, Virtual Router Redundancy Protocol (VRRP) [8], Automatic Link Protection (APS) for SONET/SDH, Resilient Packet Ring (RPR) for Ethernet, and Fast Reroute for Multiprotocol Label Switching (MPLS-FRR) [9]. ✨

1.1. Scope 🌸

Benchmarking terminology was already defined for IP-layer convergence in [6]. But sub-IP layer protection mechanisms need their own terminology and methodologies, so ngl we need this doc 💅 The performance metrics for sub-IP protection get measured at the IP layer. That way the results always relate back to IP and don't depend on which protection mechanism is being used 🧚 The whole point of this doc is to give you one terminology for benchmarking sub-IP protection mechanisms.

With a common terminology, you can benchmark and compare different implementations of the same protection mechanism. You can also benchmark and compare implementations of different protection mechanisms, which is so main character energy 🎀 The plan is that each sub-IP protection mechanism can get its own methodology doc built on this shared terminology. The terminology works for methodologies that benchmark with a single stream of traffic or with multiple streams. The traffic flow can be unidirectional or bidirectional, depending on what the methodology says to indicate 🫶

1.2. General Model

Okay so here's the sequence of events for benchmarking sub-IP protection, and it goes in this exact order 💅:

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

These terms get more detail later in the doc ✨

Figures 1 through 5 show models that MAY be used when benchmarking sub-IP protection mechanisms. They MUST use a Protection-Switching System, which is a minimum of two Protection-Switching Nodes 🎀: an Ingress Node (called the Headend Node) and an Egress Node (called 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 happens along the Primary Path or at the Primary Node. The Working Path is the Primary Path before the Failover Event and the Backup Path after it. 🦋

A Tester sits outside the two paths or nodes and sends and receives IP traffic along the Working Path. The tester MUST record the IP packet sequence numbers, departure time, and arrival time so the metrics of Failover Time, Additive Latency, Packet Reordering, Duplicate Packets, and Reversion Time can be measured. The Tester can be a single device or a test system. If Reversion is supported, the Working Path is the Primary Path again after Restoration (Failure Recovery) of the Primary Path. 💖

Link Protection (Figure 1) protects you when a Failover Event happens on the link between two nodes along the Primary Path. Node Protection (Figure 2) covers a Failover Event at a Node along the Primary Path. Path Protection (Figure 3) covers link or node failures across multiple hops along the Primary Path. Local Link Protection (Figure 4) gives sub-IP protection for a link between two nodes, without a Backup Node. An example of this kind of sub-IP protection mechanism is SONET APS. High Availability Protection (Figure 5) protects a Primary Node with a redundant Standby Node. State Control runs between the Primary and Standby Nodes. The Primary Node failure gets detected at the sub-IP layer, which forces traffic over to the Standby Node. That node has state maintained for zero or minimal packet loss, which is so iconic 🔥

                  +-----------+
   +--------------|  Tester   |<-----------------------+
   |              +-----------+                        |
   | IP Traffic        | Failover           IP Traffic |
   |                   |  Event                        |
   |     ------------  |                 ----------    |
   +--->|  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   |<-----------------+
   |                    +-----------+                  |
   | IP Traffic               | Failover    IP Traffic |
   |                          | Event                  |
   |                          V                        |
   |     ------------      --------      ----------    |
   +--->|  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

                            +-----------+
+---------------------------|  Tester   |<----------------------+
|                           +-----------+                       |
| IP Traffic                      | Failover         IP Traffic |
|                                 | Event                       |
|                Primary Path     |                             |
|     ------------      --------  |  --------     ----------    |
+--->|  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   |<-------------------+
         |                    +-----------+                    |
         | IP Traffic               | Failover      IP Traffic |
         |                          | Event                    |
         |              Primary     |                          |
         |    +--------+  Path      v            +--------+    |
         |    |        |------------------------>|        |    |
         +--->| Ingress|                         | Egress |----+
              |  Node  |- - - - - - - - - - - - >|  Node  |
              +--------+      Backup Path        +--------+
              |                                           |
              |            IP-Layer Forwarding            |
              +<----------------------------------------->+

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

                        +-----------+
      +-----------------|  Tester   |<--------------------+
      |                 +-----------+                     |
      | IP Traffic            | Failover       IP Traffic |
      |                       | Event                     |
      |                       V                           |
      |     ---------      --------      ----------       |
      +--->| 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 might use a series of steps that are different from the general model. The specific differences SHOULD be highlighted in each technology-specific methodology. Also, some protection-switching technologies can re-optimize the working path after a node or link failure, which is a whole main character move 👑

2. Existing Definitions

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

   Latency                   [2], Section 3.8
   Frame Loss Rate           [2], Section 3.6
   Throughput                [2], Section 3.17
   Device Under Test (DUT)   [3], Section 3.1.1
   System Under Test (SUT)   [3], Section 3.1.2
   Offered Load              [3], Section 3.5.2
   Out-of-order Packet       [4], Section 3.3.4
   Duplicate Packet          [4], Section 3.3.5
   Forwarding Delay          [4], Section 3.2.4
   Jitter                    [4], Section 3.2.5
   Packet Loss               [6], Section 3.5
   Packet Reordering         [7], Section 3.3

This document has the following frequently used acronyms:

   DUT  Device Under Test
   SUT  System Under Test

This document adopts the definition format in Section 2 of RFC 1242 [2]. Terms defined in this document get capitalized when they're 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 BCP 14, RFC 2119 [5]. RFC 2119 defines how these keywords are used, to help make the intent of Standards Track documents as clear as possible. This document uses these keywords, but it is not a Standards Track document 🙈

3. Test Considerations

3.1. Paths

3.1.1. Path

Definition:

A unidirectional sequence of nodes <R1, ..., Rn> and links <L12,... L(n-1)n> 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<i<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, which is different from an IP path in RFC 2026 [1]. 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 [10] 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

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

3.1.2. Working Path

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

3.1.3. Primary Path 💖

Definition: The preferred point-to-point path for forwarding traffic between two or more nodes. It's the VIP route, bestie 👑

Discussion: The Primary Path is the Path that traffic traverses prior to a Failover Event. So it's the route everyone is on until something goes wrong 😭

Measurement Units: n/a

Issues: None.

See Also:

Path
Failover Event

3.1.4. Protected Primary Path 🛡️

Definition: A Primary Path that is protected with a Backup Path. It's the Primary Path with a bodyguard 💅

Discussion: A Protected Primary Path must include at least one Protection-Switching Node. No cap, that's the rule 🫶

Measurement Units: n/a

Issues: None.

See Also:

Path
Primary Path

3.1.5. Backup Path 🦋

Definition: A path that exists to carry data traffic only if a Failover Event occurs on a Primary Path. It's the understudy that waits in the wings 🎭

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, and they're giving very different energy:

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

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

3.1.6. Standby Backup Path 🌸

Definition: A Backup Path that is established prior to a Failover Event to protect a Primary Path. It's already set up and waiting, like the friend who's always early 🧚

Discussion: The Standby Backup Path and Dynamic Backup Path provide protection, but are established at different times. That's the whole tea ☕

Measurement Units: n/a

Issues: None.

See Also:

Backup Path
Primary Path
Failover Event

3.1.7. Dynamic Backup Path 🌈

Definition: A Backup Path that is established upon occurrence of a Failover Event. It gets made the moment it's needed, so it's a last-minute legend 🔥

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

Measurement Units: n/a

Issues: None.

See See Also:

Backup Path
Standby Backup Path
Failover Event

3.1.8. Disjoint Paths 🍓

Definition: A pair of paths that do not share a common link or nodes. They're totally separate friend groups 🙈

Discussion: Two paths are disjoint if they do not share a common node or link other than the ingress and egress. So the only things they're allowed to share are the start and the end ✨

Measurement Units: n/a

Issues: None.

See Also:

Path
Primary Path
SRLG

3.1.9. Point of Local Repair (PLR) 🔧

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. It's the fixer of the group 💅

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. It's giving multitasking 🫶

Measurement Units: n/a

Issues: None.

See Also:

Primary Path
Backup Path
Failover

3.1.10. Shared Risk Link Group (SRLG) ⭐

Definition: SRLG is a set of links that share the same risk (physical or logical) within a network. They're all riding on the same risky ride together 🎢

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. So if one falls, they all fall, periodt 😭

Measurement Units: n/a

Issues: None.

See Also:

Path Primary Path

Primary Path
Backup Path

3.3. Protection Switching ⚡

3.3.1. Protection-Switching System 🔁

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. It's the system that does the switcheroo 💃

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. It's got both the spotting and the switching covered 👑

Measurement Units: n/a

Issues: None.

See Also:

Primary Path Backup Path Failover

3.3.2. Failover Event ⚠️

Definition: The occurrence of a planned or unplanned action in the network that results in a change in the Path that data traffic traverses. Planned or unplanned, it still counts, bestie 🫶

Discussion: Failover Events include, but are not limited to, link failure and router failure. Routing changes are considered Convergence Events [6] 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 [6] by the detection of the failure and subsequent protection switching at a sub-IP layer. Failover occurs at a PLR or Primary Node. Routing changes are a whole different drama 🎭

Measurement Units: n/a

Issues: None.

See Also:

Path
Failure Detection
Disjoint Path

3.3.3. Failure Detection 🔍

Definition: The process to identify at a sub-IP layer a Failover Event at a Primary Node or along the Primary Path. It's the detective work, and it's giving Sherlock 🕵️‍♀️

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 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. Some failures are solo, some come with the whole squad 💀

Measurement Units: n/a

Issues: None.

See Also:

Primary Path

3.3.4. Failover ✨

Definition: okay so Failover is the moment data traffic gets switched from the protected Primary Path over to the Backup Path, and it kicks off once Failure Detection of a Failover Event happens 🦋

Discussion: bestie, Failover onto a Backup Path gives you Link Protection, Node Protection, or Path Protection, so pick your fighter 💅 Failover is only complete when Packet Loss [6], Out-of-order Packets [4], and Duplicate Packets [4] are no longer showing up. Forwarding Delay [4] may keep showing up after that, and that's fine 🫶

Measurement Units: n/a

Issues: None.

See Also:

Primary Path
Backup Path
Failover Event
Failover

3.3.5. Restoration 🌸

Definition: Restoration is the failover recovery state where the Primary Path has recovered from a Failover Event, but it isn't forwarding packets yet because the Backup Path is still the Working Path 🫠

Discussion: Restoration must occur while the Backup Path is the Working Path. The Backup Path stays as the Working Path during Restoration. Restoration gives you a Primary Path that's recovered from failure, but it's not forwarding traffic yet. Traffic is still being forwarded by the Backup Path, which is doing the job of the Working Path 💜

Measurement Units: n/a

Issues: None.

See Also:

Primary Path
Failover Event
Failure Recovery
Working Path
Backup Path

3.3.6. Reversion 🔄

Definition: Reversion is the failover recovery state where the Primary Path has become the Working Path, so it's the one actually forwarding packets now 👑

Discussion: Protection-Switching Systems may or may not support Reversion, so it's totally optional 🤷‍♀️ If Reversion is supported, it must occur after Restoration. Packet forwarding on the Primary Path that comes from Reversion may happen either fully or partially over the Primary Path. The tea here is that Reversion can cause a discontinuity in end-to-end delay when the Forwarding Delays [4] along the Primary Path and Backup Path are different. That can lead to Out-of-order Packets [4], Duplicate Packets [4], and increased Jitter [4] 😭

Measurement Units: n/a

Issues: None.

See Also:

Protection-Switching System
Working Path
Primary Path

Issues: None.

See Also:

Primary Node
State Control Interface

Reversion
Primary Path
Working Path
Reversion Packet Loss
Time-Based Loss Method (TBLM)
Packet-Loss-Based Method (PLBM)
Timestamp-Based Method (TBM)

3.5.5. Additive Backup Delay 🐢

Definition: This is the extra Forwarding Delay [4] you get when data traffic goes over the Backup Path instead of the Primary Path 😬

Discussion: Additive Backup Delay is calculated using Equation 1, 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 it could be a sign of a sub-optimum network configuration. Tea spilled ☕

See Also:

Primary Path
Backup Path
Primary Path Latency
Backup Path Latency

3.6. Failover Time Calculation Methods 🧮

These 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. The test designer must be aware of the number of packets per second sent to each prefix, though, because that sets the sampling of the path and the time resolution for measuring Failover time on a per-flow basis. Don't skip the math, girl 🥰

3.6.1. Time-Based Loss Method (TBLM) ⏱️

Definition: okay so this one is the method for working out Failover Time (or Reversion Time) by using a time scale on the Tester to measure the interval of Failover Packet Loss. 🎀

Discussion: the Tester has to hand over statistics showing how long the failure lasted, on a time scale based on when packet loss happened. You can tell by how long the packet loss is non-zero 👀. TBLM includes failure detection time and the time for data traffic to start traversing the Backup Path. Failover Time and Reversion Time get calculated with TBLM like this, per 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 🦋

3.6.2. Packet-Loss-Based Method (PLBM) 📉

Definition: this is the method for calculating Failover Time (or Reversion Time) straight from the amount of Failover Packet Loss. 💅

Discussion: PLBM includes failure detection time and the time for data traffic to begin traversing the Backup Path. Failover Time can be calculated with PLBM from the amount of Failover Packet Loss, 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 💜

3.6.3. Timestamp-Based Method (TBM) 🕰️

Definition: this is the method for calculating Failover Time (or Reversion Time) using a time scale that measures the gap between unimpaired packets arriving in the test stream. 🔥

Discussion: the whole point here is to quantify how long the failure or reversion lasted, on a time scale, based on watching the unimpaired packets. TBM is calculated from Equation 2, except it uses the values from the timestamp in the packet payload instead of the Tester clock (which is what TBLM uses). 🧚

Unimpaired packets are normal packets that aren't lost, reordered, or duplicated. A reordered packet is defined in Section 3.3 of [7]. A duplicate packet is defined in Section 3.3.5 of [4]. You can detect unimpaired packets by checking a sequence number in the payload, where the sequence number equals the next expected number for an unimpaired packet. A sequence gap or sequence reversal means the packets are impaired. 🙈

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

Measurement Units: milliseconds 🍓

Issues: None. ✨

See Also: Failover, Failover Time, Reversion, Reversion Time 👑

4. Security Considerations 🔐

Benchmarking activities 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. 😭 This one is serious, bestie, so please don't skip it!!

Further, benchmarking is performed on a "black-box" basis, relying solely on measurements observable external to the DUT/SUT. 🕵️

Special capabilities SHOULD NOT exist in the DUT/SUT specifically for benchmarking purposes. Any implications for network security arising from the DUT/SUT SHOULD be identical in the lab and in production networks. 💀

5. References 📚

5.1. Normative References 🎀

[1]  Bradner, S., "The Internet Standards Process -- Revision 3", BCP
     9, RFC 2026, October 1996.

[2]  Bradner, S., "Benchmarking Terminology for Network
     Interconnection Devices", RFC 1242, July 1991.

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

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

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

[6]  Poretsky, S., Imhoff, B., and K. Michielsen, "Terminology for
     Benchmarking Link-State IGP Data Plane Route Convergence", RFC
     6412, November 2011.

[7]  Morton, A., Ciavattone, L., Ramachandran, G., Shalunov, S., and
     J. Perser, "Packet Reordering Metrics", RFC 4737, November 2006.

[8]  Nadas, S., Ed., "Virtual Router Redundancy Protocol (VRRP)
     Version 3 for IPv4 and IPv6", RFC 5798, March 2010.

5.2. Informative References 🦋

[9]  Pan, P., Ed., Swallow, G., Ed., and A. Atlas, Ed., "Fast Reroute
     Extensions to RSVP-TE for LSP Tunnels", RFC 4090, May 2005.

[10] Nichols, K., Blake, S., Baker, F., and D. Black, "Definition of
     the Differentiated Services Field (DS Field) in the IPv4 and
     IPv6 Headers", RFC 2474, December 1998.

6. Acknowledgments 🫶

We would like thank the BMWG and particularly Al Morton and Curtis Villamizar for their reviews, comments, and contributions to this work. 🌷 Huge love to these legends!!

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

📦 where this page comes from

ietf: rfc6414 2011-11
💖 girlified by claude-haiku-5-5 on 2026-10-17: a language model's rewrite of the original, under its terms