draft-ietf-bmwg-protection-meth-00.txt   draft-ietf-bmwg-protection-meth-01.txt 
Network Working Group R. Papneja Network Working Group R. Papneja
Internet Draft Isocore Internet Draft Isocore
Expires: March 2007 S.Vapiwala Intended status: Informational S.Vapiwala
J.Karthik Expires: August 2007 J.Karthik
Cisco Systems Cisco Systems
S. Poretsky S. Poretsky
Reef Point Reef Point
S. Rao S. Rao
Qwest Communications Qwest Communications
Jean-Louis Le Roux Jean-Louis Le Roux
France Telecom France Telecom
October 06 February 23, 2007
Methodology for benchmarking MPLS Protection mechanisms Methodology for benchmarking MPLS Protection mechanisms
<draft-ietf-bmwg-protection-meth-00.txt> <draft-ietf-bmwg-protection-meth-01.txt>
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that By submitting this Internet-Draft, each author represents that
any applicable patent or other IPR claims of which he or she is any applicable patent or other IPR claims of which he or she is
aware have been or will be disclosed, and any of which he or she aware have been or will be disclosed, and any of which he or she
becomes aware will be disclosed, in accordance with Section 6 of becomes aware will be disclosed, in accordance with Section 6 of
BCP 79. BCP 79.
This document may only be posted in an Internet-Draft. This document may only be posted in an Internet-Draft.
skipping to change at page 2, line 5 skipping to change at page 1, line 45
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at 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 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 August 23, 2007.
Copyright Notice
Poretsky, Rao, Le Roux Poretsky, Rao, Le Roux
Protection Mechanisms Protection Mechanisms
Copyright (C) The IETF Trust (2007).
Abstract Abstract
This draft provides the methodology for benchmarking MPLS Protection This draft describes the methodology for benchmarking MPLS Protection
mechanisms especially the failover time of local protection (MPLS Fast mechanisms for link and node protection as defined in [MPLS-FRR-EXT].
Reroute as defined in RFC-4090). The failover to a backup tunnel could The benchmarking and terminology [TERM-ID] are to be used for
happen at the headend of the primary tunnel or a midpoint and the backup benchmarking MPLS based protection mechanisms [MPLS-FRR-EXT]. This
could offer link or node protection. It becomes vital to benchmark the document provides test methodologies and test-bed setup for measuring
failover time for all the cases and combinations. The failover time failover times while considering all dependencies that might impact
could also greatly differ based on the design and implementation and by faster recovery of real time services riding on MPLS based primary
factors like the number of prefixes carried by the tunnel, the routing tunnel. The terms used in the procedures included in this document are
protocols that installed these prefixes (IGP, BGP...), the number of defined in [TERM-ID].
primary tunnels affected by the event that caused the failover, number
of primary tunnels the backup protects and type of failure, the physical
media type on which the failover occurs etc. All the required
benchmarking criteria and benchmarking topology required for measuring
failover time of local protection is described Conventions used in this
document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119]. document are to be interpreted as described in RFC-2119 [RFC-WORDS].
Table of Contents Table of Contents
1. Introduction...................................................3 1. Introduction...................................................3
2. Existing definitions...........................................6 2. Existing definitions...........................................6
3. Test Considerations............................................6 3. Test Considerations............................................6
3.1. Failover Events...........................................6 3.1. Failover Events...........................................6
3.2. Failure Detection [TERMID]................................7 3.2. Failure Detection ........................................7
3.3. Use of Data Traffic for MPLS Protection Benchmarking......7 3.3. Use of Data Traffic for MPLS Protection Benchmarking......8
3.4. LSP and Route Scaling.....................................8 3.4. LSP and Route Scaling.....................................8
3.5. Selection of IGP..........................................8 3.5. Selection of IGP..........................................8
3.6. Reversion [TERMID]........................................8 3.6. Reversion ................................................9
3.7. Traffic generation........................................9 3.7. Traffic generation........................................9
3.8. Motivation for topologies.................................9 3.8. Motivation for topologies.................................9
4. Test Setup.....................................................9 4. Test Setup....................................................10
4.1. Link Protection with 1 hop primary (from PLR) and 1 hop 4.1. Link Protection with 1 hop primary (from PLR) and 1 hop
backup........................................................10 backup........................................................11
TE tunnels....................................................10 TE tunnels....................................................11
4.2. Link Protection with 1 hop primary (from PLR) and 2 hop 4.2. Link Protection with 1 hop primary (from PLR) and 2 hop
backup TE tunnels.............................................11 backup TE tunnels.............................................11
4.3. Link Protection with 2+ hop (from PLR) primary and 1 hop 4.3. Link Protection with 2+ hop (from PLR) primary and 1 hop
backup TE tunnels.............................................11 backup TE tunnels.............................................12
4.4. Link Protection with 2+ hop (from PLR) primary and 2 hop
backup TE tunnels.............................................12
Poretsky, Rao, Le Roux Poretsky, Rao, Le Roux
Protection Mechanisms Protection Mechanisms
4.4. Link Protection with 2+ hop (from PLR) primary and 2 hop
backup TE tunnels.............................................12
4.5. Node Protection with 2 hop primary (from PLR) and 1 hop 4.5. Node Protection with 2 hop primary (from PLR) and 1 hop
backup TE tunnels.............................................13 backup TE tunnels.............................................13
4.6. Node Protection with 2 hop primary (from PLR) and 2 hop 4.6. Node Protection with 2 hop primary (from PLR) and 2 hop
backup TE tunnels.............................................13
4.7. Node Protection with 3+ hop primary (from PLR) and 1 hop
backup TE tunnels.............................................14 backup TE tunnels.............................................14
4.7. Node Protection with 3+ hop primary (from PLR) and 1 hop
backup TE tunnels.............................................15
4.8. Node Protection with 3+ hop primary (from PLR) and 2 hop 4.8. Node Protection with 3+ hop primary (from PLR) and 2 hop
backup TE tunnels.............................................15 backup TE tunnels.............................................15
4.9. Baseline MPLS Forwarding Performance Test Topology.......15
5. Test Methodology..............................................16 5. Test Methodology..............................................16
5.1. Headend as PLR with link failure.........................16 5.1. Headend as PLR with link failure.........................17
5.2. Mid-Point as PLR with link failure.......................17 5.2. Mid-Point as PLR with link failure.......................18
5.3. Headend as PLR with Node failure.........................18 5.3. Headend as PLR with Node failure.........................19
5.4. Mid-Point as PLR with Node failure.......................20 5.4. Mid-Point as PLR with Node failure.......................20
5.5. Baseline MPLS Forwarding Performance Test Cases..........21 5.5. MPLS FRR Forwarding Performance Test Cases...............22
5.5.1. DUT Throughput as Ingress...........................21 5.5.1. PLR as Headend......................................22
5.5.2. DUT Latency as Ingress..............................21 5.5.2. PLR as Mid-point....................................23
5.5.3. DUT Throughput as Egress............................22
5.5.4. DUT Latency as Egress...............................22
5.5.5. DUT Throughput as Mid-Point.........................23
5.5.6. DUT Latency as Mid-Point............................23
6. Reporting Format..............................................24 6. Reporting Format..............................................24
7. Security Considerations.......................................25 7. Security Considerations.......................................25
8. Acknowledgements..............................................25 8. Acknowledgements..............................................26
9. References....................................................25 9. References....................................................26
9.1. Normative References.....................................25 9.1. Normative References.....................................26
9.2. Informative References...................................26 9.2. Informative References...................................26
10. Author's Address.............................................26 10. Author's Address...................Error! Bookmark not defined.
Appendix A: Fast Reroute Scalability Table.......................29 Appendix A: Fast Reroute Scalability Table.......................30
1. Introduction 1. Introduction
A link or a node failure could occur at the headend or the mid point This draft describes the methodology for benchmarking MPLS based
node of a given primary tunnel. The time it takes to failover to the protection mechanisms. The new terminology that it introduces is defined
backup tunnel is a key measurement since it directly affects the traffic in [TERM-ID].
carried over the tunnel. The failover could occur at the headend or the
midpoint of a primary tunnel and the time it takes to failover depends MPLS based protection mechanisms provide faster recovery of real time
on a variety of factors like the type of physical media, method of FRR services in case of an unplanned link or node failure in the network
solution (detour vs facility), number of primary tunnels, number of core, where MPLS is used as a signaling protocol to setup point-to-point
prefixes carried over the tunnel etc. Given all this service providers traffic engineered tunnels. MPLS based protection mechanisms improve
certainly like to see a methodology to measure the failover time under service availability by minimizing the duration of the most common
all possible conditions. failures. There are generally two factors impacting service
availability. One is the frequency and the other is the duration of the
failure. Unexpected correlated failures are less common. Correlated
failures mean co-occurrence of two or more failures simultaneously.
These failures are often observed when two or more logical resources
Poretsky, Rao, Le Roux Poretsky, Rao, Le Roux
Protection Mechanisms Protection Mechanisms
(for e.g. layer-2 links), relying on a common physical resource (for
e.g. common transport) fail. Common transport may include TDM and WDM
links providing multiplexing at layer-2 and layer-1. Within the context
of MPLS protection mechanisms, Shared Risk Link Groups [MPLS-FRR-EXT]
encompass correlations failures.
The following sections describe all the different topologies and Not all correlated failures can be anticipated in advance of their
scenarios that should be used and considered to effectively benchmark occurrence. Failures due to natural disasters or planned failures are
the failover time. The failure triggers, procedures, scaling the most notable causes. Due to the frequent occurrences of such
considerations and reporting format of the results are discussed as failures, it is necessary that implementations can handle these faults
well. gracefully, and recover the services affected by failures very quickly.
In order to benchmark failover time, data plane traffic is used as Some routers recover faster as compared to the others, hence
mentioned in [IGP-METH] since traffic loss is measured in a black-box benchmarking this type of failures become very useful. Benchmarking of
test and is a widely accepted way to measure convergence. unexpected correlated failures should include measurement of
restoration with and without the availability of IP fallback. This
document provides detailed test cases focusing on benchmarking MPLS
protection mechanisms. Benchmarking of unexpected correlated failures
is currently out of scope of this document.
Important point to be noted when benchmarking the failover time is that A link or a node failure could occur either at the head-end or at the
depending on whether PHP is happening (whether or not implicit null is mid point node of a primary tunnel. The backup tunnel could offer either
advertised by the tail-end), and on the number of hops of primary and link or node protection following a failure along the path of the
backup tunnel, we could have different situations where the packets primary tunnel. The time lapsed in transitioning primary tunnel traffic
switched over to the backup tunnel may have one, more or 0 labels. to the backup tunnel is a key measurement that ensures the service level
agreements. Failover time depends upon many factors such as the number
of prefixes bound to a tunnel, services (such as IGP, BGP, Layer 3/
Layer 2 VPNs) that are bound to the tunnel, number of primary tunnels
affected by the failure event, number of primary tunnels protected by
backup, the type of failure and the physical media on which the failover
occurs. This document describes all different topologies and scenarios
that should be considered to effectively benchmark MPLS protection
mechanisms and failover times. Different failure scenarios and scaling
considerations are also provided in this document. In addition the
document provides a reporting format for the observed results.
All the benchmarking cases mentioned in this document could apply to To benchmark the failover time, data plane traffic is used as defined in
facility backup as well as local protection enabled in the detour mode. [IGP-METH]. Traffic loss is the key component in a black-box type test
The test cases and the procedures described here should completely and is used to measure convergence.
benchmark the failover time of a device under test in all possible
scenarios and configuration.
The additional scenarios defined in this document, are in addition to Poretsky, Rao, Le Roux
those considered in [FRR-METH]. All the cases enlisted in this document Protection Mechanisms
could be verified in a single topology that is similar to this.
All benchmarking test cases defined in this document apply to both
facility backup and local protection enabled in detour mode. The test
cases cover all possible failure scenarios and the associated procedures
benchmark the ability of the DUT to perform recovery from failures
within target failover time.
Figure 1 represents the basic reference test bed and is applicable to
all the test cases defined in this document. TG & TA represents Traffic
Generator & Analyzer respectively. A tester is connected to the DUT and
it sends and receives IP traffic along with the working Path, run
protocol emulations simulating real world peering scenarios.
--------------------------- ---------------------------
| ------------|--------------- | ------------|---------------
| | | | | | | |
| | | | | | | |
-------- -------- -------- -------- -------- -------- -------- -------- -------- --------
TG-| R1 |-----| R2 |----| R3 | | R4 | | R5 |-TA TG-| R1 |-----| R2 |----| R3 | | R4 | | R5 |-TA
| |-----| |----| |----| |---| | | |-----| |----| |----| |---| |
-------- -------- -------- -------- -------- -------- -------- -------- -------- --------
| | | | | | | |
| | | | | | | |
| -------- | | | -------- | |
---------| R6 |-------- | ---------| R6 |-------- |
| |-------------------- | |--------------------
-------- --------
Poretsky, Rao, Le Roux
Protection Mechanisms
Fig.1: Fast Reroute Topology. Fig.1: Fast Reroute Topology.
In figure 1, TG & TA are Traffic Generator & Analyzer respectively. The tester MUST record the number of lost, duplicate, and reordered
A tester is set outside the node as it sends and receives IP traffic packets. It should further record arrival and departure times so that
along the working Path, run protocol emulations simulating real world Failover Time, Additive Latency, and Reversion Time can be measured.
peering scenarios. The tester MUST record the number of lost packets, The tester may be a single device or a test system emulating all the
duplicate packet count, reordered packet count, departure time, and different roles along a primary or backup path.
arrival time so that the metrics of Failover Time, Additive Latency, and
Reversion Time can be measured. The tester may be a single device or a
test system.
Two or more failures are considered correlated if those failures occur
more or less simultaneously. Correlated failures are often expected
where two or more logical resources, such as layer-2 links, rely on a
common physical resource, such as common transport. TDM and WDM provide
multiplexing at layer-2 and layer-1 that are often the cause of
correlated failures. Where such correlations are known, such as knowing
that two logical links share a common fiber segment, the expectation of
a common failure can be compensated for by specifying Shared Risk Link
Groups [RFC-4090]. Not all correlated failures are anticipated in
advance of their occurrence. Failures due to natural disasters or due
to certain man-made disasters or mistakes are the most notable causes.
Failures of this type occur many times a year and generally a quite
spectacular failure occurs every few years.
There are two factors impacting service availability. One is the
frequency of failure. The other is the duration of failure. FRR
improves availability by minimizing the duration of the most common
failures. Unexpected correlated failures are less common. Some routers
recover much more quickly than others and therefore benchmarking this
type of failure may also be useful. Benchmarking of unexpected
correlated failures should include measurement of restoration with and
without the availability of IP fallback. The use BGP free core may be
growing, making the latter case an important test case. This document
focuses on FRR failover benchmarking with MPLS TE. Benchmarking of
unexpected correlated failures is out of scope but may be covered by a
later document.
Poretsky, Rao, Le Roux Poretsky, Rao, Le Roux
Protection Mechanisms Protection Mechanisms
2. Existing definitions 2. Existing definitions
For the sake of clarity and continuity this RFC adopts the template For the sake of clarity and continuity this RFC adopts the template
for definitions set out in Section 2 of RFC 1242. Definitions are for definitions set out in Section 2 of RFC 1242. Definitions are
indexed and grouped together in sections for ease of reference. indexed and grouped together in sections for ease of reference.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in
this document are to be interpreted as described in RFC 2119. this document are to be interpreted as described in RFC 2119.
The reader is assumed to be familiar with the commonly used MPLS The reader is assumed to be familiar with the commonly used MPLS
terminology, some of which is defined in [MPLS-RSVP], [MPLS-RSVP-TE], terminology, some of which is defined in [MPLS-FRR-EXT].
and [MPLS-FRR-EXT].
3. Test Considerations 3. Test Considerations
This section discusses the fundamentals of MPLS Protection testing: This section discusses the fundamentals of MPLS Protection testing:
-The types of network events that causes failover -The types of network events that causes failover
-Indications for failover -Indications for failover
-the use of data traffic -the use of data traffic
-Traffic generation -Traffic generation
-LSP Scaling -LSP Scaling
-Reversion of LSP -Reversion of LSP
-IGP Selection -IGP Selection
3.1. Failover Events 3.1. Failover Events
Triggers for failover to a backup tunnel are link and node failures The failover to the backup tunnel is primarily triggered by either a
seen downstream of the PLR as follows. link or node failures observed downstream of the Point of Local
repair (PLR). Some of these failure events are listed below.
Link failure events Link failure events
- Shutdown interface on PLR side with POS Alarm - Interface Shutdown on PLR side with POS Alarm
- Shutdown interface on remote side with POS Alarm - Interface Shutdown on remote side with POS Alarm
- Shutdown interface on PLR side with RSVP hello - Interface Shutdown on PLR side with RSVP hello
- Shutdown interface on remote side with RSVP hello - Interface Shutdown on remote side with RSVP hello
- Shutdown interface on PLR side with BFD - Interface Shutdown on PLR side with BFD
- Shutdown interface on remote side with BFD - Interface Shutdown on remote side with BFD
- Fiber Pull on PLR side (Both TX & RX or just the Tx)
- Fiber Pull on remote side (Both TX & RX or just the Rx)
Poretsky, Rao, Le Roux Poretsky, Rao, Le Roux
Protection Mechanisms Protection Mechanisms
- OIR on PLR side - 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 - OIR on remote side
- Sub-interface failure (shutting down of a VLAN) - Sub-interface failure (e.g. shutting down of a VLAN)
- Shut parent interface bearing multiple sub-interfaces - Parent interface shutdown (an interface bearing multiple sub-
interfaces
Node failure events Node failure events
A Reload is a graceful shutdown or a power failure. We refer to Crash
as a software failure or an assert.
- Reload protected Node, when RSVP Hello are enable A System reload is initiated either by a graceful shutdown or by a
- Crash Protected Node, when RSVP Hello are enable power failure. A system crash is referred to as a software failure or
an assert.
- Reload protected Node, when RSVP Hello is enabled
- Crash Protected Node, when RSVP Hello is enable
- Reload Protected Node, when BFD is enable - Reload Protected Node, when BFD is enable
- Crash Protected Node, when BFD is enable - Crash Protected Node, when BFD is enable
3.2. Failure Detection [TERMID] 3.2. Failure Detection [TERM-ID]
Local failures can be detected via SONET/SDH failure with directly Local failures can be detected via SONET/SDH failure with directly
connected LSR. Failure indication may vary with the type of alarm - connected LSR. Failure indication may vary with the type of alarm -
LOS, AIS, or RDI. Failures on Ethernet technology links such as LOS, AIS, or RDI. Failures on Ethernet links such as Gigabit Ethernet
Gigabit Ethernet rely upon Layer 3 signaling indication for failure. rely upon Layer 3 signaling indication for failure.
Different MPLS protection mechanisms and different implementations Different MPLS protection mechanisms and different implementations
use different failure indications such as RSVP hellos, BFD etc. use different failure detection techniques such as RSVP hellos, BFD
Ethernet technologies such as Gigabit Ethernet rely upon layer 3 etc. Ethernet technologies such as Gigabit Ethernet rely upon layer 3
failure indication mechanisms since there is no Layer 2 failure failure indication mechanisms since there is no Layer 2 failure
indication mechanism. The failure detection time may not always be indication mechanism. The failure detection time may not always be
negligible and it could impact the overall failover time. negligible and it could impact the overall failover time.
The test procedures in this document can be used against a local The test procedures in this document can be used for a local failure
failure as well as against a remote failure to account for or remote failure scenarios for comprehensive benchmarking and to
completeness of benchmarking and to evaluate failover performance evaluate failover performance independent of the failure detection
independent of the implemented signaling indication mechanism. techniques.
3.3. Use of Data Traffic for MPLS Protection Benchmarking
Customers of service providers use packet loss as the metric for
failover time. Packet loss is an externally observable event having
direct impact on customers' 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
Poretsky, Rao, Le Roux Poretsky, Rao, Le Roux
Protection Mechanisms Protection Mechanisms
packet loss as a metric. At a known rate for forwarding, packet loss
can be measured and used to calculate the Failover time. Measurement 3.3. Use of Data Traffic for MPLS Protection Benchmarking
of control plane signaling to establish backup paths is not enough
to verify failover. Failover is best determined when packets are Currently end customers use packet loss as a key metric for failover
actually traversing the backup path. time. Packet loss is an externally observable event and has direct
impact on customers' applications. 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 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 An additional benefit of using packet loss for calculation of
Failover time is that it enables black-box tests to be designed. Data Failover time is that it allows use of a black-box tests environment.
traffic can be offered at line-rate to the device under test (DUT), Data traffic is offered at line-rate to the device under test (DUT),
an emulated network event as described above can be forced to occur, and an emulated network failure event is forced to occur, and packet
and packet loss can be externally measured to calculate the loss is externally measured to calculate the convergence time. This
convergence time. Knowledge of DUT architecture is not required. setup is independent of the DUT architecture.
There is no need to rely on the understanding of the implementation
details of the DUT to get the required test results.
In addition, this methodology will consider the errored packets and In addition, this methodology considers the packets in error and
duplicate packets that could have been generated during the failover duplicate packets that could have been generated during the failover
process. In extreme cases, where measurement of errored and duplicate process. In scenarios, where separate measurement of packets in error
packets is difficult, these packets could be attributed to lost and duplicate packets is difficult to obtain, these packets should be
packets. attributed to lost packets.
3.4. LSP and Route Scaling 3.4. LSP and Route Scaling
Failover time performance may vary with the number of established Failover time performance may vary with the number of established
primary and backup LSPs and routes learned. However the procedure primary and backup tunnels (LSP) and installed routes. However the
outlined here may be used for any number of LSPs, L, and number of procedure outlined here should be used for any number of LSPs (L) and
routes protected by PLR, R. L and R must be recorded. number of routes protected by PLR(R). Number of L and R must be
recorded.
3.5. Selection of IGP 3.5. Selection of IGP
The underlying IGP could be ISIS-TE or OSPF-TE for the methodology The underlying IGP could be ISIS-TE or OSPF-TE for the methodology
proposed here. proposed here.
3.6. Reversion [TERMID] Poretsky, Rao, Le Roux
Protection Mechanisms
3.6. Reversion [TERM-ID]
Fast Reroute provides a method to return or restore a backup path to Fast Reroute provides a method to return or restore a backup path to
original primary LSP upon recovery from the failure. This is referred original primary LSP upon recovery from the failure. This is referred
to as Reversion, which can be implemented as Global Reversion or to as Reversion, which can be implemented as Global Reversion or
Local Reversion. In all test cases listed here Reversion should not Local Reversion. In all test cases listed here Reversion should not
produce any packet loss, out of order or duplicate packets. Each of produce any packet loss, out of order or duplicate packets. Each of
the test cases in this methodology document provides a step to verify the test cases in this methodology document provides a check to
that there is no packet loss. confirm that there is no packet loss.
Poretsky, Rao, Le Roux
Protection Mechanisms
3.7. Traffic generation 3.7. Traffic generation
It is suggested that there be one or more traffic streams as long as 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 there is a steady and constant rate of flow for all the streams. In
order to monitor the DUT performance for recovery times a set of order to monitor the DUT performance for recovery times a set of
route prefixes should be advertised before traffic is sent. The route prefixes should be advertised before traffic is sent. The
traffic should be configured towards these routes. traffic should be configured towards these routes.
A typical example would be configuring the traffic generator to send A typical example would be configuring the traffic generator to send
the traffic to the first, middle and last of the advertised routes. the traffic to the first, middle and last of the advertised routes.
skipping to change at page 9, line 32 skipping to change at page 10, line 5
manner) is not recommended. The reason why traffic generation is not manner) is not recommended. The reason why traffic generation is not
recommended in a Round-Robin fashion to all the prefixes, one at a 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 is that if there are many prefixes reachable through the LSP the
time interval between 2 packets destined to one prefix may be time interval between 2 packets destined to one prefix may be
significantly high and may be comparable with the failover time being significantly high and may be comparable with the failover time being
measured which does not aid in getting an accurate failover measured which does not aid in getting an accurate failover
measurement. measurement.
3.8. Motivation for topologies 3.8. Motivation for topologies
Given that the label stack is dependent on the following 3 entities Poretsky, Rao, Le Roux
Protection Mechanisms
Given that the label stack is dependent of the following 3 entities
it is recommended that the benchmarking of failover time be performed it is recommended that the benchmarking of failover time be performed
on all the 8 topologies enlisted in section 4 on all the 8 topologies provided in section 4
- Type of protection (Link Vs Node) - Type of protection (Link Vs Node)
- # of remaining hops of the primary tunnel from the PLR - # of remaining hops of the primary tunnel from the PLR
- # of remaining hops of the backup tunnel from the PLR - # of remaining hops of the backup tunnel from the PLR
4. Test Setup 4. Test Setup
Topologies to be used for benchmarking the failover time: Topologies to be used for benchmarking the failover time:
This section proposes a set of topologies that covers the scenarios This section proposes a set of topologies that covers all the
for local protection. All of these 8 topologies shown (figure 2- scenarios for local protection. All of these 8 topologies shown
figure 9) can be mapped to the master FRR topology shown in figure 1. (figure 2- figure 9) can be mapped to the reference topology shown in
Topologies shown in section 4.1 to 4.8 refer to the network figure 1. Topologies provided in sections 4.1 to 4.8 refer to test-
topologies required to benchmark failover time when DUT is configured bed required to benchmark failover time when DUT is configured as a
as a PLR either in headend or midpoint role. The number of labels PLR in either head-end or midpoint role. The labels stack provided
listed below are all w.r.t the PLR. with each topology is at the PLR.
Poretsky, Rao, Le Roux
Protection Mechanisms
The label stacks shown below each figure in section 4.1 to 4.9 The label stacks shown below each figure in section 4.1 to 4.9
considers the scenario when PHP is enabled. considers enabling of Penultimate Hop Popping (PHP).
In the following network topologies, Figures 2-9 uses the following convention:
HE is Head-End, TE is Tail-End, MID is Mid point, MP is Merge Point, a) HE is Head-End
PLR is Point of Local Repair, PRI is Primary and BKP denotes Backup b) TE is Tail-End
Node
c) MID is Mid point
d) MP is Merge Point
e) PLR is Point of Local Repair
f) PRI is Primary
g) BKP denotes Backup Node
Poretsky, Rao, Le Roux
Protection Mechanisms
4.1. Link Protection with 1 hop primary (from PLR) and 1 hop backup 4.1. Link Protection with 1 hop primary (from PLR) and 1 hop backup
TE tunnels TE tunnels
------- -------- PRI -------- ------- -------- PRI --------
| R1 | | R2 | | R3 | | R1 | | R2 | | R3 |
TG-| HE |--| MID |----| TE |-TA TG-| HE |--| MID |----| TE |-TA
| | | PLR |----| | | | | PLR |----| |
------- -------- BKP -------- ------- -------- BKP --------
Figure 2: Represents the setup for section 4.1 Figure 2: Represents the setup for section 4.1
Traffic No of Labels No of labels after Traffic No of Labels No of labels after
before failure failure before failure failure
IP TRAFFIC (P-P) 0 0 IP TRAFFIC (P-P) 0 0
Layer3 VPN (PE-PE) 1 1 Layer3 VPN (PE-PE) 1 1
Layer3 VPN (PE-P) 2 2 Layer3 VPN (PE-P) 2 2
Layer2 VC (PE-PE) 1 1 Layer2 VC (PE-PE) 1 1
Layer2 VC (PE-P) 2 2 Layer2 VC (PE-P) 2 2
Mid-point LSPs 0 0 Mid-point LSPs 0 0
Poretsky, Rao, Le Roux
Protection Mechanisms
4.2. Link Protection with 1 hop primary (from PLR) and 2 hop backup TE 4.2. Link Protection with 1 hop primary (from PLR) and 2 hop backup TE
tunnels tunnels
------- -------- -------- ------- -------- --------
| R1 | | R2 | | R3 | | R1 | | R2 | | R3 |
TG-| HE | | MID |PRI | TE |-TA TG-| HE | | MID |PRI | TE |-TA
| |----| PLR |----| | | |----| PLR |----| |
------- -------- -------- ------- -------- --------
|BKP | |BKP |
| -------- | | -------- |
| | R6 | | | | R6 | |
|----| BKP |----| |----| BKP |----|
| MID | | MID |
-------- --------
Figure 3: Representing setup for section 4.2 Figure 3: Representing setup for section 4.2
Traffic No of Labels No of labels Traffic No of Labels No of labels
before failure after failure before failure after failure
Poretsky, Rao, Le Roux
Protection Mechanisms
IP TRAFFIC (P-P) 0 1 IP TRAFFIC (P-P) 0 1
Layer3 VPN (PE-PE) 1 2 Layer3 VPN (PE-PE) 1 2
Layer3 VPN (PE-P) 2 3 Layer3 VPN (PE-P) 2 3
Layer2 VC (PE-PE) 1 2 Layer2 VC (PE-PE) 1 2
Layer2 VC (PE-P) 2 3 Layer2 VC (PE-P) 2 3
Mid-point LSPs 0 1 Mid-point LSPs 0 1
4.3. Link Protection with 2+ hop (from PLR) primary and 1 hop backup TE 4.3. Link Protection with 2+ hop (from PLR) primary and 1 hop backup TE
tunnels tunnels
-------- -------- -------- -------- -------- -------- -------- --------
| R1 | | R2 |PRI | R3 |PRI | R4 | | R1 | | R2 |PRI | R3 |PRI | R4 |
TG-| HE |----| MID |----| MID |------| TE |-TA TG-| HE |----| MID |----| MID |------| TE |-TA
| | | PLR |----| | | | | | | PLR |----| | | |
-------- -------- BKP -------- -------- -------- -------- BKP -------- --------
Figure 4: Representing setup for section 4.3 Figure 4: Representing setup for section 4.3
Traffic No of Labels No of labels Traffic No of Labels No of labels
Poretsky, Rao, Le Roux
Protection Mechanisms
before failure after failure before failure after failure
IP TRAFFIC (P-P) 1 1 IP TRAFFIC (P-P) 1 1
Layer3 VPN (PE-PE) 2 2 Layer3 VPN (PE-PE) 2 2
Layer3 VPN (PE-P) 3 3 Layer3 VPN (PE-P) 3 3
Layer2 VC (PE-PE) 2 2 Layer2 VC (PE-PE) 2 2
Layer2 VC (PE-P) 3 3 Layer2 VC (PE-P) 3 3
Mid-point LSPs 1 1 Mid-point LSPs 1 1
4.4. Link Protection with 2+ hop (from PLR) primary and 2 hop backup TE 4.4. Link Protection with 2+ hop (from PLR) primary and 2 hop backup TE
tunnels tunnels
Poretsky, Rao, Le Roux
Protection Mechanisms
-------- -------- PRI -------- PRI -------- -------- -------- PRI -------- PRI --------
| R1 | | R2 | | R3 | | R4 | | R1 | | R2 | | R3 | | R4 |
TG-| HE |----| MID |----| MID |------| TE |-TA TG-| HE |----| MID |----| MID |------| TE |-TA
| | | PLR | | | | | | | | PLR | | | | |
-------- -------- -------- -------- -------- -------- -------- --------
BKP| | BKP| |
| -------- | | -------- |
| | R6 | | | | R6 | |
---| BKP |- ---| BKP |-
| MID | | MID |
skipping to change at page 13, line 5 skipping to change at page 13, line 31
Traffic No of Labels No of labels Traffic No of Labels No of labels
before failure after failure before failure after failure
IP TRAFFIC (P-P) 1 2 IP TRAFFIC (P-P) 1 2
Layer3 VPN (PE-PE) 2 3 Layer3 VPN (PE-PE) 2 3
Layer3 VPN (PE-P) 3 4 Layer3 VPN (PE-P) 3 4
Layer2 VC (PE-PE) 2 3 Layer2 VC (PE-PE) 2 3
Layer2 VC (PE-P) 3 4 Layer2 VC (PE-P) 3 4
Mid-point LSPs 1 2 Mid-point LSPs 1 2
Poretsky, Rao, Le Roux
Protection Mechanisms
4.5. Node Protection with 2 hop primary (from PLR) and 1 hop backup TE 4.5. Node Protection with 2 hop primary (from PLR) and 1 hop backup TE
tunnels tunnels
-------- -------- -------- -------- -------- -------- -------- --------
| R1 | | R2 |PRI | R3 | PRI | R4 | | R1 | | R2 |PRI | R3 | PRI | R4 |
TG-| HE |----| MID |----| MID |------| TE |-TA TG-| HE |----| MID |----| MID |------| TE |-TA
| | | PLR | | | | | | | | PLR | | | | |
-------- -------- -------- -------- -------- -------- -------- --------
|BKP | |BKP |
----------------------------- -----------------------------
Figure 6: Representing the setup for section 4.5 Figure 6: Representing the setup for section 4.5
Poretsky, Rao, Le Roux
Protection Mechanisms
Traffic No of Labels No of labels Traffic No of Labels No of labels
before failure after failure before failure after failure
IP TRAFFIC (P-P) 1 0 IP TRAFFIC (P-P) 1 0
Layer3 VPN (PE-PE) 2 1 Layer3 VPN (PE-PE) 2 1
Layer3 VPN (PE-P) 3 2 Layer3 VPN (PE-P) 3 2
Layer2 VC (PE-PE) 2 1 Layer2 VC (PE-PE) 2 1
Layer2 VC (PE-P) 3 2 Layer2 VC (PE-P) 3 2
Mid-point LSPs 1 0 Mid-point LSPs 1 0
skipping to change at page 14, line 5 skipping to change at page 14, line 34
| |----| PLR |----| |----| | | |----| PLR |----| |----| |
-------- -------- -------- -------- -------- -------- -------- --------
| | | |
BKP| -------- | BKP| -------- |
| | R6 | | | | R6 | |
---------| BKP |--------- ---------| BKP |---------
| MID | | MID |
-------- --------
Figure 7: Representing setup for section 4.6 Figure 7: Representing setup for section 4.6
Poretsky, Rao, Le Roux
Protection Mechanisms
Traffic No of Labels No of labels Traffic No of Labels No of labels
before failure after failure before failure after failure
IP TRAFFIC (P-P) 1 1 IP TRAFFIC (P-P) 1 1
Layer3 VPN (PE-PE) 2 2 Layer3 VPN (PE-PE) 2 2
Layer3 VPN (PE-P) 3 3 Layer3 VPN (PE-P) 3 3
Poretsky, Rao, Le Roux
Protection Mechanisms
Layer2 VC (PE-PE) 2 2 Layer2 VC (PE-PE) 2 2
Layer2 VC (PE-P) 3 3 Layer2 VC (PE-P) 3 3
Mid-point LSPs 1 1 Mid-point LSPs 1 1
4.7. Node Protection with 3+ hop primary (from PLR) and 1 hop backup TE 4.7. Node Protection with 3+ hop primary (from PLR) and 1 hop backup TE
tunnels tunnels
-------- -------- PRI -------- PRI -------- PRI -------- -------- -------- PRI -------- PRI -------- PRI --------
| R1 | | R2 | | R3 | | R4 | | R5 | | R1 | | R2 | | R3 | | R4 | | R5 |
TG-| HE |--| MID |---| MID |---| MP |---| TE |-TA TG-| HE |--| MID |---| MID |---| MP |---| TE |-TA
skipping to change at page 15, line 5 skipping to change at page 15, line 33
Traffic No of Labels No of labels Traffic No of Labels No of labels
before failure after failure before failure after failure
IP TRAFFIC (P-P) 1 1 IP TRAFFIC (P-P) 1 1
Layer3 VPN (PE-PE) 2 2 Layer3 VPN (PE-PE) 2 2
Layer3 VPN (PE-P) 3 3 Layer3 VPN (PE-P) 3 3
Layer2 VC (PE-PE) 2 2 Layer2 VC (PE-PE) 2 2
Layer2 VC (PE-P) 3 3 Layer2 VC (PE-P) 3 3
Mid-point LSPs 1 1 Mid-point LSPs 1 1
Poretsky, Rao, Le Roux
Protection Mechanisms
4.8. Node Protection with 3+ hop primary (from PLR) and 2 hop backup 4.8. Node Protection with 3+ hop primary (from PLR) and 2 hop backup
TE tunnels TE tunnels
Poretsky, Rao, Le Roux
Protection Mechanisms
-------- -------- -------- -------- -------- -------- -------- -------- -------- --------
| R1 | | R2 | | R3 | | R4 | | R5 | | R1 | | R2 | | R3 | | R4 | | R5 |
TG-| HE | | MID |PRI| MID |PRI| MP |PRI| TE |-TA TG-| HE | | MID |PRI| MID |PRI| MP |PRI| TE |-TA
| |-- | PLR |---| |---| |---| | | |-- | PLR |---| |---| |---| |
-------- -------- -------- -------- -------- -------- -------- -------- -------- --------
BKP| | BKP| |
| -------- | | -------- |
| | R6 | | | | R6 | |
---------| BKP |------- ---------| BKP |-------
| MID | | MID |
skipping to change at page 15, line 32 skipping to change at page 16, line 29
Figure 9: Representing setup for section 4.8 Figure 9: Representing setup for section 4.8
Traffic No of Labels No of labels Traffic No of Labels No of labels
before failure after failure before failure after failure
IP TRAFFIC (P-P) 1 2 IP TRAFFIC (P-P) 1 2
Layer3 VPN (PE-PE) 2 3 Layer3 VPN (PE-PE) 2 3
Layer3 VPN (PE-P) 3 4 Layer3 VPN (PE-P) 3 4
Layer2 VC (PE-PE) 2 3 Layer2 VC (PE-PE) 2 3
Layer2 VC (PE-P) 3 4 Layer2 VC (PE-P) 3 4
Any 1 2 Mid-point LSPs 1 2
4.9. Baseline MPLS Forwarding Performance Test Topology
------- -------- --------
| R1 | | R2 | | R3 |
| HE |--| MID |----| TE |
| | | | | |
------- -------- --------
Figure 10: Baseline Forwarding Performance
Poretsky, Rao, Le Roux
Protection Mechanisms
5. Test Methodology 5. Test Methodology
The procedure described in this section can be applied to all the 8 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 base test cases and the associated topologies. The backup as well as
the primary tunnel are configured to be alike in terms of bandwidth the primary tunnel are configured to be alike in terms of bandwidth
usage. In order to benchmark failover with all possible label stack usage. In order to benchmark failover with all possible label stack
depth applicable as seen with current deployments, it is suggested depth applicable as seen with current deployments, it is suggested
that the methodology includes all the scenarios listed here that the methodology includes all the scenarios listed here
Poretsky, Rao, Le Roux
Protection Mechanisms
5.1. Headend as PLR with link failure 5.1. Headend as PLR with link failure
Objective Objective
To benchmark the MPLS failover time due to Link failure events To benchmark the MPLS failover time due to Link failure events
described in section 3.1 experienced by the DUT which is the point described in section 3.1 experienced by the DUT which is the point
of local repair (PLR). of local repair (PLR).
Test Setup Test Setup
- select any one topology out of 8 from section 4 - select any one topology out of 8 from section 4
- select overlay technology for FRR test e.g IGP,VPN,or VC - select overlay technology for FRR test e.g. IGP,VPN,or VC
- The DUT will also have 2 interfaces connected to the traffic - The DUT will also have 2 interfaces connected to the traffic
Generator/analyzer. (If the node downstream of the PLR is not Generator/analyzer. (If the node downstream of the PLR is not
A simulated node, then the Ingress of the tunnel should have A simulated node, then the Ingress of the tunnel should have
one link connected to the traffic generator and the node one link connected to the traffic generator and the node
downstream to the PLR or the egress of the tunnel should have downstream to the PLR or the egress of the tunnel should have
a link connected to the traffic analyzer). a link connected to the traffic analyzer).
Test Configuration Test Configuration
1. Configure the number of primaries on R2 and the backups on 1. Configure the number of primaries on R2 and the backups on
R2 as required by the topology selected. R2 as required by the topology selected.
2. Advertise prefixes (as per FRR Scalability table describe in 2. Advertise prefixes (as per FRR Scalability table describe in
Appendix A) by the tail end. Appendix A) by the tail end.
Procedure Procedure
1. Establish the primary lsp on R2 required by the topology 1. Establish the primary lsp on R2 required by the topology
selected selected
2. Establish the backup lsp on R2 required by the selected 2. Establish the backup lsp on R2 required by the selected
topology topology
Poretsky, Rao, Le Roux
Protection Mechanisms
3. Verify primary and backup lsps are up and that primary is 3. Verify primary and backup lsps are up and that primary is
protected protected
4. Verify Fast Reroute protection is enabled and ready 4. Verify Fast Reroute protection is enabled and ready
5. Setup traffic streams as described in section 3.7 5. Setup traffic streams as described in section 3.7
6. Send IP traffic at maximum Forwarding Rate to DUT. 6. Send IP traffic at maximum Forwarding Rate to DUT.
7. Verify traffic switched over Primary LSP. 7. Verify traffic switched over Primary LSP.
Poretsky, Rao, Le Roux
Protection Mechanisms
8. Trigger any choice of Link failure as describe in section 8. Trigger any choice of Link failure as describe in section
3.1 3.1
9. Verify that primary tunnel and prefixes gets mapped to 9. Verify that primary tunnel and prefixes gets mapped to
backup tunnels backup tunnels
10. Stop traffic stream and measure the traffic loss. 10. Stop traffic stream and measure the traffic loss.
11. Failover time is calculated as per defined in section 6, 11. Failover time is calculated as per defined in section 6,
Reporting format. Reporting format.
12. Start traffic stream again to verify reversion when 12. Start traffic stream again to verify reversion when
protected interface comes up. Traffic loss should be 0 due protected interface comes up. Traffic loss should be 0 due
to make before break or reversion. to make before break or reversion.
skipping to change at page 18, line 4 skipping to change at page 18, line 41
- select any one topology out of 8 from section 4 - select any one topology out of 8 from section 4
- select overlay technology for FRR test as Mid-Point lsps - select overlay technology for FRR test as Mid-Point lsps
- The DUT will also have 2 interfaces connected to the traffic - The DUT will also have 2 interfaces connected to the traffic
generator. generator.
Test Configuration Test Configuration
1. Configure the number of primaries on R1 and the backups on 1. Configure the number of primaries on R1 and the backups on
R2 as required by the topology selected R2 as required by the topology selected
Poretsky, Rao, Le Roux
Protection Mechanisms
2. Advertise prefixes (as per FRR Scalability table describe in 2. Advertise prefixes (as per FRR Scalability table describe in
Appendix A) by the tail end. Appendix A) by the tail end.
Poretsky, Rao, Le Roux
Protection Mechanisms
Procedure Procedure
1. Establish the primary lsp on R1 required by the topology 1. Establish the primary lsp on R1 required by the topology
selected selected
2. Establish the backup lsp on R2 required by the selected 2. Establish the backup lsp on R2 required by the selected
topology topology
3. Verify primary and backup lsps are up and that primary is 3. Verify primary and backup lsps are up and that primary is
protected protected
4. Verify Fast Reroute protection 4. Verify Fast Reroute protection
5. Setup traffic streams as described in section 3.7 5. Setup traffic streams as described in section 3.7
skipping to change at page 19, line 5 skipping to change at page 19, line 44
5.3. Headend as PLR with Node failure 5.3. Headend as PLR with Node failure
Objective Objective
To benchmark the MPLS failover time due to Node failure events To benchmark the MPLS failover time due to Node failure events
described in section 3.1 experienced by the device under test which described in section 3.1 experienced by the device under test which
is the point of local repair (PLR). is the point of local repair (PLR).
Test Setup Test Setup
Poretsky, Rao, Le Roux
Protection Mechanisms
- select any one topology from section 4.5 to 4.8 - select any one topology from section 4.5 to 4.8
- select overlay technology for FRR test e.g IGP,VPN,or VC - select overlay technology for FRR test e.g. IGP,VPN,or VC
- The DUT will also have 2 interfaces connected to the traffic - The DUT will also have 2 interfaces connected to the traffic
Poretsky, Rao, Le Roux
Protection Mechanisms
generator. generator.
Test Configuration Test Configuration
1. Configure the number of primaries on R2 and the backups on 1. Configure the number of primaries on R2 and the backups on
R2 as required by the topology selected R2 as required by the topology selected
2. Advertise prefixes (as per FRR Scalability table describe in 2. Advertise prefixes (as per FRR Scalability table describe in
Appendix A) by the tail end. Appendix A) by the tail end.
Procedure Procedure
skipping to change at page 20, line 5 skipping to change at page 20, line 42
10. Stop traffic stream and measure the traffic loss. 10. Stop traffic stream and measure the traffic loss.
11. Failover time is calculated as per defined in section 6, 11. Failover time is calculated as per defined in section 6,
Reporting format. Reporting format.
12. Start traffic stream again to verify reversion when 12. Start traffic stream again to verify reversion when
protected interface comes up. Traffic loss should be 0 due protected interface comes up. Traffic loss should be 0 due
to make before break or reversion to make before break or reversion
13. Boot protected Node that was down. 13. Boot protected Node that was down.
14. Verify head-end signals new LSP and protection should be in 14. Verify head-end signals new LSP and protection should be in
place again place again
Poretsky, Rao, Le Roux
Protection Mechanisms
5.4. Mid-Point as PLR with Node failure 5.4. Mid-Point as PLR with Node failure
Poretsky, Rao, Le Roux
Protection Mechanisms
Objective Objective
To benchmark the MPLS failover time due to Node failure events To benchmark the MPLS failover time due to Node failure events
described in section 3.1 experienced by the device under test which described in section 3.1 experienced by the device under test which
is the point of local repair (PLR). is the point of local repair (PLR).
Test Setup Test Setup
- select any one topology from section 4.5 to 4.8 - select any one topology from section 4.5 to 4.8
- select overlay technology for FRR test as Mid-Point lsps - select overlay technology for FRR test as Mid-Point lsps
skipping to change at page 21, line 14 skipping to change at page 22, line 14
Poretsky, Rao, Le Roux Poretsky, Rao, Le Roux
Protection Mechanisms Protection Mechanisms
12. Start traffic stream again to verify reversion when 12. Start traffic stream again to verify reversion when
protected interface comes up. Traffic loss should be 0 due protected interface comes up. Traffic loss should be 0 due
to make before break or reversion to make before break or reversion
13. Boot protected Node that was down 13. Boot protected Node that was down
14. Verify head-end signals new LSP and protection should be in 14. Verify head-end signals new LSP and protection should be in
place again place again
5.5. Baseline MPLS Forwarding Performance Test Cases 5.5. MPLS FRR Forwarding Performance Test Cases
For the following Forwarding Performance Benchmarking cases, the
egress must not send an implicit-null label. That is PHP should
not occur.
5.5.1. DUT Throughput as Ingress
Objective
To baseline the MPLS Throughput of the DUT acting as an
Ingress.
Procedure
1. Configure the DUT as R1, Ingress and the Tester as R2/R3
Midpoint and Egress as shown in Figure 10.
2. Execute the Throughput benchmarking test, as specified in
[RFC-BENCH], paragraph 26.1.
Expected Results:
The DUT will push a single label onto the IP packet and
forward it to the Tester as an MPLS packet.
5.5.2. DUT Latency as Ingress
Objective
To baseline the MPLS Latency of the DUT acting as an
Ingress.
Procedure
Poretsky, Rao, Le Roux
Protection Mechanisms
1. Configure the DUT as R1, Ingress and the Tester as R2/R3
Midpoint and Egress as shown in Figure 10.
2. Execute the Latency benchmarking test, as specified in
[RFC-BENCH], paragraph 26.2.
Expected Results:
The DUT will push a single label onto the IP packet and For the following MPLS FRR Forwarding Performance Benchmarking
forward it to the Tester as an MPLS packet. cases, Test the maximum PPS rate allowed by given hardware
5.5.3. DUT Throughput as Egress 5.5.1. PLR as Headend
Objective Objective
To baseline the MPLS Throughput of the DUT acting as an To benchmark the maximum rate (pps) on the PLR (as headend)
Egress. over primary FRR LSP and backup lsp.
Procedure
1. Configure the DUT as R3, Egress and the Tester as R1/R2
Ingress and Midpoint as shown in Figure 10.
2. Execute the Throughput benchmarking test, as specified in
[RFC-BENCH], paragraph 26.1 using MPLS labeled IP packets for
the offered load.
Expected Results:
The DUT will pop a single label from the IP packet and
forward it to the Tester as an IP packet.
5.5.4. DUT Latency as Egress
Objective Test Setup
To baseline the MPLS Latency of the DUT acting as an Egress. - select any one topology out of 8 from section 4
- select overlay technology for FRR test 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 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 Procedure
1. Configure the DUT as R3, Egress and the Tester as R1/R2 1. Establish the primary lsp on R2 required by the
Ingress and Midpoint as shown in Figure 10. 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
Poretsky, Rao, Le Roux Poretsky, Rao, Le Roux
Protection Mechanisms Protection Mechanisms
2. Execute the Latency benchmarking test, as specified in 5. Setup traffic streams as described in section 3.7
[RFC-BENCH], paragraph 26.2 using MPLS labeled IP packets for 6. Send IP traffic at maximum forwarding rate (pps) that
the offered load. the device under test supports over the primary LSP
7. Record maximum PPS rate forwarded over primary LSP
Expected Results: 8. Stop traffic stream
9. Trigger any choice of Link failure as describe 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 primary LSP
12. Record maximum PPS rate forwarded over backup LSP
The DUT will pop a single label from the IP packet and 5.5.2. PLR as Mid-point
forward it to the Tester as an IP packet.
5.5.5. DUT Throughput as Mid-Point To benchmark the maximum rate (pps) on the PLR (as mid-point)
over primary FRR LSP and backup lsp.
Objective Test Setup
To baseline the MPLS Throughput of the DUT acting as a Mid- - select any one topology out of 8 from section 4
Point. - select overlay technology for FRR test as Mid-Point lsps
- The DUT will also have 2 interfaces connected to the traffic
generator.
Procedure Procedure
1. Configure the DUT as R2, Mid-Point and the Tester as 1. Establish the primary lsp on R1 required by the
R1/R3 Ingress and Egress as shown in Figure 10. topology selected
2. Execute the Throughput benchmarking test, as specified in 2. Establish the backup lsp on R2 required by the
[RFC-BENCH], paragraph 26.1 using MPLS labeled IP packets for selected topology
the offered load. 3. Verify primary and backup lsps are up and that primary
is protected
Expected Results: 4. Verify Fast Reroute protection is enabled and ready
5. Setup traffic streams as described in section 3.7
The DUT will receive the MPLS labeled packet, swap a single
MPLS label and forward it to the Tester as an MPLS labeled
packet.
5.5.6. DUT Latency as Mid-Point
Objective
To baseline the MPLS Latency of the DUT acting as a Mid-
Point.
Procedure
Poretsky, Rao, Le Roux Poretsky, Rao, Le Roux
Protection Mechanisms Protection Mechanisms
1. Configure the DUT as R2, Mid-Point and the Tester as 6. Send IP traffic at maximum forwarding rate (pps) that
R1/R3 Ingress and Egress as shown in Figure 10. the device under test supports over the primary LSP
2. Execute the Latency benchmarking test, as specified in 7. Record maximum PPS rate forwarded over primary LSP
[RFC-BENCH], paragraph 26.2 using MPLS labeled IP packets for 8. Stop traffic stream
the offered load. 9. Trigger any choice of Link failure as describe in
section 3.1
Expected Results: 10. Verify that primary tunnel and prefixes gets mapped to
backup tunnels
The DUT will receive the MPLS labeled packet, swap a single 11. Send IP traffic at maximum forwarding rate (pps) that
MPLS label and forward it to the Tester as an MPLS labeled the device under test supports over the backup LSP
packet. 12. Record maximum PPS rate forwarded over backup LSP
6. Reporting Format 6. Reporting Format
For each test, it is recommended that the results be reported in the For each test, it is recommended that the results be reported in the
following format. following format.
Parameter Units Parameter Units
IGP used for the test ISIS-TE/ OSPF-TE IGP used for the test ISIS-TE/ OSPF-TE
Interface types Gige,POS,ATM,VLAN etc. Interface types Gige,POS,ATM,VLAN etc.
Packet Sizes offered to the DUT Bytes Packet Sizes offered to the DUT Bytes
Forwarding rate number of packets
IGP routes advertised number of IGP routes IGP routes advertised number of IGP routes
RSVP hello timers configured (if any) milliseconds RSVP hello timers configured (if any) milliseconds
Number of FRR tunnels configured number of tunnels Number of FRR tunnels configured number of tunnels
Number of VPN routes in head-end number of VPN routes Number of VPN routes in head-end number of VPN routes
Number of VC tunnels number of VC tunnels Number of VC tunnels number of VC tunnels
Number of BGP routes number of BGP routes Number of BGP routes number of BGP routes
Number of mid-point tunnels number of tunnels Number of mid-point tunnels number of tunnels
Number of Prefixes protected by Primary number of prefixes Number of Prefixes protected by Primary number of prefixes
Number of LSPs being protected number of LSPs Number of LSPs being protected number of LSPs
Topology being used Section number Topology being used Section number
Failure Event Event type Failure Event Event type
Benchmarks Benchmarks
Minimum failover time milliseconds
Mean failover time milliseconds
Poretsky, Rao, Le Roux Poretsky, Rao, Le Roux
Protection Mechanisms Protection Mechanisms
Minimum failover time milliseconds
Mean failover time milliseconds
Maximum failover time milliseconds Maximum failover time milliseconds
Minimum reversion time milliseconds Minimum reversion time milliseconds
Mean reversion time milliseconds Mean reversion time milliseconds
Maximum reversion time milliseconds Maximum reversion time milliseconds
Failover time suggested above is calculated using the following Failover time suggested above is calculated using one of the
formula: (Numbers of packet drop/rate per second * 1000) milliseconds following 2 methods
1. Packet loss based method: (Numbers of packet drop/rate per
second * 1000) milliseconds
2. Time based method: Traffic generators provide statistics which
show the duration of failure in milliseconds based on the when
the packet loss occurred (interval between non-zero packet loss
and zero loss).
Note: If the primary is configured to be dynamic, and if the primary 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 is is to reroute, make before break should occur from the backup that is
in use to a new alternate primary. If there is any packet loss seen, in use to a new alternate primary. If there is any packet loss seen,
it should be added to failover time. it should be added to failover time.
7. Security Considerations 7. IANA Considerations
Documents of this type do not directly affect the security of This document requires no IANA considerations.
the Internet or of corporate networks as long as benchmarking
is not performed on devices or systems connected to operating
networks.
8. Acknowledgements 8. Security Considerations
We would like to thank Jean Philip Vasseur for his invaluable input Benchmarking activities as described in this memo are limited to
to the document and Curtis Villamizar for his contribution in suggesting technology characterization using controlled stimuli in a laboratory
text on definition and need for benchmarking Correlated failures. environment, with dedicated address space and the constraints
specified in the sections above.
Additionally we would like to thank Arun Gandhi, Amrit Hanspal, Karu The benchmarking network topology will be an independent test setup
Ratnam and for their input to the document. and MUST NOT be connected to devices that may forward the test
traffic into a production network, or misroute traffic to the test
management network.
9. References Poretsky, Rao, Le Roux
Protection Mechanisms
Further, benchmarking is performed on a "black-box" basis, relying
solely on measurements observable external to the DUT/SUT.
9.1. Normative References Special capabilities SHOULD NOT exist in the DUT/SUT specifically
for benchmarking purposes. Any implications for network security
arising from the DUT/SUT SHOULD be identical in the lab and in
production networks.
[MPLS-RSVP] R. Braden, Ed., et al, "Resource ReSerVation The isolated nature of the benchmarking environments and the fact
protocol (RSVP) -- version 1 functional that no special features or capabilities, other than those used in
specification," RFC2205, September 1999. operational networks, are enabled on the DUT/SUT requires no
security considerations specific to the benchmarking process.
[MPLS-RSVP-TE] D. Awduche, et al, "RSVP-TE: Extensions to 9. Acknowledgements
RSVP for LSP Tunnels", RFC3209, December 2001.
[MPLS-FRR-EXT] Pan, P., Atlas, A., Swallow, G., 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.
Poretsky, Rao, Le Roux Additionally we would like to thank Arun Gandhi, Amrit Hanspal, Karu
Protection Mechanisms Ratnam and for their input to the document.
"Fast Reroute Extensions to RSVP-TE for LSP
Tunnels", RFC 4090.
[MPLS-ARCH] Rosen, E., Viswanathan, A. and R. Callon, 10. References
"Multiprotocol Label Switching Architecture",
RFC 3031, January 2001.
[RFC-BENCH] Bradner, S. and McQuaid, J., "Benchmarking 10.1. Normative References
Methodology for Network Interconnect Devices",
RFC 2544.
9.2. Informative References [MPLS-FRR-EXT] Pan, P., Atlas, A., Swallow, G., "Fast Reroute
Extensions to RSVP-TE for LSP Tunnels", RFC 4090.
[MPLS-LDP] Andersson, L., Doolan, P., Feldman, N., 10.2. Informative References
Fredette, A. and B. Thomas, "LDP Specification",
RFC 3036, January 2001.
[RFC-WORDS] Bradner, S., "Key words for use in RFCs to [RFC-WORDS] Bradner, S., "Key words for use in RFCs to
Indicate Requirement Levels", RFC 2119, Indicate Requirement Levels", RFC 2119, March 1997.
March 1997.
[RFC-IANA] T. Narten and H. Alvestrand, "Guidelines for [TERM-ID] Poretsky, S., Papneja, R., "Benchmarking Terminology
Writing an IANA Considerations Section in RFCs", for Protection Performance", draft-poretsky-
RFC 2434.
[TERM-ID] Poretsky, S., Papneja, R., Poretsky, Rao, Le Roux
"Benchmarking Terminology for Protection Protection Mechanisms
Performance", draft-poretsky-protection-term- protection-term-00.txt, work in progress.
00.txt, work in progress.
[IGP-METH] S. Poretsky, B. Imhoff. "Benchmarking Methodology [MPLS-FRR-EXT] Pan P., Swollow G., Atlas A., "Fast Reroute
Extensions to RSVP-TE for LSP Tunnels”, RFC 4090.
[IGP-METH] S. Poretsky, B. Imhoff, "Benchmarking Methodology
for IGP Data Plane Route Convergence," draft-ietf- for IGP Data Plane Route Convergence," draft-ietf-
bmwg-igp-dataplane-conv-meth-11.txt,” work in bmwg-igp-dataplane-conv-meth-11.txt”, work in
progress. progress.
10. Author's Address 11. Authors' Addresses
Rajiv Papneja Rajiv Papneja
Poretsky, Rao, Le Roux
Protection Mechanisms
Isocore Isocore
12359 Sunrise Valley Drive, STE 100 12359 Sunrise Valley Drive, STE 100
Reston, VA 20190 Reston, VA 20190
USA USA
Phone: +1 703 860 9273 Phone: +1 703 860 9273
Email: rpapneja@isocore.com Email: rpapneja@isocore.com
Samir Vapiwala Samir Vapiwala
Cisco System Cisco System
300 Beaver Brook Road 300 Beaver Brook Road
skipping to change at page 27, line 30 skipping to change at page 28, line 5
Email: svapiwal@cisco.com Email: svapiwal@cisco.com
Jay Karthik Jay Karthik
Cisco System Cisco System
300 Beaver Brook Road 300 Beaver Brook Road
Boxborough, MA 01719 Boxborough, MA 01719
USA USA
Phone: +1 978 936 0533 Phone: +1 978 936 0533
Email: jkarthik@cisco.com Email: jkarthik@cisco.com
Poretsky, Rao, Le Roux
Protection Mechanisms
Scott Poretsky Scott Poretsky
Reef Point Systems Reef Point Systems
8 New England Executive Park 8 New England Executive Park
Burlington, MA 01803 Burlington, MA 01803
USA USA
Phone: + 1 781 395 5090 Phone: + 1 781 395 5090
EMail: sporetsky@reefpoint.com EMail: sporetsky@reefpoint.com
Shankar Rao Shankar Rao
Qwest Communications, Qwest Communications,
950 17th Street 950 17th Street
Suite 1900 Suite 1900
Qwest Communications Qwest Communications
Denver, CO 80210 Denver, CO 80210
USA USA
Phone: + 1 303 437 6643 Phone: + 1 303 437 6643
Email: shankar.rao@qwest.com Email: shankar.rao@qwest.com
Poretsky, Rao, Le Roux
Protection Mechanisms
Jean-Louis Le Roux Jean-Louis Le Roux
France Telecom France Telecom
2 av Pierre Marzin 2 av Pierre Marzin
22300 Lannion 22300 Lannion
France France
Phone: 00 33 2 96 05 30 20 Phone: 00 33 2 96 05 30 20
Email: jeanlouis.leroux@orange-ft.com Email: jeanlouis.leroux@orange-ft.com
Full Copyright Statement Full Copyright Statement
Copyright (C) The Internet Society (2006). Copyright (C) The IETF Trust (2007).
This document is subject to the rights, licenses and restrictions This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors contained in BCP 78, and except as set forth therein, the authors
retain all their rights. retain all their rights.
This document and the information contained herein are provided on an Disclaimer
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET Poretsky, Rao, Le Roux
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, Protection Mechanisms
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE This document and the information contained herein are provided
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 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.
Intellectual Property Statement
Intellectual Property
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights 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 might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79. found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an 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 attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at specification can be obtained from the IETF on-line IPR repository at
Poretsky, Rao, Le Roux
Protection Mechanisms
http://www.ietf.org/ipr. http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at ietf- this standard. Please address the information to the IETF at
ipr@ietf.org. ietf-ipr@ietf.org
Acknowledgement Acknowledgement
Funding for the RFC Editor function is currently provided by the Funding for the RFC Editor function is currently provided by the
Internet Society. Internet Society.
Poretsky, Rao, Le Roux
Protection Mechanisms
Appendix A: Fast Reroute Scalability Table Appendix A: Fast Reroute Scalability Table
This section provides the recommended numbers for evaluating the This section provides the recommended numbers for evaluating the
scalability of fast reroute implementations. It also recommends the scalability of fast reroute implementations. It also recommends the
typical numbers for IGP/VPNv4 Prefixes, LSP Tunnels and VC entries. typical numbers for IGP/VPNv4 Prefixes, LSP Tunnels and VC entries.
Based on the features supported by the device under test, appropriate Based on the features supported by the device under test, appropriate
scaling limits can be used for the test bed. scaling limits can be used for the test bed.
A 1. FRR IGP Table A 1. FRR IGP Table
skipping to change at page 30, line 5 skipping to change at page 30, line 34
2(Load Balance) 100 2(Load Balance) 100
2(Load Balance) 500 2(Load Balance) 500
2(Load Balance) 1000 2(Load Balance) 1000
2(Load Balance) 2000 2(Load Balance) 2000
2(Load Balance) 5000 2(Load Balance) 5000
100 100 100 100
500 500 500 500
1000 1000 1000 1000
2000 2000 2000 2000
Poretsky, Rao, Le Roux
Protection Mechanisms
A 2. FRR VPN Table A 2. FRR VPN Table
No of Headend VPNv4 Prefixes No of Headend VPNv4 Prefixes
TE LSPs TE LSPs
1 100 1 100
1 500 1 500
1 1000 1 1000
1 2000 1 2000
1 5000 1 5000
1 10000 1 10000
Poretsky, Rao, Le Roux
Protection Mechanisms
1 20000 1 20000
1 Max 1 Max
2(Load Balance) 100 2(Load Balance) 100
2(Load Balance) 500 2(Load Balance) 500
2(Load Balance) 1000 2(Load Balance) 1000
2(Load Balance) 2000 2(Load Balance) 2000
2(Load Balance) 5000 2(Load Balance) 5000
2(Load Balance) 10000 2(Load Balance) 10000
2(Load Balance) 20000 2(Load Balance) 20000
2(Load Balance) Max 2(Load Balance) Max
A 3. FRR Mid-Point LSP Table A 3. FRR Mid-Point LSP Table
No of Mid-point TE LSps could be configured at the following No of Mid-point TE LSPs could be configured at the following
recommended levels recommended levels
100 100
500 500
1000 1000
2000 2000
Max supported number Max supported number
A 4. FRR VC Table A 4. FRR VC Table
No of Headend VC entries No of Headend VC entries
TE LSPs TE LSPs
1 100 1 100
1 500 1 500
1 1000 1 1000
Poretsky, Rao, Le Roux
Protection Mechanisms
1 2000 1 2000
1 Max 1 Max
100 100 100 100
500 500 500 500
1000 1000 1000 1000
2000 2000 2000 2000
Appendix B: Abbreviations Appendix B: Abbreviations
Poretsky, Rao, Le Roux
Protection Mechanisms
BFD - Bidirectional Fault Detection BFD - Bidirectional Fault Detection
BGP - Border Gateway protocol BGP - Border Gateway protocol
CE - Customer Edge CE - Customer Edge
DUT - Device Under Test DUT - Device Under Test
FRR - Fast Reroute FRR - Fast Reroute
IGP - Interior Gateway Protocol IGP - Interior Gateway Protocol
IP - Internet Protocol IP - Internet Protocol
LSP - Label Switched Path LSP - Label Switched Path
MP - Merge Point MP - Merge Point
MPLS - Multi Protocol Label Switching MPLS - Multi Protocol Label Switching
 End of changes. 135 change blocks. 
418 lines changed or deleted 379 lines changed or added

This html diff was produced by rfcdiff 1.33. The latest version is available from http://tools.ietf.org/tools/rfcdiff/