Network Working Group
 Internet Draft
 Expires: January 2008
 Intended Status: Informational
                                               S. Poretsky
                                               Reef Point Systems

                                               R. Papneja
                                               Isocore

                                               J. Karthik
                                               S.Vapiwala
                                               S. Vapiwala
                                               Cisco Systems

                                               November 2007

         Benchmarking Terminology for Protection Performance
             <draft-ietf-bmwg-protection-term-02.txt
             <draft-ietf-bmwg-protection-term-03.txt >

   Intellectual Property Rights (IPR) statement:
   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, in accordance with Section 6 of BCP 79.

Status of this Memo

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

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

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

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

Copyright Notice
   Copyright (C) The IETF Trust (2007).

                          Protection Performance

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, so avoid dependence on
  specific sub-IP protection mechanisms. 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 Multi-Protocol Label Switching Fast Reroute (MPLS-FRR).

                          Protection Performance

 Table of Contents
        1. Introduction..............................................3
        2. Existing definitions......................................4
        3. Test Considerations.......................................4 Considerations.......................................5
           3.1. Path.................................................5
              3.1.1. Path............................................5
              3.1.2. Tunnel..........................................6
              3.1.3. Working Path....................................6
              3.1.4.
              3.1.3. Primary Path....................................7
              3.1.5. Path....................................6
              3.1.4. Protected Primary Path..........................7
              3.1.6. Path..........................6
              3.1.5. Backup Path.....................................8
              3.1.7. Path.....................................7
              3.1.6. Standby Backup Path.............................8
              3.1.8.
              3.1.7. Dynamic Backup Path.............................9
              3.1.9. Path.............................8
              3.1.8. Disjoint Paths..................................9
              3.1.10. Paths..................................8
              3.1.9. Shared Risk Link Group (SRLG)..................10 (SRLG)...................9
           3.2. Protection...........................................10 Protection...........................................9
              3.2.1. Protection Switching System.....................10 System.....................9
              3.2.2. Link Protection.................................11 Protection.................................10
              3.2.3. Node Protection.................................11 Protection.................................10
              3.2.4. Path Protection.................................12 Protection.................................10
              3.2.5. Backup Span.....................................12 Span.....................................11
              3.2.6  Protected Interface.............................12 Interface.............................11
           3.3. Failure..............................................13 Protection Switching.................................12
              3.3.1. Failover Event..................................13 Event..................................12
              3.3.2. Failure Detection...............................13 Detection...............................12
              3.3.3. Failover........................................14 Failover........................................13
              3.3.4. Restoration (Failover recovery).................14 Restoration.....................................13
              3.3.5. Reversion.......................................15 Reversion.......................................14
           3.4. Nodes................................................15 Nodes................................................14
              3.4.1. Protection-Switching Node.......................15 Node.......................14
              3.4.2. Non-Protection Switching Node...................15 Node...................14
              3.4.3. Failover Node...................................16 Node...................................15
              3.4.4. Merge Node......................................16
                          Protection Performance Node......................................15
              3.4.5. Point of Local repair (PLR).....................17 (PLR).....................16
              3.4.6. Head-end Failover Node..........................17 Node..........................16
           3.5. Metrics..............................................18 Benchmarks...........................................17
              3.5.1. Failover Packet Loss............................18 Loss............................17
              3.5.2. Reversion Packet Loss...........................18 Loss...........................17
              3.5.3. Primary Path Latency............................19
              3.5.4. Backup Path Latency.............................19
           3.6. Benchmarks...........................................20
              3.6.1. Failover Time...................................20
              3.6.2. Time...................................18
              3.5.4. Reversion Time..................................18
              3.5.5. Additive Backup Latency.........................21
              3.6.3. Reversion Time..................................21
           3.7 Latency.........................19
           3.6 Failover Time Calculation Method...........................22
              3.7.1 Methods.....................19
              3.6.1 Time-Based Loss Method...........................22
              3.7.2 Packet-Based Loss Method.........................22
              3.7.3 Method...........................19
              3.6.2 Packet-Loss Based Method.........................20
              3.6.3 Timestamp-Based Method...........................23 Method...........................21
        4. Acknowledgments...........................................24 Acknowledgments...........................................22
        5. IANA Considerations.......................................24 Considerations.......................................22
        6. Security Considerations...................................24 Considerations...................................22
        7. References................................................24
           7.1. Normative References.................................24
           7.2. Informative References...............................24 References................................................22
        8. Author's Address..........................................25 Address..........................................23
                          Protection Performance

1. Introduction

   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.  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 technologies
   includes High Availability (HA) stateful failover.  Virtual Router
   Redundancy Protocol (VRRP), Automatic Link Protection (APS) for
   SONET/SDH, Resilient Packet Ring (RPR) for Ethernet, and Fast
   Reroute for Multi-Protocol Label Switching (MPLS). (MPLS-FRR) [8].

   Benchmarking terminology have been defined for IP-layer route
   convergence [7].  New terminology and methodologies specific
   to benchmarking sub-IP layer protection mechanisms are required.
   This will enable different implementations of the same
   protection mechanisms to be benchmarked and evaluated. In
   addition, different protection mechanisms can be benchmarked and
   evaluated.  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
                          Protection Performance
   the specific protection mechanism being used. The purpose of this
   document is to provide a single terminology for benchmarking sub-IP
   protection mechanisms.  It is intended that there can exist unique
   methodology documents for each sub-IP protection mechanism. The
   sequence of events 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.  Figure 1 shows
   the fundamental model that is to be used in benchmarking sub-IP
   protection mechanisms.  The sequence of
   events is Failover Event, Failure Detection, Failover, Restoration
   (Failover recovery), and optionally Reversion.  A Protection Switching consists of a minimum
   of two Protection-Switching Nodes with a  Primary Path and a Backup
   Path.  A Failover Event occurs along the Primary Path.  A tester Tester is
   set outside the two nodes as it sends and receives IP traffic along
   the Working Path.  The Working Path is the Primary Path prior to
   the Failover Event and the Backup Path following after the Failover Event.
   If Reversion is supported then the Working Path is the Primary Path
   after Failure
   Recovery. Restoration (Failure Recovery) of the Primary 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.

                          Protection Performance

                                  +-----------+
             +--------------------|  Tester   |<-------------------+
             |                    +-----------+                    |
             | IP Traffic               | Failover      IP Traffic |
             |                          | Event                    |
             |              Primary     |                          |
             |    +--------+  Path      v            +--------+    |
             |    |        |------------------------>|        |    |
             +--->| Node 1 |                         | Node 2 |----+
                  |        |- - - - - - - - - - - - >|        |
                  +--------+      Backup Path        +--------+
                  |                                           |
                  ^                                           ^
                  |            IP-Layer Forwarding            |
                  +-------------------------------------------+

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

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

          Latency                   [Ref.[2], section 3.8]
          Frame Loss Rate           [Ref.[2], section 3.6]
          Throughput                [Ref.[2], section 3.17]
          Device Under Test (DUT)   [Ref.[3], section 3.1.1]
          System Under Test (SUT)   [Ref.[3], section 3.1.2]
          Out-of-order Packet       [Ref.[4], section 3.3.2]
          Duplicate Packet          [Ref.[4], section 3.3.3]
          Forwarding Delay          [Ref.[4], section 3.2.4]
          Jitter                    [Ref.[4], section 3.2.5]
          Packet Loss               [Ref.[7], Section 3.5]
          Packet Reordering         [Ref.[10]         [Ref.[10], 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].

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

                          Protection Performance

3. Test Considerations

  3.1. Path

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

                          Protection Performance

    Discussion:
       The path is defined in the sub-IP layer in this document, unlike
       an IP path in RFC 2026 [1].  For example, the SONET/SDH path,
       the label switched path for MPLS, and optical path.   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 [9] will transverse traverse one or more paths.
       The path is unidirectional.  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:

                          Protection Performance

    3.1.2. Tunnel

    Definition:
       Tunnel is a collection of related Paths.

    Discussion:
       A Tunnel is used to carry a specific flow of traffic which
       is generally large aggregation of microflows, but may be any
       flow defined by a classifier at the ingress. A Tunnel may
       include two primary paths during the MPLS make-before-break
       reroute.

    Measurement units: n/a

    Issues: None

    See Also:
       Path
       Primary Path
       Backup Path

    3.1.3. Working Path

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

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

                          Protection Performance

    Measurement units:
       n/a

    Issues:

    See Also:
       Path
       Primary Path
       Backup Path

    3.1.4.

   3.1.3.  Primary Path

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

       Discussion:

       Measurement units:
          n/a

        Issues:
          None

        See Also:
          Path

    3.1.5.

    3.1.4.  Protected Primary Path

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

       Discussion:

       Measurement units:
          n/a

       Issues:

       See Also:
          Path
       A Protected Primary Path MUST include at least one Protection
       Switching Node.

                          Protection Performance
    3.1.6.

       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. occurs on a Primary Path.

       Discussion:
       The Backup Path is SHALL be 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

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

          b. shared Backup Path (1:N), which is dedicated to the
          protection for more than one specific Primary Path, and an 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 is always computed before Path may be signaled or unsignaled.  The Backup Path
       MUST be created prior to the
       failover event. Failover Event.  A new path Path
       computed after the failover event Failover Event is simply reroute of the primary path. A backup may be
       signaled or unsignaled. Convergence [7]
       to a new Primary Path.

       Measurement units:
          n/a

       Issues:

       See Also:
          Path
          Working Path
          Primary Path

     3.1.7.
                          Protection Performance

     3.1.6.  Standby Backup Path

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

                          Protection Performance

        Discussion:

        Measurement units:
           n/a

        Issues:

        See Also:
           Path
           Working Path
           Primary Path
           Failover Event

     3.1.8.

     3.1.7. Dynamic Backup Path

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

         Discussion:

         Measurement units:
             n/a

         Issues:

         See Also:
             Path
             Working Path
             Primary Path
             Failover Event

     3.1.9.

     3.1.8. Disjoint Paths

        Definition:
        A pair of paths is considered disjoint if they do not
        share a common link.

                          Protection Performance

        Discussions:
        Paths that protect a segment of a path may merge beyond the
        segment being protected and are considered disjoint if they
        do not use a link from the set of links in the protected
        segment. A path is node disjoint if it does not share a
        common node other than the ingress and egress.

                          Protection Performance

        Measurement units:
           n/a

        Issues:

        See Also:
           Path
           Primary Path
           SRLG

     3.1.10.

     3.1.9. Shared Risk Link Group (SRLG)

         Definition:
          SRLG is a set of links which are likely to fail
          concurrently due to sharing share a physical resource.

         Discussion:
          SRLG are 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 fails.

         Measurement units:
             n/a

         Issues: None

         See Also:
             Path
             Primary Path
             Disjoint Path

   3.2. Protection
     3.2.1.  Protection Switching System

        Definition:
          A SUT DUT/SUT that is capable of Failure Detection and Failover
          from a Primary Path to a Backup Path.

                          Protection Performance Path when a Failover Event
          occurs.

        Discussion:
          The Protection Switching System MUST have a Primary Path
          and a Backup Path.  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

        See Also:
             Primary Path
             Backup Path
             Failure Detection
             Failover
                          Protection Performance

     3.2.2.  Link Protection

         Definition:
           A backup path Backup Path that is signal signaled to next node avoiding protected
           interface that provide protection protect for link failure
           of interfaces and links along a Primary Path.

         Discussion:
           Link Protection may or may not protect the entire Primary
           Path.

         Measurement units: n/a

         Issues: None

         See Also:
             Primary Path
             Backup Path

     3.2.3.  Node Protection

         Definition:
           A backup path Backup Path that is signal to next signaled to next node avoiding
           protected node that provide protection protect for failure
           of link or
           node. 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.

         Measurement units: n/a

         Issues: None

         See Also:
             Link Protection
                          Protection Performance

     3.2.4.   Path Protection

        Definition:
        A Backup Path that provides protection for 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 MUST have the same ingress
        node as the Primary Path.

        Measurement units: n/a

        Issues: None
                          Protection Performance

        See Also:
             Primary Path
             Backup Path
             Node Protection
             Link protection

     3.2.5. Backup Span

        Definition:
        The numbers of hop used by backup tunnel to protected link or
        node. a Backup Path.

        Discussion:

        Measurement units: number of nodes

        Issues: None

        See Also:
             Primary Path
             Backup Path

     3.2.6 Protected Interface

        Definition:
        A
        An interface which primary path along the Primary Path that is signaled over and protected by
        backup tunnel
        a Backup Path

        Discussion:

        Measurement units: None

        Issues: None

        See Also:
           Primary Path
           Backup Path
                          Protection Performance

   3.3. Failure Protection Switching

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

       Discussion:
       Failover Events include, but are not limited to, link failure
       and router failure.  Routing changes are considered Convergence
       Events [7] 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.

       Measurement units:
          n/a

       Issues:

       See Also:
          Path
          Failure Detection
          Disjoint Path

     3.3.2.  Failure Detection

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

       Discussion:
       Failure Detection occurs at the 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 which share a single SRLG
       (e.g. port with many sub-interfaces). A failure may affect
       multiple links that are not part of SRLG.

       Measurement units: n/a

       Issues:

       See Also:
         Primary Path
                          Protection Performance

     3.3.3.  Failover

        Definition:
        To
        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
        Lost Packets, Out-of-Order Packets,
        Packet Loss [7], Out-of-order Packets [4], and Duplicate
        Packets [4] are no longer observed.  Forwarding Delay [4]
        may continue to be observed.

        Measurement units:
            n/a

        Issues:

        See Also:
             Primary Path
             Backup Path
             Failover Event

     3.3.4.  Restoration

        Definition:
        The act of Failover Recovery failover recovery in which the Primary Path is
        restored following
        recovers from a Failover Event. 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 Failure Recovery. This implies Restoration.  Restoration produces
        a Primary Path that
        the service is either restored fully or partially.
        Restoration can cause congestion, recovered from failure, but primary paths
        rerouting avoid restoration. An unavoidable problem in any
        restoration is the discontinuity in end to end delay when
        the primary and backup path delays differ significantly. If
        the backup path has a shorter delay out of order delivery
        may occur if restoration
        not yet forwarding traffic.  Traffic is fast.  If still being
        forwarded by the backup path is
        longer then a sudden increase in delay will occur which can
        affect real time applications which use playback buffers to
        remove limited jitter. Backup Path functioning as the Working
        Path.

        Measurement units:
            n/a

        Issues:

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

     3.3.5.  Reversion

        Definition:
        The act of restoring failover recovery in which the Primary Path as becomes
        the Working Path. Path so that it is forwarding packets.

        Discussion:
        Protection Switching Systems may or may not support Reversion.
        Reversion, if supported, MUST occur after Failure Recovery. 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 [4] along the Primary Path
        and Backup Path are different, possibly causing 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

   3.4. Nodes

     3.4.1.  Protection-Switching Node

         Definition:
         A node that is capable to participate in a Protection Switching
         System.

         Discussion:
         The Protection Switching Node MAY be an ingress or egress for
         a Primary Path or Backup Path.

         Measurement units:
             n/a

         Issues:

         See Also:
             Protection Switching System
             Primary Path
             Backup Path

     3.4.2.  Non-Protection Switching Node

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

                          Protection Performance

         Discussion:

         Measurement units:
             n/a

         Issues:

         See Also:
             Protection Switching System
             Primary Path
             Backup Path

     3.4.3.  Failover Node

         Definition:
             A node along the Primary Path that is capable of Failover.

         Discussion:
             The Failover Node can be any node along the Primary Path
             except the egress node of the Primary Path.  There can be
             multiple Failover Nodes along a Primary Path.  The Failover
             Node MUST be the ingress to the Backup Path.  The Failover
             Node MAY also be the ingress of the Primary Path.

         Measurement units:
             n/a

         Issues:

         See Also:
             Primary Path
             Backup Path
             Failover

     3.4.4.  Merge Node

         Definition:
             A Node along the primary path where backup path terminates
. 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 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
                          Protection Performance

         Issues:

         See Also:
             Primary Path
             Backup Path
             PLR
             Failover

     3.4.5. Point of Local repair Repair (PLR)

         Definition:
         A node along the Primary Path that uses a Backup Path to
         protect another node or link.

         Discussion:
         Based on the functionality of the PLR, its role is defined
         based on the type of method used.  If the one-to-one backup
         method is used, the PLR is responsible for computing a
         separate Backup Path for each Primary Path.  In the case
         the facility backup method is used, the PLR creates a
         single Backup Path that can be used to protect multiple
         Primary Paths.

         Measurement units: n/a

         Issues:

         See Also:
             Primary Path
             Backup Path
             Failover

     3.4.6.  Head-end Failover Node

        Definition:
        A node that is ingress to along the Primary Path that is capable of Failover.

        Discussion:
        Based on the functionality of the Head-end, its role
        The Head-end Failover Node is
        defined to be as the ingress of the signaled LSP. It could
        also occur, that this node happens to be a PLR. In this
        scenario the term head-end failover node Backup
        Path. The Head-end Failover Node is defined. always a PLR

        Measurement units: n/a
                          Protection Performance

        Issues:

        See Also:
             Primary Path
             Backup Path
             Point of Local Repair
             Failover
                          Protection Performance

     3.5. Metrics  Benchmarks

      3.5.1.  Failover Packet Loss

        Definition:
        The amount of packet loss produced by a Failover Event until
        Failover completes.

        Discussion:
        Packet loss can be observed as a reduction of forwarded
        traffic from 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 and packets that were
        delayed due to buffering. 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

      3.5.2.   Reversion Packet Loss

        Definition:
        The amount of packet loss produced by Reversion. 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 and packets that were
        delayed due to buffering. lost, reordered, or delayed.
        Reversion Packet Loss MAY reach 100% of the offered load.

         Measurement units: Number of Packets

         Issues:  None

         See Also:
           Reversion
                          Protection Performance

      3.5.3.    Primary Path Latency Failover Time

        Definition:
             Latency [2] measured along the Primary Path.
         The amount of time it takes for Failover to successfully
         complete.

        Discussion:

         Measurement units:
           seconds

         Issues:  None

         See Also:
           Primary Path

      3.5.4.    Backup Path Latency

        Definition:
             Latency [2] measured along
        Failover Time can be calculated using the Backup Path.

         Discussion: 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:
             seconds
           milliseconds

        Issues: None

        See Also:
             Backup Path
                          Protection Performance

     3.6.  Benchmarks

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

      3.5.4.  Reversion Time

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

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

        Measurement units:
           Seconds
           milliseconds

        Issues: None

        See Also:
           Failover
           Failover Time
           Working
           Reversion
           Primary Path
           Backup
           Working Path
           Reversion Packet Loss
           Time-Based Loss Method (TBLM)
           Packet-Based Loss
           Packet-Loss Based Method (PBLM) (PLBM)
           Timestamp-Based Method (TBM)
                          Protection Performance

      3.6.2.

      3.5.5.  Additive Backup Latency Delay

        Definition:
        The amount of increased latency Forwarding Delay [4] resulting
        from data traffic traversing the Backup Path instead of
        the Primary Path.

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

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

        Measurement units:
             Seconds
           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

      3.6.3.  Reversion Time

        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-Based Loss Method (PBLM), or
        Timestamp-Based Method (TBM).  It is RECOMMENDED that the
        TBM is used.

        Measurement units:
           Seconds

        Issues: None

        See Also:
           Reversion
           Primary Path
           Working Path
           Reversion Packet Loss
           Time-Based Loss Method (TBLM)
           Packet-Based Loss Method (PBLM)
           Timestamp-Based Method (TBM)
                          Protection Performance

     3.7

     3.6 Failover Time Calculation Method

     3.7.1 Methods

     3.6.1 Time-Based Loss Method (TBLM)

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

      Discussion:
      Traffic generators
      The Tester MUST provide statistics which show the duration of
      failure on a time scale to granularity of milliseconds 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:

                          Protection Performance

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

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

      Measurement units:
             Milliseconds
         milliseconds

      Issues:
         None

      See Also:
         Failover
             Packet-Based Loss
         Packet-Loss Based Method

     3.7.2 Packet-Based Loss

     3.6.2 Packet-Loss Based Method (PBLM) (PLBM)

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

      Discussion:
      PLBM includes failure detection time and time for data traffic to
      begin traversing the Backup Path.  Failover Time can be
      calculated using PBLM is PLBM from the amount Failover Packet Loss that occurs due to a Failover Event and Failover as
      shown below in Equation 2: 3:

      (Equation 2) 3)
           (Equation 3a)
           PLBM Failover (or Reversion) Time =
              Number of packets drop/(rate per
            second lost /
                       (Offered Load rate * 1000) milliseconds

           Packet based loss method includes failure detection time and
           time for data traffic to begin traversing the Backup Path.

           (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
                          Protection Performance

     3.7.3

     3.6.3 Timestamp-Based Method (TBM)

      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 with granularity of
      milliseconds based on the observation of unimpaired packets,
      using Equation 3.

        (Equation 3)
        Failover (or Reversion) Time = Time2 - Time1

      where
      Time1 is the arrival time of the last unimpaired packet before
      the effects of Failover (or Reversion) are observed in 2 with the packet
      stream.

      Time2 is difference being that the arrival time of the first unimpaired packet
      following
      values are obtained from the observation of impaired packets due to Failover
      (or Reversion) timestamp in the packet stream. payload
      rather than from the Tester.

      Unimpaired packets are normal packets that are not lost,
      reordered, or duplicated.  A reordered packet is defined in
      [10, section 3.3].  A duplicate packet is defined in
      [4, section 3.3.3].  A lost packet is defined in
      [7, Section 3.5].  Unimpaired packets may be detected 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 may indicate 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
                          Protection Performance

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

5. IANA Considerations
     This document requires no IANA considerations.

6. Security Considerations
     This document only addresses terminology for the performance
     benchmarking of protection systems, and the information contained
     in this document has no effect on the security of the Internet.

7. References
7.1. Normative References
     [1] Bradner, S., "The Internet Standards Process -- Revision 3",
         RFC 2026, October 1996.

     [2] Bradner, S., Editor, "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., et al., "Terminology for Benchmarking
         Network-layer Traffic Control Mechanisms", RFC 4689,
         November 2006.

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

     [6] Paxson, V., et al., "Framework for IP Performance Metrics",
         RFC 2330, May 1998.

     [7] Poretsky, S., Imhoff, B., "Benchmarking Terminology for IGP
         Convergence", draft-ietf-bmwg-igp-dataplane-conv-term-13,
         work in progress, July 2007.

     [8] Pan., P. et al, "Fast Reroute Extensions to RSVP-TE for LSP
         Tunnels",
         Paths", RFC 4090, May 2005.

     [9] Nichols, K., et al, "Definition of the Differentiated
         Services Field (DS Field) in the IPv4 and IPv6 Headers",
         RFC 2474, December 1998.

     [10] Morton, A., et al, "Packet Reordering Metrics", RFC 4737,
          November 2006.

7.2. Informative References

     None
                          Protection Performance

8.  Author's Address

   Scott Poretsky
   Reef Point Systems
   8 New England Executive Park
   Burlington, MA 01803
   USA
   Phone: + 1 508 439 9008
   EMail: sporetsky@reefpoint.com

   Rajiv Papneja
   Isocore
   12359 Sunrise Valley Drive
   Reston, VA 22102
   USA
   Phone: 1 703 860 9273
   Email: rpapneja@isocore.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: vapiwala@cisco.com svapiwal@cisco.com

Full Copyright Statement

   Copyright (C) The IETF Trust (2007).

   This document is subject to the rights, licenses and restrictions
   contained in BCP 78, and except as set forth therein, the authors
   retain all their rights.

   This document and the information contained herein are provided
   on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
   REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE
   IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL
   WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY
   WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE
   ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS
   FOR A PARTICULAR PURPOSE.

                          Protection Performance

Intellectual Property

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at ietf-
   ipr@ietf.org.

Acknowledgement
   Funding for the RFC Editor function is currently provided by the
   Internet Society.