Network Working Group                                     Rajiv                                        R. Papneja
Internet Draft                                                  Isocore
Intended Status: Informational                               S.Vapiwala
Expires: April 2, September 8, 2009                                     S. Vapiwala
                                                             J. Karthik
                                                          Cisco Systems

                                                            S. Poretsky
                                                   Allot Communications

                                                                 S. Rao
                                                   Qwest Communications
                                                     Jean-Louis

                                                           J.L. Le Roux
                                                         France Telecom
                                                       November 3, 2008

                                                          March 8, 2009

          Methodology for Benchmarking benchmarking MPLS Protection Mechanisms
                  draft-ietf-bmwg-protection-meth-04.txt protection mechanisms
                  draft-ietf-bmwg-protection-meth-05.txt

Status of this Memo

   By submitting this Internet-Draft, each author represents that
   any applicable patent or other IPR claims of which he or she
   This Internet-Draft is
   aware have been or will be disclosed, and any of which he or she
   becomes aware will be disclosed, submitted to IETF in accordance full conformance with Section 6 the
   provisions of BCP 78 and BCP 79.

   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
   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
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on April 3, September 8, 2009.

Abstract

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

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

                        Protection Mechanisms

Abstract
   This draft describes the methodology for benchmarking  MPLS
   Protection mechanisms for link and node protection as defined in
   [MPLS-FRR-EXT].  This document provides test methodologies and test
   bed
   testbed setup for measuring failover times while considering
   all dependencies that might impact faster recovery of real-time services
   applications bound to MPLS based traffic engineered tunnels.
   The benchmarking terms used in the procedures included in this document are defined in
   [TERM-ID].

Table of Contents

   1. Introduction...................................................3
   2. Document Scope.................................................4
   3. General reference sample topology..............................5
   4. Existing definitions...........................................5
   4. General Reference Topology.....................................5
   5. Test Considerations............................................6
   5.1. Failover Events..............................................6
   5.2. Failure Detection [TERM-ID]..................................7 Detection............................................7
   5.3. Use of Data Traffic for MPLS Protection benchmarking.........7 Benchmarking.........7
   5.4. LSP and Route Scaling........................................8
   5.5. Selection of IGP.............................................8
   5.6. Reversion [TERM-ID]..........................................8 Reversion....................................................8
   5.7. Traffic Generation...........................................8 Offered Load.................................................8
   5.8. Motivation for Topologies....................................9 Tester Capabilities..........................................9
   6. Reference Test Setup...........................................9
   6.1. Link Protection with 1 hop primary (from PLR) and 1 hop backup
   TE tunnels.......................................................10
   6.2. Link Protection with 1 hop primary (from PLR) and 2 hop backup
   TE tunnels.......................................................11
   6.3. Link Protection with 2+ hop (from PLR) primary and 1 hop backup
   TE tunnels.......................................................11
   6.4. Setups..........................................9
   6.1 Link Protection with 2+ hop (from PLR) primary and 2 hop backup
   TE tunnels.......................................................12
   6.5. Node Protection with 2 hop primary (from PLR) and 1 hop backup
   TE tunnels.......................................................12
   6.6. Node Protection with 2 hop primar (from PLR) and 2 hop backup
   TE tunnels.......................................................13
   6.7. Node Protection with 3+ hop primary (from PLR) and 1 hop backup
   TE tunnels.......................................................14
   6.8. Protection...............................................9
   6.2 Node Protection with 3+ hop primary (from PLR) and 2 hop backup
   TE tunnels.......................................................15 Protection..............................................13
   7. Test Methodology..............................................15 Methodologies............................................15
   7.1. MPLS FRR Forwarding Performance Test Cases..................15
   7.2. Headend as PLR with link failure............................15
   7.2. failure...............................17
   7.3. Mid-Point as PLR with link failure..........................17
   7.3. failure.............................18
   7.4. Headend as PLR with Node Failure............................18 Failure...............................19
                        Protection Mechanisms

   7.4.

   7.5. Mid-Point as PLR with Node failure..........................19
   7.5. MPLS FRR Forwarding Performance Test cases..................21
   7.5.1. PLR as Headend............................................21
   7.5.2. PLR as Mid-point..........................................22 Failure.............................21
   8. Reporting Format..............................................23
   Benchmarks.......................................................24
   9. Security Considerations.......................................25 Considerations.......................................24
   10. IANA Considerations..........................................25 Considerations..........................................24
   11. References...................................................25 References...................................................24
   11.1. Normative References.......................................25 References.......................................24
   11.2. Informative References.....................................25
   Author's Addresses...............................................26
   Intellectual Property Statement..................................27
   Disclaimer of Validity...........................................28
   Copyright Statement..............................................28 References.....................................24
   12. Acknowledgments..............................................28 Acknowledgments..............................................24
   Author's Addresses...............................................25
   Appendix A: Fast Reroute Scalability Table.......................28 Table.......................26
   Appendix B: Abbreviations........................................31 Abbreviations........................................38

1. Introduction

   This draft describes the methodology for benchmarking MPLS based
   protection mechanisms.  The new terminology that this document
   introduces is defined in [TERM-ID].

   MPLS based protection mechanisms provide fast recovery of real-time
   services from a planned or an unplanned link or node failures.
   MPLS protection mechanisms are generally deployed in a network
   infrastructure,
   infrastructure where MPLS is used for provisioning of point-to-
   point traffic engineered tunnels (tunnel).  MPLS based protection
   mechanisms  promises promise to improve service disruption period by
   minimizing recovery time from most common failures.

   Generally there two factors impacting service availability - one is
   frequency of failures,

   Network elements from different manufacturers behave differently to
   network failures, which impacts the network's ability and
   performance for failure recovery.  It therefore becomes imperative
   for service providers to have a common benchmark to understand the
   performance behaviors of network elements.

                        Protection Mechanisms

   There are two factors impacting service availability:
   frequency of failures and other being duration for which the failures last. persist.
   Failures can be classified further into two types-                                                                       - types: correlated and
   uncorrelated.  Correlated and uncorrelated failures. failures may be planned
   or unplanned.

   Planned failures are predictable.  Network implementations should
   be able to handle both planned and unplanned failures and recover
   gracefully within a time frame to maintain service assurance.
   Hence, failover recovery time is one of the most important benchmark
   that a service provider considers in choosing the building blocks
   for their network infrastructure.

   A Correlated correlated failure is the co- simultaneous occurrence
   of two or more failures simultaneously. failures. A typical example
   would be a is failure of a logical
   resource (e.g. layer-2 links), relying links) due to a dependency on a common
   physical resource  (e.g. common interface) conduit) that fails.  Within
   the context of MPLS protection mechanisms, failures that arise due
   to Shared Risk Link Groups (SRLG) [MPLS-FRR-EXT] can be considered
   as  correlations  failures  or. correlated failures.  Not all correlated failures are
                        Protection Mechanisms
   predictable in advance especially the ones advance, for example, those caused due to by natural
   disasters.

   Planned  failures

2. Document Scope

   This document provides detailed test cases along with different
   topologies and scenarios that should be considered to effectively
   benchmark MPLS protection mechanisms and failover times on the  other  hand  are  predictable
   Data Plane.   Different Failover Events and
   implementations should handle scaling considerations
   are also provided in this document.

   All benchmarking testcases defined in this document apply to both types of failures
   facility backup and local protection enabled in detour mode.  The
   test cases cover all possible failure scenarios and recover
   gracefully within the time frame acceptable for service assurance.
   Hence,
   associated procedures benchmark the performance of the Device
   Under Test (DUT) to recover from failures.  Data plane traffic is
   used to benchmark failover recovery time times.

   Benchmarking of correlated failures is one out of scope of this
   document.  Protection from Bi-directional Forwarding Detection
   (BFD) is outside the most important benchmark
   that a service provider considers scope of this document.

                        Protection Mechanisms

3. Existing definitions

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in choosing the building blocks
   for their network infrastructure.

   It is a known fact that network elements from different manufactures
   behave differently to network failures, which impact their ability this
   document are to recover from be interpreted as described in BCP 14, RFC 2119
   [Br97].  RFC 2119 defines the failures. It becomes imperative from network
   service  providers use of these key words to  have help make the
   intent of standards track documents as clear as possible.  While this
   document uses these keywords, this document is not a  common  benchmark,  which  could  be
   followed standards track
   document.

   The reader is assumed to  understand be familiar with the  performance  behaviors commonly used MPLS
   terminology, some of  network
   elements.

   Considering  failover  recovery  an  important  parameter,  the  test
   methodology presented which is defined in this [MPLS-FRR-EXT].

   This document considers the factors that
   may impact the failover times. To benchmark uses much of the failover times, data
   plane traffic is used as terminology defined in [IGP-METH].

   All benchmarking
   [TERM-ID].  This document also uses existing terminology defined
   in other BMWG work.  Examples include, but are not limited to:

             Throughput                [Ref.[Br91], section 3.17]
             Device Under Test (DUT)   [Ref.[Ma98], section 3.1.1]
             System Under Test (SUT)   [Ref.[Ma98], section 3.1.2]
             Out-of-order Packet       [Ref.[Po06], section 3.3.2]
             Duplicate Packet          [Ref.[Po06], section 3.3.3]

4. General Reference Topology

   Figure 1 illustrates the basic reference testbed and is applicable
   to all the test cases defined in this document apply document. The Tester is
   comprised of a Traffic Generator (TG) & Test Analyzer (TA). A
   Tester is directly connected to both
   facility backup and local protection enabled in detour mode. the DUT.  The
   test cases cover all possible failure scenarios Tester sends and
   receives IP traffic to the associated
   procedures benchmark the ability of the DUT tunnel ingress and performs signaling
   protocol emulation to perform recovery from
   failures within target failover time.

2. Document Scope

   This document provides detailed test cases along with different
   topologies and scenarios that should be considered to effectively
   benchmark MPLS protection mechanisms and failover times. Different
   failure simulate real network scenarios and scaling considerations are also provided in
   this document, in addition to reporting formats for the observed
   results.

   Benchmarking of unexpected correlated failures is currently out of
   scope of this document.

                        Protection Mechanisms

3. General reference sample topology

   Figure 1 illustrates the basic reference testbed and is applicable a lab
   environment. The Tester may also support MPLS-TE signaling to all act
   as the test cases defined in this document. TG & TA represents
   Traffic Generator & Analyzer respectively. A tester is connected ingress node to the DUT and it sends and receives IP traffic along with the working
   Path,  run  protocol  emulations  simulating  real  world  peering
   scenarios. The reference testbed shown in the figure MPLS tunnel.

         ---------------------------
        |               ------------|---------------
        |              |            |               |
        |              |            |               |
     --------       --------      --------      --------     --------
    TG-|
TG--|   R1   |-----|   R2   |----|   R3   |    |    R4  |   |  R5    |-TA    |
    |        |-----|        |----|        |----|        |---|        |
     --------       --------      --------      --------     --------
        |             |              |            |            |
        |             |              |            |            |
        |          --------          |            |           TA
         ---------|   R6   |--------   |---------             |
                  |        |--------------------        |----------------------
                   --------

                       Fig.1: Fast Reroute Topology.

                        Protection Mechanisms

   The tester MUST record the number of lost, duplicate, and reordered
   packets. It should further record arrival and departure times so
   that failover Failover Time, Additive Latency, and Reversion Time can be
   measured.  The tester may be a single device or a test system
   emulating all the different roles along a primary or backup path.

4. Existing definitions

   For

   The label stack is dependent of the sake following 3 entities:

       - Type of protection (Link Vs Node)
       - # of remaining hops of clarity and continuity this RFC adopts the template
   for definitions set out in Section 2 primary tunnel from the PLR
       - # of RFC 1242.  Definitions are
   indexed and grouped together in sections for ease remaining hops of reference. The
   terms used in this document are defined in detail in [TERM-ID].

                        Protection Mechanisms

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY", and "OPTIONAL" in
   this document is the backup tunnel from the PLR

   Due to be interpreted as described in RFC 2119.

   The reader this dependency, it is assumed to be familiar with RECOMMENDED that the commonly used MPLS
   terminology, some benchmarking of which is defined in [MPLS-FRR-EXT].

5. Test Considerations

   This
   failover times be performed on all the topologies provided in
   section 6.

5. Test Considerations

   This section discusses the fundamentals of MPLS Protection testing:

       -The types of network events that causes failover
       -Indications for failover
       -the use of data traffic
       -Traffic generation
       -LSP Scaling
       -Reversion of LSP
       -IGP Selection

5.1. Failover Events [TERM ID] [TERM-ID]

   The failover to the backup tunnel is primarily triggered by either
   link or node failures observed downstream of the Point of Local
   repair (PLR). Some of these failure events are listed below.

   Link failure events
       - Interface Shutdown on PLR side with POS Alarm
       - Interface Shutdown on remote side with POS Alarm
       - Interface Shutdown on PLR side with RSVP hello enabled
       - Interface Shutdown on remote side with RSVP hello enabled
       - Interface Shutdown on PLR side with BFD
       - Interface Shutdown on remote side with BFD
       - Fiber Pull on the PLR side (Both TX & RX or just the TX)
       - Fiber Pull on the remote side (Both TX & RX or just the RX)
       - Online insertion and removal (OIR) on PLR side
       - OIR on remote side
       - Sub-interface failure (e.g. shutting down of a VLAN)
       - Parent interface shutdown (an interface bearing multiple sub-
         interfaces
                        Protection Mechanisms

   Node failure events
       - A System reload is initiated either by a graceful shutdown or by
         a power failure.
       - A system crash is referred due to as a software failure or an assert.

       - Reload protected Node, when RSVP hello is enabled
       - Crash Protected Node, when RSVP hello is enabled
       - Reload Protected Node, when BFD is enable
       - Crash Protected Node, when BFD is enable

                        Protection Mechanisms

5.2. Failure Detection [TERM-ID]

   Link failure detection time depends on the link type and failure
   detection protocols running.  For SONET/SDH, the alarm type (such as
   LOS, AIS, or RDI) can be used.  Other link types have layer-two
   alarms, but they may not provide a short enough failure detection
   time. Ethernet based links do not have layer 2 failure indicators,
   and therefore relies on layer 3 signaling for failure detection.

   MPLS has different failure detection techniques such as BFD, or use
   of RSVP hellos.  These methods can be used for the layer 3 failure
   indicators required by Ethernet based links, or for some other non-
   Ethernet based links to help improve failure detection time.

   The test procedures in this document can be used for a local failure
   or remote failure scenarios for comprehensive benchmarking and to
   evaluate failover performance independent of the failure detection
   techniques.

5.3. Use of Data Traffic for MPLS Protection benchmarking

   Currently end customers use packet loss as a key metric for failover
   time.
   Failover Time [TERM-ID].  Failover Packet loss Loss [TERM-ID] is an
   externally observable event and has direct impact on customers' applications. application
   performance.  MPLS protection mechanism is expected to minimize the packet
   loss in the event of a failure.  For this reason it is important to
   develop a standard router benchmarking methodology for measuring
   MPLS protection that uses packet loss as a metric.  At a known rate
   of forwarding, packet loss can be measured and the failover time
   can be determined.  Measurement of control plane signaling to
   establish backup paths is not enough
                        Protection Mechanisms to verify failover. Failover
   is best determined when packets are actually traversing the backup
   path.

                        Protection Mechanisms

   An additional benefit of using packet loss for calculation of
   failover time is that it allows use of a black-box  tests test environment.
   Data traffic is offered at line-rate to the device under test (DUT), and (DUT)
   an emulated network failure event is forced to occur, and packet loss
   is externally measured to calculate the convergence time.  This setup
   is independent of the DUT architecture.

   In addition, this methodology considers the packets in error and
   duplicate packets that could have been generated during the failover
   process. In scenarios, where separate measurement of packets in
   error  The methodologies consider lost, out-of-order, and
   duplicate packets is difficult to obtain, these packets
   should be attributed impaired packets that contribute to lost packets. the
   Failover Time.

5.4. LSP and Route Scaling

   Failover time performance may vary with the number of established
   primary and backup tunnel label switched paths (LSP) and installed
   routes.  However the procedure outlined here should be used for
   any number of LSPs (L) and number of routes protected by PLR(R). Number
   The amount of L and R must be recorded.

5.5. Selection of IGP

   The underlying IGP could be ISIS-TE or OSPF-TE for the methodology
   proposed here.  See [IGP-METH] for IGP options to consider and
   report.

5.6. Restoration and Reversion [TERM-ID]

   Fast Reroute provides a method to return or restore a backup path to an original
   primary LSP upon recovery from the failure. This is
   referred failure (Restoration) and to as Reversion, which
   switch traffic from the Backup Path to the restored Primary Path
   (Reversion).  In MPLS-FRR, Reversion can be implemented as Global
   Reversion or Local Reversion. In all test cases listed here  It is important to include
   Restoration and Reversion should not produce any as a step in each test case to measure
   the amount of packet loss, out of order packets, or duplicate packets. Each of the test cases in this methodology
   document provides a check to confirm
   packets that there is no packet loss. produced.

5.7. Traffic Generation Offered Load

   It is suggested that there be one or more traffic streams as long as
   there is a steady and constant rate of flow for all the streams.  In
   order to monitor the DUT performance for recovery times times, a set of
   route prefixes should be advertised before traffic is sent.  The
   traffic should be configured towards these routes.

                        Protection Mechanisms

   A typical example would be configuring the traffic generator to send
   the traffic to the first, middle and last of the advertised routes.
   (First, middle and last could be decided by the numerically
                        Protection Mechanisms

   smallest, median and the largest respectively of the advertised
   prefix).  Generating traffic to all of the prefixes reachable by the
   protected tunnel (probably in a Round-Robin fashion, where the
   traffic is destined to all the prefixes but one prefix at a time in
   a  cyclic manner) is not recommended.  The reason why traffic
   generation is not recommended in a Round-Robin fashion to all the
   prefixes, one at a time is that if there are many prefixes reachable
   through the LSP the time interval between 2 packets destined to one
   prefix may be significantly high and may be comparable with the
   failover time being measured which does not aid in getting an
   accurate failover measurement.

5.8. Motivation for Topologies

   Given

5.8 Tester Capabilities

   It is RECOMMENDED that the label stack is dependent of Tester used to execute each test case
   have the following 3 entities
   it  is  recommended  that  the  benchmarking  of  failover capabilities:
      1. Ability to establish MPLS-TE tunnels and push/pop labels.
      2. Ability to produce Failover Event [TERM-ID].
      3. Ability to insert a timestamp in each data packet's IP
         payload.
      4. An internal time  be
   performed clock to control timestamping, time
         measurements, and time calculations.
      5. Ability to disable or tune specific Layer-2 and Layer-3
         protocol functions on all any interface(s).

    The Tester MAY be capable to make non-data plane convergence
    observations and use those observations for measurements.

6. Reference Test Setup

   In addition to the 8 topologies provided general reference topology shown in section 4

       - Type of protection (Link Vs Node)

       - # of remaining hops of the primary tunnel from the PLR

       - # of remaining hops of the backup tunnel from the PLR

6. Reference Test Setup

   In addition to the general reference topology shown in figure 1,
   this figure 1,
   this section provides detailed insight into various proposed test
   setups that should be considered for comprehensively benchmarking
   the failover time in different roles along the primary tunnel:

   This section proposes a set of topologies that covers all the
   scenarios for local protection. All of these 8 topologies shown
   (figure 2- figure 9) can be
   mapped to the reference topology shown in figure Figure 1.  Topologies
   provided in sections 4.1 to 4.8 this section refer to
   test-bed the testbed required to
   benchmark failover time when the DUT is configured as a PLR in
   either headend Headend or midpoint role. The labels stack
   provided  Provided with each topology
   below is the label stack at the PLR.

   The label stacks shown below each figure in section 4.1 to 4.9
   considers enabling of  Penultimate Hop
   Popping (PHP). (PHP) MAY be used and must be reported when used.

                        Protection Mechanisms

   Figures 2-9 uses 2 thru 9 use the following convention:

   a) HE is Headend
   b) TE is Tail-End
   c) MID is Mid point
   d) MP is Merge Point
   e) PLR is Point of Local Repair
   f) PRI is Primary Path
   g) BKP denotes Backup Node Path and Nodes

6.1. Link Protection with

6.1.1 Link Protection - 1 hop primary (from PLR) and 1 hop backup TE
   tunnels

             -------    -------- PRI  --------
            |  R1   |  |   R2   |    |   R3   |
         TG-|  HE   |--|  MID   |----|    TE  |-TA
            |       |  |  PLR   |----|        |
             -------    -------- BKP  --------

                          Figure 2: Represents the setup for section 4.1 2.

       Traffic            No            Num of Labels      No     Num of labels after
                          before failure    after failure
       IP TRAFFIC (P-P)       0             0
       Layer3 VPN (PE-PE)     1             1
       Layer3 VPN (PE-P)      2             2
       Layer2 VC (PE-PE)      1             1
       Layer2 VC (PE-P)       2             2
       Mid-point LSPs         0             0
                        Protection Mechanisms

6.2.

6.1.2. Link Protection with - 1 hop primary (from PLR) and 2 hop backup TE
   tunnels

           -------      --------      --------
          |  R1   |    |  R2    |    |   R3   |
       TG-|  HE   |    |  MID   |PRI |   TE   |-TA
          |       |----|  PLR   |----|        |
           -------      --------      --------
                           |BKP               |
                           |     --------     |
                           |    |   R6   |    |
                           |----|  BKP   |----|
                                |   MID  |
                                 --------

                                 Figure 3: Representing setup for section 4.2 3.

       Traffic            No            Num of Labels      No     Num of labels
                          before failure    after failure
       IP TRAFFIC (P-P)       0              1
       Layer3 VPN (PE-PE)     1              2
       Layer3 VPN (PE-P)      2              3
       Layer2 VC (PE-PE)      1              2
       Layer2 VC (PE-P)       2              3
       Mid-point LSPs         0              1

6.3.

6.1.3. Link Protection with - 2+ hop (from PLR) primary and 1 hop backup TE
   tunnels

           --------      --------      --------        --------
          |  R1    |    | R2     |PRI |   R3   |PRI   |   R4   |
       TG-|  HE    |----| MID    |----| MID    |------|   TE   |-TA
          |        |    | PLR    |----|        |      |        |
           --------      -------- BKP  --------        --------

                                Figure 4: Representing setup for section 4.3 4.

       Traffic            No            Num of Labels      No     Num of labels
                          before failure    after failure
                        Protection Mechanisms
       IP TRAFFIC (P-P)       1                1
       Layer3 VPN (PE-PE)     2                2
       Layer3 VPN (PE-P)      3                3
       Layer2 VC (PE-PE)      2                2
       Layer2 VC (PE-P)       3                3
       Mid-point LSPs         1                1

6.4.
                        Protection Mechanisms

6.1.4. Link Protection with - 2+ hop (from PLR) primary and 2 hop backup TE
   tunnels

           --------      -------- PRI  --------  PRI   --------
          |  R1    |    |  R2    |    |   R3   |      |   R4   |
       TG-|   HE   |----| MID    |----|  MID   |------|   TE   |-TA
          |        |    | PLR    |    |        |      |        |
           --------      --------      --------        --------
                        BKP|              |
                           |    --------  |
                           |   |   R6   | |
                            ---|  BKP   |-
                               |  MID   |
                                --------

                                Figure 5: Representing the setup for section 4.4 5.

       Traffic            No            Num of Labels      No     Num of labels
                          before failure    after failure

       IP TRAFFIC (P-P)       1              2
       Layer3 VPN (PE-PE)     2              3
       Layer3 VPN (PE-P)      3              4
       Layer2 VC (PE-PE)      2              3
       Layer2 VC (PE-P)       3              4
       Mid-point LSPs         1              2

6.5.
                        Protection Mechanisms

6.2. Node Protection with

6.2.1. Node Protection - 2 hop primary (from PLR) and 1 hop backup TE
   tunnels
                        Protection Mechanisms

           --------      --------      --------        --------
          |  R1    |    |  R2    |PRI |   R3   | PRI  |   R4   |
       TG-|   HE   |----|  MID   |----|  MID   |------|  TE    |-TA
          |        |    |  PLR   |    |        |      |        |
           --------      --------      --------        --------
                          |BKP                          |
                           -----------------------------

                             Figure 6: Representing the setup for section 4.5 6.

       Traffic            No            Num of Labels      No     Num of labels
                          before failure    after failure

       IP TRAFFIC (P-P)       1             0
       Layer3 VPN (PE-PE)     2             1
       Layer3 VPN (PE-P)      3             2
       Layer2 VC (PE-PE)      2             1
       Layer2 VC (PE-P)       3             2
       Mid-point LSPs         1             0

6.6.

6.2.2. Node Protection with - 2 hop primary (from PLR) and 2 hop backup TE
   tunnels

           --------      --------      --------      --------
          |  R1    |    |  R2    |    |   R3   |    |   R4   |
       TG-|  HE    |    |  MID   |PRI |  MID   |PRI |  TE    |-TA
          |        |----|  PLR   |----|        |----|        |
           --------      --------      --------      --------
                          |                            |
                       BKP|          --------          |
                          |         |   R6   |         |
                           ---------|  BKP   |---------
                                    |  MID   |
                                     --------

                             Figure 7: Representing setup for section 4.6 7.

                        Protection Mechanisms

       Traffic            No            Num of Labels      No     Num of labels
                          before failure    after failure

       IP TRAFFIC (P-P)       1             1
       Layer3 VPN (PE-PE)     2             2
       Layer3 VPN (PE-P)      3             3
       Layer2 VC (PE-PE)      2             2
       Layer2 VC (PE-P)       3             3
       Mid-point LSPs         1             1

6.7.

6.2.3. Node Protection with - 3+ hop primary (from PLR) and 1 hop backup TE
   tunnels

       --------    -------- PRI -------- PRI -------- PRI --------
      |  R1    |  |  R2    |   |   R3   |   |   R4   |   |   R5   |
   TG-|   HE   |--|  MID   |---| MID    |---|  MP    |---|  TE    |-TA
      |        |  |  PLR   |   |        |   |        |   |        |
       --------    --------     --------     --------     --------
                  BKP|                          |
                      --------------------------

                              Figure 8: Representing setup for section 4.7 8.

       Traffic            No            Num of Labels      No     Num of labels
                          before failure    after failure

       IP TRAFFIC (P-P)       1             1
       Layer3 VPN (PE-PE)     2             2
       Layer3 VPN (PE-P)      3             3
       Layer2 VC (PE-PE)      2             2
       Layer2 VC (PE-P)       3             3
       Mid-point LSPs         1             1
                        Protection Mechanisms

6.8.

6.2.4. Node Protection with - 3+ hop primary (from PLR) and 2 hop backup TE
   tunnels

    --------     --------     --------     --------     --------
   |  R1    |   |  R2    |   |   R3   |   |   R4   |   |   R5   |
TG-|  HE    |   |   MID  |PRI|  MID   |PRI|  MP    |PRI|  TE    |-TA
   |        |-- |  PLR   |---|        |---|        |---|        |
    --------     --------     --------     --------     --------
                 BKP|                          |
                    |          --------        |
                    |         |  R6    |       |
                     ---------|  BKP   |-------
                              |  MID   |
                               --------

                             Figure 9: Representing setup for section 4.8 9.

       Traffic            No            Num of Labels      No     Num of labels
                          before failure    after failure

       IP TRAFFIC (P-P)       1             2
       Layer3 VPN (PE-PE)     2             3
       Layer3 VPN (PE-P)      3             4
       Layer2 VC (PE-PE)      2             3
       Layer2 VC (PE-P)       3             4
       Mid-point LSPs         1             2

7. Test Methodology

   The procedure described in this section can be applied to all the 8
   base test cases and the associated topologies. The backup as well as
   the primary tunnels are configured to be alike in terms of bandwidth
   usage. In order to benchmark failover with all possible label stack
   depth applicable as seen with current deployments, it is suggested
   that RECOMMENDED
   to perform all of the test cases provided in this section.  The
   forwarding performance test cases in section 7.1 MUST be performed
   prior to performing the failover test cases.

                        Protection Mechanisms

7.1. MPLS FRR Forwarding Performance

   Benchmarking Failover Time [TERM-ID] for MPLS protection first
   requires baseline measurement of the forwarding performance of the
   test topology including the DUT.  Forwarding performance is
   benchmarked by the metric Throughput as defined in [Br91] and
   measured in units pps.  This section provides two test cases to
   benchmark forwarding performance.  These are with the DUT
   configured as a Headend PLR, Mid-Point PLR, and Egress PLR.

7.1.1. Headend PLR Forwarding Performance

   Objective

   To benchmark the maximum rate (pps) on the PLR (as headend) over
   primary LSP and backup LSP.

   Test Setup

     - Select any one topology out of the 8 from section 6.
     - Select overlay technologies (e.g. IGP, VPN, or VC) with DUT
       as Headend PLR.
     - The DUT will also have 2 interfaces connected to the traffic
       Generator/analyzer. (If the node downstream of the PLR is not
       A simulated node, then the Ingress of the tunnel should have
       one link connected to the traffic generator and the node
       downstream to the PLR or the egress of the tunnel should have
       a link connected to the traffic analyzer).

    Procedure

      1. Establish the primary LSP on R2 required by the topology
         selected.
      2. Establish the backup LSP on R2 required by the selected
         topology.
      3. Verify primary and backup LSPs are up and that primary is
         protected.
      4. Verify Fast Reroute protection is enabled and ready.
      5. Setup traffic streams as described in section 5.7.
      6. Send MPLS traffic over the primary LSP at the Throughput
         supported by the DUT.
      7. Record the Throughput over the primary LSP.
      8. Trigger a link failure as described in section 5.1.
      9. Verify that the offered load gets mapped to the backup tunnel
         and measure the Additive Backup Delay.
      10. 30 seconds after Failover, stop the offered load and
          measure the Throughput, Packet Loss, Out-of-Order Packets,
          and Duplicate Packets over the Backup LSP.
      11. Adjust the offered load and repeat steps 6 through 10 until
          the Throughput values for the primary and backup LSPs are
          equal.
      12. Record the Throughput.  This is the methodology includes all offered load that will be
          used for the scenarios listed here

7.1. Headend as PLR with link failure

   Objective failover test cases.

                        Protection Mechanisms

7.1.2. Mid-Point PLR Forwarding Performance

   Objective

   To benchmark the MPLS failover time due to Link failure events
   described in section 3.1 experienced by the DUT which is maximum rate (pps) on the point
   of local repair (PLR). PLR (as mid-point) over
   primary LSP and backup LSP.

   Test Setup

     - Select any one topology out of 8 from section 4 6.
     - Select overlay technology for FRR test e.g. IGP,VPN,or VC technologies (e.g. IGP, VPN, or VC) with DUT
       as Mid-Point PLR.
     - The DUT will also have 2 interfaces connected to the traffic
       Generator/analyzer. (If the node downstream of the PLR is not
       A simulated node, then the Ingress of the tunnel should have
       one link connected to the traffic generator and the node
       downstream to the PLR or the egress of the tunnel should have
       a link connected to the traffic analyzer).

   Test Configuration

      1. Configure the number of primaries on R2 and the backups on R2
           as required by the topology selected.
      2. Advertise prefixes (as per FRR Scalability table describe
           in Appendix A) by the tail end.
       generator.

   Procedure

      1. Establish the primary LSP on R2 R1 required by the topology
         selected.
      2. Establish the backup LSP on R2 required by the selected
         topology.
      3. Verify primary and backup LSPs are up and that primary is
         protected.
      4. Verify Fast Reroute protection is enabled and ready.
      5. Setup traffic streams as described in section 3.7. 5.7.
      6. Send IP MPLS traffic over the primary LSP at maximum Forwarding Rate to the Throughput
         supported by the DUT.
      7. Verify traffic switched Record the Throughput over Primary the primary LSP.
      8. Trigger any choice of Link a link failure as describe described in section 3.1. 5.1.
      9. Verify that primary tunnel and prefixes the offered load gets mapped to the backup
         tunnels.
         tunnel and measure the Additive Backup Delay.
      10. Stop traffic stream 30 seconds after Failover, stop the offered load and
          measure the Throughput, Packet Loss, Out-of-Order Packets,
          and Duplicate Packets over the Backup LSP.
      11. Adjust the offered load and repeat steps 6 through 10 until
          the Throughput values for the primary and measure backup LSPs are
          equal.
      12. Record the traffic loss.
      11. Failover time Throughput.  This is calculated as defined in section 6, Reporting
         format.

                        Protection Mechanisms

      12. Start traffic stream again to verify reversion when protected
         interface comes up. Traffic loss should be 0 due to make
         before break or reversion.
      13. Enable protected interface that was down (Node in the case of
         NNHOP).
      14. Verify headend signals new LSP and protection should offered load that will
          be in
         place again.

7.2. used for the Mid-Point as PLR with link failure failover test cases.

                        Protection Mechanisms

7.1.3. Egress PLR Forwarding Performance

   Objective

   To benchmark the MPLS failover time due to Link failure events
   described in section 3.1 experienced by the device under test which
   is maximum rate (pps) on the point of local repair (PLR). PLR (as egress) over
   primary LSP and backup LSP.

   Test Setup

     - Select any one topology out of 8 from section 4 6.
     - Select overlay technology for FRR test technologies (e.g. IGP, VPN, or VC) with DUT
       as Mid-Point LSPs Egress PLR.
     - The DUT will also have 2 interfaces connected to the traffic
       generator.

   Test Configuration

      1. Configure the number of primaries on R1 and the backups on R2
           as required by the topology selected.
      2. Advertise prefixes (as per FRR Scalability table describe in
           Appendix A) by the tail end.

   Procedure

      1. Establish the primary LSP on R1 required by the topology
         selected.
      2. Establish the backup LSP on R2 required by the selected
         topology.
      3. Verify primary and backup LSPs are up and that primary is
         protected.

                        Protection Mechanisms
      4. Verify Fast Reroute protection. protection is enabled and ready.
      5. Setup traffic streams as described in section 3.7. 5.7.
      6. Send IP MPLS traffic over the primary LSP at maximum Forwarding Rate to the Throughput
         supported by the DUT.
      7. Verify traffic switched Record the Throughput over Primary the primary LSP.
      8. Trigger any choice of Link a link failure as describe described in section 3.1. 5.1.
      9. Verify that primary tunnel and prefixes the offered load gets mapped to the backup
         tunnels.
      10. Stop traffic stream
         tunnels and measure the traffic loss.
      11. Failover time is calculated as per defined in section 6,
         Reporting format.
      12. Start traffic stream again to verify reversion when protected
         interface comes up. Traffic loss should be 0 due to make
         before break or reversion.
      13. Enable protected interface that was down (Node in Additive Backup Delay..
      10. 30 seconds after Failover, stop the case of
         NNHOP).
      14. Verify headend signals new LSP offered load and protection should
          measure the Throughput, Packet Loss, Out-of-Order Packets,
          and Duplicate Packets over the Backup LSP.
      11. Adjust the offered load and repeat steps 6 through 10 until
          the Throughput values for the primary and backup LSPs are
          equal.
      12. Record the Throughput.  This is the offered load that will be in
         place again.

7.3.
          used for the Egress PLR failover test cases.

7.2. Headend as PLR with Node Link Failure

   Objective

   To benchmark the MPLS failover time due to Node link failure events
   described in section 3.1 5.1 experienced by the device under test, DUT which is the point of local repair (PLR).
   Headend PLR.

   Test Setup

     - Select any one topology out of 8 from section 4.5 to 4.8 6
     - Select overlay technology for FRR test e.g. IGP, VPN, or VC (e.g. IGP,VPN,or VC).

                        Protection Mechanisms

     - The DUT will also have 2 interfaces connected to the traffic
       generator.
       Generator/analyzer. (If the node downstream of the PLR is not
       A simulated node, then the Ingress of the tunnel should have
       one link connected to the traffic generator and the node
       downstream to the PLR or the egress of the tunnel should have
       a link connected to the traffic analyzer).

   Test Configuration

      1. Configure the number of primaries on R2 and the backups on R2
           as required by the topology selected.
      2. Configure the test setup to support Reversion.
      3. Advertise prefixes (as per FRR Scalability table describe Table described
           in Appendix A) by the tail end.

      Procedure
                        Protection Mechanisms
      Test Case "7.1.1. Headend PLR Forwarding Performance" MUST be
      completed first to obtain the Throughput to use as the offered
      load.

      1. Establish the primary LSP on R2 required by the topology
         selected.
      2. Establish the backup LSP on R2 required by the selected
         topology.
      3. Verify primary and backup LSPs are up and that primary is
         protected.
      4. Verify Fast Reroute protection. protection is enabled and ready.
      5. Setup traffic streams for the offered load as described
         in section 3.7. 5.7.
      6. Send IP traffic Provide the offered load from the tester at maximum Forwarding Rate to DUT. the Throughput
         [Br91] level obtained from test case 7.1.1.
      7. Verify traffic is switched over Primary LSP. LSP without packet
         loss.
      8. Trigger any choice of Node a link failure as describe described in section 3.1. 5.1.
      9. Verify that primary tunnel and prefixes the offered load gets mapped to the backup
         tunnels
         tunnel and measure the Additive Backup Delay.
      10. Stop traffic stream 30 seconds after Failover [TERM-ID], stop the offered
          load and measure the traffic loss. total Failover Packet Loss [TERM-ID].
      11. Calculate the Failover time is calculated as per defined in section 6,
         Reporting format. Time [TERM-ID] benchmark using the
          selected Failover Time Calculation Method (TBLM, PLBM, or
          TBM) [TERM-ID].
      12. Start traffic stream again Restart the offered load and restore the primary LSP to
          verify reversion when protected
         interface comes up. Traffic loss should be 0 due to make
         before break or reversion. Reversion [TERM-ID] occurs and measure the Reversion
          Packet Loss [TERM-ID].
      13. Boot protected Node that was down. Calculate the Reversion Time [TERM-ID] benchmark using the
          selected Failover Time Calculation Method (TBLM, PLBM, or
          TBM) [TERM-ID].
      14. Verify headend Headend signals new LSP and protection should be in
          place again.

7.4.

      IT is RECOMMENDED that this procedure be repeated for each of
      the link failure triggers defined in section 5.1.

                        Protection Mechanisms

7.3. Mid-Point as PLR with Node link failure

   Objective

   To benchmark the MPLS failover time due to Node link failure events
   described in section 3.1 5.1 experienced by the device under test, DUT which
   is the point of local repair (PLR). Mid-Point PLR.

   Test Setup

     - Select any one topology out of 8 from section 4.5 to 4.8. 6
     - Select overlay technology for FRR test as Mid-Point LSPs. LSPs
     - The DUT will also have 2 interfaces connected to the traffic
       generator.

   Test Configuration
                        Protection Mechanisms

      1. Configure the number of primaries on R1 and the backups on R2
           as required by the topology selected.
      2. Configure the test setup to support Reversion.
      3. Advertise prefixes (as per FRR Scalability table describe in
           Appendix A) by the tail end.

   Procedure

      1. Establish the primary LSP on R1 required by the topology
         selected.
      2. Establish the backup LSP on R2 required by the selected
         topology.
      3. Verify primary and backup LSPs are up and that primary is
         protected.
      4. Verify Fast Reroute protection.
      5. Setup traffic streams as Table described in section 3.7.
      6. Send IP traffic at maximum Forwarding Rate to DUT.
      7. Verify traffic switched over Primary LSP.
      8. Trigger any choice of Node failure as describe in section 3.1.
      9. Verify that primary tunnel and prefixes gets mapped to backup
         tunnels.
      10. Stop traffic stream and measure the traffic loss.
      11. Failover time is calculated as per defined in section 6,
         Reporting format.
      12. Start traffic stream again to verify reversion when protected
         interface comes up. Traffic loss should be 0 due to make
         before break or reversion.
      13. Boot protected Node that was down.
      14. Verify headend signals new LSP and protection should be in
         place again.

                        Protection Mechanisms

7.5. MPLS FRR Forwarding Performance Test cases

     For
           Appendix A) by the following MPLS FRR Forwarding Performance Benchmarking
     cases, tail end.

   Procedure
      Test Case "7.1.2. Mid-Point PLR Forwarding Performance" MUST be
      completed first to obtain the maximum PPS rate allowed Throughput to use as the offered
      load.

      1. Establish the primary LSP on R1 required by given hardware. One
     may follow the topology
         selected.
      2. Establish the backup LSP on R2 required by the selected
         topology.
      3. Perform steps 3 through 14 from section 7.2 Headend PLR
         with Link Failure.

      IT is RECOMMENDED that this procedure be repeated for determining MPLS forwarding
     performance each of
      the link failure triggers defined in [MPLS-FORWARD]

7.5.1. PLR as section 5.1.

                        Protection Mechanisms

7.4. Headend PLR with Node Failure

   Objective

   To benchmark the maximum rate (pps) on MPLS failover time due to Node failure events
   described in section 5.1 experienced by the PLR (as headend) over
   primary FRR LSP and backup LSP. DUT which is the
   Headend PLR.

   Test Setup

     - Select any one topology out of 8 from section 4. 6.5 to 6.8
     - Select overlay technology for FRR test e.g. IGP,VPN,or VC. (e.g. IGP, VPN, or VC)
     - The DUT will also have 2 interfaces connected to the traffic
       Generator/analyzer. (If the node downstream of the PLR is not
       A simulated node, then
       generator.

   Test Configuration

     1.  Configure the Ingress number of primaries on R2 and the tunnel should have
       one link connected to backups on R2
          as required by the traffic generator and topology selected.
     2.  Configure the node
       downstream test setup to support Reversion.
     3.  Advertise prefixes (as per FRR Scalability table describe in
          Appendix A) by the tail end.

   Procedure

      Test Case "7.1.1. Headend PLR or the egress of Forwarding Performance" MUST be
      completed first to obtain the tunnel should have
       a link connected Throughput to use as the traffic analyzer).

    Procedure offered
      load.

      1. Establish the primary LSP on R2 required by the topology
         selected.
      2. Establish the backup LSP on R2 required by the selected
         topology.
      3. Verify primary and backup LSPs are up and that primary is
         protected.
      4. Verify Fast Reroute protection is enabled and ready. protection.
      5. Setup traffic streams for the offered load as described
         in section 3.7. 5.7.
      6. Send IP traffic Provide the offered load from the tester at maximum forwarding rate (pps) that the
         device under Throughput
         [Br91] level obtained from test supports over the primary LSP. case 7.1.1.
      7. Record maximum PPS rate forwarded over primary LSP. Verify traffic is switched over Primary LSP without packet
         loss.
      8. Stop traffic stream.
      9. Trigger any choice of Link a node failure as describe described in section 3.1.

                        Protection Mechanisms

      10. Verify that primary tunnel and prefixes gets mapped to backup
         tunnels.
      11. Send IP traffic at maximum forwarding rate (pps) 5.1.
      9. Perform steps 9 through 14 in 7.2 Headend PLR with Link
         Failure.

      IT is RECOMMENDED that this procedure be repeated for each of
      the
         device under test supports over the primary LSP.
      12. Record maximum PPS rate forwarded over backup LSP.

7.5.2. node failure triggers defined in section 5.1.

                        Protection Mechanisms

7.5. Mid-Point PLR as Mid-point with Node failure

   Objective

   To benchmark the maximum rate (pps) on the PLR (as mid-point of MPLS failover time due to Node failure events
   described in section 5.1 experienced by the
   primary path and ingress of DUT which is the backup path) over primary FRR LSP
   and backup LSP.
   Mid-Point PLR.

   Test Setup

     - Select any one topology out of 8 from section 4. 6.5 to 6.8.
     - Select overlay technology for FRR test as Mid-Point LSPs.
     - The DUT will also have 2 interfaces connected to the traffic
       generator.

   Test Configuration

      1. Configure the number of primaries on R1 and the backups on
           R2 as required by the topology selected.
      2. Configure the test setup to support Reversion.
      3. Advertise prefixes (as per FRR Scalability table describe in
           Appendix A) by the tail end.

   Procedure

      Test Case "7.1.2. Mid-Point PLR Forwarding Performance" MUST be
      completed first to obtain the Throughput to use as the offered
      load.

      1. Establish the primary LSP on R1 required by the topology
         selected.
      2. Establish the backup LSP on R2 required by the selected
         topology.
      3. Verify primary and backup LSPs are up and that primary is
         protected.
      4. Verify Fast Reroute protection is enabled and ready. protection.
      5. Setup traffic streams for the offered load as described
         in section 3.7. 5.7.
      6. Send IP traffic Provide the offered load from the tester at maximum forwarding rate (pps) that the
         device under Throughput
         [Br91] level obtained from test supports over the primary LSP. case 7.1.1.
      7. Record maximum PPS rate forwarded Verify traffic is switched over primary LSP. Primary LSP without packet
         loss.
      8. Stop traffic stream.
      9. Trigger any choice of a node failure as described in section 5.1.
      9. Perform steps 9 through 14 in 7.2 Headend PLR with Link
         Failure.

      IT is RECOMMENDED that this procedure be repeated for each of
      the node failure as describe triggers defined in section 3.1.
      10. Verify that primary tunnel and prefixes gets mapped to backup
         tunnels.
      11. Send IP traffic at maximum forwarding rate (pps) that the
         device under test supports over the backup LSP. 5.1.

                        Protection Mechanisms

      12. Record maximum PPS rate forwarded over backup LSP.

8. Reporting Format

   For each test, it is recommended that the results be reported in the
   following format.

        Parameter                          Units

        IGP used for the test              ISIS-TE/ OSPF-TE

        Interface types                    Gige,POS,ATM,VLAN etc.

        Packet Sizes offered to the DUT    Bytes

        Forwarding rate                    Number of                    packets per second

        IGP routes advertised              Number of IGP routes

        Penultimate Hop Popping            Used/Not Used

        RSVP hello timers configured                  Milliseconds
        (if any)

        Number of FRR tunnels              Number of tunnels
        configured

        Number of VPN routes installed     Number of VPN routes
        on the headend Headend

        Number of VC tunnels               Number of VC tunnels

        Number of BGP routes               BGP routes installed

        Number of mid-point tunnels        Number of tunnels

        Number of Prefixes protected by    Number of LSPs
        Primary

        Topology being used                Section number, and
                                           figure reference
                        Protection Mechanisms

        Failure event

        Failover Event                     Event type
                        Protection Mechanisms

   Benchmarks

        Parameter                 Unit

        Minimum failover time     Milliseconds

        Mean failover time        Milliseconds

        Maximum failover time     Milliseconds

        Minimum reversion time    Milliseconds

        Mean reversion time       Milliseconds

        Maximum reversion time    Milliseconds (to be recorded for each test case):

   Failover-
       Failover time Time                        seconds
       Failover Packet Loss                 packets
       Additive Backup Delay                seconds
       Out-of-Order Packets                 packets
       Duplicate Packets                    packets

   Reversion-
       Reversion Time                       seconds
       Reversion Packet Loss                packets
       Additive Backup Delay                seconds
       Out-of-Order Packets                 packets
       Duplicate Packets                    packets

   Failover Time suggested above is calculated using one of the
   following three methods

      1. Packet-Based Loss method (PBLM): (Number of packets
        dropped/packets per second * 1000) milliseconds. This method
        could also be referred as Rate Derived method.

      2. Time-Based Loss Method (TBLM): This method relies on the
        ability of the Traffic generators to provide statistics which
        reveal the duration of failure in milliseconds based on when
        the packet loss occurred (interval between non-zero packet loss
        and zero loss).

      3. Timestamp Based Method (TBM): This method of failover
        calculation is based on the timestamp that gets transmitted as
        payload in the packets originated by the generator. The Traffic
        Analyzer records the timestamp of the last packet received
        before the failover event and the first packet after the
        failover and derives the time based on the difference between
        these 2 timestamps. Note: The payload could also contain
        sequence numbers for out-of-order packet calculation and
        duplicate packets.

   Note: If the primary is configured to be dynamic, and if the primary
   is to reroute, make before break should occur from the backup that
                        Protection Mechanisms
   is in use to a new alternate primary. If there is any packet loss
   seen, it should be added to failover time.

                        Protection Mechanisms

9. Security Considerations

   During the course
   Documents of test, this type do not directly affect the test topology must be disconnected
   from security of
   Internet or corporate networks as long as benchmarking is not
   performed on devices that may forward the test traffic into a or systems connected to production
   environment.

   There are no specific security considerations within networks.
   Security threats and how to counter these in SIP and the scope media
   layer is discussed in RFC3261, RFC3550, and RFC3711 and various
   other drafts.  This document attempts to formalize a set of
   this document.
   common methodology for benchmarking performance of failover
   mechanisms in a lab environment.

10. IANA Considerations

   There are
   This document requires no considerations for IANA at this time. considerations.

11.  References

11.1. Normative Informative References

   [MPLS-FRR-EXT]   Pan, P., Atlas, A., Swallow, G., "Fast Reroute
                    Extensions to RSVP-TE for LSP Tunnels", RFC 4090.
      NONE

11.2. Informative Normative References

   [TERM-ID] Poretsky S., Papneja R., Karthik J., Vapiwala S.,
             "Benchmarking Terminology for Protection Performance", draft-ietf-bmwg-protection-term-
                    05.txt,
             draft-ietf-bmwg-protection-term-06.txt, work in
             progress.

   [MPLS-FRR-EXT] Pan P., Swallow G., Atlas A., "Fast Reroute
             Extensions to RSVP-TE for LSP Tunnels'', Tunnels", RFC 4090.

   [IGP-METH] S. Poretsky, B. Imhoff, "Benchmarking Methodology
              for IGP Data Plane Route Convergence, draft-ietf-
                    bmwg-igp-dataplane-conv-meth-16.txt, "draft-ietf-
              bmwg-igp-dataplane-conv-meth-17.txt", work in progress.

   [MPLS-FORWARD]   A. Akhter, and R. Asati, ''MPLS Forwarding

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

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

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

   [Po06] Poretsky, S., et al., "Terminology for Benchmarking Methodology,'' draft-ietf-bmwg-mpls-
                    forwarding-meth-00.txt, work
         Network-layer Traffic Control Mechanisms", RFC 4689,
         November 2006.

12. Acknowledgments

   We would like to thank Jean Philip Vasseur for his invaluable input
   to the document and Curtis Villamizar his contribution in progress. suggesting
   text on definition and need for benchmarking Correlated failures.
   Additionally we would like to thank Al Morton, Arun Gandhi,
   Amrit Hanspal, Karu Ratnam, Raveesh Janardan, Andrey Kiselev, and
   Mohan Nanduri for their formal reviews of this document.

                        Protection Mechanisms

Author's Addresses

   Rajiv Papneja
   Isocore
   12359 Sunrise Valley Drive, STE 100
   Reston, VA 20190
   USA
   Phone: +1 703 860 9273
   Email: rpapneja@isocore.com

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

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

   Scott Poretsky
   Allot Communications
   67 South Bedford Street, Suite 400
   Burlington, MA 01803
   USA
   Phone: + 1 +1 508 309 2179
   EMail: sporetsky@allot.com

   Shankar Rao
   Qwest Communications,
   950 17th Street
   Suite 1900
                        Protection Mechanisms
   Qwest Communications
   Denver, CO 80210
   USA
   Phone: + 1 303 437 6643
   Email: shankar.rao@qwest.com

   Jean-Louis Le Roux
   France Telecom
   2 av Pierre Marzin
   22300 Lannion
   France
   Phone: 00 33 2 96 05 30 20
   Email: jeanlouis.leroux@orange-ft.com

Intellectual Property Statement

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

Disclaimer

   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.

Full Copyright Statement

   Copyright (C) The IETF Trust (2008).

   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.

12. Acknowledgments

   We would like to thank Jean Philip Vasseur for his invaluable input
   to the document and Curtis Villamizar his contribution in suggesting
   text on definition and need for benchmarking Correlated failures.

   Additionally we would like to thank Arun Gandhi, Amrit Hanspal, Karu
   Ratnam and for their input to the document.

Appendix A: Fast Reroute Scalability Table

   This section provides the recommended numbers for evaluating the
   scalability of fast reroute implementations. It also recommends the
   typical numbers for IGP/VPNv4 Prefixes, LSP Tunnels and VC entries.
   Based on the features supported by the device under  test, test (DUT),
   appropriate scaling limits can be used for the test bed.

                        Protection Mechanisms

   A 1.

   A1. FRR IGP Table

        No. of Headend TE Tunnels       IGP Prefixes

        1                               100

        1                               500

        1                               1000

        1                               2000

        1                               5000

        2 (Load Balance)                100

        2 (Load Balance)                500

        2 (Load Balance)                1000

        2 (Load Balance)                2000

        2 (Load Balance)                5000

        100                             100

        500                             500

        1000                            1000

        2000                            2000
                        Protection Mechanisms

A 2. FRR VPN Table

        No. of Headend TE Tunnels       VPNv4 Prefixes

        1                               100

        1                               500

        1                               1000

        1                               2000

        1                               5000

        1                               10000

        1                               20000

        1                               Max

        2 (Load Balance)                100

        2 (Load Balance)                500

        2 (Load Balance)                1000

        2 (Load Balance)                2000

        2 (Load Balance)                5000

        2 (Load Balance)                10000

        2 (Load Balance)                20000

        2 (Load Balance)                Max

   A 3. FRR Mid-Point LSP Table

   No of Mid-point TE LSPs could be configured at recommended levels -
   100, 500, 1000, 2000, or max supported number.

                        Protection Mechanisms

   A 4.   FRR VC Table

        No. of Headend TE Tunnels       VC entries

        1                               100
        1                               500
        1                               1000
        1                               2000
        1                               Max
        100                             100
        500                             500
        1000                            1000
        2000                            2000

Appendix B: Abbreviations

   BFD      - Bidirectional Fault Detection
   BGP      - Border Gateway protocol
   CE       - Customer Edge
   DUT      - Device Under Test
   FRR      - Fast Reroute
   IGP      - Interior Gateway Protocol
   IP       - Internet Protocol
   LSP      - Label Switched Path
   MP       - Merge Point
   MPLS     - Multi Protocol Label Switching
   N-Nhop   - Next - Next Hop
   Nhop     - Next Hop
   OIR      - Online Insertion and Removal
   P        - Provider
   PE       - Provider Edge
   PHP      - Penultimate Hop Popping
   PLR      - Point of Local Repair
                        Protection Mechanisms
   RSVP     - Resource reSerVation Protocol
   SRLG     - Shared Risk Link Group
   TA       - Traffic Analyzer
   TE       - Traffic Engineering
   TG       - Traffic Generator
   VC       - Virtual Circuit
   VPN      - Virtual Private Network