Network Working Group INTERNET-DRAFT Expires in: January 2006 Scott Poretsky Quarry Technologies Rajiv Papneja Isocore Shankar Rao Qwest Communications Jean-Louis Le Roux France Telecom July 2005 Benchmarking Methodology for MPLS Protection Mechanisms Intellectual Property Rights (IPR) statement: By submitting this Internet-Draft, each author represents that 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 becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Status of this Memo By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Copyright Notice Copyright (C) The Internet Society (2005). All Rights Reserved. Poretsky, Khanna, Papneja, Rao, Le Roux [Page 1] INTERNET-DRAFT Benchmarking Methodology for July 2005 MPLS Protection Mechanisms ABSTRACT This draft describes the methodology for benchmarking MPLS protection mechanisms using the terminology defined in [TERMID]. An overview of existing MPLS protection terminology and functionality is provided as as background for the methodology. The methodology can be applied to any MPLS protection mechanisms such as Standby LSP, Fast Reroute Detour Mode, and Fast Reroute Bypass Mode. The methodology can also be used to benchmark LSP rerouting due to a Headend Reroute. The data plane is measured to obtain the benchmarking metrics. Discussion is included to explain the differences between MPLS Protection mechanisms, the network events that cause failover, and the benefits of measuring the data plane for black-box MPLS Protection benchmarking. Measurements can be used to compare failover performance of different Label-Switched Routers and evaluate the different MPLS protection mechanisms. Table of Contents 1. Introduction ...............................................3 2. Existing definitions........................................4 3. Test Considerations.........................................5 3.1 Types of Failover Events...................................5 3.2 Network Indications for Failover...........................5 3.3 Use of Data Traffic for MPLS Protection Benchmarking.......6 3.4 LSP and Route Scaling......................................6 3.5 Selection of IGP...........................................6 3.6 Reversion..................................................6 4. Test Setup..................................................7 4.1 DUT as Ingress.............................................7 4.2 DUT as Failover Node with Link Protection..................7 4.3 DUT as Failover Node with Node Protection..................7 4.4 DUT as Merge Node..........................................7 4.5 DUT as Egress..............................................8 4.6 DUT as Ingress and Failover Node with Link Protection......8 4.7 DUT as Ingress and Failover Node with Node Protection......8 4.8 DUT as Egress and Merge Node...............................8 5. Test Cases..................................................9 5.1 Node Protection............................................9 5.1.1 Ingress..................................................9 5.1.1.1 Local SONET Failure....................................9 5.1.1.2 Local Administrative Shutdown..........................10 5.1.1.3 Remote Failure.........................................11 5.1.2 Failover Node............................................12 5.1.2.1 Ingress Failover Node..................................12 5.1.2.2 Midpoint Failover Node.................................13 5.1.3 Merge Node...............................................14 5.1.4 Merge Node and Egress....................................15 5.2 Link Protection............................................16 5.2.1 Ingress Failover Node....................................16 5.2.2 Midpoint Failover Node...................................17 5.3 Fast Reroute Scalability...................................18 Poretsky, Khanna, Papneja, Rao, Le Roux [Page 2] INTERNET-DRAFT Benchmarking Methodology for July 2005 MPLS Protection Mechanisms 6. Security Considerations.....................................19 7. Acknowledgements............................................19 8. References..................................................19 9. Author's Address............................................20 1. Introduction MPLS-TE offers three options for Protection Mechanisms to reroute traffic from a Primary LSP to a Backup LSP: Standby LSP, Fast Reroute (FRR) Detour Mode, and Fast Reroute (FRR) Bypass Mode. The methodology can also be used to benchmark LSP rerouting due to a Headend Reroute. The purpose of these mechanisms is to provide protection for link and node failures. Each of the mechanisms offers a distinct tradeoff in the amount of network configuration and level of protection. Headend Reroute is the default Protection Mechanism for MPLS-TE. Headend Reroute establishes a backup LSP that is dynamically signaled after a failure event has occurred. Headend Reroute has the advantage that a backup is not utilizing resources prior to failure. Its disadvantage is its long failover time [TERMID] that produces high packet loss during failure that can be greater than that of IGP Convergence. The most basic topology for dynamic headend reroute is shown in Figure 1. -------- -------- -------- |Ingress | |MidPoint| | Egress | |Node |----| Node |----| Node | -------- -------- -------- | | | -------- | ---------|Backup |--------- |Midpoint| -------- Figure 1. Topology for Headend Reroute The Standby LSP is an extension to RSVP-TE signaling in which a backup LSP is signaled in advance from primary Ingress to Egress. Its advantage is that it is faster than Headend Reroute, but it requires high resource utilization at the ingress to maintain unused backup LSPs. The topology for Standby LSP is identical to that for Dynamic Headend Reroute shown in Figure 1, but the Backup Path is pre-established. FRR is an extension to TE specified in [MPLS-FRR-EXT] to provide a Protection Mechanism with fast failover characteristics to minimize packet loss while reducing processing load at the tunnel ingress. FRR provides link and node protection. The primary and backup LSPs are signaled using an optional extension to the Resource Reservation Protocol with TE extensions (RSVP-TE). With FRR midpoint LSRs along the primary path are responsible for laying out the protected path in the downstream direction, toward Poretsky, Khanna, Papneja, Rao, Le Roux [Page 3] INTERNET-DRAFT Benchmarking Methodology for July 2005 MPLS Protection Mechanisms the egress. This provides local protection for link and node failure and achieves a goal of less than 45msec failover while minimizing resource utilization at the ingress. FRR does require greater network configuration and increases signaling complexity. There are two FRR modes, Bypass and Detour, each with distinct advantages for operational configuration. The topology for FRR is shown in Figure 2. -------- -------- -------- -------- -------- |Ingress | |Failover| |MidPoint| | Merge | | Egress | | Node |----| Node |----| Node |----| Node |----| Node | -------- -------- -------- -------- -------- | | | -------- | ---------|Backup |--------- |Midpoint| -------- Figure 2. Topology for Fast Reroute This draft describes the methodology for benchmarking MPLS protection mechanisms. The methodology can be applied to any MPLS Protection mechanism such as Headend Reroute, Standby LSP, Fast Reroute Detour Mode, and Fast Reroute Bypass Mode. The data plane is measured to obtain the benchmarking metrics. Discussion is included to explain the network events that cause failover and benefits of measuring the data plane for black-box MPLS Protection benchmarking. Measurements can be used to compare failover performance of different Label-Switched Routers and evaluate the different MPLS protection mechanisms. 2. Existing definitions For the sake of clarity and continuity this RFC adopts the template for definitions set out in Section 2 of RFC 1242. Definitions are indexed and grouped together in sections for ease of reference. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119. The reader is assumed to be familiar with the commonly used MPLS terminology, some of which is defined in [MPLS-RSVP], [MPLS-RSVP-TE], and [MPLS-FRR-EXT]. Poretsky, Khanna, Papneja, Rao, Le Roux [Page 4] INTERNET-DRAFT Benchmarking Methodology for July 2005 MPLS Protection Mechanisms 3. Test Considerations This section discusses three fundamentals of MPLS Protection testing: the types of network events that cause failover, indications for failover, the use of data traffic, LSP Scaling, and IGP Selection. 3.1 Failover Events [TERMID] Causes of reroute are administration change, link failure, node failure, setting of the IGP overload bit, and path optimization. Indication for these types of failures wil vary whether the failure is local or remote. Reasons for all of these types of failures can vary due to the router/switch or network. Different causes for failures could vary the detection and recovery times. 3.2 Failure Detection [TERMID] For an ingress administrative change a make-before-break should occur to prevent any packet loss. Local failures can be detected via SONET failure with directly connected LSR. Failure indication may vary with the type of alram - LOS, AIS, or RDI. Failures on Ethernet technology links such as Gigabit Ethernet rely upon Layer 3 signaling indication for failure. Remote failures are indicated via Control Plane signaling. Signaling indications are Negative RSVP Indication (loss of PATH Refresh messages from upstream node, loss of RESV Refresh messages from downstream node, or loss of RSVP Fast Hellos), Positive RSVP Indication (receipt of PATHTear Message from upstream node or receipt of RESVTear Message from downstream node), or change to the TE-LSDB via the IGP. Different MPLS Protection Mechanisms and different implementations use different failure indications. Ethernet technologies such as Gigabit Ethernet rely upon Layer 3 failure indication mechanisms since there is no Layer 2 failure indication mechanisms. The methodologies in this document provide remote failure cases to evaluate failover performance independent of the implemented signaling indication mechanism. Poretsky, Khanna, Papneja, Rao, Le Roux [Page 5] INTERNET-DRAFT Benchmarking Methodology for July 2005 MPLS Protection Mechanisms 3.3 Use of Data Traffic for MPLS Protection Benchmarking Customers of service providers use packet loss as the metric for failover time. Packet loss is an externally observable event having direct impact on customers' application performance. MPLS Protection mechanisms exist to minimize packet loss in the event of failure. For this reason it is important to develop a standard router benchmarking methodology and terminology for measuring MPLS Protection that uses packet loss as a metric. At a known rate for forwarding rate, packet loss can be measured and used to calculate the Failover time. Measurement of control plane signaling to establish Backup paths is not enough to verify failover. Failover is best determined when packets are actually traversing the Backup Path. An additional benefit of using packet loss for calculation of Failover time is that it enables black-box tests to be designed. Data traffic can be offered at line-rate to the device under test (DUT), an emulated network event as described above can be forced to occur, and packet loss can be externally measured to calculate the convergence time. Knowledge of the DUT architecture is not required. There is no need to rely on the DUT to produce the test results. 3.4 LSP and Route Scaling Failover Time performance may vary with the number of established primary and backup LSPs and routes learned. The methodologies may be used for any number of LSPs, L, and number of routes, R. N and R must be recorded. It is intended with Fast Reroute that the less than 45msec failover requirement is maintained when scaling the number of protected LSPs. 3.5 Selection of IGP The methodologies can be used with ISIS-TE or OSPF-TE. 3.6 Reversion [TERMID] Fast Reroute provides a method to return to restore a Backup Path to original Primary LSP upon recoery from the failure. This is referred to as Reversion, which can be implemented as Global Reversion or Local Reversion. Standby LSP and Headend Reroute also provide the ability to return to the Primary LSP upon failure recovery. With any mechanism, Reversion should not produce any packet loss. Each of the test cases in this methodology document provides a step to verify that there is no packet loss. The step can be performed regarless of Protection mechanism and Reversion method. Poretsky, Khanna, Papneja, Rao, Le Roux [Page 6] INTERNET-DRAFT Benchmarking Methodology for July 2005 MPLS Protection Mechanisms 4. Test Setup There are numerous test setups for benchmarking a Protection Switching System [TERMID] that use MPLS. This is due to the many roles that an LSR can be along the LSP. A single DUT should be tested in each of these roles. The Test Setups to use are shown in Figures 3 through 10. 4.1 DUT as Ingress -------- -------- -------- |Ingress | |MidPoint| | Egress | | DUT |----| Node |----| Node | -------- -------- -------- | | | -------- | ---------|Backup |--------- |Midpoint| -------- Figure 3. Test Setup with DUT as Ingress 4.2 DUT as Failover Node with Link Protection [TERMID] -------- -------- -------- -------- -------- |Ingress | | FN | |MidPoint| | Merge | | Egress | | |----| DUT |----| Node |----| Node |----| Node | -------- -------- -------- -------- -------- | | | -------- | ---|Backup |-- |Midpoint| -------- Figure 4. Test Setup with DUT as Failover Node with Link Protection 4.3 DUT as Failover Node with Node Protection [TERMID] -------- -------- -------- -------- -------- |Ingress | | FN | |MidPoint| | Merge | | Egress | | |----| DUT |----| Node |----| Node |----| Node | -------- -------- -------- -------- -------- | | | -------- | ---------|Backup |--------- |Midpoint| -------- Figure 5. Test Setup with DUT as Failover Node with Node Protection 4.4 DUT as Merge Node [TERMID] -------- -------- -------- -------- -------- |Ingress | | FN | |MidPoint| | Merge | | Egress | | |----| |----| Node |----|Node DUT|----| Node | -------- -------- -------- -------- -------- | | | -------- | ---------|Backup |--------- |Midpoint| -------- Figure 6. Test Setup with DUT as Merge Node Poretsky, Khanna, Papneja, Rao, Le Roux [Page 7] INTERNET-DRAFT Benchmarking Methodology for July 2005 MPLS Protection Mechanisms 4.5 DUT as Egress -------- -------- -------- |Ingress | |MidPoint| | Egress | | |----| Node |----| DUT | -------- -------- -------- | | | -------- | ---------|Backup |--------- |Midpoint| -------- Figure 7. Test Setup with DUT as Egress 4.6 DUT as Ingress and Failover Node with Link Protection -------- -------- -------- -------- |Ingress/| |MidPoint| | Merge | | Egress | |FN DUT |----| Node |----| Node |----| Node | -------- -------- -------- -------- | | | -------- | ---|Backup |-- |Midpoint| -------- Figure 8. Test Setup with DUT as Ingress and Failover Node with Link Protection 4.7 DUT as Ingress and Failover Node with Node Protection -------- -------- -------- -------- |Ingress/| |MidPoint| | Merge | | Egress | |FN DUT |----| Node |----| Node |----| Node | -------- -------- -------- -------- | | | -------- | ---------|Backup |--------- |Midpoint| -------- Figure 9. Test Setup with DUT as Ingress and Failover Node with Node Protection Poretsky, Khanna, Papneja, Rao, Le Roux [Page 8] INTERNET-DRAFT Benchmarking Methodology for July 2005 MPLS Protection Mechanisms 4.8 DUT as Egress and Merge Node -------- -------- -------- --------- |Ingress | | FN | |MidPoint| | Egress/ | | |----| DUT |----| Node |----|Merge DUT| -------- -------- -------- --------- | | | -------- | ---------|Backup |--------- |Midpoint| -------- Figure 10. Test Setup with DUT as Egress and Merge Node 5. Test Cases 5.1 Node Protection [TERMID] 5.1.1 Ingress 5.1.1.1 Local SONET Failure Objective To benchmark the MPLS failover time due to a Local SONET Link failure event at the Ingress. Test Setup Use Figure 3. The DUT is the LSP ingress. The test device(s) will have three interfaces to the DUT: 1. Transmit IP Traffic to DUT 2. Receive MPLS traffic from DUT's Primary interface 3. Receive MPLS traffic from DUT's Backup interface after failover Test Configuration The ingress can be configured for Headend Reroute, Standby LSP, or Fast Reroute. The test device(s) should emulate the Primary Path Midpoint, Backup Path Midpoint, and Egress Node. The test device sources an offered load of IP packets to the DUT ingress interface and receives switched MPLS from the DUT. Procedure 1. Enable either IGP-TE (ISIS-TE or OSPF-TE) on the interfaces. 2. Advertise matching IGP TE-LSDB routes from Tester to DUT on both primary and backup interfaces. 3. Establish Primary LSP. 4. Establish Backup LSP (Step 4 does not apply for Headend Reroute). 5. Send IP traffic at maximum Forwarding Rate to DUT. IP destination address must match FEC for Primary LSP. Poretsky, Khanna, Papneja, Rao, Le Roux [Page 9] INTERNET-DRAFT Benchmarking Methodology for July 2005 MPLS Protection Mechanisms 6. Verify traffic switched over Primary LSP. 7. Remove SONET on DUT's Ingress Interface to Primary LSP. 8. Observe Packet Loss. 9. Measure Failover Time as DUT detects the link down event and switches MPLS traffic over the Backup LSP. 10.Recover from failure and verify Reversion does not produce any packet loss. Results Packet loss upon failure at Ingress's (DUT) primary interface should be 100%. The Failover Time is the time to restore 100% of the traffic. The measured failover time is influenced by the failure indication and Hardware update time. The result with Headend Reroute is also influenced by the time to establish the Backup LSP. 5.1.1.2 Local Administrative Shutdown Objective To benchmark the MPLS failover time due to a Local administrative shutdown event at the Ingress. Test Setup Use Figure 3. The DUT is the LSP ingress. The test device(s) will have three interfaces to the DUT: 1. Transmit IP Traffic to DUT 2. Receive MPLS traffic from DUT's Primary interface 3. Receive MPLS traffic from DUT's Backup interface after failover Test Configuration The ingress can be configured for Headend Reroute, Standby LSP, or Fast Reroute. The test device(s) should emulate the Primary Path Midpoint, Backup Path Midpoint, and Egress Node. The test device sources an offered load of IP packets to the DUT ingress interface and receives switched MPLS from the DUT. Procedure 1. Enable either IGP-TE (ISIS-TE or OSPF-TE) on the interfaces. 2. Advertise matching IGP TE-LSDB routes from Tester to DUT on both primary and backup interfaces. 3. Establish Primary LSP. 4. Establish Backup LSP (Step 4 does not apply for Headend Reroute). 5. Send IP traffic at maximum Forwarding Rate to DUT. IP destination address must match FEC for Primary LSP. 6. Verify traffic switched over Primary LSP. 7. Administratively shutdown the DUT's Ingress Interface to Primary LSP. Poretsky, Khanna, Papneja, Rao, Le Roux [Page 10] INTERNET-DRAFT Benchmarking Methodology for July 2005 MPLS Protection Mechanisms 8. Observe Packet Loss. 9. Measure Failover Time as DUT detects the link down event and switches MPLS traffic over the Backup LSP. 10.Recover from failure and verify Reversion does not produce any packet loss. Results Make-before-break should occur so that there is no observed packet loss. 5.1.1.3 Remote Failure Objective To benchmark the MPLS failover time due to a remote failure event at remote interface of a mid-point node. Test Setup Use Figure 3. The DUT is the LSP ingress. For Headend Reroute and Standby LSPs, additional mid-point nodes may be added to the test setup. The test device(s) will have three interfaces to the DUT: 1. Transmit IP Traffic to DUT 2. Receive MPLS traffic from DUT's Primary interface 3. Receive MPLS traffic from DUT's Backup interface after failover Test Configuration The ingress can be configured for Headend Reroute or Standby LSP. The test device(s) should emulate the Primary Path Midpoint, Backup Path Midpoint, and Egress Node. The test device sources an offered load of IP packets to the DUT ingress interface and receives switched MPLS from the DUT. Procedure 1. Enable either IGP-TE (ISIS-TE or OSPF-TE) on the interfaces. 2. Advertise matching IGP TE-LSDB routes from Tester to DUT on both primary and backup interfaces. 3. Establish Primary LSP. 4. Establish Backup LSP (Step 4 does not apply for Headend Reroute). 5. Send IP traffic at maximum Forwarding Rate to DUT. IP destination address must match FEC for Primary LSP. 6. Verify traffic switched over Primary LSP. 7. Receive control plane indication on DUT's Ingress Interface to Primary LSP. 8. Observe Packet Loss. 9. Measure Failover Time as DUT detects the link down event and switches MPLS traffic over the Backup LSP. 10.Recover from failure and verify Reversion does not produce any packet loss. Poretsky, Khanna, Papneja, Rao, Le Roux [Page 11] INTERNET-DRAFT Benchmarking Methodology for July 2005 MPLS Protection Mechanisms Results Failover Time is the period starting with the first occurence of packet loss and ending with full restoration of 100% of the traffic. Traffic loss is first observed upon receipt and processing of the control plane indication at the DUT. At this time the DUT stops sending traffic on the primary LSP and switches it to the Backup LSP. The Failover Time is the time for the DUT to switch the traffic. The test device packet generation and forwarding time is inherently not a factor in the measurement. 5.1.2 Failover Node [TERMID] 5.1.2.1 Ingress Failover Node Objective To benchmark the MPLS failover time due to a Local SONET Link failure event at the Ingress also configured as Failover Node with node protection. Test Setup Use Figure 9. The DUT is the LSP ingress. All other nodes indicated in the figure are simulated by a test device. The test device(s) will have three interfaces to the DUT: 1. Transmit IP Traffic to DUT 2. Receive MPLS traffic from DUT's Primary interface 3. Receive MPLS traffic from DUT's Backup interface after failover Test Configuration The ingress is configured for FRR. The test device(s) should emulate FRR Primary Path Midpoint, Backup Path Midpoint, and Egress Node. The test device sources an offered load of IP packets to the DUT ingress interface and receives switched MPLS from the DUT. Procedure 1. Enable either IGP-TE (ISIS-TE or OSPF-TE) on the interfaces. 2. Advertise matching IGP TE-LSDB routes from Tester to DUT on both primary and backup interfaces. 3. Establish Primary LSP. 4. Establish Backup LSP. Ensure that the primary LSP and Backup LSP outgoing interfaces are different. 5. Send IP traffic at maximum Forwarding Rate to DUT. IP destination address must match FEC for Primary LSP. 6. Verify traffic switched over Primary LSP. 7. Remove SONET on DUT's Ingress Interface to Primary LSP. 8. Observe Packet Loss. 9. Measure Failover Time as DUT detects the link down event and switches MPLS traffic over the Backup LSP. 10.Recover from failure and verify Reversion does not produce any packet loss. Poretsky, Khanna, Papneja, Rao, Le Roux [Page 12] INTERNET-DRAFT Benchmarking Methodology for July 2005 MPLS Protection Mechanisms Results Packet loss upon failure at Ingress's (DUT) primary interface should be 100%. The Failover Time is the time to restore 100% of the traffic. The measured failover time is influenced by the failure indication and Hardware update time. 5.1.2.2 Midpoint Failover Node Objective To benchmark the MPLS failover time with node protection provided, due to a SONET Link failure event at the Midpoint Failover Node. Test Setup Use Figure 5. The DUT is a midpoint on the primary LSP. The remaining nodes, in the indicated topology are simulated by the test device. The test device(s) will have three interfaces to the DUT: 1. Transmit MPLS Traffic to DUT 2. Receive MPLS traffic from DUT's Primary interface 3. Receive MPLS traffic from DUT's Backup interface after failover Test Configuration The DUT as midpoint Failover Node is configured for FRR. The test device(s) should emulate FRR Ingress, Primary Path Midpoint, Backup Path Midpoint, and Egress Node. The test device sources an offered load of MPLS packets to the DUT ingress interface and receives switched MPLS from the DUT. Procedure 1. Enable either IGP-TE (ISIS-TE or OSPF-TE) on the interfaces. 2. Advertise matching IGP TE-LSDB routes from Tester to DUT on both primary and backup interfaces. 3. Establish Primary LSP with Tester as in the ingress. 4. Establish Backup LSP. 5. Send labeled traffic at maximum Forwarding Rate to DUT. Label must match the one received from DUT. 6. Verify traffic switched over Primary LSP. 7. Remove SONET on DUT's interface to downstream Midpoint LSR on Primary LSP path. 8. Observe Packet Loss. 9. Measure Failover Time as DUT detects the link down event and switches MPLS traffic over the Backup LSP. 10.Recover from failure and verify Reversion does not produce any packet loss. Results Packet loss upon failure on midpoint LSRs (DUT) primary LSP interface should be 100%. The Failover Time is the time to Poretsky, Khanna, Papneja, Rao, Le Roux [Page 13] INTERNET-DRAFT Benchmarking Methodology for July 2005 MPLS Protection Mechanisms restore 100% of the traffic. The measured failover time is influenced by the Local failure indication and hardware update time. 5.1.3 Merge Node [TERMID] Objective To benchmark the MPLS failover time and packet loss at the merge node due to failure event along the protected path somewhere upstream. Test Setup Use Figure 6. The DUT is the Merge Node. All other nodes are simulated by the test device and the failure is assumed to occur along the protected path upstream to the DUT. The test device(s) will have three interfaces to the DUT: 1. Transmit MPLS Traffic to DUT inbound primary Interface 2. Transmit MPLS traffic to DUT's Backup interface 3. Receive MPLS traffic from DUT's primary outbound interface before and after the failover Test Configuration The Merge Node can be configured for merging Backup Paths using Sender-Template specific method and merging Detours using Path- Specifi Method. The test device(s) should emulate the Point of LLocal Repair, Primary Path Midpoint, Backup Path Midpoint, and Egress Node. The test device sources an offered load of MPLS packets to the DUT inbound interfaces and receives switched MPLS from the DUT as an egress. Procedure 1. Enable either IGP-TE (ISIS-TE or OSPF-TE) on the interfaces. 2. Advertise matching IGP TE-LSDB routes from Tester to DUT on both primary and backup interfaces. 3. Establish Primary LSP with DUT as the potential Merge Node. 4. Establish Backup/Detour LSP with DUT as a Merge Node. 5. Send MPLS traffic at maximum Forwarding Rate to DUT along the Primary Path. 6. Configure the Merge Node to have common outgoing interfaces and the next-hop tester interface. 7. Verify that the DUT correctly identifies the Protected and Backup LSP based on Sender-Template specific Method and Path-Specific Method. 8. Verify traffic received at the emulated egress is not affected after the failure has occurred and Failover Node has switched to the Backup LSP. 9. Observe Packet Loss and observe packet re-ordering if any. 10. If there is packet loss measure the convergence time until the DUT stabilizes switches MPLS traffic to the merged LSP. 11.Recover from failure and verify Reversion does not produce any packet loss. Poretsky, Khanna, Papneja, Rao, Le Roux [Page 14] INTERNET-DRAFT Benchmarking Methodology for July 2005 MPLS Protection Mechanisms Results Packet loss should be ideally 0% once the Failover Node switches to the backup and merging takes place at the DUT. If there is packet loss, the measured time should be less than that specified in [MPLS-FRR-EXT]. 5.1.4 Merge Node and Egress Objective To benchmark the MPLS failover time and packet loss at the merge node/Egress due to failure event along the protected path somewhere upstream. Test Setup Use Figure 10. The DUT is the Merge Node. All other nodes are simulated by the test device and the failure is assumed to occur along the protected path upstream to the DUT. The test device(s) will have three interfaces to the DUT: 1. Transmit MPLS Traffic to DUT inbound primary Interface 2. Transmit MPLS traffic to DUT's Backup interface 3. Receive IP traffic from DUT's primary outbound interface before and after the failover Test Configuration The Merge Node can be configured for merging Backup Paths using Sender-Template specific method and merging Detours using Path -Specific Method. The test device(s) should emulate the Point of Local Repair, Primary Path Midpoint, Backup Path Midpoint, and Egress Node. The test device sources an offered load of MPLS packets to the DUT inbound interfaces and receives switched MPLS from the DUT as an egress. Procedure 1. Enable either IGP-TE (ISIS-TE or OSPF-TE) on the interfaces. 2. Advertise matching IGP TE-LSDB routes from Tester to DUT on both primary and backup interfaces. 3. Establish Primary LSP with DUT as the potential Merge Node. 4. Establish Backup/Detour LSP with DUT as a Merge Node. 5. Send MPLS traffic at maximum Forwarding Rate to DUT along the Primary Path. 6. Configure the Merge Node to have common outgoing interfaces and the next-hop tester interface. 7. Verify that the DUT correctly identifies the Protected and Backup LSP based on Sender-Template specific Method and Path-Specific Method. 8. Verify traffic received at the emulated egress is not affected after the failure has occurred and Failover Node has switched to the Backup LSP. 9. Observe Packet Loss and observe packet re-ordering if any. 10.If there is packet loss measure the convergence time until the Poretsky, Khanna, Papneja, Rao, Le Roux [Page 15] INTERNET-DRAFT Benchmarking Methodology for July 2005 MPLS Protection Mechanisms DUT stabilizes and maps the IP traffic correctly to the destination. 11.Recover from failure and verify Reversion does not produce any packet loss. Results Packet loss should be ideally 0% once the Failover Node switches to the backup and merging takes place at the DUT. If there is packet loss the measured time should be less than that specified in [MPLS-FRR-EXT]. 5.2 Link Protection [TERMID] 5.2.1 Ingress Failover Node Objective To benchmark the MPLS failover time due to a Local SONET Link failure event at the Ingress with link protection. Test Setup Use Figure 8. The DUT is the LSP ingress. All other nodes indicated in the figure are simulated by a test device. The test device(s) will have three interfaces to the DUT: 1. Transmit IP Traffic to DUT 2. Receive MPLS traffic from DUT's Primary interface 3. Receive MPLS traffic from DUT's Backup interface after failover Test Configuration The ingress is configured for FRR. The test device(s) should emulate FRR Primary Path Midpoint, Backup Path Midpoint, and Egress Node. The test device sources an offered load of IP packets to the DUT ingress interface and receives switched MPLS from the DUT. Procedure 1. Enable either IGP-TE (ISIS-TE or OSPF-TE) on the interfaces. 2. Advertise matching IGP TE-LSDB routes from Tester to DUT on both primary and backup interfaces. 3. Establish Primary LSP. 4. Establish Backup LSP. Ensure that the primary LSP and Backup LSP outgoing interfaces are different. 5. Send IP traffic at maximum Forwarding Rate to DUT. IP destination address must match FEC for Primary LSP. 6. Verify traffic switched over Primary LSP. 7. Remove SONET on DUT's Ingress Interface to Primary LSP. 8. Observe Packet Loss. 9. Measure Failover Time as DUT detects the link down event and switches MPLS traffic over the Backup LSP. Poretsky, Khanna, Papneja, Rao, Le Roux [Page 16] INTERNET-DRAFT Benchmarking Methodology for July 2005 MPLS Protection Mechanisms 10.Recover from failure and verify Reversion does not produce any packet loss. Results Packet loss upon failure at Ingress's (DUT) primary interface should be 100%. The Failover Time is the time to restore 100% of the traffic. The measured failover time is influenced by the failure indication and Hardware update time. 5.2.2 Midpoint Failover Node Objective To benchmark the MPLS failover time, with local (link) protection provided, due to a SONET Link failure event at the Midpoint Failover Node. Test Setup Use Figure 4. The DUT is a midpoint on the primary LSP. The reamining nodes, in the indicated topology are simulated by the test device. The test device(s) will have three interfaces to the DUT: 1. Transmit MPLS Traffic to DUT 2. Receive MPLS traffic from DUT's Primary interface 3. Receive MPLS traffic from DUT's Backup interface after failover Test Configuration The DUT as midpoint Failover Node is configured for FRR. The test device(s) should emulate FRR Ingress, Primary Path Midpoint, Backup Path Midpoint, and Egress Node. The test device sources an offered load of MPLS packets to the DUT ingress interface and receives switched MPLS from the DUT. Procedure 1. Enable either IGP-TE (ISIS-TE or OSPF-TE) on the interfaces. 2. Advertise matching IGP TE-LSDB routes from Tester to DUT on both primary and backup interfaces. 3. Establish Primary LSP with Tester as in the ingress. 4. Establish Backup LSP. 5. Send labeled traffic at maximum Forwarding Rate to DUT. Label must match the one received from DUT. 6. Verify traffic switched over Primary LSP. 7. Remove SONET on DUT's interface to downstream Midpoint LSR on Primary LSP path. 8. Observe Packet Loss. 9. Measure Failover Time as DUT detects the link down event and switches MPLS traffic over the Backup LSP. 10.Recover from failure and verify Reversion does not produce any packet loss. Poretsky, Khanna, Papneja, Rao, Le Roux [Page 17] INTERNET-DRAFT Benchmarking Methodology for July 2005 MPLS Protection Mechanisms Results Packet loss upon failure at Ingress's (DUT) primary interface should be 100%. The Failover Time is the time to restore 100% of the traffic. The measured failover time is influenced by the failure indication and Hardware update time. 5.3 Fast Reroute Scalability Objective Fast Reroute Recovery Delay could be dependent upon the number of protected primary LSPs. The purpose of this test is to benchmark the number of TE LSPs that can be protected within 50ms. Test Setup Use Figure 5. The DUT is the Failover Node. All other nodes indicated in the figure are simulated by test device(s). The test device(s) will have three interfaces to the DUT: 1. Transmit MPLS Traffic to DUT 2. Receive MPLS traffic from DUT's Primary interface 3. Receive MPLS traffic from DUT's Backup interface after failover Test Configuration The Failover Node is configured for FRR. The test device(s) should emulate FRR Primary LSP Midpoint, Backup Path Midpoint, and Egress Node. The test device sources an offered load of MPLS packets to the DUT ingress interface and receives switched MPLS from the DUT. Procedure 1. Enable either IGP-TE (ISIS-TE or OSPF-TE) on the interfaces. 2. Advertise matching IGP TE-LSDB routes from Tester to DUT on both primary and backup interfaces. 3. Establish a set of number N_tot primary TE LSPs. N_tot must be quite high. Basically N_tot = 50 000 4. Establish a Bypass LSP. 5. Send trafic into each primary TE LSP at Aggregate Forwarding Rate, Rg, to DUT. 6. Verify traffic switched over Primary LSPs. 7. Remove SONET on DUT's interface to downstream Midpoint LSR on Primary LSP path. 8. Measure number of packets forwaded for 50ms, R_50. 9. Calculate the number of LSPs that are recovered within 50ms, N_50. N_50 = (R_50 / Rg) * N_tot. Results Results will vary depending upon Failover Node implementation. Poretsky, Khanna, Papneja, Rao, Le Roux [Page 18] INTERNET-DRAFT Benchmarking Methodology for July 2005 MPLS Protection Mechanisms 6. Security Considerations Documents of this type do not directly effect the security of the Internet or of corporate networks as long as benchmarking is not performed on devices or systems connected to operating networks. 7. Acknowledgements Thanks to Alia Atlas and Markus Jork for their review and suggestions for this document. Their efforts to standardize and implement Fast Reroute ([MPLS-FRR-EXT]) created the need for this benchmarking methodology. Thanks to Dr. Bijan Jabbari of Isocore for providing an independent leading edge laboratory for equipment vendors and Service Providers to evaluate and discuss MPLS protection mechanisms. 8. References [MPLS-LDP] Andersson, L., Doolan, P., Feldman, N., Fredette, A. and B. Thomas, "LDP Specification", RFC 3036, January 2001. [MPLS-RSVP] R. Braden, Ed., et al, "Resource ReSerVation protocol (RSVP) -- version 1 functional specification," RFC2205, September 1999. [MPLS-RSVP-TE] D. Awduche, et al, "RSVP-TE: Extensions to RSVP for LSP Tunnels", RFC3209, December 2001. [MPLS-FRR-EXT] Pan, P., Atlas, A., Swallow, G., "Fast Reroute Extensions to RSVP-TE for LSP Tunnels", RFC 4090, work in progress. [MPLS-ARCH] Rosen, E., Viswanathan, A. and R. Callon, "Multiprotocol Label Switching Architecture", RFC 3031, January 2001. [RFC-WORDS] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, March 1997. [RFC-IANA] T. Narten and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", RFC 2434. [TERM-ID] Poretsky, S., Papneja, R., Kimura, T., "Benchmarking Terminology for Protection Performance", draft-poretsky-protection-term-00.txt, work in progress. Poretsky, Khanna, Papneja, Rao, Le Roux [Page 19] INTERNET-DRAFT Benchmarking Methodology for July 2005 MPLS Protection Mechanisms 9. Author's Address Scott Poretsky Reef Point Systems 8 New England Executive Park Burlington, MA 01803 USA Phone: + 1 781 395 5090 EMail: sporetsky@reefpoint.com Rajiv Papneja Isocore 12359 Sunrise Valley Drive Reston, VA 22102 USA Phone: 1 703 860 9273 Email: rpapneja@isocore.com Shankar Rao Qwest Communications, 950 17th Street Suite 1900 Qwest Communications Denver, CO 80210 USA Phone: + 1 303 437 6643 Email: shankar.rao@qwest.com Jean-Louis Le Roux France Telecom FT R&D DAC/CPN av Pierre Marzin 22300 Lannion France Phone: 00 33 2 96 05 30 20 Email: jeanlouis.leroux@rd.francetelecom.com Poretsky, Khanna, Papneja, Rao, Le Roux [Page 20] INTERNET-DRAFT Benchmarking Methodology for July 2005 MPLS Protection Mechanisms Full Copyright Statement Copyright (C) The Internet Society (2005). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in 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 made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf- ipr@ietf.org. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society. Poretsky, Khanna, Papneja, Rao, Le Roux [Page 21]