idnits 2.17.1 draft-eardley-pcn-marking-behaviour-00.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 15. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 635. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 646. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 653. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 659. 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 : ---------------------------------------------------------------------------- No issues found here. 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 (April 29, 2008) is 5838 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) No issues found here. Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 PCN Working Group (Editor) 3 Internet-Draft BT 4 Intended status: Standards Track April 29, 2008 5 Expires: October 31, 2008 7 Marking behaviour of PCN-nodes 8 draft-eardley-pcn-marking-behaviour-00 10 Status of this Memo 12 By submitting this Internet-Draft, each author represents that any 13 applicable patent or other IPR claims of which he or she is aware 14 have been or will be disclosed, and any of which he or she becomes 15 aware will be disclosed, in accordance with Section 6 of BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This Internet-Draft will expire on October 31, 2008. 35 Copyright Notice 37 Copyright (C) The IETF Trust (2008). 39 Abstract 41 This document standardises the two marking behaviours of PCN-nodes: 42 threshold marking and excess traffic marking. Threshold marking 43 marks all PCN-packets if the PCN traffic rate is greater than a first 44 configured rate. Excess traffic marking marks a proportion of PCN- 45 packets, such that the amount marked equals the traffic rate in 46 excess of a second configured rate. 48 Requirements Language 50 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 51 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 52 document are to be interpreted as described in RFC 2119 [RFC2119]. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 2. Specified PCN-marking behaviour . . . . . . . . . . . . . . . 4 58 2.1. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 5 59 2.2. Classify and condition function . . . . . . . . . . . . . 5 60 2.3. Threshold meter function . . . . . . . . . . . . . . . . . 6 61 2.4. Excess traffic meter function . . . . . . . . . . . . . . 6 62 2.5. Marking function . . . . . . . . . . . . . . . . . . . . . 7 63 3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 64 4. Security Considerations . . . . . . . . . . . . . . . . . . . 8 65 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8 66 6. Authors . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 67 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 68 7.1. Normative References . . . . . . . . . . . . . . . . . . . 8 69 7.2. Informative References . . . . . . . . . . . . . . . . . . 8 70 Appendix A. Example algorithms . . . . . . . . . . . . . . . . . 9 71 A.1. Threshold metering and marking . . . . . . . . . . . . . . 9 72 A.2. Excess traffic metering and marking . . . . . . . . . . . 10 73 Appendix B. Implementation notes . . . . . . . . . . . . . . . . 11 74 B.1. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 11 75 B.2. Classify and condition . . . . . . . . . . . . . . . . . . 11 76 B.3. Threshold metering . . . . . . . . . . . . . . . . . . . . 12 77 B.4. Excess traffic metering . . . . . . . . . . . . . . . . . 13 78 B.5. Marking . . . . . . . . . . . . . . . . . . . . . . . . . 14 79 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 14 80 Intellectual Property and Copyright Statements . . . . . . . . . . 15 82 1. Introduction 84 [draft-pcn-architecture] describes a general architecture for flow 85 admission and termination based on pre-congestion information in 86 order to protect the quality of service of established inelastic 87 flows within a single DiffServ domain. The pre-congestion 88 information consists of specific markings of PCN-packets. The edge 89 nodes of the DiffServ domain read these markings and convert them 90 into flow admission and termination decisions. Overall the aim is to 91 enable PCN-nodes to give an "early warning" of potential congestion 92 before there is any significant build-up of PCN-packets in their 93 queues. 95 This document standardises the two marking behaviours of PCN-nodes. 96 In summary, their objectives are: 98 o threshold marking: its objective is to mark all PCN-packets (with 99 a "threshold-mark") whenever the rate of PCN-packets is greater 100 than some configured rate ("PCN-threshold-rate"); 102 o excess traffic marking: whenever the rate of PCN-packets is 103 greater than some configured rate ("PCN-excess-rate"), its 104 objective is to mark PCN-packets (with an "excess-traffic-mark") 105 at a rate equal to the difference between the bit rate of PCN- 106 packets and the PCN-excess-rate. 108 [draft-pcn-architecture] describes how the admission control 109 mechanism limits the PCN-traffic on each link to *roughly* its PCN- 110 threshold-rate and how the flow termination mechanism limits the PCN- 111 traffic on each link to *roughly* its PCN-excess-rate. 113 Section 2 specifies the functions involved, which in outline are: 115 o Packet classify and condition - decide whether an incoming packet 116 belongs to a PCN-flow or not; drop (or downgrade) packets if the 117 link is overloaded; 119 o Threshold meter - determine whether the rate of PCN-packets is 120 greater than the configured PCN-threshold-rate; 122 o Excess traffic meter - measure by how much the rate of PCN-packets 123 is greater than the configured PCN-excess-rate; 125 o Mark - actually mark the PCN-packets, if the meter functions 126 indicate to do so; 128 [pcn-encoding] specifies the actual encoding, which uses the DSCP and 129 ECN fields. In a particular deployment the operator may have three 130 encoding states available (so allowing both threshold marking and 131 excess traffic marking) or may have only two encoding state, which it 132 may use for either threshold marking or excess traffic marking. This 133 leads to the following four use cases: 135 1. an operator requires both admission control and flow termination, 136 and has three encoding states available. Then admission control 137 is triggered from PCN-packets that are threshold-marked, and flow 138 termination from PCN-packets that are excess-traffic-marked 139 [ref]. 141 2. an operator requires both admission control and flow termination, 142 and has only two encoding states available. Then both admission 143 control and flow termination are triggered from PCN-packets that 144 are excess-traffic-marked [ref]. 146 3. an operator requires only admission control. Then admission 147 control is triggered from PCN-packets that are threshold-marked 148 and only two encoding states are needed. 150 4. an operator requires only flow termination. Then flow 151 termination is triggered from PCN-packets that are excess- 152 traffic-marked and only one encoding states are needed. 154 +---------+ Result 155 +->|Threshold|-------+ 156 | | Meter | | 157 | +---------+ V 158 +---------+ | +--------+ 159 |Classify | | | | Marked 160 Packet ===>| & |==?================>| Marker |===> Packet 161 Stream |Condition| | | | Stream 162 +---------+ | +--------+ 163 | +---------+ ^ 164 | | Excess | | 165 +->| Traffic |-------+ 166 | Meter | Result 167 +---------+ 169 Figure 1: Schematic of functions for PCN-marking 171 2. Specified PCN-marking behaviour 172 2.1. Scope 174 The functions defined in the following sub-sections SHOULD be 175 implemented on all links in the PCN-domain. 177 There are three possibilities regarding encoding states: 179 o three encoding states are available, 181 * one for threshold marks, 183 * one for excess rate marks 185 * one for "not PCN-marked"; 187 o two encoding states are available, 189 * one for threshold marks 191 * one for "not PCN-marked"; 193 o two encoding states are available, 195 * one for excess rate marks 197 * one for "not PCN-marked". 199 The same choice MUST be used throughout a PCN-domain. 201 The descriptions in the following sub-sections are functional and are 202 not intended to restrict the implementation. 204 2.2. Classify and condition function 206 A packet MUST be classified as a PCN-packet if the value of its DSCP 207 and ECN fields are as described in [draft-pcn-encoding]. 209 There may be traffic that is more important than PCN that shares the 210 same capacity as PCN and is priority scheduled over PCN (perhaps an 211 operator's control messages). Such traffic MUST be metered as though 212 it were PCN-traffic, but MUST NOT be PCN-marked. Such packets, 213 together with PCN-packets, are called "metered packets". 215 Otherwise the packet MUST NOT be classified as a PCN-packet. 217 If the level of traffic is sufficiently high to overload the PCN 218 behaviour aggregate(s), then traffic MUST be conditioned. The three 219 possibilities are: 221 o drop PCN-packets; 223 o downgrade PCN-packets to a lower priority behaviour aggregate, 224 such as best effort or assured forwarding, and perhaps drop lower 225 priority packets; 227 o drop or downgrade other "metered packets". 229 If PCN-packets are dropped (or downgraded) then: 231 o excess-traffic-marked PCN-packets SHOULD be preferentially dropped 232 (downgraded); 234 o PCN-packets that are dropped (downgraded) SHOULD NOT be metered by 235 the Excess traffic Meter. 237 2.3. Threshold meter function 239 The Threshold Meter MUST have behaviour that is functionally 240 equivalent to the following. 242 The meter is a token bucket, which is sized in bits and has a 243 configured bit rate, termed PCN-threshold-rate. The amount of tokens 244 in the token bucket is termed TB1.fill. Tokens are added at the PCN- 245 threshold-rate, to a maximum value TB1.max. Tokens are removed equal 246 to the size in bits of the metered-packet, to a minimum TB1.fill=0. 248 The token bucket has a configured token bucket depth (between 0 and 249 TB1.max), termed TB1.threshold. If TB1.fill < TB1.threshold, then 250 the meter indicates to the Marking function that the packet is to be 251 threshold-marked; otherwise it does not. 253 2.4. Excess traffic meter function 255 A packet SHOULD NOT be metered (by this excess traffic meter 256 function) in the following two cases: 258 o If the packet is already excess-traffic-marked; 260 o If this PCN-node drops (downgrades) the packet because the link is 261 overloaded. 263 Otherwise it is metered by the Excess traffic Meter. 265 The Excess traffic Meter MUST have behaviour that is functionally 266 equivalent to the following. 268 The meter is a token bucket, which is sized in bits and has a 269 configured bit rate, termed PCN-excess-rate. The amount of tokens in 270 the token bucket is termed TB2.fill. Tokens are added at the PCN- 271 excess-rate, to a maximum value TB2.max. Tokens are removed equal to 272 the size in bits of the metered-packet, to a minimum value of 0. The 273 PCN-excess-rate is greater than (or equal to) the PCN-threshold-rate. 275 If the token bucket is empty (TB2.fill = 0), then the meter indicates 276 to the Marking function that the packet is to be excess-traffic- 277 marked. If the token bucket is within an MTU of being empty, then 278 the meter SHOULD indicate to the Marking function that the packet is 279 to be excess-traffic-marked; MTU means the maximum size of PCN- 280 packets on the link. Otherwise the meter does not indicate marking. 282 2.5. Marking function 284 If the packet is not a PCN-packet, then it MUST NOT be marked. A 285 PCN-packet MUST be marked to reflect the metering results by setting 286 its encoding state appropriately, as specified below. The encoding 287 states are defined values of the DSCP and ECN fields, as specified in 288 [pcn-encoding]. 290 There are three possibilities, depending on how many encoding states 291 are available: 293 o if three encoding states are available (one for threshold-marked, 294 one for excess-traffic-marked and one for "not PCN-marked") then: 296 * the encoding state of a packet that has already been excess- 297 traffic-marked is not altered, whatever the meters indicate; 299 * Otherwise: 301 + if both meters indicate marking, then the packet is excess- 302 traffic-marked; 304 + if one meter indicates marking and the other doesn't, then 305 that marking is applied; 307 + if neither meter indicates marking, then the packet's 308 encoding state is not altered. 310 o if two encoding states are available (one for threshold-marked and 311 one for "not PCN-marked") then: 313 * if the Threshold Meter indicates marking, then the packet is 314 threshold-marked; 316 * otherwise the packet's encoding state is not altered. 318 o if two encoding states are available (one for excess-traffic- 319 marked and one for "not PCN-marked") then: 321 * if the Excess traffic Meter indicates marking, then the packet 322 is excess-traffic-marked; 324 * otherwise the packet's encoding state is not altered. 326 3. IANA Considerations 328 This document makes no request of IANA. 330 Note to RFC Editor: this section may be removed on publication as an 331 RFC. 333 4. Security Considerations 335 See [draft-pcn-architecture] 337 5. Acknowledgements 339 Michael Menth, Joe Babiarz, Anna Charny reviewed this draft. 341 All the work by many people in the PCN WG. 343 6. Authors 345 Many people need to be added. 347 7. References 349 7.1. Normative References 351 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 352 Requirement Levels", BCP 14, RFC 2119, March 1997. 354 7.2. Informative References 356 [t] "", 2004. 358 Appendix A. Example algorithms 360 Note: This Appendix is informative, not normative. It is an example 361 of algorithms that implement Section 2 and is based on 362 [draft-charny-pcn-comparison] and 363 [http://www3.informatik.uni-wuerzburg.de/staff/menth/Publications/ 364 Menth08-PCN-Comparison.pdf]. 366 There is no attempt to optimise the algorithms. It implements the 367 metering and marking functions together. It is assumed that three 368 encoding states are available (one for threshold-marked, one for 369 excess-traffic-marked and one for "not PCN-marked"). It is assumed 370 that all metered-packets are PCN-packets and that the link is never 371 overloaded. 373 A.1. Threshold metering and marking 375 A token bucket with the following parameters: 377 o TB1.PCN-threshold-rate: token rate of token bucket (bits/second) 379 o TB1.max: depth of token bucket (bits) 381 o TB1.threshold: marking threshold of token bucket (bits) 383 o TB1.lastUpdate: time the token bucket was last updated (seconds) 385 o TB1.fill: amount of tokens in token bucket (bits) 387 A PCN-packet has the following parameters: 389 o packet.size: the size of the PCN-packet (bits) 391 o packet.mark: the PCN encoding state of the packet 393 In addition there are the parameters: 395 o now: the current time (seconds) 397 The following steps are performed when a PCN-packet arrives on a 398 link: 400 o TB1.fill = min(TB1.max, TB1.fill + (now - TB1.lastUpdate) * 401 TB1.PCN-threshold-rate); // add tokens to token bucket 403 o TB1.fill = max(0, TB1.fill - packet.size); // remove tokens from 404 token bucket 406 o if ((TB1.fill < TB1.threshold) AND (packet.mark != excess-traffic- 407 marked)) then packet.mark = threshold-marked; // do threshold 408 marking, but don't re-mark packets that are already excess- 409 traffic-marked 411 o TB1.lastUpdate = now 413 A.2. Excess traffic metering and marking 415 A token bucket with the following parameters: 417 o TB2.PCN-excess-rate: token rate of token bucket (bits/second) 419 o TB2.max: depth of TB in token bucket (bits) 421 o TB2.lastUpdate: time the token bucket was last updated (seconds) 423 o TB2.fill: amount of tokens in token bucket (bits) 425 A PCN-packet has the following parameters: 427 o packet.size: the size of the PCN-packet (bits) 429 o packet.mark: the PCN encoding state of the packet 431 In addition there are the parameters: 433 o now: the current time (seconds) 435 o MTU: the maximum transfer unit of the link (or the known maximum 436 size of PCN-packets on the link) (bits) 438 The following steps are performed when a PCN-packet arrives on a 439 link: 441 o TB2.fill = min(TB2.max, TB2.fill + (now - TB2.lastUpdate) * 442 TB2.PCN-excess-rate); // add tokens to token bucket 444 o if (packet.mark != excess-traffic-marked) then TB2.fill = max(0, 445 TB2.fill - packet.size); // remove tokens from token bucket, but 446 do not meter packets that are already excess-traffic-marked 448 o if (TB2.fill < MTU) then packet.mark = excess-traffic-marked; // 449 do (packet size independent) excess traffic marking 451 o TB1.lastUpdate = now 453 Appendix B. Implementation notes 455 Note: This Appendix is informative, not normative. It comments on 456 Section 2. 458 B.1. Scope 460 It may be known, eg by the design of the network topology, that some 461 links can never be pre-congested (even in unusual circumstances, eg 462 after the failure of some links). There is then no need to implement 463 PCN behaviour on those links. 465 The meter and marker can be implemented on the ingoing or outgoing 466 interface of a PCN-node. It may be that existing hardware can 467 support only one meter and marker per ingoing interface and one per 468 outgoing interface. Then for instance threshold metering and marking 469 could be run on all the ingoing interfaces and excess traffic 470 metering and marking on all the outgoing interfaces; note that the 471 same choice must be made for all the links in a PCN-domain to ensure 472 that the two metering behaviours are applied exactly once for all the 473 links. 475 Note that even if there is only one encoding state both the meters 476 are still implemented, in order to ease compatibility between 477 equipment and remove a configuration option and associated 478 complexity. Although this means that the Marking function ignores 479 indications from one of the meters, they might be logged or acted 480 upon in some other way, for example by the management system or an 481 explicit signalling protocol; such considerations are out of scope of 482 PCN. 484 B.2. Classify and condition 486 Traffic that has a higher DiffServ priority than PCN, but shares the 487 same capacity, is metered as though it were PCN-traffic but cannot be 488 PCN-marked. This means that a meter may indicate a packet is to be 489 PCN-marked, but the Marking function knows it cannot be marked. It 490 is left open to the implementation exactly what to do in this case; 491 one simple possibility is to mark the next PCN-packet. Note that 492 unless the PCN-packets are a large fraction of all the metered- 493 packets then the PCN mechanisms may not work well. 495 Preferential dropping of excess-traffic-marked packets: Section 2.2 496 specifies: "If the level of traffic is sufficiently high to overload 497 the PCN behaviour aggregate(s), then traffic MUST be conditioned ... 498 excess-traffic-marked PCN-packets SHOULD be preferentially dropped 499 (downgraded)". This avoids over-termination, with the CL/SM edge 500 behaviour, in the event of multiple bottlenecks in the PCN-domain 502 [ref]. 504 Exactly what "preferentially dropped" means is left to the 505 implementation. It is also left to the implementation what to do if 506 there are no excess-traffic-marked PCN-packets available at a 507 particular instant. 509 515 Section 2.2 also specifies: "PCN-packets that are dropped 516 (downgraded) SHOULD NOT be metered by the Excess traffic Meter." 517 This avoids over-termination, with the CL/SM edge behaviour, in the 518 event of multiple bottlenecks [ref]. 520 B.3. Threshold metering 522 The description is in terms of a 'token bucket with threshold', 523 however the implementation is not standardised. For example, it 524 could equally well be implemented as a virtual queue [ref]. 526 The behaviour must be functionally equivalent to the description 527 above. "Functionally equivalent" is intended to allow implementation 528 freedom over matters such as: 530 533 o whether tokens are added to the token bucket at regular time 534 intervals or only when a packet is processed 536 o whether the new token bucket depth is calculated before or after 537 it is decided whether to mark the packet. The effect of this is 538 simply to shift the sequence of marks by one packet. 540 o when the token bucket is very nearly empty and a packet arrives 541 larger than TB1.fill, then the precise change in TB1.fill is up to 542 the implementation. Essentially any behaviour is functionally 543 equivalent if either precisely the same set of packets is marked, 544 or if the set is shifted by one packet. For instance, the 545 following should all be considered as "functionally equivalent": 547 * set TB1.fill = 0 and indicate threshold-mark to the Marking 548 function. 550 * check whether TB1.fill < TB1.threshold and if it is then 551 indicate threshold-mark to the Marking function; then set 552 TB1.fill = 0. 554 * leave TB1.fill unaltered and indicate threshold-mark to the 555 Marking function. 557 o similarly, when the token bucket is very nearly full and a packet 558 arrives large than (TB1.max - TB1.fill), then the precise change 559 in TB1.fill is up to the implementation. 561 B.4. Excess traffic metering 563 The description is in terms of a token bucket, however the 564 implementation is not standardised. 566 As in Section B.3, "functionally equivalent" allows some 567 implementation flexibility when the token bucket is very nearly empty 568 or very nearly full. 570 Packet size independent marking is specified as a SHOULD in Section 571 2.4 ( "If the token bucket is within an MTU of being empty, then the 572 meter SHOULD indicate to the Marking function that the packet is to 573 be excess-traffic-marked; MTU means the maximum size of PCN-packets 574 on the link.") Without it, large packets are more likely to be 575 excess-traffic-marked than small packets and this means that, with 576 some edge behaviours, flows with large packets are more likely to be 577 terminated than flows with small packets [refs: http:// 578 www3.informatik.uni-wuerzburg.de/staff/menth/Publications/ 579 Menth08-PCN-MFT.pdf & http://www.ietf.org/internet-drafts/ 580 draft-briscoe-tsvwg-byte-pkt-mark-02.txt]. 582 Section 2.4 specifies: "A metered-packet SHOULD NOT be metered (by 583 this excess traffic meter function) ... If the packet is already 584 excess-traffic-marked". This avoids over-termination (with some edge 585 behaviours) in the event that the PCN-traffic passes through multiple 586 bottlenecks in the PCN-domain [ref]. Note that an implementation 587 could determine whether the packet is already excess-traffic-marked 588 as an integral part of its Classification function. 590 Note that TB2.max is independent of TB1.max; TB2.fill is independent 591 of TB1.fill (except in that a packet changes both); and the two 592 configured rates, PCN-excess-rate and PCN-threshold-rate are 593 independent (except that PCN-excess-rate >= PCN-threshold-rate). 595 B.5. Marking 597 Although the metering functions are described separately from the 598 Marking function, they can be implemented in an integrated fashion. 600 [pcn-encoding] specifies the encoding states. In some environments 601 encoding states may be scarce, for example MPLS, and then only one 602 encoding state may be preferable. 604 Section 2.5 states: "if three encoding states are available ... if 605 one meter indicates marking and the other doesn't, then that marking 606 is applies". Normally this means that the Threshold Meter indicates 607 marking and the Excess traffic Meter doesn't. However, the reverse 608 is possible for a short time - because the meters react at different 609 speeds when the traffic rate changes. 611 Author's Address 613 Philip Eardley +++ 614 BT 615 Adastral Park, Martlesham Heath 616 Ipswich IP5 3RE 617 UK 619 Email: philip.eardley@bt.com 621 Full Copyright Statement 623 Copyright (C) The IETF Trust (2008). 625 This document is subject to the rights, licenses and restrictions 626 contained in BCP 78, and except as set forth therein, the authors 627 retain all their rights. 629 This document and the information contained herein are provided on an 630 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 631 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 632 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 633 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 634 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 635 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 637 Intellectual Property 639 The IETF takes no position regarding the validity or scope of any 640 Intellectual Property Rights or other rights that might be claimed to 641 pertain to the implementation or use of the technology described in 642 this document or the extent to which any license under such rights 643 might or might not be available; nor does it represent that it has 644 made any independent effort to identify any such rights. Information 645 on the procedures with respect to rights in RFC documents can be 646 found in BCP 78 and BCP 79. 648 Copies of IPR disclosures made to the IETF Secretariat and any 649 assurances of licenses to be made available, or the result of an 650 attempt made to obtain a general license or permission for the use of 651 such proprietary rights by implementers or users of this 652 specification can be obtained from the IETF on-line IPR repository at 653 http://www.ietf.org/ipr. 655 The IETF invites any interested party to bring to its attention any 656 copyrights, patents or patent applications, or other proprietary 657 rights that may cover technology that may be required to implement 658 this standard. Please address the information to the IETF at 659 ietf-ipr@ietf.org. 661 Acknowledgment 663 Funding for the RFC Editor function is provided by the IETF 664 Administrative Support Activity (IASA).