[Docs] [txt|pdf] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03 04

Network Working Group                                         A. Akhter
Internet Draft                                                 R. Asati
Expires: January 2007                                         M. Khalid

                                                          cisco Systems
                                                          July 12, 2006


                       MPLS Benchmarking Methodology
                   <draft-akhter-bmwg-mpls-meth-01.txt>


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 January 18, 2007.

Abstract

   The purpose of this draft is to describe methodology specific to the
   benchmarking of MPLS forwarding 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



Akhter, et al.         Expires January 18, 2007                [Page 1]


Internet-Draft      MPLS Benchmarking Methodology             July 2006


   Group (BMWG) efforts.  This document seeks to extend these efforts to
   the MPLS paradigm.



   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...................................................3
   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..........................................5
         4.1.3. Frame Sizes..........................................5
         4.1.4. TTL..................................................5
         4.1.5. Trial Duration.......................................5
         4.1.6. Traffic Verification.................................6
         4.1.7. Address Resolution and Dynamic Protocol State........6
         4.1.8. Abbreviations Used...................................6
   5. Reporting Format...............................................7
   6. Test Cases - MPLS Forwarding...................................8
      6.1. MPLS Forwarding and Throughput............................8
      6.2. MPLS Forwarding - EXP Operations.........................30
      6.3. MPLS Forwarding Delay Measurement........................31
      6.4. MPLS Forwarding Negative Characterization................32
   7. Security Considerations.......................................32
   8. IANA Considerations...........................................32
   9. References....................................................33
      9.1. Normative References.....................................33
   Author's Addresses...............................................33
   Intellectual Property Statement..................................34
   Disclaimer of Validity...........................................34
   Copyright Statement..............................................35
   Acknowledgment...................................................35





Akhter, et al.         Expires January 18, 2007                [Page 2]


Internet-Draft      MPLS Benchmarking Methodology             July 2006


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.

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.

   An accompanying document titled 'Terminology for MPLS Benchmarking'
   defines many of the terms used in this document. The terminology
   should be consulted before attempting to make use of this document.

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.









Akhter, et al.         Expires January 18, 2007                [Page 3]


Internet-Draft      MPLS Benchmarking Methodology             July 2006


                    +-----------------+
    +---------+     |                 |     +---------+
    | 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



   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



Akhter, et al.         Expires January 18, 2007                [Page 4]


Internet-Draft      MPLS Benchmarking Methodology             July 2006


   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 are 64, 128, 256, 512,
   1024, 1280 and 1518.  Recommended sizes for other media can be found
   in RFC 2544.

   In addition to the individual frame size trials, an IMIX traffic run
   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
   holddown timer is 180 seconds) are being used.

   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.






Akhter, et al.         Expires January 18, 2007                [Page 5]


Internet-Draft      MPLS Benchmarking Methodology             July 2006


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 MPLS label presence or non-presence of the packet MUST
   be verified, as well as checksum, frame sequencing and correct TTL
   decrementing.

   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 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.



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
   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)






Akhter, et al.         Expires January 18, 2007                [Page 6]


Internet-Draft      MPLS Benchmarking Methodology             July 2006


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:



        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






Akhter, et al.         Expires January 18, 2007                [Page 7]


Internet-Draft      MPLS Benchmarking Methodology             July 2006


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. 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.

     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




Akhter, et al.         Expires January 18, 2007                [Page 8]


Internet-Draft      MPLS Benchmarking Methodology             July 2006


     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)



     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. Unidirectional Static Single Label Disposition Rate



   Objective

     To obtain the maximum label disposition rate for a regular (IPv4)
     packet by the DUT.




Akhter, et al.         Expires January 18, 2007                [Page 9]


Internet-Draft      MPLS Benchmarking Methodology             July 2006


   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
     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.


Akhter, et al.         Expires January 18, 2007               [Page 10]


Internet-Draft      MPLS Benchmarking Methodology             July 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 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. Unidirectional Static Single Label Swap Rate



   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.




Akhter, et al.         Expires January 18, 2007               [Page 11]


Internet-Draft      MPLS Benchmarking Methodology             July 2006


     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
     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.


Akhter, et al.         Expires January 18, 2007               [Page 12]


Internet-Draft      MPLS Benchmarking Methodology             July 2006






6.1.4. 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.



     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'.






Akhter, et al.         Expires January 18, 2007               [Page 13]


Internet-Draft      MPLS Benchmarking Methodology             July 2006


     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.



     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.



Akhter, et al.         Expires January 18, 2007               [Page 14]


Internet-Draft      MPLS Benchmarking Methodology             July 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.5. 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.

     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




Akhter, et al.         Expires January 18, 2007               [Page 15]


Internet-Draft      MPLS Benchmarking Methodology             July 2006


     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.

     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




Akhter, et al.         Expires January 18, 2007               [Page 16]


Internet-Draft      MPLS Benchmarking Methodology             July 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.6. 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.

     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





Akhter, et al.         Expires January 18, 2007               [Page 17]


Internet-Draft      MPLS Benchmarking Methodology             July 2006


     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.



   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.



Akhter, et al.         Expires January 18, 2007               [Page 18]


Internet-Draft      MPLS Benchmarking Methodology             July 2006




6.1.7. 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
     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 January 18, 2007               [Page 19]


Internet-Draft      MPLS Benchmarking Methodology             July 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.8. 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.




Akhter, et al.         Expires January 18, 2007               [Page 20]


Internet-Draft      MPLS Benchmarking Methodology             July 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.



   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)







Akhter, et al.         Expires January 18, 2007               [Page 21]


Internet-Draft      MPLS Benchmarking Methodology             July 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.9. 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.

     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.


Akhter, et al.         Expires January 18, 2007               [Page 22]


Internet-Draft      MPLS Benchmarking Methodology             July 2006


     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.







6.1.10. 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


Akhter, et al.         Expires January 18, 2007               [Page 23]


Internet-Draft      MPLS Benchmarking Methodology             July 2006




     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.



     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.


Akhter, et al.         Expires January 18, 2007               [Page 24]


Internet-Draft      MPLS Benchmarking Methodology             July 2006


     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)

     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. 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


Akhter, et al.         Expires January 18, 2007               [Page 25]


Internet-Draft      MPLS Benchmarking Methodology             July 2006


     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



   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.


Akhter, et al.         Expires January 18, 2007               [Page 26]


Internet-Draft      MPLS Benchmarking Methodology             July 2006


     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. 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

     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.




Akhter, et al.         Expires January 18, 2007               [Page 27]


Internet-Draft      MPLS Benchmarking Methodology             July 2006


   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.



     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. Unidirectional 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.




Akhter, et al.         Expires January 18, 2007               [Page 28]


Internet-Draft      MPLS Benchmarking Methodology             July 2006


   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
     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,



Akhter, et al.         Expires January 18, 2007               [Page 29]


Internet-Draft      MPLS Benchmarking Methodology             July 2006


     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



     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. Unidirectional MPLS Imposition Rate with IPv6 Extension Header

6.1.15. Unidirectional MPLS Imposition Rate with IPv4 Router Options



6.2. MPLS Forwarding - EXP Operations



6.2.1. Label Imposition Rate in IP-to-MPLS path for DSCP to EXP

6.2.2. Label Imposition Rate in MPLS-to-MPLS path for EXP

6.2.3. MPLS-to-IP path - Label Disposition - EXP










Akhter, et al.         Expires January 18, 2007               [Page 30]


Internet-Draft      MPLS Benchmarking Methodology             July 2006


6.3. MPLS Forwarding Delay Measurement

   This measures the time taken by the DUT to forward the MPLS packet
   during various MPLS switching paths such as IP-to-MPLS or MPLS-to-
   MPLS involving one or more labels.

   The forwarding delay measurement requires the accurate propagation
   delay measurement as prerequisite.

   One of the propagation delay measurement mechanisms is to connect two
   test ports such as A1 and B1 with the wire length=X (bypass DA1 and
   DB1) and measure the time (t1) taken by the packet to reach from A1
   to B1.

   Once the time t1 has been recorded, then the DUT should be inserted
   such that the test port A1 connects to DA1 and B1 connects to DB1,
   and the sum of A1-DA1 wire length and B1-DB1 wire length equals X.

   The packet should be sent from A1 to B1 such that the packet is
   received by DA1, which after consulting with its forwarding table,
   forwards the packet to B1 via DB1. The time (t2) taken by the packet
   to reach B1 (from A1) is recorded.

   The difference of time t2-t1 would provide the ballpark measurement
   of DUT's forwarding delay.

   The measurement for t2 could be performed under the following six
   cases and the forward delay could be measured accordingly.



6.3.1. Forwarding Delay in IP-to-MPLS path - Single Label Imposition

6.3.2. Forwarding Delay in IP-to-MPLS path - Multi Label Imposition

6.3.3. Forwarding Delay in MPLS-to-MPLS path - Single Label Swap

6.3.4. Forwarding Delay in MPLS-to-MPLS path - Multi Label Swap

6.3.5. Forwarding Delay in MPLS-to-IP path - Single Label disposition

6.3.6. Forwarding Delay in MPLS-to-IP path - Multi Label disposition







Akhter, et al.         Expires January 18, 2007               [Page 31]


Internet-Draft      MPLS Benchmarking Methodology             July 2006


6.4. MPLS Forwarding Negative Characterization

      The purpose of such characterization is to subject the DUT to
   various negative forwarding conditions and ensure that the DUT
   behaves appropriately (i.e. drops negative packets, processes them or
   punts them) without affecting the overall health of the LSR. Specific
   expected behaviors are elaborated under each sub-case.

   Additionally, any impact on the DUT's forwarding SHOULD be measured.



6.4.1. MPLS TTL Timeout

6.4.2. MPLS topmost label's EOS bit within a label stack

6.4.3. MPLS label stack's depth

6.4.4. MPLS packet received on a non-MPLS interface





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 January 18, 2007               [Page 32]


Internet-Draft      MPLS Benchmarking Methodology             July 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


   Mohamed Khalid
   Cisco Systems
   7025 Kit Creek Road
   RTP, NC 27709
   USA

   Phone: 919 392 3260
   Email: mkhalid@cisco.com











Akhter, et al.         Expires January 18, 2007               [Page 33]


Internet-Draft      MPLS Benchmarking Methodology             July 2006


   Rajiv Asati
   Cisco Systems
   7025 Kit Creek Road
   RTP, NC 27709
   USA

   Phone: 919 392 8558
   Email: rajiva@cisco.com




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.




Akhter, et al.         Expires January 18, 2007               [Page 34]


Internet-Draft      MPLS Benchmarking Methodology             July 2006


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

   Funding for the RFC Editor function is currently provided by the
   Internet Society.





































Akhter, et al.         Expires January 18, 2007               [Page 35]


Html markup produced by rfcmarkup 1.123, available from https://tools.ietf.org/tools/rfcmarkup/