draft-ietf-bmwg-protection-meth-01.txt   draft-ietf-bmwg-protection-meth-02.txt 
Network Working Group R. Papneja Network Working Group R. Papneja
Internet Draft Isocore Internet Draft Isocore
Intended status: Informational S.Vapiwala Intended status: Informational S.Vapiwala
Expires: August 2007 J.Karthik Expires: January 2008 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
February 23, 2007 July 6, 2007
Methodology for benchmarking MPLS Protection mechanisms Methodology for benchmarking MPLS Protection mechanisms
<draft-ietf-bmwg-protection-meth-01.txt> <draft-ietf-bmwg-protection-meth-02.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 1, line 45 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. This Internet-Draft will expire on January 6, .
Copyright Notice Copyright Notice
Poretsky, Rao, Le Roux Poretsky, Rao, Le Roux
Protection Mechanisms Protection Mechanisms
Copyright (C) The IETF Trust (2007). Copyright (C) The IETF Trust (2007).
Abstract Abstract
This draft describes the methodology for benchmarking MPLS Protection This draft describes the methodology for benchmarking MPLS Protection
skipping to change at page 2, line 31 skipping to change at page 2, line 31
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 [RFC-WORDS]. 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 ........................................7 3.2. Failure Detection [TERM-ID]...............................7
3.3. Use of Data Traffic for MPLS Protection Benchmarking......8 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..........................................9
3.6. Reversion ................................................9 3.6. Reversion [TERM-ID].......................................9
3.7. Traffic generation........................................9 3.7. Traffic generation........................................9
3.8. Motivation for topologies.................................9 3.8. Motivation for topologies................................10
4. Test Setup....................................................10 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........................................................11 backup........................................................11
TE tunnels....................................................11 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.............................................12 backup TE tunnels.............................................12
4.4. Link Protection with 2+ hop (from PLR) primary and 2 hop 4.4. Link Protection with 2+ hop (from PLR) primary and 2 hop
backup TE tunnels.............................................12 backup TE tunnels.............................................13
Poretsky, Rao, Le Roux Poretsky, Rao, Le Roux
Protection Mechanisms Protection Mechanisms
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
4.6. Node Protection with 2 hop primary (from PLR) and 2 hop
backup TE tunnels.............................................14 backup TE tunnels.............................................14
4.7. Node Protection with 3+ hop primary (from PLR) and 1 hop 4.6. Node Protection with 2 hop primary (from PLR) and 2 hop
backup TE tunnels.............................................15 backup TE tunnels.............................................15
4.7. Node Protection with 3+ hop primary (from PLR) and 1 hop
backup TE tunnels.............................................16
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.............................................16
5. Test Methodology..............................................16 5. Test Methodology..............................................17
5.1. Headend as PLR with link failure.........................17 5.1. Headend as PLR with link failure.........................18
5.2. Mid-Point as PLR with link failure.......................18 5.2. Mid-Point as PLR with link failure.......................19
5.3. Headend as PLR with Node failure.........................19 5.3. Headend as PLR with Node failure.........................20
5.4. Mid-Point as PLR with Node failure.......................20 5.4. Mid-Point as PLR with Node failure.......................21
5.5. MPLS FRR Forwarding Performance Test Cases...............22 5.5. MPLS FRR Forwarding Performance Test Cases...............23
5.5.1. PLR as Headend......................................22 5.5.1. PLR as Headend......................................23
5.5.2. PLR as Mid-point....................................23 5.5.2. PLR as Mid-point....................................24
6. Reporting Format..............................................24 6. Reporting Format..............................................25
7. Security Considerations.......................................25 7. IANA Considerations...........................................26
8. Acknowledgements..............................................26 This document requires no IANA considerations....................26
9. References....................................................26 8. Security Considerations.......................................27
9.1. Normative References.....................................26 9. Acknowledgements..............................................27
9.2. Informative References...................................26 10. References...................................................28
10. Author's Address...................Error! Bookmark not defined. 10.1. Normative References....................................28
Appendix A: Fast Reroute Scalability Table.......................30 10.2. Informative References..................................28
11. Authors' Addresses...........................................28
Intellectual Property Statement..................................30
Appendix A: Fast Reroute Scalability Table.......................31
1. Introduction 1. Introduction
This draft describes the methodology for benchmarking MPLS based This draft describes the methodology for benchmarking MPLS based
protection mechanisms. The new terminology that it introduces is defined protection mechanisms. The new terminology that it introduces is defined
in [TERM-ID]. in [TERM-ID].
MPLS based protection mechanisms provide faster recovery of real time MPLS based protection mechanisms provide faster recovery of real time
services in case of an unplanned link or node failure in the network services in case of an unplanned link or node failure in the network
core, where MPLS is used as a signaling protocol to setup point-to-point core, where MPLS is used as a signaling protocol to setup point-to-point
traffic engineered tunnels. MPLS based protection mechanisms improve traffic engineered tunnels. MPLS based protection mechanisms improve
service availability by minimizing the duration of the most common service availability by minimizing the duration of the most common
failures. There are generally two factors impacting service failures. There are generally two factors impacting service
availability. One is the frequency and the other is the duration of the 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
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
(for e.g. layer-2 links), relying on a common physical resource (for (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 e.g. common transport) fail. Common transport may include TDM and WDM
links providing multiplexing at layer-2 and layer-1. Within the context links providing multiplexing at layer-2 and layer-1. Within the context
of MPLS protection mechanisms, Shared Risk Link Groups [MPLS-FRR-EXT] of MPLS protection mechanisms, Shared Risk Link Groups [MPLS-FRR-EXT]
encompass correlations failures. encompass correlations failures.
Not all correlated failures can be anticipated in advance of their Not all correlated failures can be anticipated in advance of their
occurrence. Failures due to natural disasters or planned failures are occurrence. Failures due to natural disasters or planned failures are
the most notable causes. Due to the frequent occurrences of such the most notable causes. Due to the frequent occurrences of such
failures, it is necessary that implementations can handle these faults failures, it is necessary that implementations can handle these faults
skipping to change at page 4, line 43 skipping to change at page 5, line 5
of prefixes bound to a tunnel, services (such as IGP, BGP, Layer 3/ 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 Layer 2 VPNs) that are bound to the tunnel, number of primary tunnels
affected by the failure event, number of primary tunnels protected by affected by the failure event, number of primary tunnels protected by
backup, the type of failure and the physical media on which the failover backup, the type of failure and the physical media on which the failover
occurs. This document describes all different topologies and scenarios occurs. This document describes all different topologies and scenarios
that should be considered to effectively benchmark MPLS protection that should be considered to effectively benchmark MPLS protection
mechanisms and failover times. Different failure scenarios and scaling mechanisms and failover times. Different failure scenarios and scaling
considerations are also provided in this document. In addition the considerations are also provided in this document. In addition the
document provides a reporting format for the observed results. document provides a reporting format for the observed results.
Poretsky, Rao, Le Roux
Protection Mechanisms
To benchmark the failover time, data plane traffic is used as defined in To benchmark the failover time, data plane traffic is used as defined in
[IGP-METH]. Traffic loss is the key component in a black-box type test [IGP-METH]. Traffic loss is the key component in a black-box type test
and is used to measure convergence. and is used to measure convergence.
Poretsky, Rao, Le Roux
Protection Mechanisms
All benchmarking test cases defined in this document apply to both All benchmarking test cases defined in this document apply to both
facility backup and local protection enabled in detour mode. The test facility backup and local protection enabled in detour mode. The test
cases cover all possible failure scenarios and the associated procedures cases cover all possible failure scenarios and the associated procedures
benchmark the ability of the DUT to perform recovery from failures benchmark the ability of the DUT to perform recovery from failures
within target failover time. within target failover time.
Figure 1 represents the basic reference test bed and is applicable to Figure 1 represents the basic reference test bed and is applicable to
all the test cases defined in this document. TG & TA represents Traffic all the test cases defined in this document. TG & TA represents Traffic
Generator & Analyzer respectively. A tester is connected to the DUT and Generator & Analyzer respectively. A tester is connected to the DUT and
it sends and receives IP traffic along with the working Path, run it sends and receives IP traffic along with the working Path, run
skipping to change at page 5, line 40 skipping to change at page 6, line 4
| -------- | | | -------- | |
---------| 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 reordered
packets. It should further record arrival and departure times so that packets. It should further record arrival and departure times so that
Failover Time, Additive Latency, and Reversion Time can be measured. Failover Time, Additive Latency, and Reversion Time can be measured.
The tester may be a single device or a test system emulating all the
different roles along a primary or backup path.
Poretsky, Rao, Le Roux Poretsky, Rao, Le Roux
Protection Mechanisms Protection Mechanisms
The tester may be a single device or a test system emulating all the
different roles along a primary or backup path.
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.
skipping to change at page 6, line 41 skipping to change at page 7, line 4
3.1. Failover Events 3.1. Failover Events
The failover to the backup tunnel is primarily triggered by either a The failover to the backup tunnel is primarily triggered by either a
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). 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
Poretsky, Rao, Le Roux
Protection Mechanisms
- Interface Shutdown on remote side with POS Alarm - Interface Shutdown on remote side with POS Alarm
- Interface Shutdown on PLR side with RSVP hello - Interface Shutdown on PLR side with RSVP hello
- Interface Shutdown on remote side with RSVP hello - Interface Shutdown on remote side with RSVP hello
- 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
Poretsky, Rao, Le Roux
Protection Mechanisms
- 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)
- Online insertion and removal (OIR) on PLR side - Online insertion and removal (OIR) on PLR side
- OIR on remote side - OIR on remote side
- Sub-interface failure (e.g. shutting down of a VLAN) - Sub-interface failure (e.g. shutting down of a VLAN)
- Parent interface shutdown (an interface bearing multiple sub- - Parent interface shutdown (an interface bearing multiple sub-
interfaces interfaces
Node failure events Node failure events
skipping to change at page 7, line 42 skipping to change at page 8, line 4
Different MPLS protection mechanisms and different implementations Different MPLS protection mechanisms and different implementations
use different failure detection techniques such as RSVP hellos, BFD use different failure detection techniques such as RSVP hellos, BFD
etc. 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 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
techniques.
Poretsky, Rao, Le Roux Poretsky, Rao, Le Roux
Protection Mechanisms Protection Mechanisms
evaluate failover performance independent of the failure detection
techniques.
3.3. Use of Data Traffic for MPLS Protection Benchmarking 3.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. Packet loss is an externally observable event and has direct time. Packet loss is an externally observable event and has direct
impact on customers' applications. MPLS protection mechanism is impact on customers' applications. MPLS protection mechanism is
expected to minimize the packet loss in the event of a failure. For expected to minimize the packet loss in the event of a failure. For
this reason it is important to develop a standard router benchmarking this reason it is important to develop a standard router benchmarking
methodology for measuring MPLS protection that uses packet loss as a methodology for measuring MPLS protection that uses packet loss as a
metric. At a known rate of forwarding, packet loss can be measured metric. At a known rate of forwarding, packet loss can be measured
skipping to change at page 8, line 43 skipping to change at page 9, line 5
attributed to lost 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 tunnels (LSP) and installed routes. However the primary and backup tunnels (LSP) and installed routes. However the
procedure outlined here should be used for any number of LSPs (L) and procedure outlined here should be used for any number of LSPs (L) and
number of routes protected by PLR(R). Number of L and R must be number of routes protected by PLR(R). Number of L and R must be
recorded. recorded.
Poretsky, Rao, Le Roux
Protection Mechanisms
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.
Poretsky, Rao, Le Roux
Protection Mechanisms
3.6. Reversion [TERM-ID] 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 check to the test cases in this methodology document provides a check to
confirm that there is no packet loss. confirm that there is no packet loss.
skipping to change at page 9, line 41 skipping to change at page 10, line 5
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. 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
Poretsky, Rao, Le Roux Poretsky, Rao, Le Roux
Protection Mechanisms Protection Mechanisms
3.8. Motivation for topologies
Given that the label stack is dependent of the following 3 entities 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 provided 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
skipping to change at page 10, line 46 skipping to change at page 11, line 5
b) TE is Tail-End b) TE is Tail-End
c) MID is Mid point c) MID is Mid point
d) MP is Merge Point d) MP is Merge Point
e) PLR is Point of Local Repair e) PLR is Point of Local Repair
f) PRI is Primary f) PRI is Primary
g) BKP denotes Backup Node
Poretsky, Rao, Le Roux Poretsky, Rao, Le Roux
Protection Mechanisms Protection Mechanisms
g) BKP denotes Backup Node
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
skipping to change at page 11, line 41 skipping to change at page 12, line 4
| 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 |
-------- --------
Poretsky, Rao, Le Roux
Protection Mechanisms
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
skipping to change at page 12, line 34 skipping to change at page 13, line 5
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.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 Poretsky, Rao, Le Roux
Protection Mechanisms 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 | | | | |
skipping to change at page 18, line 12 skipping to change at page 19, line 12
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 Poretsky, Rao, Le Roux
Protection Mechanisms 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 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. Enable protected interface that was down (Node in the case 13. Enable protected interface that was down (Node in the case
of NNHOP) of NNHOP)
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.2. Mid-Point as PLR with link failure 5.2. Mid-Point as PLR with link failure
skipping to change at page 25, line 15 skipping to change at page 26, line 15
Poretsky, Rao, Le Roux Poretsky, Rao, Le Roux
Protection Mechanisms Protection Mechanisms
Minimum failover time milliseconds Minimum failover time milliseconds
Mean 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 one of the Failover time suggested above is calculated using one of the
following 2 methods following 3 methods
1. Packet loss based method: (Numbers of packet drop/rate per 1. Packet-Based Loss method (PBLM): (Number of packets
second * 1000) milliseconds dropped/packets per second * 1000) milliseconds. This method
could also be referred as Rate Derived method.
2. Time based method: Traffic generators provide statistics which 2. Time-Based Loss Method (TBLM): This method relies on the
show the duration of failure in milliseconds based on the when ability of the Traffic generators to provide statistics which
the packet loss occurred (interval between non-zero packet loss reveal the duration of failure in milliseconds based on when the
and zero loss). packet loss occurred (interval between non-zero packet loss and
zero loss).
3. Timestamp Based Method (TBM): This method of failover
calculation is based on the timestamp that gets transmitted as
payload in the packets originated by the generator. The Traffic
Analyzer records the timestamp of the last packet received
before the failover event and the first packet after the
failover and derives the time based on the difference between
these 2 timestamps. Note: The payload could also contain
sequence numbers for out-of-order packet calculation and
duplicate packets.
Note: If the primary is configured to be dynamic, and if the primary 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. IANA Considerations 7. IANA Considerations
This document requires no IANA considerations. This document requires no IANA considerations.
Poretsky, Rao, Le Roux
Protection Mechanisms
8. Security Considerations 8. Security Considerations
Benchmarking activities as described in this memo are limited to Benchmarking activities as described in this memo are limited to
technology characterization using controlled stimuli in a laboratory technology characterization using controlled stimuli in a laboratory
environment, with dedicated address space and the constraints environment, with dedicated address space and the constraints
specified in the sections above. specified in the sections above.
The benchmarking network topology will be an independent test setup The benchmarking network topology will be an independent test setup
and MUST NOT be connected to devices that may forward the test and MUST NOT be connected to devices that may forward the test
traffic into a production network, or misroute traffic to the test traffic into a production network, or misroute traffic to the test
management network. management network.
Poretsky, Rao, Le Roux
Protection Mechanisms
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 Special capabilities SHOULD NOT exist in the DUT/SUT specifically
for benchmarking purposes. Any implications for network security for benchmarking purposes. Any implications for network security
arising from the DUT/SUT SHOULD be identical in the lab and in arising from the DUT/SUT SHOULD be identical in the lab and in
production networks. production networks.
The isolated nature of the benchmarking environments and the fact The isolated nature of the benchmarking environments and the fact
that no special features or capabilities, other than those used in that no special features or capabilities, other than those used in
skipping to change at page 26, line 29 skipping to change at page 28, line 5
9. Acknowledgements 9. 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 and Curtis Villamizar his contribution in suggesting to the document and Curtis Villamizar his contribution in suggesting
text on definition and need for benchmarking Correlated failures. text on definition and need for benchmarking Correlated failures.
Additionally we would like to thank Arun Gandhi, Amrit Hanspal, Karu Additionally we would like to thank Arun Gandhi, Amrit Hanspal, Karu
Ratnam and for their input to the document. Ratnam and for their input to the document.
Poretsky, Rao, Le Roux
Protection Mechanisms
10. References 10. References
10.1. Normative References 10.1. Normative References
[MPLS-FRR-EXT] Pan, P., Atlas, A., Swallow, G., "Fast Reroute [MPLS-FRR-EXT] Pan, P., Atlas, A., Swallow, G., "Fast Reroute
Extensions to RSVP-TE for LSP Tunnels", RFC 4090. Extensions to RSVP-TE for LSP Tunnels", RFC 4090.
10.2. Informative References 10.2. Informative References
[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, March 1997. Indicate Requirement Levels", RFC 2119, March 1997.
[TERM-ID] Poretsky, S., Papneja, R., "Benchmarking Terminology [TERM-ID] Poretsky S., Papneja R., Karthik J., Vapiwala S.,
for Protection Performance", draft-poretsky- "Benchmarking Terminology for Protection
Performance", draft-ietf-bmwg-protection-term-
Poretsky, Rao, Le Roux 02.txt, work in progress.
Protection Mechanisms
protection-term-00.txt, work in progress.
[MPLS-FRR-EXT] Pan P., Swollow G., Atlas A., "Fast Reroute [MPLS-FRR-EXT] Pan P., Swollow G., Atlas A., "Fast Reroute
Extensions to RSVP-TE for LSP Tunnels”, RFC 4090. Extensions to RSVP-TE for LSP Tunnels”, RFC 4090.
[IGP-METH] S. Poretsky, B. Imhoff, "Benchmarking Methodology [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-12.txt”, work in
progress. progress.
11. Authors' Addresses 11. Authors' Addresses
Rajiv Papneja Rajiv Papneja
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
Poretsky, Rao, Le Roux
Protection Mechanisms
Email: rpapneja@isocore.com Email: rpapneja@isocore.com
Samir Vapiwala Samir Vapiwala
Cisco System Cisco System
300 Beaver Brook Road 300 Beaver Brook Road
Boxborough, MA 01719 Boxborough, MA 01719
USA USA
Phone: +1 978 936 1484 Phone: +1 978 936 1484
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,
skipping to change at page 28, line 29 skipping to change at page 30, line 4
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
Jean-Louis Le Roux Jean-Louis Le Roux
France Telecom France Telecom
2 av Pierre Marzin 2 av Pierre Marzin
22300 Lannion 22300 Lannion
Poretsky, Rao, Le Roux
Protection Mechanisms
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 IETF Trust (2007). 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.
Disclaimer Disclaimer
Poretsky, Rao, Le Roux
Protection Mechanisms
This document and the information contained herein are provided This document and the information contained herein are provided
on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE
IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL
WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY
WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE
ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS
FOR A PARTICULAR PURPOSE. FOR A PARTICULAR PURPOSE.
Intellectual Property Statement Intellectual Property Statement
skipping to change at page 29, line 29 skipping to change at page 31, line 4
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
Poretsky, Rao, Le Roux
Protection Mechanisms
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
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 this standard. Please address the information to the IETF at
ietf-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 30 skipping to change at page 32, line 4
1 500 1 500
1 1000 1 1000
1 2000 1 2000
1 5000 1 5000
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
Poretsky, Rao, Le Roux
Protection Mechanisms
500 500 500 500
1000 1000 1000 1000
2000 2000 2000 2000
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
skipping to change at page 31, line 30 skipping to change at page 33, line 5
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
Poretsky, Rao, Le Roux
Protection Mechanisms
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
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. 50 change blocks. 
80 lines changed or deleted 103 lines changed or added

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