idnits 2.17.1 draft-ietf-avt-tfrc-profile-10.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 14. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 510. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 481. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 488. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 494. 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 (22 July 2007) is 6122 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) ** Obsolete normative reference: RFC 4566 (Obsoleted by RFC 8866) == Outdated reference: A later version (-06) exists of draft-ietf-dccp-rfc3448bis-01 == Outdated reference: A later version (-12) exists of draft-ietf-avt-profile-savpf-10 == Outdated reference: A later version (-06) exists of draft-ietf-dccp-dtls-00 Summary: 2 errors (**), 0 flaws (~~), 4 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Engineering Task Force AVT WG 2 INTERNET-DRAFT Ladan Gharai 3 Intended status: Standards Track 22 July 2007 4 draft-ietf-avt-tfrc-profile-10.txt 5 Expires: January 2008 7 RTP with TCP Friendly Rate Control 9 Status of this Memo 11 By submitting this Internet-Draft, each author represents that any 12 applicable patent or other IPR claims of which he or she is aware 13 have been or will be disclosed, and any of which he or she becomes 14 aware will be disclosed, in accordance with Section 6 of BCP 79. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that other 18 groups may also distribute working documents as Internet-Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six months 21 and may be updated, replaced, or obsoleted by other documents at any 22 time. It is inappropriate to use Internet-Drafts as reference 23 material or to cite them other than as "work in progress." 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/ietf/1id-abstracts.txt 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html. 31 Copyright Notice 33 Copyright (C) The IETF Trust (2007). 35 Abstract 37 This memo specifies how the TCP Friendly Rate Control (TFRC) of RTP 38 flows can be supported using the RTP/AVPF profile and the general RTP 39 header extension mechanism. AVPF feedback packets and RTP header 40 extensions are defined to support the exchange of control information 41 between RTP TFRC senders and receivers. TFRC is an equation-based 42 congestion control scheme for unicast flows operating in a best 43 effort Internet environment. 45 1. Introduction 47 [Note to RFC Editor: All references to RFC XXXX are to be replaced 48 with the RFC number of this memo, when published] 50 This memo specifies how the TCP Friendly Rate Control (TFRC) of RTP 51 flows can be supported using the RTP/AVPF [RFC3550][RFC4585] profile 52 and RTP header extensions, by defining a new header extension and 53 AVPF feedback packet, and related parameters. Any of the AVPF based 54 RTP profiles, such as SAVPF, can be used to support TFRC RTP flows. 56 TFRC is an equation-based congestion control scheme for unicast flows 57 operating in a best effort Internet environment and competing with 58 TCP traffic. TFRC computes a TCP-friendly data rate based on current 59 network conditions, as represented by the latest round trip time and 60 packet loss calculations. The complete TFRC mechanism is described in 61 detail in [RFC3448bis]. 63 To calculate a TCP-friendly data rate and keep track of round trip 64 times and packet losses, TFRC senders and receivers rely on 65 exchanging specific information between each other, i.e: the sender 66 provides the receiver with the latest updates to round trip time 67 calculations, while the receiver provides feedback needed to compute 68 round trip times and on packet losses. This memo defines how this 69 information can be exchanged between TFRC senders and receiver with 70 RTP header extensions and an AVPF feedback packet. 72 2. Terminology 74 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 75 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 76 document are to be interpreted as described in RFC 2119 [RFC2119]. 78 3. Relation to the Datagram Congestion Control Protocol 80 The TFRC congestion control mechanism is one of a set of congestion 81 control methods provided by the Datagram Congestion Control Protocol 82 (DCCP) [RFC4340] In this section we detail the pros and cons of using 83 TFRC with RTP versus DCCP. 85 DCCP is a minimal general purpose transport-layer protocol with 86 unreliable yet congestion controlled packet delivery semantics and 87 reliable connection setup and teardown [RFC4336]. DCCP currently 88 supports both TFRC [RFC4342] and TCP-like [RFC4341] congestion 89 control, and the protocol is structured to support new congestion 90 control mechanisms defined in the future. A DCCP mapping for RTP has 91 been standardized for media applications [RFCxRTP]. In addition DCCP 92 supports a host of other features, such as: use of Explicit 93 Congestion Notification (ECN) and the ECN Nonce, flexible options 94 processing, reliable option negotiation, DTLS [ID.DTLS], Path Maximum 95 Transfer Unit (PMTU) and Service Codes. Naturally an application 96 using RTP/DCCP as its transport protocol will benefit from the 97 protocol features supported by DCCP. 99 However there are a number of benefits to be gained by the 100 development and standardization of the use RTP with TFRC: 102 o Media applications lacking congestion control can incorporate 103 congestion controlled transport without delay by using RTP with 104 TFRC. Widespread deployment of the DCCP protocol is not currently 105 in place. 107 o Use of RTP with TFRC is not contingent on any OS level changes 108 and can be quickly deployed, because RTP is implemented at the 109 application layer. 111 o RTP/UDP flows face the same restrictions in firewall traversal 112 as do UDP flows and do not require NATs and firewall 113 modifications. DCCP flows, on the other hand, do require NAT 114 and firewall modifications, however once these modifications are 115 in place, they can result in easier NAT and firewall traversal 116 for RTP/DCCP flows in the future. 118 o Use of RTP with TFRC with various media applications will give 119 researchers, implementors and developers a better understanding 120 of the intricate relationship between media quality and 121 equation-based congestion control. Hopefully this experience 122 with congestion control and TFRC will ease the migration of media 123 applications to DCCP once DCCP is deployed. 125 Using the AVPF/RTP profile and header extension to support TFRC 126 provides an immediate means for congestion control in media streams, 127 in the time until DCCP is deployed. 129 Additionally, there are also a number of technical differences as to 130 how (and which) congestion control information is exchanged between 131 DCCP with CCID3 and RTP: 133 o Using header extensions the RTP TFRC sender transmits a 134 send timestamp to the RTP TFRC receiver with every data packet. 135 In addition to congestion control the send timestamp can be 136 used by the receiver for jitter calculations. 138 In contrast DCCP with CCID3 transmits a quad round trip 139 counter to the receiver. 141 o The RTP TFRC receiver only provides the RTP TFRC sender 142 with the loss event rate as computed by the receiver. 144 In contrast DCCP with CCID3, provides 2 other options for the 145 transport of loss event rate. A sender may choose to receive 146 loss intervals or an Ack Vector. These two options provide the 147 sender with the necessary information to compute the loss event 148 rate. 150 o Sequence number: DCCP supports a 48 bit and a 24 bit sequence 151 number, whereas RTP only supports a 16 bit sequence number. While 152 this makes RTP susceptible to data injection attacks, it can be 153 avoided by using the SRTP [RFC3711] profile. 155 4. The TFRC Information Exchange Loop 157 TFRC depends on the exchange of congestion control information 158 between a sender and receiver. In this section we reiterate which 159 items are exchanged between a TFRC sender and receiver as discussed 160 in [RFC3448bis]. We note how RTP can accommodates these exchanges. 162 4.1. Data Packets 164 As stated in [RFC3448bis] a TFRC sender transmits the following 165 information in each data packet to the receiver: 167 o A sequence number, incremented by one for each data packet 168 transmitted. 170 o A timestamp indicating the packet send time and the sender's 171 current estimate of the round-trip time, RTT. This information 172 is then used by the receiver to compute the TFRC loss intervals. 173 - or - 174 A course-grained timestamp incrementing every quarter of a 175 round trip time, which is then used to determine the TFRC loss 176 intervals. 178 The standard RTP sequence number suffices for the functionality 179 provided by TFRC. A RTP header extension [hdrtxt] is used to 180 transmit the send timestamp and RTT. This extension is defined in 181 Section 5. 183 4.2. Feedback Packets 185 As stated in [RFC3448bis] a TFRC receiver provides the following 186 feedback to the sender at least once per RTT or per data packet 187 received (which ever time interval is larger): 189 o The send timestamp of the last data packet received, t_i. 191 o The amount of time elapsed between the receipt of the last 192 data packet at the receiver, and the generation of this feedback 193 report, t_delay. This is used by the sender for RTT computations. 195 o The rate at which the receiver estimates that data was received 196 since the last feedback report was sent, x_recv. 198 o The receiver's current estimate of the loss event rate, p, a real 199 value between 0 and 1.0. 201 To accommodate the feedback of these values a new AVPF transport 202 layer feedback message is defined, as detailed in Section 6. The 203 timing interval between the feedback packets is discussed in Section 204 7. 206 5. The Header Extension 208 The form of the extension block is depicted in Figure 1. The length 209 field for the extension takes the value 6 to indicate that the 210 payload is 7 bytes. Two header extension fields are defined and used 211 as follows: 213 Send timestamp (t_i): 32 bits 214 The timestamp indicating when the packet is sent. This timestamp 215 is measured in microseconds and is used for round trip time 216 calculations. 218 Round trip time (RTT): 24 bits 219 The round trip time as measured by the RTP TFRC sender in 220 microseconds. 222 0 1 2 3 223 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 224 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 225 | 0xBE | 0xDE | length=2 | 226 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 227 | ID | len=6 | RTT | 228 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 229 | send timestamp (t_i) | 230 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 231 Figure 1: RTP Sender Header Extension Block 233 6. TFRC-FB: A New AVPF Transport Layer Feedback Message 235 A new transport layer AVPF feedback message is defined to support 236 feedback from the receivers: TFRC-FB. Figure 2 depicts the both the 237 common packet format (the first 12 octets) and the feedback control 238 information (FCI) for the TFRC-FB packet. 240 We note that the TFRC related feedback, is specific to one media 241 stream sender, therefore all messages in the compound RTCP packet 242 MUST share the same media source SSRC. In the case where a sender is 243 sending multiple media streams to a receiver, each media flow will be 244 allocated its own AVPF feedback flow. 246 We define four FCI fields for the TFRC-FB message as follows: 248 Send timestamp (t_i): 32 bits 249 The send timestamp of the last data packet received by the 250 RTP TFRC receiver, t_i, in microseconds. 252 Delay (t_delay): 32 bits 253 The amount of time elapsed between the receipt of the last data 254 packet at the RTP TFRC receiver, and the generation of this 255 feedback report in microseconds. This is used by the RTP TFRC 256 sender for RTT computations. 258 Data rate (X_recv): 32 bits 259 The rate at which the receiver estimates that data was received 260 since the last feedback report was sent in bytes per second. X_recv 261 is computed per [RFC3448bis]. 263 Loss event rate (p): 32 bits 264 The receiver's current estimate of the loss event rate, p, 265 expressed as a fixed point number with the binary point at the 266 left edge of the field. (That is equivalent to taking the integer 267 part after multiplying the loss event rate by 2^32.) The value of 268 the loss event rate is computed per [RFC3448bis] Section 5. 270 0 1 2 3 271 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 272 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 273 |V=2|P| FMT=2 | PT=RTPFB | length | 274 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 275 | SSRC of packet sender | 276 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 277 | SSRC of media source | 278 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 279 | send timestamp (t_i) | 280 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 281 | delay (t_delay) | 282 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 283 | data rate at the receiver (x_recv) | 284 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 285 | loss event rate (p) | 286 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 287 Figure 2: The AVPF TFRC-FB RTCP Transport Layer Feedback Message 289 7. RTCP Transmission Intervals and Bandwidth Requirements 291 When using TFRC rate controlled RTP, the RTCP transmission intervals 292 must be set according to the requirements of the TFRC algorithm. TFRC 293 requires a receiver to generate a feedback ack packet at least once 294 per RTT or per packet received (based on the larger time interval). 295 These requirements are to ensure timely reaction to congestion. 297 The TFRC requirements of receiving feedback once per RTT can at times 298 conflict with the AVP RTCP bandwidth constraints, particularly at 299 small RTTs of 20 ms or less. Assuming only one TFRC-FB report per 300 RTCP compound packet, Table 1 lists the RTCP bandwidths at RTTs of 2, 301 5, 10 and 20 ms and the minimum corresponding RTP data rates, where 302 RTCP(X) <= (0.05)*RTP(X) is true. For example, according to Table 303 1, a TFRC RTP flow of less than 3.2 Mbps and a RTT of 5 ms, can not 304 comply with the 5% RTCP bandwidth constraints (Table 1 assumes each 305 RTCP packet is 100 bytes). RTP flows facing such circumstances 306 should take into account the additional RTCP bandwidth needed when 307 signaling their bandwidth information in SDP [RFC4566]. 309 Based on initial assumptions on round trip time if more than the 310 recommended 5% is needed for RTCP bandwidth, the applications SHOULD 311 use the SDP bandwidth modifiers RS and RR [RFC3556] to signal the 312 amount of RTCP bandwidth needed. If the round trip time assumptions 313 change after the RTP flows start running, the application MAY 314 recalculate the amount of RTCP bandwidth needed and re-signal this 315 new value using its signaling protocol of choice. 317 RTT RTCP(X) RTP(X) 318 +------------------------------+ 319 | 20 ms | 40 kbps | 0.8 Mbps | 320 | 10 ms | 80 kbps | 1.6 Mbps | 321 | 5 ms | 160 kbps | 3.2 Mbps | 322 | 2 ms | 400 kbps | 8.0 Mbps | 323 +------------------------------+ 324 Table 1: RTCP bandwidth for TFRC flows with corresponding 325 RTTs of 20, 10, 5 and 2 ms. Assuming, 100 byte RTCP packets 326 and one RTCP packet per RTT. 328 Additionally, to support the transmission of a feedback packet once per 329 RTT, the AVPF T_rr_interval variable MUST NOT be set to a value larger 330 than the current round trip time, RTT, as this would prevent generating 331 feedback packets at least once per RTT (see RFC 4585, Section 3.4,m). 333 8. SDP Usage 335 RTP flows using TFRC congestion control MUST signal their use of the 336 AVPF profile and RTCP feedback packets, the round trip time (RTT) and 337 send timestamp extension, and MAY also signal an initial RTCP 338 bandwidth usage: 340 v=0 341 o=alice 2890844526 2890844526 IN IP4 host.example.com 342 s=congestion control with TFRC 343 c=IN IP4 host.example.com 344 m=video 5400 RTP/AVPF 112 345 a=rtpmap:112 H261/90000 346 a=extmap:4 urn:ietf:params:rtp-hdtext:rtt-sendts 347 a=rtcp-fb * tfrc 348 b=AS:400 349 b=RS:800 350 b=RR:4000 352 8.1. Usage with the SDP Offer/Answer Model 354 TBC 356 9. IANA Considerations 358 In this section we detail IANA registry values that need to be 359 registered. Two new values must be reistered for the AVPF profile: 361 The new RTP/AVPF feedback packet, TFRC-FB. The following format 362 (FMT) values must be registerd in the FMT sub-registry of the RTPFB 363 payload type: 365 Value name: TFRC-FB 366 Long name: TFRC feedback 367 Value: 5 368 Reference: RFC XXXX 370 The new rtcp-fd-id "tfrc" must be registered with the "rtcp-fb" 371 attribute registry: 373 Value name: tfrc 374 Long name: TFRC Feedback 375 Reference: RFC XXXX 377 For the new header extension, the name rtt-sendts must be registered 378 into the rtp-hdrext section of the urn:ietf: namespace, referring to 379 RFC XXXX. 381 10. Security Considerations 383 This memo defines how to use the RTP AVPF profile and the general RTP 384 header extensions to support TFRC congestion control. Therefore RTP 385 packets using these mechanisms are subject to the security 386 considerations discussed in the RTP specification [RFC3550], the 387 RTP/AVPF profile specification [RFC4585] and the general header 388 extensions mechanism [hdrtxt]. Combining these mechanisms does not 389 pose any additional security implications. Applications requiring 390 authentication and integrity protection, or applictions operating in 391 environments that must strictly adhere to the TFRC send rate (and 392 fear manipulation of the feedback messsages) can use the SAVPF 393 [SAVPF] profile. 395 11. Acknowledgments 397 This memo is based upon work supported by the U.S. National Science 398 Foundation (NSF) under Grant No. 0334182. Any opinions, findings and 399 conclusions or recommendations expressed in this material are those 400 of the authors and do not necessarily reflect the views of NSF. 402 12. Author's Address 404 Ladan Gharai 406 Normative References 408 [RFC2119] S. Bradner, "Key words for use in RFCs to Indicate 409 Requirement Levels", Internet Engineering Task Force, 410 RFC 2119, March 1997. 412 [RFC3550] H. Schulzrinne, S. Casner, R. Frederick and V. Jacobson, 413 "RTP: A Transport Protocol for Real-Time Applications", 414 Internet Engineering Task Force, RFC 3550 (STD0064), July 415 2003. 417 [RFC3556] S. Casner, "Session Description Protocol (SDP) Bandwidth 418 Modifiers for RTP Control Protocol (RTCP) Bandwidth", RFC 419 3556, July 2003. 421 [RFC3711] M. Baugher, D. McGrew, M. Naslund, E. Carrara, K. Norrman, 422 "The Secure Real-time Transport Protocol", RFC 3711, March 423 2004. 425 [RFC4566] M. Handley, V. Jacobson and C. Perkins, "SDP: Session 426 Description Protocol", RFC 4566, July 2006. 428 [RFC4585] J. Ott, S. Wenger, A. Sato, C. Burmeister and J. Ray, 429 "Extended RTP Profile for RTCP-based Feedback (RTP/AVPF)", 430 RFC 4585, July 2006. 432 [RFC3448bis] M. Handley, S. Floyed, J. Padhye and J. widmer, 433 "TCP Friendly Rate Control (TRFC): Protocol Specification", 434 draft-ietf-dccp-rfc3448bis-01.txt, March 2007. 436 [hdrext] D. Singer, "A general mechanism for RTP Header Extensions", 437 IETF Work in Progress, draft-ietf-avt-rtp-hdrext-12.txt. 439 [SAVPF] J. Ott, E. Carrara, "Extended Secure RTP Profile for 440 RTCP-based Feedback (RTP/SAVPF)," IETF Work in Progress, 441 draft-ietf-avt-profile-savpf-10.txt. 443 Informative References 445 [RFC3711] M. Baugher, D. McGrew, M. Naslund, E. Carrara, K. Norrman, 446 "The Secure Real-time Transport Protocol", RFC 3711, March 447 2004. 449 [RFC4336] Floyd, S., Handley, M., and E. Kohler, "Problem Statement 450 for the Datagram Congestion Control Protocol (DCCP)", RFC 451 4336, March 2006. 453 [RFC4340] Kohler, E., Handley, M., and S. Floyd, "Datagram Congestion 454 Control Protocol (DCCP)", RFC 4340, March 2006. 456 [RFC4341] Floyd, S. and E. Kohler, "Profile for Datagram Congestion 457 Control Protocol (DCCP) Congestion Control ID 2: TCP-like 458 Congestion Control", RFC 4341, March 2006. 460 [RFC4342] Floyd, S., Kohler, E., and J. Padhye, "Profile for Datagram 461 Congestion Control Protocol (DCCP) Congestion Control ID 3: 462 TCP-Friendly Rate Control (TFRC)", RFC 4342, March 2006. 464 [RFCxRTP] C. Perkins, "RTP and the Datagram Congestion Control 465 Protocol (DCCP)", IETF Work in Progress, draft-ietf-dccp- 466 rtp-07.txt. 468 [ID.DTLS] T.Phelan, "Datagram Transport Layer Security (DTLS) 469 over the Datagram Congestion Control Protocol (DCCP)", IETF 470 Work in Progress, draft-ietf-dccp-dtls-00.txt. 472 13. IPR Notice 474 The IETF takes no position regarding the validity or scope of any 475 Intellectual Property Rights or other rights that might be claimed to 476 pertain to the implementation or use of the technology described in 477 this document or the extent to which any license under such rights 478 might or might not be available; nor does it represent that it has 479 made any independent effort to identify any such rights. Information 480 on the procedures with respect to rights in RFC documents can be 481 found in BCP 78 and BCP 79. 483 Copies of IPR disclosures made to the IETF Secretariat and any 484 assurances of licenses to be made available, or the result of an 485 attempt made to obtain a general license or permission for the use of 486 such proprietary rights by implementers or users of this 487 specification can be obtained from the IETF on-line IPR repository at 488 http://www.ietf.org/ipr. 490 The IETF invites any interested party to bring to its attention any 491 copyrights, patents or patent applications, or other proprietary 492 rights that may cover technology that may be required to implement 493 this standard. Please address the information to the IETF at ietf- 494 ipr@ietf.org. 496 14. Full Copyright Statement 498 Copyright (C) The IETF Trust (2007). 500 This document is subject to the rights, licenses and restrictions 501 contained in BCP 78, and except as set forth therein, the authors 502 retain all their rights. 504 This document and the information contained herein are provided on an 505 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 506 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 507 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 508 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 509 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 510 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.