idnits 2.17.1 draft-ietf-bmwg-mpls-forwarding-meth-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 18. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 786. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 760. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 767. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 773. 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 : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([RFC1242], [RFC2544]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust 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.) -- The document date (November 3, 2008) is 5650 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 3107 (Obsoleted by RFC 8277) Summary: 3 errors (**), 0 flaws (~~), 1 warning (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group Aamer Akhter 2 Internet Draft Cisco Systems 3 Intended status: Informational 4 Expires: May 2009 Rajiv Asati 5 Cisco Systems 7 November 3, 2008 9 MPLS Forwarding Benchmarking Methodology 10 draft-ietf-bmwg-mpls-forwarding-meth-01.txt 12 Status of this Memo 14 By submitting this Internet-Draft, each author represents that 15 any applicable patent or other IPR claims of which he or she is 16 aware have been or will be disclosed, and any of which he or she 17 becomes aware will be disclosed, in accordance with Section 6 of 18 BCP 79. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as Internet- 23 Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six 26 months and may be updated, replaced, or obsoleted by other documents 27 at any time. It is inappropriate to use Internet-Drafts as 28 reference material or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html 36 This Internet-Draft will expire on May 3, 2009. 38 Abstract 40 This document describes a methodology specific to the benchmarking 41 of MPLS forwarding devices, limited to various types of packet- 42 forwarding and delay measurements. It builds upon the tenets set 43 forth in RFC2544 [RFC2544], RFC1242 [RFC1242] and other IETF 44 Benchmarking Methodology Working Group (BMWG) efforts. This 45 document seeks to extend these efforts to the MPLS paradigm. 47 Table of Contents 49 1. Introduction...................................................2 50 2. Document Scope.................................................3 51 3. Key Words to Reflect Requirements..............................3 52 4. Test Methodology...............................................3 53 4.1. Test Considerations..........................................4 54 4.1.1. IGP Support................................................5 55 4.1.2. Label Distribution Support.................................5 56 4.1.3. Frame Sizes................................................5 57 4.1.4. Time-to-Live (TTL) or Hop Limit............................6 58 4.1.5. Trial Duration.............................................6 59 4.1.6. Address Resolution and Dynamic Protocol State..............7 60 4.1.7. Abbreviations Used.........................................7 61 5. Reporting Format...............................................7 62 6. MPLS Forwarding Benchmarking Tests.............................8 63 6.1. Throughput..................................................11 64 6.1.1. Throughput for MPLS Label Imposition......................11 65 6.1.2. Throughout for MPLS Label Swap............................12 66 6.1.3. Throughout for MPLS Label Disposition.....................13 67 6.1.4. Throughput for MPLS Label Disposition (Aggregate).........14 68 6.2. Latency Measurement.........................................15 69 6.3. Frame Loss Rate Measurement (FLR)...........................15 70 6.4. System Recovery.............................................16 71 6.5. Reset.......................................................17 72 7. Security Considerations.......................................18 73 8. IANA Considerations...........................................18 74 9. Acknowledgement...............................................18 75 10. References...................................................19 76 10.1. Normative References.......................................19 77 10.2. Informative References.....................................19 78 Author's Addresses...............................................20 79 Intellectual Property Statement..................................20 80 Disclaimer of Validity...........................................21 81 Copyright Statement..............................................21 83 1. Introduction 85 Over the past several years MPLS networks have gained greater 86 popularity. However, there is no standard method to compare and 87 contrast the varying implementations and their strong and weak 88 points. This document proposes a methodology using common criteria 89 for the comparison of various implementations of basic MPLS 90 forwarding devices. 92 The terms used in this document remain consistent with those defined 93 in "Benchmarking Terminology for Network Interconnect Devices" 94 RFC1242 [RFC1242]. This terminology SHOULD be consulted before using 95 or applying the recommendations of this document. 97 2. Document Scope 99 The purpose of this draft is to describe a methodology specific to 100 the benchmarking of MPLS forwarding devices. The scope of this 101 benchmarking will be limited to various types of packet-forwarding 102 and delay measurements in a laboratory setting. It builds upon the 103 tenets set forth in RFC2544 [RFC2544], RFC1242 [RFC1242] and other 104 IETF Benchmarking Methodology Working Group (BMWG) efforts. 106 MPLS [RFC3031] is a foundation enabling technology for other more 107 advanced technologies such as Layer 3 MPLS-VPNs, Layer 2 MPLS-VPNs, 108 and MPLS Traffic Engineering. This document focuses on MPLS 109 forwarding characterization. This document is not a replacement for, 110 but a complement to, RFC 2544. 112 3. Key Words to Reflect Requirements 114 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 115 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 116 document are to be interpreted as described in BCP 14, RFC 2119 117 [RFC2119]. RFC 2119 defines the use of these key words to help make 118 the intent of standards track documents as clear as possible. While 119 this document uses these keywords, this document is not a standards 120 track document. 122 4. Test Methodology 124 The set of methodologies described in this document will use the 125 topologies described in this section. An effort has been made to 126 exclude superfluous equipment needs such that each test can be 127 carried out with the minimum number of requirements. 129 Figure 1 illustrates the sample topology in which the DUT is 130 connected to the test ports on the test tool. 132 +-----------------+ 133 +---------+ | | +---------+ 134 | Test | | | | Test | 135 | Port A1 +-----+ DA1 DB1 -----+ Port B1 | 136 +---------+ | | +---------+ 137 +---------+ | DUT | +---------+ 138 | Test | | | | Test | 139 | Port A2 +-----+ DA2 DB2 +-----+ Port B2 | 140 +---------+ | | +---------+ 141 ... | | ... 142 +---------+ | | +---------+ 143 | Test | +-----------------+ | Test | 144 | Port Ap | | Port Bp | 145 +---------+ +---------+ 147 Figure 1 Topology #1 for MPLS Forwarding Benchmarking 149 p = number of ports; determined by the maximum unidirectional 150 forwarding throughput of the DUT and the load capacity of the media 151 between the Test Ports and DUT. 153 For example, if the DUT's forwarding throughput is 100 frames per 154 second (fps), and the media capacity is 50 fps, then p = 2. 156 The exact throughput is a measured quantity obtained through 157 testing. Throughput may vary depending on the number of ports used, 158 and other factors. The number of ports used (p) SHOULD be reported 159 for both Tx and Rx sides of DUT. Please see Test Setup in section 6. 161 4.1. Test Considerations 163 This methodology assumes a full-duplex uniform medium topology. The 164 medium used MUST be reported in each test result. Issues regarding 165 mixed transmission media, speed mismatches, media header differences 166 etc, are not under consideration. Traffic-affecting features such as 167 Flow control, QoS, Graceful Restart etc. MUST be disabled, unless 168 explicitly requested in the test case. Additionally, any non- 169 essential traffic MUST also be avoided. 171 4.1.1. IGP Support 173 It is highly RECOMMENDED that all of the interfaces (A1, DA1, DB1, 174 A2..) on DUT and test tool support an IGP such as IS-IS, OSPF, 175 EIGRP, RIP etc. Furthermore, there are testing considerations in 176 this document that the device is able to provide a stable control- 177 plane during heavy forwarding workloads. The route distribution 178 method used (OSPF, IS-IS, EIGRP, RIP etc.) MUST be reported. 180 4.1.2. Label Distribution Support 182 The DUT and test tool must support at least one protocol for 183 exchanging MPLS labels. The DUT and test tool MUST be capable of 184 learning and advertising MPLS label bindings via the chosen 185 protocol(s), and use them during packet forwarding all the time 186 (including when the label bindings change). The most commonly used 187 protocols are Label Distribution Protocol (LDP) [RFC5036], Resource 188 Reservation Protocol-Traffic Engineering (RSVP-TE) [RFC5151] and 189 Border Gateway Protocol (BGP) [RFC3107]. 191 All of the interfaces connected to the DUT such as A1, DA1, DB1, A2 192 etc., SHOULD support LDP, RSVP-TE, and BGP for IPv4 or IPv6 193 Forwarding Equivalence Classes (FECs). 195 This document discourages the use of static label to establish the 196 MPLS label switched paths, since it is not commonly used in the 197 production networks. 199 4.1.3. Frame Sizes 201 Each test SHOULD be run with different (layer 2) frame sizes in 202 different trials. The recommended sizes for IPv4 are 64, 128, 256, 203 512, 1024, 1280 and 1518. Recommended sizes for other media can be 204 found in RFC 2544 and IPv6 Benchmarking [RFC5180]. Frame sizes MUST 205 be based on the pre-MPLS shim version of the frame. 207 In addition to the individual frame size trials, results MAY also be 208 collected with multiple simultaneous frame sizes (sometimes referred 209 to as an IMIX to simulate real network traffic according to the 210 frame size ordering and usage). There is no standard for mixtures of 211 frame sizes, and the results are subject to wide interpretation. See 212 section 18 of RFC 2544. 214 When running trials using multiple simultaneous frame sizes, the DUT 215 configuration MUST remain the same. 217 4.1.4. Time-to-Live (TTL) or Hop Limit 219 The MPLS TTL or IPv4 TTL or IPv6 Hop Limit (depending on which 220 portion of the frame the DUT is basing the forwarding behavior) MUST 221 be large enough to traverse the DUT. 223 If TTL/Hop Limit Decrement is a configurable option on the DUT, the 224 setting SHOULD be reported. 226 4.1.5. Trial Duration 228 Unless otherwise specified, the test portion of each trial SHOULD be 229 no less than 30 seconds when static routing is in place, and no less 230 than 200 seconds when a dynamic routing protocol and LDP (default 231 LDP holddown timer is 180 seconds) are being used. 233 The longer trial time used for dynamic routing protocols is to 234 verify that the DUT is able to maintain a stable control plane when 235 the data-forwarding plane is under stress. 237 4.1.5.1. Traffic Verification 239 In all cases, sent traffic MUST be accounted for, whether it was 240 received on the wrong port, correct port or not received at all. 241 Specifically, traffic loss (also referred to as frame loss) is 242 defined as the traffic (i.e. one or more frames) not received where 243 expected (i.e. received on incorrect port, or received with 244 incorrect layer2 or above header information etc.). In addition, 245 presence or absence of MPLS header, ethertype (0x8847 vs. 0x0800), 246 checksum, frame sequencing and correct MPLS TTL decrementing, MUST 247 be verified in the received frame. 249 Many test tools may, by default, only verify that they have received 250 the embedded signature on the receive side. However, for MPLS header 251 presence verification, some tests will require the MPLS header to be 252 imposed while others will require a swap or disposition. Hence, this 253 document requires the test tool to verify the MPLS stack depth. An 254 even greater level of verification would be to check if the correct 255 label was imposed, but that is out of scope for these tests. 257 4.1.6. Address Resolution and Dynamic Protocol State 259 If the test or media is making use of a dynamic protocol (eg ARP, 260 OSPF, LDP), all state for the protocols should be pre-established 261 before the start of the trial. 263 4.1.7. Abbreviations Used 265 Please refer to Figure 1, "Port based Remote Network" for a topology 266 view of the network. The following abbreviations are used in this 267 document - 269 M := Module Side (could be A or B) 271 P := port number 273 RN := Remote Network (can also be thought of as a network that is 274 reachable via Mp). 276 Y := number of network. (i.e. the first network reachable via B1 277 would be called B1RN1 and the 5th network would be called B1RN5) 279 5. Reporting Format 281 For each test case, it is RECOMMENDED that the following variables 282 be reported in addition to the specific parameters requested by the 283 test case: 285 Parameter Units or Examples 287 Internet Protocol IPv4, IPv6, Dual-Stack 289 Label Distribution Protocol LDP, RSVP-TE, BGP (or 290 combinations) 292 MPLS Forwarding Operation Imposition, Swap, 293 Disposition 295 IGP ISIS, OSPF, EIGRP, RIP, 296 static. 298 Throughput Frames per second 300 Interface Type GigE, POS, ATM etc 302 Interface Speed 1 gbps, 100 Mbps, etc 304 Interface Encapsulation VLAN, PPP, HDLC 306 Frame Size Bytes 308 Number of A and B 1A, 2B 309 interfaces (see Figure 1) 311 The individual test cases may have additional reporting requirements 312 that may refer to other RFCs. 314 6. MPLS Forwarding Benchmarking Tests 316 MPLS is a different forwarding paradigm from IP. Unlike IP packet 317 and IP forwarding, an MPLS packet may contain more than one MPLS 318 header and may go through one of three forwarding operations - 319 imposition, swap and disposition. Such characteristics desire 320 further granularity in MPLS forwarding benchmarking than those 321 described in RFC2544. Thus the benchmarking includes, but is not 322 limited to: 324 1. Throughput 326 2. Latency 327 3. Frame Loss rate 329 4. System Recovery 331 5. Reset 333 6. MPLS EXP field Operations (including explicit-null cases) 335 7. Negative Scenarios (TTL expiry, etc) 337 8. Multicast 339 This document focuses on the first five categories, inline with the 340 spirit of RFC2544. All the benchmarking test cases described in this 341 document are expected to, at a minimum, follow the 'Test Setup' and 342 'Test Procedure' below - 344 Test Setup 346 Referring to Figure 1, a single A and B interface SHOULD be used 347 (p = 1 SHOULD be used). However, if the forwarding throughput of 348 the DUT is more than that of the media rate of a single interface, 349 then additional A and B interfaces MUST be enabled so as to exceed 350 the DUT's forwarding throughput. In such case, the tool traffic 351 should use IP addresses assigned to BpRN1 and BpAN as the IP 352 destinations and conform to section 16 of RFC 2544. 354 Test Procedure (Refer to section 26 of RFC 2544) 356 Send traffic from port(s) Ap towards DUT at a constant load 357 towards IP prefixes (BpRN1 addresses) advertised by the tool on 358 the receive ports, for a fixed time interval. 360 If any frame loss is detected, a new iteration is needed where the 361 offered load is decreased and the sender will transmit again. An 362 iterative search algorithm MUST be used to determine the maximum 363 offered frame rate with a zero frame loss. 365 Each iteration should involve varying the offered load of the 366 traffic, while keeping the other parameters (test duration, number 367 of interfaces, number of addresses, frame size etc) constant, 368 until the maximum rate at which none of the offered frames are 369 dropped is determined. 371 6.1. Throughput 373 This section contains the description of the tests that are related 374 to the characterization of DUT's MPLS traffic forwarding. 376 6.1.1. Throughput for MPLS Label Imposition 378 Objective 380 To obtain the DUT's Throughput (as per RFC 2544) during label 381 imposition (i.e. IP to MPLS). 383 Test Setup 385 In addition to setup described in section 6, the test tool should 386 advertise the IP prefix(es) i.e. RNx(using a routing protocol as 387 per section 1.1) and associated MPLS label (using a label 388 distribution protocol as per section 1.2) on its receive ports Bp 389 to DUT. The test tool may learn these IP prefixes on its transmit 390 ports Ap from DUT. 392 Discussion 394 The DUT's MPLS forwarding table must contain a non-reserved MPLS 395 label value as the outgoing label for the learned prefix, 396 resulting in IP-to-MPLS forwarding operation. The test tool must 397 receive MPLS packets on receive ports Bp (from DUT) with the same 398 label values that are advertised. 400 Procedure 402 Please see Test Procedure in section 6. Additionally, the test 403 tool MUST send unlabeled IP packets on transmit ports Ap (with IP 404 destination belonging to above IP prefix(es)), and expect to 405 receive MPLS packets on receive ports Bp. 407 Reporting Format 409 Same as RFC2544 and the parameters of section 5. 411 Results for each test SHOULD be in the form of a table with a row 412 for each of the tested frame sizes. Additional columns SHOULD 413 include: offered load and measured throughput. 415 6.1.2. Throughout for MPLS Label Swap 417 Objective 419 To obtain the DUT's Throughput (as per RFC 2544) during label 420 swapping (i.e. MPLS to MPLS). 422 Test Setup 424 In addition to setup described in section 6, the test tool must be 425 set up to advertise IP prefix (using a routing protocol as per 426 section 1.1) and associated MPLS label (using a label distribution 427 protocol as per section 1.2) on the receive ports Bp, and learn 428 the IP prefix(es) with the appropriate MPLS labels on the transmit 429 ports Ap. The test tool then must use the learned MPLS label 430 values and learned IP prefix values in MPLS packets transmitted on 431 ports Ap. 433 Discussion 435 The DUT's MPLS forwarding table must contain non-reserved MPLS 436 label values as the outgoing and incoming labels for the learned 437 prefix, resulting in MPLS-to-MPLS forwarding operation. The test 438 tool must receive MPLS packets on receive ports Bp (from DUT). The 439 received MPLS packets must contain the same number of MPLS headers 440 as those of transmitted MPLS Packets. 442 Procedure 444 Please see Test Procedure in section 6. Additionally, the test 445 tool must send MPLS packets on its transmit ports Ap (with IP 446 destination belonging to advertised IP prefix(es)), and expect to 447 receive MPLS packets on its receive ports Bp. 449 Reporting Format 451 Same as RFC2544 and the parameters of section 5. 453 Results for each test SHOULD be in the form of a table with a row 454 for each of the tested frame sizes. 456 6.1.3. Throughout for MPLS Label Disposition 458 Objective 460 To obtain the DUT's Throughput (as per RFC 2544) during label 461 disposition (i.e. MPLS to IP) using "Untagged" outgoing label. 463 Test Setup 465 In addition to setup described in section 6, the test tool must be 466 set up to advertise the IP prefix(es) (using a routing protocol as 467 per section 1.1) without any MPLS label on the receive ports Bp, 468 and learn the IP prefix(es) with the appropriate MPLS labels on 469 the transmit ports Ap. The test tool then must use the learned 470 MPLS label values and learned IP prefix values in MPLS packets 471 transmitted on ports Ap. 473 Discussion 475 The DUT's MPLS forwarding table must contain an untagged outgoing 476 label for the learned prefix, resulting in MPLS-to-IP forwarding 477 operation. The test tool must receive IP packets on receive ports 478 Bp (from DUT). 480 Procedure 482 Please see Test Procedure in section 6. Additionally, the test 483 tool must send MPLS packets on its transmit ports Ap (with IP 484 destination belonging to advertised IP prefix(es)), and expect to 485 receive IP packets on its receive ports Bp. 487 Reporting Format 489 Same as RFC2544 and the parameters of section 5. 491 Results for each test SHOULD be in the form of a table with a row 492 for each of the tested frame sizes. 494 6.1.4. Throughput for MPLS Label Disposition (Aggregate) 496 Objective 498 To obtain the DUT's Throughput (as per RFC 2544) during label 499 disposition (i.e. MPLS to IP) using "Aggregate" outgoing label. 501 Test Setup 503 In addition to setup described in section 6, the DUT should be 504 provisioned such that it allocates an aggregate outgoing label to 505 a prefix (where the prefix may be a 'BGP aggregated prefix' , 'BGP 506 VPN connected prefix' or an IGP aggregation that results in an 507 aggregate label, etc. and must include the addresses belonging to 508 the DUT receive ports Bp). 510 The DUT must advertise the IP prefix(es) along with the MPLS 511 label(s) via a label distribution protocol to the test tool on 512 tool transmit ports Ap. 514 The test tool then must use the learned MPLS label values and 515 learned IP prefix values in MPLS packets transmitted on ports Ap. 517 Discussion 519 The DUT's MPLS forwarding table must contain an aggregate outgoing 520 label and IP forwarding table must contain a valid entry for the 521 learned prefix, resulting in MPLS-to-IP forwarding operation (i.e. 522 MPLS header removal followed by IP lookup). The test tool must 523 receive IP packets on receive ports Bp (from DUT). 525 Procedure 527 Please see Test Procedure in section 6. Additionally, the test 528 tool must send MPLS packets on its transmit ports Ap (with IP 529 destination belonging to advertised IP prefix(es)), and expect to 530 receive IP packets on its receive ports Bp. 532 Reporting Format 534 Same as RFC2544 and the parameters of section 5. 536 Results for each test SHOULD be in the form of a table with a row 537 for each of the tested frame sizes. 539 6.2. Latency Measurement 541 This measures the time taken by the DUT to forward the MPLS packet 542 during various MPLS switching paths such as IP-to-MPLS or MPLS-to- 543 MPLS or MPLS-to-IP involving one or more MPLS headers. 545 Objective 547 To obtain the maximum latency induced by the DUT during MPLS 548 packet forwarding for each of three forwarding operations. 550 Test Setup 552 Follow the Test Setup guidelines established for each of three 553 MPLS forwarding operations in section 6.1.1 (for IP-to-MPLS), 554 6.1.2 (for MPLS-to-MPLS) ), and 6.1.3 and 6.1.4 (for MPLS-to-IP) 555 one by one. 557 Procedure 559 Please refer to section 26.2 in RFC2544 in addition to following 560 the associated procedure for each MPLS forwarding operation in 561 accord with the Test Setup described earlier - 563 IP-to-MPLS forwarding (Imposition) Section 6.1.1 564 MPLS-to-MPLS forwarding (Swap) Section 6.1.2 565 MPLS-to-IP forwarding (Disposition) Section 6.1.3 566 MPLS-to-IP forwarding (Aggregate) Section 6.1.4 568 Reporting Format 570 Same as RFC2544 and the parameters of section 5. 572 6.3. Frame Loss Rate Measurement (FLR) 574 This measures the percentage of MPLS frames that were not forwarded 575 during various switching paths such as IP-to-MPLS (imposition) or 576 MPLS-to-IP (swap) or MPLS-IP (disposition) by the DUT under 577 overloaded state. 579 Please refer to RFC2544 section 26.3 for more details. 581 Objective 583 To obtain the frame loss rate, as defined in RFC1242, for each of 584 three MPLS forwarding operations of a DUT, throughout the range of 585 input data rates and frame sizes. 587 Test Setup 589 Follow the Test Setup guidelines established for each of three 590 MPLS forwarding operations in section 6.1.1 (for IP-to-MPLS), 591 6.1.2 (for MPLS-to-MPLS), and 6.1.3 and 6.1.4 (for MPLS-to-IP) and 592 procedure one by one. 594 Procedure 596 Please refer to section 26.3 of RFC 2544 RFC2544 and follow the 597 associated procedure for each MPLS forwarding operation one-by-one 598 in accord with the Test Setup described earlier - 600 IP-to-MPLS forwarding (Imposition) Section 6.1.1 601 MPLS-to-MPLS forwarding (Swap) Section 6.1.2 602 MPLS-to-IP forwarding (Disposition) Section 6.1.3 603 MPLS-to-IP forwarding (Aggregate) Section 6.1.4 605 Reporting Format 607 Same as RFC2544 and the parameters of section 5. 609 6.4. System Recovery 611 Objective 613 To characterize the speed at which a DUT recovers from an overload 614 condition. 616 Test Setup 618 Follow the Test Setup guidelines established for each of three 619 MPLS forwarding operations in section 6.1.1 (for IP-to-MPLS), 620 6.1.2 (for MPLS-to-MPLS) and 6.1.3 (for MPLS-to-IP) and procedure 621 one by one. 623 Procedure 625 Please refer to RFC2544 and follow the associated procedure for 626 each MPLS forwarding operation in the referenced sections one-by- 627 one in accord with the Test Setup described earlier - 629 IP-to-MPLS forwarding (Imposition) Section 6.1.1 630 MPLS-to-MPLS forwarding (Swap) Section 6.1.2 631 MPLS-to-IP forwarding (Disposition) Section 6.1.3 632 MPLS-to-IP forwarding (Aggregate) Section 6.1.4 634 Reporting Format 636 Same as RFC2544 and the parameters of section 5. 638 6.5. Reset 640 Objective 642 To characterize the speed at which a DUT recovers from a device or 643 software reset. 645 Test Setup 647 Follow the Test Setup guidelines established for each of three 648 MPLS forwarding operations in section 6.1.1 (for IP-to-MPLS), 649 6.1.2 (for MPLS-to-MPLS) and 6.1.3 (for MPLS-to-IP) and procedure 650 one by one. 652 For this test, all graceful-restart features MUST be disabled. 654 Procedure 656 Please refer to RFC2544 section 26.5. Examples of hardware and 657 software resets are: 659 Hardware reset - forwarding module resetting (e.g. OIR). 661 Software reset - reset initiated through a CLI (e.g. reload). 663 Additionally, follow the specific section for procedure (and test 664 Setup) for each MPLS forwarding operation one-by-one - 666 IP-to-MPLS forwarding (Imposition) Section 6.1.1 667 MPLS-to-MPLS forwarding (Swap) Section 6.1.2 668 MPLS-to-IP forwarding (Disposition) Section 6.1.3 669 MPLS-to-IP forwarding (Aggregate) Section 6.1.4 671 Reporting Format 673 Same as RFC2544 and the parameters of section 5 including the 674 specific kind of reset performed. 676 7. Security Considerations 678 Benchmarking activities, as described in this memo, are limited to 679 technology characterization using controlled stimuli in a laboratory 680 environment, with dedicated address space and the constraints 681 specified in the sections above. 683 The benchmarking network topology will be an independent test setup 684 and MUST NOT be connected to devices that may forward the test 685 traffic into a production network or misroute traffic to the test 686 management network. 688 There are no specific security considerations within the scope of 689 this document. 691 8. IANA Considerations 693 There are no considerations for IANA at this time. 695 9. Acknowledgement 697 The authors would like to thank Mo Khalid, who motivated us to write 698 this document. We would like to thank Chip Popoviciu, Jay Karthik, 699 Rajiv Pap, Samir Vapiwala, Silvija Andrijic Dry, Scott Bradner, Al 700 Morton and Bill Cerveny for their careful review and suggestions. 702 10. References 704 10.1. Normative References 706 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 707 Requirement Levels", BCP 14, RFC 2119, March 1997. 709 [RFC2544] Bradner, S. and McQuaid, J., "Benchmarking Methodology for 710 Network Interconnect Devices", RFC 2544, March 1999. 712 [RFC1242] Bradner, S., Editor, "Benchmarking Terminology for Network 713 Interconnection Devices", RFC 1242, July 1991. 715 [RFC3031] Rosen et al., "Multiprotocol Label Switching 716 Architecture", Rosen et al., RFC 3031, August 1999. 718 [RFC3107] Rosen, E. and Rekhter, Y., "Carrying Label Information in 719 BGP-4", RFC 3107, May 2001. 721 [RFC5036] Andersson, L., Doolan, P., Feldman, N., Fredette, A. and 722 B. Thomas, "LDP Specification", RFC 5036, January 2001. 724 10.2. Informative References 726 [RFC5180] Popoviciu, C., et al, "IPv6 Benchmarking Methodology for 727 Network Interconnect Devices", RFC 5180, May 2008. 729 [RFC5151] Farrel, et al, "Inter-Domain MPLS and GMPLS Traffic 730 Engineering --Resource Reservation Protocol-Traffic 731 Engineering (RSVP-TE) Extensions", RFC 5151, Feb 2008. 733 Author's Addresses 735 Aamer Akhter 736 Cisco Systems 737 7025 Kit Creek Road 738 RTP, NC 27709 739 USA 741 Email: aakhter@cisco.com 743 Rajiv Asati 744 Cisco Systems 745 7025 Kit Creek Road 746 RTP, NC 27709 747 USA 749 Email: rajiva@cisco.com 751 Intellectual Property Statement 753 The IETF takes no position regarding the validity or scope of any 754 Intellectual Property Rights or other rights that might be claimed 755 to pertain to the implementation or use of the technology described 756 in this document or the extent to which any license under such 757 rights might or might not be available; nor does it represent that 758 it has made any independent effort to identify any such rights. 759 Information on the procedures with respect to rights in RFC 760 documents can be found in BCP 78 and BCP 79. 762 Copies of IPR disclosures made to the IETF Secretariat and any 763 assurances of licenses to be made available, or the result of an 764 attempt made to obtain a general license or permission for the use 765 of such proprietary rights by implementers or users of this 766 specification can be obtained from the IETF on-line IPR repository 767 at http://www.ietf.org/ipr. 769 The IETF invites any interested party to bring to its attention any 770 copyrights, patents or patent applications, or other proprietary 771 rights that may cover technology that may be required to implement 772 this standard. Please address the information to the IETF at 773 ietf-ipr@ietf.org. 775 Disclaimer of Validity 777 Copyright Statement 779 This document and the information contained herein are provided on 780 an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 781 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE 782 IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL 783 WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY 784 WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE 785 ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS 786 FOR A PARTICULAR PURPOSE. 788 Copyright (C) The IETF Trust (2008). 790 This document is subject to the rights, licenses and restrictions 791 contained in BCP 78, and except as set forth therein, the authors 792 retain all their rights.