draft-ietf-bmwg-protection-meth-10.txt   draft-ietf-bmwg-protection-meth-11.txt 
Network Working Group R. Papneja Network Working Group R. Papneja
Internet-Draft Huawei Technologies Internet-Draft Huawei Technologies
Intended status: Informational S. Vapiwala Intended status: Standards Track S. Vapiwala
Expires: November 30, 2012 J. Karthik Expires: April 1, 2013 J. Karthik
Cisco Systems Cisco Systems
S. Poretsky S. Poretsky
Allot Communications Allot Communications
S. Rao S. Rao
Qwest Communications Qwest Communications
JL. Le Roux JL. Le Roux
France Telecom France Telecom
May 29, 2012 September 28, 2012
Methodology for Benchmarking MPLS-TE Fast Reroute Protection Methodology for Benchmarking MPLS-TE Fast Reroute Protection
draft-ietf-bmwg-protection-meth-10.txt draft-ietf-bmwg-protection-meth-11.txt
Abstract Abstract
This document describes the methodology for benchmarking MPLS This document describes the methodology for benchmarking MPLS Protection
Protection mechanisms for link and node protection as defined in mechanisms for link and node protection as defined in [RFC 4090].
[RFC4090]. This document provides test methodologies and testbed This document provides test methodologies and testbed setup for
setup for measuring failover times while considering all dependencies measuring failover times of Fast Reroute techniques while considering
that might impact faster recovery of real-time applications bound to all other factors (such as underlying links) that might impact
MPLS traffic engineered (MPLS-TE) tunnels. recovery times for real-time applications bound to MPLS traffic
engineered (MPLS-TE) tunnels.
Status of this Memo Status of this Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
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."
This Internet-Draft will expire on November 30, 2012. This Internet-Draft will expire on April 1, 2013.
Copyright Notice Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the Copyright (c) 2012 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 3, line 12 skipping to change at page 3, line 12
it for publication as an RFC or to translate it into languages other it for publication as an RFC or to translate it into languages other
than English. than English.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5
2. Document Scope . . . . . . . . . . . . . . . . . . . . . . . . 6 2. Document Scope . . . . . . . . . . . . . . . . . . . . . . . . 6
3. Existing Definitions and Requirements . . . . . . . . . . . . 6 3. Existing Definitions and Requirements . . . . . . . . . . . . 6
4. General Reference Topology . . . . . . . . . . . . . . . . . . 7 4. General Reference Topology . . . . . . . . . . . . . . . . . . 7
5. Test Considerations . . . . . . . . . . . . . . . . . . . . . 8 5. Test Considerations . . . . . . . . . . . . . . . . . . . . . 8
5.1. Failover Events . . . . . . . . . . . . . . . . . . . . . 8 5.1. Failover Events [RFC 6414] . . . . . . . . . . . . . . . . 8
5.2. Failure Detection . . . . . . . . . . . . . . . . . . . . 9 5.2. Failure Detection [RFC 6414] . . . . . . . . . . . . . . . 9
5.3. Use of Data Traffic for MPLS Protection benchmarking . . . 9 5.3. Use of Data Traffic for MPLS Protection benchmarking . . . 10
5.4. LSP and Route Scaling . . . . . . . . . . . . . . . . . . 10 5.4. LSP and Route Scaling . . . . . . . . . . . . . . . . . . 10
5.5. Selection of IGP . . . . . . . . . . . . . . . . . . . . . 10 5.5. Selection of IGP . . . . . . . . . . . . . . . . . . . . . 10
5.6. Restoration and Reversion . . . . . . . . . . . . . . . . 10 5.6. Restoration and Reversion [RFC 6414] . . . . . . . . . . . 10
5.7. Offered Load . . . . . . . . . . . . . . . . . . . . . . . 11 5.7. Offered Load . . . . . . . . . . . . . . . . . . . . . . . 11
5.8. Tester Capabilities . . . . . . . . . . . . . . . . . . . 11 5.8. Tester Capabilities . . . . . . . . . . . . . . . . . . . 11
5.9. Failover Time Measurement Methods . . . . . . . . . . . . 12 5.9. Failover Time Measurement Methods . . . . . . . . . . . . 12
6. Reference Test Setup . . . . . . . . . . . . . . . . . . . . . 12 6. Reference Test Setup . . . . . . . . . . . . . . . . . . . . . 12
6.1. Link Protection . . . . . . . . . . . . . . . . . . . . . 13 6.1. Link Protection . . . . . . . . . . . . . . . . . . . . . 13
6.1.1. Link Protection - 1 hop primary (from PLR) and 1 6.1.1. Link Protection - 1 hop primary (from PLR) and 1
hop backup TE tunnels . . . . . . . . . . . . . . . . 13 hop backup TE tunnels . . . . . . . . . . . . . . . . 13
6.1.2. Link Protection - 1 hop primary (from PLR) and 2 6.1.2. Link Protection - 1 hop primary (from PLR) and 2
hop backup TE tunnels . . . . . . . . . . . . . . . . 14 hop backup TE tunnels . . . . . . . . . . . . . . . . 14
6.1.3. Link Protection - 2+ hops (from PLR) primary and 1 6.1.3. Link Protection - 2+ hop (from PLR) primary and 1
hop backup TE tunnels . . . . . . . . . . . . . . . . 14 hop backup TE tunnels . . . . . . . . . . . . . . . . 14
6.1.4. Link Protection - 2+ hop (from PLR) primary and 2 6.1.4. Link Protection - 2+ hop (from PLR) primary and 2
hop backup TE tunnels . . . . . . . . . . . . . . . . 15 hop backup TE tunnels . . . . . . . . . . . . . . . . 15
6.2. Node Protection . . . . . . . . . . . . . . . . . . . . . 16 6.2. Node Protection . . . . . . . . . . . . . . . . . . . . . 16
6.2.1. Node Protection - 2 hop primary (from PLR) and 1 6.2.1. Node Protection - 2 hop primary (from PLR) and 1
hop backup TE tunnels . . . . . . . . . . . . . . . . 16 hop backup TE tunnels . . . . . . . . . . . . . . . . 16
6.2.2. Node Protection - 2 hop primary (from PLR) and 2 6.2.2. Node Protection - 2 hop primary (from PLR) and 2
hop backup TE tunnels . . . . . . . . . . . . . . . . 17 hop backup TE tunnels . . . . . . . . . . . . . . . . 17
6.2.3. Node Protection - 3+ hop primary (from PLR) and 1 6.2.3. Node Protection - 3+ hop primary (from PLR) and 1
hop backup TE tunnels . . . . . . . . . . . . . . . . 18 hop backup TE tunnels . . . . . . . . . . . . . . . . 18
6.2.4. Node Protection - 3+ hop primary (from PLR) and 2 6.2.4. Node Protection - 3+ hop primary (from PLR) and 2
hop backup TE tunnels . . . . . . . . . . . . . . . . 19 hop backup TE tunnels . . . . . . . . . . . . . . . . 19
7. Test Methodology . . . . . . . . . . . . . . . . . . . . . . . 20 7. Test Methodology . . . . . . . . . . . . . . . . . . . . . . . 20
7.1. MPLS FRR Forwarding Performance . . . . . . . . . . . . . 21 7.1. MPLS FRR Forwarding Performance . . . . . . . . . . . . . 20
7.1.1. Headend PLR Forwarding Performance . . . . . . . . . . 21 7.1.1. Headend PLR Forwarding Performance . . . . . . . . . . 20
7.1.2. Mid-Point PLR Forwarding Performance . . . . . . . . . 22 7.1.2. Mid-Point PLR Forwarding Performance . . . . . . . . . 21
7.2. Headend PLR with Link Failure . . . . . . . . . . . . . . 23 7.2. Headend PLR with Link Failure . . . . . . . . . . . . . . 23
7.3. Mid-Point PLR with Link Failure . . . . . . . . . . . . . 25 7.3. Mid-Point PLR with Link Failure . . . . . . . . . . . . . 24
7.4. Headend PLR with Node Failure . . . . . . . . . . . . . . 26 7.4. Headend PLR with Node Failure . . . . . . . . . . . . . . 26
7.5. Mid-Point PLR with Node Failure . . . . . . . . . . . . . 28 7.5. Mid-Point PLR with Node Failure . . . . . . . . . . . . . 27
8. Reporting Format . . . . . . . . . . . . . . . . . . . . . . . 29 8. Reporting Format . . . . . . . . . . . . . . . . . . . . . . . 28
9. Security Considerations . . . . . . . . . . . . . . . . . . . 30 9. Security Considerations . . . . . . . . . . . . . . . . . . . 30
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 31 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 30
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 31 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 30
12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 31 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 30
12.1. Informative References . . . . . . . . . . . . . . . . . . 31 12.1. Informative References . . . . . . . . . . . . . . . . . . 30
12.2. Normative References . . . . . . . . . . . . . . . . . . . 31 12.2. Normative References . . . . . . . . . . . . . . . . . . . 31
Appendix A. Fast Reroute Scalability Table . . . . . . . . . . . 32 Appendix A. Fast Reroute Scalability Table . . . . . . . . . . . 31
Appendix B. Abbreviations . . . . . . . . . . . . . . . . . . . . 35 Appendix B. Abbreviations . . . . . . . . . . . . . . . . . . . . 34
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 36 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 35
1. Introduction 1. Introduction
This document describes the methodology for benchmarking MPLS based This document describes the methodology for benchmarking MPLS Fast
protection mechanisms. This document uses much of the terminology Reroute (FRR) protection mechanisms. This document uses much of the
defined in [RFC6414]. terminology defined in [RFC 6414].For any conflicting content, this
document supersedes [RFC 6414]
MPLS based protection mechanisms provide fast recovery of real-time Protection mechanisms provide recovery of client services from a
services from a planned or an unplanned link or node failures. MPLS planned or an unplanned link or node failures. MPLS FRR protection
protection mechanisms are generally deployed in a network mechanisms are generally deployed in a network infrastructure where
infrastructure where MPLS is used for provisioning of point-to- point MPLS is used for provisioning of point-to- point traffic engineered
traffic engineered tunnels (tunnel). MPLS based protection tunnels (tunnel). MPLS FRR protection mechanisms aim to reduce
mechanisms promise to reduce service disruption period by minimizing service disruption period by minimizing recovery time from most
recovery time from most common failures. common failures.
Network elements from different manufacturers behave differently to Network elements from different manufacturers behave differently to
network failures, which impacts the network's ability and failure network failures, which impacts the network's ability and performance
recovery performance. It therefore becomes imperative for service for failure recovery. It therefore becomes imperative for service
providers to have a common benchmark to verify the performance providers to have a common benchmark to understand the performance
behaviors of these network elements. behaviors of network elements.
There are two factors impacting service availability: frequency of There are two factors impacting service availability: frequency of
failures and duration for which the failures persist. Failures can failures and duration for which the failures persist. Failures can
be classified into two types: correlated and uncorrelated. be classified further into two types: correlated and uncorrelated.
Correlated or uncorrelated failures may be planned or unplanned. Correlated and uncorrelated failures may be planned or unplanned.
Planned failures are predictable. Network implementations should be Planned failures are predictable. Network implementations should be
able to handle both planned and unplanned failures and recover able to handle both planned and unplanned failures and recover
gracefully within a time period acceptable to maintain service gracefully within a time frame to maintain service assurance. Hence,
assurance. Hence, failover recovery time is one of the most failover recovery time is one of the most important benchmark that a
important benchmark that a service provider considers in choosing a service provider considers in choosing the building blocks for their
the building blocks for their network infrastructure. network infrastructure.
A correlated failure is the simultaneous occurrence of two or more A correlated failure is the simultaneous occurrence of two or more
failures. A typical example is failure of a logical resource (e.g. failures. A typical example is failure of a logical resource (e.g.
layer-2 links) due to a dependency on a common physical resource layer-2 links) due to a dependency on a common physical resource
(e.g. common conduit) that fails. Within the context of MPLS-TE (e.g. common conduit) that fails. Within the context of MPLS
protection mechanisms, failures that arise due to Shared Risk Link protection mechanisms, failures that arise due to Shared Risk Link
Groups (SRLG) [RFC4090] can be considered as correlated failures. Groups (SRLG) [RFC 4090] can be considered as correlated failures.
MPLS Fast Re-Route (MPLS-FRR) allows for the possibility that the MPLS FRR [RFC 4090] allows for the possibility that the Label
Label Switched Paths tunnels can be re-optimized following the Switched Paths can be re-optimized in the minutes following Failover.
Failover. IP Traffic would be re-routed according to the preferred IP Traffic would be re-routed according to the preferred path for the
path according to the post-failure topology. Hence, MPLS-FRR may post-failure topology. Thus, MPLS-FRR may include additional steps
include additional steps following the occurrence of the failure following the occurrence of the failure detection [RFC 6414] and
detection [RFC6414] and failover event [RFC6414]. failover event [RFC 6414].
(1) Failover Event - Primary Path (Working Path) fails (1) Failover Event - Primary Path (Working Path) fails
(2) Failure Detection- Failover Event is detected (2) Failure Detection- Failover Event is detected
(3) (3)
a. Failover - Working Path switched to Backup path a. Failover - Working Path switched to Backup path
b. Re-Optimization of Working Path (possible change from b. Re-Optimization of Working Path (possible change from
Backup Path) Backup Path)
(4) Restoration [RFC6414] (4) Restoration [RFC 6414]
(5) Reversion [RFC6414] (5) Reversion [RFC 6414]
2. Document Scope 2. Document Scope
This document provides detailed test cases along with different This document provides detailed test cases along with different
topologies and scenarios that should be considered to effectively topologies and scenarios that should be considered to effectively
benchmark MPLS-TE protection mechanisms and failover times. benchmark MPLS FRR protection mechanisms and failover times on the
Different failover events and scaling considerations are also Data Plane. Different Failover Events and scaling considerations are
provided in this document. also provided in this document.
All benchmarking test-cases defined in this document apply to All benchmarking test-cases defined in this document apply to
facility backup method [RFC4090]. The test cases cover all possible Facility backup [RFC 4090]. The test cases cover all possible
failure scenarios to benchmark the performance of the Device Under failure scenarios and the associated procedures benchmark the
Test (DUT) to recover from failures. Data plane traffic is used to performance of the Device Under Test (DUT) to recover from failures.
benchmark failover times. Data plane traffic is used to benchmark failover times.
Benchmarking of correlated failures is out of scope of this document. Benchmarking of correlated failures is out of scope of this document.
Faster failure detection using Bi-directional Forwarding Detection Detection using Bi-directional Forwarding Detection (BFD) is outside
(BFD) is outside the scope of this document, but is mentioned in the the scope of this document, but mentioned in discussion sections.
discussion sections.
The Performance benchmarking of control plane is outside the scope of The Performance of control plane is outside the scope of this
this benchmarking. benchmarking.
As described above, MPLS-FRR may include a Re-optimization of the As described above, MPLS-FRR may include a Re-optimization of the
Working Path. Characterization of Re-optimization is beyond the Working Path, with possible packet transfer impairments.
scope of this memo. Characterization of Re-optimization is beyond the scope of this memo.
3. Existing Definitions and Requirements 3. Existing Definitions and Requirements
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 BCP 14, RFC 2119 document are to be interpreted as described in BCP 14, RFC 2119
[RFC2119]. RFC 2119 defines the use of these key words to help make [Br97]. RFC 2119 defines the use of these key words to help make the
the intent of standards track documents as clear as possible. While intent of standards track documents as clear as possible. While this
this document uses these keywords, this document is not a standards document uses these keywords, this document is not a standards track
track document. document.
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 [RFC4090]. terminology, some of which is defined in [MPLS-FRR-EXT].
This document uses much of the terminology defined in [RFC6414]. This document uses much of the terminology defined in [RFC 6414].
This document also uses existing terminology defined in other BMWG This document also uses existing terminology defined in other BMWG
Work [RFC1242], [RFC2285], [RFC4689]. Work [Br91], [Ma98], [Po06].
4. General Reference Topology 4. General Reference Topology
Figure 1 illustrates the basic reference testbed and is applicable to Figure 1 illustrates the basic reference testbed and is applicable to
all the test cases defined in this document. Tester comprises a all the test cases defined in this document. The Tester is comprised
Traffic Generator (TG), Test Analyzer (TA) and Emulator. The Tester of a Traffic Generator (TG) & Test Analyzer (TA) and Emulator. A
is connected to the test network and based on test case, the DUT role Tester is connected to the test network and depending upon the test
could vary. The Tester (TG) sends and receives (TA) IP traffic to case, the DUT could vary. The Tester sends and receives IP traffic
the tunnel ingress and performs signaling protocol emulation to to the tunnel ingress and performs signaling protocol emulation to
simulate real network scenarios in a lab environment. The Tester may simulate real network scenarios in a lab environment. The Tester may
also support MPLS-TE signaling to act as the ingress/egress node. also support MPLS-TE signaling to act as the ingress node to the MPLS
tunnel.
+---------------------------+ +---------------------------+
| +------------|---------------+ | +------------|---------------+
| | | | | | | |
| | | | | | | |
+--------+ +--------+ +--------+ +--------+ +--------+ +--------+ +--------+ +--------+ +--------+ +--------+
TG--| R1 |-----| R2 |----| R3 | | R4 | | R5 | TG--| R1 |-----| R2 |----| R3 | | R4 | | R5 |
| |-----| |----| |----| |---| | | |-----| |----| |----| |---| |
+--------+ +--------+ +--------+ +--------+ +--------+ +--------+ +--------+ +--------+ +--------+ +--------+
| | | | | | | | | |
| | | | | | | | | |
| +--------+ | | TA | +--------+ | | TA
+---------| R6 |---------+ | +---------| R6 |---------+ |
| |----------------------+ | |----------------------+
+--------+ +--------+
Fig. 1 Fast Reroute Topology Fig. 1 Fast Reroute Topology
The tester must be able to record the number of lost, duplicate, and The tester MUST record the number of lost, duplicate, and reordered
reordered packets. It should further record arrival and departure packets. It should further record arrival and departure times so
times so that Failover Time, Additive Latency, and Reversion Time can that Failover Time, Additive Latency, and Reversion Time can be
be measured. The tester may be a single device or a test system measured. The tester may be a single device or a test system
emulating different roles along a primary or backup path. emulating all the different roles along a primary or backup path.
The label stack is dependent on the following 3 entities: The label stack is dependent of the following 3 entities:
(1) Type of protection (Link Vs Node) (1) Type of protection (Link Vs Node)
(2) # of remaining hops of the primary tunnel from the Point of (2) # of remaining hops of the primary tunnel from the PLR[RFC
Local Repair (PLR)[RFC6414] 6414]
(3) # of remaining hops of the backup tunnel from the PLR (3) # of remaining hops of the backup tunnel from the PLR
Due to this dependency, it is RECOMMENDED that the benchmarking of Due to this dependency, it is RECOMMENDED that the benchmarking of
failover times be performed on all the topologies provided in section failover times be performed on all the topologies provided in section
6. 6.
5. Test Considerations 5. Test Considerations
This section discusses the fundamentals of MPLS Protection testing: This section discusses the fundamentals of MPLS Protection testing:
skipping to change at page 8, line 42 skipping to change at page 8, line 42
(3) the use of data traffic (3) the use of data traffic
(4) Traffic generation (4) Traffic generation
(5) LSP Scaling (5) LSP Scaling
(6) Reversion of LSP (6) Reversion of LSP
(7) IGP Selection (7) IGP Selection
5.1. Failover Events 5.1. Failover Events [RFC 6414]
The failover to the backup tunnel is primarily triggered by either The failover to the backup tunnel is primarily triggered by either
link or node failures observed downstream of the PLR. Some of these link or node failures observed downstream of the Point of Local
failure events [RFC6414] are listed below. repair (PLR). Some of these failure events are listed below.
Link Failure Events Link Failure Events
- Interface Shutdown on PLR side with POS Alarm - Interface Shutdown on PLR side with POS Alarm
- Interface Shutdown on remote side with POS Alarm - Interface Shutdown on remote side with POS Alarm
- Interface Shutdown on PLR side with RSVP hello enabled - Interface Shutdown on PLR side with RSVP hello enabled
- Interface Shutdown on remote side with RSVP hello enabled - Interface Shutdown on remote side with RSVP hello enabled
- Interface Shutdown on PLR side with BFD - Interface Shutdown on PLR side with BFD
- Interface Shutdown on remote side with BFD - Interface Shutdown on remote side with BFD
- Fiber Pull on the PLR side (Both TX & RX or just the TX) - Fiber Pull on the PLR side (Both TX & RX or just the TX)
- Fiber Pull on the remote side (Both TX & RX or just the RX) - Fiber Pull on the remote side (Both TX & RX or just the RX)
skipping to change at page 9, line 26 skipping to change at page 9, line 26
- Parent interface shutdown on PLR side (an interface bearing multiple - Parent interface shutdown on PLR side (an interface bearing multiple
sub-interfaces) sub-interfaces)
- Parent interface shutdown on remote side - Parent interface shutdown on remote side
Node Failure Events Node Failure Events
- A System reload initiated either by a graceful shutdown - A System reload initiated either by a graceful shutdown
or by a power failure. or by a power failure.
- A system crash due to a software failure or an assert. - A system crash due to a software failure or an assert.
5.2. Failure Detection 5.2. Failure Detection [RFC 6414]
Link failure detection [RFC6414] time depends on the link type and Link failure detection time depends on the link type and failure
failure detection techniques enabled. For SONET/SDH, the alarm type detection protocols running. For SONET/SDH, the alarm type (such as
(such as LOS, AIS, or RDI) can be used. Other link types have layer- LOS, AIS, or RDI) can be used. Other link types have layer-two
two alarms, but they may not provide a short enough failure detection alarms, but they may not provide a short enough failure detection
time. Ethernet based links do not have layer 2 failure indicators, time. Ethernet based links do not have layer 2 failure indicators,
and therefore relies on layer 3 signaling for failure detection. and therefore relies on layer 3 signaling for failure detection.
However for directly connected devices, remote fault indication in However for directly connected devices, remote fault indication in
the Ethernet auto-negotiation scheme could be considered as a type of the ethernet auto-negotiation scheme could be considered as a type of
layer 2 link failure indicator. layer 2 link failure indicator.
BFD and RSVP-hellos may be used as failure detection techniques. MPLS has different failure detection techniques such as BFD, or use
These methods can be used for the layer 3 failure indicators required of RSVP hellos. These methods can be used for the layer 3 failure
by Ethernet based links, or for some other non- Ethernet based links indicators required by Ethernet based links, or for some other non-
to help improve failure detection time. However, these fast failure Ethernet based links to help improve failure detection time.
detection mechanisms are out of scope of this document. However, these fast failure detection mechanisms are out of scope
The test procedures in this document can be used for MPLS-TE The test procedures in this document can be used for a local failure
protection benchmarking due to either a local failure or remote or remote failure scenarios for comprehensive benchmarking and to
failure. evaluate failover performance independent of the failure detection
techniques.
5.3. Use of Data Traffic for MPLS Protection benchmarking 5.3. Use of Data Traffic for MPLS Protection benchmarking
Currently end customers use packet loss as a key metric for Failover Currently end customers use packet loss as a key metric for Failover
Time [RFC6414]. Failover Packet Loss [RFC6414] is an externally Time [RFC 6414]. Failover Packet Loss [RFC 6414] is an externally
observable event and has direct impact on application performance. observable event and has direct impact on application performance.
MPLS-TE protection is expected to minimize the packet loss in the MPLS protection is expected to minimize the packet loss in the event
event of a failure. For this reason it is important to develop a of a failure. For this reason it is important to develop a standard
standard router benchmarking methodology for measuring MPLS router benchmarking methodology for measuring MPLS protection that
protection that uses packet loss as a metric. At a known rate of uses packet loss as a metric. At a known rate of forwarding, packet
forwarding, packet loss can be measured and the failover time can be loss can be measured and the failover time can be determined.
determined. Measurement of control plane recovery and establishing Measurement of control plane signaling to establish backup paths is
backup paths is not enough to verify a timely failover. Failover not enough to verify failover. Failover is best determined when
performance is best determined when packets are actually switched to packets are actually traversing the backup path.
the backup path.
Benefit of using packet loss for calculation of failover time is that An additional benefit of using packet loss for calculation of
it allows use of a black-box test environment. Data traffic is failover time is that it allows use of a black-box test environment.
offered at line-rate to the device under test (DUT) an emulated Data traffic is offered at line-rate to the device under test (DUT)
network failure event is forced to occur, and packet loss is an emulated network failure event is forced to occur, and packet loss
externally measured to calculate the convergence time. This setup is is externally measured to calculate the convergence time. This setup
independent of the DUT architecture. is independent of the DUT architecture.
The methodology considers lost, packet in error, out-of-order In addition, this methodology considers the packets in error and
[RFC4689] and duplicate packets as impaired packets that contribute duplicate packets [Po06] that could have been generated during the
failover process. The methodologies consider lost, out-of-order
[Po06] and duplicate packets to be impaired packets that contribute
to the Failover Time. to the Failover Time.
5.4. LSP and Route Scaling 5.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 tunnel label switched paths (LSP) and installed primary and backup tunnel label switched paths (LSP) and installed
routes. However, the procedure outlined here should be used for any routes. However the procedure outlined here should be used for any
number of LSPs (L) and number of routes protected by the headend as number of LSPs (L) and number of routes protected by PLR(R). The
the PLR(R). The amount of L and R must be recorded. The recommended amount of L and R must be recorded.
table is provided in appendix A.
5.5. Selection of IGP 5.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. See [RFC6412] for IGP options to consider and report. proposed here. See [RFC 6412] for IGP options to consider and
At least one of the IGP is required to be enabled for the procedures report.
discussed in the document.
5.6. Restoration and Reversion 5.6. Restoration and Reversion [RFC 6414]
Path restoration [RFC6414] provides a method to restore an alternate Path restoration provides a method to restore an alternate primary
primary LSP upon failure and to switch traffic from the Backup Path LSP upon failure and to switch traffic from the Backup Path to the
to the restored Primary Path (Reversion). In MPLS-FRR, Reversion can restored Primary Path (Reversion). In MPLS-FRR, Reversion can be
be implemented as Global Reversion or Local Reversion. It is implemented as Global Reversion or Local Reversion. It is important
important to include Restoration and Reversion as a step in each test to include Restoration and Reversion as a step in each test case to
case to measure the amount of packet loss, out of order packets, or measure the amount of packet loss, out of order packets, or duplicate
duplicate packets that occurs in this process. packets that is produced.
Note: In addition to restoration and reversion, re-optimization can Note: In addition to restoration and reversion, re-optimization can
take place while the failure is still not recovered but it depends on take place while the failure is still not recovered but it depends on
the user configuration, and re-optimization timers. the user configuration, and re-optimization timers.
5.7. Offered Load 5.7. Offered Load
It is recommended that there be three or more traffic streams It is suggested that there be three or more traffic streams as long
configured with steady and constant rate of flow for all the streams. as 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 In 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 to target the advertised routes. traffic should be configured towards these routes.
For better accuracy, one may consider provisioning 16 flows, or more At least 16 flows should be used, and more if possible. Prefix-
if possible. IP Prefix-dependency behaviors are key and tests with dependency behaviors are key in IP and tests with route-specific
route-specific flows spread across the routing table reveals such flows spread across the routing table will reveal this dependency.
dependency. Sending traffic to all of the prefixes reachable by the Generating traffic to all of the prefixes reachable by the protected
protected tunnel in a round-robin fashion is not recommended as the tunnel (probably in a Round-Robin fashion, where the traffic is
time interval between two subsequent packets destined to one prefix destined to all the prefixes but one prefix at a time in a cyclic
may be higher than the failover time being measured resulting in manner) is not recommended. The reason why traffic generation is not
inaccurate failover measurements. recommended in a Round-Robin fashion to all the prefixes, one at a
time is that if there are many prefixes reachable through the LSP the
time interval between 2 packets destined to one prefix may be
significantly high and may be comparable with the failover time being
measured which does not aid in getting an accurate failover
measurement.
5.8. Tester Capabilities 5.8. Tester Capabilities
It is RECOMMENDED that the Tester used to execute each test case have It is RECOMMENDED that the Tester used to execute each test case have
the following capabilities: the following capabilities:
1.Ability to establish MPLS-TE tunnels and push/pop labels. 1.Ability to establish MPLS-TE tunnels and push/pop labels.
2.Ability to produce Failover Event [RFC6414]. 2.Ability to produce Failover Event [RFC 6414].
3.Ability to insert a timestamp in each data packet's IP 3.Ability to insert a timestamp in each data packet's IP
payload. payload.
4.An internal time clock to control timestamping, time 4.An internal time clock to control timestamping, time
measurements, and time calculations. measurements, and time calculations.
5.Ability to disable or tune specific Layer-2 and Layer-3 5.Ability to disable or tune specific Layer-2 and Layer-3
protocol functions on any interface(s) such as disabling or protocol functions on any interface(s).
enabling interface IP addresses, auto-negotiation on ethernet
interfaces or scrambling on Packet over SONET interfaces.
6. In a case, if the tester is the headend, it should be able 6.Ability to react upon the receipt of path error from the PLR
to react upon the receipt of path error from the PLR
The Tester MAY be capable to make non-data plane convergence The Tester MAY be capable to make non-data plane convergence
observations and use those observations for measurements. observations and use those observations for measurements.
5.9. Failover Time Measurement Methods 5.9. Failover Time Measurement Methods
Failover Time is calculated using one of the following three methods Failover Time is calculated using one of the following three methods
1. Packet-Loss Based method (PLBM): (Number of packets dropped/ 1. Packet-Loss Based method (PLBM): (Number of packets dropped/
packets per second * 1000) milliseconds. This method could also packets per second * 1000) milliseconds. This method could also
skipping to change at page 12, line 28 skipping to change at page 12, line 33
3. Timestamp Based Method (TBM): This method of failover calculation 3. Timestamp Based Method (TBM): This method of failover calculation
is based on the timestamp that gets transmitted as payload in the is based on the timestamp that gets transmitted as payload in the
packets originated by the generator. The Traffic Analyzer packets originated by the generator. The Traffic Analyzer
records the timestamp of the last packet received before the records the timestamp of the last packet received before the
failover event and the first packet after the failover and failover event and the first packet after the failover and
derives the time based on the difference between these 2 derives the time based on the difference between these 2
timestamps. Note: The payload could also contain sequence timestamps. Note: The payload could also contain sequence
numbers for out-of-order packet calculation and duplicate numbers for out-of-order packet calculation and duplicate
packets. packets.
The timestamp based method would be able to detect Reversion The timestamp based method method would be able to detect Reversion
impairments beyond loss, thus it is RECOMMENDED method as a Failover impairments beyond loss, thus it is RECOMMENDED method as a Failover
Time method. Time method.
6. Reference Test Setup 6. Reference Test Setup
In addition to the general reference topology shown in figure 1, this In addition to the general reference topology shown in figure 1, this
section provides detailed insight into various proposed test setups section provides detailed insight into various proposed test setups
that should be considered for comprehensively benchmarking the that should be considered for comprehensively benchmarking the
failover time in different roles along the primary tunnel failover time in different roles along the primary tunnel
skipping to change at page 13, line 38 skipping to change at page 13, line 41
before failure after failure before failure after 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
Note: Please note the following: Note: Please note the following:
a) For P-P case, R2 and R3 acts as P routers a) For P-P case, R2 and R3 acts as P routers
b) For PE-PE case,R2 acts as PE and R3 acts as a remote PE b) For PE-PE case,R2 acts as PE and R3 acts as a remote PE
c) For PE-P case,R2 acts as a PE router, R3 acts as a P router c) For PE-P case,R2 acts as a PE router, R3 acts as a P router and R5 acts as remote
and R5 acts as remote PE router (Please refer to figure 1 PE router (Please refer to figure 1 for complete setup)
for complete setup) d) For Mid-point case, R1, R2 and R3 act as shown in above figure HE, Midpoint/PLR and
d) For Mid-point case, R1, R2 and R3 act as shown in above figure TE respectively
HE, Midpoint/PLR and TE respectively
6.1.2. Link Protection - 1 hop primary (from PLR) and 2 hop backup TE 6.1.2. Link Protection - 1 hop primary (from PLR) and 2 hop backup TE
tunnels tunnels
+-------+ +--------+ +--------+ +-------+ +--------+ +--------+
| R1 | | R2 | | R3 | | R1 | | R2 | | R3 |
| UR/HE | | HE/MID |PRI | MP/TE | | UR/HE | | HE/MID |PRI | MP/TE |
| |----| PLR |----| | | |----| PLR |----| |
+-------+ +--------+ +--------+ +-------+ +--------+ +--------+
|BKP | |BKP |
skipping to change at page 14, line 33 skipping to change at page 14, line 33
before failure after failure before failure after failure
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
Note: Please note the following: Note: Please note the following:
a) For P-P case, R2 and R3 acts as P routers a) For P-P case, R2 and R3 acts as P routers
b) For PE-PE case,R2 acts as PE and R3 acts as a remote PE b) For PE-PE case,R2 acts as PE and R3 acts as a remote PE
c) For PE-P case,R2 acts as a PE router, R3 acts as a P router c) For PE-P case,R2 acts as a PE router, R3 acts as a P router and R5 acts as remote
and R5 acts as remote PE router (Please refer to figure 1 PE router (Please refer to figure 1 for complete setup)
for complete setup) d) For Mid-point case, R1, R2 and R3 act as shown in above figure HE, Midpoint/PLR
d) For Mid-point case, R1, R2 and R3 act as shown in above figure and TE respectively
HE, Midpoint/PLR and TE respectively
6.1.3. Link Protection - 2+ hops (from PLR) primary and 1 hop backup TE 6.1.3. Link Protection - 2+ hop (from PLR) primary and 1 hop backup TE
tunnels tunnels
+--------+ +--------+ +--------+ +--------+ +--------+ +--------+ +--------+ +--------+
| R1 | | R2 |PRI | R3 |PRI | R4 | | R1 | | R2 |PRI | R3 |PRI | R4 |
| UR/HE |----| HE/MID |----| MP/MID |------| TE | | UR/HE |----| HE/MID |----| MP/MID |------| TE |
| | | PLR |----| | | | | | | PLR |----| | | |
+--------+ +--------+ BKP+--------+ +--------+ +--------+ +--------+ BKP+--------+ +--------+
Figure 4. Figure 4.
Traffic Num of Labels Num of labels Traffic Num of Labels Num 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
Note: Please note the following: Note: Please note the following:
a) For P-P case, R2, R3 and R4 acts as P routers a) For P-P case, R2, R3 and R4 acts as P routers
b) For PE-PE case,R2 acts as PE and R4 acts as a remote PE b) For PE-PE case,R2 acts as PE and R4 acts as a remote PE
c) For PE-P case,R2 acts as a PE router, R3 acts as a P router c) For PE-P case,R2 acts as a PE router, R3 acts as a P router and R5 acts as remote
and R5 acts as remote PE router (Please refer to figure 1 PE router (Please refer to figure 1 for complete setup)
for complete setup) d) For Mid-point case, R1, R2, R3 and R4 act as shown in above figure HE, Midpoint/PLR
d) For Mid-point case, R1, R2, R3 and R4 act as shown in above and TE respectively
figure HE, Midpoint/PLR and TE respectively
6.1.4. Link Protection - 2+ hop (from PLR) primary and 2 hop backup TE 6.1.4. Link Protection - 2+ hop (from PLR) primary and 2 hop backup TE
tunnels tunnels
+--------+ +--------+PRI +--------+ PRI +--------+ +--------+ +--------+PRI +--------+ PRI +--------+
| R1 | | R2 | | R3 | | R4 | | R1 | | R2 | | R3 | | R4 |
| UR/HE |----| HE/MID |----| MP/MID|------| TE | | UR/HE |----| HE/MID |----| MP/MID|------| TE |
| | | PLR | | | | | | | | PLR | | | | |
+--------+ +--------+ +--------+ +--------+ +--------+ +--------+ +--------+ +--------+
BKP| | BKP| |
| +--------+ | | +--------+ |
skipping to change at page 16, line 29 skipping to change at page 16, line 29
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
Note: Please note the following: Note: Please note the following:
a) For P-P case, R2, R3 and R4 acts as P routers a) For P-P case, R2, R3 and R4 acts as P routers
b) For PE-PE case,R2 acts as PE and R4 acts as a remote PE b) For PE-PE case,R2 acts as PE and R4 acts as a remote PE
c) For PE-P case,R2 acts as a PE router, R3 acts as a P router c) For PE-P case,R2 acts as a PE router, R3 acts as a P router and R5 acts as remote
and R5 acts as remote PE router (Please refer to figure 1 PE router (Please refer to figure 1 for complete setup)
for complete setup) d) For Mid-point case, R1, R2, R3 and R4 act as shown in above figure HE, Midpoint/PLR
d) For Mid-point case, R1, R2, R3 and R4 act as shown in above and TE respectively
figure HE, Midpoint/PLR and TE respectively
6.2. Node Protection 6.2. Node Protection
6.2.1. Node Protection - 2 hop primary (from PLR) and 1 hop backup TE 6.2.1. Node Protection - 2 hop primary (from PLR) and 1 hop backup TE
tunnels tunnels
+--------+ +--------+ +--------+ +--------+ +--------+ +--------+ +--------+ +--------+
| R1 | | R2 |PRI | R3 | PRI | R4 | | R1 | | R2 |PRI | R3 | PRI | R4 |
| UR/HE |----| HE/MID |----| MID |------| MP/TE | | UR/HE |----| HE/MID |----| MID |------| MP/TE |
| | | PLR | | | | | | | | PLR | | | | |
+--------+ +--------+ +--------+ +--------+ +--------+ +--------+ +--------+ +--------+
skipping to change at page 17, line 25 skipping to change at page 17, line 25
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
Note: Please note the following: Note: Please note the following:
a) For P-P case, R2, R3 and R3 acts as P routers a) For P-P case, R2, R3 and R3 acts as P routers
b) For PE-PE case,R2 acts as PE and R4 acts as a remote PE b) For PE-PE case,R2 acts as PE and R4 acts as a remote PE
c) For PE-P case,R2 acts as a PE router, R4 acts as a P router c) For PE-P case,R2 acts as a PE router, R4 acts as a P router and R5 acts as remote
and R5 acts as remote PE router (Please refer to figure 1 PE router (Please refer to figure 1 for complete setup)
for complete setup) d) For Mid-point case, R1, R2, R3 and R4 act as shown in above figure HE, Midpoint/PLR
d) For Mid-point case, R1, R2, R3 and R4 act as shown in above and TE respectively
figure HE, Midpoint/PLR and TE respectively
6.2.2. Node Protection - 2 hop primary (from PLR) and 2 hop backup TE 6.2.2. Node Protection - 2 hop primary (from PLR) and 2 hop backup TE
tunnels tunnels
+--------+ +--------+ +--------+ +--------+ +--------+ +--------+ +--------+ +--------+
| R1 | | R2 | | R3 | | R4 | | R1 | | R2 | | R3 | | R4 |
| UR/HE | | HE/MID |PRI | MID |PRI | MP/TE | | UR/HE | | HE/MID |PRI | MID |PRI | MP/TE |
| |----| PLR |----| |----| | | |----| PLR |----| |----| |
+--------+ +--------+ +--------+ +--------+ +--------+ +--------+ +--------+ +--------+
| | | |
skipping to change at page 18, line 18 skipping to change at page 18, line 16
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
Note: Please note the following: Note: Please note the following:
a) For P-P case, R2, R3 and R4 acts as P routers a) For P-P case, R2, R3 and R4 acts as P routers
b) For PE-PE case,R2 acts as PE and R4 acts as a remote PE b) For PE-PE case,R2 acts as PE and R4 acts as a remote PE
c) For PE-P case,R2 acts as a PE router, R4 acts as a c) For PE-P case,R2 acts as a PE router, R4 acts as a P router and R5 acts as remote
P router and R5 acts as remote PE router (Please refer PE router (Please refer to figure 1 for complete setup)
to figure 1 for complete setup) d) For Mid-point case, R1, R2, R3 and R4 act as shown in above figure HE, Midpoint/PLR
d) For Mid-point case, R1, R2, R3 and R4 act as shown in and TE respectively
above figure HE, Midpoint/PLR and TE respectively
6.2.3. Node Protection - 3+ hop primary (from PLR) and 1 hop backup TE 6.2.3. Node Protection - 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 |
| UR/HE |--| HE/MID |---| MID |---| MP |---| TE | | UR/HE |--| HE/MID |---| MID |---| MP |---| TE |
| | | PLR | | | | | | | | | | PLR | | | | | | |
+--------+ +--------+ +--------+ +--------+ +--------+ +--------+ +--------+ +--------+ +--------+ +--------+
BKP| | BKP| |
-------------------------- --------------------------
Figure 8. Figure 8.
skipping to change at page 19, line 25 skipping to change at page 19, line 5
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
Note: Please note the following: Note: Please note the following:
a) For P-P case, R2, R3, R4 and R5 acts as P routers a) For P-P case, R2, R3, R4 and R5 acts as P routers
b) For PE-PE case,R2 acts as PE and R5 acts as a remote PE b) For PE-PE case,R2 acts as PE and R5 acts as a remote PE
c) For PE-P case,R2 acts as a PE router, R4 acts as a P router c) For PE-P case,R2 acts as a PE router, R4 acts as a P router and R5 acts as remote
and R5 acts as remote PE router (Please refer to figure 1 PE router (Please refer to figure 1 for complete setup)
for complete setup) d) For Mid-point case, R1, R2, R3, R4 and R5 act as shown in above figure HE,
d) For Mid-point case, R1, R2, R3, R4 and R5 act as shown in Midpoint/PLR and TE respectively
above figure HE, Midpoint/PLR and TE respectively
6.2.4. Node Protection - 3+ hop primary (from PLR) and 2 hop backup TE 6.2.4. Node Protection - 3+ hop primary (from PLR) and 2 hop backup TE
tunnels tunnels
+--------+ +--------+ +--------+ +--------+ +--------+ +--------+ +--------+ +--------+ +--------+ +--------+
| R1 | | R2 | | R3 | | R4 | | R5 | | R1 | | R2 | | R3 | | R4 | | R5 |
| UR/HE | | HE/MID |PRI| MID |PRI| MP |PRI| TE | | UR/HE | | HE/MID |PRI| MID |PRI| MP |PRI| TE |
| |-- | PLR |---| |---| |---| | | |-- | PLR |---| |---| |---| |
+--------+ +--------+ +--------+ +--------+ +--------+ +--------+ +--------+ +--------+ +--------+ +--------+
BKP| | BKP| |
skipping to change at page 20, line 30 skipping to change at page 19, line 40
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
Note: Please note the following: Note: Please note the following:
a) For P-P case, R2, R3, R4 and R5 acts as P routers a) For P-P case, R2, R3, R4 and R5 acts as P routers
b) For PE-PE case,R2 acts as PE and R5 acts as a remote PE b) For PE-PE case,R2 acts as PE and R5 acts as a remote PE
c) For PE-P case,R2 acts as a PE router, R4 acts as a P router c) For PE-P case,R2 acts as a PE router, R4 acts as a P router and R5 acts as remote
and R5 acts as remote PE router (Please refer to figure 1 PE router (Please refer to figure 1 for complete setup)
for complete setup) d) For Mid-point case, R1, R2, R3, R4 and R5 act as shown in above figure HE,
d) For Mid-point case, R1, R2, R3, R4 and R5 act as shown in Midpoint/PLR and TE respectively
above figure HE, Midpoint/PLR and TE respectively
7. Test Methodology 7. 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 tunnels are configured to be alike in terms of bandwidth the primary tunnels 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 RECOMMENDED depth applicable as seen with current deployments, it is RECOMMENDED
to perform all of the test cases provided in this section. The to perform all of the test cases provided in this section. The
forwarding performance test cases in section 7.1 MUST be performed forwarding performance test cases in section 7.1 MUST be performed
prior to performing the failover test cases. prior to performing the failover test cases.
The considerations of Section 4 of [RFC2544] are applicable when The considerations of Section 4 of [RFC 2544] are applicable when
evaluating the results obtained using these methodologies as well. evaluating the results obtained using these methodologies as well.
7.1. MPLS FRR Forwarding Performance 7.1. MPLS FRR Forwarding Performance
Benchmarking Failover Time [RFC6414] for MPLS protection first Benchmarking Failover Time [RFC 6414] for MPLS protection first
requires baseline measurement of the forwarding performance of the requires baseline measurement of the forwarding performance of the
test topology including the DUT. Forwarding performance is test topology including the DUT. Forwarding performance is
benchmarked by the Throughput as defined in [RFC5695] and measured in benchmarked by the Throughput as defined in [MPLS-FWD] and measured
units packet per second (pps). This section provides two test cases in units pps. This section provides two test cases to benchmark
to benchmark forwarding performance. These are with the DUT forwarding performance. These are with the DUT configured as a
configured as a Headend PLR, Mid-Point PLR, and Egress PLR. Headend PLR, Mid-Point PLR, and Egress PLR.
7.1.1. Headend PLR Forwarding Performance 7.1.1. Headend PLR Forwarding Performance
Objective: Objective:
To benchmark the maximum rate (pps) on the PLR (as headend) over To benchmark the maximum rate (pps) on the PLR (as headend) over
primary LSP and backup LSP. primary LSP and backup LSP.
Test Setup: Test Setup:
skipping to change at page 22, line 9 skipping to change at page 21, line 18
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 is enabled and ready. 4. Verify Fast Reroute protection is enabled and ready.
5. Setup traffic streams as described in section 5.7. 5. Setup traffic streams as described in section 5.7.
6. Send the required MPLS traffic over the primary LSP to 6. Send MPLS traffic over the primary LSP at the Throughput
achieve the throughput supported by the DUT (section 6, RFC supported by the DUT (section 6, RFC 2544).
2544).
7. Record the Throughput over the primary LSP. 7. Record the Throughput over the primary LSP.
8. Trigger a link failure as described in section 5.1. 8. Trigger a link failure as described in section 5.1.
9. Verify that the offered load gets mapped to the backup tunnel 9. Verify that the offered load gets mapped to the backup tunnel
and measure the Additive Backup Delay (RFC 6414). and measure the Additive Backup Delay (RFC 6414).
10. 30 seconds after Failover, stop the offered load and measure 10. 30 seconds after Failover, stop the offered load and measure
the Throughput, Packet Loss, Out-of-Order Packets, and the Throughput, Packet Loss, Out-of-Order Packets, and
skipping to change at page 24, line 48 skipping to change at page 24, line 17
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 for the offered load as described in 5. Setup traffic streams for the offered load as described in
section 5.7. section 5.7.
6. Provide the offered load from the tester at the Throughput 6. Provide the offered load from the tester at the Throughput
[RFC1242] level obtained from test case 7.1.1. [Br91] level obtained from test case 7.1.1.
7. Verify traffic is switched over Primary LSP without packet 7. Verify traffic is switched over Primary LSP without packet
loss. loss.
8. Trigger a link failure as described in section 5.1. 8. Trigger a link failure as described in section 5.1.
9. Verify that the offered load gets mapped to the backup tunnel 9. Verify that the offered load gets mapped to the backup tunnel
and measure the Additive Backup Delay. and measure the Additive Backup Delay.
10. 30 seconds after Failover [RFC6414], stop the offered load 10. 30 seconds after Failover [RFC 6414], stop the offered load
and measure the total Failover Packet Loss [RFC6414]. and measure the total Failover Packet Loss [RFC 6414].
11. Calculate the Failover Time [RFC6414] benchmark using the 11. Calculate the Failover Time [RFC 6414] benchmark using the
selected Failover Time Calculation Method (TBLM, PLBM, or selected Failover Time Calculation Method (TBLM, PLBM, or
TBM) [RFC6414]. TBM) [RFC 6414].
12. Restart the offered load and restore the primary LSP to 12. Restart the offered load and restore the primary LSP to
verify Reversion [RFC6414] occurs and measure the Reversion verify Reversion [RFC 6414] occurs and measure the Reversion
Packet Loss [RFC6414]. Packet Loss [RFC 6414].
13. Calculate the Reversion Time [RFC6414] benchmark using the 13. Calculate the Reversion Time [RFC 6414] benchmark using the
selected Failover Time Calculation Method (TBLM, PLBM, or selected Failover Time Calculation Method (TBLM, PLBM, or
TBM) [RFC6414]. TBM) [RFC 6414].
14. Verify Headend signals new LSP and protection should be in 14. Verify Headend signals new LSP and protection should be in
place again. place again.
IT is RECOMMENDED that this procedure be repeated for each of the IT is RECOMMENDED that this procedure be repeated for each of the
link failure triggers defined in section 5.1. link failure triggers defined in section 5.1.
7.3. Mid-Point PLR with Link Failure 7.3. Mid-Point PLR with Link Failure
Objective: Objective:
skipping to change at page 27, line 39 skipping to change at page 27, line 11
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 for the offered load as described in 5. Setup traffic streams for the offered load as described in
section 5.7. section 5.7.
6. Provide the offered load from the tester at the Throughput 6. Provide the offered load from the tester at the Throughput
[RFC1242] level obtained from test case 7.1.1. [Br91] level obtained from test case 7.1.1.
7. Verify traffic is switched over Primary LSP without packet 7. Verify traffic is switched over Primary LSP without packet
loss. loss.
8. Trigger a node failure as described in section 5.1. 8. Trigger a node failure as described in section 5.1.
9. Perform steps 9 through 14 in 7.2 Headend PLR with Link 9. Perform steps 9 through 14 in 7.2 Headend PLR with Link
Failure. Failure.
IT is RECOMMENDED that this procedure be repeated for each of the IT is RECOMMENDED that this procedure be repeated for each of the
skipping to change at page 29, line 11 skipping to change at page 28, line 26
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 for the offered load as described in 5. Setup traffic streams for the offered load as described in
section 5.7. section 5.7.
6. Provide the offered load from the tester at the Throughput 6. Provide the offered load from the tester at the Throughput
[RFC1242] level obtained from test case 7.1.1. [Br91] level obtained from test case 7.1.1.
7. Verify traffic is switched over Primary LSP without packet 7. Verify traffic is switched over Primary LSP without packet
loss. loss.
8. Trigger a node failure as described in section 5.1. 8. Trigger a node failure as described in section 5.1.
9. Perform steps 9 through 14 in 7.2 Headend PLR with Link 9. Perform steps 9 through 14 in 7.2 Headend PLR with Link
Failure. Failure.
IT is RECOMMENDED that this procedure be repeated for each of the IT is RECOMMENDED that this procedure be repeated for each of the
skipping to change at page 31, line 12 skipping to change at page 30, line 27
Further, benchmarking is performed on a "black-box" basis, relying Further, benchmarking is performed on a "black-box" basis, relying
solely on measurements observable external to the DUT/SUT. solely on measurements observable external to the DUT/SUT.
Special capabilities SHOULD NOT exist in the DUT/SUT specifically for Special capabilities SHOULD NOT exist in the DUT/SUT specifically for
benchmarking purposes. Any implications for network security arising benchmarking purposes. Any implications for network security arising
from the DUT/SUT SHOULD be identical in the lab and in production from the DUT/SUT SHOULD be identical in the lab and in production
networks. networks.
10. IANA Considerations 10. IANA Considerations
This document does not require any new allocations by IANA. This draft does not require any new allocations by IANA.
11. Acknowledgements 11. Acknowledgements
We would like to thank Jean Philip Vasseur for his invaluable input We would like to thank Jean Philip Vasseur for his invaluable input
to the document, Curtis Villamizar for his contribution in suggesting to the document, Curtis Villamizar for his contribution in suggesting
text on definition and need for benchmarking Correlated failures and text on definition and need for benchmarking Correlated failures and
Bhavani Parise for his textual input and review. Additionally we Bhavani Parise for his textual input and review. Additionally we
would like to thank Al Morton, Arun Gandhi, Amrit Hanspal, Karu would like to thank Al Morton, Arun Gandhi, Amrit Hanspal, Karu
Ratnam, Raveesh Janardan, Andrey Kiselev, and Mohan Nanduri for their Ratnam, Raveesh Janardan, Andrey Kiselev, and Mohan Nanduri for their
formal reviews of this document. formal reviews of this document.
skipping to change at page 31, line 43 skipping to change at page 31, line 13
Control Mechanisms", RFC 4689, October 2006. Control Mechanisms", RFC 4689, October 2006.
12.2. Normative References 12.2. Normative References
[RFC1242] Bradner, S., "Benchmarking terminology for network [RFC1242] Bradner, S., "Benchmarking terminology for network
interconnection devices", RFC 1242, July 1991. interconnection devices", RFC 1242, July 1991.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2544] Bradner, S. and J. McQuaid, "Benchmarking Methodology for
Network Interconnect Devices", RFC 2544, March 1999.
[RFC4090] Pan, P., Swallow, G., and A. Atlas, "Fast Reroute [RFC4090] Pan, P., Swallow, G., and A. Atlas, "Fast Reroute
Extensions to RSVP-TE for LSP Tunnels", RFC 4090, Extensions to RSVP-TE for LSP Tunnels", RFC 4090,
May 2005. May 2005.
[RFC5695] Akhter, A., Asati, R., and C. Pignataro, "MPLS Forwarding [RFC5695] Akhter, A., Asati, R., and C. Pignataro, "MPLS Forwarding
Benchmarking Methodology for IP Flows", RFC 5695, Benchmarking Methodology for IP Flows", RFC 5695,
November 2009. November 2009.
[RFC6412] Poretsky, S., Imhoff, B., and K. Michielsen, "Terminology
for Benchmarking Link-State IGP Data-Plane Route
Convergence", RFC 6412, November 2011.
[RFC6414] Poretsky, S., Papneja, R., Karthik, J., and S. Vapiwala,
"Benchmarking Terminology for Protection Performance",
RFC 6414, November 2011.
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 (DUT), Based on the features supported by the device under test (DUT),
appropriate scaling limits can be used for the test bed. appropriate scaling limits can be used for the test bed.
A1. FRR IGP Table A1. FRR IGP Table
No. of Headend TE Tunnels IGP Prefixes No. of Headend TE Tunnels IGP Prefixes
(L) (R)
1 100 1 100
1 500 1 500
1 1000 1 1000
1 2000 1 2000
1 5000 1 5000
skipping to change at page 34, line 5 skipping to change at page 33, line 5
100 100 100 100
500 500 500 500
1000 1000 1000 1000
2000 2000 2000 2000
A2. FRR VPN Table A2. FRR VPN Table
No. of Headend TE Tunnels VPNv4 Prefixes No. of Headend TE Tunnels VPNv4 Prefixes
(L) (R)
1 100 1 100
1 500 1 500
1 1000 1 1000
1 2000 1 2000
1 5000 1 5000
skipping to change at page 35, line 5 skipping to change at page 34, line 5
2 (Load Balance) Max 2 (Load Balance) Max
A3. FRR Mid-Point LSP Table A3. FRR Mid-Point LSP Table
No of Mid-point TE LSPs could be configured at recommended levels - No of Mid-point TE LSPs could be configured at recommended levels -
100, 500, 1000, 2000, or max supported number. 100, 500, 1000, 2000, or max supported number.
A2. FRR VC Table A2. FRR VC Table
No. of Headend TE Tunnels VC entries No. of Headend TE Tunnels VC entries
(L) (R)
1 100 1 100
1 500 1 500
1 1000 1 1000
1 2000 1 2000
1 Max 1 Max
100 100 100 100
500 500 500 500
1000 1000 1000 1000
2000 2000 2000 2000
skipping to change at page 36, line 38 skipping to change at page 35, line 38
Email: jkarthik@cisco.com Email: jkarthik@cisco.com
Scott Poretsky Scott Poretsky
Allot Communications Allot Communications
USA USA
Email: sporetsky@allot.com Email: sporetsky@allot.com
Shankar Rao Shankar Rao
Qwest Communications
950 17th Street 950 17th Street
Suite 1900 Suite 1900
Denver, CO 80210 Denver, CO 80210
USA USA
Email: shankar.rao@du.edu Email: shankar.rao@du.edu
JL. Le Roux JL. Le Roux
France Telecom France Telecom
2 av Pierre Marzin 2 av Pierre Marzin
22300 Lannion 22300 Lannion
 End of changes. 89 change blocks. 
255 lines changed or deleted 236 lines changed or added

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