idnits 2.17.1 draft-ietf-bmwg-mpls-forwarding-meth-06.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 (September 8, 2009) is 5315 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: March, 2010 Rajiv Asati 6 Cisco Systems 8 Carlos Pignataro 9 Cisco Systems 11 September 8, 2009 13 MPLS Forwarding Benchmarking Methodology for IP Flows 14 draft-ietf-bmwg-mpls-forwarding-meth-06 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 March 8, 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............................................14 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...............................................31 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 workload on network 126 forwarding device resources that MPLS forwarding places is different 127 from that of IP forwarding; therefore, 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.3) 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 octets (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 178 Figure 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 +-----+ DAp DBp +-----+ 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 Figure 219 1 from Section 6 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 IP Prefix FEC 248 from MPLS perpsective. 250 4.1.2. IGP Support 252 It is RECOMMENDED that all of the ports (A1, DA1, DB1, and A2) on 253 DUT and test tool support a dynamic Interior Gateway Protocol (IGP) 254 for routing such as IS-IS, OSPF, RIP etc. Furthermore, there are 255 testing considerations in this document that the device be able to 256 provide a stable control-plane during heavy forwarding workloads. In 257 particular, the procedures defined in section 11.3 of RFC2544 must 258 be followed. This is to ensure that control plane instability during 259 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 Static labels SHOULD NOT be used to establish the MPLS label 285 switched paths (LSPs), unless specified explicitly by the testcase. 287 This is because the use of static label is quite uncommon in the 288 production networks. 290 The IPv4 and IPv6 Explicit NULL labels (label values 0 and 2) are 291 sometimes used to identify the payload of an MPLS packet on an LSP 292 [RFC3032]. Explicit NULL labels are not used in the tests described 293 in this document because the tests are limited to the use of no more 294 than one non-reserved MPLS label in the label stack of all packets 295 to, form, or through the DUT. 297 4.1.4. Frame Formats 299 This section explains the frame formats for IP and MPLS packets 300 (Section 4.1.4.1), the usage of IP as the mandatory layer 3 protocol 301 and as the MPLS packet payload (Section 4.1.4.2), change in frame 302 format during forwarding (Section 4.1.4.3) and recommended frame 303 formats for the MPLS benchmarking (Section 4.1.4.4). 305 4.1.4.1. Frame format for IP vs. MPLS 307 A test frame carrying an IP packet is illustrated in the Figure 2 308 below. Note that RFC2544 [RFC2544] prescribes using such a frame as 309 the test frame over the chosen layer 2 media. 311 +---------+--------------+-----------------------+ 312 | Layer 2 | Layer 3 = IP | Layer 4 = UDP | 313 +---------+--------------+-----------------------+ 315 Figure 2 Frame Format for IP packet 317 Unlike a test frame carrying an IP packet, a test frame carrying an 318 MPLS packet contains an 'MPLS label stack' [RFC3032] immediately 319 after the layer 2 header (and before the IP header, if any) as 320 illustrated in Figure 3 below - 322 +---------+-------+--------------+-----------------------+ 323 | Layer 2 | MPLS | Layer 3 = IP | Layer 4 = UDP | 324 +---------+-------+--------------+-----------------------+ 326 Figure 3 Frame format for MPLS packet 328 The MPLS label stack is represented as a sequence of "label stack 329 entries", where each label stack entry is 4 octets, as illustrated 330 in Figure 1 of [RFC3032]. This document requires exactly one entry 331 in the MPLS label stack in an MPLS packet. 333 MPLS label values used in any testcase MUST be outside the reserved 334 label value (0-15) unless stated otherwise. 336 4.1.4.2. MPLS packet payload 338 This document prescribes using IP packet as the MPLS payload (as 339 illustrated in Figure 3 above). Generically speaking, this document 340 mandates the test frame to include IP (either IPv4 or IPv6) as the 341 layer 3 protocol, in accord with Section 8 of [RFC2544] and 342 independent of the MPLS label stack presence, for three reasons: 344 1. This enables using IP Prefix Forwarding Equivalence Class (FEC) 345 [RFC3031], which is a must for every MPLS network. 347 2. This provides the foundation or baseline for benchmarking of 348 various other MPLS applications such as L3VPN, L2VPN, TE-FRR etc. 350 3. This enables leveraging RFC2544 [RFC2544], which prescribes using 351 IP packet with UDP data as the test frames. (Note that [RFC5180] 352 also uses this prescription for IPv6 benchmarking). 354 While the usage of non-IP payloads is possible, it requires an MPLS 355 application e.g. L2VPN, whose benchmarking may be covered in 356 separate BMWG documents (MPLS L2VPN Benchmarking, for example) in 357 the future. This is also explained in Section 2. 359 4.1.4.3. Change in Frame Format due to MPLS Push and Pop 361 A frame carrying IP or MPLS packet may go through any of the three 362 MPLS forwarding operations: label push (or LSP Ingress), label swap 363 and label pop (or LSP Egress), as defined in [RFC3031]. It is 364 important to understand the change of the frame format from IP to 365 MPLS or vice versa depending on the forwarding operation. 367 In label push (or LSP ingress) operation, the DUT receives a frame 368 containing an IP packet and forwards a frame containing an MPLS 369 packet if the corresponding forwarding lookup for the IP destination 370 points to a label push operation. 372 In label swap operation, the DUT receives a frame containing an MPLS 373 packet and forwards a frame containing an MPLS packet if the 374 corresponding forwarding lookup for the label value points to a 375 label swap operation. 377 In label pop (or LSP egress) operation, the DUT receives a frame 378 containing an MPLS packet and forwards a frame containing an IP 379 packet if the corresponding forwarding lookup for the label value 380 points to a label pop operation. 382 4.1.4.4. Frame Formats to be used for Benchmarking 384 This document prescribes using two test frame formats to 385 appropriately test the forwarding operations: (1) Frame format for 386 IP and (2) Frame format for MPLS. Both formats are explained in 387 Section 4.1.4.1. Additionally, the format of the test frame may 388 change depending on the forwarding operation. 390 1. For testcases involving label push operation - the test tool must 391 use the frame format for IP packet (Figure 2) to send the test 392 frames to the DUT, and must use the frame format for MPLS packet 393 (Figure 3) to receive the test frames from the DUT. 395 2. For testcases involving label swap operation - the test tool must 396 use the frame format for MPLS packet (Figure 3) to send the test 397 frames to the DUT, and must use the frame format for MPLS packet 398 (Figure 3) to receive the test frames from the DUT. 400 3. For testcases involving label pop operation - the test tool must 401 use the frame format for MPLS packet (Figure 3) to send the test 402 frames to the DUT, and must use the frame format for IP packet 403 (Figure 2) to receive the test frames from the DUT. 405 4.1.5. Frame Sizes 407 Two types of port media are commonly deployed: Ethernet and POS 408 (Packet Over Synchronous Optical Network). This section identifies 409 the frame sizes that SHOULD be used for each media type, if 410 supported by the DUT. Section 4.1.5.1 covers Ethernet and 4.1.5.2 411 covers POS. 413 First, it is important to note the possible increase in frame size 414 due to the presence of an MPLS label stack in the frame (as 415 explained in Section 4.1.4.3). 417 As observed in the current deployments, presence of an MPLS label 418 stack in a layer 2 frame is assumed to be transparent to layer3=IP, 419 which continues to follow the conventional maximum frame payload 420 size [RFC3032] (1500 octets for ethernet, say). This means that the 421 effective maximum frame payload size [RFC3032] of the resulting 422 layer2 frame is Z octets more than the conventional maximum frame 423 payload size, where Z = 4 x number of entries in the label stack. 425 Hence, to ensure successful delivery of layer2 frames carrying MPLS 426 packets and realistic benchmarking, it is RECOMMENDED to set the 427 media MTU value to the effective maximum frame payload size 428 [RFC3032], which equals Z octets + conventional maximum frame 429 payload size. It is expected that such a change in media MTU value 430 only impacts the effective Maximum Frame Payload Size for MPLS 431 packets, but not for IP packets. 433 Note that this document requires exactly a single entry in the MPLS 434 label stack in an MPLS packet. In other words, the depth of the 435 label stack is set to one e.g. Z = 4 x 1 = 4 octets. 436 Furthermore, in accord with Section 9 and 9.1 of RFC2544, this 437 document prescribes that each testcase case is run with different 438 (layer 2) frame sizes in different trials. Additionally, results MAY 439 also be collected with multiple simultaneous frame sizes (sometimes 440 referred to as an IMIX to simulate real network traffic according to 441 the frame size ordering and usage). There is no standard for 442 mixtures of frame sizes, and the results are subject to wide 443 interpretation. See Section 18 of RFC 2544. When running trials 444 using multiple simultaneous frame sizes, the DUT configuration MUST 445 remain the same. 447 4.1.5.1. Frame Sizes to be used on Ethernet Media 449 Ethernet media, in all its types, has become the most commonly 450 deployed port media in MPLS networks. If any test case execution 451 (such as Label Push case) requires the testtool to send (or receive) 452 a layer2 frame containing an IP packet, then the following frame 453 sizes SHOULD be used for benchmarking over ethernet media: 64, 128, 454 256, 512, 1024, 1280 and 1518 octets. This is in line with Section 9 455 and 9.1 of RFC2544. Figure 4 illustrates the header sizes for an 456 untagged ethernet frame containing an IP payload (per RFC2544) - 457 <----------------64-1518B------------------------> 458 <--18B---><-----------46-1500B-------------------> 459 +---------+---------+----------------------------+ 460 | Layer 2 | Layer 3 | Layer 4 (and higher) | 461 +---------+---------+----------------------------+ 463 Figure 4 Frame Size for Label Push cases 465 Note 1: The 64 and 1518 octet frame size represents the minimum 466 and maximum length of an untagged Ethernet frame, as per IEEE 467 802.3 [IEE8023]. A frame size commonly used in operational 468 environments may range from 68 to 1522 octets, which are the 469 minimum and maximum length of a single VLAN-tagged frame, as per 470 IEEE 802.1D [IEE8021]. 472 Note 2: While jumbo frames are outside the scope of the 802.3 IEEE 473 standard, tests SHOULD be executed with the frame sizes that are 474 supported by the DUT. Examples of commonly used jumbo (ethernet) 475 frame sizes are: 4096, 8192, and 9216 octets. 477 If any test case execution (such as Label Swap and Label Pop cases) 478 requires the testtool to transmit (or receive) a layer2 frame 479 containing an MPLS packet, then the untagged layer2 frame must 480 include an additional 4 octets for the MPLS header, resulting in the 481 following frame sizes to be used for benchmarking over ethernet 482 media: 68, 132, 260, 516, 1028, 1284 and 1522 octets. Figure 5 483 illustrates the header sizes for an untagged ethernet frame 484 containing an MPLS packet - 486 <------------------68-1522B------------------------------> 487 <--18B---><--4B--><-----------46-1500B-------------------> 488 +---------+-------+---------+----------------------------+ 489 | Layer 2 | MPLS | Layer 3 | Layer 4 (and higher) | 490 +---------+-------+---------+----------------------------+ 492 Figure 5 Frame Size for Label Swap and Pop cases. 494 Note: The Media MTU on the link between the testtool and DUT must 495 be changed, if needed, to accommodate the effective maximum frame 496 payload size [RFC3032] resulting from adding an MPLS label stack 497 to the IP packet. As clarified in Section 3.1 of RFC3032, most 498 layer 2 media drivers are capable of sending and receiving layer 2 499 frames with effective maximum frame payload size. Many vendors 500 also allow the Media MTU to be changed for MPLS, without changing 501 it for IP. The recommended link MTU value for MPLS is Z octets 502 more than the conventional maximum frame payload size [RFC3032] 503 (for example, the conventional maximum frame payload size for 504 ethernet is 1500 octets). This document prescribes Z=4 octets. If 505 a vendor DUT doesn't allow such an MTU change, then the 506 benchmarking can not be performed for the true maximum frame 507 payload size [RFC3032] and this must be reported. 509 4.1.5.2. Frame Sizes to be used on POS Media 511 Packet over SONET (POS) media are commonly used for edge uplinks and 512 high-bandwidth core links. POS may use one of various 513 encapsulations techniques (such as PPP, HDLC, Frame Relay etc.), 514 resulting in the layer 2 header (~4 octets) being less than that of 515 ethernet media. The rest of the frame format (illustrated in Figures 516 2 and 3) remains pretty much unchanged. 518 If the MPLS forwarding characterization of POS interfaces on the DUT 519 is desired, then the following frame sizes SHOULD be used: 521 Label Push testcases: 47, 64, 128, 256, 512, 1024, 522 1280, 1518, 2048 and 4096 octets. 524 Label Swap and Pop testcases: 51, 68, 132, 260, 516, 1028, 525 1284, 1522, 2052 and 4100 octets. 527 4.1.6. Time-to-Live (TTL) or Hop Limit 529 The TTL value in the frame header MUST be large enough to allow a 530 TTL decrement to happen and still be forwared through the DUT. The 531 aforementioned TTL field may be referring to either the MPLS TTL, 532 IPV4 TTL, or IPV6 Hop Limit depending on the exact forwarding 533 scenario under evaluation. 535 If TTL/Hop Limit Decrement, as specified in [RFC3443], is a 536 configurable option on the DUT, the setting SHOULD be reported. 538 4.1.7. Trial Duration 540 Unless otherwise specified, the test portion of each trial SHOULD be 541 no less than 30 seconds when static routing is in place, and no less 542 than 200 seconds when a dynamic routing protocol and LDP (default 543 LDP holddown timer is 180 seconds) are being used. If the holddown 544 timer default value is changed, then it should be reported and the 545 trial duration should still be 20 seconds more than the holddown 546 timer value. 548 The longer trial time used for dynamic routing protocols is to 549 verify that the DUT is able to maintain a stable control plane when 550 the data-forwarding plane is under stress. 552 4.1.8. Traffic Verification 554 In all cases, sent traffic MUST be accounted for, whether it was 555 received on the wrong port, correct port or not received at all. 556 Specifically, traffic loss (also referred to as frame loss) is 557 defined as the traffic (i.e. one or more frames) not received where 558 expected (i.e. received on incorrect port, or received with 559 incorrect layer2 or above header information etc.). In addition, the 560 presence or absence of MPLS label stack, every field value inside 561 the label stack, if present, ethertype (0x8847 or 0x8848 vs. 0x0800 562 or 0x86DD), frame sequencing and frame check sequence (FCS), MUST be 563 verified in the received frame. 565 Many test tools may, by default, only verify that they have received 566 the embedded signature on the receive side. However, for MPLS header 567 presence verification, some tests will require the MPLS header to be 568 pushed while others will require a swap or pop. Hence, this document 569 requires the test tool to verify the MPLS stack depth. An even 570 greater level of verification would be to check if the correct label 571 was pushed. However, some test tools are not capable of checking the 572 received label value for correctness. Test tools SHOULD verify that 573 the packets received carry the expected MPLS label. 575 4.1.9. Address Resolution and Dynamic Protocol State 577 If a test setup utilizes any dynamic protocols for control plane 578 signalling (eg. ARP, PPP (including MPLSCP), OSPF, LDP, etc.), then 579 all state for the protocols MUST be pre-established bofore the test 580 case is executed (i.e. packet streams are started). 582 5. Reporting Format 584 For each test case, it is RECOMMENDED that the following variables 585 be reported in addition to the specific parameters requested by the 586 test case: 588 Parameter Units or Examples 590 Prefix Forwarding Equivalence IPv4, IPv6, Both 591 Class (FEC) 593 Label Distribution Protocol LDP, RSVP-TE, BGP (or 594 combinations) 596 MPLS Forwarding Operation Push, Swap, Pop 598 IGP ISIS, OSPF, EIGRP, RIP, 599 static. 601 Throughput Frames per second and 602 Bits per second 604 Port Media GigE, POS, ATM etc. 606 Port Speed 1 gbps, 100 Mbps, etc. 608 Interface Encapsulation Ethernet, Ethernet 609 VLAN, PPP, HDLC etc. 611 Frame Size (Section 4.1.5) Octets 613 p (Number of {DA, DB} pair 1,2, etc. 614 ports per Figure 1) 616 The individual test cases may have additional reporting requirements 617 that may refer to other RFCs. 619 6. MPLS Forwarding Benchmarking Tests 621 MPLS is a different forwarding paradigm from IP. Unlike IP packet 622 and IP forwarding, an MPLS packet may contain more than one MPLS 623 header and may go through one of three forwarding operations : push 624 (or LSP ingress), swap or pop (or LSP egress), as defined in 625 [RFC3031]. Such characteristics desire further granularity in MPLS 626 forwarding benchmarking than those described in RFC2544. Thus the 627 benchmarking may include, but not limited to: 629 1. Throughput 631 2. Latency 633 3. Frame Loss rate 635 4. System Recovery 637 5. Reset 639 6. MPLS TC (previously known as EXP [RFC5462]) field Operations 640 (including explicit-null cases) 642 7. Negative Scenarios (TTL expiry, etc) 644 8. Multicast 646 However, this document focuses only on the first five categories, 647 inline with the spirit of RFC2544. All the benchmarking test cases 648 described in this document are expected to, at a minimum, follow the 649 'Test Setup' and 'Test Procedure' below- 651 Test Setup 653 Referring to Figure 1, a single port (p = 1) on both A and B 654 Modules SHOULD be used. However, if the forwarding throughput of 655 the DUT is more than that of the media rate of a single port, then 656 additional ports on A and B Modules MUST be enabled as follows: If 657 the DUT can be configured with A and B ports so as to exceed the 658 DUT's forwarding throughput without overloading any B ports, then 659 those MUST be enabled; if on the other hand the DUT's forwarding 660 throughput capacity is greater than what can achieved enabling all 661 ports, then all An and Bn ports MUST be enabled. In the case where 662 more than one A and B ports are enabled, the procedures described 663 in Section 16 of RFC2544 must be followed to accommodate the 664 multi-port scenario. The frame formats transmitted and received 665 must be in accord with Section 4.1.4.3 and 4.1.4.4, and frame 666 sizes must be in accord with in Section 4.1.5. 668 Note - The test tool must be configured to not advertise a prefix 669 or FEC to the DUT on more than one port. In other words, the DUT 670 must associate a FEC with one and only one DB port. The Equal Cost 671 Multi-Path (ECMP) behavior in MPLS networks uses heuristics 672 [RFC4928], hence, the usage of ECMP is NOT permitted by this 673 document to ensure the deterministic forwarding behavior during 674 the benchmarking. 676 Test Procedure 678 In accord with Section 26 of RFC2544 [RFC2544], the traffic is 679 sent from test tool port(s) Ap to the DUT at a constant load for a 680 fixed time interval, and is received from the DUT on test tool 681 port(s) Bp. As described in Section 4.1.4.3, the frame may contain 682 either an IP packet or an MPLS packet depending on the testcase 683 need. Furthermore, the IP packet must be either an IPv4 or IPv6 684 packet, depending on whether the MPLS benchmarking is done for 685 IPv4 or IPv6. 687 If any frame loss is detected, then a new iteration is needed 688 where the offered load is decreased and the sender will transmit 689 again. An iterative search algorithm MUST be used to determine the 690 maximum offered frame rate with a zero frame loss. 692 This maximum offered frame rate that results in zero frame loss 693 through the DUT is defined as the Throughput in Section 3.17 of 694 [RFC1242] for that test case. Informally, this rate is referred to 695 as the No Drop Rate. 697 Each iteration should involve varying the offered load of the 698 traffic, while keeping the other parameters (test duration, number 699 of ports, number of addresses, frame size etc) constant, until the 700 maximum rate at which none of the offered frames are dropped is 701 determined. 703 6.1. Throughput 705 This Section contains the description of the tests that are related 706 to the characterization of DUT's MPLS traffic forwarding. 708 6.1.1. Throughput for MPLS Label Push 710 Objective 712 To obtain the DUT's Throughput (as per RFC 2544) during label push 713 or LSP Ingress forwarding operation (i.e. IP to MPLS). 715 Test Setup 717 In addition to the test setup described in Section 6, the test 718 tool must advertise the IP prefix(es) i.e. RNx (using a routing 719 protocol as per Section 4.1.2) and associated MPLS label-FEC 720 binding(s) (using a label distribution protocol as per Section 721 4.1.3) on its receive ports Bp to DUT. The test tool may learn the 722 IP prefix(es) on it's transmit ports Ap from DUT. 724 MPLS and/or label distribution protocol must be enabled only on 725 the test tool receive ports Bp and DUT transmit ports DBp. 727 Discussion 729 The DUT's MPLS forwarding table (also referred to as Incoming 730 Label Map (ILM) to Next Hop Label Forwarding Entry (NHLFE) mapping 731 table per Section 3.11 of [RFC3031]) must contain a non-reserved 732 MPLS label value as the outgoing label for each learned IP prefix 733 corresponding to the label-FEC binding, resulting in DUT 734 performing the IP-to-MPLS forwarding operation. The test tool must 735 receive MPLS packets on receive ports Bp (from DUT) with the same 736 label values that were advertised. 738 Procedure 740 Please see Test Procedure in Section 6. Additionally, the test 741 tool MUST send the frames containing IP packets (with IP 742 destination belonging to the advertised IP prefix(es)) on transmit 743 ports Ap, and expect to receive frames containing MPLS packets on 744 receive ports Bp, as described in Section 4.1.4.4. 746 Reporting Format 748 The result should be reported as per Section 5 and as per RFC2544. 750 Results for each test SHOULD be in the form of a table with a row 751 for each of the tested frame sizes. Additional columns SHOULD 752 include: offered load and measured throughput. 754 6.1.2. Throughput for MPLS Label Swap 756 Objective 758 To obtain the DUT's Throughput (as per RFC 2544) during label 759 swapping operation (i.e. MPLS to MPLS). 761 Test Setup 763 In addition to setup described in Section 6, the test tool must 764 advertise IP prefix(es) (using a routing protocol as per Section 765 4.1.2) and associated MPLS label-FEC bindings (using a label 766 distribution protocol as per Section 4.1.3) on the receive ports 767 Bp, and then learn the IP prefix(es) as well as the label-FEC 768 binding(s) on the transmit ports Ap. The test tool must use the 769 learned MPLS label values and learned IP prefix values in the 770 frames transmitted on ports Ap to DUT. 772 MPLS and/or label distribution protocol must be enabled on the 773 test tool ports Bp and Ap, and DUT ports DBp and DAp. 775 Discussion 777 The DUT's MPLS forwarding table (also referred to as ILM to NHLFE 778 mapping table per Section 3.11 of [RFC3031]) must contain non- 779 reserved MPLS label values as the outgoing and incoming labels for 780 the learned IP prefixes, resulting in MPLS-to-MPLS forwarding 781 operation e.g. label swap. The test tool must receive MPLS packets 782 on receive ports Bp (from DUT) with the same label values that 783 were advertised using the label distribution protocol. The 784 received frames must contain the same number of MPLS headers as 785 those of transmitted frames. 787 Procedure 789 Please see Test Procedure in Section 6. Additionally, the test 790 tool must send frames containing MPLS packets (with IP destination 791 belonging to the advertised IP prefix(es)) on it's transmit ports 792 Ap, and expect to receive frames containing MPLS packets on its 793 receive ports Bp, as described in Section 4.1.4.4. 795 Reporting Format 797 The result should be reported as per Section 5 and as per RFC2544. 799 Results for each test SHOULD be in the form of a table with a row 800 for each of the tested frame sizes. 802 6.1.3. Throughput for MPLS Label Pop (Unlabeled) 804 Objective 806 To obtain the DUT's Throughput (as per RFC 2544) during label pop 807 or LSP Egress forwaridng operation (i.e. MPLS to IP) using 808 "Unlabeled" outgoing label. 810 Test Setup 812 In addition to setup described in Section 6, the test tool must 813 advertise the IP prefix(es) (using a routing protocol as per 814 Section 4.1.2) without any MPLS label-FEC bindings on the receive 815 ports Bp, and then learn the IP prefix(es) as well as the FEC- 816 label binding(s) on the transmit ports Ap. The test tool must use 817 the learned MPLS label values and learned IP prefix values in the 818 frames transmitted on ports Ap. 820 MPLS and/or label distribution protocol must be enabled only on 821 the test tool port(s) Ap and DUT port(s) DAp. 823 Discussion 825 The DUT's MPLS forwarding table (also referred to as ILM to NHLFE 826 mapping table per Section 3.11 of [RFC3031]) must contain an 827 Unlabeled outgoing label (also known as untagged) for the learned 828 IP prefix, resulting in MPLS-to-IP forwarding operation. 830 Procedure 832 Please see Test Procedure in Section 6. Additionally, the test 833 tool must send frames containing MPLS packets on its transmit 834 ports Ap (with IP destination belonging to the IP prefix(es) 835 advertised on port Bp), and expect to receive frames containing IP 836 packets on its receive ports Bp, as described in Section 4.1.4.4. 838 Reporting Format 840 The result should be reported as per Section 5 and as per RFC2544. 842 Results for each test SHOULD be in the form of a table with a row 843 for each of the tested frame sizes. 845 6.1.4. Throughput for MPLS Label Pop (Aggregate) 847 Objective 849 To obtain the DUT's Throughput (as per RFC 2544) during label pop 850 or LSP Egress forwarding operation (i.e. MPLS to IP) using 851 "Aggregate" outgoing label[RFC3031]. 853 Test Setup 855 In addition to setup described in Section 6, the DUT must be 856 provisioned such that it allocates an aggregate outgoing label 857 (please see Section 3.20 in [RFC3031]) to an IP prefix, which 858 aggregates a set of prefixes learned on ports DBp from the test 859 tool. The prefix aggregation can be performed using BGP 860 aggregation (Section 9.2.2.2 of [RFC4271]), IGP aggregation 861 (Section 16.5 of [RFC2328]), etc.). 863 The DUT must advertise the aggregating IP prefix along with the 864 associated MPLS label-FEC binding on ports DAp to the test tool. 866 The test tool then must use the learned MPLS label values and 867 learned IP prefix values in frames transmitted on ports Ap to the 868 DUT. The test tool must receive frames containing IP packets on 869 ports Bp from the DUT. 871 MPLS and/or label distribution protocol must be enabled only on 872 the test tool port(s) Ap and DUT port(s) DAp. 874 Discussion 876 The DUT's MPLS forwarding table (also referred to as ILM to NHLFE 877 mapping table per Section 3.11 of [RFC3031]) must contain an 878 aggregate outgoing label and IP forwarding table must contain a 879 valid entry for the learned prefix(es), resulting in MPLS-to-IP 880 forwarding operation (i.e. MPLS header removal followed by IP 881 lookup). 883 Procedure 885 Please see Test Procedure in Section 6. Additionally, the test 886 tool must send frames containing MPLS packets on its transmit 887 ports Ap (with IP destination belonging to the IP prefix(es) 888 advertised on port Bp), and expect to receive frames containing IP 889 packets on its receive ports Bp, as described in Section 4.1.4.4. 891 Reporting Format 893 The result should be reported as per Section 5 and as per RFC2544. 895 Results for each test SHOULD be in the form of a table with a row 896 for each of the tested frame sizes. 898 6.1.5. Throughput for MPLS Label Pop (PHP) 900 Objective 902 To obtain the DUT's Throughput (as per RFC 2544) during label pop 903 (i.e. MPLS to IP) or penultimate hop popping (PHP) using "imp- 904 null" outgoing label. 906 Test Setup 908 In addition to setup described in Section 6, the test tool must be 909 set up to advertise the IP prefix(es) (using a routing protocol as 910 per Section 4.1.2) and associated MPLS label-FEC binding with a 911 reserved MPLS label value = 3 (using a label distribution protocol 912 as per Section 4.1.3) on its receive ports Bp. The test tool must 913 learn the IP prefix(es) as well as the MPLS label-FEC bindings on 914 its transmit ports Ap. The test tool then must use the learned 915 MPLS label values and learned IP prefix values in the frames 916 transmitted on ports Ap to DUT. The test tool must receive frames 917 containing IP packets on receive ports Bp (from DUT). 919 MPLS and/or label distribution protocol must be enabled on the 920 test tool ports Bp and Ap, and DUT ports DBp and DAp. 922 Discussion 923 This test case characterizes the Penultimate Hop Popping (PHP), 924 which is described in RFC3031. 926 The DUT's MPLS forwarding table (also referred to as ILM to NHLFE 927 mapping table per Section 3.11 of [RFC3031]) must contain a 928 reserved MPLS label value = 3 (e.g. pop or imp-null) as the 929 outgoing label for the learned prefix(es), resulting in MPLS-to-IP 930 forwarding operation. 932 This test case characterizes DUT's penultimate hop popping (PHP) 933 functionality. 935 Procedure 937 Please see Test Procedure in Section 6. Additionally, the test 938 tool must send frames containing MPLS packets on its transmit 939 ports Ap (with IP destination belonging to advertised IP 940 prefix(es)), and expect to receive frames containing IP packets on 941 its receive ports Bp, as described in Section 4.1.4.4. 943 Reporting Format 945 The result should be reported as per Section 5 and as per RFC2544. 947 Results for each test SHOULD be in the form of a table with a row 948 for each of the tested frame sizes. 950 6.2. Latency Measurement 952 This measures the time taken by the DUT to forward the MPLS packet 953 during various MPLS switching paths such as IP-to-MPLS or MPLS-to- 954 MPLS or MPLS-to-IP involving an MPLS label stack. 956 Objective 958 To obtain the average latency induced by the DUT during MPLS 959 packet forwarding for each of five forwarding operations. 961 Test Setup 963 Follow the Test Setup guidelines established for each of four MPLS 964 forwarding operations in Section 6.1.1 (for IP-to-MPLS), 6.1.2 965 (for MPLS-to-MPLS), 6.1.3 (for MPLS-to-IP Unlabeled), 6.1.4 (for 966 MPLS-to-IP Aggregate) and 6.1.5 (for MPLS-to-IP PHP) one by one. 968 Procedure 970 Please refer to Section 26.2 in RFC2544 in addition to following 971 the associated procedure for each MPLS forwarding operation in 972 accord with the Test Setup described earlier: 974 IP-to-MPLS forwarding (Push) Section 6.1.1 975 MPLS-to-MPLS forwarding (Swap) Section 6.1.2 976 MPLS-to-IP forwarding (Pop) Section 6.1.3 977 MPLS-to-IP forwarding (Aggregate) Section 6.1.4 978 MPLS-to-IP forwarding (PHP) Section 6.1.5 980 Reporting Format 982 The result should be reported as per Section 5 and as per RFC2544. 984 6.3. Frame Loss Rate Measurement (FLR) 986 This measures the percentage of MPLS frames that were not forwarded 987 during various switching paths such as IP-to-MPLS (push) or MPLS-to- 988 IP (swap) or MPLS-IP (pop) by the DUT under overloaded state. 990 Please refer to RFC2544 Section 26.3 for more details. 992 Objective 994 To obtain the frame loss rate, as defined in RFC1242, for each of 995 three MPLS forwarding operations of a DUT, throughout the range of 996 input data rates and frame sizes. 998 Test Setup 1000 Follow the Test Setup guidelines established for each of four MPLS 1001 forwarding operations in Section 6.1.1 (for IP-to-MPLS), 6.1.2 1002 (for MPLS-to-MPLS), 6.1.3 (for MPLS-to-IP Unlabeled), 6.1.4 (for 1003 MPLS-to-IP Aggregate) and 6.1.5 (for MPLS-to-IP PHP) one by one. 1005 Procedure 1006 Please refer to Section 26.3 of RFC 2544 RFC2544 and follow the 1007 associated procedure for each MPLS forwarding operation one-by-one 1008 in accord with the Test Setup described earlier: 1010 IP-to-MPLS forwarding (Push) Section 6.1.1 1011 MPLS-to-MPLS forwarding (Swap) Section 6.1.2 1012 MPLS-to-IP forwarding (Pop) Section 6.1.3 1013 MPLS-to-IP forwarding (Aggregate) Section 6.1.4 1014 MPLS-to-IP forwarding (PHP) Section 6.1.5 1016 A misdirected frame, that is a frame received on the wrong Bn, is 1017 considered as lost. If the test tool is capable of checking 1018 received MPLS label values, a frame with the wrong MPLS label is 1019 considered as lost. 1021 Reporting Format 1023 The result should be reported as per Section 5 and as per RFC2544. 1025 6.4. System Recovery 1027 Objective 1029 To characterize the speed at which a DUT recovers from an overload 1030 condition. 1032 Test Setup 1034 Follow the Test Setup guidelines established for each of five MPLS 1035 forwarding operations in Section 6.1.1 (for IP-to-MPLS), 6.1.2 1036 (for MPLS-to-MPLS), 6.1.3 (for MPLS-to-IP Unlabeled), 6.1.4 (for 1037 MPLS-to-IP Aggregate) and 6.1.5 (for MPLS-to-IP PHP) one by one. 1039 Procedure 1041 Please refer to Section 26.5 of RFC2544 and follow the associated 1042 procedure for each MPLS forwarding operation in the referenced 1043 Sections one-by-one in accord with the Test Setup described 1044 earlier: 1046 IP-to-MPLS forwarding (Push) Section 6.1.1 1047 MPLS-to-MPLS forwarding (Swap) Section 6.1.2 1048 MPLS-to-IP forwarding (Pop) Section 6.1.3 1049 MPLS-to-IP forwarding (Aggregate) Section 6.1.4 1050 MPLS-to-IP forwarding (PHP) Section 6.1.5 1052 Reporting Format 1054 The result should be reported as per Section 5 and as per RFC2544. 1056 6.5. Reset 1058 The 'reset' aspects of benchmarking are described in [RFC2544], 1059 but these procedures need to be clarified in order to ensure 1060 consistency. This document does not specify the reset procedures. 1061 These need to be addressed in a separate document and will more 1062 generally apply to IP and MPLS test cases. 1064 The text below describes the MPLS forwarding benchmarking specific 1065 setup that will have to be used in conjuction with the procedures 1066 from the separate document to make this test case meaningful. 1068 Objective 1070 To characterize the speed at which a DUT recovers from a device or 1071 software reset. 1073 Test Setup 1075 Follow the Test Setup guidelines established for each of four MPLS 1076 forwarding operations in Section 6.1.1 (for IP-to-MPLS), 6.1.2 1077 (for MPLS-to-MPLS), 6.1.3 (for MPLS-to-IP Unlabeled), 6.1.4 (for 1078 MPLS-to-IP Aggregate) and 6.1.5 (for MPLS-to-IP PHP) one by one. 1080 For this testcase, the requirements of LDP and a routing protocol 1081 are removed and replaced by static configurations. For the IP-to- 1082 MPLS forwarding, static route configurations should be applied. 1083 For the MPLS-to-MPLS and MPLS-to-IP, static label configurations 1084 must be applied. 1086 For this test, all graceful-restart features MUST be disabled. 1088 Discussion 1089 This test case is intended to provide an insight into how long an 1090 MPLS device could take to be fully operational after any of the 1091 reset events. It is quite likely that the time an IP/MPLS device 1092 takes to become fully operational after any of the reset events 1093 may be different from that of an IP only device. 1095 Modern devices now have many more reset options that were not 1096 available when section 26.6 of RFC2544 was published. Moreover, 1097 different reset events on modern devices may produce different 1098 results, hence, needing clarity and consistency in reset 1099 procedures beyond what's specified in RFC2544. 1101 Procedure 1103 Please follow the procedure from the separate document for each 1104 MPLS forwarding operation one-by-one: 1106 IP-to-MPLS forwarding (Push) Section 6.1.1 1107 MPLS-to-MPLS forwarding (Swap) Section 6.1.2 1108 MPLS-to-IP forwarding (Pop) Section 6.1.3 1109 MPLS-to-IP forwarding (Aggregate) Section 6.1.4 1110 MPLS-to-IP forwarding (PHP) Section 6.1.5 1112 Reporting Format 1114 The result should be reported as per section 5 and as per the 1115 separate document. 1117 7. Security Considerations 1119 Benchmarking activities, as described in this memo, are limited to 1120 technology characterization using controlled stimuli in a laboratory 1121 environment, with dedicated address space and the constraints 1122 specified in the sections above. 1124 The benchmarking network topology will be an independent test setup 1125 and MUST NOT be connected to devices that may forward the test 1126 traffic into a production network or misroute traffic to the test 1127 management network. 1129 Furthermore, benchmarking is performed on a "black-box" basis, 1130 relying solely on measurements observable external to the DUT/SUT. 1132 Special capabilities SHOULD NOT exist in the DUT/SUT specifically 1133 for benchmarking purposes. Any implications for network security 1134 arising from the DUT/SUT SHOULD be identical in the lab and in 1135 production networks. 1137 There are no specific security considerations within the scope of 1138 this document. 1140 8. IANA Considerations 1142 There are no considerations for IANA at this time. 1144 9. Acknowledgement 1146 The authors would like to thank Mo Khalid, who motivated us to write 1147 this document. We would like to thank Rodney Dunn, Chip Popoviciu, 1148 Jeff Byzek, Jay Karthik, Rajiv Papneja, Samir Vapiwala, Silvija 1149 Andrijic Dry, Scott Bradner, Al Morton and Bill Cerveny for their 1150 careful review and suggestions. 1152 This document was prepared using 2-Word-v2.0.template.dot. 1154 10. References 1156 10.1. Normative References 1158 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1159 Requirement Levels", BCP 14, RFC 2119, March 1997. 1161 [RFC2544] Bradner, S. and McQuaid, J., "Benchmarking Methodology for 1162 Network Interconnect Devices", RFC 2544, March 1999. 1164 [RFC1242] Bradner, S., Editor, "Benchmarking Terminology for Network 1165 Interconnection Devices", RFC 1242, July 1991. 1167 [RFC3031] Rosen et al., "Multiprotocol Label Switching 1168 Architecture", RFC 3031, August 1999. 1170 [RFC3032] Rosen et al., "MPLS Label Stack Encoding", RFC 3032, 1171 January 2001. 1173 [RFC3107] Rosen, E. and Rekhter, Y., "Carrying Label Information in 1174 BGP-4", RFC 3107, May 2001. 1176 [RFC5036] Andersson, L., Doolan, P., Feldman, N., Fredette, A. and 1177 B. Thomas, "LDP Specification", RFC 5036, January 2001. 1179 10.2. Informative References 1181 [RFC5180] Popoviciu, C., et al, "IPv6 Benchmarking Methodology for 1182 Network Interconnect Devices", RFC 5180, May 2008. 1184 [RFC3209] Awduche, et al., "RSVP-TE: Extensions to RSVP for LSP 1185 Tunnels", RFC 3209, Dec 2001. 1187 [RFC4364] Rosen E. and Rekhter Y., "BGP/MPLS IP Virtual Private 1188 Networks (VPNs)", RFC4364, February 2006. 1190 [RFC4271] Rekhter, Y. and T. Li, "Framework for Layer 2 Virtual 1191 Private Networks (L2VPNs)", RFC 4664, Sep 2006. 1193 [RFC4664] Rosen, E. and Andersson L., " A Border Gateway Protocol 4 1194 (BGP-4)", RFC 4271, Jan 2006. 1196 [IEE8021] Mick Seaman (editor), "IEEE Std 802.1D-2004, MAC Bridges", 1197 Feb 2004. 1199 [IEE8023] LAN/MAN Standards Committee of the IEEE Computer Society, 1200 "IEEE Std 802.3as-2006, Part 3: Carrier Sense Multiple 1201 Access with Collision Detection (CSMA/CD) Access Method 1202 and Physical Layer Specifications, Amendment 3: Frame 1203 format extensions", Nov 2006. 1205 [RFC3443] Agarwal, P. and Akyol, B., "Time To Live (TTL) Processing 1206 in MPLS Networks", RFC3443, Jan 2003. 1208 [RFC2328] Moy, J., "OSPF Version 2", RFC2328, April 1998. 1210 [RFC5462] Asati, R. and Andersson, L., "Multi-Protocol Label 1211 Switching (MPLS) label stack entry: "EXP" field renamed to 1212 "Traffic Class" field", RFC5462, Feb 2009. 1214 [RFC4928] Swallow, et al., "Avoiding Equal Cost Multipath Treatment 1215 in MPLS Networks", RFC4928, June 2007. 1217 [RFC4090] Pan, et al., "Fast Reroute Extensions to RSVP-TE for LSP 1218 Tunnels", RFC4090, May 2005. 1220 Author's Addresses 1222 Aamer Akhter 1223 Cisco Systems 1224 7025 Kit Creek Road 1225 RTP, NC 27709 1226 USA 1228 Email: aakhter@cisco.com 1230 Rajiv Asati 1231 Cisco Systems 1232 7025 Kit Creek Road 1233 RTP, NC 27709 1234 USA 1236 Email: rajiva@cisco.com 1238 Carlos Pignataro 1239 Cisco Systems 1240 7200-12 Kit Creek Road 1241 RTP, NC 27709 1242 USA 1244 Email: cpignata@cisco.com