diff options
Diffstat (limited to 'doc/rfc/rfc5695.txt')
| -rw-r--r-- | doc/rfc/rfc5695.txt | 1515 |
1 files changed, 1515 insertions, 0 deletions
diff --git a/doc/rfc/rfc5695.txt b/doc/rfc/rfc5695.txt new file mode 100644 index 0000000..a0bceb9 --- /dev/null +++ b/doc/rfc/rfc5695.txt @@ -0,0 +1,1515 @@ + + + + + + +Network Working Group A. Akhter +Request for Comments: 5695 R. Asati +Category: Informational C. Pignataro + Cisco Systems + November 2009 + + + MPLS Forwarding Benchmarking Methodology for IP Flows + +Abstract + + This document describes a methodology specific to the benchmarking + of Multiprotocol Label Switching (MPLS) forwarding devices, limited + to the most common MPLS packet forwarding scenarios and delay + measurements for each, considering IP flows. It builds upon the + tenets set forth in RFC 2544, RFC 1242, and other IETF Benchmarking + Methodology Working Group (BMWG) efforts. This document seeks to + extend these efforts to the MPLS paradigm. + +Status of This Memo + + This memo provides information for the Internet community. It does + not specify an Internet standard of any kind. Distribution of this + memo is unlimited. + +Copyright Notice + + Copyright (c) 2009 IETF Trust and the persons identified as the + document authors. All rights reserved. + + This document is subject to BCP 78 and the IETF Trust's Legal + Provisions Relating to IETF Documents + (http://trustee.ietf.org/license-info) in effect on the date of + publication of this document. Please review these documents + carefully, as they describe your rights and restrictions with respect + to this document. Code Components extracted from this document must + include Simplified BSD License text as described in Section 4.e of + the Trust Legal Provisions and are provided without warranty as + described in the BSD License. + + This document may contain material from IETF Documents or IETF + Contributions published or made publicly available before November + 10, 2008. The person(s) controlling the copyright in some of this + material may not have granted the IETF Trust the right to allow + modifications of such material outside the IETF Standards Process. + Without obtaining an adequate license from the person(s) controlling + the copyright in such materials, this document may not be modified + outside the IETF Standards Process, and derivative works of it may + + + +Akhter, et al. Informational [Page 1] + +RFC 5695 MPLS Benchmarking Methodology November 2009 + + + not be created outside the IETF Standards Process, except to format + it for publication as an RFC or to translate it into languages other + than English. + +Table of Contents + + 1. Introduction ....................................................2 + 2. Document Scope ..................................................3 + 3. Key Words To Reflect Requirements ...............................4 + 4. Test Methodology ................................................4 + 4.1. Test Considerations ........................................5 + 4.1.1. Abbreviations Used ..................................5 + 4.1.2. IGP Support .........................................6 + 4.1.3. Label Distribution Support ..........................6 + 4.1.4. Frame Formats .......................................7 + 4.1.5. Frame Sizes .........................................9 + 4.1.6. Time-to-Live (TTL) or Hop Limit ....................12 + 4.1.7. Trial Duration .....................................12 + 4.1.8. Traffic Verification ...............................12 + 4.1.9. Address Resolution and Dynamic Protocol State ......13 + 5. Reporting Format ...............................................13 + 6. MPLS Forwarding Benchmarking Tests .............................14 + 6.1. Throughput ................................................15 + 6.1.1. Throughput for MPLS Label Push .....................16 + 6.1.2. Throughput for MPLS Label Swap .....................17 + 6.1.3. Throughput for MPLS Label Pop (Unlabeled) ..........18 + 6.1.4. Throughput for MPLS Label Pop (Aggregate) ..........19 + 6.1.5. Throughput for MPLS Label Pop (PHP) ................20 + 6.2. Latency Measurement .......................................21 + 6.3. Frame-Loss Rate (FLR) Measurement .........................22 + 6.4. System Recovery ...........................................23 + 6.5. Reset .....................................................23 + 7. Security Considerations ........................................25 + 8. Acknowledgement ................................................25 + 9. References .....................................................25 + 9.1. Normative References ......................................25 + 9.2. Informative References ....................................26 + +1. Introduction + + Over the past several years, there has been an increase in the use of + MPLS as a forwarding architecture in new and existing network + designs. MPLS, defined in [RFC3031], is a foundation technology and + the basis for many advanced technologies such as Layer 3 MPLS VPNs, + Layer 2 MPLS VPNs, and MPLS Traffic Engineering. + + + + + + +Akhter, et al. Informational [Page 2] + +RFC 5695 MPLS Benchmarking Methodology November 2009 + + + However, there is no standard method defined to compare and contrast + the foundational MPLS packet forwarding capabilities of network + devices. This document proposes a methodology using common criteria + (such as throughput, latency, frame-loss rate, system recovery, + reset, etc.) to evaluate MPLS forwarding of any implementation. + +2. Document Scope + + The benchmarking methodology principles outlined in RFC 2544 + [RFC2544] are independent of forwarding techniques; however, they + don't fully address MPLS benchmarking. The workload on network + forwarding device resources that MPLS forwarding places is different + from that of IP forwarding; therefore, MPLS forwarding benchmarking + specifics are desired. + + The purpose of this document is to describe a methodology specific to + the benchmarking of MPLS forwarding devices. The methods described + are limited in scope to the most common MPLS packet forwarding + scenarios and corresponding performance measurements in a laboratory + setting. It builds upon the tenets set forth in RFC 2544 [RFC2544], + RFC 1242 [RFC1242], and other IETF Benchmarking Methodology Working + Group (BMWG) efforts. In other words, this document is not a + replacement for, but a complement to, RFC 2544. + + This document focuses on the MPLS label stack [RFC3032] that has only + one entry, as it is the fundamental of MPLS forwarding. It is + expected that future documents may cover the benchmarking of MPLS + applications such as Layer 3 VPN (L3VPN) [RFC4364], Layer 2 VPN + (L2VPN) [RFC4664], Fast ReRoute [RFC4090], etc., which require more + than one entry in the MPLS label stack. + + Moreover, to address the majority of current deployments' needs, this + document focuses on having IP packets as the MPLS payload. In other + words, label distribution for IP Forwarding Equivalence Class (FEC) + [RFC3031] is prescribed (see Section 4.1.3) by this document. It is + expected that future documents may focus on having non-IP packets as + the MPLS payload. + + Note that the presence of an MPLS label stack does not require the + length of MPLS payload (which is an IP packet, per this document) to + be changed; hence, the effective maximum size of a frame can increase + by Z octets (where Z = 4 x number of label stack entries), as + observed in current deployments. This document focuses on + benchmarking such a scenario. + + + + + + + +Akhter, et al. Informational [Page 3] + +RFC 5695 MPLS Benchmarking Methodology November 2009 + + +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 + [RFC2119]. 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 Methodology + + The set of methodologies described in this document will use the + topology described in this section. An effort has been made to + exclude superfluous equipment needs such that each test can be + carried out with a minimal number of devices. Figure 1 illustrates + the sample topology in which the Device Under Test (DUT) is connected + to the test ports on the test tool in accord with Figure 1 of RFC + 2544. + + +-----------------+ + +---------+ | | +---------+ + | Test | | | | Test | + | Port A1 +-----+ DA1 DB1 +-----+ Port B1 | + +---------+ | | +---------+ + +---------+ | DUT | +---------+ + | Test | | | | Test | + | Port A2 +-----+ DA2 DB2 +-----+ Port B2 | + +---------+ | | +---------+ + ... | ... ... | ... + +---------+ | | +---------+ + | Test | | | | Test | + | Port Ap +-----+ DAp DBp +-----+ Port Bp | + +---------+ +-----------------+ +---------+ + + Figure 1: Topology for MPLS Forwarding Benchmarking + + A represents a Tx-side Module of the test tool, whereas B represents + an Rx-side Module of the same test tool. Of course, the suffixed + numbers (1, 2, ..., p) represent ports on a Module. + + Similarly, DA represents an Rx-side Module of the DUT, whereas DB + represents a Tx-side Module. The suffixed numbers (1, 2, ..., p) + represent ports on a Module. + + + + + + + +Akhter, et al. Informational [Page 4] + +RFC 5695 MPLS Benchmarking Methodology November 2009 + + + p = the number of {DA, DB} pair ports on the DUT. It is determined + by the maximum unidirectional forwarding throughput of the DUT and + the load capacity of the port media (e.g., interface) connecting the + DUT to the test tool. + + For example, if the DUT's maximum forwarding throughput is 100 frames + per second (fps) and the load capacity of the port media (e.g., + interface) is 50 fps, then p >= 2 is needed to sufficiently test the + maximum frame forwarding. + + The exact throughput is a measured quantity obtained through testing. + Throughput may vary depending on the number of ports used and other + factors. The number of ports (p) used SHOULD be reported. Please + see "Test Setup" in Section 6. Following Figure 1 from Section 6 of + RFC 2544 is recommended. + +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. Traffic affecting features such + as Flow control, Quality of Service (QoS), Graceful Restart, etc. + MUST be disabled, unless explicitly requested in the test case. + Additionally, any non-essential traffic MUST also be avoided. + +4.1.1. Abbreviations Used + + The terms used in this document remain consistent with those defined + in "Benchmarking Terminology for Network Interconnect Devices" RFC + 1242 [RFC1242]. This terminology SHOULD be consulted before using or + applying the recommendations of this document. + + Please refer to Figure 1 for a topology view of the network. The + following abbreviations are used in this document: + + M := Module on a device (i.e., Line-Card or Slot; could be A or B) + + p := Port number (i.e., port on the Module; could be 1, 2, etc.) + + RN := Remote Network (i.e., network that is reachable via a port of a + module; could be B1RN1 or B2RN5 to mean the first network reachable + via port 1 of module B, e.g., B1, or the fifth network reachable via + port 2 of module B, etc.). RN is considered to be the IP Prefix FEC + from the MPLS perspective. + + + + + + +Akhter, et al. Informational [Page 5] + +RFC 5695 MPLS Benchmarking Methodology November 2009 + + +4.1.2. IGP Support + + It is RECOMMENDED that all of the ports (A1, DA1, DB1, and A2) on the + DUT and test tool support a dynamic Interior Gateway Protocol (IGP) + for routing such as IS-IS, OSPF, RIP, etc. Furthermore, there are + testing considerations in this document that the device be able to + provide a stable control plane during heavy forwarding workloads. In + particular, the procedures defined in Section 11.3 of RFC 2544 must + be followed. This is to ensure that control plane instability during + load conditions is not the contributing factor towards frame + forwarding performance. + + The route distribution method (OSPF, IS-IS, Enhanced Interior Gateway + Routing Protocol (EIGRP), RIP, Static, etc.), if used, MUST be + reported. Furthermore, if any specific configuration is used to + maintain control plane stability during the test (i.e., Control Plane + Protection, Control Plane Rate Limiting, etc.), then it MUST also be + reported. + +4.1.3. Label Distribution Support + + The DUT and test tool must support at least one protocol for + exchanging MPLS label/FEC bindings for Prefix Forwarding Equivalence + Class (FEC) [RFC3031]. The DUT and test tool MUST be capable of + learning and advertising MPLS label/FEC bindings via the chosen + protocol(s) and use them during packet forwarding all the time + (including when the label/FEC bindings change). The most commonly + used protocols are Label Distribution Protocol (LDP) [RFC5036], + Resource Reservation Protocol-Traffic Engineering (RSVP-TE) + [RFC3209], and Border Gateway Protocol (BGP) [RFC3107]. + + All of the ports (A1, DA1, DB1, B1, etc.) either on the DUT or the + test tool used in the testing SHOULD support LDP, RSVP-TE, and BGP + for IPv4 or IPv6 Prefix Forwarding Equivalence Classes (FECs). + + Static labels SHOULD NOT be used to establish the MPLS label switched + paths (LSPs), unless specified explicitly by the test case. + + This is because the use of a static label is quite uncommon in the + production networks. + + The IPv4 and IPv6 Explicit NULL labels (label values 0 and 2) are + sometimes used to identify the payload of an MPLS packet on an LSP + [RFC3032]. Explicit NULL labels are not used in the tests described + in this document because the tests are limited to the use of no more + than one non-reserved MPLS label in the label stack of all packets + to, from, or through the DUT. + + + + +Akhter, et al. Informational [Page 6] + +RFC 5695 MPLS Benchmarking Methodology November 2009 + + +4.1.4. Frame Formats + + This section explains the frame formats for IP and MPLS packets + (Section 4.1.4.1), the usage of IP as the mandatory Layer 3 protocol + and as the MPLS packet payload (Section 4.1.4.2), change in frame + format during forwarding (Section 4.1.4.3), and recommended frame + formats for the MPLS benchmarking (Section 4.1.4.4). + +4.1.4.1. Frame Format for IP versus MPLS + + A test frame carrying an IP packet is illustrated in Figure 2 below. + Note that RFC 2544 [RFC2544] prescribes using such a frame as the + test frame over the chosen Layer 2 media. + + +---------+--------------+-----------------------+ + | Layer 2 | Layer 3 = IP | Layer 4 = UDP | + +---------+--------------+-----------------------+ + + Figure 2: Frame Format for IP Packets + + Unlike a test frame carrying an IP packet, a test frame carrying an + MPLS packet contains an "MPLS label stack" [RFC3032] immediately + after the Layer 2 header (and before the IP header, if any) as + illustrated in Figure 3 below. + + +---------+-------+--------------+-----------------------+ + | Layer 2 | MPLS | Layer 3 = IP | Layer 4 = UDP | + +---------+-------+--------------+-----------------------+ + + Figure 3: Frame Format for MPLS Packets + + The MPLS label stack is represented as a sequence of "label stack + entries", where each label stack entry is 4 octets, as illustrated in + Figure 1 of [RFC3032]. This document requires exactly one entry in + the MPLS label stack in an MPLS packet. + + MPLS label values used in any test case MUST be outside the reserved + label value (0-15) unless stated otherwise. + +4.1.4.2. MPLS Packet Payload + + This document prescribes using an IP packet as the MPLS payload (as + illustrated in Figure 3 above). Generically speaking, this document + mandates the test frame to include IP (either IPv4 or IPv6) as the + Layer 3 protocol, in accord with Section 8 of [RFC2544] and + independent of the MPLS label stack presence, for three reasons: + + + + + +Akhter, et al. Informational [Page 7] + +RFC 5695 MPLS Benchmarking Methodology November 2009 + + + 1. This enables using IP Prefix Forwarding Equivalence Class (FEC) + [RFC3031], which is a must for every MPLS network. + + 2. This provides the foundation or baseline for the benchmarking of + various other MPLS applications such as L3VPN, L2VPN, TE-FRR, etc. + + 3. This enables leveraging RFC 2544 [RFC2544], which prescribes using + IP packets with UDP data as the test frames. (Note that [RFC5180] + also uses this prescription for IPv6 benchmarking). + + While the usage of non-IP payloads is possible, it requires an MPLS + application, e.g., L2VPN, whose benchmarking may be covered in + separate BMWG documents (MPLS L2VPN Benchmarking, for example) in the + future. This is also explained in Section 2. + +4.1.4.3. Change in Frame Format Due to MPLS Push and Pop + + A frame carrying an IP or MPLS packet may go through any of the three + MPLS forwarding operations: label push (or LSP Ingress), label swap, + and label pop (or LSP Egress), as defined in [RFC3031]. It is + important to understand the change of the frame format from IP to + MPLS or vice versa depending on the forwarding operation. + + In a label push (or LSP Ingress) operation, the DUT receives a frame + containing an IP packet and forwards a frame containing an MPLS + packet if the corresponding forwarding lookup for the IP destination + points to a label push operation. + + In a label swap operation, the DUT receives a frame containing an + MPLS packet and forwards a frame containing an MPLS packet if the + corresponding forwarding lookup for the label value points to a label + swap operation. + + In a label pop (or LSP Egress) operation, the DUT receives a frame + containing an MPLS packet and forwards a frame containing an IP + packet if the corresponding forwarding lookup for the label value + points to a label pop operation. + +4.1.4.4. Frame Formats to Be Used for Benchmarking + + This document prescribes using two test frame formats to + appropriately test the forwarding operations: (1) Frame format for IP + and (2) Frame format for MPLS. Both formats are explained in Section + 4.1.4.1. Additionally, the format of the test frame may change + depending on the forwarding operation. + + + + + + +Akhter, et al. Informational [Page 8] + +RFC 5695 MPLS Benchmarking Methodology November 2009 + + + 1. For test cases involving the label push operation, the test tool + must use the frame format for IP packets (Figure 2) to send the + test frames to the DUT, and must use the frame format for MPLS + packets (Figure 3) to receive the test frames from the DUT. + + 2. For test cases involving the label swap operation, the test tool + must use the frame format for MPLS packets (Figure 3) to send the + test frames to the DUT, and must use the frame format for MPLS + packets (Figure 3) to receive the test frames from the DUT. + + 3. For test cases involving the label pop operation, the test tool + must use the frame format for MPLS packets (Figure 3) to send the + test frames to the DUT, and must use the frame format for IP + packets (Figure 2) to receive the test frames from the DUT. + +4.1.5. Frame Sizes + + Two types of port media are commonly deployed: Ethernet and POS + (Packet Over Synchronous Optical Network). This section identifies + the frame sizes that SHOULD be used for each media type, if supported + by the DUT; Section 4.1.5.1 covers Ethernet and Section 4.1.5.2 + covers POS. + + First, it is important to note the possible increase in frame size + due to the presence of an MPLS label stack in the frame (as explained + in Section 4.1.4.3). + + As observed in the current deployments, presence of an MPLS label + stack in a Layer 2 frame is assumed to be transparent to Layer3=IP, + which continues to follow the conventional maximum frame payload size + [RFC3032] (1500 octets for Ethernet, say). This means that the + effective maximum frame payload size [RFC3032] of the resulting Layer + 2 frame is Z octets more than the conventional maximum frame payload + size, where Z = 4 x number of entries in the label stack. + + Hence, to ensure successful delivery of Layer 2 frames carrying MPLS + packets and realistic benchmarking, it is RECOMMENDED to set the + media MTU value to the effective maximum frame payload size + [RFC3032], which equals Z octets + conventional maximum frame payload + size. It is expected that such a change in the media MTU value only + impacts the effective Maximum Frame Payload Size for MPLS packets, + but not for IP packets. + + Note that this document requires exactly a single entry in the MPLS + label stack in an MPLS packet. In other words, the depth of the + label stack is set to one, e.g., Z = 4 x 1 = 4 octets. Furthermore, + in accord with Sections 9 and 9.1 of RFC 2544, this document + prescribes that each test case is run with different (Layer 2) frame + + + +Akhter, et al. Informational [Page 9] + +RFC 5695 MPLS Benchmarking Methodology November 2009 + + + sizes in different trials. Additionally, results MAY also be + collected with multiple simultaneous frame sizes (sometimes referred + to as an Interactive Multimodal Information Extraction (IMIX) to + simulate real network traffic according to the frame size ordering + and usage). There is no standard for mixtures of frame sizes, and + the results are subject to wide interpretation (see Section 18 of RFC + 2544). When running trials using multiple simultaneous frame sizes, + the DUT configuration MUST remain the same. + +4.1.5.1. Frame Sizes To Be Used on Ethernet Media + + Ethernet media, in all its types, has become the most commonly + deployed port media in MPLS networks. If any test case execution + (such as the Label Push case) requires the test tool to send (or + receive) a Layer 2 frame containing an IP packet, then the following + frame sizes SHOULD be used for benchmarking over Ethernet media: 64, + 128, 256, 512, 1024, 1280, and 1518 octets. This is in-line with + Sections 9 and 9.1 of RFC 2544. Figure 4 illustrates the header + sizes for an untagged Ethernet frame containing an IP payload (per + RFC 2544). + + <----------------64-1518B------------------------> + <--18B---><-----------46-1500B-------------------> + +---------+---------+----------------------------+ + | Layer 2 | Layer 3 | Layer 4 (and higher) | + +---------+---------+----------------------------+ + + Figure 4: Frame Size for Label Push Cases + + Note 1: The 64- and 1518-octet frame size represents the minimum + and maximum length of an untagged Ethernet frame, as per IEEE + 802.3 [IEE8023]. A frame size commonly used in operational + environments may range from 68 to 1522 octets, which are the + minimum and maximum lengths of a single VLAN-tagged frame, as per + IEEE 802.1D [IEE8021]. + + Note 2: While jumbo frames are outside the scope of the 802.3 IEEE + standard, tests SHOULD be executed with the frame sizes that are + supported by the DUT. Examples of commonly used jumbo (Ethernet) + frame sizes are: 4096, 8192, and 9216 octets. + + If any test case execution (such as Label Swap and Label Pop cases) + requires the test tool to transmit (or receive) a Layer 2 frame + containing an MPLS packet, then the untagged Layer 2 frame must + + + + + + + +Akhter, et al. Informational [Page 10] + +RFC 5695 MPLS Benchmarking Methodology November 2009 + + + include an additional 4 octets for the MPLS header, resulting in the + following frame sizes to be used for benchmarking over Ethernet + media: 68, 132, 260, 516, 1028, 1284, and 1522 octets. Figure 5 + illustrates the header sizes for an untagged Ethernet frame + containing an MPLS packet. + + <------------------68-1522B------------------------------> + <--18B---><--4B--><-----------46-1500B-------------------> + +---------+-------+---------+----------------------------+ + | Layer 2 | MPLS | Layer 3 | Layer 4 (and higher) | + +---------+-------+---------+----------------------------+ + + Figure 5: Frame Size for Label Swap and Pop Cases + + Note: The Media MTU on the link between the test tool and the DUT + must be changed, if needed, to accommodate the effective maximum + frame payload size [RFC3032] resulting from adding an MPLS label + stack to the IP packet. As clarified in Section 3.1 of RFC 3032, + most Layer 2 media drivers are capable of sending and receiving + Layer 2 frames with effective maximum frame payload size. Many + vendors also allow the Media MTU to be changed for MPLS, without + changing it for IP. The recommended link MTU value for MPLS is Z + octets more than the conventional maximum frame payload size + [RFC3032] (for example, the conventional maximum frame payload + size for Ethernet is 1500 octets). This document prescribes Z=4 + octets. If a vendor DUT doesn't allow such an MTU change, then + the benchmarking cannot be performed for the true maximum frame + payload size [RFC3032] and this must be reported. + +4.1.5.2. Frame Sizes to Be Used on POS Media + + Packet over SONET (POS) media are commonly used for edge uplinks and + high-bandwidth core links. POS may use one of various encapsulations + techniques (such as PPP, High-Level Data Link Control (HDLC), Frame + Relay, etc.), resulting in the Layer 2 header (~4 octets) being less + than that of the Ethernet media. The rest of the frame format + (illustrated in Figures 2 and 3) remains pretty much unchanged. + + If the MPLS forwarding characterization of POS interfaces on the DUT + is desired, then the following frame sizes SHOULD be used: + + Label Push test cases: 47, 64, 128, 256, 512, 1024, + 1280, 1518, 2048, and 4096 octets. + + Label Swap and Pop test cases: 51, 68, 132, 260, 516, 1028, + 1284, 1522, 2052, and 4100 octets. + + + + + +Akhter, et al. Informational [Page 11] + +RFC 5695 MPLS Benchmarking Methodology November 2009 + + +4.1.6. Time-to-Live (TTL) or Hop Limit + + The TTL value in the frame header MUST be large enough to allow a TTL + decrement to happen and still be forwarded through the DUT. The + aforementioned TTL field may be referring to either the MPLS TTL, + IPv4 TTL, or IPv6 Hop Limit depending on the exact forwarding + scenario under evaluation. + + If TTL/Hop Limit decrement, as specified in [RFC3443], is a + configurable option on the DUT, the setting SHOULD be reported. + +4.1.7. 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 + holddown timer is 180 seconds) are being used. If the holddown timer + default value is changed, then it should be reported and the trial + duration should still be 20 seconds more than the holddown timer + value. + + The longer trial time used for dynamic routing protocols is to verify + that the DUT is able to maintain a stable control plane when the + data-forwarding plane is under stress. + +4.1.8. Traffic Verification + + In all cases, sent traffic MUST be accounted for, whether it was + received on the wrong port, the correct port, or not received at all. + Specifically, traffic loss (also referred to as frame loss) is + defined as the traffic (i.e., one or more frames) not received where + expected (i.e., received on the incorrect port, or received with + incorrect Layer 2 or above header information, etc.). In addition, + the presence or absence of the MPLS label stack, every field value + inside the label stack, if present, ethertype (0x8847 or 0x8848 + versus 0x0800 or 0x86DD), frame sequencing, and frame check sequence + (FCS) MUST be verified in the received frame. + + Many test tools may, by default, only verify that they have received + the embedded signature on the receive side. However, for MPLS header + presence verification, some tests will require the MPLS header to be + pushed while others will require a swap or pop. Hence, this document + requires the test tool to verify the MPLS stack depth. An even + greater level of verification would be to check if the correct label + was pushed. However, some test tools are not capable of checking the + received label value for correctness. Test tools SHOULD verify that + the packets received carry the expected MPLS label. + + + + +Akhter, et al. Informational [Page 12] + +RFC 5695 MPLS Benchmarking Methodology November 2009 + + +4.1.9. Address Resolution and Dynamic Protocol State + + If a test setup utilizes any dynamic protocols for control plane + signaling (e.g., ARP, PPP (including MPLSCP), OSPF, LDP, etc.), then + all state for the protocols MUST be pre-established before the test + case is executed (i.e., packet streams are started). + +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 Units or Examples + + Prefix Forwarding Equivalence IPv4, IPv6, Both + Class (FEC) + + Label Distribution Protocol LDP, RSVP-TE, BGP (or + combinations) + + MPLS Forwarding Operation Push, Swap, Pop + + IGP ISIS, OSPF, EIGRP, RIP, + static. + + Throughput Frames per second and + bits per second + + Port Media GigE (Gigabit Ethernet), + POS, ATM, etc. + + Port Speed 1 gbps, 100 Mbps, etc. + + Interface Encapsulation Ethernet, Ethernet + VLAN, PPP, HDLC, etc. + + Frame Size (Section 4.1.5) Octets + + p (Number of {DA, DB} pair 1,2, etc. + ports per Figure 1) + + The individual test cases may have additional reporting requirements + that may refer to other RFCs. + + + + + + + +Akhter, et al. Informational [Page 13] + +RFC 5695 MPLS Benchmarking Methodology November 2009 + + +6. MPLS Forwarding Benchmarking Tests + + MPLS is a different forwarding paradigm from IP. Unlike IP packets + and IP forwarding, an MPLS packet may contain more than one MPLS + header and may go through one of three forwarding operations: push + (or LSP Ingress), swap, or pop (or LSP Egress), as defined in + [RFC3031]. Such characteristics desire further granularity in MPLS + forwarding benchmarking than those described in RFC 2544. Thus, the + benchmarking may include, but is not limited to: + + 1. Throughput + + 2. Latency + + 3. Frame-Loss Rate + + 4. System Recovery + + 5. Reset + + 6. MPLS TC (previously known as EXP [RFC5462]) field Operations + (including explicit-null cases) + + 7. Negative Scenarios (TTL expiry, etc.) + + 8. Multicast + + However, this document focuses only on the first five categories, + inline with the spirit of RFC 2544. All the benchmarking test cases + described in this document are expected to, at a minimum, follow the + "Test Setup" and "Test Procedure" below: + + Test Setup + + Referring to Figure 1, a single port (p = 1) on both A and B + Modules SHOULD be used. However, if the forwarding throughput of + the DUT is more than that of the media rate of a single port, then + additional ports on A and B Modules MUST be enabled as follows: if + the DUT can be configured with the A and B ports so as to exceed + the DUT's forwarding throughput without overloading any B ports, + then those MUST be enabled; if, on the other hand, the DUT's + forwarding throughput capacity is greater than what can be + achieved enabling all ports, then all An and Bn ports MUST be + enabled. In the case where more than one A and B port is enabled, + the procedures described in Section 16 of RFC 2544 must be + + + + + + +Akhter, et al. Informational [Page 14] + +RFC 5695 MPLS Benchmarking Methodology November 2009 + + + followed to accommodate the multi-port scenario. The frame + formats transmitted and received must be in accord with Sections + 4.1.4.3 and 4.1.4.4, and frame sizes must be in accord with + Section 4.1.5. + + Note: The test tool must be configured not to advertise a prefix + or FEC to the DUT on more than one port. In other words, the DUT + must associate a FEC with one and only one DB port. The Equal + Cost Multi-Path (ECMP) behavior in MPLS networks uses heuristics + [RFC4928]; hence, the usage of ECMP is NOT permitted by this + document to ensure the deterministic forwarding behavior during + benchmarking. + + Test Procedure + + In accord with Section 26 of RFC 2544 [RFC2544], the traffic is + sent from test tool port(s) Ap to the DUT at a constant load for a + fixed-time interval, and is received from the DUT on test tool + port(s) Bp. As described in Section 4.1.4.3, the frame may + contain either an IP packet or an MPLS packet depending on the + test case need. Furthermore, the IP packet must be either an IPv4 + or IPv6 packet, depending on whether the MPLS benchmarking is done + for IPv4 or IPv6. + + If any frame loss is detected, then a new iteration is needed + where 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. + + This maximum offered frame rate that results in zero frame loss + through the DUT is defined as the Throughput in Section 3.17 of + [RFC1242] for that test case. Informally, this rate is referred + to as the No-Drop Rate (NDR). + + Each iteration should involve varying the offered load of the + traffic, while keeping the other parameters (test duration, number + of ports, number of addresses, frame size, etc.) constant, until + the maximum rate at which none of the offered frames are dropped + is determined. + +6.1. Throughput + + This section contains the description of the tests that are related + to the characterization of a DUT's MPLS traffic forwarding. + + + + + + + +Akhter, et al. Informational [Page 15] + +RFC 5695 MPLS Benchmarking Methodology November 2009 + + +6.1.1. Throughput for MPLS Label Push + + Objective + + To obtain the DUT's Throughput (as per RFC 2544) during label push + or LSP Ingress forwarding operation (i.e., IP to MPLS). + + Test Setup + + In addition to the "Test Setup" described in Section 6, the test + tool must advertise the IP prefix(es), i.e., RNx (using a routing + protocol as per Section 4.1.2) and associated MPLS label-FEC + binding(s) (using a label distribution protocol as per Section + 4.1.3) on its receive ports Bp to the DUT. The test tool may + learn the IP prefix(es) on its transmit ports Ap from the DUT. + + MPLS and/or the label distribution protocol must be enabled only + on the test tool receive ports Bp and DUT transmit ports DBp. + + Discussion + + The DUT's MPLS forwarding table (also referred to as Incoming + Label Map (ILM) to Next Hop Label Forwarding Entry (NHLFE) mapping + table per Section 3.11 of [RFC3031]) must contain a non-reserved + MPLS label value as the outgoing label for each learned IP prefix + corresponding to the label-FEC binding, resulting in the DUT + performing the IP-to-MPLS forwarding operation. The test tool + must receive MPLS packets on receive ports Bp (from the DUT) with + the same label values that were advertised. + + Procedure + + Please see "Test Procedure" in Section 6. Additionally, the test + tool MUST send the frames containing IP packets (with the IP + destination belonging to the advertised IP prefix(es)) on transmit + ports Ap, and expect to receive frames containing MPLS packets on + receive ports Bp, as described in Section 4.1.4.4. + + Reporting Format + + The result should be reported as per Section 5 and RFC 2544. + + 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. Informational [Page 16] + +RFC 5695 MPLS Benchmarking Methodology November 2009 + + +6.1.2. Throughput for MPLS Label Swap + + Objective + + To obtain the DUT's Throughput (as per RFC 2544) during label + swapping operation (i.e., MPLS-to-MPLS). + + Test Setup + + In addition to the setup described in Section 6, the test tool + must advertise IP prefix(es) (using a routing protocol as per + Section 4.1.2) and associated MPLS label-FEC bindings (using a + label distribution protocol as per Section 4.1.3) on the receive + ports Bp, and then learn the IP prefix(es) as well as the label- + FEC binding(s) on the transmit ports Ap. The test tool must use + the learned MPLS label values and learned IP prefix values in the + frames transmitted on ports Ap to the DUT. + + MPLS and/or label distribution protocol must be enabled on the + test tool ports Bp and Ap, and the DUT ports DBp and DAp. + + Discussion + + The DUT's MPLS forwarding table (also referred to as ILM to NHLFE + mapping table per Section 3.11 of [RFC3031]) must contain non- + reserved MPLS label values as the outgoing and incoming labels for + the learned IP prefixes, resulting in an MPLS-to-MPLS forwarding + operation, e.g., label swap. The test tool must receive MPLS + packets on receive ports Bp (from the DUT) with the same label + values that were advertised using the label distribution protocol. + The received frames must contain the same number of MPLS headers + as those of transmitted frames. + + Procedure + + Please see "Test Procedure" in Section 6. Additionally, the test + tool must send frames containing MPLS packets (with the IP + destination belonging to the advertised IP prefix(es)) on its + transmit ports Ap, and expect to receive frames containing MPLS + packets on its receive ports Bp, as described in Section 4.1.4.4. + + Reporting Format + + The result should be reported as per Section 5 and RFC 2544. + + Results for each test SHOULD be in the form of a table with a row + for each of the tested frame sizes. + + + + +Akhter, et al. Informational [Page 17] + +RFC 5695 MPLS Benchmarking Methodology November 2009 + + +6.1.3. Throughput for MPLS Label Pop (Unlabeled) + + Objective + + To obtain the DUT's Throughput (as per RFC 2544) during label pop + or LSP Egress forwarding operation (i.e., MPLS-to-IP) using + "Unlabeled" outgoing label. + + Test Setup + + In addition to the setup described in Section 6, the test tool + must advertise the IP prefix(es) (using a routing protocol as per + Section 4.1.2) without any MPLS label-FEC bindings on the receive + ports Bp, and then learn the IP prefix(es) as well as the FEC- + label binding(s) on the transmit ports Ap. The test tool must use + the learned MPLS label values and learned IP prefix values in the + frames transmitted on ports Ap. + + MPLS and/or label distribution protocol must be enabled only on + the test tool port(s) Ap and DUT port(s) DAp. + + Discussion + + The DUT's MPLS forwarding table (also referred to as ILM to NHLFE + mapping table per Section 3.11 of [RFC3031]) must contain an + Unlabeled outgoing label (also known as untagged) for the learned + IP prefix, resulting in an MPLS-to-IP forwarding operation. + + Procedure + + Please see "Test Procedure" in Section 6. Additionally, the test + tool must send frames containing MPLS packets on its transmit + ports Ap (with the IP destination belonging to the IP prefix(es) + advertised on port Bp), and expect to receive frames containing IP + packets on its receive ports Bp, as described in Section 4.1.4.4. + + Reporting Format + + The result should be reported as per Section 5 and RFC 2544. + + Results for each test SHOULD be in the form of a table with a row + for each of the tested frame sizes. + + + + + + + + + +Akhter, et al. Informational [Page 18] + +RFC 5695 MPLS Benchmarking Methodology November 2009 + + +6.1.4. Throughput for MPLS Label Pop (Aggregate) + + Objective + + To obtain the DUT's Throughput (as per RFC 2544) during label pop + or LSP Egress forwarding operation (i.e., MPLS-to-IP) using the + "Aggregate" outgoing label [RFC3031]. + + Test Setup + + In addition to the setup described in Section 6, the DUT must be + provisioned such that it allocates an aggregate outgoing label + (please see Section 3.20 in [RFC3031]) to an IP prefix, which + aggregates a set of prefixes learned on ports DBp from the test + tool. The prefix aggregation can be performed using BGP + aggregation (Section 9.2.2.2 of [RFC4271]), IGP aggregation + (Section 16.5 of [RFC2328]), etc. + + The DUT must advertise the aggregating IP prefix along with the + associated MPLS label-FEC binding on ports DAp to the test tool. + + The test tool then must use the learned MPLS label values and + learned IP prefix values in frames transmitted on ports Ap to the + DUT. The test tool must receive frames containing IP packets on + ports Bp from the DUT. + + MPLS and/or label distribution protocol must be enabled only on + the test tool port(s) Ap and DUT port(s) DAp. + + Discussion + + The DUT's MPLS forwarding table (also referred to as ILM to NHLFE + mapping table per Section 3.11 of [RFC3031]) must contain an + aggregate outgoing label and IP forwarding table must contain a + valid entry for the learned prefix(es), resulting in MPLS-to-IP + forwarding operation (i.e., MPLS header removal followed by IP + lookup). + + Procedure + + Please see "Test Procedure" in Section 6. Additionally, the test + tool must send frames containing MPLS packets on its transmit + ports Ap (with IP destination belonging to the IP prefix(es) + advertised on port Bp), and expect to receive frames containing IP + packets on its receive ports Bp, as described in Section 4.1.4.4. + + + + + + +Akhter, et al. Informational [Page 19] + +RFC 5695 MPLS Benchmarking Methodology November 2009 + + + Reporting Format + + The result should be reported as per Section 5 and RFC 2544. + + Results for each test SHOULD be in the form of a table with a row + for each of the tested frame sizes. + +6.1.5. Throughput for MPLS Label Pop (PHP) + + Objective + + To obtain the DUT's Throughput (as per RFC 2544) during label pop + (i.e., MPLS-to-IP) or penultimate hop popping (PHP) using the + "imp-null" outgoing label. + + Test Setup + + In addition to the setup described in Section 6, the test tool + must be set up to advertise the IP prefix(es) (using a routing + protocol as per Section 4.1.2) and associated MPLS label-FEC + binding with a reserved MPLS label value = 3 (using a label + distribution protocol as per Section 4.1.3) on its receive ports + Bp. The test tool must learn the IP prefix(es) as well as the + MPLS label-FEC bindings on its transmit ports Ap. The test tool + then must use the learned MPLS label values and learned IP prefix + values in the frames transmitted on ports Ap to the DUT. The test + tool must receive frames containing IP packets on receive ports Bp + (from the DUT). + + MPLS and/or label distribution protocol must be enabled on the + test tool ports Bp and Ap, and DUT ports DBp and DAp. + + Discussion + + This test case characterizes Penultimate Hop Popping (PHP), which + is described in RFC 3031. + + The DUT's MPLS forwarding table (also referred to as ILM to NHLFE + mapping table per Section 3.11 of [RFC3031]) must contain a + reserved MPLS label value = 3 (e.g., pop or imp-null) as the + outgoing label for the learned prefix(es), resulting in MPLS-to-IP + forwarding operation. + + This test case characterizes DUT's penultimate hop popping (PHP) + functionality. + + + + + + +Akhter, et al. Informational [Page 20] + +RFC 5695 MPLS Benchmarking Methodology November 2009 + + + Procedure + + Please see "Test Procedure" in Section 6. Additionally, the test + tool must send frames containing MPLS packets on its transmit + ports Ap (with IP destination belonging to advertised IP + prefix(es)), and expect to receive frames containing IP packets on + its receive ports Bp, as described in Section 4.1.4.4. + + Reporting Format + + The result should be reported as per Section 5 and RFC 2544. + + Results for each test SHOULD be in the form of a table with a row + for each of the tested frame sizes. + +6.2. Latency Measurement + + Latency measurement measures the time taken by the DUT to forward the + MPLS packet during various MPLS switching paths such as IP-to-MPLS, + MPLS-to-MPLS, or MPLS-to-IP involving an MPLS label stack. + + Objective + + To obtain the average latency induced by the DUT during MPLS + packet forwarding for each of five forwarding operations. + + Test Setup + + Follow the "Test Setup" guidelines established for each of the + five MPLS forwarding operations in Sections 6.1.1 (for IP-to- + MPLS), 6.1.2 (for MPLS-to-MPLS), 6.1.3 (for MPLS-to-IP Unlabeled), + 6.1.4 (for MPLS-to-IP Aggregate), and 6.1.5 (for MPLS-to-IP PHP), + one by one. + + Procedure + + Please refer to Section 26.2 in RFC 2544 in addition to following + the associated procedure for each MPLS forwarding operation in + accord with the test setup described earlier: + + IP-to-MPLS forwarding (Push) Section 6.1.1 + MPLS-to-MPLS forwarding (Swap) Section 6.1.2 + MPLS-to-IP forwarding (Pop) Section 6.1.3 + MPLS-to-IP forwarding (Aggregate) Section 6.1.4 + MPLS-to-IP forwarding (PHP) Section 6.1.5 + + + + + + +Akhter, et al. Informational [Page 21] + +RFC 5695 MPLS Benchmarking Methodology November 2009 + + + Reporting Format + + The result should be reported as per Section 5 and RFC 2544. + +6.3. Frame-Loss Rate (FLR) Measurement + + Frame-Loss Rate (FLR) measurement measures the percentage of MPLS + frames that were not forwarded during various switching paths such as + IP-to-MPLS (push), MPLS-to-IP (swap), or MPLS-IP (pop) by the DUT + under overloaded state. + + Please refer to RFC 2544, Section 26.3, for more details. + + Objective + + To obtain the frame-loss rate, as defined in RFC 1242, for each of + the three MPLS forwarding operations of a DUT, throughout the + range of input data rates and frame sizes. + + Test Setup + + Follow the "Test Setup" guidelines established for each of the + five MPLS forwarding operations in Sections 6.1.1 (for IP-to- + MPLS), 6.1.2 (for MPLS-to-MPLS), 6.1.3 (for MPLS-to-IP Unlabeled), + 6.1.4 (for MPLS-to-IP Aggregate), and 6.1.5 (for MPLS-to-IP PHP), + one by one. + + Procedure + + Please refer to Section 26.3 of RFC 2544 [RFC2544] and follow the + associated procedure for each MPLS forwarding operation one-by-one + in accord with the test setup described earlier: + + IP-to-MPLS forwarding (Push) Section 6.1.1 + MPLS-to-MPLS forwarding (Swap) Section 6.1.2 + MPLS-to-IP forwarding (Pop) Section 6.1.3 + MPLS-to-IP forwarding (Aggregate) Section 6.1.4 + MPLS-to-IP forwarding (PHP) Section 6.1.5 + + A misdirected frame, that is, a frame received on the wrong Bn, is + considered lost. If the test tool is capable of checking received + MPLS label values, a frame with the wrong MPLS label is considered + lost. + + Reporting Format + + The result should be reported as per Section 5 and RFC 2544. + + + + +Akhter, et al. Informational [Page 22] + +RFC 5695 MPLS Benchmarking Methodology November 2009 + + +6.4. System Recovery + + Objective + + To characterize the speed at which a DUT recovers from an overload + condition. + + Test Setup + + Follow the "Test Setup" guidelines established for each of the + five MPLS forwarding operations in Sections 6.1.1 (for IP-to- + MPLS), 6.1.2 (for MPLS-to-MPLS), 6.1.3 (for MPLS-to-IP Unlabeled), + 6.1.4 (for MPLS-to-IP Aggregate), and 6.1.5 (for MPLS-to-IP PHP), + one by one. + + Procedure + + Please refer to Section 26.5 of RFC 2544 and follow the associated + procedure for each MPLS forwarding operation in the referenced + sections one-by-one in accord with the test setup described + earlier: + + IP-to-MPLS forwarding (Push) Section 6.1.1 + MPLS-to-MPLS forwarding (Swap) Section 6.1.2 + MPLS-to-IP forwarding (Pop) Section 6.1.3 + MPLS-to-IP forwarding (Aggregate) Section 6.1.4 + MPLS-to-IP forwarding (PHP) Section 6.1.5 + + Reporting Format + + The result should be reported as per Section 5 and RFC 2544. + +6.5. Reset + + The "reset" aspects of benchmarking are described in [RFC2544], but + these procedures need to be clarified in order to ensure consistency. + This document does not specify the reset procedures. These need to + be addressed in a separate document and will more generally apply to + IP and MPLS test cases. + + The text below describes the MPLS forwarding benchmarking-specific + setup that will have to be used in conjunction with the procedures + from the separate document to make this test case meaningful. + + Objective + + To characterize the speed at which a DUT recovers from a device or + software reset. + + + +Akhter, et al. Informational [Page 23] + +RFC 5695 MPLS Benchmarking Methodology November 2009 + + + Test Setup + + Follow the "Test Setup" guidelines established for each of the + five MPLS forwarding operations in Sections 6.1.1 (for IP-to- + MPLS), 6.1.2 (for MPLS-to-MPLS), 6.1.3 (for MPLS-to-IP Unlabeled), + 6.1.4 (for MPLS-to-IP Aggregate), and 6.1.5 (for MPLS-to-IP PHP), + one by one. + + For this test case, the requirements of LDP and a routing protocol + are removed and replaced by static configurations. For the IP-to- + MPLS forwarding, static route configurations should be applied. + For the MPLS-to-MPLS and MPLS-to-IP, static label configurations + must be applied. + + For this test, all Graceful Restart features MUST be disabled. + + Discussion + + This test case is intended to provide insight into how long an + MPLS device could take to be fully operational after any of the + reset events. It is quite likely that the time an IP/MPLS device + takes to become fully operational after any of the reset events + may be different from that of an IP-only device. + + Modern devices now have many more reset options that were not + available when Section 26.6 of RFC 2544 was published. Moreover, + different reset events on modern devices may produce different + results, hence, needing clarity and consistency in reset + procedures beyond what's specified in RFC 2544. + + Procedure + + Please follow the procedure from the separate document for each + MPLS forwarding operation one-by-one: + + IP-to-MPLS forwarding (Push) Section 6.1.1 + MPLS-to-MPLS forwarding (Swap) Section 6.1.2 + MPLS-to-IP forwarding (Pop) Section 6.1.3 + MPLS-to-IP forwarding (Aggregate) Section 6.1.4 + MPLS-to-IP forwarding (PHP) Section 6.1.5 + + Reporting Format + + The result should be reported as per Section 5 and as per the + separate document. + + + + + + +Akhter, et al. Informational [Page 24] + +RFC 5695 MPLS Benchmarking Methodology November 2009 + + +7. Security Considerations + + Benchmarking activities, as described in this memo, are limited to + technology characterization using controlled stimuli in a laboratory + environment, with dedicated address space and the constraints + specified in the sections above. + + The benchmarking network topology will be an independent test setup + and MUST NOT be connected to devices that may forward the test + traffic into a production network or misroute traffic to the test + management network. + + Furthermore, benchmarking is performed on a "black-box" basis, + relying solely on measurements observable external to the DUT/SUT + (System Under Test). + + Special capabilities SHOULD NOT exist in the DUT/SUT specifically for + benchmarking purposes. Any implications for network security arising + from the DUT/SUT SHOULD be identical in the lab and in production + networks. + + There are no specific security considerations within the scope of + this document. + +8. Acknowledgement + + The authors would like to thank Mo Khalid, who motivated us to write + this document. We would like to thank Rodney Dunn, Chip Popoviciu, + Jeff Byzek, Jay Karthik, Rajiv Papneja, Samir Vapiwala, Silvija + Andrijic Dry, Scott Bradner, Al Morton, and Bill Cerveny for their + careful review and suggestions. + + This document was originally prepared using 2-Word-v2.0.template.dot. + +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 J. McQuaid, "Benchmarking Methodology for + Network Interconnect Devices", RFC 2544, March 1999. + + [RFC1242] Bradner, S., "Benchmarking Terminology for Network + Interconnection Devices", RFC 1242, July 1991. + + + + + +Akhter, et al. Informational [Page 25] + +RFC 5695 MPLS Benchmarking Methodology November 2009 + + + [RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol + Label Switching Architecture", RFC 3031, January 2001. + + [RFC3032] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y., + Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack + Encoding", RFC 3032, January 2001. + + [RFC3107] Rekhter, Y. and E. Rosen, "Carrying Label Information in + BGP-4", RFC 3107, May 2001. + + [RFC5036] Andersson, L., Ed., Minei, I., Ed., and B. Thomas, Ed., + "LDP Specification", RFC 5036, October 2007. + +9.2. Informative References + + [RFC5180] Popoviciu, C., Hamza, A., Van de Velde, G., and D. + Dugatkin, "IPv6 Benchmarking Methodology for Network + Interconnect Devices", RFC 5180, May 2008. + + [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., + and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP + Tunnels", RFC 3209, December 2001. + + [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private + Networks (VPNs)", RFC 4364, February 2006. + + [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A Border + Gateway Protocol 4 (BGP-4)", RFC 4271, January 2006. + + [RFC4664] Andersson, L., Ed., and E. Rosen, Ed., "Framework for Layer + 2 Virtual Private Networks (L2VPNs)", RFC 4664, September + 2006. + + [IEE8021] Mick Seaman (editor), "IEEE Std 802.1D-2004, MAC Bridges", + Feb 2004. + + [IEE8023] LAN/MAN Standards Committee of the IEEE Computer Society, + "IEEE Std 802.3as-2006, Part 3: Carrier Sense Multiple + Access with Collision Detection (CSMA/CD) Access Method and + Physical Layer Specifications, Amendment 3: Frame format + extensions", Nov 2006. + + [RFC3443] Agarwal, P. and B. Akyol, "Time To Live (TTL) Processing in + Multi-Protocol Label Switching (MPLS) Networks", RFC 3443, + January 2003. + + + + + + +Akhter, et al. Informational [Page 26] + +RFC 5695 MPLS Benchmarking Methodology November 2009 + + + [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998. + + [RFC5462] Andersson, L. and R. Asati, "Multiprotocol Label Switching + (MPLS) Label Stack Entry: "EXP" Field Renamed to "Traffic + Class" Field", RFC 5462, February 2009. + + [RFC4928] Swallow, G., Bryant, S., and L. Andersson, "Avoiding Equal + Cost Multipath Treatment in MPLS Networks", BCP 128, RFC + 4928, June 2007. + + [RFC4090] Pan, P., Ed., Swallow, G., Ed., and A. Atlas, Ed., "Fast + Reroute Extensions to RSVP-TE for LSP Tunnels", RFC 4090, + May 2005. + +Authors' Addresses + + Aamer Akhter + Cisco Systems + 7025 Kit Creek Road + RTP, NC 27709 + USA + + EMail: aakhter@cisco.com + + + Rajiv Asati + Cisco Systems + 7025 Kit Creek Road + RTP, NC 27709 + USA + + EMail: rajiva@cisco.com + + + Carlos Pignataro + Cisco Systems + 7200-12 Kit Creek Road + RTP, NC 27709 + USA + + EMail: cpignata@cisco.com + + + + + + + + + + +Akhter, et al. Informational [Page 27] + |