idnits 2.17.1 draft-ietf-bmwg-acc-bench-meth-06.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 20. -- Found old boilerplate from RFC 3978, Section 5.5 on line 618. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 629. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 636. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 642. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 14 instances of lines with control characters in the document. ** The abstract seems to contain references ([4]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 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 (October 2006) is 6396 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: '6' is mentioned on line 129, but not defined == Unused Reference: '1' is defined on line 549, but no explicit reference was found in the text == Unused Reference: '2' is defined on line 552, but no explicit reference was found in the text == Unused Reference: '3' is defined on line 555, but no explicit reference was found in the text == Unused Reference: '5' is defined on line 562, but no explicit reference was found in the text == Unused Reference: 'RFC3871' is defined on line 567, but no explicit reference was found in the text == Unused Reference: 'NANOG25' is defined on line 571, but no explicit reference was found in the text == Unused Reference: 'IEEECQR' is defined on line 574, but no explicit reference was found in the text == Unused Reference: 'CONVMETH' is defined on line 577, but no explicit reference was found in the text ** Downref: Normative reference to an Informational RFC: RFC 1242 (ref. '1') ** Downref: Normative reference to an Informational RFC: RFC 2285 (ref. '2') ** Downref: Normative reference to an Informational RFC: RFC 2544 (ref. '3') == Outdated reference: A later version (-13) exists of draft-ietf-bmwg-acc-bench-term-10 ** Downref: Normative reference to an Informational draft: draft-ietf-bmwg-acc-bench-term (ref. '4') == Outdated reference: A later version (-23) exists of draft-ietf-bmwg-igp-dataplane-conv-meth-11 Summary: 9 errors (**), 0 flaws (~~), 13 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group 2 INTERNET-DRAFT 3 Expires in: April 2006 4 Scott Poretsky 5 Reef Point Systems 7 Shankar Rao 8 Qwest Communications 10 October 2006 12 Methodology Guidelines for 13 Accelerated Stress Benchmarking 14 16 Intellectual Property Rights (IPR) statement: 17 By submitting this Internet-Draft, each author represents that any 18 applicable patent or other IPR claims of which he or she is aware 19 have been or will be disclosed, and any of which he or she becomes 20 aware will be disclosed, in accordance with Section 6 of BCP 79. 22 Status of this Memo 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF), its areas, and its working groups. Note that 26 other groups may also distribute working documents as 27 Internet-Drafts. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 The list of current Internet-Drafts can be accessed at 35 http://www.ietf.org/ietf/1id-abstracts.txt. 37 The list of Internet-Draft Shadow Directories can be accessed at 38 http://www.ietf.org/shadow.html. 40 Copyright Notice 41 Copyright (C) The Internet Society (2006). 43 ABSTRACT 44 Routers in an operational network are configured with multiple 45 protocols and security policies while simultaneously forwarding 46 traffic and being managed. To accurately benchmark a router for 47 deployment it is necessary to test the router under accelerated 48 operational conditions, which is known as Stress Testing. This 49 document provides the Methodology Guidelines for performing 50 Accelerated Stress Benchmarking of networking devices. 51 Descriptions of Test Topology, Benchmarks and Reporting Format 52 are provided in addition to procedures for conducting various 53 test cases. The methodology is to be used with the companion 54 terminology document [4]. These guidelines can be used as the 55 basis for additional methodology documents that benchmark 56 stress conditions for specific network technologies. 58 for Accelerated Stress Benchmarking 59 Table of Contents 60 1. Introduction ............................................... 2 61 2. Existing definitions ....................................... 3 62 3. Test Setup.................................................. 3 63 3.1 Test Topologies............................................ 3 64 3.2 Test Considerations........................................ 3 65 3.3 Reporting Format........................................... 4 66 3.3.1 Configuration Sets....................................... 5 67 3.3.2 Startup Conditions....................................... 6 68 3.3.3 Instability Conditions................................... 6 69 3.3.4 Benchmarks............................................... 7 70 4. Stress Test Procedure...................................... 8 71 4.1 General Methodology with Multiple Instability Conditions... 8 72 4.2 General Methodology with a Single Instability Condition....10 73 5. IANA Considerations.........................................11 74 6. Security Considerations.....................................11 75 7. Normative References........................................11 76 8. Informative References......................................11 77 9. Author's Address............................................12 79 1. Introduction 80 Router testing benchmarks have consistently been made in a monolithic 81 fashion wherein a single protocol or behavior is measured in an 82 isolated environment. It is important to know the limits for a 83 networking device's behavior for each protocol in isolation, however 84 this does not produce a reliable benchmark of the device's behavior 85 in an operational network. 87 Routers in an operational network are configured with multiple 88 protocols and security policies while simultaneously forwarding 89 traffic and being managed. To accurately benchmark a router for 90 deployment it is necessary to test that router in operational 91 conditions by simultaneously configuring and scaling network 92 protocols and security policies, forwarding traffic, and managing 93 the device. It is helpful to accelerate these network operational 94 conditions with Instability Conditions [4] so that the networking 95 devices are stress tested. 97 This document provides the Methodology for performing Stress 98 Benchmarking of networking devices. Descriptions of Test Topology, 99 Benchmarks and Reporting Format are provided in addition to 100 procedures for conducting various test cases. The methodology is 101 to be used with the companion terminology document [4]. 103 Stress Testing of networking devices provides the following benefits: 104 1. Evaluation of multiple protocols enabled simultaneously as 105 configured in deployed networks 106 2. Evaluation of system and software stability 107 3. Evaluation of manageability under stressful conditions 108 4. Identification of buffer overflow conditions 109 5. Identification of software coding bugs such as: 110 a. Memory leaks 111 b. Suboptimal CPU utilization 112 c. Coding logic 113 for Accelerated Stress Benchmarking 115 These benefits produce significant advantages for network operations: 116 1. Increased stability of routers and protocols 117 2. Hardened routers to DoS attacks 118 3. Verified manageability under stress 119 4. Planning router resources for growth and scale 121 2. Existing definitions 122 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 123 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 124 document are to be interpreted as described in BCP 14, RFC 2119 125 [6]. RFC 2119 defines the use of these key words to help make the 126 intent of standards track documents as clear as possible. While this 127 document uses these keywords, this document is not a standards track 128 document. 130 Terms related to Accelerated Stress Benchmarking are defined in [4]. 132 3. Test Setup 133 3.1 Test Topologies 134 Figure 1 shows the physical configuration to be used for the 135 methodologies provided in this document. The number of interfaces 136 between the tester and DUT will scale depending upon the number of 137 control protocol sessions and traffic forwarding interfaces. A 138 separate device may be required to externally manage the device in 139 the case that the test equipment does not support such 140 functionality. Figure 2 shows the logical configuration for the 141 stress test methodologies. Each plane MAY be emulated by single or 142 multiple test equipment. 144 3.2 Test Considerations 145 The Accelerated Stress Benchmarking test can be applied in 146 service provider test environments to benchmark DUTs under 147 stress in an environment that reflects conditions found in 148 an operational network. A particular Configuration Set is 149 defined and the DUT is benchmarked using this configuration 150 set and the Instability Conditions. Varying Configuration 151 Sets and/or Instability Conditions applied in an iterative 152 fashion can provide an accurate characterization of the DUT 153 to help determine future network deployments. 155 For the management plane SNMP Gets SHOULD be performed 156 continuously. Management sessions SHOULD be open 157 simultaneously and be repeatedly open and closed using 158 access protocols such as telnet and SSH. Open management 159 sessions SHOULD have valid and invalid configuration and 160 show commands entered. For the security plane, tunnels 161 for protocols such as IPsec SHOULD be established and 162 flapped. Policies for Firewalls and ACLs SHOULD be 163 repeatedly added and removed via management sessions. 165 for Accelerated Stress Benchmarking 167 ___________ 168 | DUT | 169 ___|Management | 170 | | | 171 | ----------- 172 \/ 173 ___________ 174 | | 175 | DUT | 176 |--->| |<---| 177 xN | ----------- | xN 178 interfaces | | interfaces 179 | ___________ | 180 | | | | 181 |--->| Tester |<---| 182 | | 183 ----------- 185 Figure 1. Physical Configuration 187 ___________ ___________ 188 | Control | | Management| 189 | Plane |___ ___| Plane | 190 | | | | | | 191 ----------- | | ----------- 192 \/ \/ ___________ 193 ___________ | Security | 194 | |<-----------| Plane | 195 | DUT | | | 196 |--->| |<---| ----------- 197 | ----------- | 198 | | 199 | ___________ | 200 | | Data | | 201 |--->| Plane |<---| 202 | | 203 ----------- 205 Figure 2. Logical Configuration 207 3.3 Reporting Format 208 Each methodology requires reporting of information for test 209 repeatability when benchmarking the same or different devices. 210 The information that are the Configuration Sets, Instability 211 Conditions, and Benchmarks, as defined in [4]. Example 212 reporting formats for each are provided below. Benchmarks 213 MUST be reported as provided below. 215 for Accelerated Stress Benchmarking 217 3.3.1 Configuration Sets 219 The minimum Configuration Set that MUST be used is as follows: 220 PARAMETER UNITS 221 Number of IGP Adjacencies Adjacencies 222 Number of IGP Routes Routes 223 Number of Nodes per Area Nodes 224 Number of Areas per Node Areas 225 SNMP GET Rate SNMP Gets/minute 226 Telnet Establishment Rate Sessions/Hour 227 Concurrent Telnet Sessions Sessions 228 FTP Establishment Rate Sessions/Hour 229 Concurrent FTP Session Sessions 230 SSH Establishment Rate Sessions/Hour 231 Concurrent SSH sessions Sessions 232 DATA TRAFFIC 233 Traffic Forwarding Enabled/Disabled 234 Aggregate Offered Load bps (or pps) 235 Number of Ingress Interfaces interfaces 236 Number of Egress Interfaces interfaces 237 Packet Size(s) bytes 238 Offered Load (interface) array of bps 239 Number of Flows flows 240 Encapsulation(flow) array of encapsulation types 242 Configuration Sets MAY include and are not limited to the 243 following examples. 244 Example Routing Protocol Configuration Set- 245 PARAMETER UNITS 246 BGP Enabled/Disabled 247 Number of EBGP Peers Peers 248 Number of IBGP Peers Peers 249 Number of BGP Route Instances Routes 250 Number of BGP Installed Routes Routes 251 MBGP Enabled/Disabled 252 Number of MBGP Route Instances Routes 253 Number of MBGP Installed Routes Routes 254 IGP Enabled/Disabled 255 IGP-TE Enabled/Disabled 256 Number of IGP Adjacencies Adjacencies 257 Number of IGP Routes Routes 258 Number of Nodes per Area Nodes 259 Number of Areas per Node Areas 261 Example MPLS Protocol Configuration Set- 262 PARAMETER UNITS 263 MPLS-TE Enabled/Disabled 264 Number of Tunnels as Ingress Tunnels 265 Number of Tunnels as Mid-Point Tunnels 266 Number of Tunnels as Egress Tunnels 267 LDP Enabled/Disabled 268 Number of Sessions Sessions 269 Number of FECs FECs 270 for Accelerated Stress Benchmarking 272 Example Multicast Protocol Configuration Set- 273 PARAMETER UNITS 274 PIM-SM Enabled/Disabled 275 RP Enabled/Disabled 276 Number of Multicast Groups Groups 277 MSDP Enabled/Disabled 279 Example Data Plane Configuration Set- 280 PARAMETER UNITS 281 Traffic Forwarding Enabled/Disabled 282 Aggregate Offered Load bps (or pps) 283 Number of Ingress Interfaces interfaces 284 Number of Egress Interfaces interfaces 286 TRAFFIC PROFILE 287 Packet Size(s) bytes 288 Offered Load (interface) array of bps 289 Number of Flows flows 290 Encapsulation(flow) array of encapsulation type 292 Example Management Configuration Set- 293 PARAMETER UNITS 294 SNMP GET Rate SNMP Gets/minute 295 Logging Enabled/Disabled 296 Protocol Debug Enabled/Disabled 297 Telnet Establishment Rate Sessions/Hour 298 Concurrent Telnet Sessions Sessions 299 FTP Establishment Rate Sessions/Hour 300 Concurrent FTP Session Sessions 301 SSH Establishment Rate Sessions/Hour 302 Concurrent SSH sessions Sessions 303 Packet Statistics Collector Enabled/Disabled 304 Statistics Sampling Rate X:1 packets 306 Example Security Configuration Set - 307 PARAMETER UNITS 308 Packet Filters Enabled/Disabled 309 Number of Filters For-Me filters 310 Number of Filter Rules For-Me rules 311 Number of Traffic Filters filters 312 Number of Traffic Filter Rules rules 313 IPsec tunnels tunnels 314 RADIUS Enabled/Disabled 315 TACACS Enabled/Disabled 317 Example SIP Configuration Set - 318 PARAMETER UNITS 319 Session Rate Sessions per Second 320 Media Streams per Session Streams per session 321 Total Sessions Sessions 322 for Accelerated Stress Benchmarking 324 3.3.2 Startup Conditions 325 Startup Conditions MAY include and are not limited to the following 326 examples: 327 PARAMETER UNITS 328 EBGP peering sessions negotiated Total EBGP Sessions 329 IBGP peering sessions negotiated Total IBGP Sessions 330 ISIS adjacencies established Total ISIS Adjacencies 331 ISIS routes learned rate ISIS Routes per Second 332 IPsec tunnels negotiated Total IPsec Tunnels 333 IPsec tunnel establishment rate IPsec tunnels per second 335 3.3.3 Instability Conditions 336 Instability Conditions MAY include and are not limited to the 337 following examples: 338 PARAMETER UNITS 339 Interface Shutdown Cycling Rate interfaces per minute 340 ISIS Route Flap Rate routes per minutes 341 LSP Reroute Rate LSP per minute 342 Overloaded Links number 343 Amount Links Overloaded % of bandwidth 344 FTP Rate Mb/minute 345 IPsec Tunnel Flap Rate tunnels per minute 346 Filter Policy Changes policies per hour 347 SSH Session Rate SSH sessions per hour 348 Telnet Session Rate Telnet session per hour 349 Command Entry Rate Commands per Hour 350 Message Flood Rate Messages 352 3.3.4 Benchmarks 354 Benchmarks are as defined in [4] and MUST be reported as follow: 355 PARAMETER UNITS PHASE 356 Stable Aggregate Forwarding Rate pps Startup 357 Stable Latency seconds Startup 358 Stable Session Count sessions Startup 359 Unstable Aggregate Forwarding Rate pps Instability 360 Degraded Aggregate Forwarding Rate pps Instability 361 Ave. Degraded Aggregate Forwarding Rate pps Instability 362 Unstable Latency seconds Instability 363 Unstable Uncontrolled Sessions Lost sessions Instability 364 Recovered Aggregate Forwarding Rate pps Recovery 365 Recovered Latency seconds Recovery 366 Recovery Time seconds Recovery 367 Recovered Uncontrolled Sessions sessions Recovery 368 for Accelerated Stress Benchmarking 370 4. Stress Test Procedure 372 4.1 General Methodology with Multiple Instability Conditions 374 Objective 375 To benchmark the DUT under accelerated stress when there are 376 multiple instability conditions. 378 Procedure 380 1. Report Configuration Set 381 2. Begin Startup Conditions with the DUT 382 3. Establish Configuration Sets with the DUT 383 4. Report Stability Benchmarks 384 5. Apply Instability Conditions 385 6. Apply Instability Condition specific to test case. 386 7. Report Instability Benchmarks 387 8. Stop applying all Instability Conditions 388 9. Report Recovery Benchmarks 389 10. Optional - Change Configuration Set and/or Instability 390 Conditions for next iteration 392 Expected Results 393 Ideally the Forwarding Rates, Latencies, and Session Counts will 394 be neasured to be the same at each phase. If no packet or 395 session loss occurs then the Instability Conditions MAY be 396 increased for a repeated iteration (step 10 of the procedure). 398 Example Procedure 400 1. Report Configuration Set 402 BGP Enabled 403 10 EBGP Peers 404 30 IBGP Peers 405 500K BGP Route Instances 406 160K BGP FIB Routes 408 ISIS Enabled 409 ISIS-TE Disabled 410 30 ISIS Adjacencies 411 10K ISIS Level-1 Routes 412 250 ISIS Nodes per Area 414 MPLS Disabled 415 IP Multicast Disabled 417 IPsec Enabled 418 10K IPsec tunnels 419 640 Firewall Policies 420 100 Firewall Rules per Policy 421 for Accelerated Stress Benchmarking 423 Traffic Forwarding Enabled 424 Aggregate Offered Load 10Gbps 425 30 Ingress Interfaces 426 30 Egress Interfaces 427 Packet Size(s) = 64, 128, 256, 512, 1024, 1280, 1518 bytes 428 Forwarding Rate[1..30] = 1Gbps 429 10000 Flows 430 Encapsulation[1..5000] = IPv4 431 Encapsulation[5001.10000] = IPsec 432 Logging Enabled 433 Protocol Debug Disabled 434 SNMP Enabled 435 SSH Enabled 436 10 Concurrent SSH Sessions 437 FTP Enabled 438 RADIUS Enabled 439 TACACS Disabled 440 Packet Statistics Collector Enabled 442 2. Begin Startup Conditions with the DUT 444 10 EBGP peering sessions negotiated 445 30 EBGP peering sessions negotiated 446 1K BGP routes learned per second 447 30 ISIS Adjacencies 448 1K ISIS routes learned per second 449 10K IPsec tunnels negotiated 451 3. Establish Configuration Sets with the DUT 453 4. Report Stability Benchmarks as follow: 455 Stable Aggregate Forwarding Rate 456 Stable Latency 457 Stable Session Count 459 It is RECOMMENDED that the benchmarks be measured and 460 recorded at one-second intervals. 462 5. Apply Instability Conditions 464 Interface Shutdown Cycling Rate = 1 interface every 5 465 minutes 466 BGP Session Flap Rate = 1 session every 10 minutes 467 BGP Route Flap Rate = 100 routes per minute 468 ISIS Route Flap Rate = 100 routes per minute 469 IPsec Tunnel Flap Rate = 1 tunnel per minute 470 Overloaded Links = 5 of 30 471 Amount Links Overloaded = 20% 472 SNMP GETs = 1 per sec 473 SSH Session Rate = 6 sessions per hour 474 SSH Session Duration = 10 minutes 475 Command Rate via SSH = 20 commands per minute 476 for Accelerated Stress Benchmarking 478 FTP Restart Rate = 10 continuous transfers (Puts/Gets) 479 per hour 480 FTP Transfer Rate = 100 Mbps 481 Statistics Sampling Rate = 1:1 packets 482 RADIUS Server Loss Rate = 1 per Hour 483 RADIUS Server Loss Duration = 3 seconds 485 6. Apply Instability Condition specific to test case. 487 7. Report Instability Benchmarks as follow: 488 Unstable Aggregate Forwarding Rate 489 Degraded Aggregate Forwarding Rate 490 Ave. Degraded Aggregate Forwarding Rate 491 Unstable Latency 492 Unstable Uncontrolled Sessions Lost 494 It is RECOMMENDED that the benchmarks be measured and 495 recorded at one-second intervals. 497 8. Stop applying all Instability Conditions 499 9. Report Recovery Benchmarks as follow: 501 Recovered Aggregate Forwarding Rate 502 Recovered Latency 503 Recovery Time 504 Recovered Uncontrolled Sessions Lost 506 It is RECOMMENDED that the benchmarks be measured and 507 recorded at one-second intervals. 509 10. Optional - Change Configuration Set and/or Instability 510 Conditions for next iteration 512 4.2 General Methodology with a Single Instability Condition 514 Objective 515 To benchmark the DUT under accelerated stress when there is a 516 single instability conditions. 518 Procedure 520 1. Report Configuration Set 521 2. Begin Startup Conditions with the DUT 522 3. Establish Configuration Sets with the DUT 523 4. Report Stability Benchmarks 524 5. Apply single Instability Condition 525 6. Report Instability Benchmarks 526 7. Stop applying all Instability Condition 527 8. Report Recovery Benchmarks 528 9. Optional - Change Configuration Set and/or Instability 529 Conditions for next iteration 530 for Accelerated Stress Benchmarking 532 Expected Results 533 Ideally the Forwarding Rates, Latencies, and Session Counts will 534 be neasured to be the same at each phase. If no packet or session 535 loss occurs then the Instability Conditions MAY be increased 536 for a repeated iteration (step 10 of the procedure). 538 5. IANA Considerations 539 This document requires no IANA considerations. 541 6. Security Considerations 542 Documents of this type do not directly affect the security of 543 the Internet or of corporate networks as long as benchmarking 544 is not performed on devices or systems connected to operating 545 networks. 547 7. Normative References 549 [1] Bradner, S., Editor, "Benchmarking Terminology for Network 550 Interconnection Devices", RFC 1242, October 1991. 552 [2] Mandeville, R., "Benchmarking Terminology for LAN Switching 553 Devices", RFC 2285, October 1998. 555 [3] Bradner, S. and McQuaid, J., "Benchmarking Methodology for 556 Network Interconnect Devices", RFC 2544, March 1999. 558 [4] Poretsky, S. and Rao, S., "Terminology for Accelerated 559 Stress Benchmarking", draft-ietf-bmwg-acc-bench-term-10, 560 work in progress, October 2006. 562 [5] Bradner, S., "Key words for use in RFCs to Indicate 563 Requirement Levels", RFC 2119, March 1997. 565 8. Informative References 567 [RFC3871] RFC 3871 "Operational Security Requirements for Large 568 Internet Service Provider (ISP) IP Network Infrastructure. 569 G. Jones, Ed.. IETF, September 2004. 571 [NANOG25] "Core Router Evaluation for Higher Availability", 572 Scott Poretsky, NANOG 25, October 8, 2002, Toronto, CA. 574 [IEEECQR] "Router Stress Testing to Validate Readiness for 575 Network Deployment", Scott Poretsky, IEEE CQR 2003. 577 [CONVMETH] Poretsky, S., "Benchmarking Methodology for IGP Data 578 Plane Route Convergence", 579 draft-ietf-bmwg-igp-dataplane-conv-meth-11, work in 580 progress, October 2006. 582 for Accelerated Stress Benchmarking 584 9. Author's Address 586 Scott Poretsky 587 Reef Point Systems 588 8 New England Executive Park 589 Burlington, MA 01803 590 USA 591 Phone: + 1 781 395 5090 592 EMail: sporetsky@reefpoint.com 594 Shankar Rao 595 1801 California Street 596 8th Floor 597 Qwest Communications 598 Denver, CO 80202 599 USA 600 Phone: + 1 303 437 6643 601 Email: shankar.rao@qwest.com 602 for Accelerated Stress Benchmarking 604 Full Copyright Statement 606 Copyright (C) The Internet Society (2006). 608 This document is subject to the rights, licenses and restrictions 609 contained in BCP 78, and except as set forth therein, the authors 610 retain all their rights. 612 This document and the information contained herein are provided on an 613 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 614 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 615 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 616 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 617 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 618 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 620 Intellectual Property 622 The IETF takes no position regarding the validity or scope of any 623 Intellectual Property Rights or other rights that might be claimed to 624 pertain to the implementation or use of the technology described in 625 this document or the extent to which any license under such rights 626 might or might not be available; nor does it represent that it has 627 made any independent effort to identify any such rights. Information 628 on the procedures with respect to rights in RFC documents can be 629 found in BCP 78 and BCP 79. 631 Copies of IPR disclosures made to the IETF Secretariat and any 632 assurances of licenses to be made available, or the result of an 633 attempt made to obtain a general license or permission for the use of 634 such proprietary rights by implementers or users of this 635 specification can be obtained from the IETF on-line IPR repository at 636 http://www.ietf.org/ipr. 638 The IETF invites any interested party to bring to its attention any 639 copyrights, patents or patent applications, or other proprietary 640 rights that may cover technology that may be required to implement 641 this standard. Please address the information to the IETF at ietf- 642 ipr@ietf.org. 644 Acknowledgement 646 Funding for the RFC Editor function is currently provided by the 647 Internet Society.