draft-ietf-bmwg-protection-meth-12.txt   draft-ietf-bmwg-protection-meth-13.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: Informational S. Vapiwala
Expires: May 9, 2013 J. Karthik Expires: May 13, 2013 J. Karthik
Cisco Systems Cisco Systems
S. Poretsky S. Poretsky
Allot Communications Allot Communications
S. Rao S. Rao
Qwest Communications Qwest Communications
J. Roux JL. Le Roux
France Telecom France Telecom
November 5, 2012 November 14, 2012
Methodology for Benchmarking MPLS-TE Fast Reroute Protection Methodology for Benchmarking MPLS-TE Fast Reroute Protection
draft-ietf-bmwg-protection-meth-12.txt draft-ietf-bmwg-protection-meth-13.txt
Abstract Abstract
This draft describes the methodology for benchmarking MPLS Protection This draft describes the methodology for benchmarking MPLS Fast
mechanisms for link and node protection as defined in [RFC 4090]. Reroute (FRR) protection mechanisms for link and node protection.
This document provides test methodologies and testbed setup for This document provides test methodologies and testbed setup for
measuring failover times of Fast Reroute techniques while considering measuring failover times of Fast Reroute techniques while considering
all other factors (such as underlying links) that might impact factors (such as underlying links) that might impact
recovery times for real-time applications bound to MPLS traffic recovery times for real-time applications bound to MPLS traffic
engineered (MPLS-TE) tunnels. 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
skipping to change at page 5, line 7 skipping to change at page 5, line 7
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 30 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 30
12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 30 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 30
12.1. Informative References . . . . . . . . . . . . . . . . . . 30 12.1. Informative References . . . . . . . . . . . . . . . . . . 30
12.2. Normative References . . . . . . . . . . . . . . . . . . . 30 12.2. Normative References . . . . . . . . . . . . . . . . . . . 30
Appendix A. Fast Reroute Scalability Table . . . . . . . . . . . 30 Appendix A. Fast Reroute Scalability Table . . . . . . . . . . . 30
Appendix B. Abbreviations . . . . . . . . . . . . . . . . . . . . 33 Appendix B. Abbreviations . . . . . . . . . . . . . . . . . . . . 33
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 34 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 34
1. Introduction 1. Introduction
This draft describes the methodology for benchmarking MPLS Fast This document describes the methodology for benchmarking MPLS Fast
Reroute (FRR) protection mechanisms. This document uses much of the Reroute (FRR) protection mechanisms. This document uses much of the
terminology defined in [RFC 6414]. terminology defined in [RFC 6414].
Protection mechanisms provide recovery of client services from a Protection mechanisms provide recovery of client services from a
planned or an unplanned link or node failures. MPLS FRR protection planned or an unplanned link or node failures. MPLS FRR protection
mechanisms are generally deployed in a network infrastructure where mechanisms are generally deployed in a network infrastructure where
MPLS is used for provisioning of point-to- point traffic engineered MPLS is used for provisioning of point-to-point traffic engineered
tunnels (tunnel). MPLS FRR protection mechanisms aim to reduce tunnels (tunnel). MPLS FRR protection mechanisms aim to reduce
service disruption period by minimizing recovery time from most service disruption period by minimizing 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 performance network failures, which impacts the network's ability and performance
for failure recovery. It therefore becomes imperative for service for failure recovery. It therefore becomes imperative for service
providers to have a common benchmark to understand the performance providers to have a common benchmark to understand the performance
behaviors of network elements. behaviors of network elements.
skipping to change at page 6, line 29 skipping to change at page 6, line 29
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 FRR protection mechanisms and failover times on the benchmark MPLS FRR protection mechanisms and failover times on the
Data Plane. Different Failover Events and scaling considerations are Data Plane. Different Failover Events and scaling considerations are
also 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 [RFC 4090]. The test cases cover all possible Facility backup [RFC 4090]. The test cases cover set of interesting
failure scenarios and the associated procedures benchmark the failure scenarios and the associated procedures benchmark the
performance of the Device Under Test (DUT) to recover from failures. performance of the Device Under Test (DUT) to recover from failures.
Data plane traffic is used to 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.
Detection using Bi-directional Forwarding Detection (BFD) is outside Detection using Bi-directional Forwarding Detection (BFD) is outside
the scope of this document, but mentioned in discussion sections. the scope of this document, but mentioned in discussion sections.
The Performance of control plane is outside the scope of this The Performance of control plane is outside the scope of this
benchmarking. benchmarking.
skipping to change at page 7, line 14 skipping to change at page 7, line 14
document are to be interpreted as described in BCP 14, [RFC 2119]. document are to be interpreted as described in BCP 14, [RFC 2119].
While [RFC 2119] defines the use of these key words primarily for While [RFC 2119] defines the use of these key words primarily for
Standards Track documents however, this Informational track document Standards Track documents however, this Informational track document
may use some of uses these keywords. may use some of uses these keywords.
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 [RFC 4090]. terminology, some of which is defined in [RFC 4090].
This document uses much of the terminology defined in [RFC 6414]. 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 [RFC 1242], [RFC 2285], [RFC 4689]. Work [RFC 1242], [RFC 2285], [RFC 4689]. Appendix B provide
abbreviations used in the document
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. The Tester is comprised all the test cases defined in this document. The Tester is comprised
of a Traffic Generator (TG) & Test Analyzer (TA) and Emulator. A of a Traffic Generator (TG) & Test Analyzer (TA) and Emulator. A
Tester is connected to the test network and depending upon the test Tester is connected to the test network and depending upon the test
case, the DUT could vary. The Tester sends and receives IP traffic case, the DUT could vary. The Tester sends and receives IP traffic
to 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 node to the MPLS also support MPLS-TE signaling to act as the ingress node to the MPLS
tunnel. tunnel. The lines in figures represent physical connections.
+---------------------------+ +---------------------------+
| +------------|---------------+ | +------------|---------------+
| | | | | | | |
| | | | | | | |
+--------+ +--------+ +--------+ +--------+ +--------+ +--------+ +--------+ +--------+ +--------+ +--------+
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 record the number of lost, duplicate, and reordered The tester MUST record the number of lost, duplicate, and out-of-order
packets. It should further record arrival and departure times so packets. It should further record arrival and departure times so
that Failover Time, Additive Latency, and Reversion Time can be that Failover Time, Additive Latency, and Reversion Time can 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 all the different roles along a primary or backup path. emulating all the different roles along a primary or backup path.
The label stack is dependent of 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 PLR[RFC (2) # of remaining hops of the primary tunnel from the PLR[RFC
skipping to change at page 8, line 28 skipping to change at page 8, line 28
(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:
(1) The types of network events that causes failover (1) The types of network events that causes failover (section 5.1)
(2) Indications for failover (2) Indications for failover (section 5.2)
(3) the use of data traffic (3) the use of data traffic (section 5.3)
(4) Traffic generation (4) LSP Scaling (Section 5.4)
(5) LSP Scaling (5) IGP Selection (Section 5.5)
(6) Reversion of LSP (6) Reversion of LSP (Section 5.6)
(7) IGP Selection (7) Traffic generation (section 5.7)
5.1. Failover Events [RFC 6414] 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 Point of Local link or node failures observed downstream of the Point of Local
repair (PLR). Some of these failure events are listed below. repair (PLR). The 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 42 skipping to change at page 9, line 42
time. Ethernet based links enabled with MPLS/IP do not have layer 2 time. Ethernet based links enabled with MPLS/IP do not have layer 2
failure indicators, and therefore relies on layer 3 signaling for failure indicators, and therefore relies on layer 3 signaling for
failure detection. However for directly connected devices, remote failure detection. However for directly connected devices, remote
fault indication in the ethernet auto-negotiation scheme could be fault indication in the ethernet auto-negotiation scheme could be
considered as a type of layer 2 link failure indicator. considered as a type of layer 2 link failure indicator.
MPLS has different failure detection techniques such as BFD, or use MPLS has different failure detection techniques such as BFD, or use
of RSVP hellos. These methods can be used for the layer 3 failure of RSVP hellos. These methods can be used for the layer 3 failure
indicators required by Ethernet based links, or for some other non- indicators required by Ethernet based links, or for some other non-
Ethernet based links to help improve failure detection time. Ethernet based links to help improve failure detection time.
However, these fast failure detection mechanisms are out of scope However, these fast failure detection mechanisms are out of scope.
The test procedures in this document can be used for a local failure The test procedures in this document can be used for a local failure
or remote failure scenarios for comprehensive benchmarking and to or remote failure scenarios for comprehensive benchmarking and to
evaluate failover performance independent of the failure detection evaluate failover performance independent of the failure detection
techniques. 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 [RFC 6414]. Failover Packet Loss [RFC 6414] is an externally Time [RFC 6414]. Failover Packet Loss [RFC 6414] is an externally
skipping to change at page 11, line 19 skipping to change at page 11, line 19
the user configuration, and re-optimization timers. the user configuration, and re-optimization timers.
5.7. Offered Load 5.7. Offered Load
It is suggested that there be three or more traffic streams as long It is suggested that there be three or more traffic streams as long
as there is a steady and constant rate of flow for all 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 towards these routes. traffic should be configured towards these routes.
At least 16 flows should be used, and more if possible. Prefix- Prefix-dependency behaviors are key in IP and tests with route-specific
dependency behaviors are key in IP and tests with route-specific
flows spread across the routing table will reveal this dependency. flows spread across the routing table will reveal this dependency.
Generating traffic to all of the prefixes reachable by the protected Generating traffic to all of the prefixes reachable by the protected
tunnel (probably in a Round-Robin fashion, where the traffic is tunnel (probably in a Round-Robin fashion, where the traffic is
destined to all the prefixes but one prefix at a time in a cyclic destined to all the prefixes but one prefix at a time in a cyclic
manner) is not recommended. The reason why traffic generation is not manner) is not recommended. Round-Robin traffic generation
recommended in a Round-Robin fashion to all the prefixes, one at a is not recommended to all prefixes, as time to hit all the prefixes
time is that if there are many prefixes reachable through the LSP the may be higher than the failover time. This phenomenon will reduce
time interval between 2 packets destined to one prefix may be the granularity of the measured results and the results observed
significantly high and may be comparable with the failover time being may not be accurate.
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 [RFC 6414]. 2.Ability to produce Failover Event [RFC 6414].
skipping to change at page 29, line 33 skipping to change at page 29, line 33
Number of mid-point tunnels Number of tunnels Number of mid-point tunnels Number of tunnels
Number of Prefixes protected by Number of LSPs Number of Prefixes protected by Number of LSPs
Primary Primary
Topology being used Section number, and Topology being used Section number, and
figure reference figure reference
Failover Event Event type Failover Event Event type
Re-optimization Yes/No Re-optimization Yes/No
Benchmarks (to be recorded for each test case): Benchmarks (to be recorded for each test case):
Failover- Failover-
Failover Time seconds Failover Time seconds
Failover Packet Loss packets Failover Packet Loss packets
Additive Backup Delay seconds Additive Backup Delay seconds
Out-of-Order Packets packets Out-of-Order Packets packets
Duplicate Packets packets Duplicate Packets packets
Failover Time Calculation Method Method Used Failover Time Calculation Method Method Used
 End of changes. 24 change blocks. 
32 lines changed or deleted 30 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/