idnits 2.17.1 draft-ietf-bmwg-igp-dataplane-conv-term-11.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 21. -- Found old boilerplate from RFC 3978, Section 5.5 on line 738. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 750. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 757. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 763. ** 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 3 instances of too long lines in the document, the longest one being 4 characters in excess of 72. ** The abstract seems to contain references ([Po061], [Po062], [Mo98], [Ca90]), 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 (November 2006) is 6371 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? 'Po061' on line 89 looks like a reference -- Missing reference section? 'Po062' on line 504 looks like a reference -- Missing reference section? 'Ca90' on line 92 looks like a reference -- Missing reference section? 'Mo98' on line 92 looks like a reference -- Missing reference section? '5' on line 103 looks like a reference -- Missing reference section? '6' on line 103 looks like a reference -- Missing reference section? 'Ma98' on line 104 looks like a reference -- Missing reference section? 'Ba91' on line 132 looks like a reference -- Missing reference section? 'Ba99' on line 132 looks like a reference -- Missing reference section? 'Ca01' on line 193 looks like a reference -- Missing reference section? 'Ci03' on line 193 looks like a reference Summary: 5 errors (**), 0 flaws (~~), 2 warnings (==), 18 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: November 2006 4 Scott Poretsky 5 Reef Point Systems 7 Brent Imhoff 8 Juniper Networks 10 May 2006 12 Terminology for Benchmarking 13 IGP Data Plane Route Convergence 15 17 Intellectual Property Rights (IPR) statement: 18 By submitting this Internet-Draft, each author represents that any 19 applicable patent or other IPR claims of which he or she is aware 20 have been or will be disclosed, and any of which he or she becomes 21 aware will be disclosed, in accordance with Section 6 of BCP 79. 23 Status of this Memo 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF), its areas, and its working groups. Note that 27 other groups may also distribute working documents as 28 Internet-Drafts. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 The list of current Internet-Drafts can be accessed at 36 http://www.ietf.org/ietf/1id-abstracts.txt. 38 The list of Internet-Draft Shadow Directories can be accessed at 39 http://www.ietf.org/shadow.html. 41 Copyright Notice 42 Copyright (C) The Internet Society (2006). 44 ABSTRACT 45 This document describes the terminology for benchmarking IGP 46 Route Convergence as described in Applicability document [Po061] and 47 Methodology document [Po062]. The methodology and terminology are to 48 be used for benchmarking Convergence Time and can be applied to 49 any link-state IGP such as ISIS [Ca90] and OSPF [Mo98]. The data plane 50 is measured to obtain the convergence benchmarking metrics 51 described in [Po062]. 53 IGP Data Plane Route Convergence 55 Table of Contents 56 1. Introduction .................................................2 57 2. Existing definitions .........................................3 58 3. Term definitions..............................................3 59 3.1 Convergence Event.........................................3 60 3.2 Route Convergence.........................................4 61 3.3 Network Convergence.......................................4 62 3.4 Full Convergence..........................................5 63 3.5 Convergence Packet Loss...................................5 64 3.6 Convergence Event Instant.................................6 65 3.7 Convergence Recovery Instant..............................6 66 3.8 Rate-Derived Convergence Time.............................7 67 3.9 Convergence Event Transition..............................7 68 3.10 Convergence Recovery Transition..........................8 69 3.11 Loss-Derived Convergence Time............................8 70 3.12 Sustained Forwarding Convergence Time....................9 71 3.13 Restoration Convergence Time.............................9 72 3.14 Packet Sampling Interval.................................10 73 3.15 Local Interface..........................................11 74 3.16 Neighbor Interface.......................................11 75 3.17 Remote Interface.........................................11 76 3.18 Preferred Egress Interface...............................12 77 3.19 Next-Best Egress Interface...............................12 78 3.20 Stale Forwarding.........................................13 79 3.21 Nested Convergence Events................................13 80 4. IANA Considerations...........................................13 81 5. Security Considerations.......................................14 82 6. Acknowledgements..............................................14 83 7. Normative References..........................................14 84 8. Author's Address..............................................15 86 1. Introduction 87 This draft describes the terminology for benchmarking IGP Route 88 Convergence. The motivation and applicability for this 89 benchmarking is provided in [Po061]. The methodology to be used for 90 this benchmarking is described in [Po062]. The methodology and 91 terminology to be used for benchmarking Route Convergence can be 92 applied to any link-state IGP such as ISIS [Ca90] and OSPF [Mo98]. The 93 data plane is measured to obtain black-box (externally observable) 94 convergence benchmarking metrics. The purpose of this document is 95 to introduce new terms required to complete execution of the IGP 96 Route Convergence Methodology [Po062]. These terms apply to IPv4 and 97 IPv6 traffic as well as IPv4 and IPv6 IGPs. 99 An example of Route Convergence as observed and measured from the 100 data plane is shown in Figure 1. The graph in Figure 1 shows 101 Forwarding Rate versus Time. Time 0 on the X-axis is on the far 102 right of the graph. The Offered Load to the ingress interface of 103 the DUT SHOULD equal the measured maximum Throughput [5,6] of the DUT 104 and the Forwarding Rate [Ma98] is measured at the egress interfaces 105 of the DUT. The components of the graph and the metrics are defined 106 in the Term Definitions section. 108 IGP Data Plane Route Convergence 110 Convergence Convergence 111 Recovery Event 112 Instant Instant Time = 0sec 113 Forwarding Rate = ^ ^ ^ Offered Load = 114 Offered Load --> ------\ Packet /-------- <---Max Throughput 115 \ Loss /<----Convergence 116 Convergence------->\ / Event Transition 117 Recovery Transition \ / 118 \_____/<------Maximum Packet Loss 119 X-axis = Time 120 Y-axis = Forwarding Rate 122 Figure 1. Convergence Graph 124 2. Existing definitions 125 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 126 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 127 document are to be interpreted as described in BCP 14, RFC 2119. 128 RFC 2119 defines the use of these key words to help make the 129 intent of standards track documents as clear as possible. While this 130 document uses these keywords, this document is not a standards track 131 document. The term Throughput is defined in [Ba91] and [Ba99]. 133 3. Term Definitions 134 3.1 Convergence Event 136 Definition: 137 The occurrence of a planned or unplanned action in the network 138 that results in a change in the egress interface of the Device 139 Under Test (DUT) for 140 routed packets. 142 Discussion: 143 Convergence Events include link loss, routing protocol session 144 loss, router failure, configuration change, and better next-hop 145 learned via a routing protocol. 147 Measurement Units: 148 N/A 150 Issues: 151 None 153 See Also: 154 Convergence Packet Loss 155 Convergence Event Instant 156 IGP Data Plane Route Convergence 158 3.2 Route Convergence 160 Definition: 161 Recovery from a Convergence Event indicated by the DUT 162 Throughput equal to the offered load. 164 Discussion: 165 Route Convergence is the action of all components of the router 166 being updated with the most recent route change(s) including the 167 Routing Information Base (RIB) and Forwaridng Information Base 168 (FIB), along with software and hardware tables. Route 169 Convergence can be observed externally by the rerouting of data 170 Traffic to a new egress interface. 172 Measurement Units: 173 N/A 175 Issues: 176 None 178 See Also: 179 Network Convergence 180 Full Convergence 181 Convergence Event 183 3.3 Network Convergence 185 Definition: 186 The completion of updating of all routing tables, including the 187 FIB, in all routers throughout the network. 189 Discussion: 190 Network Convergence is bounded by the sum of Route Convergence 191 for all routers in the network. Network Convergence can be 192 determined by recovery of the Throughput to equal the 193 offered load, with no Stale Forwarding, and no blenders[Ca01][Ci03]. 195 Measurement Units: 196 N/A 198 Issues: 199 None 201 See Also: 202 Route Convergence 203 Stale Forwarding 204 IGP Data Plane Route Convergence 206 3.4 Full Convergence 207 Definition: 208 Route Convergence for an entire FIB. 210 Discussion: 211 When benchmarking convergence, it is useful to measure 212 the time to converge an entire FIB. For example, 213 a Convergence Event can be produced for an OSPF table of 214 5000 routes so that the time to converge routes 1 through 215 5000 is measured. Full Convergence is externally observable 216 from the data plane when the Throughput of the data 217 plane traffic on the Next-Best Egress Interface equals the 218 offered load. 220 Measurement Units: 221 N/A 223 Issues: None 225 See Also: 226 Network Convergence 227 Route Convergence 228 Convergence Event 230 3.5 Convergence Packet Loss 232 Definition: 233 The amount of packet loss produced by a Convergence Event 234 until Route Convergence occurs. 236 Discussion: 237 Packet loss can be observed as a reduction of forwarded traffic 238 from the maximum Throughput. Convergence Packet Loss 239 includes packets that were lost and packets that were delayed 240 due to buffering. The maximum Convergence Packet Loss observed 241 in a Packet Sampling Interval may or may not reach 100% during 242 Route Convergence (see Figure 1). 244 Measurement Units: 245 number of packets 247 Issues: None 249 See Also: 250 Route Convergence 251 Convergence Event 252 Rate-Derived Convergence Time 253 Loss-Derived Convergence Time 254 Packet Sampling Interval 255 IGP Data Plane Route Convergence 257 3.6 Convergence Event Instant 259 Definition: 260 The time instant that a Convergence Event becomes observable in 261 the data plane. 263 Discussion: 264 Convergence Event Instant is observable from the data 265 plane as the precise time that the device under test begins 266 to exhibit packet loss. 268 Measurement Units: 269 hh:mm:ss:nnn, where 'nnn' is milliseconds 271 Issues: 272 None 274 See Also: 275 Convergence Event 276 Convergence Packet Loss 277 Convergence Recovery Instant 279 3.7 Convergence Recovery Instant 281 Definition: 282 The time instant that Full Convergence is measured 283 and then maintained for an interval of duration equal to 284 the Sustained Forwarding Convergence Time 286 Discussion: 287 Convergence Recovery Instant is measurable from the data 288 plane as the precise time that the device under test 289 achieves Full Convergence. 291 Measurement Units: 292 hh:mm:ss:uuu 294 Issues: 295 None 297 See Also: 298 Sustained Forwarding Convergence Time 299 Convergence Packet Loss 300 Convergence Event Instant 301 IGP Data Plane Route Convergence 303 3.8 Rate-Derived Convergence Time 304 Definition: 305 The amount of time for Convergence Packet Loss to persist upon 306 occurrence of a Convergence Event until occurrence of Route 307 Convergence. 309 Rate-Derived Convergence Time can be measured as the time 310 difference from the Convergence Event Instant to the 311 Convergence Recovery Instant, as shown with Equation 1. 313 (eq 1) Rate-Derived Convergence Time = 314 Convergence Recovery Instant - Convergence Event Instant. 316 Discussion: 317 Rate-Derived Convergence Time should be measured at the maximum 318 Throughput. Failure to achieve Full Convergence results in 319 a Rate-Derived Convergence Time benchmark of infinity. 321 Measurement Units: 322 seconds/milliseconds 324 Issues: 325 None 327 See Also: 328 Convergence Packet Loss 329 Convergence Recovery Instant 330 Convergence Event Instant 331 Full Convergence 333 3.9 Convergence Event Transition 334 Definition: 335 The characteristic of a router in which Throughput 336 gradually reduces to zero after a Convergence Event. 338 Discussion: 339 The Convergence Event Transition is best observed for 340 Full Convergence. The Convergence Event Transition may 341 not be linear. 343 Measurement Units: 344 seconds/milliseconds 346 Issues: 347 None 349 See Also: 350 Convergence Event 351 Rate-Derived Convergence Time 352 Convergence Packet Loss 353 Convergence Recovery Transition 354 IGP Data Plane Route Convergence 356 3.10 Convergence Recovery Transition 358 Definition: 359 The characteristic of a router in which Throughput 360 gradually increases to equal the offered load. 362 Discussion: 363 The Convergence Recovery Transition is best observed for 364 Full Convergence. The Convergence Event Transition may 365 not be linear. 367 Measurement Units: 368 seconds/milliseconds 370 Issues: None 372 See Also: 373 Full Convergence 374 Rate-Derived Convergence Time 375 Convergence Packet Loss 376 Convergence Event Transition 378 3.11 Loss-Derived Convergence Time 380 Definition: 381 The amount of time it takes for Route Convergence to 382 to be achieved as calculated from the Convergence Packet 383 Loss. Loss-Derived Convergence Time can be calculated 384 from Convergence Packet Loss that occurs due to a 385 Convergence Event and Route Convergence as shown with 386 Equation 2. 388 (eq 2) Loss-Derived Convergence Time = 389 Convergence Packets Loss / Offered Load 390 NOTE: Units for this measurement are 391 packets / packets/second = seconds 393 Discussion: 394 Loss-Derived Convergence Time gives a better than 395 actual result when converging many routes simultaneously. 396 Rate-Derived Convergence Time takes the Convergence Recovery 397 Transition into account, but Loss-Derived Convergence Time 398 ignores the Route Convergence Recovery Transition because 399 it is obtained from the measured Convergence Packet Loss. 401 Ideally, the Convergence Event Transition and Convergence 402 Recovery Transition are instantaneous so that the 403 Rate-Derived Convergence Time = Loss-Derived Convergence Time. 404 However, router implementations are less than ideal. 405 For these reasons the preferred reporting benchmark for IGP 406 Route Convergence is the Rate-Derived Convergence Time. 408 IGP Data Plane Route Convergence 410 Guidelines for reporting Loss-Derived Convergence Time are 411 provided in [Po062]. 413 Measurement Units: 414 seconds/milliseconds 416 Issues: 417 None 419 See Also: 420 Route Convergence 421 Convergence Packet Loss 422 Rate-Derived Convergence Time 423 Convergence Event Transition 424 Convergence Recovery Transition 426 3.12 Sustained Forwarding Convergence Time 428 Definition: 429 The amount of time for which Full Convergence is maintained 430 without additional packet loss. 432 Discussion: 433 The purpose of the Sustained Forwarding Convergence Time is to 434 produce Convergence benchmarks protected against fluctuation 435 in Throughput after Full Convergence is observed. The 436 Sustained Forwarding Convergence Time to be used is calculated 437 as shown in Equation 3. 439 (eq 3) 440 Sustained Forwarding Convergence Time = 441 5*(Convergence Packet Loss/Offered Load) 442 units are packets/pps = sec 444 for which at least one packet per route in the FIB for all 445 routes in the FIB MUST be offered to the DUT per second. 447 Measurement Units: 448 seconds or milliseconds 450 Issues: None 452 See Also: 453 Full Convergence 454 Convergence Recovery Instant 456 3.13 Restoration Convergence Time 457 Definition: 458 The amount of time for the router under test to restore 459 traffic to the original outbound port after recovery from 460 a Convergence Event. 462 IGP Data Plane Route Convergence 464 Discussion: 465 Restoration Convergence Time is the amount of time for routes 466 to converge to the original outbound port. This is achieved 467 by recovering from the Convergence Event, such as restoring 468 the failed link. Restoration Convergence Time is measured 469 using the Rate-Derived Convergence Time calculation technique, 470 as provided in Equation 1. It is possible to have the 471 Restoration Convergence Time differ from the Rate-Derived 472 Convergence Time. 474 Measurement Units: 475 seconds or milliseconds 477 Issues: 478 None 480 See Also: 481 Convergence Event 482 Rate-Derived Convergence Time 484 3.14 Packet Sampling Interval 485 Definition: 486 The interval at which the tester (test equipment) polls to make 487 measurements for arriving packet flows. 489 Discussion: 490 Metrics measured at the Packet Sampling Interval MUST include 491 Forwarding Rate and Convergence Packet Loss. 493 Measurement Units: 494 seconds or milliseconds 496 Issues: 497 Packet Sampling Interval can influence the Convergence Graph. 498 This is particularly true when implementations achieve Full 499 Convergence in less than 1 second. The Convergence Event 500 Transition and Convergence Recovery Transition can become 501 exaggerated when the Packet Sampling Interval is too long. 502 This will produce a larger than actual Rate-Derived 503 Convergence Time. The recommended value for configuration 504 of the Packet Sampling Interval is provided in [Po062]. 506 See Also: 507 Convergence Packet Loss 508 Convergence Event Transition 509 Convergence Recovery Transition 510 IGP Data Plane Route Convergence 512 3.15 Local Interface 513 Definition: 514 An interface on the DUT. 516 Discussion: 517 None 519 Measurement Units: 520 N/A 522 Issues: 523 None 525 See Also: 526 Neighbor Interface 527 Remote Interface 529 3.16 Neighbor Interface 531 Definition: 532 The interface on the neighbor router or tester that is 533 directly linked to the DUT's Local Interface. 535 Discussion: 536 None 538 Measurement Units: 539 N/A 541 Issues: 542 None 544 See Also: 545 Local Interface 546 Remote Interface 548 3.17 Remote Interface 550 Definition: 551 An interface on a neighboring router that is not directly 552 connected to any interface on the DUT. 554 Discussion: 555 None 557 Measurement Units: 558 N/A 560 Issues: 561 None 562 IGP Data Plane Route Convergence 564 See Also: 565 Local Interface 566 Neighbor Interface 568 3.18 Preferred Egress Interface 570 Definition: 571 The outbound interface from the DUT for traffic routed to the 572 preferred next-hop. 574 Discussion: 575 The Preferred Egress Interface is the egress interface prior 576 to a Convergence Event. 578 Measurement Units: 579 N/A 581 Issues: 582 None 584 See Also: 585 Next-Best Egress Interface 587 3.19 Next-Best Egress Interface 589 Definition: 590 The outbound interface from the DUT for traffic routed to the 591 second-best next-hop. It is the same media type and link speed 592 as the Preferred Egress Interface 594 Discussion: 595 The Next-Best Egress Interface becomes the egress interface 596 after a Convergence Event. 598 Measurement Units: 599 N/A 601 Issues: 602 None 604 See Also: 605 Preferred Egress Interface 606 IGP Data Plane Route Convergence 608 3.20 Stale Forwarding 610 Definition: 611 Forwarding of traffic to route entries that no longer exist 612 or to route entries with next-hops that are no longer preferred. 614 Discussion: 615 Stale Forwarding can be caused by a Convergence Event and is 616 also known as a "black-hole" since it may produce packet loss. 617 Stale Forwarding exists until Network Convergence is achieved. 619 Measurement Units: 620 N/A 622 Issues: 623 None 625 See Also: 626 Network Convergence 628 3.21 Nested Convergence Events 630 Definition: 631 The occurence of Convergence Event while the route table 632 is converging from a prior Convergence Event. 634 Discussion: 635 The Convergence Events for a Nested Convergence Events 636 MUST occur with different neighbors. A common 637 observation from a Nested Convergence Event will be 638 the withdrawal of routes from one neighbor while the 639 routes of another neighbor are being installed. 641 Measurement Units: 642 N/A 644 Issues: 645 None 647 See Also: 648 Convergence Event 650 4. IANA Considerations 652 This document requires no IANA considerations. 654 IGP Data Plane Route Convergence 656 5. Security Considerations 658 Documents of this type do not directly affect the security of 659 Internet or corporate networks as long as benchmarking 660 is not performed on devices or systems connected to production 661 networks. 663 6. Acknowledgements 664 Thanks to Sue Hares, Al Morton, Kevin Dubray, and participants of 665 the BMWG for their contributions to this work. 667 7. References 668 7.1 Normative References 670 [Ba91]Bradner, S. "Benchmarking Terminology for Network 671 Interconnection Devices", RFC1242, July 1991. 673 [Ba99]Bradner, S. and McQuaid, J., "Benchmarking 674 Methodology for Network Interconnect Devices", 675 RFC 2544, March 1999. 677 [Ca90]Callon, R., "Use of OSI IS-IS for Routing in TCP/IP and Dual 678 Environments", RFC 1195, December 1990. 680 [Ma98]Mandeville, R., "Benchmarking Terminology for LAN 681 Switching Devices", RFC 2285, February 1998. 683 [Mo98]Moy, J., "OSPF Version 2", RFC 2328, IETF, April 1998. 685 [Po061]Poretsky, S., "Benchmarking Applicability for IGP Data Plane 686 Route Convergence", draft-ietf-bmwg-igp-dataplane-conv-app-11, 687 work in progress, May 2006. 689 [Po062]Poretsky, S., "Benchmarking Methodology for IGP Data Plane 690 Route Convergence", draft-ietf-bmwg-igp-dataplane-conv-meth-11, 691 work in progress, May 2006. 693 7.2 Informative References 695 [Ca01]S. Casner, C. Alaettinoglu, and C. Kuan, "A Fine-Grained View 696 of High Performance Networking", NANOG 22, June 2001. 698 [Ci03]L. Ciavattone, A. Morton, and G. Ramachandran, "Standardized 699 Active Measurements on a Tier 1 IP Backbone", IEEE 700 Communications Magazine, pp90-97, May 2003. 702 IGP Data Plane Route Convergence 704 8. Author's Address 706 Scott Poretsky 707 Reef Point Systems 708 8 New England Executive Park 709 Burlington, MA 01803 710 USA 712 Phone: + 1 508 439 9008 713 EMail: sporetsky@reefpoint.com 715 Brent Imhoff 716 Juniper Networks 717 1194 North Mathilda Ave 718 Sunnyvale, CA 94089 719 USA 721 Phone: + 1 314 378 2571 722 EMail: bimhoff@planetspork.com 724 Full Copyright Statement 726 Copyright (C) The Internet Society (2006). 728 This document is subject to the rights, licenses and restrictions 729 contained in BCP 78, and except as set forth therein, the authors 730 retain all their rights. 732 This document and the information contained herein are provided on an 733 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 734 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 735 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 736 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 737 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 738 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 740 IGP Data Plane Route Convergence 742 Intellectual Property 743 The IETF takes no position regarding the validity or scope of any 744 Intellectual Property Rights or other rights that might be claimed to 745 pertain to the implementation or use of the technology described in 746 this document or the extent to which any license under such rights 747 might or might not be available; nor does it represent that it has 748 made any independent effort to identify any such rights. Information 749 on the procedures with respect to rights in RFC documents can be 750 found in BCP 78 and BCP 79. 752 Copies of IPR disclosures made to the IETF Secretariat and any 753 assurances of licenses to be made available, or the result of an 754 attempt made to obtain a general license or permission for the use of 755 such proprietary rights by implementers or users of this 756 specification can be obtained from the IETF on-line IPR repository at 757 http://www.ietf.org/ipr. 759 The IETF invites any interested party to bring to its attention any 760 copyrights, patents or patent applications, or other proprietary 761 rights that may cover technology that may be required to implement 762 this standard. Please address the information to the IETF at ietf- 763 ipr@ietf.org. 765 Acknowledgement 766 Funding for the RFC Editor function is currently provided by the 767 Internet Society.