idnits 2.17.1 draft-ietf-bmwg-acc-bench-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 3667, Section 5.1 on line 19. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 541. ** The document claims conformance with section 10 of RFC 2026, but uses some RFC 3978/3979 boilerplate. As RFC 3978/3979 replaces section 10 of RFC 2026, you should not claim conformance with it if you have changed to using RFC 3978/3979 boilerplate. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** The document seems to lack an RFC 3978 Section 5.5 (updated by RFC 4748) Disclaimer -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack an RFC 3979 Section 5, para. 1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack an RFC 3979 Section 5, para. 3 IPR Disclosure Invitation -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, or will be disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard == It seems as if not all pages are separated by form feeds - found 0 form feeds but 12 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. (A line matching the expected section header was found, but with an unexpected indentation: ' 1. Introduction' ) ** The document seems to lack a Security Considerations section. (A line matching the expected section header was found, but with an unexpected indentation: ' 5. Security Considerations' ) ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack an Authors' Addresses Section. ** There are 6 instances of too long lines in the document, the longest one being 4 characters in excess of 72. ** There are 222 instances of lines with control characters in the document. ** The abstract seems to contain references ([2], [3], [4], [5], [6], [1]), 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 (April 2005) is 6922 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 section? '6' on line 502 looks like a reference -- Missing reference section? '1' on line 487 looks like a reference -- Missing reference section? '2' on line 490 looks like a reference -- Missing reference section? '3' on line 493 looks like a reference -- Missing reference section? '4' on line 496 looks like a reference -- Missing reference section? '5' on line 499 looks like a reference Summary: 15 errors (**), 0 flaws (~~), 3 warnings (==), 10 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 2005 4 Scott Poretsky 5 Quarry Technologies 7 Shankar Rao 8 Qwest Communications 10 October 2004 12 Methodology for Accelerated Stress Benchmarking 13 15 Intellectual Property Rights (IPR) statement: 16 By submitting this Internet-Draft, I certify that any applicable 17 patent or other IPR claims of which I am aware have been disclosed, or 18 will be disclosed, and any of which I become aware will be disclosed, 19 in accordance with RFC 3668. 21 Status of this Memo 23 This document is an Internet-Draft and is in full conformance with 24 all provisions of Section 10 of RFC2026. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF), its areas, and its working groups. Note that 28 other groups may also distribute working documents as Internet- 29 Drafts. 31 Internet-Drafts are draft documents valid for a maximum of six 32 months and may be updated, replaced, or obsoleted by other 33 documents at any time. It is inappropriate to use Internet-Drafts 34 as reference material or to cite them other than as "work in 35 progress." 37 The list of current Internet-Drafts can be accessed at 38 http://www.ietf.org/ietf/1id-abstracts.txt 40 The list of Internet-Draft Shadow Directories can be accessed at 41 http://www.ietf.org/shadow.html. 43 ABSTRACT 44 Routers in an operational network are simultaneously configured with 45 multiple protocols and security policies while forwarding traffic and 46 being managed. To accurately benchmark a router for deployment it is 47 necessary that the router be tested in these simultaneous 48 operational conditions, which is known as Stress Testing. This 49 document provides the Methodology for performing Stress Benchmarking 50 of networking devices. Descriptions of Test Topology, Benchmarks and 51 Reporting Format are provided in addition to procedures for 52 conducting various test cases. The methodology is to be used with 53 the companion terminology document [6]. 55 Table of Contents 56 1. Introduction ............................................... 2 57 2. Existing definitions ....................................... 3 58 3. Test Setup.................................................. 3 59 3.1 Test Topologies............................................ 3 60 3.2 Test Considerations........................................ 4 61 3.3 Reporting Format........................................... 4 62 3.3.1 Configuration Sets....................................... 4 63 3.3.2 Instability Conditions................................... 6 64 3.3.3 Benchmarks............................................... 6 65 4. Test Cases.................................................. 7 66 4.1 Failed Primary EBGP Peer................................... 7 67 4.2 Establish New EBGP Peer.................................... 7 68 4.3 BGP Route Explosion........................................ 8 69 4.4 BGP Policy Configuration................................... 8 70 4.5 Persistent BGP Flapping.................................... 9 71 4.6 DoS Attack................................................. 9 72 5. Security Considerations..................................... 10 73 6. References.................................................. 10 74 7. Author's Address............................................ 11 76 1. Introduction 77 Router testing benchmarks have consistently been made in a 78 monolithic fashion wherein a single protocol or behavior is 79 measured in an isolated environment. It is important to know the 80 limits for a networking device's behavior for each protocol in isolation, 81 however this does not produce a reliable benchmark of the device's 82 behavior in an operational network. 84 Routers in an operational network are simultaneously configured with 85 multiple protocols and security policies while forwarding traffic 86 and being managed. To accurately benchmark a router for deployment 87 it is necessary to test that router in operational conditions by 88 simultaneously configuring and scaling network protocols and security 89 policies, forwarding traffic, and managing the device. It is helpful 90 to accelerate these network operational conditions with Instability 91 Conditions [6] so that the networking devices are stress tested. 93 Stress Testing of networking devices provides the following benefits: 94 1. Evaluation of multiple protocols enabled simultaneously as 95 configured in deployed networks 96 2. Evaluation of System and Software Stability 97 3. Evaluation of Manageability under stressful conditions 98 4. Identification of Software Coding bugs such as: 99 a. Memory Leaks 100 b. Suboptimal CPU Utilization 101 c. Coding Logic 103 These benefits produce significant advantages for network operations: 104 1. Increased stability of routers and protocols 105 2. Hardened routers to DoS attacks 106 3. Verified manageability under stress 107 4. Planning router resources for growth and scale 108 This document provides the Methodology for performing Stress 109 Benchmarking of networking devices. Descriptions of Test Topology, 110 Benchmarks and Reporting Format are provided in addition to 111 procedures for conducting various test cases. The methodology is 112 to be used with the companion terminology document [6]. 114 2. Existing definitions 116 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 117 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 118 this document are to be interpreted as described in RFC 2119. 120 Terms related to Accelerated Stress Benchmarking are defined in [6]. 122 3. Test Setup 124 3.1 Test Topologies 126 Figure 1 shows the physical configuration to be used for the 127 methodologies provided in this document. The number of 128 interfaces between the tester and DUT will scale depending upon 129 the number of control protocol sessions and traffic 130 forwarding interfaces. A separate device may be required to 131 externally manage the device in the case that the test equipment 132 does not support such functionality. 134 Figure 2 shows the logical configuration for the stress test 135 methodologies. Each plane may be emulated by single or 136 multiple test equipment. 138 ___________ 139 | DUT | 140 ___|Management | 141 | | | 142 | ----------- 143 \/ 144 ___________ 145 | | 146 | DUT | 147 |--->| |<---| 148 xN | ----------- | xN 149 interfaces | | interfaces 150 | ___________ | 151 | | | | 152 |--->| Tester |<---| 153 | | 154 ----------- 156 Figure 1. Physical Configuration 157 ___________ ___________ 158 | Control | | Management| 159 | Plane |___ ___| Plane | 160 | | | | | | 161 ----------- | | ----------- 162 \/ \/ ___________ 163 ___________ | Security | 164 | |<-----------| Plane | 165 | DUT | | | 166 |--->| |<---| ----------- 167 | ----------- | 168 | | 169 | ___________ | 170 | | Data | | 171 |--->| Plane |<---| 172 | | 173 ----------- 175 Figure 2. Logical Configuration 177 3.2 Test Considerations 179 The Accelerated Stress Benchmarking test can be applied in 180 service provider test environments to benchmark DUTs under 181 stress in an environment that is reflective of an operational 182 network. A particular Configuration Set is defined and the 183 DUT is benchmarked using this configuration set and the 184 Instability Conditions. Varying Configuration Sets and/or 185 Instability Conditions applied in an iterative fashion can 186 provide an accurate characterization of the DUT 187 to help determine future network deployments. 189 3.3 Reporting Format 191 Each methodology requires reporting of information for test 192 repeatability when benchmarking the same or different devices. 193 The information that are the Configuration Sets, Instability 194 Conditions, and Benchmarks, as defined in [6]. Example 195 reporting formats for each are provided below. 197 3.3.1 Configuration Sets 198 Example Routing Protocol Configuration Set- 199 PARAMETER UNITS 200 BGP Enabled/Disabled 201 Number of EBGP Peers Peers 202 Number of IBGP Peers Peers 203 Number of BGP Route Instances Routes 204 Number of BGP Installed Routes Routes 206 MBGP Enabled/Disabled 207 Number of MBGP Route Instances Routes 208 Number of MBGP Installed Routes Routes 209 IGP Enabled/Disabled 210 IGP-TE Enabled/Disabled 211 Number of IGP Adjacencies Adjacencies 212 Number of IGP Routes Routes 213 Number of Nodes per Area Nodes 215 Example MPLS Protocol Configuration Set- 216 PARAMETER UNITS 217 MPLS-TE 218 Number of Ingress Tunnels Tunnels 219 Number of Mid-Point Tunnels Tunnels 220 Number of Egress Tunnels Tunnels 222 LDP 223 Number of Sessions Sessions 224 Number of FECs FECs 226 Example Multicast Protocol Configuration Set- 227 PARAMETER UNITS 228 PIM-SM Enabled/Disabled 229 RP Enabled/Disabled 230 Number of Multicast Groups Groups 231 MSDP Enabled/Disabled 233 Example Data Plane Configuration Set- 234 PARAMETER UNITS 235 Traffic Forwarding Enabled/Disabled 236 Aggregate Offered Load bps (or pps) 237 Number of Ingress Interfaces number 238 Number of Egress Interfaces number 240 TRAFFIC PROFILE 241 Packet Size(s) bytes 242 Packet Rate(interface) array of packets per second 243 Number of Flows number 244 Encapsulation(flow) array of encapsulation type 246 Management Configuration Set- 247 PARAMETER UNITS 248 SNMP GET Rate SNMP Gets/minute 249 Logging Enabled/Disabled 250 Protocol Debug Enabled/Disabled 251 Telnet Rate Sessions/Hour 252 FTP Rate Sessions/Hour 253 Concurrent Telnet Sessions Sessions 254 Concurrent FTP Session Sessions 255 Packet Statistics Collector Enabled/Disabled 256 Statistics Sampling Rate X:1 packets 257 Security Configuration Set - 258 PARAMETER UNITS 259 Packet Filters Enabled/Disabled 260 Number of Filters For-Me number 261 Number of Filter Rules For-Me number 262 Number of Traffic Filters number 263 Number of Traffic Filter Rules number 264 SSH Enabled/Disabled 265 Number of simultaneous SSH sessions number 266 RADIUS Enabled/Disabled 267 TACACS Enabled/Disabled 269 3.3.2 Instability Conditions 270 PARAMETER UNITS 271 Interface Shutdown Cycling Rate interfaces per minute 272 BGP Session Flap Rate sessions per minute 273 BGP Route Flap Rate routes per minutes 274 IGP Route Flap Rate routes per minutes 275 LSP Reroute Rate LSP per minute 276 Overloaded Links number 277 Amount Links Overloaded % of bandwidth 278 FTP Rate Mb/minute 279 IPsec Session Loss sessions per minute 280 Filter Policy Changes policies per hour 281 SSH Session Restart SSH sessions per hour 282 Telnet Session Restart Telnet session per hour 284 3.3.3 Benchmarks 285 PARAMETER UNITS PHASE 286 Stable Aggregate Forwarding Rate pps Startup 287 Stable Latency seconds Startup 288 Stable Session Count sessions Startup 289 Unstable Aggregate Forwarding Rate pps Instability 290 Degraded Aggregate Forwarding Rate pps Instability 291 Ave. Degraded Aggregate Forwarding Rate pps Instability 292 Unstable Latency seconds Instability 293 Unstable Uncontrolled Sessions Lost sessions Instability 294 Recovered Aggregate Forwarding Rate pps Recovery 295 Recovered Latency seconds Recovery 296 Recovery Time seconds Recovery 297 Recovered Uncontrolled Sessions Lost sessions Recovery 299 It is RECOMMENDED that Aggregate Forwarding Rates, Latencies, and 300 Session Losses be measured at one-second intervals. These same 301 benchmarks can also be used as Variability Benchmarks reported as 302 the differences between the Benchmarks for multiple iterations 303 with the same DUT. For the purpose of the Variability Benchmarks, 304 A more complete characterization of the DUT would be to apply 305 multiple test iterations for the same Configuration Sets and 306 Instability Conditions, measure the Variability Benchmarks, and 307 then vary the Configuration Set and/or Instability Conditions. 309 4. Test Cases 310 4.1 Failed Primary EBGP Peer 312 Objective 313 The purpose of this test is to benchmark the performance 314 of the DUT during stress conditions when losing an EBGP 315 Peer from which most FIB routes have been learned. 317 Procedure 318 1. Report Configuration Set 319 2. Begin Startup Conditions with the DUT 320 3. Establish Configuration Sets with the DUT 321 4. Report benchmarks (for stability) 322 5. Apply Instability Conditions 323 6. Remove link to EBGP peer with most FIB routes. This SHOULD 324 be achieved by losing physical layer connectivity with 325 a local fiber pull. Loss of the peering session SHOULD 326 cause the DUT to withdraw 100,000 or greater routes. 327 7. Report benchmarks (for instability) 328 8. Stop applying all Instability Conditions 329 9. Report benchmarks (for recovery) 330 10. Optional - Change Configuration Set and/or Instability 331 Conditions for next iteration 333 Results 334 It is expected that there will be significant packet loss 335 until the DUT converges from the lost EBGP link. Other DUT 336 operation should be stable without session loss or sustained 337 packet loss. Recovery time should not be infinite. 339 4.2 Establish New EBGP Peer 340 Objective 341 The purpose of this test is to benchmark the performance 342 of the DUT during stress conditions when establishing a 343 new EBGP Peer from which routes are learned. 345 Procedure 346 1. Report Configuration Set 347 2. Begin Startup Conditions with the DUT 348 3. Establish Configuration Sets with the DUT 349 4. Report benchmarks (for stability) 350 5. Apply Instability Conditions 351 6. Configure new EBGP peering session at DUT and peering router. 352 Physical and Data Link Layer connectivity SHOULD already exist 353 to perform this step. Establishment of the peering session 354 SHOULD result in the DUT learning 100,000 or greater routes from 355 the BGP peer and advertising 100,000 or greater routes to 356 the BGP peer 357 7. Report benchmarks (for instability) 358 8. Stop applying all Instability Conditions 359 9. Report benchmarks (for recovery) 360 10. Optional - Change Configuration Set and/or Instability 361 Conditions for next iteration 363 Results 364 It is expected that there will be zero packet loss as the DUT 365 learns the new routes. Other DUT operation should be stable 366 without session loss or sustained packet loss. 368 4.3 BGP Route Explosion 370 Objective 371 The purpose of this test is to benchmark the performance 372 of the DUT during stress conditions when there is BGP Route 373 Explosion experienced in the network. 375 Procedure 376 1. Report Configuration Set 377 2. Begin Startup Conditions with the DUT 378 3. Establish Configuration Sets with the DUT 379 4. Report benchmarks (for stability) 380 5. Apply Instability Conditions 381 6. Advertise 1M BGP routes to the DUT from a single EBGP 382 neighbor. 383 7. Report benchmarks (for instability) 384 8. Stop applying all Instability Conditions 385 9. Report benchmarks (for recovery) 386 10. Optional - Change Configuration Set and/or Instability 387 Conditions for next iteration 389 Results 390 It is expected that there will be no additional packet loss from 391 the advertisement of routes from the BGP neighbor. Other 392 DUT operation should be stable without session loss. 394 4.4 BGP Policy Configuration 396 Objective 397 The purpose of this test is to benchmark the performance 398 of the DUT during stress conditions when there is continuous 399 reconfiguration of BGP Policy at the DUT. 401 Procedure 402 1. Report Configuration Set 403 2. Begin Startup Conditions with the DUT 404 3. Establish Configuration Sets with the DUT 405 4. Report benchmarks (for stability) 406 5. Apply Instability Conditions 407 6. Configure BGP Policy on the DUT for each established neighbor. 408 The BGP Policy SHOULD filter 25% of the routes learned from 409 that neighbor. Note that the specific policy configuration 410 to achieve the filtering may be device specific. 412 7. Every 30 minutes remove the BGP Policy configuration and then 413 configure it gain so that it is reapplied. 414 8. Report benchmarks (for instability) 415 9. Stop applying all Instability Conditions 416 10. Report benchmarks (for recovery) 417 11. Optional - Change Configuration Set and/or Instability 418 Conditions for next iteration 420 Results 421 It is expected that there will be no packet loss resulting from 422 the continuous configuration and removal of BGP Policy for BGP 423 neighbors. Other DUT operation should be stable without session 424 loss. 426 4.5 Persistent BGP Flapping 428 Objective 429 The purpose of this test is to benchmark the performance 430 of the DUT during stress conditions when flapping BGP Peering 431 sessions for an infinite period. 433 Procedure 434 1. Report Configuration Set 435 2. Begin Startup Conditions with the DUT 436 3. Establish Configuration Sets with the DUT 437 4. Report benchmarks (for stability) 438 5. Apply Instability Conditions 439 6. Repeatedly flap an IBGP and an EBGP peering session. 440 This SHOULD be achieved by losing physical layer connectivity 441 via a local fiber pull. Loss of the EBGP peering session SHOULD 442 cause the DUT to withdraw 10,000 or greater routes. Route Flap 443 Dampening SHOULD NOT be enabled. 444 7. Report benchmarks (for instability) 445 8. Stop applying all Instability Conditions 446 9. Report benchmarks (for recovery) 447 10. Optional - Change Configuration Set and/or Instability 448 Conditions for next iteration 450 Results 451 It is expected that there will be significant packet loss 452 from repeated convergence events. Other DUT operation should be 453 stable without session loss. Recovery time should not be infinite. 455 4.6 DoS Attack 457 Objective 458 The purpose of this test is to benchmark the performance of the 459 DUT during stress conditions while experiencing a DoS attack. 461 Procedure 462 1. Report Configuration Set 463 2. Begin Startup Conditions with the DUT 464 3. Establish Configuration Sets with the DUT 465 4. Report benchmarks (for stability) 466 5. Apply Instability Conditions 467 6. Initiate DoS Attack against DUT. It is RECOMMENDED that 468 the SYN Flood attack be used for the DoS attack. 469 7. Report benchmarks (for instability) 470 8. Stop applying all Instability Conditions 471 9. Report benchmarks (for recovery) 472 10. Optional - Change Configuration Set and/or Instability 473 Conditions for next iteration 475 Results 476 DUT should be able to defend against DoS attack without additional 477 packet loss or session loss. 479 5. Security Considerations 480 Documents of this type do not directly affect the security of 481 the Internet or of corporate networks as long as benchmarking 482 is not performed on devices or systems connected to operating 483 networks. 485 6. References 487 [1] Bradner, S., Editor, "Benchmarking Terminology for Network 488 Interconnection Devices", RFC 1242, October 1991. 490 [2] Mandeville, R., "Benchmarking Terminology for LAN Switching 491 Devices", RFC 2285, June 1998. 493 [3] Bradner, S. and McQuaid, J., "Benchmarking Methodology for 494 Network Interconnect Devices", RFC 2544, March 1999. 496 [4] "Core Router Evaluation for Higher Availability", Scott 497 Poretsky, NANOG 25, June 8, 2002, Toronto, CA. 499 [5] "Router Stress Testing to Validate Readiness for Network 500 Deployment", Scott Poretsky, IEEE CQR 2003. 502 [6] Poretsky, S. and Rao, S., "Terminology for Accelerated 503 Stress Benchmarking", draft-ietf-bmwg-acc-bench-term-04, 504 work in progress, October 2004. 506 7. Author's Address 508 Scott Poretsky 509 Quarry Technologies 510 8 New England Executive Park 511 Burlington, MA 01803 512 USA 514 Phone: + 1 781 395 5090 515 EMail: sporetsky@quarrytech.com 517 Shankar Rao 518 950 17th Street 519 Suite 1900 520 Qwest Communications 521 Denver, CO 80210 522 USA 523 Phone: + 1 303 437 6643 524 Email: shankar.rao@qwest.com 526 Intellectual Property Statement 528 The IETF takes no position regarding the validity or scope of any Intel- 529 lectual Property Rights or other rights that might be claimed to pertain 530 to the implementation or use of the technology described in this docu- 531 ment or the extent to which any license under such rights might or might 532 not be available; nor does it represent that it has made any independent 533 effort to identify any such rights. Information on the procedures with 534 respect to rights in RFC documents can be found in BCP 78 and BCP 79. 536 Copies of IPR disclosures made to the IETF Secretariat and any 537 assurances of licenses to be made available, or the result of an attempt 538 made to obtain a general license or permission for the use of such 539 proprietary rights by implementers or users of this specification can be 540 obtained from the IETF on-line IPR repository at 541 http://www.ietf.org/ipr. 543 The IETF invites any interested party to bring to its attention any 544 copyrights, patents or patent applications, or other proprietary rights 545 that may cover technology that may be required to implement this stan- 546 dard. Please address the information to the IETF at ietf-ipr@ietf.org. 548 Disclaimer of Warranty 550 This document and the information contained herein are provided on an 551 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR 552 IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 553 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 554 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMA- 555 TION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 556 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 558 Copyright Statement 560 Copyright (C) The Internet Society (2004). This document is subject to 561 the rights, licenses and restrictions contained in BCP 78, and except as 562 set forth therein, the authors retain all their rights.