wdiff rfc6894.original rfc6894.txt

Network Working Group
Internet Engineering Task Force (IETF) R. Papneja
Internet-Draft
Request for Comments: 6894 Huawei Technologies
Intended status:
Category: Informational S. Vapiwala
Expires: May 28, 2013
ISSN: 2070-1721 J. Karthik
Cisco Systems
S. Poretsky
Allot Communications
S. Rao
Qwest Communications
JL. Le Roux
France Telecom
November 29, 2012
March 2013

Methodology for Benchmarking MPLS-TE MPLS Traffic Engineered (MPLS-TE)
Fast Reroute Protection
draft-ietf-bmwg-protection-meth-14.txt

Abstract

This draft document describes the methodology for benchmarking MPLS Fast
Reroute (FRR) protection mechanisms for link and node protection.
This document provides test methodologies and testbed setup for
measuring failover times of Fast Reroute techniques while considering
factors (such as underlying links) that might impact
recovery times for real-time applications bound to MPLS traffic
engineered Traffic
Engineered (MPLS-TE) tunnels.

Status of this This Memo

This Internet-Draft document is submitted in full conformance with the
provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents not an Internet Standards Track specification; it is
published for informational purposes.

This document is a product of the Internet Engineering Task Force
(IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list It represents the consensus of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.

Internet-Drafts are draft documents valid the IETF community. It has
received public review and has been approved for publication by the
Internet Engineering Steering Group (IESG). Not all documents
approved by the IESG are a maximum candidate for any level of six months Internet
Standard; see Section 2 of RFC 5741.

Information about the current status of this document, any
errata, and how to provide feedback on it may be updated, replaced, or obsoleted by other documents obtained at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."

This Internet-Draft will expire on May 9, 2013.
http://www.rfc-editor.org/info/rfc6894.

This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.

This document may contain material from IETF Documents or IETF
Contributions published or made publicly available before November
10, 2008. The person(s) controlling the copyright in some of this
material may not have granted the IETF Trust the right to allow
modifications of such material outside the IETF Standards Process.
Without obtaining an adequate license from the person(s) controlling
the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other
than English.

Table of Contents

1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 ....................................................3
2. Document Scope . . . . . . . . . . . . . . . . . . . . . . . . 6 ..................................................5
3. Existing Definitions and Requirements . . . . . . . . . . . . 6 ...........................5
4. General Reference Topology . . . . . . . . . . . . . . . . . . 7 ......................................6
5. Test Considerations . . . . . . . . . . . . . . . . . . . . . 8 .............................................7
5.1. Failover Events [RFC 6414] . . . . . . . . . . . . . . . . 8 ............................................7
5.2. Failure Detection [RFC 6414] . . . . . . . . . . . . . . . 9 ..........................................8
5.3. Use of Data Traffic for MPLS Protection benchmarking . . . 10 Benchmarking .......8
5.4. LSP and Route Scaling . . . . . . . . . . . . . . . . . . 10 ......................................9
5.5. Selection of IGP . . . . . . . . . . . . . . . . . . . . . 10 ...........................................9
5.6. Restoration and Reversion [RFC 6414] . . . . . . . . . . . 10 ..................................9
5.7. Offered Load . . . . . . . . . . . . . . . . . . . . . . . 11 ...............................................9
5.8. Tester Capabilities . . . . . . . . . . . . . . . . . . . 11 .......................................10
5.9. Failover Time Measurement Methods . . . . . . . . . . . . 12 .........................10
6. Reference Test Setup . . . . . . . . . . . . . . . . . . . . . 12 ...........................................11
6.1. Link Protection . . . . . . . . . . . . . . . . . . . . . 13 ...........................................12
6.1.1. Link Protection - 1 hop primary Protection: 1-Hop Primary (from PLR)
and 1
hop backup TE tunnels . . . . . . . . . . . . . . . . 13 1-Hop Backup Tail-End Tunnels ..................12
6.1.2. Link Protection - 1 hop primary Protection: 1-Hop Primary (from PLR)
and 2
hop backup TE tunnels . . . . . . . . . . . . . . . . 14 2-Hop Backup Tail-End Tunnels ..................13
6.1.3. Link Protection - 2+ hop Protection: 2-Hop (or More) Primary (from PLR) primary
and 1
hop backup TE tunnels . . . . . . . . . . . . . . . . 14 1-Hop Backup Tail-End Tunnels ..................14
6.1.4. Link Protection - 2+ hop Protection: 2-Hop (or More) Primary (from PLR) primary
and 2
hop backup TE tunnels . . . . . . . . . . . . . . . . 15 2-Hop Backup Tail-End Tunnels ..................15
6.2. Node Protection . . . . . . . . . . . . . . . . . . . . . 16 ...........................................16
6.2.1. Node Protection - 2 hop primary Protection: 2-Hop Primary (from PLR)
and 1
hop backup TE tunnels . . . . . . . . . . . . . . . . 16 1-Hop Backup Tail-End Tunnels ..................16
6.2.2. Node Protection - 2 hop primary Protection: 2-Hop Primary (from PLR)
and 2
hop backup TE tunnels . . . . . . . . . . . . . . . . 17 2-Hop Backup Tail-End Tunnels ..................17
6.2.3. Node Protection - 3+ hop primary Protection: 3-Hop (or More) Primary (from PLR)
and 1
hop backup TE tunnels . . . . . . . . . . . . . . . . 18 1-Hop Backup Tail-End Tunnels ..................18
6.2.4. Node Protection - 3+ hop primary Protection: 3-Hop (or More) Primary (from PLR)
and 2
hop backup TE tunnels . . . . . . . . . . . . . . . . 19 2-Hop Backup Tail-End Tunnels ..................19
7. Test Methodology . . . . . . . . . . . . . . . . . . . . . . . 20 ...............................................19
7.1. MPLS FRR MPLS-FRR Forwarding Performance . . . . . . . . . . . . . 20 ...........................20
7.1.1. Headend Head-End PLR Forwarding Performance . . . . . . . . . . 20 ................20
7.1.2. Mid-Point Midpoint PLR Forwarding Performance . . . . . . . . . 21 ................21
7.2. Headend Head-End PLR with Link Failure . . . . . . . . . . . . . . 23 ............................22
7.3. Mid-Point Midpoint PLR with Link Failure . . . . . . . . . . . . . 24 ............................24
7.4. Headend Head-End PLR with Node Failure . . . . . . . . . . . . . . 26 ............................25
7.5. Mid-Point Midpoint PLR with Node Failure . . . . . . . . . . . . . 27 ............................26
8. Reporting Format . . . . . . . . . . . . . . . . . . . . . . . 28 ...............................................27
9. Security Considerations . . . . . . . . . . . . . . . . . . . 30 ........................................29
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 30
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 30
12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 30
12.1. Informative ..............................................29
11. References . . . . . . . . . . . . . . . . . . 30
12.2. ....................................................29
11.1. Normative References . . . . . . . . . . . . . . . . . . . 30 .....................................29
11.2. Informative References ...................................30
Appendix A. Fast Reroute Scalability Table . . . . . . . . . . . 30 ........................31
Appendix B. Abbreviations . . . . . . . . . . . . . . . . . . . . 33
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 34 .........................................34

1. Introduction

This document describes the methodology for benchmarking MPLS Fast
Reroute (FRR) protection mechanisms. This document uses much of the
terminology defined in [RFC 6414]. [RFC6414].

Protection mechanisms provide recovery of client services from a
planned or an unplanned link or node failures. MPLS FRR failure. MPLS-FRR protection
mechanisms are generally deployed in a network infrastructure where
MPLS is used for the provisioning of point-to-point traffic
engineered tunnels (tunnel). MPLS FRR MPLS-FRR protection mechanisms aim to
reduce the service disruption period by minimizing recovery time from
most common failures.

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

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

Planned failures are generally 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 benchmarks
that a service provider considers in choosing the building blocks for
their network infrastructure.

A correlated failure is a result of the occurrence of two or more
failures. A typical example is failure of a logical resource (e.g.
layer-2 (e.g.,
Layer-2 (L2) links) due to a dependency on a common physical resource
(e.g.
(e.g., common conduit) that fails. Within the context of MPLS
protection mechanisms, failures that arise due to Shared Risk Link
Groups (SRLG) [RFC 4202] (SRLGs) [RFC4202] can be considered as correlated failures.

MPLS FRR [RFC 4090]

MPLS-FRR [RFC4090] allows for the possibility that the Label Switched
Paths (LSPs) can be re-optimized reoptimized in the minutes following Failover. failover.
IP Traffic traffic would be re-routed rerouted according to the preferred path for the
post-failure topology. Thus, MPLS-FRR may include additional steps
following the occurrence of the failure detection [RFC 6414] and failover event [RFC 6414].
[RFC6414].

(1) Failover Event - Primary Path (Working Path) path (working path) fails

(2) Failure Detection- Detection - Failover Event event is detected

(3)

(3a) Failover - Working Path path switched to Backup backup path

b. Re-Optimization

(3b) Reoptimization of Working Path working path (possible change from
Backup Path) backup
path)

(4) Restoration [RFC 6414] (see Section 3.3.5 of [RFC6414])

(5) Reversion [RFC 6414] (see Section 3.3.6 of [RFC6414])

2. Document Scope

This document provides detailed test cases along with different
topologies and scenarios that should be considered to effectively
benchmark MPLS FRR MPLS-FRR protection mechanisms and failover times on the
Data Plane.
data plane. Different Failover Events failover events and scaling considerations are
also provided in this document.

All benchmarking test-cases test cases defined in this document apply to
Facility
facility backup [RFC 4090]. [RFC4090]. The test cases cover a set of interesting
failure scenarios and the associated procedures benchmark the
performance of the Device Under Test (DUT) to recover from failures.
Data plane
Data-plane traffic is used to benchmark failover times. Testing
scenarios related to MPLS-TE protection mechanisms when applied to
MPLS Transport Profile and IP fast reroute applied to MPLS networks
were not considered and are out of outside the scope of this document.
However, the test setups considered for MPLS based Layer 3 MPLS-based L3 and
Layer 2 L2 services
consider LDP over MPLS RSVP-TE configurations.

Benchmarking of correlated failures is out of outside the scope of this
document. Detection using Bi-directional Bidirectional Forwarding Detection (BFD)
is outside the scope of this document, but it is mentioned in
discussion sections.

The Performance performance of the control plane is outside the scope of this
benchmarking.
document.

As described above, MPLS-FRR may include a Re-optimization reoptimization of the
Working Path,
working path, with possible packet transfer impairments.
Characterization of Re-optimization reoptimization is beyond the scope of this memo.

3. Existing Definitions and Requirements

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]. 14 [RFC2119].
While [RFC 2119] [RFC2119] defines the use of these key words primarily for
Standards Track documents however, documents, this Informational track document
may use uses some of uses
these keywords. key words.

The reader is assumed to be familiar with the commonly used MPLS
terminology, some of which is defined in [RFC 4090]. [RFC4090].

This document uses much of the terminology defined in [RFC 6414]. [RFC6414].
This document also uses existing terminology defined in other BMWG
Work [RFC 1242], [RFC 2285], [RFC 4689].
documents [RFC1242] [RFC2285] [RFC4689]. Appendix B provide provides
abbreviations used in the document document.

4. General Reference Topology

Figure 1 illustrates the general reference topology. It shows the
basic reference testbed and is applicable to all the test cases
defined in this document. The Tester is comprised of a Traffic
Generator (TG) & Test and Traffic Analyzer (TA) and Emulator. A Tester is
connected to the test network and and, depending upon the test case, the
DUT could vary. The Tester sends and receives IP traffic to the
tunnel ingress and performs signaling protocol emulation to simulate
real network scenarios in a lab environment. The Tester may also
support MPLS-TE signaling to act as the ingress node to the MPLS
tunnel. The lines in figures represent physical connections.

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

Fig.

Figure 1 Fast Reroute Topology

The tester MUST record the number of lost, duplicate, and out-of-order out-of-
order packets. It should further record arrival and departure times
so that Failover Time, 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.

The label stack is dependent of on the following 3 three entities:

(1) Type of protection (Link Vs versus Node)

(2) # Number of remaining hops of the primary tunnel from the PLR[RFC
6414] Point of
Local Repair (PLR) [RFC6414]

(3) # Number of remaining hops of the backup tunnel from the PLR

Due to this dependency, it is RECOMMENDED that the benchmarking of
failover times be performed on all the topologies provided in section Section
6.

5. Test Considerations

This section discusses the fundamentals of MPLS Protection testing:

(1) The types of network events that causes cause failover (section (Section 5.1)

(2) Indications for failover (section (Section 5.2)

(3) the The use of data traffic (section (Section 5.3)

(4) LSP Label Switched Path Scaling (Section 5.4)

(5) IGP Selection (Section 5.5)

(6) Reversion of LSP (Section 5.6)

(7) Traffic generation (section (Section 5.7)

5.1. Failover Events [RFC 6414]

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

Link Failure Events
- Interface Shutdown on PLR side with physical/link Alarm alarm
- Interface Shutdown on remote side with physical/link Alarm 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 (both Transmit (TX) and Receive (RX)
or just the TX)
- Fiber Pull on the remote side (Both (both TX & and RX or just the RX)
- Online insertion Insertion and removal Removal (OIR) on PLR side
- OIR on remote side
- Sub-interface failure on PLR side (e.g. (e.g., shutting down of a
VLAN)
- Sub-interface failure on remote side
- Parent interface shutdown on PLR side (an interface bearing
multiple sub-interfaces)
- Parent interface shutdown on remote side

Node Failure Events
- A System reload initiated either by either a graceful shutdown or by a
power failure. failure
- A system crash due to a software failure or an assert. assert

5.2. Failure Detection [RFC 6414]

Link failure detection [RFC6414] time depends on the link type and
failure detection protocols running. For SONET/SDH, Synchronous Optical Network
(SONET) / Synchronous Digital Hierarchy (SDH), the alarm type (such
as LOS, AIS, or RDI) can be used. Other link types have layer-two L2 alarms,
but they may not provide a short enough failure detection time. Ethernet based
Ethernet-based links enabled with MPLS/IP do not have layer 2 L2 failure indicators, and therefore relies
indicators; therefore, they rely on layer 3 L3 signaling for failure
detection. However However, for directly connected devices, remote fault
indication in the ethernet auto-negotiation scheme could be
considered as a type of layer 2 L2 link failure indicator.

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

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 Benchmarking

Currently, end customers use packet loss as a key metric for Failover
Time [RFC 6414]. failover
time [RFC6414]. Failover Packet Loss [RFC 6414] [RFC6414] is an externally
observable event and has a direct impact on application performance.
MPLS protection is expected to minimize the packet loss in the event of a
failure. For this reason 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 control-plane signaling to establish backup paths is
not enough to verify failover. Failover is best determined when
packets are actually traversing the backup path.

An additional benefit of using packet loss for calculation of
failover time is that it allows use of a black-box test environment.
Data traffic is offered at line-rate to the device under test (DUT) 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 [RFC 4689] [RFC4689] that could have been generated during the
failover process. The methodologies consider lost, out-of-order
[RFC 4689]
[RFC4689], and duplicate packets to be impaired packets that
contribute to the Failover Time. 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) LSPs and installed routes. However However, the
procedure outlined here should be used for any number of LSPs (L) and
any number of routes protected by PLR(R). the PLR (R). The
amount values 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 [RFC 6412] [RFC6412] for IGP options to consider and report.

5.6. Restoration and Reversion [RFC 6414]

Path restoration [RFC6414] provides a method to restore an alternate
primary LSP upon failure and to switch traffic from the Backup Path backup path
to the restored Primary Path (Reversion). primary path (reversion). In MPLS-FRR, Reversion reversion
[RFC6414] can be implemented as Global Reversion or Local Reversion.
It is important to include Restoration restoration and Reversion reversion as a step in
each test case to measure the amount of packet loss, out of order out-of-order
packets, or duplicate packets that is are produced.

Note: In addition to restoration and reversion, re-optimization reoptimization can
take place while the failure is still not recovered but it depends on
the user configuration, configuration and re-optimization reoptimization timers.

5.7. Offered Load

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

Prefix-dependency behaviors are key in IP IP, and tests with route-specific route-
specific flows spread across the routing table will reveal this
dependency. 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. Round-Robin traffic generation is
not recommended to all prefixes, as time to hit all the prefixes may
be higher than the failover time. This phenomenon will reduce the
granularity of the measured results results, and the results observed may not
be accurate.

5.8. Tester Capabilities

It is RECOMMENDED that the Tester used to execute each test case have
the following capabilities:

1.Ability

1. Ability to establish MPLS-TE tunnels and push/pop labels.

2.Ability

2. Ability to produce Failover Event [RFC 6414].

3.Ability a failover event [RFC6414].

3. Ability to insert a timestamp in each data packet's IP payload.

4.An

4. An internal time clock to control timestamping, time
measurements, and time calculations.

5.Ability

5. Ability to disable or tune specific Layer-2 L2 and Layer-3 L3 protocol
functions on any interface(s).

6.Ability interface.

6. Ability to react upon the receipt of path error from the PLR PLR.

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

5.9. Failover Time Measurement Methods

Failover Time time [RFC6414] is calculated using one of the following
three methods methods:

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

2. Time-Based Loss Method (TBLM): This method relies on the
ability of the Traffic traffic generators to provide statistics which that
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 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
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 two timestamps. Note: The payload could also
contain sequence numbers for out-of-order packet calculation
and duplicate packets.

The timestamp based method method

TBM would be able to detect Reversion reversion impairments beyond loss, thus loss; thus,
it is RECOMMENDED method as a Failover
Time the failover time method.

6. Reference Test Setup

In addition to the general reference topology shown in figure 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 tunnel.

This section proposes a set of topologies that covers all the
scenarios for local protection. All of these topologies can be
mapped to the reference topology shown in Figure 1. Topologies
provided in this section refer to the testbed required to benchmark
failover time when the DUT is configured as a PLR in either Headend head-end
or midpoint role. Provided with each topology below is the label
stack at the PLR. Penultimate Hop Popping (PHP) MAY be used and must
be reported when used.

Figures 2 thru through 9 use the following convention and are subset of
figure
Figure 1:

a) HE is Headend Head-End
b) TE T/E is Tail-End
c) MID is Mid point Midpoint
d) MP is Merge Point
e) PLR is Point of Local Repair
f) PRI is Primary Path
g) BKP denotes Backup Path and Nodes
h) UR is Upstream Router

6.1. Link Protection

6.1.1. Link Protection - 1 hop primary Protection: 1-Hop Primary (from PLR) and 1 hop backup TE
tunnels 1-Hop Backup
Tail-End Tunnels

+-------+ +--------+ +--------+
| R1 | | R2 | PRI| R3 |
| UR/HE |--| HE/MID |----| MP/TE MP/T/E |
| | | PLR |----| |
+-------+ +--------+ BKP+--------+

Figure 2. 2

Traffic Num No. of Labels Num No. of labels
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
Midpoint LSPs 0 0

Note:

Please note the following:

a) For the P-P case, R2 and R3 acts act as P routers
b) For the PE-PE case,R2 cases, R2 acts as a PE and R3 acts as a remote PE
c) For the PE-P case,R2 cases, R2 acts as a PE router, R3 acts as a P router router,
and R5 acts as a remote PE router (Please (please refer to figure Figure 1 for
complete setup)
d) For Mid-point the midpoint case, R1, R2 R2, and R3 act as shown in above figure HE, Midpoint/PLR midpoint/PLR, and
TE
tail-end, respectively (as shown in the figure above)

6.1.2. Link Protection - 1 hop primary Protection: 1-Hop Primary (from PLR) and 2 hop backup TE
tunnels 2-Hop Backup
Tail-End Tunnels

+-------+ +--------+ +--------+
| R1 | | R2 | | R3 |
| UR/HE | | HE/MID |PRI | MP/TE MP/T/E |
| |----| PLR |----| |
+-------+ +--------+ +--------+
|BKP |
| +--------+ |
| | R6 | |
|----| BKP |----|
| MID |
+--------+

Figure 3. 3

Traffic Num No. of Labels Num No. 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
Midpoint LSPs 0 1

Note:

Please note the following:

a) For the P-P case, R2 and R3 acts act as P routers
b) For PE-PE case,R2 cases, R2 acts as a PE and R3 acts as a remote PE
c) For PE-P case,R2 cases, R2 acts as a PE router, R3 acts as a P router router, and
R5 acts as a remote PE router (Please (please refer to figure Figure 1 for
complete setup)
d) For Mid-point the midpoint case, R1, R2 R2, and R3 act as shown in above figure HE, Midpoint/PLR midpoint/PLR, and TE
tail-end, respectively (as shown in the figure above)

6.1.3. Link Protection - 2+ hop Protection: 2-Hop (or More) Primary (from PLR) primary and 1 hop backup TE
tunnels 1-Hop
Backup Tail-End Tunnels

+--------+ +--------+ +--------+ +--------+
| R1 | | R2 |PRI | R3 |PRI | R4 |
| UR/HE |----| HE/MID |----| MP/MID |------| TE T/E |
| | | PLR |----| | | |
+--------+ +--------+ BKP+--------+ +--------+

Figure 4. 4

Traffic Num No. of Labels 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
Midpoint LSPs 1 1

Note:

Please note the following:

a) For the P-P case, R2, R3 R3, and R4 acts act as P routers
b) For PE-PE case,R2 cases, R2 acts as a PE and R4 acts as a remote PE c) For
PE-P case,R2 cases, R2 acts as a PE router, R3 acts as a P router router, and R5
acts as remote PE router (Please (please refer to figure Figure 1 for complete
setup)
d) For Mid-point the midpoint case, R1, R2, R3 R3, and R4 act as shown in above figure HE, Midpoint/PLR midpoint/PLR,
and TE tail-end, respectively (as shown in the figure above)

6.1.4. Link Protection - 2+ hop Protection: 2-Hop (or More) Primary (from PLR) primary and 2 hop backup TE
tunnels 2-Hop
Backup Tail-End Tunnels

+--------+ +--------+PRI +--------+ PRI +--------+
| R1 | | R2 | | R3 | | R4 |
| UR/HE |----| HE/MID |----| MP/MID|------| TE T/E |
| | | PLR | | | | |
+--------+ +--------+ +--------+ +--------+
BKP| |
| +--------+ |
| | R6 | |
+---| BKP |-
| MID |
+--------+

Figure 5. 5

Traffic Num No. of Labels Num No. 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
Midpoint LSPs 1 2

Note:

Please note the following:

a) For the P-P case, R2, R3 R3, and R4 acts act as P routers
b) For PE-PE case,R2 cases, R2 acts as a PE and R4 acts as a remote PE
c) For PE-P case,R2 cases, R2 acts as a PE router, R3 acts as a P router router, and
R5 acts as remote PE router (Please (please refer to figure Figure 1 for complete
setup)
d) For Mid-point the midpoint case, R1, R2, R3 and R4 act as shown in above figure HE, Midpoint/PLR midpoint/PLR,
and TE tail-end, respectively (as shown in the figure above)

6.2. Node Protection

6.2.1. Node Protection - 2 hop primary Protection: 2-Hop Primary (from PLR) and 1 hop backup TE
tunnels 1-Hop Backup
Tail-End Tunnels

+--------+ +--------+ +--------+ +--------+
| R1 | | R2 |PRI | R3 | PRI | R4 |
| UR/HE |----| HE/MID |----| MID |------| MP/TE MP/T/E |
| | | PLR | | | | |
+--------+ +--------+ +--------+ +--------+
|BKP |
-----------------------------

Figure 6. 6

Traffic Num No. of Labels Num No. 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
Midpoint LSPs 1 0

Note:

Please note the following:

a) For the P-P case, R2, R3 R3, and R3 acts R4 act as P routers
b) For PE-PE case,R2 cases, R2 acts as a PE and R4 acts as a remote PE
c) For PE-P case,R2 cases, R2 acts as a PE router, R4 acts as a P router router, and
R5 acts as remote PE router (Please (please refer to figure Figure 1 for complete
setup)
d) For Mid-point the midpoint case, R1, R2, R3 R3, and R4 act as shown in above figure HE, Midpoint/PLR midpoint/PLR,
and TE tail-end, respectively (as shown in the figure above)

6.2.2. Node Protection - 2 hop primary Protection: 2-Hop Primary (from PLR) and 2 hop backup TE
tunnels 2-Hop Backup
Tail-End Tunnels

+--------+ +--------+ +--------+ +--------+
| R1 | | R2 | | R3 | | R4 |
| UR/HE | | HE/MID |PRI | MID |PRI | MP/TE MP/T/E |
| |----| PLR |----| |----| |
+--------+ +--------+ +--------+ +--------+
| |
BKP| +--------+ |
| | R6 | |
---------| BKP |---------
| MID |
+--------+

Figure 7. 7

Traffic Num No. of Labels Num No. 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
Midpoint LSPs 1 1

Note:

Please note the following:

a) For the P-P case, R2, R3 R3, and R4 acts act as P routers
b) For PE-PE case,R2 cases, R2 acts as a PE and R4 acts as a remote PE
c) For PE-P case,R2 cases, R2 acts as a PE router, R4 acts as a P router router, and
R5 acts as remote PE router (Please (please refer to figure Figure 1 for complete
setup)
d) For Mid-point the midpoint case, R1, R2, R3 R3, and R4 act as shown in above figure HE, Midpoint/PLR midpoint/PLR,
and TE tail-end, respectively (as shown in the figure above)

6.2.3. Node Protection - 3+ hop primary Protection: 3-Hop (or More) Primary (from PLR) and 1 hop backup TE
tunnels 1-Hop
Backup Tail-End Tunnels

+--------+ +--------+PRI+--------+PRI+--------+PRI+--------+
| R1 | | R2 | | R3 | | R4 | | R5 |
| UR/HE |--| HE/MID |---| MID |---| MP |---| TE T/E |
| | | PLR | | | | | | |
+--------+ +--------+ +--------+ +--------+ +--------+
BKP| |
--------------------------

Figure 8. 8

Note:

Please note the following:

a) For the P-P case, R2, R3, R4 R4, and R5 acts act as P routers
b) For PE-PE case,R2 cases, R2 acts as a PE and R5 acts as a remote PE
c) For PE-P case,R2 cases, R2 acts as a PE router, R4 acts as a P router router, and
R5 acts as remote PE router (Please (please refer to figure Figure 1 for complete
setup)
d) For Mid-point the midpoint case, R1, R2, R3, R4 R4, and R5 act as shown in above figure HE,
Midpoint/PLR
midpoint/PLR, and TE tail-end, respectively (as shown in the figure
above)

6.2.4. Node Protection - 3+ hop primary Protection: 3-Hop (or More) Primary (from PLR) and 2 hop backup TE
tunnels 2-Hop
Backup Tail-End Tunnels

+--------+ +--------+ +--------+ +--------+ +--------+
| R1 | | R2 | | R3 | | R4 | | R5 |
| UR/HE | | HE/MID |PRI| MID |PRI| MP |PRI| TE T/E |
| |-- | PLR |---| |---| |---| |
+--------+ +--------+ +--------+ +--------+ +--------+
BKP| |
| +--------+ |
| | R6 | |
---------| BKP |-------
| MID |
+--------+

Figure 9. 9

Note:

Please note the following:

a) For the P-P case, R2, R3, R4 R4, and R5 acts act as P routers
b) For PE-PE case,R2 cases, R2 acts as a PE and R5 acts as a remote PE
c) For PE-P case,R2 cases, R2 acts as a PE router, R4 acts as a P router router,
and R5 acts as remote PE router (Please (please refer to figure Figure 1 for
complete setup)
d) For Mid-point the midpoint case, R1, R2, R3, R4 R4, and R5 act as shown in above figure HE,
Midpoint/PLR
midpoint/PLR, and TE tail-end, respectively (as shown in the
figure above)

7. Test Methodology

The procedure described in this section can be applied to all the 8 eight
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 (as seen with current deployments, deployments), it is
RECOMMENDED to perform all of the test cases provided in this
section. The forwarding performance test cases in section Section 7.1 MUST
be performed prior to performing the failover test cases.

The considerations of Section 4 of [RFC 2544] [RFC2544] are applicable when
evaluating the results obtained using these methodologies as well.

7.1. MPLS FRR MPLS-FRR Forwarding Performance

Benchmarking Failover Time [RFC 6414] failover time [RFC6414] for MPLS protection first
requires a baseline measurement of the forwarding performance of the
test topology topology, including the DUT. Forwarding performance is
benchmarked by the Throughput throughput as defined in [RFC 5695] [RFC5695] and measured in
units pps. of packets per second (pps). This section provides two test
cases to benchmark forwarding performance. These are with the DUT
configured as a
Headend head-end PLR, Mid-Point midpoint PLR, and Egress egress PLR.

7.1.1. Headend Head-End PLR Forwarding Performance

Objective:

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

Test Setup:

A. Select any one topology out of the 8 eight from section Section 6.

B. Select or enable IP, Layer 3 VPN L3 VPN, or Layer 2 L2 VPN services with the DUT
as Headend head-end PLR.

C. The DUT will also have 2 two interfaces connected to the traffic
Generator/analyzer.
generator/analyzer. (If the node downstream of the PLR is not
a simulated node, then the Ingress ingress of the tunnel should have
one link connected to the traffic generator generator, and the node
downstream to of 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 that primary and backup LSPs are up and that the
primary is protected.

4. Verify that Fast Reroute protection is enabled and ready.

5. Setup Set up traffic streams as described in section Section 5.7.

6. Send MPLS traffic over the primary LSP at the Throughput throughput
supported by the DUT (section 6, RFC 2544). (Section 6 of [RFC2544]).

7. Record the Throughput throughput over the primary LSP.

8. Trigger a link failure as described in section Section 5.1.

9. Verify that the offered load gets mapped to the backup tunnel
and measure the Additive Backup Delay (RFC 6414). [RFC6414].

10. 30 seconds after Failover, failover, stop the offered load and measure
the Throughput, Packet Loss, Out-of-Order Packets, throughput, packet loss, out-of-order packets, and
Duplicate Packets
duplicate packets over the Backup backup LSP.

11. Adjust the offered load and repeat steps 6 through 10 until
the Throughput throughput values for the primary and backup LSPs are
equal.

12. Record the final Throughput, throughput, which corresponds to the offered
load that will be used for the Headend head-end PLR failover test
cases.

7.1.2. Mid-Point Midpoint PLR Forwarding Performance

Objective:

To benchmark the maximum rate (pps) on the PLR (as mid-point) midpoint) over
the primary LSP and backup LSP.

Test Setup:

A. Select any one topology out of the 8 eight from section Section 6.

B. The DUT will also have 2 two interfaces connected to the traffic
generator.

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 that primary and backup LSPs are up and that the
primary is protected.

4. Verify that Fast Reroute protection is enabled and ready.

5. Setup Set up traffic streams as described in section Section 5.7.

6. Send MPLS traffic over the primary LSP at the Throughput throughput
supported by the DUT (section 6, RFC 2544). (Section 6 of [RFC2544]).

7. Record the Throughput throughput over the primary LSP.

8. Trigger a link failure as described in section Section 5.1.

9. Verify that the offered load gets mapped to the backup tunnel
and measure the Additive Backup Delay (RFC 6414). [RFC6414].

11. Adjust the offered load and repeat steps 6 through 10 until
the Throughput throughput values for the primary and backup LSPs are
equal.

12. Record the final Throughput throughput, which corresponds to the offered
load that will be used for the Mid-Point midpoint PLR failover test
cases.

7.2. Headend Head-End PLR with Link Failure

Objective:

To benchmark the MPLS failover time due to link failure events
described in section Section 5.1 experienced by the DUT DUT, which is the
Headend
head-end PLR.

Test Setup:

A. Select any one topology out of the 8 eight from section Section 6.

B. Select or enable IP, Layer 3 VPN L3 VPN, or Layer 2 L2 VPN services with the DUT
as Headend head-end PLR.

C. The DUT will also have 2 two interfaces connected to the traffic
Generator/analyzer.
generator/analyzer. (If the node downstream of the PLR is not
a simulated node, then the Ingress ingress of the tunnel should have
one link connected to the traffic generator 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. reversion.

3. Advertise prefixes (as per the FRR Scalability Table described in
Appendix A) by the tail end. tail-end.

Procedure:

Test Case "7.1.1. Headend

The test case in Section 7.1.1, "Head-End PLR Forwarding Performance"
Performance", MUST be completed first to obtain the Throughput 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 that primary and backup LSPs are up and that the
primary is protected.

4. Verify that Fast Reroute protection is enabled and ready.

5. Setup Set up traffic streams for the offered load as described in
section
Section 5.7.

6. Provide the offered load from the tester at the Throughput
[RFC 1242] throughput
[RFC1242] level obtained from the test case in Section 7.1.1.

7. Verify that traffic is switched over Primary the primary LSP without
packet loss.

8. Trigger a link failure as described in section Section 5.1.

9. Verify that the offered load gets mapped to the backup tunnel
and measure the Additive Backup Delay. Delay [RFC6414].

10. 30 seconds after Failover [RFC 6414], failover, stop the offered load and measure
the total Failover Packet Loss [RFC 6414]. failover packet loss [RFC6414].

11. Calculate the Failover Time [RFC 6414] failover time benchmark using the selected Failover Time Calculation Method
failover time calculation method (TBLM, PLBM, or TBM) [RFC 6414].
[RFC6414].

12. Restart the offered load and restore the primary LSP to
verify Reversion [RFC 6414] that reversion occurs and measure the Reversion Packet
Loss [RFC 6414]. [RFC6414].

13. Calculate the Reversion Time [RFC 6414] benchmark using the selected Failover Time Calculation Method
failover time calculation method (TBLM, PLBM, or TBM) [RFC 6414].
[RFC6414].

14. Verify Headend that the head-end signals new LSP and protection
should be in place again.

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

7.3. Mid-Point Midpoint PLR with Link Failure

Objective:

To benchmark the MPLS failover time due to link failure events
described in section Section 5.1 experienced by the DUT DUT, which is the Mid-
Point
midpoint PLR.

Test Setup:

A. Select any one topology out of the 8 eight from section Section 6.

B. The DUT will also have 2 two 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. reversion.

3. Advertise prefixes (as per the FRR Scalability Table described in
Appendix A) by the tail end. tail-end.

Procedure:

Test Case "7.1.2. Mid-Point

The test case in Section 7.1.2, "Midpoint PLR Forwarding Performance"
Performance", MUST be completed first to obtain the Throughput throughput to
use as the offered load.

1. Establish the primary LSP on R1 as required by the topology
selected.

2. Establish the backup LSP on R2 as required by the selected
topology.

3. Perform steps 3 through 14 from section 7.2 Headend Section 7.2, "Head-End PLR
with Link Failure.

IT Failure".

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

7.4. Headend Head-End PLR with Node Failure

Objective:

To benchmark the MPLS failover time due to Node node failure events
described in section Section 5.1 experienced by the DUT DUT, which is the
Headend
head-end PLR.

Test Setup:

A. Select any one topology out of the 8 eight from section Section 6.

B. Select or enable IP, Layer 3 VPN L3 VPN, or Layer 2 L2 VPN services with the DUT
as Headend head-end PLR.

C. The DUT will also have 2 two interfaces connected to the traffic
generator/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. reversion.

3. Advertise prefixes (as per the FRR Scalability Table described in
Appendix A) by the tail end. tail-end.

Procedure:

Test Case "7.1.1. Headend

The test case in Section 7.1.1, "Head-End PLR Forwarding Performance"
Performance", MUST be completed first to obtain the Throughput throughput to
use as the offered load.

1. Establish the primary LSP on R2 as required by the topology
selected.

2. Establish the backup LSP on R2 as required by the selected
topology.

3. Verify that the primary and backup LSPs are up and that the
primary is protected.

4. Verify that Fast Reroute protection is enabled and ready.

5. Setup Set up traffic streams for the offered load as described in
section
Section 5.7.

6. Provide the offered load from the tester at the Throughput
[RFC 1242] throughput
[RFC1242] level obtained from the test case in Section 7.1.1.

7. Verify that traffic is switched over Primary the primary LSP without
packet loss.

8. Trigger a node failure as described in section Section 5.1.

9. Perform steps 9 through 14 in 7.2 Headend Section 7.2, "Head-End PLR with
Link
Failure.

IT Failure".

It is RECOMMENDED that this procedure be repeated for each of the
node failure triggers defined in section Section 5.1.

7.5. Mid-Point Midpoint PLR with Node Failure

Objective:

To benchmark the MPLS failover time due to Node node failure events
described in section Section 5.1 experienced by the DUT DUT, which is the Mid-
Point
midpoint PLR.

Test Setup:

A. Select any one topology from section Sections 6.1 to 6.2.

B. The DUT will also have 2 two 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. reversion.

3. Advertise prefixes (as per the FRR Scalability Table described in
Appendix A) by the tail end. tail-end.

Procedure:

Test Case "7.1.1. Mid-Point

The test case in Section 7.1.1, "Midpoint PLR Forwarding Performance"
Performance", MUST be completed first to obtain the Throughput throughput to
use as the offered load.