Network Working Group A. Akhter Internet Draft R. Asati Expires: May 2007 cisco Systems November 30, 2006 MPLS Benchmarking Methodology Status of this Memo 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. 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 This Internet-Draft will expire on May 30, 2007. Abstract The purpose of this draft is to describe a methodology specific to the benchmarking of MPLS imposition, forwarding and disposition devices. The scope of this benchmarking will be limited to various types of packet-forwarding and delay measurements. It builds upon the tenets set forth in RFC2544, RFC1242 and other IETF Benchmarking Methodology Working Group (BMWG) efforts. This document seeks to extend these efforts into the MPLS paradigm. Akhter, et al. Expires May 30, 2007 [Page 1] Internet-Draft MPLS Benchmarking Methodology November 2006 The BMWG produces two major classes of documents: Benchmarking Terminology documents and Benchmarking Methodology documents. The Terminology documents present the benchmarks and other related terms. The Methodology documents define the procedures required to collect the benchmarks cited in the corresponding Terminology documents. Table of Contents 1. Introduction...................................................2 2. Document Scope.................................................3 3. Key Words to Reflect Requirements..............................3 4. Test Setup.....................................................3 4.1. Test Considerations.......................................4 4.1.1. IGP Support..........................................4 4.1.2. LDP Support..........................................4 4.1.3. Frame Sizes..........................................4 4.1.4. TTL..................................................5 4.1.5. Trial Duration.......................................5 4.1.6. Traffic Verification.................................5 4.1.7. Address Resolution and Dynamic Protocol State........6 4.1.8. Abbreviations Used...................................6 5. Reporting Format...............................................6 6. Test Cases - MPLS Forwarding...................................7 7. Security Considerations.......................................33 8. IANA Considerations...........................................33 9. References....................................................34 9.1. Normative References.....................................34 Author's Addresses...............................................34 Intellectual Property Statement..................................35 Disclaimer of Validity...........................................35 Copyright Statement..............................................35 Acknowledgment...................................................35 1. Introduction Over the past several years MPLS networks have gained greater popularity, however there is no standard method to compare and contrast the varying implementations and their strong and weak points. This document proposes several criteria and a methodology for the comparison of various implementations of basic MPLS forwarding devices. Akhter, et al. Expires May 30, 2007 [Page 2] Internet-Draft MPLS Benchmarking Methodology November 2006 2. Document Scope Generic MPLS is a foundation enabling technology for other more advanced technologies such as IPv4 MPLS-VPNS, Layer 2 VPNs, and MPLS Traffic Engineering. This document will limit it self to only generic MPLS such as basic label forwarding and LDP for control-plane activities. Child technologies will be covered in a subsequent set of documents. 3. Key Words to Reflect Requirements 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 BCP 14, RFC 2119 [Br97]. RFC 2119 defines the use of these key words to help make the intent of standards track documents as clear as possible. While this document uses these keywords, this document is not a standards track document. 4. Test Setup The set of methodologies described in this document will use the topologies described in this section. An effort has been made to exclude superfluous equipment needs such that each test can be carried out with the minimum number of requirements. +-----------------+ +---------+ | | +---------+ | Test | | | | Test | | Port A1 +-----+ DA1 DB1 -----+ Port B1 | +---------+ | | +---------+ +---------+ | DUT | +---------+ | Test | | | | Test | | Port A2 +-----+ DA2 DB2 +-----+ Port B2 | +---------+ | | +---------+ ... | | ... +---------+ | | +---------+ | Test | +-----------------+ | Test | | Port Ax | | Port Bx | +---------+ +---------+ Figure 1 Topology #1, Basic Forwarding Akhter, et al. Expires May 30, 2007 [Page 3] Internet-Draft MPLS Benchmarking Methodology November 2006 Where (x) is determined by the maximum unidirectional forwarding throughput of the DUT and the load capacity of the media between the Test Ports and DUT. For example, if the DUT's forwarding throughput is 100 frames per second (fps), and the media capacity is 50 fps than x = 2. The minimum value for Bx is 2, as multiple B interfaces are needed for head of line blocking testing (Section TBD). 4.1. Test Considerations This methodology assumes a full-duplex uniform medium topology. The medium used MUST be reported in each test result. Issues regarding mixed transmission media, speed mismatches, media header differences etc, are not under consideration. Flow control, QoS, Graceful Restart and other non-essential traffic or traffic-effecting features MUST be disabled, unless explicitly requested by the test case. 4.1.1. IGP Support It is highly RECOMMENDED that all of the interfaces (A1, DA1, DB1, A2..) support an IGP such as IS-IS or OSPF. While technically, MPLS can work in conjunction with RIP, EIGRP, or static routes etc, practically, devices will be used with either OSPF or IS-IS. Furthermore, there are testing considerations in this document that the device is able to provide a stable control-plane during heavy forwarding workloads. The route distribution method used (OSPF, IS- IS, static) MUST be repoted. 4.1.2. LDP Support The DUT must support at least one protocol for exchanging MPLS labels. The most commonly used protocol is Label Distribution Protocol (LDP) [RFC3036]. All of the interfaces connected to the DUT such as A1, DA1, DB1, A2 etc., MUST support Label Distribution Protocol (LDP) for IPv4 or IPv6 FECs. The test traffic generator will need to learn and advertise labels from and to the DUT using LDP. 4.1.3. Frame Sizes Each test SHOULD be run with different frame sizes in different trials. For Ethernet, the recommended sizes (in bytes) are 64, 128, 256, 512, 1024, 1280 and 1518. Recommended sizes for other media can be found in RFC 2544. Akhter, et al. Expires May 30, 2007 [Page 4] Internet-Draft MPLS Benchmarking Methodology November 2006 In addition to the individual frame size trials, an IMIX traffic trial SHOULD also be included. When running trials between different frame sizes, the DUT configuration MUST remain the same. 4.1.4. TTL The MPLS TTL or IP TTL (depending on which portion of the packet the DUT is basing the forwarding behavior) MUST be large enough to traverse the DUT. 4.1.5. Trial Duration Unless otherwise specified, the test portion of each trial SHOULD be no less than 30 seconds when static routing is in place and no less than 200 seconds when a dynamic routing protocol and LDP (default LDP hold-down timer is 180 seconds) are being used. If non-default hold- down and keepalive times are being used in the control plane, these should be reported and the trial duration adjusted such that the test portion of the trial period is longer than a full control-plane holddown cycle. The longer trial time for when dynamic routing protocols are being used is for verifying that the DUT is able to maintain a stable control-plane when the data-forwarding plane is under stress. 4.1.6. Traffic Verification In all cases, the sent traffic MUST be accounted for, whether it was received on the wrong port, correct port or not received at all. In addition, the presence of the MPLS shim, checksum, frame sequencing and correct TTL MUST be verified. The MPLS label presence will be determined by the test. Some tests will require the label to be popped while others will require a swap. In general, many test tools will by default only verify that they have received the embedded instrumented signature on the receive side, but will not validate MPLS stack depth. An even greater level of verification would be to check if the correct label was imposed, but that is considered out of scope for these tests. Akhter, et al. Expires May 30, 2007 [Page 5] Internet-Draft MPLS Benchmarking Methodology November 2006 4.1.7. Address Resolution and Dynamic Protocol State If the test or media is making use of a dynamic protocol (eg ARP, OSPF, LDP), all state for the protocols should be pre-established and in a stable condition before the start of the trial. 4.1.8. Abbreviations Used 4.1.8.1. PxRNy Port based Remote Network P := port (could be A or B) x: = port number RN := Remote Network (can also be thought of as a network that is reachable via ) Px. y := number of network. (ie the first network reachable via B1 would be called B1RN1 and the 5th network would be called B1RN5) 4.1.8.2. PxAN Port Based Attached Network P := port (could be A or B) x: = port number AN := Attached (connected) Network 5. Reporting Format For each test case, it is recommended that the following variables be reported in addition to the specific parameters requested by the test case: Akhter, et al. Expires May 30, 2007 [Page 6] Internet-Draft MPLS Benchmarking Methodology November 2006 Parameter Unit Label Allocation Protocol LDP, RSVP-TE, BGP (or combinations) IGP ISIS or OSPF Throughput Frames per second Interface Type GigE, POS, ATM etc Interface Speed 1 gbps, 100 Mbps, etc Interface Encapsulation VLAN, PPP, HDLC Packet Size Bytes Number of A and B 1A, 2B interfaces 6. Test Cases - MPLS Forwarding 6.1. MPLS Forwarding and Throughput This section contains the description of the tests that are related to the characterization of frame forwarding of a DUT in various MPLS environments. 6.1.1. Determination of Unidirectional Static Label Imposition Rate Objective To obtain the maximum label imposition rate for a regular (IPv4 or IPv6) packet by the DUT. Test Setup It is recommended that a single A and B interface SHOULD be used. However, if the forwarding rate of the DUT is more than that of the media rate, then additional A and B interfaces MUST be enabled so as to match up the DUT's forwarding throughput. The traffic streams offered MUST conform to section 16 of RFC 2544. Akhter, et al. Expires May 30, 2007 [Page 7] Internet-Draft MPLS Benchmarking Methodology November 2006 For this unidirectional test, the test tool will be sending unlabeled traffic to ports DAx and receiving labeled traffic on ports Bx. The DUT will be configured such that a single network address will be reachable via each Bx port. For example, there will be the connected network on the link between DB1 and B1, and a single network (B1RN1) will be reachable via B1's Layer 3 address. Test tool traffic will be destined to an address in each BxRN1. The DUT will be statically configured to impose a unique non-null label for each BxRN1 Discussion Procedure Offer traffic from port Ax towards DUT at a constant load towards all BxRN1 addresses for a fixed duration of time. If any frame loss is detected, the offered load is decreased and the sender will transmit again. An iterative search algorithm MUST be used to determine the maximum offered frame rate with a zero frame loss. Each iteration will involve varying the offered load of the regular traffic, while keeping the other parameters (test duration, number of interfaces, number of addresses, frame size etc) constant, until the maximum rate at which none of the offered frames are dropped is determined. Reporting Format The following parameters MUST be reflected in the test report, in addition to the parameters in section 4: o Maximum throughput as defined in RFC 1242, section 3.17. Akhter, et al. Expires May 30, 2007 [Page 8] Internet-Draft MPLS Benchmarking Methodology November 2006 o Values for each BxRN1 (eg 1.1.1.0/24) Results for each test SHOULD be in the form of a table with a row for each of the tested frame sizes. Additional columns SHOULD include: offered load and measured throughput. 6.1.2. Determination of Unidirectional Static Single Label Disposition Rate Objective To obtain the maximum label disposition rate for a regular (IPv4) packet by the DUT. Test Setup It is recommended that a single A and B interface SHOULD be used. However, if the forwarding throughput of the DUT is more than that of the media rate, then additional A and B interfaces MUST be enabled so as to match up the DUT's forwarding rate. The traffic streams offered MUST conform to section 16 of RFC 2544. For this unidirectional test, the test tool will be sending labeled traffic to ports DAx and receiving on ports Bx. The DUT will be configured such that a single network address will be reachable via each Bx port. For example, there will be the connected network on the link between DB1 and B1 (B1AN), and a single network (B1RN1) will be reachable via B1's Layer 3 address. The DUT will be statically configured such that each BxRN1 and BxAN is assigned a unique non-null label, and that label is installed in the LFIB. Test tool traffic will be destined to BxRN1 and BxAN in a weighted round robin fashion. The labels assigned to BxRN1 and BxAN on the DUT will be used. The weighting ratio between BxRN1 and BxAN is a Akhter, et al. Expires May 30, 2007 [Page 9] Internet-Draft MPLS Benchmarking Methodology November 2006 constant test parameter. A suggested ratio is 1:100 with BxAN:BxRN1. Discussion Procedure Offer traffic from port Ax towards DUT at a constant load towards all BxRN1 addresses for a fixed duration of time. If any frame loss is detected, the offered load is decreased and the sender will transmit again. An iterative search algorithm MUST be used to determine the maximum offered frame rate with a zero frame loss. Each iteration will involve varying the offered load of the regular traffic, while keeping the other parameters (test duration, number of interfaces, number of addresses, frame size, ratio of BxAN and BxRN1 etc) constant, until the maximum rate at which none of the offered frames are dropped is determined. Reporting Format The following parameters MUST be reflected in the test report, in addition to the parameters in section 4: o Maximum throughput as defined in RFC 1242, section 3.17. o Values for each BxAN (eg 1.1.1.0/24) o Ratio of BxAN:BxRN1 Results for each test SHOULD be in the form of a table with a row for each of the tested frame sizes. Additional columns SHOULD include: offered load and measured throughput. 6.1.3. Determination of Unidirectional Static Single Label Swap Rate Akhter, et al. Expires May 30, 2007 [Page 10] Internet-Draft MPLS Benchmarking Methodology November 2006 Objective To obtain the maximum label swap rate for a labeled packet by the DUT. Test Setup Although only a single A and B interface SHOULD be used, it is possible that the forwarding capacity of the box may exceed the media capacity. In such a case additional A and B interfaces MUST be enabled and traffic streams offered MUST conform to section 16 of RFC 2544. For this unidirectional test, the test tool will be sending labeled traffic to ports DAx and receiving labeled traffic on ports Bx. The DUT will be configured such that a single network address will be reachable via each Bx port. For example, there will be the connected network on the link between DB1 and B1 (B1AN), and a single network (B1RN1) will be reachable via B1's Layer 3 address. The DUT will be statically configured such that each BxRN1 is assigned a unique non-null label, and that label is installed in the LFIB. The DUT will be statically configured such that each BxRN1 incoming label (defined above) also has an outgoing label associated with the Bx next-hop, such that a label swap will occour. Test tool traffic will be destined to BxRN1. The labels assigned to BxRN1 on the DUT will be used. Discussion Procedure Offer traffic from port Ax towards DUT at a constant load towards all BxRN1 addresses for a fixed duration of time. If any frame loss is detected, the offered load is decreased and the sender will transmit again. An iterative search algorithm MUST Akhter, et al. Expires May 30, 2007 [Page 11] Internet-Draft MPLS Benchmarking Methodology November 2006 be used to determine the maximum offered frame rate with a zero frame loss. Each iteration will involve varying the offered load of the regular traffic, while keeping the other parameters (test duration, number of interfaces, number of addresses, frame size, etc) constant, until the maximum rate at which none of the offered frames are dropped is determined. Reporting Format The following parameters MUST be reflected in the test report, in addition to the parameters in section 4: o Maximum throughput as defined in RFC 1242, section 3.17. Results for each test SHOULD be in the form of a table with a row for each of the tested frame sizes. Additional columns SHOULD include: offered load and measured throughput. 6.1.4. Determination of Bidirectional Static Single Label Imposition and Disposition Rate Objective To obtain the maximum label imposition and disposition rate for a labeled packet by the DUT. Test Setup Although only a single A and B interface SHOULD be used, it is possible that the forwarding capacity of the box may exceed the media capacity. In such a case additional A and B interfaces MUST be enabled and traffic streams offered MUST conform to section 16 of RFC 2544. Akhter, et al. Expires May 30, 2007 [Page 12] Internet-Draft MPLS Benchmarking Methodology November 2006 For this bidirectional test, the test tool will be sending/receiving labeled traffic via ports DAx and receiving/sending unlabeled traffic via ports DBx. The DUT will be configured such that a single network address will be reachable via each Bx and Ax port. For example, there will be the connected network on the link between DB1 and B1 (B1AN), and a single network (B1RN1) will be reachable via B1's Layer 3 address. The DUT will be statically configured such that each AxRN1 is assigned a unique non-null label, and that label is installed in the LFIB as an outgoing label for AxRN1. Each BxRN1 will also be assigned a label, but this label will have an outgoing behavior of 'pop'. Test tool traffic will be destined to BxRN1 and AxRN1. The labels assigned to BxRN1 on the DUT will be used in traffic via DAx to BxRN1. Traffic destined to AxRN1 will be unlabeled and sent via DBx. Discussion Procedure Offer traffic from port Ax towards DUT at a constant load towards all BxRN1 addresses for a fixed duration of time. At the same time, traffic is offered from Bx towards DUT at a constant load towards the AxRN1 addresses. If any frame loss is detected, the offered load is decreased on both Ax and Bx and the sender will transmit again. An iterative search algorithm MUST be used to determine the maximum offered frame rate with a zero frame loss. Akhter, et al. Expires May 30, 2007 [Page 13] Internet-Draft MPLS Benchmarking Methodology November 2006 Each iteration will involve varying the offered load of the regular traffic, while keeping the other parameters (test duration, number of interfaces, number of addresses, frame size, etc) constant, until the maximum rate at which none of the offered frames are dropped is determined. Reporting Format The following parameters MUST be reflected in the test report, in addition to the parameters in section 4: . Maximum throughput as defined in RFC 1242, section 3.17. . If the load out of Ax and Bx are not the same, the differences must be noted. Results for each test SHOULD be in the form of a table with a row for each of the tested frame sizes. Additional columns SHOULD include: offered load and measured throughput. 6.1.5. Determination of Unidirectional Multi-label Imposition Rate Objective To obtain the maximum multi-label imposition rate for a regular (IPv4 or IPv6) packet by the DUT. Test Setup It is recommended that a single A and B interface SHOULD be used. However, if the forwarding rate of the DUT is more than that of the media rate, then additional A and B interfaces MUST be enabled so as to exceed the DUT's maximum forwarding rate. The traffic streams offered MUST conform to section 16 of RFC 2544. Akhter, et al. Expires May 30, 2007 [Page 14] Internet-Draft MPLS Benchmarking Methodology November 2006 For this unidirectional test, the test tool will be sending unlabeled traffic to ports DAx and receiving multi-labeled traffic on ports Bx. The DUT will be configured such that a single network address will be reachable via each Bx port. For example, there will be the connected network on the link between DB1 and B1, and a single network (B1RN1) will be reachable via B1's Layer 3 address. Test tool traffic will be destined to an address in each BxRN1. The DUT will be configured to enable imposing a multi-label MPLS shim header consistiting of unique non-null labels for each BxRN1. The multi-label may be imposed by BxRN1 being reachable via a MPLS- TE (Traffic Engineering) tunnel, BxRN1 being a MPLS-L3VPN address or other forms. Specifically, MPLS L2VPNs MUST NOT be used to create the multi-label state. Discussion MPLS-TE as as well as MPLS-VPNs would require the DUT to process the IP headers of the test packet. However, in the case of MPLS- L2VPNs, the IP header is not processed at all and therefore the DUT has fewer and simpler operations to perform. In addition, the number of 'IGP LSPs' (number of outer label LSP tunnels used to deliver the inner label packets to the destination ports), MUST be a minimum of 1 per DBx. Procedure Offer traffic from port Ax towards DUT at a constant load towards all BxRN1 addresses for a fixed duration of time. If any frame loss is detected, the offered load is decreased and the sender will transmit again. An iterative search algorithm MUST be used to determine the maximum offered frame rate with a zero frame loss. Akhter, et al. Expires May 30, 2007 [Page 15] Internet-Draft MPLS Benchmarking Methodology November 2006 Each iteration will involve varying the offered load of the regular traffic, while keeping the other parameters (test duration, number of interfaces, number of addresses, frame size etc) constant, until the maximum rate at which none of the offered frames are dropped is determined. Reporting Format The following parameters MUST be reflected in the test report, in addition to the parameters in section 4: o Maximum throughput as defined in RFC 1242, section 3.17. o Values for each BxRN1 (eg 1.1.1.0/24) o Method used to create multi-label state o Number of 'IGP LSPs' used Results for each test SHOULD be in the form of a table with a row for each of the tested frame sizes. Additional columns SHOULD include: offered load and measured throughput. 6.1.6. Determination of Unidirectional Multi-label Disposition Rate Objective To obtain the maximum multi-label disposition rate for a regular (IPv4 or IPv6) packet by the DUT. Test Setup It is recommended that a single A and B interface SHOULD be used. However, if the forwarding rate of the DUT is more than that of the media rate, then additional A and B interfaces MUST be enabled so as to exceed the DUT's maximum forwarding rate. The traffic streams offered MUST conform to section 16 of RFC 2544. Akhter, et al. Expires May 30, 2007 [Page 16] Internet-Draft MPLS Benchmarking Methodology November 2006 For this unidirectional test, the test tool will be sending multi- labeled traffic to ports DAx and receiving unlabeled traffic on ports Bx. The DUT will be configured such that a single network address will be reachable via each Bx port. For example, there will be the connected network on the link between DB1 and B1, and a single network (B1RN1) will be reachable via B1's Layer 3 address. Test tool traffic will be destined to an address in each BxRN1. The DUT will be configured to allocate a multi-label MPLS shim header consistiting of unique non-null labels for each BxRN1. The multi-label may be imposed by BxRN1 being reachable via a MPLS-TE (Traffic Engineering) tunnel, BxRN1 being a MPLS-L3VPN address or other forms. Discussion The number of 'IGP LSPs' (number of outer label LSP tunnels used to deliver the inner label packets to the destination ports), MUST be a minimum of 1 per DBx. Procedure Offer multi-labeled traffic from port Ax towards DUT at a constant load towards all BxRN1 addresses for a fixed duration of time. If any frame loss is detected, the offered load is decreased and the sender will transmit again. An iterative search algorithm MUST be used to determine the maximum offered frame rate with a zero frame loss. Each iteration will involve varying the offered load of the regular traffic, while keeping the other parameters (test duration, number of interfaces, number of addresses, frame size etc) constant, until the maximum rate at which none of the offered frames are dropped is determined. Akhter, et al. Expires May 30, 2007 [Page 17] Internet-Draft MPLS Benchmarking Methodology November 2006 Reporting Format The following parameters MUST be reflected in the test report, in addition to the parameters in section 4: o Maximum throughput as defined in RFC 1242, section 3.17. o Values for each BxRN1 (eg 1.1.1.0/24) o Method used to create multi-label state o Number of 'IGP LSPs' used Results for each test SHOULD be in the form of a table with a row for each of the tested frame sizes. Additional columns SHOULD include: offered load and measured throughput. 6.1.7. Determination of Unidirectional Single Label Disposition Rate with Explicit-null Objective To obtain the maximum exp-null label disposition rate for a regular (IPv4 or IPv6) packet by the DUT. Test Setup It is recommended that a single A and B interface SHOULD be used. However, if the forwarding rate of the DUT is more than that of the media rate, then additional A and B interfaces MUST be enabled so as to exceed the DUT's maximum forwarding rate. The traffic streams offered MUST conform to section 16 of RFC 2544. For this unidirectional test, the test tool will be sending exp- null labeled traffic to ports DAx and receiving unlabeled traffic on ports Bx. The DUT will be configured such that a single network address will be reachable via each Bx port. For example, there will be the Akhter, et al. Expires May 30, 2007 [Page 18] Internet-Draft MPLS Benchmarking Methodology November 2006 connected network on the link between DB1 and B1, and a single network (B1RN1) will be reachable via B1's Layer 3 address. Test tool traffic will be destined to an address in each BxRN1. Discussion Procedure Offer explicit-null traffic from port Ax towards DUT at a constant load towards all BxRN1 addresses for a fixed duration of time. If any frame loss is detected, the offered load is decreased and the sender will transmit again. An iterative search algorithm MUST be used to determine the maximum offered frame rate with a zero frame loss. Each iteration will involve varying the offered load of the regular traffic, while keeping the other parameters (test duration, number of interfaces, number of addresses, frame size etc) constant, until the maximum rate at which none of the offered frames are dropped is determined. Reporting Format The following parameters MUST be reflected in the test report, in addition to the parameters in section 4: o Maximum throughput as defined in RFC 1242, section 3.17. o Values for each BxRN1 (eg 1.1.1.0/24) Results for each test SHOULD be in the form of a table with a row for each of the tested frame sizes. Additional columns SHOULD include: offered load and measured throughput. Akhter, et al. Expires May 30, 2007 [Page 19] Internet-Draft MPLS Benchmarking Methodology November 2006 6.1.8. Determination of Unidirectional Single Label Swap Rate with Explicit-null Objective To obtain the maximum exp-null label swap rate for a regular (IPv4 or IPv6) packet by the DUT. Test Setup It is recommended that a single A and B interface SHOULD be used. However, if the forwarding rate of the DUT is more than that of the media rate, then additional A and B interfaces MUST be enabled so as to exceed the DUT's maximum forwarding rate. The traffic streams offered MUST conform to section 16 of RFC 2544. For this unidirectional test, the test tool will be sending exp- null labeled traffic to ports DAx and receiving exp-null traffic on ports Bx. The DUT will be configured such that a single network address will be reachable via each Bx port. For example, there will be the connected network on the link between DB1 and B1, and a single network (B1RN1) will be reachable via B1's Layer 3 address. Test tool traffic will be destined to an address in each BxRN1. Discussion Procedure Offer explicit-null traffic from port Ax towards DUT at a constant load towards all BxRN1 addresses for a fixed duration of time. If any frame loss is detected, the offered load is decreased and the sender will transmit again. An iterative search algorithm MUST be used to determine the maximum offered frame rate with a zero frame loss. Akhter, et al. Expires May 30, 2007 [Page 20] Internet-Draft MPLS Benchmarking Methodology November 2006 Each iteration will involve varying the offered load of the regular traffic, while keeping the other parameters (test duration, number of interfaces, number of addresses, frame size etc) constant, until the maximum rate at which none of the offered frames are dropped is determined. Reporting Format The following parameters MUST be reflected in the test report, in addition to the parameters in section 4: o Maximum throughput as defined in RFC 1242, section 3.17. o Values for each BxRN1 (eg 1.1.1.0/24) Results for each test SHOULD be in the form of a table with a row for each of the tested frame sizes. Additional columns SHOULD include: offered load and measured throughput. 6.1.9. Determination of Unidirectional Multi-label Imposition Rate with Explicit-null Objective To obtain the maximum multi-label imposition rate for a regular (IPv4 or IPv6) packet by the DUT, where the outer label is explicit-null. Test Setup It is recommended that a single A and B interface SHOULD be used. However, if the forwarding rate of the DUT is more than that of the media rate, then additional A and B interfaces MUST be enabled so as to match up the DUT's forwarding throughput. The traffic streams offered MUST conform to section 16 of RFC 2544. For this unidirectional test, the test tool will be sending unlabeled traffic to ports DAx and receiving multi-labeled traffic on ports Bx. Akhter, et al. Expires May 30, 2007 [Page 21] Internet-Draft MPLS Benchmarking Methodology November 2006 The DUT will be configured such that a single network address will be reachable via each Bx port. For example, there will be the connected network on the link between DB1 and B1, and a single network (B1RN1) will be reachable via B1's Layer 3 address. Test tool traffic will be destined to an address in each BxRN1. The DUT will be statically configured to impose a unique non-null label for each BxRN1, and explicit-null as the outer label. Discussion Procedure Offer traffic from port Ax towards DUT at a constant load towards all BxRN1 addresses for a fixed duration of time. If any frame loss is detected, the offered load is decreased and the sender will transmit again. An iterative search algorithm MUST be used to determine the maximum offered frame rate with a zero frame loss. Each iteration will involve varying the offered load of the regular traffic, while keeping the other parameters (test duration, number of interfaces, number of addresses, frame size etc) constant, until the maximum rate at which none of the offered frames are dropped is determined. Reporting Format The following parameters MUST be reflected in the test report, in addition to the parameters in section 4: o Maximum throughput as defined in RFC 1242, section 3.17. o Values for each BxRN1 (eg 1.1.1.0/24) Akhter, et al. Expires May 30, 2007 [Page 22] Internet-Draft MPLS Benchmarking Methodology November 2006 Results for each test SHOULD be in the form of a table with a row for each of the tested frame sizes. Additional columns SHOULD include: offered load and measured throughput. 6.1.10. Determination of Unidirectional Multi-label Disposition Rate with Explicit-null Objective To obtain the maximum multi-label disposition rate for a regular (IPv4 or IPv6) packet by the DUT, where the outer label is explicit-null. Test Setup It is recommended that a single A and B interface SHOULD be used. However, if the forwarding rate of the DUT is more than that of the media rate, then additional A and B interfaces MUST be enabled so as to exceed the DUT's maximum forwarding rate. The traffic streams offered MUST conform to section 16 of RFC 2544. For this unidirectional test, the test tool will be sending traffic such that the outer label is explict-null and the inner label is a unique non-null label. This multi-label traffic will be sent to ports DAx and received as unlabeled traffic on ports Bx. The DUT will be configured such that a single network address will be reachable via each Bx port. For example, there will be the connected network on the link between DB1 and B1, and a single network (B1RN1) will be reachable via B1's Layer 3 address. Test tool traffic will be destined to an address in each BxRN1. Akhter, et al. Expires May 30, 2007 [Page 23] Internet-Draft MPLS Benchmarking Methodology November 2006 The DUT will be statically configured such that each BxRN1 and BxAN is assigned a unique non-null label, and that label is installed in the LFIB. Test tool traffic will be destined to BxRN1 and BxAN in a weighted round robin fashion. The labels assigned to BxRN1 and BxAN on the DUT will be used. The weighting ratio between BxRN1 and BxAN is a constant test parameter. A suggested ratio is 1:100 with BxAN:BxRN1. Discussion Procedure Offer traffic from port Ax towards DUT at a constant load towards all BxRN1 addresses for a fixed duration of time. If any frame loss is detected, the offered load is decreased and the sender will transmit again. An iterative search algorithm MUST be used to determine the maximum offered frame rate with a zero frame loss. Each iteration will involve varying the offered load of the regular traffic, while keeping the other parameters (test duration, number of interfaces, number of addresses, frame size etc) constant, until the maximum rate at which none of the offered frames are dropped is determined. Reporting Format The following parameters MUST be reflected in the test report, in addition to the parameters in section 4: o Maximum throughput as defined in RFC 1242, section 3.17. o Values for each BxRN1 (eg 1.1.1.0/24) Akhter, et al. Expires May 30, 2007 [Page 24] Internet-Draft MPLS Benchmarking Methodology November 2006 o Ratio of BxAN:BxRN1 Results for each test SHOULD be in the form of a table with a row for each of the tested frame sizes. Additional columns SHOULD include: offered load and measured throughput. 6.1.11. Determination of Unidirectional Single Label Disposition Rate for Aggregate Label Objective To obtain the maximum label disposition rate for a regular (IPv4) packet by the DUT, where the packet needs to be IP processed. Test Setup It is recommended that a single A and B interface SHOULD be used. However, if the forwarding throughput of the DUT is more than that of the media rate, then additional A and B interfaces MUST be enabled so as to match up the DUT's forwarding rate. The traffic streams offered MUST conform to section 16 of RFC 2544. For this unidirectional test, the test tool will be sending labeled traffic to ports DAx and receiving unlabelled traffic on ports Bx. The DUT will be configured such that a single network address will be reachable via each Bx port. For example, there will be the connected network on the link between DB1 and B1 (B1AN), and a single network (B1RN1) will be reachable via B1's Layer 3 address. The DUT will be statically configured such that each BxRN1 and BxAN is assigned a unique non-null label, and that label is installed in the LFIB. Test tool traffic will be destined to BxAN using the labels assigned to BxAN on the DUT. Discussion Akhter, et al. Expires May 30, 2007 [Page 25] Internet-Draft MPLS Benchmarking Methodology November 2006 Procedure Offer traffic from port Ax towards DUT at a constant load towards all BxRN1 addresses for a fixed duration of time. If any frame loss is detected, the offered load is decreased and the sender will transmit again. An iterative search algorithm MUST be used to determine the maximum offered frame rate with a zero frame loss. Each iteration will involve varying the offered load of the regular traffic, while keeping the other parameters (test duration, number of interfaces, number of addresses, frame size, ratio of BxAN and BxRN1 etc) constant, until the maximum rate at which none of the offered frames are dropped is determined. Reporting Format The following parameters MUST be reflected in the test report, in addition to the parameters in section 4: o Maximum throughput as defined in RFC 1242, section 3.17. o Values for each BxAN (eg 1.1.1.0/24) Results for each test SHOULD be in the form of a table with a row for each of the tested frame sizes. Additional columns SHOULD include: offered load and measured throughput. 6.1.12. Determination of Unidirectional Static Single label Swap Rate for Aggregate Label Objective To obtain the maximum label swap rate for a labeled packet by the DUT, where the ingress label is an aggregate label. Test Setup Akhter, et al. Expires May 30, 2007 [Page 26] Internet-Draft MPLS Benchmarking Methodology November 2006 Although only a single A and B interface SHOULD be used, it is possible that the forwarding capacity of the box may exceed the media capacity. In such a case additional A and B interfaces MUST be enabled and traffic streams offered MUST conform to section 16 of RFC 2544. For this unidirectional test, the test tool will be sending labeled traffic to ports DAx and receiving labeled traffic on ports Bx. The DUT will be configured such that a single network address will be reachable via each Bx port. For example, there will be the connected network on the link between DB1 and B1 (B1AN), and a single network (B1RN1) will be reachable via B1's Layer 3 address. The DUT will be configured such that each BxRN1 is assigned a unique non-null aggregate label, and that label is installed in the LFIB. The DUT will be statically configured such that each BxRN1 incoming label (defined above) also has an outgoing label associated with the Bx next-hop, such that a label swap will occur. Test tool traffic will be destined to BxRN1. The aggregate labels mapping to BxRN1 on the DUT will be used. Discussion Procedure Offer traffic from port Ax towards DUT at a constant load towards all BxRN1 addresses for a fixed duration of time. If any frame loss is detected, the offered load is decreased and the sender will transmit again. An iterative search algorithm MUST be used to determine the maximum offered frame rate with a zero frame loss. Each iteration will involve varying the offered load of the regular traffic, while keeping the other parameters (test duration, number of interfaces, number of addresses, frame size, etc) constant, until the maximum rate at which none of the offered frames are dropped is determined. Akhter, et al. Expires May 30, 2007 [Page 27] Internet-Draft MPLS Benchmarking Methodology November 2006 Reporting Format The following parameters MUST be reflected in the test report, in addition to the parameters in section 4: o Maximum throughput as defined in RFC 1242, section 3.17. Results for each test SHOULD be in the form of a table with a row for each of the tested frame sizes. Additional columns SHOULD include: offered load and measured throughput. 6.1.13. Determination of Unidirectional IPv4 packet Fragmentation Rate with Imposition Objective To obtain the maximum label imposition rate for a packet by the DUT, where label imposition results in IP fragmentation. Test Setup Although only a single A and B interface SHOULD be used, it is possible that the forwarding capacity of the box may exceed the media capacity. In such a case additional A and B interfaces MUST be enabled and traffic streams offered MUST conform to section 16 of RFC 2544. The MTU on ports DBx should be reduced such that single label imposition results in IP fragmentation. For this unidirectional test, the test tool will be sending unlabeled traffic to ports DAx and receiving fragmented labeled traffic on ports Bx. The DUT will be configured such that a single network address will be reachable via each Bx port. For example, there will be the Akhter, et al. Expires May 30, 2007 [Page 28] Internet-Draft MPLS Benchmarking Methodology November 2006 connected network on the link between DB1 and B1 (B1AN), and a single network (B1RN1) will be reachable via B1's Layer 3 address. The DUT will be statically configured to impose a unique non-null label for each BxRN1 Discussion Given that test tools may not be able to completely validate the fragmentation, as the instrumented signature would only be present in one of the fragments, or spread out amongst multiple fragments, it is acceptable to use packet counts to validate the received packets. Procedure Offer traffic from port Ax towards DUT at a constant load towards all BxRN1 addresses for a fixed duration of time. If any frame loss is detected, the offered load is decreased and the sender will transmit again. An iterative search algorithm MUST be used to determine the maximum offered frame rate with a zero frame loss. Each iteration will involve varying the offered load of the regular traffic, while keeping the other parameters (test duration, number of interfaces, number of addresses, frame size, etc) constant, until the maximum rate at which none of the offered frames are dropped is determined. Reporting Format The following parameters MUST be reflected in the test report, in addition to the parameters in section 4: o Maximum throughput as defined in RFC 1242, section 3.17. o Changed MTU value o Size and number of fragments from each test packet Akhter, et al. Expires May 30, 2007 [Page 29] Internet-Draft MPLS Benchmarking Methodology November 2006 Results for each test SHOULD be in the form of a table with a row for each of the tested frame sizes. Additional columns SHOULD include: offered load and measured throughput. 6.1.14. Stability Verification under Unidirectional MPLS Imposition with IPv6 Extension Header Objective Verify that control plane remains stable while processing IPv6 packet with hop-by-hop extension header. Test Setup For this unidirectional test, the test tool will be sending unlabeled IPv6 traffic to ports DAx and receiving labeled traffic on ports Bx. The unlabeled traffic will include a hop-by-hop Router Alert (RFC2711) extension header that will need to be processed by the local software module. The configuration of policing technology such that LER resources are not overwhelmed as long as this policy is also present for all other tests is allowed and recommended. Other factors in this setup can be the same as in the previous testcase with unidirectional MPLS imposition. Discussion The IPv6 hop-by-hop router alert extension header requires the software module of the LER to follow special processing of the packet. As the router alert is not considered regular traffic, the purpose of this test is not to benchmark the maximum forwarding rate, but to ensure that the router can maintain self stability as well as a stable control plane while dealing with router alert traffic. Procedure Offer traffic from port Ax towards DUT at a constant load towards all BxRN1 addresses for a fixed duration of time. Relevant LER resources (CPU, memory, etc) should be monitored for reporting. Control plane (IGP, LDP, etc) MUST be monitored such Akhter, et al. Expires May 30, 2007 [Page 30] Internet-Draft MPLS Benchmarking Methodology November 2006 that control session does not drop and relevant hello packets are within receive and transmit windows. If any frame loss is detected, the loss rate should be recorded. Reporting Format The following parameters MUST be reflected in the test report, in addition to the parameters in section 4: o Changed packet rate such at 1%, 10% and 50% of interface bandwidth is consumed. Results for each test SHOULD be in the form of a table with a row for each of the tested frame sizes. Additional columns SHOULD include: offered load and measured throughput. 6.1.15. Stability Verification for Unidirectional MPLS Imposition with IPv4 Router Options The test is exactly the same as the 'Stability Verification under Unidirectional MPLS Imposition with IPv6 Extension Header' test except IPv4 traffic with the router-alert option is to be used. 6.1.16. Stability Verification under Unidirectional MPLS Forwarding with Router Alert Label Objective Verify that control plane remains stable while processing MPLS frame with Router Alert label. Test Setup For this unidirectional test, the test tool will be sending labeled traffic to ports DAx and receiving labeled traffic on ports Bx. The traffic will include a Router Alert label as well an additional label that will determine forwarding. The configuration of policing technology such that LER resources are not overwhelmed as long as this policy is also present for all other tests is allowed and recommended. As the control plane stability is being tested, a dynamic label distribution protocol must be used on both port A and B. Akhter, et al. Expires May 30, 2007 [Page 31] Internet-Draft MPLS Benchmarking Methodology November 2006 Other factors in this setup can be the same as in the previous testcase with unidirectional MPLS label swapping. Discussion The MPLS Router Alert label requires the software module of the LSR to follow special processing of the packet. As the router alert is not considered regular traffic, the purpose of this test is not to benchmark the maximum forwarding rate, but to ensure that the router can maintain self stability as well as a stable control plane while dealing with router alert traffic. Procedure Offer traffic from port Ax towards DUT at a constant load towards all BxRN1 addresses for a fixed duration of time. Relevant LER resources (CPU, memory, etc) should be monitored for reporting. Control plane (IGP, LDP, etc) MUST be monitored such that control session does not drop and relevant hello packets are within receive and transmit windows. If any frame loss is detected, the loss rate should be recorded. Reporting Format The following parameters MUST be reflected in the test report, in addition to the parameters in section 4: o Changed packet rate such at 1%, 10% and 50% of interface bandwidth is consumed. Results for each test SHOULD be in the form of a table with a row for each of the tested frame sizes. Additional columns SHOULD include: offered load and measured throughput. Offer traffic from port Ax towards DUT at a constant load towards all BxRN1 addresses for a fixed duration of time. If any frame loss is detected, the offered load is decreased and the sender will transmit again. An iterative search algorithm MUST be used to determine the maximum offered frame rate with a zero frame loss. Akhter, et al. Expires May 30, 2007 [Page 32] Internet-Draft MPLS Benchmarking Methodology November 2006 Each iteration will involve varying the offered load of the regular traffic, while keeping the other parameters (test duration, number of interfaces, number of addresses, frame size, etc) constant. 7. Security Considerations During the course of test, the test topology must be disconnected from devices that may forward the test traffic into a production environment. There are no specific security considerations within the scope of this document. 8. IANA Considerations There are no considerations for IANA at this time. Akhter, et al. Expires May 30, 2007 [Page 33] Internet-Draft MPLS Benchmarking Methodology November 2006 9. References 9.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2544] Bradner, S. and McQuaid, J., "Benchmarking Methodology for Network Interconnect Devices", RFC 2544, March 1999. [RFC1242] Bradner, S., Editor, "Benchmarking Terminology for Network Interconnection Devices", RFC 1242, July 1991. [RFC3036] Andersson, L., Doolan, P., Feldman, N., Fredette, A. and B. Thomas, "LDP Specification", RFC 3036, January 2001. Author's Addresses Aamer Akhter Cisco Systems 7025 Kit Creek Road RTP, NC 27709 USA Phone: 919 392 2564 Email: aakhter@cisco.com Rajiv Asati Cisco Systems 7025 Kit Creek Road RTP, NC 27709 USA Phone: 919 392 8558 Email: rajiva@cisco.com Akhter, et al. Expires May 30, 2007 [Page 34] Internet-Draft MPLS Benchmarking Methodology November 2006 Intellectual Property Statement 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. Disclaimer of Validity 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. Copyright Statement Copyright (C) The Internet Society (2006). 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. Acknowledgment Special thanks to Scott Bradner for his very insightful comments delivered on very short notice. Akhter, et al. Expires May 30, 2007 [Page 35] Internet-Draft MPLS Benchmarking Methodology November 2006 Funding for the RFC Editor function is currently provided by the Internet Society. Akhter, et al. Expires May 30, 2007 [Page 36]