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