Network Working Group INTERNET-DRAFT Expires in: December 2003 Scott Poretsky Rajesh Khanna Avici Systems Rajiv Papneja Isocore Shankar Rao Qwest Communications June 2003 Benchmarking Methodology for MPLS Protection Mechanisms Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. 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. ABSTRACT This draft describes the methodology for benchmarking MPLS protection mechanisms. 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 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 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 Poretsky, Khanna, Papneja, Rao [Page 1] INTERNET-DRAFT Benchmarking Methodology for June 2003 MPLS Protection Mechanisms be used to compare failover performance of different Label-Switched Routers and evaluate the different MPLS protection mechanisms. Table of Contents 1. Introduction ...............................................2 2. Existing definitions........................................3 3. Test Considerations.........................................4 4. Test Setup..................................................5 5. Test Cases..................................................8 6. Security Considerations.....................................17 7. Acknowledgements............................................17 8. References..................................................17 9. Author's Address............................................18 10. Full Copyright Statement...................................18 1. Introduction MPLS-TE offers three options for Protection Mechanisms to reroute traffic from a Primary LSP to a Backup LSP: Headend Reroute, Standby LSP, and Fast 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 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 less than 500msec failover, 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. Poretsky, Khanna, Papneja, Rao [Page 2] INTERNET-DRAFT Benchmarking Methodology for June 2003 MPLS Protection Mechanisms FRR is an extension to TE specified in 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 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 | | PLR | |MidPoint| | Merge | | Egress | | 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. Methodology for benchmarking MPLS protection mechanisms can be developed completely with use of terminology existing in IETF RFCs and drafts produced in the MPLS Working Group. The reader is assumed Poretsky, Khanna, Papneja, Rao [Page 3] INTERNET-DRAFT Benchmarking Methodology for June 2003 MPLS Protection Mechanisms to be familiar with the terminology in [MPLS-RSVP], [MPLS-RSVP-TE], [MPLS-FRR-EXT], and MPLS Ping. A brief summary of these terms is provided to facilitate reference: LSP LSR Local Repair PLR Ingress Egress Mid-Point Merge Point One-to-one Backup Facility Backup Protected LSP Primary LSP Backup LSP Detour LSP Bypass Tunnel Backup Tunnel Backup Path Detour Merge Point Reroute Headend Reroute Reroutable LSP Standby LSP Failover Time Link Protection Node Protection Make-Before-Break 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 Types of Failover Events Causes of reroute are administration change, link failure, node failure, and path optimization. Indication for these types of failures wil vary whether the failure is local or remote. 3.2 Network Indications for Failover Local failures can be detected via SONET failure with directly connected LSR. For an ingress administrative change a make-before-break should occur to prevent any packet loss. Remote failures are indicated via Control Plane signaling. Signaling indications are Negative RSVP Indication (loss of PATH Refresh messages from upstream node or loss of RESV Refresh messages from downstream node), Positive RSVP Indication (receipt of PATHTear Poretsky, Khanna, Papneja, Rao [Page 4] INTERNET-DRAFT Benchmarking Methodology for June 2003 MPLS Protection Mechanisms 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. For remote failure cases, the methodologies in this document evaluate failover performance independent of the implemented signaling indication mechanism. 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 Scaling Failover Time performance may vary with the number of established primary and backup LSPs. The methodologies may be used for any number of LSPs. It is intended with Fast Reroute that the less than 45msec failover requirement is met when scaling the number of protected LSPs. 3.5 Selection of IGP The methodologies can be used with ISIS-TE or OSPF-TE. 4. Test Setup There are numerous test setups for MPLS Performance Benchmarking 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. Poretsky, Khanna, Papneja, Rao [Page 5] INTERNET-DRAFT Benchmarking Methodology for June 2003 MPLS Protection Mechanisms 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 PLR with Link Protection -------- -------- -------- -------- -------- |Ingress | | PLR | |MidPoint| | Merge | | Egress | | |----| DUT |----| Node |----| Node |----| Node | -------- -------- -------- -------- -------- | | | -------- | ---|Backup |-- |Midpoint| -------- Figure 4. Test Setup with DUT as PLR with Link Protection 4.3 DUT as PLR with Node Protection -------- -------- -------- -------- -------- |Ingress | | PLR | |MidPoint| | Merge | | Egress | | |----| DUT |----| Node |----| Node |----| Node | -------- -------- -------- -------- -------- | | | -------- | ---------|Backup |--------- |Midpoint| -------- Figure 5. Test Setup with DUT as PLR with Node Protection 4.4 DUT as Merge Node -------- -------- -------- -------- -------- |Ingress | | PLR | |MidPoint| | Merge | | Egress | | |----| |----| Node |----|Node DUT|----| Node | -------- -------- -------- -------- -------- | | | -------- | ---------|Backup |--------- |Midpoint| -------- Figure 6. Test Setup with DUT as Merge Node Poretsky, Khanna, Papneja, Rao [Page 6] INTERNET-DRAFT Benchmarking Methodology for June 2003 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 PLR with Link Protection -------- -------- -------- -------- |Ingress/| |MidPoint| | Merge | | Egress | |PLR DUT |----| Node |----| Node |----| Node | -------- -------- -------- -------- | | | -------- | ---|Backup |-- |Midpoint| -------- Figure 8. Test Setup with DUT as Ingress and PLR with Link Protection 4.7 DUT as Ingress and PLR with Node Protection -------- -------- -------- -------- |Ingress/| |MidPoint| | Merge | | Egress | |PLR DUT |----| Node |----| Node |----| Node | -------- -------- -------- -------- | | | -------- | ---------|Backup |--------- |Midpoint| -------- Figure 9. Test Setup with DUT as Ingress and PLR with Node Protection Poretsky, Khanna, Papneja, Rao [Page 7] INTERNET-DRAFT Benchmarking Methodology for June 2003 MPLS Protection Mechanisms 4.8 DUT as Egress and Merge Node -------- -------- -------- --------- |Ingress | | PLR | |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 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 [Page 8] INTERNET-DRAFT Benchmarking Methodology for June 2003 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. Results Packet loss upon SONET 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 Local SONET 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 [Page 9] INTERNET-DRAFT Benchmarking Methodology for June 2003 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. 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. Poretsky, Khanna, Papneja, Rao [Page 10] INTERNET-DRAFT Benchmarking Methodology for June 2003 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 PLR 5.1.2.1 Ingress PLR Objective To benchmark the MPLS failover time due to a Local SONET Link failure event at the Ingress also configured as PLR 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. Poretsky, Khanna, Papneja, Rao [Page 11] INTERNET-DRAFT Benchmarking Methodology for June 2003 MPLS Protection Mechanisms Results Packet loss upon SONET 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 Local SONET failure indication and Hardware update time. 5.1.2.2 Midpoint PLR Objective To benchmark the MPLS failover time, with node protection provided, due to a SONET Link failure event at the Midpoint PLR. Test Setup Use Figure 5. 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 PLR 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. Results Packet loss upon SONET failure on midpoint LSRs (DUT) primary LSP interface should be 100%. The Failover Time is the time to restore 100% of the traffic. The measured failover time is influenced by the Local SONET failure indication and Hardware update time. Poretsky, Khanna, Papneja, Rao [Page 12] INTERNET-DRAFT Benchmarking Methodology for June 2003 MPLS Protection Mechanisms 5.1.4 Merge Node 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 PLR 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. Results Packet loss should be ideally 0% once the PLR 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]. Poretsky, Khanna, Papneja, Rao [Page 13] INTERNET-DRAFT Benchmarking Methodology for June 2003 MPLS Protection Mechanisms 5.1.5 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 PLR 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 and maps the IP traffic correctly to the destination. Results Packet loss should be ideally 0% once the PLR 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]. Poretsky, Khanna, Papneja, Rao [Page 14] INTERNET-DRAFT Benchmarking Methodology for June 2003 MPLS Protection Mechanisms 5.2 Link Protection 5.2.1 Ingress PLR 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. Results Packet loss upon SONET 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 Local SONET failure indication and Hardware update time. Poretsky, Khanna, Papneja, Rao [Page 15] INTERNET-DRAFT Benchmarking Methodology for June 2003 MPLS Protection Mechanisms 5.2.2 Midpoint PLR Objective To benchmark the MPLS failover time, with local (link) protection provided, due to a SONET Link failure event at the Midpoint PLR. 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 PLR 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. Results Packet loss upon SONET failure on midpoint LSRs (DUT) primary LSP interface should be 100%. The Failover Time is the time to restore 100% of the traffic. The measured failover time is influenced by the Local SONET failure indication and Hardware update time. Poretsky, Khanna, Papneja, Rao [Page 16] INTERNET-DRAFT Benchmarking Methodology for June 2003 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 the 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 machanisms. 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., et al, "Fast Reroute Extensions to RSVP-TE for LSP Tunnels", draft-ietf-mpls-rsvp-lsp-fastreroute-02.txt, Work in progress. [MPLS-ARCH] Rosen, E., Viswanathan, A. and R. Callon, "Multiprotocol Label Switching Architecture", RFC 3031, January 2001. [MPLS-PING] Kompella, K., Pan, P. Sheth, N., Cooper, D., Swallow, G., Wadhwa, S., and Bonica, R., "Detecting MPLS Data Plane Liveness", draft-ietf-mpls-lsp-ping-02.txt, work in progress. [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. Poretsky, Khanna, Papneja, Rao [Page 17] INTERNET-DRAFT Benchmarking Methodology for June 2003 MPLS Protection Mechanisms 9. Author's Address Scott Poretsky Avici Systems, Inc. 101 Billerica Avenue N. Billerica, MA 01862 USA Phone: + 1 978 964 2287 EMail: sporetsky@avici.com Rajesh Khanna Avici Systems, Inc. 101 Billerica Avenue N. Billerica, MA 01862 USA Phone: EMail: rkhanna@avici.com Rajiv Papneja Isocore 8201 Greensboro Drive, Suite 100 Mclean, VA 20190 USA Phone: 1 703 556 4977 Email: rpapneja@isocore.com Shankar Rao Qwest Communications, 950 17th Street Suite 1900 Denver, CO 80202 USA Phone: +1 303 437 6643 Email: srao@qwest.net 10. Full Copyright Statement Copyright (C) The Internet Society (1998). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet Poretsky, Khanna, Papneja, Rao [Page 18] INTERNET-DRAFT Benchmarking Methodology for June 2003 MPLS Protection Mechanisms organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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. Poretsky, Khanna, Papneja, Rao [Page 19]