idnits 2.17.1 draft-ietf-bmwg-mpls-forwarding-meth-04.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 first octets (the first characters of the first line) of this draft are 'BM', which can make the draft submission tool erroneously think that it is an image .bmp file. It is recommended that you change this, for instance by inserting a blank line before the line starting with 'BM'. == 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 (July 9, 2009) is 5404 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 (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 BMWG Aamer Akhter 2 Internet Draft Cisco Systems 3 Intended status: Informational 4 Expires: January 9, 2009 Rajiv Asati 5 Cisco Systems 7 Carlos Pignataro 8 Cisco Systems 10 July 9, 2009 12 MPLS Forwarding Benchmarking Methodology for IP Flows 13 draft-ietf-bmwg-mpls-forwarding-meth-04.txt 15 Status of this Memo 17 This Internet-Draft is submitted to IETF in full conformance with 18 the provisions of BCP 78 and BCP 79. This document may contain 19 material from IETF Documents or IETF Contributions published or made 20 publicly available before November 10, 2008. The person(s) 21 controlling the copyright in some of this material may not have 22 granted the IETF Trust the right to allow modifications of such 23 material outside the IETF Standards Process. Without obtaining an 24 adequate license from the person(s) controlling the copyright in 25 such materials, this document may not be modified outside the IETF 26 Standards Process, and derivative works of it may not be created 27 outside the IETF Standards Process, except to format it for 28 publication as an RFC or to translate it into languages other than 29 English 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF), its areas, and its working groups. Note that 33 other groups may also distribute working documents as Internet- 34 Drafts. 36 Internet-Drafts are draft documents valid for a maximum of six 37 months and may be updated, replaced, or obsoleted by other documents 38 at any time. It is inappropriate to use Internet-Drafts as 39 reference material or to cite them other than as "work in progress." 41 The list of current Internet-Drafts can be accessed at 42 http://www.ietf.org/ietf/1id-abstracts.txt 44 The list of Internet-Draft Shadow Directories can be accessed at 45 http://www.ietf.org/shadow.html 47 This Internet-Draft will expire on October 9, 2009. 49 Copyright Notice 51 Copyright (c) 2009 IETF Trust and the persons identified as the 52 document authors. All rights reserved. 54 This document is subject to BCP 78 and the IETF Trust's Legal 55 Provisions Relating to IETF Documents in effect on the date of 56 publication of this document (http://trustee.ietf.org/license-info). 57 Please review these documents carefully, as they describe your 58 rights and restrictions with respect to this document. 60 Abstract 62 This document describes a methodology specific to the benchmarking 63 of Multi-Protocol Label Switching (MPLS) forwarding devices, limited 64 to the most common MPLS packet forwarding scenarios and delay 65 measurements for each, considering IP flows. It builds upon the 66 tenets set forth in RFC2544, RFC1242 and other IETF Benchmarking 67 Methodology Working Group (BMWG) efforts. This document seeks to 68 extend these efforts to the MPLS paradigm. 70 Table of Contents 72 1. Introduction...................................................3 73 2. Document Scope.................................................4 74 3. Key Words to Reflect Requirements..............................5 75 4. Test Methodology...............................................5 76 4.1. Test Considerations..........................................6 77 4.1.1. Abbreviations Used.........................................6 78 4.1.2. IGP Support................................................7 79 4.1.3. Label Distribution Support.................................7 80 4.1.4. Frame Formats..............................................8 81 4.1.5. Frame Sizes...............................................10 82 4.1.6. Time-to-Live (TTL) or Hop Limit...........................13 83 4.1.7. Trial Duration............................................13 84 4.1.8. Traffic Verification......................................14 85 4.1.9. Address Resolution and Dynamic Protocol State.............14 86 5. Reporting Format..............................................15 87 6. MPLS Forwarding Benchmarking Tests............................16 88 6.1. Throughput..................................................18 89 6.1.1. Throughput for MPLS Label Push............................18 90 6.1.2. Throughput for MPLS Label Swap............................19 91 6.1.3. Throughput for MPLS Label Pop (Unlabeled).................20 92 6.1.4. Throughput for MPLS Label Pop (Aggregate).................21 93 6.1.5. Throughput for MPLS Label Pop (PHP).......................22 94 6.2. Latency Measurement.........................................23 95 6.3. Frame Loss Rate Measurement (FLR)...........................24 96 6.4. System Recovery.............................................25 97 6.5. Reset.......................................................26 98 7. Security Considerations.......................................27 99 8. IANA Considerations...........................................27 100 9. Acknowledgement...............................................28 101 10. References...................................................29 102 10.1. Normative References.......................................29 103 10.2. Informative References.....................................29 104 Author's Addresses...............................................30 106 1. Introduction 108 Over the past several years, there has been an increase in the use 109 of MPLS as a forwarding architecture in new and existing network 110 designs. MPLS, defined in [RFC3031], is a foundation technology and 111 basis for many advanced technologies such as Layer 3 MPLS-VPNs, 112 Layer 2 MPLS-VPNs, and MPLS Traffic-Engineering. 114 However, there is no standard method defined to compare and contrast 115 the foundational MPLS packet forwarding capabilities of network 116 devices. This document proposes a methodology using common criteria 117 (such as throughput, latency, frame loss rate, system recovery, 118 reset etc.) to evaluate MPLS forwarding of any implementation. 120 2. Document Scope 122 The benchmarking methodology principles outlined in RFC2544 123 [RFC2544] are independent of forwarding techniques, however, they 124 don't fully address MPLS benchmarking. The fact that MPLS forwarding 125 places a different burden on the resources of the network forwarding 126 devices from that of IP forwarding, MPLS forwarding benchmarking 127 specifics are desired. 129 The purpose of this document is to describe a methodology specific 130 to the benchmarking of MPLS forwarding devices. The methods 131 described are limited in scope to the most common MPLS packet 132 forwarding scenarios and corresponding performance measurements in a 133 laboratory setting. It builds upon the tenets set forth in RFC2544 134 [RFC2544], RFC1242 [RFC1242] and other IETF Benchmarking Methodology 135 Working Group (BMWG) efforts. In other words, this document is not a 136 replacement for, but a complement to, RFC 2544. 138 This document focuses on the MPLS label stack [RFC3032] having only 139 one entry, as it is the fundamental of MPLS forwarding. It is 140 expected that future documents may cover the benchmarking of MPLS 141 applications such as L3VPN [RFC4364], L2VPN [RFC4664], Fast ReRoute 142 [RFC4090] etc., which require more than one entry in the MPLS label 143 stack. 145 Moreover, to address the majority of current deployments' needs, 146 this document focuses on having IP packets as the MPLS payload. In 147 other words, label distribution for IP Forwarding Equivalence Class 148 (FEC)[RFC3031] is prescribed (see Section 4.1.2) by this document. 149 It is expected that future documents may focus on having non-IP 150 packets as the MPLS payload. 152 Note that the presence of an MPLS label stack does not require the 153 length of MPLS payload (which is an IP packet, per this document) to 154 be changed, hence, the effective maximum size of a frame can 155 increase by Z bytes (where Z = 4 x number of label stack entries), 156 as observed in current deployments. This document focuses on 157 benchmarking such a scenario. 159 3. Key Words to Reflect Requirements 161 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 162 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 163 document are to be interpreted as described in BCP 14, RFC 2119 164 [RFC2119]. RFC 2119 defines the use of these key words to help make 165 the intent of standards track documents as clear as possible. While 166 this document uses these keywords, this document is not a standards 167 track document. 169 4. Test Methodology 171 The set of methodologies described in this document will use the 172 topology described in this section. An effort has been made to 173 exclude superfluous equipment needs such that each test can be 174 carried out with a minimal number of devices.Figure 1 illustrates 175 the sample topology in which the Device Under Test (DUT) is 176 connected to the test ports on the test tool in accord with the Fig 177 1 of RFC2544 - 179 +-----------------+ 180 +---------+ | | +---------+ 181 | Test | | | | Test | 182 | Port A1 +-----+ DA1 DB1 -----+ Port B1 | 183 +---------+ | | +---------+ 184 +---------+ | DUT | +---------+ 185 | Test | | | | Test | 186 | Port A2 +-----+ DA2 DB2 +-----+ Port B2 | 187 +---------+ | | +---------+ 188 ... | | ... 189 +---------+ | | +---------+ 190 | Test | +-----------------+ | Test | 191 | Port Ap | | Port Bp | 192 +---------+ +---------+ 194 Figure 1 Topology for MPLS Forwarding Benchmarking 196 A represents a Tx-side Module of the test tool, whereas B represents 197 an Rx-side Module of the same test tool. Of course, the suffixed 198 numbers (1, 2...p) represent ports on a Module. 200 Similarly, DA represents an Rx-side Module of the DUT, whereas DB 201 represents Tx-side Module. The suffixed numbers (1, 2...p) represent 202 ports on a Module. 204 p = number of {DA, DB} pair ports on DUT. It is determined by the 205 maximum unidirectional forwarding throughput of the DUT and the load 206 capacity of the port media (e.g. interface) connecting the DUT to 207 the test tool. 209 For example, if the DUT's maximum forwarding throughput is 100 210 frames per second (fps), and the load capacity of the port media 211 (e.g. interface) is 50 fps, then p => 2 is needed to sufficiently 212 test the maximum frame forwarding. 214 The exact throughput is a measured quantity obtained through 215 testing. Throughput may vary depending on the number of ports used, 216 and other factors. The number of ports (p) used SHOULD be reported. 217 Please see Test Setup in Section 6, and recommended to follow Fig 1 218 from S6 of RFC2544. 220 4.1. Test Considerations 222 This methodology assumes a full-duplex uniform medium topology. The 223 medium used MUST be reported in each test result. Issues regarding 224 mixed transmission media, speed mismatches, media header differences 225 etc, are not under consideration. Traffic affecting features such as 226 Flow control, QoS, Graceful Restart etc. MUST be disabled, unless 227 explicitly requested in the test case. Additionally, any non- 228 essential traffic MUST also be avoided. 230 4.1.1. Abbreviations Used 232 The terms used in this document remain consistent with those defined 233 in "Benchmarking Terminology for Network Interconnect Devices" 234 RFC1242 [RFC1242]. This terminology SHOULD be consulted before using 235 or applying the recommendations of this document. 237 Please refer to Figure 1 for a topology view of the network. The 238 following abbreviations are used in this document - 240 M := Module on a device (i.e. Line-Card or Slot; could be A or B) 242 p := Port number (i.e. Port on the Module; could be 1, 2 etc.) 243 RN := Remote Network (i.e. network that is reachable via a port of a 244 module; could be B1RN1 or B2RN5 to mean the first network reachable 245 via port 1 of module B e.g. B1, or the 5th network reachable via 246 port 2 of module B, etc.). RN is considered to be the FEC from MPLS 247 perpsective. 249 4.1.2. IGP Support 251 It is highly RECOMMENDED that all of the ports (A1, DA1, DB1, and 252 A2) on DUT and test tool support a dynamic Interior Gateway Protocol 253 (IGP) for routing such as IS-IS, OSPF, RIP etc. Furthermore, there 254 are testing considerations in this document that the device be able 255 to provide a stable control-plane during heavy forwarding workloads. 256 In particular, the procedures defined in section 11.3 of RFC2544 257 must be followed. This is to ensure that control plane instability 258 during 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 Push and Pop 350 A frame carrying IP or MPLS packet may go through any of the three 351 MPLS forwarding operations: label push (or LSP Ingress), label swap 352 and label pop (or LSP Egress), as defined in [RFC3031]. It is 353 important to understand the change of the frame format from IP to 354 MPLS or vice versa depending on the forwarding operation. 356 In label push (or LSP ingress) operation, the DUT receives a frame 357 containing an IP packet and forwards a frame containing an MPLS 358 packet if the corresponding forwarding lookup for the IP destination 359 points to a label push 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 pop (or LSP egress) operation, the DUT receives a frame 367 containing an MPLS packet and forwards a frame containing an IP 368 packet if the corresponding forwarding lookup for the label value 369 points to a label pop 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 push operation - the test tool must 380 use the frame format for IP packet (figure 1) to send the test 381 frames to the DUT, and must use the frame format for MPLS packet 382 (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 pop operation - the test tool must 390 use the frame format for MPLS packet (figure 2) to send the test 391 frames to the DUT, and must use the frame format for IP packet 392 (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 Push case) requires the testtool to send (or receive) 441 a layer2 frame containing an IP packet, then the following frame 442 sizes SHOULD be used for benchmarking over ethernet media: 64, 128, 443 256, 512, 1024, 1280 and 1518 bytes. This is in line with Section 9 444 and 9.1 of RFC2544. Figure 1 illustrates the header sizes for an 445 untagged ethernet frame containing an IP payload (per RFC2544) - 447 <----------------64-1518B------------------------> 448 <--18B---><-----------46-1500B-------------------> 449 +------------------------------------------------+ 450 | Layer 2 | Layer 3 | Layer 4 (and higher) | 451 +------------------------------------------------+ 453 Figure 3 Frame Size for Label Push cases 455 Note: The 64 and 1518 byte frame size represents the minimum and 456 maximum length of an untagged Ethernet frame, as per IEEE 802.3 457 [IEE8023]. A frame size commonly used in operational environments 458 may range from 68 to 1522 bytes, which are the minimum and maximum 459 length of a single VLAN-tagged frame, as per IEEE 802.1D 460 [IEE8021]. 462 Note: While jumbo frames are outside the scope of the 802.3 IEEE 463 standard, tests SHOULD be executed with the frame sizes that are 464 supported by the DUT. Examples of commonly used jumbo (ethernet) 465 frame sizes are: 4096, 8192, and 9216 bytes. 467 If any test case execution (such as Label Swap and Label Pop cases) 468 requires the testtool to transmit (or receive) a layer2 frame 469 containing an MPLS packet, then the untagged layer2 frame must 470 include an additional 4 bytes for the MPLS header, resulting in the 471 following frame sizes to be used for benchmarking over ethernet 472 media: 68, 132, 260, 516, 1028, 1284 and 1522 bytes. Figure 2 473 illustrates the header sizes for an untagged ethernet frame 474 containing an MPLS packet - 476 <------------------68-1522B------------------------------> 477 <--18B---><--4B--><-----------46-1500B-------------------> 478 +--------------------------------------------------------+ 479 | Layer 2 | MPLS | Layer 3 | Layer 4 (and higher) | 480 +--------------------------------------------------------+ 482 Figure 4 Frame Size for Label Swap and Pop cases. 484 Note: The Media MTU on the link between the testtool and DUT must 485 be changed, if needed, to accommodate the effective maximum frame 486 payload size [RFC3032] resulting from adding an MPLS label stack 487 to the IP packet. As clarified in Section 3.1 of RFC3032, most 488 layer 2 media drivers are capable of sending and receiving layer 2 489 frames with effective maximum frame payload size. Many vendors 490 also allow the Media MTU to be changed for MPLS, without changing 491 it for IP. The recommended link MTU value for MPLS is Z bytes more 492 than the conventional maximum frame payload size [RFC3032] (for 493 example, the conventional maximum frame payload size for ethernet 494 is 1500 bytes). This document prescribes Z=4 bytes. If a vendor 495 DUT doesn't allow such an MTU change, then the benchmarking can 496 not be performed for the true maximum frame payload size [RFC3032] 497 and this must be reported. 499 4.1.5.2. Frame Sizes to be used on POS Media 501 Packet over SONET (POS) media are commonly used for edge uplinks and 502 high-bandwidth core links. POS may use one of various 503 encapsulations techniques (such as PPP, HDLC, Frame Relay etc.), 504 resulting in the layer 2 header (~4 bytes) being less than that of 505 ethernet media. The rest of the frame format (illustrated in figure 506 2 and 3) remains pretty much unchanged. 508 If the MPLS forwarding characterization of POS interfaces on the DUT 509 is desired, then the following frame sizes SHOULD be used: 511 Label Push testcases: 47, 64, 128, 256, 512, 1024, 1280, 1518, 512 2048 and 4096 bytes. 514 Label Swap and Pop testcases: 51, 68, 132, 260, 516, 1028, 1284, 515 1522, 2052 and 4100 bytes. 517 4.1.6. Time-to-Live (TTL) or Hop Limit 519 The TTL value in the frame header must be large enough to allow a 520 TTL decrement to happen and still be forwared through the DUT. The 521 TTL field may either be MPLS TTL, IPV4 TTL, or IPV6 Hop Limit 522 depending on the exact forwarding scenario under evaluation. 524 If TTL/Hop Limit Decrement, as specified in [RFC3443], is a 525 configurable option on the DUT, the setting SHOULD be reported. 527 4.1.7. Trial Duration 529 Unless otherwise specified, the test portion of each trial SHOULD be 530 no less than 30 seconds when static routing is in place, and no less 531 than 200 seconds when a dynamic routing protocol and LDP (default 532 LDP holddown timer is 180 seconds) are being used. If the holddown 533 timer default vaue is changed, then it should be reported and the 534 trial duration should still be 20 seconds more than the holddown 535 timer value. 537 The longer trial time used for dynamic routing protocols is to 538 verify that the DUT is able to maintain a stable control plane when 539 the data-forwarding plane is under stress. 541 4.1.8. Traffic Verification 543 In all cases, sent traffic MUST be accounted for, whether it was 544 received on the wrong port, correct port or not received at all. 545 Specifically, traffic loss (also referred to as frame loss) is 546 defined as the traffic (i.e. one or more frames) not received where 547 expected (i.e. received on incorrect port, or received with 548 incorrect layer2 or above header information etc.). In addition, the 549 presence or absence of MPLS label stack, every field value inside 550 the label stack, if present, ethertype (0x8847 or 0x8848 vs. 551 0x0800), frame sequencing and frame check sequence (FCS), MUST be 552 verified in the received frame. 554 Many test tools may, by default, only verify that they have received 555 the embedded signature on the receive side. However, for MPLS header 556 presence verification, some tests will require the MPLS header to be 557 pushed while others will require a swap or pop. Hence, this document 558 requires the test tool to verify the MPLS stack depth. An even 559 greater level of verification would be to check if the correct label 560 was pushed, but that is out of scope for these tests. 562 4.1.9. Address Resolution and Dynamic Protocol State 564 If a test setup utilizes any dynamic protocols for control plane 565 signalling (eg. ARP, PPP (including MPLSCP), OSPF, LDP, etc.), then 566 all state for the protocols MUST be pre-established bofore the test 567 case is executed (i.e. packet streams are started). 569 5. Reporting Format 571 For each test case, it is RECOMMENDED that the following variables 572 be reported in addition to the specific parameters requested by the 573 test case: 575 Parameter Units or Examples 577 Prefix Forwarding IPv4, IPv6, Both 578 Equivalence Class (FEC) 580 Label Distribution Protocol LDP, RSVP-TE, BGP (or 581 combinations) 583 MPLS Forwarding Operation Push, Swap, Pop 585 IGP ISIS, OSPF, EIGRP, RIP, 586 static. 588 Throughput Frames per second and 589 Bits per second 591 Port Media GigE, POS, ATM etc. 593 Port Speed 1 gbps, 100 Mbps, etc. 595 Interface Encapsulation Ethernet, Ethernet VLAN, 596 PPP, HDLC etc. 598 Frame Size [See Section Bytes 599 4.1.3] 601 p (Number of {DA, DB} pair 1,2, etc. 602 ports per Figure 1) 604 The individual test cases may have additional reporting requirements 605 that may refer to other RFCs. 607 6. MPLS Forwarding Benchmarking Tests 609 MPLS is a different forwarding paradigm from IP. Unlike IP packet 610 and IP forwarding, an MPLS packet may contain more than one MPLS 611 header and may go through one of three forwarding operations - push 612 (or LSP ingress), swap or pop (or LSP egress), as defined in 613 [RFC3031]. Such characteristics desire further granularity in MPLS 614 forwarding benchmarking than those described in RFC2544. Thus the 615 benchmarking may include, but not limited to: 617 1. Throughput 619 2. Latency 621 3. Frame Loss rate 623 4. System Recovery 625 5. Reset 627 6. MPLS TC (previously known as EXP [RFC5462]) field Operations 628 (including explicit-null cases) 630 7. Negative Scenarios (TTL expiry, etc) 632 8. Multicast 634 However, this document focuses only on the first five categories, 635 inline with the spirit of RFC2544. All the benchmarking test cases 636 described in this document are expected to, at a minimum, follow the 637 'Test Setup' and 'Test Procedure' below - 639 Test Setup 641 Referring to Figure 1, a single port (p = 1) on both A and B 642 Modules SHOULD be used. However, if the forwarding throughput of 643 the DUT is more than that of the media rate of a single port, then 644 additional ports on A and B Modules MUST be enabled so as to 645 exceed the DUT's forwarding throughput. In such a case, the 646 procedures described in Section 16 of RFC2544 must be followed to 647 accommodate the multi-port scenario. The frame formats transmitted 648 and received must be in accord with Section 4.1.4.3 and 4.1.4.4, 649 and frame sizes must be in accord with in Section 4.1.5. 651 Note - The test tool must be configured to not advertise a prefix 652 or FEC to the DUT on more than one port. In other words, the DUT 653 must associate a FEC with one and only one DB port. The Equal Cost 654 Multi-Path (ECMP) behavior in MPLS networks uses heuristics 655 [RFC4928], hence, the usage of ECMP is NOT permitted by this 656 document to ensure the deterministic forwarding behavior during 657 the benchmarking. 659 Test Procedure 661 In accord with Section 26 of RFC2544 [RFC2544], the traffic is 662 sent from test tool port(s) Ap to the DUT at a constant load for a 663 fixed time interval, and is received from the DUT on test tool 664 port(s) Bp. The frame may contain either an IP packet or an MPLS 665 packet depending on the testcase need, as described in the Section 666 4.1.4.3. Furthermore, the IP packet must be either an IPv4 or IPv6 667 packet, depending on whether the MPLS benchmarking is done for 668 IPv4 or IPv6. 670 If any frame loss is detected, then a new iteration is needed 671 where the offered load is decreased and the sender will transmit 672 again. An iterative search algorithm MUST be used to determine the 673 maximum offered frame rate with a zero frame loss. 675 This maximum offered frame rate that results in zero frame loss 676 through the DUT is defined as the Throughput in Section 3.17 of 677 [RFC1242] for that test case. Informally, this rate is referred to 678 as the No Drop Rate. 680 Each iteration should involve varying the offered load of the 681 traffic, while keeping the other parameters (test duration, number 682 of ports, number of addresses, frame size etc) constant, until the 683 maximum rate at which none of the offered frames are dropped is 684 determined. 686 6.1. Throughput 688 This Section contains the description of the tests that are related 689 to the characterization of DUT's MPLS traffic forwarding. 691 6.1.1. Throughput for MPLS Label Push 693 Objective 695 To obtain the DUT's Throughput (as per RFC 2544) during label push 696 or LSP Ingress forwarding operation (i.e. IP to MPLS). 698 Test Setup 700 In addition to the test setup described in Section 6, the test 701 tool must advertise the IP prefix(es) i.e. RNx (using a routing 702 protocol as per Section 4.1.2) and associated MPLS label-FEC 703 binding(s) (using a label distribution protocol as per Section 704 4.1.3) on its receive ports Bp to DUT. The test tool may learn the 705 IP prefix(es) on it's transmit ports Ap from DUT. 707 MPLS and/or label distribution protocol must be enabled only on 708 the test tool receive ports Bp and DUT transmit ports DBp. 710 Discussion 712 The DUT's MPLS forwarding table (also referred to as FEC-to-NHLFE 713 (FTN) mapping table per [RFC3031]) must contain a non-reserved 714 MPLS label value as the outgoing label for each learned IP prefix 715 corresponding to the label-FEC binding, resulting in DUT 716 performing the IP-to-MPLS forwarding operation. The test tool must 717 receive MPLS packets on receive ports Bp (from DUT) with the same 718 label values that were advertised. 720 Procedure 722 Please see Test Procedure in Section 6. Additionally, the test 723 tool MUST send the frames containing IP packets (with IP 724 destination belonging to the advertised IP prefix(es)) on transmit 725 ports Ap, and expect to receive frames containing MPLS packets on 726 receive ports Bp, as described in Section 4.1.4.4. 728 Reporting Format 729 The result should be reported as per Section 5 and as per RFC2544. 731 Results for each test SHOULD be in the form of a table with a row 732 for each of the tested frame sizes. Additional columns SHOULD 733 include: offered load and measured throughput. 735 6.1.2. Throughput for MPLS Label Swap 737 Objective 739 To obtain the DUT's Throughput (as per RFC 2544) during label 740 swapping operation (i.e. MPLS to MPLS). 742 Test Setup 744 In addition to setup described in Section 6, the test tool must 745 advertise IP prefix(es) (using a routing protocol as per Section 746 4.1.2) and associated MPLS label-FEC bindings (using a label 747 distribution protocol as per Section 4.1.3) on the receive ports 748 Bp, and then learn the IP prefix(es) as well as the label-FEC 749 binding(s) on the transmit ports Ap. The test tool must use the 750 learned MPLS label values and learned IP prefix values in the 751 frames transmitted on ports Ap to DUT. 753 MPLS and/or label distribution protocol must be enabled on the 754 test tool ports Bp and Ap, and DUT ports DBp and DAp. 756 Discussion 758 The DUT's MPLS forwarding table (also referred to as FEC-to-NHLFE 759 (FTN) mapping table per [RFC3031]) must contain non-reserved MPLS 760 label values as the outgoing and incoming labels for the learned 761 IP prefixes, resulting in MPLS-to-MPLS forwarding operation e.g. 762 label swap. The test tool must receive MPLS packets on receive 763 ports Bp (from DUT) with the same label values that were 764 advertised using the label distribution protocol. The received 765 frames must contain the same number of MPLS headers as those of 766 transmitted frames. 768 Procedure 770 Please see Test Procedure in Section 6. Additionally, the test 771 tool must send frames containing MPLS packets (with IP destination 772 belonging to the advertised IP prefix(es)) on it's transmit ports 773 Ap, and expect to receive frames containing MPLS packets on its 774 receive ports Bp, as described in Section 4.1.4.4. 776 Reporting Format 778 The result should be reported as per Section 5 and as per RFC2544. 780 Results for each test SHOULD be in the form of a table with a row 781 for each of the tested frame sizes. 783 6.1.3. Throughput for MPLS Label Pop (Unlabeled) 785 Objective 787 To obtain the DUT's Throughput (as per RFC 2544) during label pop 788 or LSP Egress forwaridng operation (i.e. MPLS to IP) using 789 "Unlabeled" outgoing label. 791 Test Setup 793 In addition to setup described in Section 6, the test tool must 794 advertise the IP prefix(es) (using a routing protocol as per 795 Section 4.1.2) without any MPLS label-FEC bindings on the receive 796 ports Bp, and then learn the IP prefix(es) as well as the FEC- 797 label binding(s) on the transmit ports Ap. The test tool must use 798 the learned MPLS label values and learned IP prefix values in the 799 frames transmitted on ports Ap. 801 MPLS and/or label distribution protocol must be enabled only on 802 the test tool port(s) Ap and DUT port(s) DAp. 804 Discussion 806 The DUT's MPLS forwarding table (also referred to as FEC-to-NHLFE 807 (FTN) mapping table per [RFC3031]) must contain an Unlabeled 808 outgoing label (also known as untagged) for the learned IP prefix, 809 resulting in MPLS-to-IP forwarding operation. 811 Procedure 813 Please see Test Procedure in Section 6. Additionally, the test 814 tool must send frames containing MPLS packets on its transmit 815 ports Ap (with IP destination belonging to the IP prefix(es) 816 advertised on port Bp), and expect to receive frames containing IP 817 packets on its receive ports Bp, as described in Section 4.1.4.4. 819 Reporting Format 821 The result should be reported as per Section 5 and as per RFC2544. 823 Results for each test SHOULD be in the form of a table with a row 824 for each of the tested frame sizes. 826 6.1.4. Throughput for MPLS Label Pop (Aggregate) 828 Objective 830 To obtain the DUT's Throughput (as per RFC 2544) during label pop 831 or LSP Egress forwarding operation (i.e. MPLS to IP) using 832 "Aggregate" outgoing label[RFC3031]. 834 Test Setup 836 In addition to setup described in Section 6, the DUT must be 837 provisioned such that it allocates an aggregate outgoing label 838 (please see Section 3.20 in [RFC3031]) to an IP prefix, which 839 aggregates a set of prefixes learned on ports DBp from the test 840 tool. The prefix aggregation can be performed using BGP 841 aggregation (Section 9.2.2.2 of [RFC4271]), IGP aggregation 842 (Section 16.5 of [RFC2328]), etc.). 844 The DUT must advertise the aggregating IP prefix along with the 845 associated MPLS label-FEC binding on ports DAp to the test tool. 847 The test tool then must use the learned MPLS label values and 848 learned IP prefix values in frames transmitted on ports Ap to the 849 DUT. The test tool must receive frames containing IP packets on 850 ports Bp from the DUT. 852 MPLS and/or label distribution protocol must be enabled only on 853 the test tool port(s) Ap and DUT port(s) DAp. 855 Discussion 857 The DUT's MPLS forwarding table (also referred to as FEC-to-NHLFE 858 (FTN) mapping table per [RFC3031]) must contain an aggregate 859 outgoing label and IP forwarding table must contain a valid entry 860 for the learned prefix(es), resulting in MPLS-to-IP forwarding 861 operation (i.e. MPLS header removal followed by IP lookup). 863 Procedure 864 Please see Test Procedure in Section 6. Additionally, the test 865 tool must send frames containing MPLS packets on its transmit 866 ports Ap (with IP destination belonging to the IP prefix(es) 867 advertised on port Bp), and expect to receive frames containing IP 868 packets on its receive ports Bp, as described in Section 4.1.4.4. 870 Reporting Format 872 The result should be reported as per Section 5 and as per RFC2544. 874 Results for each test SHOULD be in the form of a table with a row 875 for each of the tested frame sizes. 877 6.1.5. Throughput for MPLS Label Pop (PHP) 879 Objective 881 To obtain the DUT's Throughput (as per RFC 2544) during label pop 882 (i.e. MPLS to IP) or penultimate hop popping (PHP) using "imp- 883 null" outgoing label. 885 Test Setup 887 In addition to setup described in Section 6, the test tool must be 888 set up to advertise the IP prefix(es) (using a routing protocol as 889 per Section 4.1.2) and associated MPLS label-FEC binding with a 890 reserved MPLS label value = 3 (using a label distribution protocol 891 as per Section 4.1.3) on its receive ports Bp. The test tool must 892 learn the IP prefix(es) as well as the MPLS label-FEC bindings on 893 its transmit ports Ap. The test tool then must use the learned 894 MPLS label values and learned IP prefix values in the frames 895 transmitted on ports Ap to DUT. The test tool must receive frames 896 containing IP packets on receive ports Bp (from DUT). 898 MPLS and/or label distribution protocol must be enabled on the 899 test tool ports Bp and Ap, and DUT ports DBp and DAp. 901 Discussion 903 This test case characterizes the Penultimate Hop Popping (PHP), 904 which is described in RFC3031. 906 The DUT's MPLS forwarding table (also referred to as FEC-to- 907 Next_Hop_Label_Forwarding_Entry (FTN) mapping table per [RFC3031]) 908 must contain a reserved MPLS label value = 3 (e.g. pop or imp- 909 null) as the outgoing label for the learned prefix(es), resulting 910 in MPLS-to-IP forwarding operation. 912 This test case characterizes DUT's penultimate hop popping (PHP) 913 functionality. 915 Procedure 917 Please see Test Procedure in Section 6. Additionally, the test 918 tool must send frames containing MPLS packets on its transmit 919 ports Ap (with IP destination belonging to advertised IP 920 prefix(es)), and expect to receive frames containing IP packets on 921 its receive ports Bp, as described in Section 4.1.4.4. 923 Reporting Format 925 The result should be reported as per Section 5 and as per RFC2544. 927 Results for each test SHOULD be in the form of a table with a row 928 for each of the tested frame sizes. 930 6.2. Latency Measurement 932 This measures the time taken by the DUT to forward the MPLS packet 933 during various MPLS switching paths such as IP-to-MPLS or MPLS-to- 934 MPLS or MPLS-to-IP involving an MPLS label stack. 936 Objective 938 To obtain the average latency induced by the DUT during MPLS 939 packet forwarding for each of five forwarding operations. 941 Test Setup 943 Follow the Test Setup guidelines established for each of four MPLS 944 forwarding operations in Section 6.1.1 (for IP-to-MPLS), 6.1.2 945 (for MPLS-to-MPLS), 6.1.3 (for MPLS-to-IP Unlabeled), 6.1.4 (for 946 MPLS-to-IP Aggregate) and 6.1.5 (for MPLS-to-IP PHP) one by one. 948 Procedure 950 Please refer to Section 26.2 in RFC2544 in addition to following 951 the associated procedure for each MPLS forwarding operation in 952 accord with the Test Setup described earlier - 954 IP-to-MPLS forwarding (Push) Section 6.1.1 955 MPLS-to-MPLS forwarding (Swap) Section 6.1.2 956 MPLS-to-IP forwarding (Pop) Section 6.1.3 957 MPLS-to-IP forwarding (Aggregate) Section 6.1.4 958 MPLS-to-IP forwarding (PHP) Section 6.1.5 960 Reporting Format 962 The result should be reported as per Section 5 and as per RFC2544. 964 6.3. Frame Loss Rate Measurement (FLR) 966 This measures the percentage of MPLS frames that were not forwarded 967 during various switching paths such as IP-to-MPLS (push) or MPLS-to- 968 IP (swap) or MPLS-IP (pop) by the DUT under overloaded state. 970 Please refer to RFC2544 Section 26.3 for more details. 972 Objective 974 To obtain the frame loss rate, as defined in RFC1242, for each of 975 three MPLS forwarding operations of a DUT, throughout the range of 976 input data rates and frame sizes. 978 Test Setup 980 Follow the Test Setup guidelines established for each of four MPLS 981 forwarding operations in Section 6.1.1 (for IP-to-MPLS), 6.1.2 982 (for MPLS-to-MPLS), 6.1.3 (for MPLS-to-IP Unlabeled), 6.1.4 (for 983 MPLS-to-IP Aggregate) and 6.1.5 (for MPLS-to-IP PHP) one by one. 985 Procedure 987 Please refer to Section 26.3 of RFC 2544 RFC2544 and follow the 988 associated procedure for each MPLS forwarding operation one-by-one 989 in accord with the Test Setup described earlier - 990 IP-to-MPLS forwarding (Push) Section 6.1.1 991 MPLS-to-MPLS forwarding (Swap) Section 6.1.2 992 MPLS-to-IP forwarding (Pop) Section 6.1.3 993 MPLS-to-IP forwarding (Aggregate) Section 6.1.4 994 MPLS-to-IP forwarding (PHP) Section 6.1.5 996 Reporting Format 998 The result should be reported as per Section 5 and as per RFC2544. 1000 6.4. System Recovery 1002 Objective 1004 To characterize the speed at which a DUT recovers from an overload 1005 condition. 1007 Test Setup 1009 Follow the Test Setup guidelines established for each of five MPLS 1010 forwarding operations in Section 6.1.1 (for IP-to-MPLS), 6.1.2 1011 (for MPLS-to-MPLS), 6.1.3 (for MPLS-to-IP Unlabeled), 6.1.4 (for 1012 MPLS-to-IP Aggregate) and 6.1.5 (for MPLS-to-IP PHP) one by one. 1014 Procedure 1016 Please refer to Section 26.5 of RFC2544 and follow the associated 1017 procedure for each MPLS forwarding operation in the referenced 1018 Sections one-by-one in accord with the Test Setup described 1019 earlier - 1021 IP-to-MPLS forwarding (Push) Section 6.1.1 1022 MPLS-to-MPLS forwarding (Swap) Section 6.1.2 1023 MPLS-to-IP forwarding (Pop) Section 6.1.3 1024 MPLS-to-IP forwarding (Aggregate) Section 6.1.4 1025 MPLS-to-IP forwarding (PHP) Section 6.1.5 1027 Reporting Format 1029 The result should be reported as per Section 5 and as per RFC2544. 1031 6.5. Reset 1033 Objective 1035 To characterize the speed at which a DUT recovers from a device or 1036 software reset. 1038 Test Setup 1040 Follow the Test Setup guidelines established for each of four MPLS 1041 forwarding operations in Section 6.1.1 (for IP-to-MPLS), 6.1.2 1042 (for MPLS-to-MPLS), 6.1.3 (for MPLS-to-IP Unlabeled), 6.1.4 (for 1043 MPLS-to-IP Aggregate) and 6.1.5 (for MPLS-to-IP PHP) one by one. 1045 For this testcase, the requirements of LDP and a routing-protocol 1046 are removed and replaced by static configurations. For the IP-to- 1047 MPLS iteration, static route configurations should be applied. For 1048 the MPLS-to-MPLS and MPLS-to-IP static label configurations must 1049 be applied. 1051 For this test, all graceful-restart features MUST be disabled. 1053 Discussion 1055 This test case is intended to provide an insight into how long an 1056 MPLS device could take to be fully operational after any of the 1057 reset events. It is quite likely that the time an IP/MPLS device 1058 takes to become fully operational after any of the reset events 1059 may be different from that of an IP only device. Moreover, 1060 different reset events may produce different results, hence, the 1061 type of reset event performed must be reported with the results. 1063 Procedure 1065 Please refer to RFC2544 Section 26.5. Examples of hardware and 1066 software resets are: 1068 Hardware reset - forwarding module resetting (e.g. OIR). 1070 Software reset - reset initiated through a CLI (e.g. reload). 1072 Additionally, follow the specific Section for procedure (and test 1073 Setup) for each MPLS forwarding operation one-by-one - 1074 IP-to-MPLS forwarding (Push) Section 6.1.1 1075 MPLS-to-MPLS forwarding (Swap) Section 6.1.2 1076 MPLS-to-IP forwarding (Pop) Section 6.1.3 1077 MPLS-to-IP forwarding (Aggregate) Section 6.1.4 1078 MPLS-to-IP forwarding (PHP) Section 6.1.5 1080 Reporting Format 1082 Same as RFC2544 and the parameters of Section 5 including the 1083 specific type of reset performed. 1085 7. Security Considerations 1087 Benchmarking activities, as described in this memo, are limited to 1088 technology characterization using controlled stimuli in a laboratory 1089 environment, with dedicated address space and the constraints 1090 specified in the sections above. 1092 The benchmarking network topology will be an independent test setup 1093 and MUST NOT be connected to devices that may forward the test 1094 traffic into a production network or misroute traffic to the test 1095 management network. 1097 Furthermore, benchmarking is performed on a "black-box" basis, 1098 relying solely on measurements observable external to the DUT/SUT. 1100 Special capabilities SHOULD NOT exist in the DUT/SUT specifically 1101 for benchmarking purposes. Any implications for network security 1102 arising from the DUT/SUT SHOULD be identical in the lab and in 1103 production networks. 1105 There are no specific security considerations within the scope of 1106 this document. 1108 8. IANA Considerations 1110 There are no considerations for IANA at this time. 1112 9. Acknowledgement 1114 The authors would like to thank Mo Khalid, who motivated us to write 1115 this document. We would like to thank Rodney Dunn, Chip Popoviciu, 1116 Jeff Byzek, Jay Karthik, Rajiv Papneja, Samir Vapiwala, Silvija 1117 Andrijic Dry, Scott Bradner, Al Morton and Bill Cerveny for their 1118 careful review and suggestions. 1120 This document was prepared using 2-Word-v2.0.template.dot. 1122 10. References 1124 10.1. Normative References 1126 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1127 Requirement Levels", BCP 14, RFC 2119, March 1997. 1129 [RFC2544] Bradner, S. and McQuaid, J., "Benchmarking Methodology for 1130 Network Interconnect Devices", RFC 2544, March 1999. 1132 [RFC1242] Bradner, S., Editor, "Benchmarking Terminology for Network 1133 Interconnection Devices", RFC 1242, July 1991. 1135 [RFC3031] Rosen et al., "Multiprotocol Label Switching 1136 Architecture", RFC 3031, August 1999. 1138 [RFC3032] Rosen et al., "MPLS Label Stack Encoding", RFC 3032, 1139 January 2001. 1141 [RFC3107] Rosen, E. and Rekhter, Y., "Carrying Label Information in 1142 BGP-4", RFC 3107, May 2001. 1144 [RFC5036] Andersson, L., Doolan, P., Feldman, N., Fredette, A. and 1145 B. Thomas, "LDP Specification", RFC 5036, January 2001. 1147 10.2. Informative References 1149 [RFC5180] Popoviciu, C., et al, "IPv6 Benchmarking Methodology for 1150 Network Interconnect Devices", RFC 5180, May 2008. 1152 [RFC3209] Awduche, et al., "RSVP-TE: Extensions to RSVP for LSP 1153 Tunnels", RFC 3209, Dec 2001. 1155 [RFC4364] Rosen E. and Rekhter Y., "BGP/MPLS IP Virtual Private 1156 Networks (VPNs)", RFC4364, February 2006. 1158 [RFC4271] Rekhter, Y. and T. Li, "Framework for Layer 2 Virtual 1159 Private Networks (L2VPNs)", RFC 4664, Sep 2006. 1161 [RFC4664] Rosen, E. and Andersson L., " A Border Gateway Protocol 4 1162 (BGP-4)", RFC 4271, Jan 2006. 1164 [IEE8021] Mick Seaman (editor), "IEEE Std 802.1D-2004, MAC Bridges", 1165 Feb 2004. 1167 [IEE8023] LAN/MAN Standards Committee of the IEEE Computer Society, 1168 "IEEE Std 802.3as-2006, Part 3: Carrier Sense Multiple 1169 Access with Collision Detection (CSMA/CD) Access Method 1170 and Physical Layer Specifications, Amendment 3: Frame 1171 format extensions", Nov 2006. 1173 [RFC3443] Agarwal, P. and Akyol, B., "Time To Live (TTL) Processing 1174 in MPLS Networks", RFC3443, Jan 2003. 1176 [RFC2328] Moy, J., "OSPF Version 2", RFC2328, April 1998. 1178 [RFC5462] Asati, R. and Andersson, L., "Multi-Protocol Label 1179 Switching (MPLS) label stack entry: "EXP" field renamed to 1180 "Traffic Class" field", RFC5462, Feb 2009. 1182 [RFC4928] Swallow, et al., "Avoiding Equal Cost Multipath Treatment 1183 in MPLS Networks", RFC4928, June 2007. 1185 [RFC4090] Pan, et al., "Fast Reroute Extensions to RSVP-TE for LSP 1186 Tunnels", RFC4090, May 2005. 1188 Author's Addresses 1190 Aamer Akhter 1191 Cisco Systems 1192 7025 Kit Creek Road 1193 RTP, NC 27709 1194 USA 1196 Email: aakhter@cisco.com 1197 Rajiv Asati 1198 Cisco Systems 1199 7025 Kit Creek Road 1200 RTP, NC 27709 1201 USA 1203 Email: rajiva@cisco.com 1205 Carlos Pignataro 1206 Cisco Systems 1207 7200-12 Kit Creek Road 1208 RTP, NC 27709 1209 USA 1211 Email: cpignata@cisco.com