idnits 2.17.1 draft-ietf-bmwg-mpls-forwarding-meth-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.i or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 1 instance of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- however, there's a paragraph with a matching beginning. Boilerplate error? -- The document date (April 21, 2009) is 5455 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 3107 (Obsoleted by RFC 8277) Summary: 2 errors (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 BMWG Aamer Akhter 3 Internet Draft Cisco Systems 4 Intended status: Informational 5 Expires: October 21, 2009 Rajiv Asati 6 Cisco Systems 8 Carlos Pignataro 9 Cisco Systems 11 April 21, 2009 13 MPLS Forwarding Benchmarking Methodology for IP Flows 14 draft-ietf-bmwg-mpls-forwarding-meth-03.txt 16 Status of this Memo 18 This Internet-Draft is submitted to IETF in full conformance with 19 the provisions of BCP 78 and BCP 79. This document may contain 20 material from IETF Documents or IETF Contributions published or made 21 publicly available before November 10, 2008. The person(s) 22 controlling the copyright in some of this material may not have 23 granted the IETF Trust the right to allow modifications of such 24 material outside the IETF Standards Process. Without obtaining an 25 adequate license from the person(s) controlling the copyright in 26 such materials, this document may not be modified outside the IETF 27 Standards Process, and derivative works of it may not be created 28 outside the IETF Standards Process, except to format it for 29 publication as an RFC or to translate it into languages other than 30 English 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF), its areas, and its working groups. Note that 34 other groups may also distribute working documents as Internet- 35 Drafts. 37 Internet-Drafts are draft documents valid for a maximum of six 38 months and may be updated, replaced, or obsoleted by other documents 39 at any time. It is inappropriate to use Internet-Drafts as 40 reference material or to cite them other than as "work in progress." 42 The list of current Internet-Drafts can be accessed at 43 http://www.ietf.org/ietf/1id-abstracts.txt 45 The list of Internet-Draft Shadow Directories can be accessed at 46 http://www.ietf.org/shadow.html 48 This Internet-Draft will expire on October 21, 2009. 50 Copyright Notice 52 Copyright (c) 2009 IETF Trust and the persons identified as the 53 document authors. All rights reserved. 55 This document is subject to BCP 78 and the IETF Trust's Legal 56 Provisions Relating to IETF Documents in effect on the date of 57 publication of this document (http://trustee.ietf.org/license-info). 58 Please review these documents carefully, as they describe your 59 rights and restrictions with respect to this document. 61 Abstract 63 This document describes a methodology specific to the benchmarking 64 of Multi-Protocol Label Switching (MPLS) forwarding devices, limited 65 to the most common MPLS packet forwarding scenarios and delay 66 measurements for each, considering IP flows. It builds upon the 67 tenets set forth in RFC2544, RFC1242 and other IETF Benchmarking 68 Methodology Working Group (BMWG) efforts. This document seeks to 69 extend these efforts to the MPLS paradigm. 71 Table of Contents 73 1. Introduction...................................................3 74 2. Document Scope.................................................4 75 3. Key Words to Reflect Requirements..............................5 76 4. Test Methodology...............................................5 77 4.1. Test Considerations..........................................6 78 4.1.1. Abbreviations Used.........................................6 79 4.1.2. IGP Support................................................7 80 4.1.3. Label Distribution Support.................................7 81 4.1.4. Frame Formats..............................................8 82 4.1.5. Frame Sizes...............................................10 83 4.1.6. Time-to-Live (TTL) or Hop Limit...........................13 84 4.1.7. Trial Duration............................................13 85 4.1.8. Traffic Verification......................................14 86 4.1.9. Address Resolution and Dynamic Protocol State.............14 87 5. Reporting Format..............................................15 88 6. MPLS Forwarding Benchmarking Tests............................16 89 6.1. Throughput..................................................18 90 6.1.1. Throughput for MPLS Label Imposition......................18 91 6.1.2. Throughput for MPLS Label Swap............................19 92 6.1.3. Throughput for MPLS Label Disposition (Unlabeled).........20 93 6.1.4. Throughput for MPLS Label Disposition (Aggregate).........21 94 6.1.5. Throughput for MPLS Label Disposition (PHP)...............22 95 6.2. Latency Measurement.........................................23 96 6.3. Frame Loss Rate Measurement (FLR)...........................24 97 6.4. System Recovery.............................................25 98 6.5. Reset.......................................................26 99 7. Security Considerations.......................................27 100 8. IANA Considerations...........................................27 101 9. Acknowledgement...............................................27 102 10. References...................................................28 103 10.1. Normative References.......................................28 104 10.2. Informative References.....................................28 105 Author's Addresses...............................................29 107 1. Introduction 109 Over the past several years, there has been an increase in the use 110 of MPLS as a forwarding architecture in new and existing network 111 designs. MPLS, defined in [RFC3031], is a foundation technology and 112 basis for many advanced technologies such as Layer 3 MPLS-VPNs, 113 Layer 2 MPLS-VPNs, and MPLS Traffic-Engineering. 115 However, there is no standard method defined to compare and contrast 116 the foundational MPLS packet forwarding capabilities of network 117 devices. This document proposes a methodology using common criteria 118 (such as throughput, latency, frame loss rate, system recovery, 119 reset etc.) to evaluate MPLS forwarding of any implementation. 121 2. Document Scope 123 The benchmarking methodology principles outlined in RFC2544 124 [RFC2544] are independent of forwarding techniques, however, they 125 don't fully address MPLS benchmarking. The fact that MPLS forwarding 126 places a different burden on the resources of the network forwarding 127 devices from that of IP forwarding, MPLS forwarding benchmarking 128 specifics are desired. 130 The purpose of this document is to describe a methodology specific 131 to the benchmarking of MPLS forwarding devices. The methods 132 described are limited in scope to the most common MPLS packet 133 forwarding scenarios and corresponding performance measurements in a 134 laboratory setting. It builds upon the tenets set forth in RFC2544 135 [RFC2544], RFC1242 [RFC1242] and other IETF Benchmarking Methodology 136 Working Group (BMWG) efforts. In other words, this document is not a 137 replacement for, but a complement to, RFC 2544. 139 This document focuses on the MPLS label stack [RFC3032] having only 140 one entry, as it is the fundamental of MPLS forwarding. It is 141 expected that future documents may cover the benchmarking of MPLS 142 applications such as L3VPN [RFC4364], L2VPN [RFC4664], Fast ReRoute 143 [RFC4090] etc., which require more than one entry in the MPLS label 144 stack. 146 Moreover, to address the majority of current deployments' needs, 147 this document focuses on having IP packets as the MPLS payload. In 148 other words, label distribution for IP Forwarding Equivalence Class 149 (FEC)[RFC3031] is prescribed (see Section 4.1.2) by this document. 150 It is expected that future documents may focus on having non-IP 151 packets as the MPLS payload. 153 Note that the presence of an MPLS label stack does not require the 154 length of MPLS payload (which is an IP packet, per this document) to 155 be changed, hence, the effective maximum size of a frame can 156 increase by Z bytes (where Z = 4 x number of label stack entries), 157 as observed in current deployments. This document focuses on 158 benchmarking such a scenario. 160 3. Key Words to Reflect Requirements 162 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 163 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 164 document are to be interpreted as described in BCP 14, RFC 2119 165 [RFC2119]. RFC 2119 defines the use of these key words to help make 166 the intent of standards track documents as clear as possible. While 167 this document uses these keywords, this document is not a standards 168 track document. 170 4. Test Methodology 172 The set of methodologies described in this document will use the 173 topology described in this section. An effort has been made to 174 exclude superfluous equipment needs such that each test can be 175 carried out with a minimal number of devices.Figure 1 illustrates 176 the sample topology in which the Device Under Test (DUT) is 177 connected to the test ports on the test tool in accord with the Fig 178 1 of RFC2544 - 180 +-----------------+ 181 +---------+ | | +---------+ 182 | Test | | | | Test | 183 | Port A1 +-----+ DA1 DB1 -----+ Port B1 | 184 +---------+ | | +---------+ 185 +---------+ | DUT | +---------+ 186 | Test | | | | Test | 187 | Port A2 +-----+ DA2 DB2 +-----+ Port B2 | 188 +---------+ | | +---------+ 189 ... | | ... 190 +---------+ | | +---------+ 191 | Test | +-----------------+ | Test | 192 | Port Ap | | Port Bp | 193 +---------+ +---------+ 195 Figure 1 Topology for MPLS Forwarding Benchmarking 197 A represents a Tx-side Module of the test tool, whereas B represents 198 an Rx-side Module of the same test tool. Of course, the suffixed 199 numbers (1, 2...p) represent ports on a Module. 201 Similarly, DA represents an Rx-side Module of the DUT, whereas DB 202 represents Tx-side Module. The suffixed numbers (1, 2...p) represent 203 ports on a Module. 205 p = number of {DA, DB} pair ports on DUT. It is determined by the 206 maximum unidirectional forwarding throughput of the DUT and the load 207 capacity of the port media (e.g. interface) connecting the DUT to 208 the test tool. 210 For example, if the DUT's maximum forwarding throughput is 100 211 frames per second (fps), and the load capacity of the port media 212 (e.g. interface) is 50 fps, then p => 2 is needed to sufficiently 213 test the maximum frame forwarding. 215 The exact throughput is a measured quantity obtained through 216 testing. Throughput may vary depending on the number of ports used, 217 and other factors. The number of ports (p) used SHOULD be reported. 218 Please see Test Setup in Section 6, and recommended to follow Fig 1 219 from S6 of RFC2544. 221 4.1. Test Considerations 223 This methodology assumes a full-duplex uniform medium topology. The 224 medium used MUST be reported in each test result. Issues regarding 225 mixed transmission media, speed mismatches, media header differences 226 etc, are not under consideration. Traffic affecting features such as 227 Flow control, QoS, Graceful Restart etc. MUST be disabled, unless 228 explicitly requested in the test case. Additionally, any non- 229 essential traffic MUST also be avoided. 231 4.1.1. Abbreviations Used 233 The terms used in this document remain consistent with those defined 234 in "Benchmarking Terminology for Network Interconnect Devices" 235 RFC1242 [RFC1242]. This terminology SHOULD be consulted before using 236 or applying the recommendations of this document. 238 Please refer to Figure 1 for a topology view of the network. The 239 following abbreviations are used in this document - 241 M := Module on a device (i.e. Line-Card or Slot; could be A or B) 243 p := Port number (i.e. Port on the Module; could be 1, 2 etc.) 244 RN := Remote Network (i.e. network that is reachable via a port of a 245 module; could be B1RN1 or B2RN5 to mean the first network reachable 246 via port 1 of module B e.g. B1, or the 5th network reachable via 247 port 2 of module B, etc.). RN is considered to be the FEC from MPLS 248 perpsective. 250 4.1.2. IGP Support 252 It is highly RECOMMENDED that all of the ports (A1, DA1, DB1, and 253 A2) on DUT and test tool support a dynamic Interior Gateway Protocol 254 (IGP) for routing such as IS-IS, OSPF, EIGRP, RIP etc. Furthermore, 255 there are testing considerations in this document that the device be 256 able to provide a stable control-plane during heavy forwarding 257 workloads. This is to ensure that control plane instability during 258 load conditions is not the contributing factor towards frame 259 forwarding performance. 261 The route distribution method (OSPF, IS-IS, EIGRP, RIP, Static 262 etc.), if used, MUST be reported. Furthermore, if any specific 263 configuration is used to maintain control-plane stability during the 264 test (i.e. Control Plane Protection, Control Plane Rate Limiting, 265 etc.), then it MUST also be reported. 267 4.1.3. Label Distribution Support 269 The DUT and test tool must support at least one protocol for 270 exchanging MPLS label/FEC bindings for Prefix Forwarding Equivalence 271 Class (FEC) [RFC3031]. The DUT and test tool MUST be capable of 272 learning and advertising MPLS label/FEC bindings via the chosen 273 protocol(s), and use them during packet forwarding all the time 274 (including when the label/FEC bindings change). The most commonly 275 used protocols are Label Distribution Protocol (LDP) [RFC5036], 276 Resource Reservation Protocol-Traffic Engineering (RSVP-TE) 277 [RFC3209] and Border Gateway Protocol (BGP) [RFC3107]. 279 All of the ports (A1, DA1, DB1, B1 etc.) either on the DUT or the 280 test tool used in the testing SHOULD support LDP, RSVP-TE, and BGP 281 for IPv4 or IPv6 Prefix Forwarding Equivalence Classes (FECs). 283 This document does NOT recommend the use of static label to 284 establish the MPLS label switched paths (LSPs), unless specified 285 explicitly by the testcase. This is because the use of static label 286 is quite uncommon in the production networks. 288 4.1.4. Frame Formats 290 This section explains the frame formats for IP and MPLS packets 291 (Section 4.1.4.1), the usage of IP as the mandatory layer 3 protocol 292 and as the MPLS packet payload (Section 4.1.4.2), change in frame 293 format during forwarding (Section 4.1.4.3) and recommended frame 294 formats for the MPLS benchmarking (Section 4.1.4.4). 296 4.1.4.1. Frame format for IP vs. MPLS 298 A test frame carrying an IP packet is illustrated in the figure 1 299 below. Note that RFC2544 [RFC2544] prescribes using such a frame as 300 the test frame over the chosen layer 2 media. 302 +------------------------------------------------+ 303 | Layer 2 | Layer 3 = IP | Layer 4 = UDP | 304 +------------------------------------------------+ 306 Figure 1 Frame Format for IP packet 308 Unlike a test frame carrying an IP packet, a test frame carrying an 309 MPLS packet contains an 'MPLS label stack' [RFC3032] immediately 310 after the layer 2 header (and before the IP header, if any) as 311 illustrated in figure 2 below - 313 +--------------------------------------------------------+ 314 | Layer 2 | MPLS | Layer 3 = IP | Layer 4 = UDP | 315 +--------------------------------------------------------+ 317 Figure 2 Frame format for MPLS packet 319 The MPLS label stack is represented as a sequence of "label stack 320 entries", where each label stack entry is 4 bytes, as illustrated in 321 figure 1 of [RFC3032]. This document requires only a single entry in 322 the MPLS label stack in an MPLS packet. 324 MPLS label values used in any testcase MUST be outside the reserved 325 label value (0-15) unless stated otherwise. 327 4.1.4.2. MPLS packet payload 329 This document prescribes using IP packet as the MPLS payload (as 330 illustrated in figure 2 above). Generically speaking, this document 331 mandates the test frame to include IP (either IPv4 or IPv6) as the 332 layer 3 protocol, in accord with Section 8 of [RFC2544] and 333 independent of the MPLS label stack presence, for three reasons: 335 1) This enables using IP Prefix Forwarding Equivalence Class (FEC) 336 [RFC3031], which is a must for every MPLS network. 337 2) This provides the foundation or baseline for benchmarking of 338 various other MPLS applications such as L3VPN, L2VPN, TE-FRR etc. 339 3) This enables leveraging RFC2544 [RFC2544], which prescribes using 340 IP packet with UDP data as the test frames. (Note that [RFC5180] 341 also uses this prescription for IPv6 benchmarking). 343 While the usage of non-IP payloads is possible, it requires an MPLS 344 application e.g. L2VPN, whose benchmarking may be covered in 345 separate BMWG documents (MPLS L2VPN Benchmarking, for example) in 346 the future. This is also explained in Section 2. 348 4.1.4.3. Change in Frame Format due to MPLS Imposition and Disposition 350 A frame carrying IP or MPLS packet may go through any of the three 351 MPLS forwarding operations: label imposition (or LSP Ingress), label 352 swap and label disposition (or LSP Egress), as defined in [RFC3031]. 353 It is important to understand the change of the frame format from IP 354 to MPLS or vice versa depending on the forwarding operation. 356 In label imposition (or LSP ingress) operation, the DUT receives a 357 frame containing an IP packet and forwards a frame containing an 358 MPLS packet if the corresponding forwarding lookup for the IP 359 destination points to a label imposition operation. 361 In label swap operation, the DUT receives a frame containing an MPLS 362 packet and forwards a frame containing an MPLS packet if the 363 corresponding forwarding lookup for the label value points to a 364 label swap operation. 366 In label disposition (or LSP egress) operation, the DUT receives a 367 frame containing an MPLS packet and forwards a frame containing an 368 IP packet if the corresponding forwarding lookup for the label value 369 points to a label disposition operation. 371 4.1.4.4. Frame Formats to be used for Benchmarking 373 This document prescribes using two test frame formats to 374 appropriately test the forwarding operations: (1) Frame format for 375 IP and (2) Frame format for MPLS. Both formats are explained in 376 Section 4.1.3.1. Additionally, the format of the test frame may 377 change depending on the forwarding operation. 379 1. For testcases involving label imposition operation - the test 380 tool must use the frame format for IP packet (figure 1) to send 381 the test frames to the DUT, and must use the frame format for MPLS 382 packet (figure 2) to receive the test frames from the DUT. 384 2. For testcases involving label swap operation - the test tool must 385 use the frame format for MPLS packet (figure 2) to send the test 386 frames to the DUT, and must use the frame format for MPLS packet 387 (figure 2) to receive the test frames from the DUT. 389 3. For testcases involving label disposition operation - the test 390 tool must use the frame format for MPLS packet (figure 2) to send 391 the test frames to the DUT, and must use the frame format for IP 392 packet (figure 1) to receive the test frames from the DUT. 394 4.1.5. Frame Sizes 396 Two types of port media are commonly deployed: Ethernet and POS 397 (Packet Over Synchronous Optical Network). This section identifies 398 the frame sizes that SHOULD be used for each media type, if 399 supported by the DUT. Section 4.1.4.1 covers Ethernet and 4.1.4.2 400 covers POS. 402 First, it is important to note the possible increase in frame size 403 due to the presence of an MPLS label stack in the frame (as 404 explained in the Section 4.1.3). 406 As observed in the current deployments, presence of an MPLS label 407 stack in a layer 2 frame is assumed to be transparent to layer3=IP, 408 which continues to follow the conventional maximum frame payload 409 size [RFC3032] (1500 bytes for ethernet, say). This means that the 410 effective maximum frame payload size [RFC3032] of the resulting 411 layer2 frame is Z bytes more than the conventional maximum frame 412 payload size, where Z = 4 x number of entries in the label stack. 414 Hence, to ensure successful delivery of layer2 frames carrying MPLS 415 packets and realistic benchmarking, it is recommended to set the 416 media MTU value to the effective maximum frame payload size 417 [RFC3032], which equals Z bytes + conventional maximum frame payload 418 size. It is expected that such a change in media MTU value only 419 impacts the effective Maximum Frame Payload Size for MPLS packets, 420 but not for IP packets. 422 Note that this document requires only a single entry in the MPLS 423 label stack in an MPLS packet. In other words, the depth of the 424 label stack is set to one e.g. Z = 4 x 1 = 4 bytes. 425 Furthermore, in accord with Section 9 and 9.1 of RFC2544, this 426 document prescribes that each testcase case is run with different 427 (layer 2) frame sizes in different trials. Additionally, results MAY 428 also be collected with multiple simultaneous frame sizes (sometimes 429 referred to as an IMIX to simulate real network traffic according to 430 the frame size ordering and usage). There is no standard for 431 mixtures of frame sizes, and the results are subject to wide 432 interpretation. See Section 18 of RFC 2544. When running trials 433 using multiple simultaneous frame sizes, the DUT configuration MUST 434 remain the same. 436 4.1.5.1. Frame Sizes to be used on Ethernet Media 438 Ethernet media, in all its types, has become the most commonly 439 deployed port media in MPLS networks. If any test case execution 440 (such as Label Imposition case) requires the testtool to send (or 441 receive) a layer2 frame containing an IP packet, then the following 442 frame sizes SHOULD be used for benchmarking over ethernet media: 443 64, 128, 256, 512, 1024, 1280 and 1518 bytes. This is in line with 444 Section 9 and 9.1 of RFC2544. Figure 1 illustrates the header sizes 445 for an untagged ethernet frame containing an IP payload (per 446 RFC2544) - 448 <----------------64-1518B------------------------> 449 <--18B---><-----------46-1500B-------------------> 450 +------------------------------------------------+ 451 | Layer 2 | Layer 3 | Layer 4 (and higher) | 452 +------------------------------------------------+ 454 Figure 3 Frame Size for Label Imposition cases 456 Note: The 64 and 1518 byte frame size represents the minimum and 457 maximum length of an untagged Ethernet frame, as per IEEE 802.3 458 [IEE8023]. A frame size commonly used in operational environments 459 may range from 68 to 1522 bytes, which are the minimum and maximum 460 length of a single VLAN-tagged frame, as per IEEE 802.1D 461 [IEE8021]. 463 Note: While jumbo frames are outside the scope of the 802.3 IEEE 464 standard, tests SHOULD be executed with the frame sizes that are 465 supported by the DUT. Examples of commonly used jumbo (ethernet) 466 frame sizes are: 4096, 8192, and 9216 bytes. 468 If any test case execution (such as Label Swap and Label Disposition 469 cases) requires the testtool to transmit (or receive) a layer2 frame 470 containing an MPLS packet, then the untagged layer2 frame must 471 include an additional 4 bytes for the MPLS header, resulting in the 472 following frame sizes to be used for benchmarking over ethernet 473 media: 68, 132, 260, 516, 1028, 1284 and 1522 bytes. Figure 2 474 illustrates the header sizes for an untagged ethernet frame 475 containing an MPLS packet - 477 <------------------68-1522B------------------------------> 478 <--18B---><--4B--><-----------46-1500B-------------------> 479 +--------------------------------------------------------+ 480 | Layer 2 | MPLS | Layer 3 | Layer 4 (and higher) | 481 +--------------------------------------------------------+ 483 Figure 4 Frame Size for Label Swap and Disposition cases. 485 Note: The Media MTU on the link between the testtool and DUT must 486 be changed, if needed, to accommodate the effective maximum frame 487 payload size [RFC3032] resulting from adding an MPLS label stack 488 to the IP packet. As clarified in Section 3.1 of RFC3032, most 489 layer 2 media drivers are capable of sending and receiving layer 2 490 frames with effective maximum frame payload size. Many vendors 491 also allow the Media MTU to be changed for MPLS, without changing 492 it for IP. The recommended link MTU value for MPLS is Z bytes more 493 than the conventional maximum frame payload size [RFC3032] (for 494 example, the conventional maximum frame payload size for ethernet 495 is 1500 bytes). This document prescribes Z=4 bytes. If a vendor 496 DUT doesn't allow such an MTU change, then the benchmarking can 497 not be performed for the true maximum frame payload size [RFC3032] 498 and this must be reported. 500 4.1.5.2. Frame Sizes to be used on POS Media 502 Packet over SONET (POS) media are commonly used for edge uplinks and 503 high-bandwidth core links. POS may use one of various 504 encapsulations techniques (such as PPP, HDLC, Frame Relay etc.), 505 resulting in the layer 2 header (~4 bytes) being less than that of 506 ethernet media. The rest of the frame format (illustrated in figure 507 2 and 3) remains pretty much unchanged. 509 If the MPLS forwarding characterization of POS interfaces on the DUT 510 is desired, then the following frame sizes SHOULD be used: 512 Label Imposition testcases: 47, 64, 128, 256, 512, 1024, 1280, 513 1518, 2048 and 4096 bytes. 515 Label Swap and Dispoisition testcases: 51, 68, 132, 260, 516, 516 1028, 1284, 1522, 2052 and 4100 bytes. 518 4.1.6. Time-to-Live (TTL) or Hop Limit 520 The TTL value in the frame header must be large enough to allow a 521 TTL decrement to happen and still be forwared through the DUT. The 522 TTL field may either be MPLS TTL, IPV4 TTL, or IPV6 Hop Limit 523 depending on the exact forwarding scenario under evaluation. 525 If TTL/Hop Limit Decrement, as specified in [RFC3443], is a 526 configurable option on the DUT, the setting SHOULD be reported. 528 4.1.7. Trial Duration 530 Unless otherwise specified, the test portion of each trial SHOULD be 531 no less than 30 seconds when static routing is in place, and no less 532 than 200 seconds when a dynamic routing protocol and LDP (default 533 LDP holddown timer is 180 seconds) are being used. If the holddown 534 timer default vaue is changed, then it should be reported and the 535 trial duration should still be 20 seconds more than the holddown 536 timer value. 538 The longer trial time used for dynamic routing protocols is to 539 verify that the DUT is able to maintain a stable control plane when 540 the data-forwarding plane is under stress. 542 4.1.8. Traffic Verification 544 In all cases, sent traffic MUST be accounted for, whether it was 545 received on the wrong port, correct port or not received at all. 546 Specifically, traffic loss (also referred to as frame loss) is 547 defined as the traffic (i.e. one or more frames) not received where 548 expected (i.e. received on incorrect port, or received with 549 incorrect layer2 or above header information etc.). In addition, the 550 presence or absence of MPLS label stack, every field value inside 551 the label stack, if present, ethertype (0x8847 or 0x8848 vs. 552 0x0800), frame sequencing and frame check sequence (FCS), MUST be 553 verified in the received frame. 555 Many test tools may, by default, only verify that they have received 556 the embedded signature on the receive side. However, for MPLS header 557 presence verification, some tests will require the MPLS header to be 558 imposed while others will require a swap or disposition. Hence, this 559 document requires the test tool to verify the MPLS stack depth. An 560 even greater level of verification would be to check if the correct 561 label was imposed, but that is out of scope for these tests. 563 4.1.9. Address Resolution and Dynamic Protocol State 565 If a test setup utilizes any dynamic protocols for control plane 566 signalling (eg. ARP, PPP (including MPLSCP), OSPF, LDP, etc.), then 567 all state for the protocols MUST be pre-established bofore the test 568 case is executed (i.e. packet streams are started). 570 5. Reporting Format 572 For each test case, it is RECOMMENDED that the following variables 573 be reported in addition to the specific parameters requested by the 574 test case: 576 Parameter Units or Examples 578 Prefix Forwarding IPv4, IPv6, Both 579 Equivalence Class (FEC) 581 Label Distribution Protocol LDP, RSVP-TE, BGP (or 582 combinations) 584 MPLS Forwarding Operation Imposition, Swap, 585 Disposition 587 IGP ISIS, OSPF, EIGRP, RIP, 588 static. 590 Throughput Frames per second and 591 Bits per second 593 Port Media GigE, POS, ATM etc. 595 Port Speed 1 gbps, 100 Mbps, etc. 597 Interface Encapsulation Ethernet, Ethernet VLAN, 598 PPP, HDLC etc. 600 Frame Size [See Section Bytes 601 4.1.3] 603 p (Number of {DA, DB} pair 1,2, etc. 604 ports per Figure 1) 606 The individual test cases may have additional reporting requirements 607 that may refer to other RFCs. 609 6. MPLS Forwarding Benchmarking Tests 611 MPLS is a different forwarding paradigm from IP. Unlike IP packet 612 and IP forwarding, an MPLS packet may contain more than one MPLS 613 header and may go through one of three forwarding operations - 614 imposition (or LSP ingress), swap or disposition (or LSP egress), as 615 defined in [RFC3031]. Such characteristics desire further 616 granularity in MPLS forwarding benchmarking than those described in 617 RFC2544. Thus the benchmarking may include, but not limited to: 619 1. Throughput 621 2. Latency 623 3. Frame Loss rate 625 4. System Recovery 627 5. Reset 629 6. MPLS TC (previously known as EXP [RFC5462]) field Operations 630 (including explicit-null cases) 632 7. Negative Scenarios (TTL expiry, etc) 634 8. Multicast 636 However, this document focuses only on the first five categories, 637 inline with the spirit of RFC2544. All the benchmarking test cases 638 described in this document are expected to, at a minimum, follow the 639 'Test Setup' and 'Test Procedure' below - 641 Test Setup 643 Referring to Figure 1, a single port (p = 1) on both A and B 644 Modules SHOULD be used. However, if the forwarding throughput of 645 the DUT is more than that of the media rate of a single port, then 646 additional ports on A and B Modules MUST be enabled so as to 647 exceed the DUT's forwarding throughput. In such a case, the 648 procedures described in Section 16 of RFC2544 must be followed to 649 accommodate the multi-port scenario. The frame formats transmitted 650 and received must be in accord with Section 4.1.4.3 and 4.1.4.4, 651 and frame sizes must be in accord with in Section 4.1.5. 653 Note - The test tool must be configured to not advertise a prefix 654 or FEC to the DUT on more than one port. In other words, the DUT 655 must associate a FEC with one and only one DB port. The Equal Cost 656 Multi-Path (ECMP) behavior in MPLS networks uses heuristics 657 [RFC4928], hence, the usage of ECMP is NOT permitted by this 658 document to ensure the deterministic forwarding behavior during 659 the benchmarking. 661 Test Procedure 663 In accord with Section 26 of RFC2544 [RFC2544], the traffic is 664 sent from test tool port(s) Ap to the DUT at a constant load for a 665 fixed time interval, and is received from the DUT on test tool 666 port(s) Bp. The frame may contain either an IP packet or an MPLS 667 packet depending on the testcase need, as described in the Section 668 4.1.4.3. Furthermore, the IP packet must be either an IPv4 or IPv6 669 packet, depending on whether the MPLS benchmarking is done for 670 IPv4 or IPv6. 672 If any frame loss is detected, then a new iteration is needed 673 where the offered load is decreased and the sender will transmit 674 again. An iterative search algorithm MUST be used to determine the 675 maximum offered frame rate with a zero frame loss. 677 This maximum offered frame rate that results in zero frame loss 678 through the DUT is defined as the Throughput in Section 3.17 of 679 [RFC1242] for that test case. Informally, this rate is referred to 680 as the No Drop Rate. 682 Each iteration should involve varying the offered load of the 683 traffic, while keeping the other parameters (test duration, number 684 of ports, number of addresses, frame size etc) constant, until the 685 maximum rate at which none of the offered frames are dropped is 686 determined. 688 6.1. Throughput 690 This Section contains the description of the tests that are related 691 to the characterization of DUT's MPLS traffic forwarding. 693 6.1.1. Throughput for MPLS Label Imposition 695 Objective 697 To obtain the DUT's Throughput (as per RFC 2544) during label 698 imposition or LSP Ingress forwarding operation (i.e. IP to MPLS). 700 Test Setup 702 In addition to the test setup described in Section 6, the test 703 tool must advertise the IP prefix(es) i.e. RNx (using a routing 704 protocol as per Section 4.1.2) and associated MPLS label-FEC 705 binding(s) (using a label distribution protocol as per Section 706 4.1.3) on its receive ports Bp to DUT. The test tool may learn the 707 IP prefix(es) on it's transmit ports Ap from DUT. 709 MPLS and/or label distribution protocol must be enabled only on 710 the test tool receive ports Bp and DUT transmit ports DBp. 712 Discussion 714 The DUT's MPLS forwarding table (also referred to as FEC-to-NHLFE 715 (FTN) mapping table per [RFC3031]) must contain a non-reserved 716 MPLS label value as the outgoing label for each learned IP prefix 717 corresponding to the label-FEC binding, resulting in DUT 718 performing the IP-to-MPLS forwarding operation. The test tool must 719 receive MPLS packets on receive ports Bp (from DUT) with the same 720 label values that were advertised. 722 Procedure 724 Please see Test Procedure in Section 6. Additionally, the test 725 tool MUST send the frames containing IP packets (with IP 726 destination belonging to the advertised IP prefix(es)) on transmit 727 ports Ap, and expect to receive frames containing MPLS packets on 728 receive ports Bp, as described in Section 4.1.4.4. 730 Reporting Format 731 The result should be reported as per Section 5 and as per RFC2544. 733 Results for each test SHOULD be in the form of a table with a row 734 for each of the tested frame sizes. Additional columns SHOULD 735 include: offered load and measured throughput. 737 6.1.2. Throughput for MPLS Label Swap 739 Objective 741 To obtain the DUT's Throughput (as per RFC 2544) during label 742 swapping operation (i.e. MPLS to MPLS). 744 Test Setup 746 In addition to setup described in Section 6, the test tool must 747 advertise IP prefix(es) (using a routing protocol as per Section 748 4.1.2) and associated MPLS label-FEC bindings (using a label 749 distribution protocol as per Section 4.1.3) on the receive ports 750 Bp, and then learn the IP prefix(es) as well as the label-FEC 751 binding(s) on the transmit ports Ap. The test tool must use the 752 learned MPLS label values and learned IP prefix values in the 753 frames transmitted on ports Ap to DUT. 755 MPLS and/or label distribution protocol must be enabled on the 756 test tool ports Bp and Ap, and DUT ports DBp and DAp. 758 Discussion 760 The DUT's MPLS forwarding table (also referred to as FEC-to-NHLFE 761 (FTN) mapping table per [RFC3031]) must contain non-reserved MPLS 762 label values as the outgoing and incoming labels for the learned 763 IP prefixes, resulting in MPLS-to-MPLS forwarding operation e.g. 764 label swap. The test tool must receive MPLS packets on receive 765 ports Bp (from DUT) with the same label values that were 766 advertised using the label distribution protocol. The received 767 frames must contain the same number of MPLS headers as those of 768 transmitted frames. 770 Procedure 772 Please see Test Procedure in Section 6. Additionally, the test 773 tool must send frames containing MPLS packets (with IP destination 774 belonging to the advertised IP prefix(es)) on it's transmit ports 775 Ap, and expect to receive frames containing MPLS packets on its 776 receive ports Bp, as described in Section 4.1.4.4. 778 Reporting Format 780 The result should be reported as per Section 5 and as per RFC2544. 782 Results for each test SHOULD be in the form of a table with a row 783 for each of the tested frame sizes. 785 6.1.3. Throughput for MPLS Label Disposition (Unlabeled) 787 Objective 789 To obtain the DUT's Throughput (as per RFC 2544) during label 790 disposition or LSP Egress forwaridng operation (i.e. MPLS to IP) 791 using "Unlabeled" outgoing label. 793 Test Setup 795 In addition to setup described in Section 6, the test tool must 796 advertise the IP prefix(es) (using a routing protocol as per 797 Section 4.1.2) without any MPLS label-FEC bindings on the receive 798 ports Bp, and then learn the IP prefix(es) as well as the FEC- 799 label binding(s) on the transmit ports Ap. The test tool must use 800 the learned MPLS label values and learned IP prefix values in the 801 frames transmitted on ports Ap. 803 MPLS and/or label distribution protocol must be enabled only on 804 the test tool port(s) Ap and DUT port(s) DAp. 806 Discussion 808 The DUT's MPLS forwarding table (also referred to as FEC-to-NHLFE 809 (FTN) mapping table per [RFC3031]) must contain an Unlabeled 810 outgoing label (also known as untagged) for the learned IP prefix, 811 resulting in MPLS-to-IP forwarding operation. 813 Procedure 815 Please see Test Procedure in Section 6. Additionally, the test 816 tool must send frames containing MPLS packets on its transmit 817 ports Ap (with IP destination belonging to the IP prefix(es) 818 advertised on port Bp), and expect to receive frames containing IP 819 packets on its receive ports Bp, as described in Section 4.1.4.4. 821 Reporting Format 823 The result should be reported as per Section 5 and as per RFC2544. 825 Results for each test SHOULD be in the form of a table with a row 826 for each of the tested frame sizes. 828 6.1.4. Throughput for MPLS Label Disposition (Aggregate) 830 Objective 832 To obtain the DUT's Throughput (as per RFC 2544) during label 833 disposition or LSP Egress forwarding operation (i.e. MPLS to IP) 834 using "Aggregate" outgoing label. 836 Test Setup 838 In addition to setup described in Section 6, the DUT must be 839 provisioned such that it allocates an aggregate outgoing label 840 (please see Section 3.20 in [RFC3031]) to an IP prefix, which 841 aggregates a set of prefixes learned on ports DBp from the test 842 tool. The prefix aggregation can be performed using BGP 843 aggregation (Section 9.2.2.2 of [RFC4271]), IGP aggregation 844 (Section 16.5 of [RFC2328]), etc.). 846 The DUT must advertise the aggregating IP prefix along with the 847 associated MPLS label-FEC binding on ports DAp to the test tool. 849 The test tool then must use the learned MPLS label values and 850 learned IP prefix values in frames transmitted on ports Ap to the 851 DUT. The test tool must receive frames containing IP packets on 852 ports Bp from the DUT. 854 MPLS and/or label distribution protocol must be enabled only on 855 the test tool port(s) Ap and DUT port(s) DAp. 857 Discussion 859 The DUT's MPLS forwarding table (also referred to as FEC-to-NHLFE 860 (FTN) mapping table per [RFC3031]) must contain an aggregate 861 outgoing label and IP forwarding table must contain a valid entry 862 for the learned prefix(es), resulting in MPLS-to-IP forwarding 863 operation (i.e. MPLS header removal followed by IP lookup). 865 Procedure 866 Please see Test Procedure in Section 6. Additionally, the test 867 tool must send frames containing MPLS packets on its transmit 868 ports Ap (with IP destination belonging to the IP prefix(es) 869 advertised on port Bp), and expect to receive frames containing IP 870 packets on its receive ports Bp, as described in Section 4.1.4.4. 872 Reporting Format 874 The result should be reported as per Section 5 and as per RFC2544. 876 Results for each test SHOULD be in the form of a table with a row 877 for each of the tested frame sizes. 879 6.1.5. Throughput for MPLS Label Disposition (PHP) 881 Objective 883 To obtain the DUT's Throughput (as per RFC 2544) during label 884 disposition (i.e. MPLS to IP) or penultimate hop popping (PHP) 885 using "imp-null" outgoing label. 887 Test Setup 889 In addition to setup described in Section 6, the test tool must be 890 set up to advertise the IP prefix(es) (using a routing protocol as 891 per Section 4.1.2) and associated MPLS label-FEC binding with a 892 reserved MPLS label value = 3 (using a label distribution protocol 893 as per Section 4.1.3) on its receive ports Bp. The test tool must 894 learn the IP prefix(es) as well as the MPLS label-FEC bindings on 895 its transmit ports Ap. The test tool then must use the learned 896 MPLS label values and learned IP prefix values in the frames 897 transmitted on ports Ap to DUT. The test tool must receive frames 898 containing IP packets on receive ports Bp (from DUT). 900 MPLS and/or label distribution protocol must be enabled on the 901 test tool ports Bp and Ap, and DUT ports DBp and DAp. 903 Discussion 905 This test case characterizes the Penultimate Hop Popping (PHP), 906 which is described in RFC3031. 908 The DUT's MPLS forwarding table (also referred to as FEC-to- 909 Next_Hop_Label_Forwarding_Entry (FTN) mapping table per [RFC3031]) 910 must contain a reserved MPLS label value = 3 (e.g. pop or imp- 911 null) as the outgoing label for the learned prefix(es), resulting 912 in MPLS-to-IP forwarding operation. 914 This test case characterizes DUT's penultimate hop popping (PHP) 915 functionality. 917 Procedure 919 Please see Test Procedure in Section 6. Additionally, the test 920 tool must send frames containing MPLS packets on its transmit 921 ports Ap (with IP destination belonging to advertised IP 922 prefix(es)), and expect to receive frames containing IP packets on 923 its receive ports Bp, as described in Section 4.1.4.4. 925 Reporting Format 927 The result should be reported as per Section 5 and as per RFC2544. 929 Results for each test SHOULD be in the form of a table with a row 930 for each of the tested frame sizes. 932 6.2. Latency Measurement 934 This measures the time taken by the DUT to forward the MPLS packet 935 during various MPLS switching paths such as IP-to-MPLS or MPLS-to- 936 MPLS or MPLS-to-IP involving an MPLS label stack. 938 Objective 940 To obtain the average latency induced by the DUT during MPLS 941 packet forwarding for each of five forwarding operations. 943 Test Setup 945 Follow the Test Setup guidelines established for each of four MPLS 946 forwarding operations in Section 6.1.1 (for IP-to-MPLS), 6.1.2 947 (for MPLS-to-MPLS), 6.1.3 (for MPLS-to-IP Unlabeled), 6.1.4 (for 948 MPLS-to-IP Aggregate) and 6.1.5 (for MPLS-to-IP PHP) one by one. 950 Procedure 952 Please refer to Section 26.2 in RFC2544 in addition to following 953 the associated procedure for each MPLS forwarding operation in 954 accord with the Test Setup described earlier - 956 IP-to-MPLS forwarding (Imposition) Section 6.1.1 957 MPLS-to-MPLS forwarding (Swap) Section 6.1.2 958 MPLS-to-IP forwarding (Disposition) Section 6.1.3 959 MPLS-to-IP forwarding (Aggregate) Section 6.1.4 960 MPLS-to-IP forwarding (PHP) Section 6.1.5 962 Reporting Format 964 The result should be reported as per Section 5 and as per RFC2544. 966 6.3. Frame Loss Rate Measurement (FLR) 968 This measures the percentage of MPLS frames that were not forwarded 969 during various switching paths such as IP-to-MPLS (imposition) or 970 MPLS-to-IP (swap) or MPLS-IP (disposition) by the DUT under 971 overloaded state. 973 Please refer to RFC2544 Section 26.3 for more details. 975 Objective 977 To obtain the frame loss rate, as defined in RFC1242, for each of 978 three MPLS forwarding operations of a DUT, throughout the range of 979 input data rates and frame sizes. 981 Test Setup 983 Follow the Test Setup guidelines established for each of four MPLS 984 forwarding operations in Section 6.1.1 (for IP-to-MPLS), 6.1.2 985 (for MPLS-to-MPLS), 6.1.3 (for MPLS-to-IP Unlabeled), 6.1.4 (for 986 MPLS-to-IP Aggregate) and 6.1.5 (for MPLS-to-IP PHP) one by one. 988 Procedure 990 Please refer to Section 26.3 of RFC 2544 RFC2544 and follow the 991 associated procedure for each MPLS forwarding operation one-by-one 992 in accord with the Test Setup described earlier - 993 IP-to-MPLS forwarding (Imposition) Section 6.1.1 994 MPLS-to-MPLS forwarding (Swap) Section 6.1.2 995 MPLS-to-IP forwarding (Disposition) Section 6.1.3 996 MPLS-to-IP forwarding (Aggregate) Section 6.1.4 997 MPLS-to-IP forwarding (PHP) Section 6.1.5 999 Reporting Format 1001 The result should be reported as per Section 5 and as per RFC2544. 1003 6.4. System Recovery 1005 Objective 1007 To characterize the speed at which a DUT recovers from an overload 1008 condition. 1010 Test Setup 1012 Follow the Test Setup guidelines established for each of four MPLS 1013 forwarding operations in Section 6.1.1 (for IP-to-MPLS), 6.1.2 1014 (for MPLS-to-MPLS), 6.1.3 (for MPLS-to-IP Unlabeled), 6.1.4 (for 1015 MPLS-to-IP Aggregate) and 6.1.5 (for MPLS-to-IP PHP) one by one. 1017 Procedure 1019 Please refer to Section 26.5 of RFC2544 and follow the associated 1020 procedure for each MPLS forwarding operation in the referenced 1021 Sections one-by-one in accord with the Test Setup described 1022 earlier - 1024 IP-to-MPLS forwarding (Imposition) Section 6.1.1 1025 MPLS-to-MPLS forwarding (Swap) Section 6.1.2 1026 MPLS-to-IP forwarding (Disposition) Section 6.1.3 1027 MPLS-to-IP forwarding (Aggregate) Section 6.1.4 1028 MPLS-to-IP forwarding (PHP) Section 6.1.5 1030 Reporting Format 1032 The result should be reported as per Section 5 and as per RFC2544. 1034 6.5. Reset 1036 Objective 1038 To characterize the speed at which a DUT recovers from a device or 1039 software reset. 1041 Test Setup 1043 Follow the Test Setup guidelines established for each of four MPLS 1044 forwarding operations in Section 6.1.1 (for IP-to-MPLS), 6.1.2 1045 (for MPLS-to-MPLS), 6.1.3 (for MPLS-to-IP Unlabeled), 6.1.4 (for 1046 MPLS-to-IP Aggregate) and 6.1.5 (for MPLS-to-IP PHP) one by one. 1048 For this testcase, the requirements of LDP and a routing-protocol 1049 are removed and replaced by static configurations. For the IP-to- 1050 MPLS iteration, static route configurations should be applied. For 1051 the MPLS-to-MPLS and MPLS-to-IP static label configurations must 1052 be applied. 1054 For this test, all graceful-restart features MUST be disabled. 1056 Procedure 1058 Please refer to RFC2544 Section 26.5. Examples of hardware and 1059 software resets are: 1061 Hardware reset - forwarding module resetting (e.g. OIR). 1063 Software reset - reset initiated through a CLI (e.g. reload). 1065 Additionally, follow the specific Section for procedure (and test 1066 Setup) for each MPLS forwarding operation one-by-one - 1068 IP-to-MPLS forwarding (Imposition) Section 6.1.1 1069 MPLS-to-MPLS forwarding (Swap) Section 6.1.2 1070 MPLS-to-IP forwarding (Disposition) Section 6.1.3 1071 MPLS-to-IP forwarding (Aggregate) Section 6.1.4 1072 MPLS-to-IP forwarding (PHP) Section 6.1.5 1074 Reporting Format 1076 Same as RFC2544 and the parameters of Section 5 including the 1077 specific kind of reset performed. 1079 7. Security Considerations 1081 Benchmarking activities, as described in this memo, are limited to 1082 technology characterization using controlled stimuli in a laboratory 1083 environment, with dedicated address space and the constraints 1084 specified in the sections above. 1086 The benchmarking network topology will be an independent test setup 1087 and MUST NOT be connected to devices that may forward the test 1088 traffic into a production network or misroute traffic to the test 1089 management network. 1091 Furthermore, benchmarking is performed on a "black-box" basis, 1092 relying solely on measurements observable external to the DUT/SUT. 1094 Special capabilities SHOULD NOT exist in the DUT/SUT specifically 1095 for benchmarking purposes. Any implications for network security 1096 arising from the DUT/SUT SHOULD be identical in the lab and in 1097 production networks. 1099 There are no specific security considerations within the scope of 1100 this document. 1102 8. IANA Considerations 1104 There are no considerations for IANA at this time. 1106 9. Acknowledgement 1108 The authors would like to thank Mo Khalid, who motivated us to write 1109 this document. We would like to thank Rodney Dunn, Chip Popoviciu, 1110 Jeff Byzek, Jay Karthik, Rajiv Pap, Samir Vapiwala, Silvija Andrijic 1111 Dry, Scott Bradner, Al Morton and Bill Cerveny for their careful 1112 review and suggestions. 1114 This document was prepared using 2-Word-v2.0.template.dot. 1116 10. References 1118 10.1. Normative References 1120 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1121 Requirement Levels", BCP 14, RFC 2119, March 1997. 1123 [RFC2544] Bradner, S. and McQuaid, J., "Benchmarking Methodology for 1124 Network Interconnect Devices", RFC 2544, March 1999. 1126 [RFC1242] Bradner, S., Editor, "Benchmarking Terminology for Network 1127 Interconnection Devices", RFC 1242, July 1991. 1129 [RFC3031] Rosen et al., "Multiprotocol Label Switching 1130 Architecture", RFC 3031, August 1999. 1132 [RFC3032] Rosen et al., "MPLS Label Stack Encoding", RFC 3032, 1133 January 2001. 1135 [RFC3107] Rosen, E. and Rekhter, Y., "Carrying Label Information in 1136 BGP-4", RFC 3107, May 2001. 1138 [RFC5036] Andersson, L., Doolan, P., Feldman, N., Fredette, A. and 1139 B. Thomas, "LDP Specification", RFC 5036, January 2001. 1141 10.2. Informative References 1143 [RFC5180] Popoviciu, C., et al, "IPv6 Benchmarking Methodology for 1144 Network Interconnect Devices", RFC 5180, May 2008. 1146 [RFC3209] Awduche, et al., "RSVP-TE: Extensions to RSVP for LSP 1147 Tunnels", RFC 3209, Dec 2001. 1149 [RFC4364] Rosen E. and Rekhter Y., "BGP/MPLS IP Virtual Private 1150 Networks (VPNs)", RFC4364, February 2006. 1152 [RFC4271] Rekhter, Y. and T. Li, "Framework for Layer 2 Virtual 1153 Private Networks (L2VPNs)", RFC 4664, Sep 2006. 1155 [RFC4664] Rosen, E. and Andersson L., " A Border Gateway Protocol 4 1156 (BGP-4)", RFC 4271, Jan 2006. 1158 [IEE8021] Mick Seaman (editor), "IEEE Std 802.1D-2004, MAC Bridges", 1159 Feb 2004. 1161 [IEE8023] LAN/MAN Standards Committee of the IEEE Computer Society, 1162 "IEEE Std 802.3as-2006, Part 3: Carrier Sense Multiple 1163 Access with Collision Detection (CSMA/CD) Access Method 1164 and Physical Layer Specifications, Amendment 3: Frame 1165 format extensions", Nov 2006. 1167 [RFC3443] Agarwal, P. and Akyol, B., "Time To Live (TTL) Processing 1168 in MPLS Networks", RFC3443, Jan 2003. 1170 [RFC2328] Moy, J., "OSPF Version 2", RFC2328, April 1998. 1172 [RFC5462] Asati, R. and Andersson, L., "Multi-Protocol Label 1173 Switching (MPLS) label stack entry: "EXP" field renamed to 1174 "Traffic Class" field", RFC5462, Feb 2009. 1176 [RFC4928] Swallow, et al., "Avoiding Equal Cost Multipath Treatment 1177 in MPLS Networks", RFC4928, June 2007. 1179 [RFC4090] Pan, et al., "Fast Reroute Extensions to RSVP-TE for LSP 1180 Tunnels", RFC4090, May 2005. 1182 Author's Addresses 1184 Aamer Akhter 1185 Cisco Systems 1186 7025 Kit Creek Road 1187 RTP, NC 27709 1188 USA 1190 Email: aakhter@cisco.com 1191 Rajiv Asati 1192 Cisco Systems 1193 7025 Kit Creek Road 1194 RTP, NC 27709 1195 USA 1197 Email: rajiva@cisco.com 1199 Carlos Pignataro 1200 Cisco Systems 1201 7200-12 Kit Creek Road 1202 RTP, NC 27709 1203 USA 1205 Email: cpignata@cisco.com