idnits 2.17.1 draft-ietf-bmwg-mpls-forwarding-meth-05.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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document seems to contain a disclaimer for pre-RFC5378 work, and may have content which was first submitted before 10 November 2008. The disclaimer is necessary when there are original authors that you have been unable to contact, or if some do not wish to grant the BCP78 rights to the IETF Trust. If you are able to get all authors (current and original) to grant those rights, you can and should remove the disclaimer; otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (August 7, 2009) is 5375 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 (~~), 1 warning (==), 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: Feb, 2010 Rajiv Asati 6 Cisco Systems 8 Carlos Pignataro 9 Cisco Systems 11 August 7, 2009 13 MPLS Forwarding Benchmarking Methodology for IP Flows 14 draft-ietf-bmwg-mpls-forwarding-meth-05.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 Feb 7, 2010. 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 Push............................18 91 6.1.2. Throughput for MPLS Label Swap............................19 92 6.1.3. Throughput for MPLS Label Pop (Unlabeled).................20 93 6.1.4. Throughput for MPLS Label Pop (Aggregate).................21 94 6.1.5. Throughput for MPLS Label Pop (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...........................................28 101 9. Acknowledgement...............................................28 102 10. References...................................................29 103 10.1. Normative References.......................................29 104 10.2. Informative References.....................................29 105 Author's Addresses...............................................30 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, RIP etc. Furthermore, there 255 are testing considerations in this document that the device be able 256 to provide a stable control-plane during heavy forwarding workloads. 257 In particular, the procedures defined in section 11.3 of RFC2544 258 must be followed. This is to ensure that control plane instability 259 during load conditions is not the contributing factor towards frame 260 forwarding performance. 262 The route distribution method (OSPF, IS-IS, EIGRP, RIP, Static 263 etc.), if used, MUST be reported. Furthermore, if any specific 264 configuration is used to maintain control-plane stability during the 265 test (i.e. Control Plane Protection, Control Plane Rate Limiting, 266 etc.), then it MUST also be reported. 268 4.1.3. Label Distribution Support 270 The DUT and test tool must support at least one protocol for 271 exchanging MPLS label/FEC bindings for Prefix Forwarding Equivalence 272 Class (FEC) [RFC3031]. The DUT and test tool MUST be capable of 273 learning and advertising MPLS label/FEC bindings via the chosen 274 protocol(s), and use them during packet forwarding all the time 275 (including when the label/FEC bindings change). The most commonly 276 used protocols are Label Distribution Protocol (LDP) [RFC5036], 277 Resource Reservation Protocol-Traffic Engineering (RSVP-TE) 278 [RFC3209] and Border Gateway Protocol (BGP) [RFC3107]. 280 All of the ports (A1, DA1, DB1, B1 etc.) either on the DUT or the 281 test tool used in the testing SHOULD support LDP, RSVP-TE, and BGP 282 for IPv4 or IPv6 Prefix Forwarding Equivalence Classes (FECs). 284 This document does NOT recommend the use of static label to 285 establish the MPLS label switched paths (LSPs), unless specified 286 explicitly by the testcase. This is because the use of static label 287 is quite uncommon in the production networks. 289 4.1.4. Frame Formats 291 This section explains the frame formats for IP and MPLS packets 292 (Section 4.1.4.1), the usage of IP as the mandatory layer 3 protocol 293 and as the MPLS packet payload (Section 4.1.4.2), change in frame 294 format during forwarding (Section 4.1.4.3) and recommended frame 295 formats for the MPLS benchmarking (Section 4.1.4.4). 297 4.1.4.1. Frame format for IP vs. MPLS 299 A test frame carrying an IP packet is illustrated in the figure 1 300 below. Note that RFC2544 [RFC2544] prescribes using such a frame as 301 the test frame over the chosen layer 2 media. 303 +------------------------------------------------+ 304 | Layer 2 | Layer 3 = IP | Layer 4 = UDP | 305 +------------------------------------------------+ 307 Figure 1 Frame Format for IP packet 309 Unlike a test frame carrying an IP packet, a test frame carrying an 310 MPLS packet contains an 'MPLS label stack' [RFC3032] immediately 311 after the layer 2 header (and before the IP header, if any) as 312 illustrated in figure 2 below - 314 +--------------------------------------------------------+ 315 | Layer 2 | MPLS | Layer 3 = IP | Layer 4 = UDP | 316 +--------------------------------------------------------+ 318 Figure 2 Frame format for MPLS packet 320 The MPLS label stack is represented as a sequence of "label stack 321 entries", where each label stack entry is 4 bytes, as illustrated in 322 figure 1 of [RFC3032]. This document requires only a single entry in 323 the MPLS label stack in an MPLS packet. 325 MPLS label values used in any testcase MUST be outside the reserved 326 label value (0-15) unless stated otherwise. 328 4.1.4.2. MPLS packet payload 330 This document prescribes using IP packet as the MPLS payload (as 331 illustrated in figure 2 above). Generically speaking, this document 332 mandates the test frame to include IP (either IPv4 or IPv6) as the 333 layer 3 protocol, in accord with Section 8 of [RFC2544] and 334 independent of the MPLS label stack presence, for three reasons: 336 1) This enables using IP Prefix Forwarding Equivalence Class (FEC) 337 [RFC3031], which is a must for every MPLS network. 338 2) This provides the foundation or baseline for benchmarking of 339 various other MPLS applications such as L3VPN, L2VPN, TE-FRR etc. 340 3) This enables leveraging RFC2544 [RFC2544], which prescribes using 341 IP packet with UDP data as the test frames. (Note that [RFC5180] 342 also uses this prescription for IPv6 benchmarking). 344 While the usage of non-IP payloads is possible, it requires an MPLS 345 application e.g. L2VPN, whose benchmarking may be covered in 346 separate BMWG documents (MPLS L2VPN Benchmarking, for example) in 347 the future. This is also explained in Section 2. 349 4.1.4.3. Change in Frame Format due to MPLS Push and Pop 351 A frame carrying IP or MPLS packet may go through any of the three 352 MPLS forwarding operations: label push (or LSP Ingress), label swap 353 and label pop (or LSP Egress), as defined in [RFC3031]. It is 354 important to understand the change of the frame format from IP to 355 MPLS or vice versa depending on the forwarding operation. 357 In label push (or LSP ingress) operation, the DUT receives a frame 358 containing an IP packet and forwards a frame containing an MPLS 359 packet if the corresponding forwarding lookup for the IP destination 360 points to a label push operation. 362 In label swap operation, the DUT receives a frame containing an MPLS 363 packet and forwards a frame containing an MPLS packet if the 364 corresponding forwarding lookup for the label value points to a 365 label swap operation. 367 In label pop (or LSP egress) operation, the DUT receives a frame 368 containing an MPLS packet and forwards a frame containing an IP 369 packet if the corresponding forwarding lookup for the label value 370 points to a label pop operation. 372 4.1.4.4. Frame Formats to be used for Benchmarking 374 This document prescribes using two test frame formats to 375 appropriately test the forwarding operations: (1) Frame format for 376 IP and (2) Frame format for MPLS. Both formats are explained in 377 Section 4.1.3.1. Additionally, the format of the test frame may 378 change depending on the forwarding operation. 380 1. For testcases involving label push operation - the test tool must 381 use the frame format for IP packet (figure 1) to send the test 382 frames to the DUT, and must use the frame format for MPLS packet 383 (figure 2) to receive the test frames from the DUT. 385 2. For testcases involving label swap operation - the test tool must 386 use the frame format for MPLS packet (figure 2) to send the test 387 frames to the DUT, and must use the frame format for MPLS packet 388 (figure 2) to receive the test frames from the DUT. 390 3. For testcases involving label pop operation - the test tool must 391 use the frame format for MPLS packet (figure 2) to send the test 392 frames to the DUT, and must use the frame format for IP packet 393 (figure 1) to receive the test frames from the DUT. 395 4.1.5. Frame Sizes 397 Two types of port media are commonly deployed: Ethernet and POS 398 (Packet Over Synchronous Optical Network). This section identifies 399 the frame sizes that SHOULD be used for each media type, if 400 supported by the DUT. Section 4.1.4.1 covers Ethernet and 4.1.4.2 401 covers POS. 403 First, it is important to note the possible increase in frame size 404 due to the presence of an MPLS label stack in the frame (as 405 explained in the Section 4.1.3). 407 As observed in the current deployments, presence of an MPLS label 408 stack in a layer 2 frame is assumed to be transparent to layer3=IP, 409 which continues to follow the conventional maximum frame payload 410 size [RFC3032] (1500 bytes for ethernet, say). This means that the 411 effective maximum frame payload size [RFC3032] of the resulting 412 layer2 frame is Z bytes more than the conventional maximum frame 413 payload size, where Z = 4 x number of entries in the label stack. 415 Hence, to ensure successful delivery of layer2 frames carrying MPLS 416 packets and realistic benchmarking, it is recommended to set the 417 media MTU value to the effective maximum frame payload size 418 [RFC3032], which equals Z bytes + conventional maximum frame payload 419 size. It is expected that such a change in media MTU value only 420 impacts the effective Maximum Frame Payload Size for MPLS packets, 421 but not for IP packets. 423 Note that this document requires only a single entry in the MPLS 424 label stack in an MPLS packet. In other words, the depth of the 425 label stack is set to one e.g. Z = 4 x 1 = 4 bytes. 426 Furthermore, in accord with Section 9 and 9.1 of RFC2544, this 427 document prescribes that each testcase case is run with different 428 (layer 2) frame sizes in different trials. Additionally, results MAY 429 also be collected with multiple simultaneous frame sizes (sometimes 430 referred to as an IMIX to simulate real network traffic according to 431 the frame size ordering and usage). There is no standard for 432 mixtures of frame sizes, and the results are subject to wide 433 interpretation. See Section 18 of RFC 2544. When running trials 434 using multiple simultaneous frame sizes, the DUT configuration MUST 435 remain the same. 437 4.1.5.1. Frame Sizes to be used on Ethernet Media 439 Ethernet media, in all its types, has become the most commonly 440 deployed port media in MPLS networks. If any test case execution 441 (such as Label Push case) requires the testtool to send (or receive) 442 a layer2 frame containing an IP packet, then the following frame 443 sizes SHOULD be used for benchmarking over ethernet media: 64, 128, 444 256, 512, 1024, 1280 and 1518 bytes. This is in line with Section 9 445 and 9.1 of RFC2544. Figure 1 illustrates the header sizes for an 446 untagged ethernet frame containing an IP payload (per 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 Push 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 Pop cases) 469 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 Pop 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 Push testcases: 47, 64, 128, 256, 512, 1024, 1280, 1518, 513 2048 and 4096 bytes. 515 Label Swap and Pop testcases: 51, 68, 132, 260, 516, 1028, 1284, 516 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 pushed while others will require a swap or pop. Hence, this document 559 requires the test tool to verify the MPLS stack depth. An even 560 greater level of verification would be to check if the correct label 561 was pushed, 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 Push, Swap, Pop 586 IGP ISIS, OSPF, EIGRP, RIP, 587 static. 589 Throughput Frames per second and 590 Bits per second 592 Port Media GigE, POS, ATM etc. 594 Port Speed 1 gbps, 100 Mbps, etc. 596 Interface Encapsulation Ethernet, Ethernet VLAN, 597 PPP, HDLC etc. 599 Frame Size [See Section Bytes 600 4.1.3] 602 p (Number of {DA, DB} pair 1,2, etc. 603 ports per Figure 1) 605 The individual test cases may have additional reporting requirements 606 that may refer to other RFCs. 608 6. MPLS Forwarding Benchmarking Tests 610 MPLS is a different forwarding paradigm from IP. Unlike IP packet 611 and IP forwarding, an MPLS packet may contain more than one MPLS 612 header and may go through one of three forwarding operations : push 613 (or LSP ingress), swap or pop (or LSP egress), as defined in 614 [RFC3031]. Such characteristics desire further granularity in MPLS 615 forwarding benchmarking than those described in RFC2544. Thus the 616 benchmarking may include, but not limited to: 618 1. Throughput 620 2. Latency 622 3. Frame Loss rate 624 4. System Recovery 626 5. Reset 628 6. MPLS TC (previously known as EXP [RFC5462]) field Operations 629 (including explicit-null cases) 631 7. Negative Scenarios (TTL expiry, etc) 633 8. Multicast 635 However, this document focuses only on the first five categories, 636 inline with the spirit of RFC2544. All the benchmarking test cases 637 described in this document are expected to, at a minimum, follow the 638 'Test Setup' and 'Test Procedure' below - 640 Test Setup 642 Referring to Figure 1, a single port (p = 1) on both A and B 643 Modules SHOULD be used. However, if the forwarding throughput of 644 the DUT is more than that of the media rate of a single port, then 645 additional ports on A and B Modules MUST be enabled so as to 646 exceed the DUT's forwarding throughput. In such a case, the 647 procedures described in Section 16 of RFC2544 must be followed to 648 accommodate the multi-port scenario. The frame formats transmitted 649 and received must be in accord with Section 4.1.4.3 and 4.1.4.4, 650 and frame sizes must be in accord with in Section 4.1.5. 652 Note - The test tool must be configured to not advertise a prefix 653 or FEC to the DUT on more than one port. In other words, the DUT 654 must associate a FEC with one and only one DB port. The Equal Cost 655 Multi-Path (ECMP) behavior in MPLS networks uses heuristics 656 [RFC4928], hence, the usage of ECMP is NOT permitted by this 657 document to ensure the deterministic forwarding behavior during 658 the benchmarking. 660 Test Procedure 662 In accord with Section 26 of RFC2544 [RFC2544], the traffic is 663 sent from test tool port(s) Ap to the DUT at a constant load for a 664 fixed time interval, and is received from the DUT on test tool 665 port(s) Bp. The frame may contain either an IP packet or an MPLS 666 packet depending on the testcase need, as described in 667 Section 4.1.4.3. Furthermore, the IP packet must be either an IPv4 668 or IPv6 packet, depending on whether the MPLS benchmarking is done 669 for IPv4 or IPv6. 671 If any frame loss is detected, then a new iteration is needed 672 where the offered load is decreased and the sender will transmit 673 again. An iterative search algorithm MUST be used to determine the 674 maximum offered frame rate with a zero frame loss. 676 This maximum offered frame rate that results in zero frame loss 677 through the DUT is defined as the Throughput in Section 3.17 of 678 [RFC1242] for that test case. Informally, this rate is referred to 679 as the No Drop Rate. 681 Each iteration should involve varying the offered load of the 682 traffic, while keeping the other parameters (test duration, number 683 of ports, number of addresses, frame size etc) constant, until the 684 maximum rate at which none of the offered frames are dropped is 685 determined. 687 6.1. Throughput 689 This Section contains the description of the tests that are related 690 to the characterization of DUT's MPLS traffic forwarding. 692 6.1.1. Throughput for MPLS Label Push 694 Objective 696 To obtain the DUT's Throughput (as per RFC 2544) during label push 697 or LSP Ingress forwarding operation (i.e. IP to MPLS). 699 Test Setup 701 In addition to the test setup described in Section 6, the test 702 tool must advertise the IP prefix(es) i.e. RNx (using a routing 703 protocol as per Section 4.1.2) and associated MPLS label-FEC 704 binding(s) (using a label distribution protocol as per Section 705 4.1.3) on its receive ports Bp to DUT. The test tool may learn the 706 IP prefix(es) on it's transmit ports Ap from DUT. 708 MPLS and/or label distribution protocol must be enabled only on 709 the test tool receive ports Bp and DUT transmit ports DBp. 711 Discussion 713 The DUT's MPLS forwarding table (also referred to as FEC-to-NHLFE 714 (FTN) mapping table per [RFC3031]) must contain a non-reserved 715 MPLS label value as the outgoing label for each learned IP prefix 716 corresponding to the label-FEC binding, resulting in DUT 717 performing the IP-to-MPLS forwarding operation. The test tool must 718 receive MPLS packets on receive ports Bp (from DUT) with the same 719 label values that were advertised. 721 Procedure 723 Please see Test Procedure in Section 6. Additionally, the test 724 tool MUST send the frames containing IP packets (with IP 725 destination belonging to the advertised IP prefix(es)) on transmit 726 ports Ap, and expect to receive frames containing MPLS packets on 727 receive ports Bp, as described in Section 4.1.4.4. 729 Reporting Format 730 The result should be reported as per Section 5 and as per RFC2544. 732 Results for each test SHOULD be in the form of a table with a row 733 for each of the tested frame sizes. Additional columns SHOULD 734 include: offered load and measured throughput. 736 6.1.2. Throughput for MPLS Label Swap 738 Objective 740 To obtain the DUT's Throughput (as per RFC 2544) during label 741 swapping operation (i.e. MPLS to MPLS). 743 Test Setup 745 In addition to setup described in Section 6, the test tool must 746 advertise IP prefix(es) (using a routing protocol as per Section 747 4.1.2) and associated MPLS label-FEC bindings (using a label 748 distribution protocol as per Section 4.1.3) on the receive ports 749 Bp, and then learn the IP prefix(es) as well as the label-FEC 750 binding(s) on the transmit ports Ap. The test tool must use the 751 learned MPLS label values and learned IP prefix values in the 752 frames transmitted on ports Ap to DUT. 754 MPLS and/or label distribution protocol must be enabled on the 755 test tool ports Bp and Ap, and DUT ports DBp and DAp. 757 Discussion 759 The DUT's MPLS forwarding table (also referred to as FEC-to-NHLFE 760 (FTN) mapping table per [RFC3031]) must contain non-reserved MPLS 761 label values as the outgoing and incoming labels for the learned 762 IP prefixes, resulting in MPLS-to-MPLS forwarding operation e.g. 763 label swap. The test tool must receive MPLS packets on receive 764 ports Bp (from DUT) with the same label values that were 765 advertised using the label distribution protocol. The received 766 frames must contain the same number of MPLS headers as those of 767 transmitted frames. 769 Procedure 771 Please see Test Procedure in Section 6. Additionally, the test 772 tool must send frames containing MPLS packets (with IP destination 773 belonging to the advertised IP prefix(es)) on it's transmit ports 774 Ap, and expect to receive frames containing MPLS packets on its 775 receive ports Bp, as described in Section 4.1.4.4. 777 Reporting Format 779 The result should be reported as per Section 5 and as per RFC2544. 781 Results for each test SHOULD be in the form of a table with a row 782 for each of the tested frame sizes. 784 6.1.3. Throughput for MPLS Label Pop (Unlabeled) 786 Objective 788 To obtain the DUT's Throughput (as per RFC 2544) during label pop 789 or LSP Egress forwaridng operation (i.e. MPLS to IP) using 790 ''Unlabeled'' outgoing label. 792 Test Setup 794 In addition to setup described in Section 6, the test tool must 795 advertise the IP prefix(es) (using a routing protocol as per 796 Section 4.1.2) without any MPLS label-FEC bindings on the receive 797 ports Bp, and then learn the IP prefix(es) as well as the FEC- 798 label binding(s) on the transmit ports Ap. The test tool must use 799 the learned MPLS label values and learned IP prefix values in the 800 frames transmitted on ports Ap. 802 MPLS and/or label distribution protocol must be enabled only on 803 the test tool port(s) Ap and DUT port(s) DAp. 805 Discussion 807 The DUT's MPLS forwarding table (also referred to as FEC-to-NHLFE 808 (FTN) mapping table per [RFC3031]) must contain an Unlabeled 809 outgoing label (also known as untagged) for the learned IP prefix, 810 resulting in MPLS-to-IP forwarding operation. 812 Procedure 814 Please see Test Procedure in Section 6. Additionally, the test 815 tool must send frames containing MPLS packets on its transmit 816 ports Ap (with IP destination belonging to the IP prefix(es) 817 advertised on port Bp), and expect to receive frames containing IP 818 packets on its receive ports Bp, as described in Section 4.1.4.4. 820 Reporting Format 822 The result should be reported as per Section 5 and as per RFC2544. 824 Results for each test SHOULD be in the form of a table with a row 825 for each of the tested frame sizes. 827 6.1.4. Throughput for MPLS Label Pop (Aggregate) 829 Objective 831 To obtain the DUT's Throughput (as per RFC 2544) during label pop 832 or LSP Egress forwarding operation (i.e. MPLS to IP) using 833 ''Aggregate'' outgoing label[RFC3031]. 835 Test Setup 837 In addition to setup described in Section 6, the DUT must be 838 provisioned such that it allocates an aggregate outgoing label 839 (please see Section 3.20 in [RFC3031]) to an IP prefix, which 840 aggregates a set of prefixes learned on ports DBp from the test 841 tool. The prefix aggregation can be performed using BGP 842 aggregation (Section 9.2.2.2 of [RFC4271]), IGP aggregation 843 (Section 16.5 of [RFC2328]), etc.). 845 The DUT must advertise the aggregating IP prefix along with the 846 associated MPLS label-FEC binding on ports DAp to the test tool. 848 The test tool then must use the learned MPLS label values and 849 learned IP prefix values in frames transmitted on ports Ap to the 850 DUT. The test tool must receive frames containing IP packets on 851 ports Bp from the DUT. 853 MPLS and/or label distribution protocol must be enabled only on 854 the test tool port(s) Ap and DUT port(s) DAp. 856 Discussion 858 The DUT's MPLS forwarding table (also referred to as FEC-to-NHLFE 859 (FTN) mapping table per [RFC3031]) must contain an aggregate 860 outgoing label and IP forwarding table must contain a valid entry 861 for the learned prefix(es), resulting in MPLS-to-IP forwarding 862 operation (i.e. MPLS header removal followed by IP lookup). 864 Procedure 865 Please see Test Procedure in Section 6. Additionally, the test 866 tool must send frames containing MPLS packets on its transmit 867 ports Ap (with IP destination belonging to the IP prefix(es) 868 advertised on port Bp), and expect to receive frames containing IP 869 packets on its receive ports Bp, as described in Section 4.1.4.4. 871 Reporting Format 873 The result should be reported as per Section 5 and as per RFC2544. 875 Results for each test SHOULD be in the form of a table with a row 876 for each of the tested frame sizes. 878 6.1.5. Throughput for MPLS Label Pop (PHP) 880 Objective 882 To obtain the DUT's Throughput (as per RFC 2544) during label pop 883 (i.e. MPLS to IP) or penultimate hop popping (PHP) using ''imp- 884 null'' outgoing label. 886 Test Setup 888 In addition to setup described in Section 6, the test tool must be 889 set up to advertise the IP prefix(es) (using a routing protocol as 890 per Section 4.1.2) and associated MPLS label-FEC binding with a 891 reserved MPLS label value = 3 (using a label distribution protocol 892 as per Section 4.1.3) on its receive ports Bp. The test tool must 893 learn the IP prefix(es) as well as the MPLS label-FEC bindings on 894 its transmit ports Ap. The test tool then must use the learned 895 MPLS label values and learned IP prefix values in the frames 896 transmitted on ports Ap to DUT. The test tool must receive frames 897 containing IP packets on receive ports Bp (from DUT). 899 MPLS and/or label distribution protocol must be enabled on the 900 test tool ports Bp and Ap, and DUT ports DBp and DAp. 902 Discussion 904 This test case characterizes the Penultimate Hop Popping (PHP), 905 which is described in RFC3031. 907 The DUT's MPLS forwarding table (also referred to as FEC-to- 908 Next_Hop_Label_Forwarding_Entry (FTN) mapping table per [RFC3031]) 909 must contain a reserved MPLS label value = 3 (e.g. pop or imp- 910 null) as the outgoing label for the learned prefix(es), resulting 911 in MPLS-to-IP forwarding operation. 913 This test case characterizes DUT's penultimate hop popping (PHP) 914 functionality. 916 Procedure 918 Please see Test Procedure in Section 6. Additionally, the test 919 tool must send frames containing MPLS packets on its transmit 920 ports Ap (with IP destination belonging to advertised IP 921 prefix(es)), and expect to receive frames containing IP packets on 922 its receive ports Bp, as described in Section 4.1.4.4. 924 Reporting Format 926 The result should be reported as per Section 5 and as per RFC2544. 928 Results for each test SHOULD be in the form of a table with a row 929 for each of the tested frame sizes. 931 6.2. Latency Measurement 933 This measures the time taken by the DUT to forward the MPLS packet 934 during various MPLS switching paths such as IP-to-MPLS or MPLS-to- 935 MPLS or MPLS-to-IP involving an MPLS label stack. 937 Objective 939 To obtain the average latency induced by the DUT during MPLS 940 packet forwarding for each of five forwarding operations. 942 Test Setup 944 Follow the Test Setup guidelines established for each of four MPLS 945 forwarding operations in Section 6.1.1 (for IP-to-MPLS), 6.1.2 946 (for MPLS-to-MPLS), 6.1.3 (for MPLS-to-IP Unlabeled), 6.1.4 (for 947 MPLS-to-IP Aggregate) and 6.1.5 (for MPLS-to-IP PHP) one by one. 949 Procedure 951 Please refer to Section 26.2 in RFC2544 in addition to following 952 the associated procedure for each MPLS forwarding operation in 953 accord with the Test Setup described earlier - 955 IP-to-MPLS forwarding (Push) Section 6.1.1 956 MPLS-to-MPLS forwarding (Swap) Section 6.1.2 957 MPLS-to-IP forwarding (Pop) Section 6.1.3 958 MPLS-to-IP forwarding (Aggregate) Section 6.1.4 959 MPLS-to-IP forwarding (PHP) Section 6.1.5 961 Reporting Format 963 The result should be reported as per Section 5 and as per RFC2544. 965 6.3. Frame Loss Rate Measurement (FLR) 967 This measures the percentage of MPLS frames that were not forwarded 968 during various switching paths such as IP-to-MPLS (push) or MPLS-to- 969 IP (swap) or MPLS-IP (pop) by the DUT under overloaded state. 971 Please refer to RFC2544 Section 26.3 for more details. 973 Objective 975 To obtain the frame loss rate, as defined in RFC1242, for each of 976 three MPLS forwarding operations of a DUT, throughout the range of 977 input data rates and frame sizes. 979 Test Setup 981 Follow the Test Setup guidelines established for each of four MPLS 982 forwarding operations in Section 6.1.1 (for IP-to-MPLS), 6.1.2 983 (for MPLS-to-MPLS), 6.1.3 (for MPLS-to-IP Unlabeled), 6.1.4 (for 984 MPLS-to-IP Aggregate) and 6.1.5 (for MPLS-to-IP PHP) one by one. 986 Procedure 988 Please refer to Section 26.3 of RFC 2544 RFC2544 and follow the 989 associated procedure for each MPLS forwarding operation one-by-one 990 in accord with the Test Setup described earlier - 991 IP-to-MPLS forwarding (Push) Section 6.1.1 992 MPLS-to-MPLS forwarding (Swap) Section 6.1.2 993 MPLS-to-IP forwarding (Pop) Section 6.1.3 994 MPLS-to-IP forwarding (Aggregate) Section 6.1.4 995 MPLS-to-IP forwarding (PHP) Section 6.1.5 997 Reporting Format 999 The result should be reported as per Section 5 and as per RFC2544. 1001 6.4. System Recovery 1003 Objective 1005 To characterize the speed at which a DUT recovers from an overload 1006 condition. 1008 Test Setup 1010 Follow the Test Setup guidelines established for each of five MPLS 1011 forwarding operations in Section 6.1.1 (for IP-to-MPLS), 6.1.2 1012 (for MPLS-to-MPLS), 6.1.3 (for MPLS-to-IP Unlabeled), 6.1.4 (for 1013 MPLS-to-IP Aggregate) and 6.1.5 (for MPLS-to-IP PHP) one by one. 1015 Procedure 1017 Please refer to Section 26.5 of RFC2544 and follow the associated 1018 procedure for each MPLS forwarding operation in the referenced 1019 Sections one-by-one in accord with the Test Setup described 1020 earlier - 1022 IP-to-MPLS forwarding (Push) Section 6.1.1 1023 MPLS-to-MPLS forwarding (Swap) Section 6.1.2 1024 MPLS-to-IP forwarding (Pop) Section 6.1.3 1025 MPLS-to-IP forwarding (Aggregate) Section 6.1.4 1026 MPLS-to-IP forwarding (PHP) Section 6.1.5 1028 Reporting Format 1030 The result should be reported as per Section 5 and as per RFC2544. 1032 6.5. Reset 1034 Note that BMWG plans to produce a separate document focusing on 1035 'reset' aspects of benchmarking in order to ensure clarity and 1036 consistency in reset procedures beyond what's specified in 1037 RFC2544. 1039 This document does not specify the reset procedures. The text 1040 below describes the MPLS forwarding benchmarking specific setup 1041 that will have to be used in conjuction with the procedures from 1042 the separate document to make this test case meaningful. 1044 Objective 1046 To characterize the speed at which a DUT recovers from a device or 1047 software reset. 1049 Test Setup 1051 Follow the Test Setup guidelines established for each of four MPLS 1052 forwarding operations in Section 6.1.1 (for IP-to-MPLS), 6.1.2 1053 (for MPLS-to-MPLS), 6.1.3 (for MPLS-to-IP Unlabeled), 6.1.4 (for 1054 MPLS-to-IP Aggregate) and 6.1.5 (for MPLS-to-IP PHP) one by one. 1056 For this testcase, the requirements of LDP and a routing-protocol 1057 are removed and replaced by static configurations. For the IP-to- 1058 MPLS iteration, static route configurations should be applied. For 1059 the MPLS-to-MPLS and MPLS-to-IP static label configurations must 1060 be applied. 1062 For this test, all graceful-restart features MUST be disabled. 1064 Discussion 1066 This test case is intended to provide an insight into how long an 1067 MPLS device could take to be fully operational after any of the 1068 reset events. It is quite likely that the time an IP/MPLS device 1069 takes to become fully operational after any of the reset events 1070 may be different from that of an IP only device. 1072 Modern devices now have many more reset options that were not 1073 available when section 26.6 of RFC2544 was published. Moreover, 1074 different reset events on modern devices may produce different 1075 results, hence, needing clarity and consistency in reset 1076 procedures beyond what's specified in RFC2544. 1078 Procedure 1080 Please follow the procedure from the separate document for each 1081 MPLS forwarding operation one-by-one - 1083 IP-to-MPLS forwarding (Push) Section 6.1.1 1084 MPLS-to-MPLS forwarding (Swap) Section 6.1.2 1085 MPLS-to-IP forwarding (Pop) Section 6.1.3 1086 MPLS-to-IP forwarding (Aggregate) Section 6.1.4 1087 MPLS-to-IP forwarding (PHP) Section 6.1.5 1089 Reporting Format 1091 The result should be reported as per section 5 and as per the 1092 separate document. 1094 7. Security Considerations 1096 Benchmarking activities, as described in this memo, are limited to 1097 technology characterization using controlled stimuli in a laboratory 1098 environment, with dedicated address space and the constraints 1099 specified in the sections above. 1101 The benchmarking network topology will be an independent test setup 1102 and MUST NOT be connected to devices that may forward the test 1103 traffic into a production network or misroute traffic to the test 1104 management network. 1106 Furthermore, benchmarking is performed on a "black-box" basis, 1107 relying solely on measurements observable external to the DUT/SUT. 1109 Special capabilities SHOULD NOT exist in the DUT/SUT specifically 1110 for benchmarking purposes. Any implications for network security 1111 arising from the DUT/SUT SHOULD be identical in the lab and in 1112 production networks. 1114 There are no specific security considerations within the scope of 1115 this document. 1117 8. IANA Considerations 1119 There are no considerations for IANA at this time. 1121 9. Acknowledgement 1123 The authors would like to thank Mo Khalid, who motivated us to write 1124 this document. We would like to thank Rodney Dunn, Chip Popoviciu, 1125 Jeff Byzek, Jay Karthik, Rajiv Papneja, Samir Vapiwala, Silvija 1126 Andrijic Dry, Scott Bradner, Al Morton and Bill Cerveny for their 1127 careful review and suggestions. 1129 This document was prepared using 2-Word-v2.0.template.dot. 1131 10. References 1133 10.1. Normative References 1135 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1136 Requirement Levels", BCP 14, RFC 2119, March 1997. 1138 [RFC2544] Bradner, S. and McQuaid, J., "Benchmarking Methodology for 1139 Network Interconnect Devices", RFC 2544, March 1999. 1141 [RFC1242] Bradner, S., Editor, "Benchmarking Terminology for Network 1142 Interconnection Devices", RFC 1242, July 1991. 1144 [RFC3031] Rosen et al., ''Multiprotocol Label Switching 1145 Architecture'', RFC 3031, August 1999. 1147 [RFC3032] Rosen et al., ''MPLS Label Stack Encoding'', RFC 3032, 1148 January 2001. 1150 [RFC3107] Rosen, E. and Rekhter, Y., ''Carrying Label Information in 1151 BGP-4'', RFC 3107, May 2001. 1153 [RFC5036] Andersson, L., Doolan, P., Feldman, N., Fredette, A. and 1154 B. Thomas, "LDP Specification", RFC 5036, January 2001. 1156 10.2. Informative References 1158 [RFC5180] Popoviciu, C., et al, "IPv6 Benchmarking Methodology for 1159 Network Interconnect Devices", RFC 5180, May 2008. 1161 [RFC3209] Awduche, et al., "RSVP-TE: Extensions to RSVP for LSP 1162 Tunnels", RFC 3209, Dec 2001. 1164 [RFC4364] Rosen E. and Rekhter Y., "BGP/MPLS IP Virtual Private 1165 Networks (VPNs)", RFC4364, February 2006. 1167 [RFC4271] Rekhter, Y. and T. Li, "Framework for Layer 2 Virtual 1168 Private Networks (L2VPNs)'', RFC 4664, Sep 2006. 1170 [RFC4664] Rosen, E. and Andersson L., " A Border Gateway Protocol 4 1171 (BGP-4)'', RFC 4271, Jan 2006. 1173 [IEE8021] Mick Seaman (editor), "IEEE Std 802.1D-2004, MAC Bridges", 1174 Feb 2004. 1176 [IEE8023] LAN/MAN Standards Committee of the IEEE Computer Society, 1177 "IEEE Std 802.3as-2006, Part 3: Carrier Sense Multiple 1178 Access with Collision Detection (CSMA/CD) Access Method 1179 and Physical Layer Specifications, Amendment 3: Frame 1180 format extensions", Nov 2006. 1182 [RFC3443] Agarwal, P. and Akyol, B., "Time To Live (TTL) Processing 1183 in MPLS Networks", RFC3443, Jan 2003. 1185 [RFC2328] Moy, J., "OSPF Version 2", RFC2328, April 1998. 1187 [RFC5462] Asati, R. and Andersson, L., "Multi-Protocol Label 1188 Switching (MPLS) label stack entry: "EXP" field renamed to 1189 ''Traffic Class'' field", RFC5462, Feb 2009. 1191 [RFC4928] Swallow, et al., "Avoiding Equal Cost Multipath Treatment 1192 in MPLS Networks", RFC4928, June 2007. 1194 [RFC4090] Pan, et al., "Fast Reroute Extensions to RSVP-TE for LSP 1195 Tunnels", RFC4090, May 2005. 1197 Author's Addresses 1199 Aamer Akhter 1200 Cisco Systems 1201 7025 Kit Creek Road 1202 RTP, NC 27709 1203 USA 1205 Email: aakhter@cisco.com 1206 Rajiv Asati 1207 Cisco Systems 1208 7025 Kit Creek Road 1209 RTP, NC 27709 1210 USA 1212 Email: rajiva@cisco.com 1214 Carlos Pignataro 1215 Cisco Systems 1216 7200-12 Kit Creek Road 1217 RTP, NC 27709 1218 USA 1220 Email: cpignata@cisco.com