AVT O. Levin Internet-Draft Z. Vax Expires: April 30, 2009 Microsoft Corporation October 27, 2008 Extensions to RTCP Feedback Mechanism for Burst Streaming draft-levin-avt-rtcp-burst-00 Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on April 30, 2009. Abstract This document defines extensions to the "RTCP-Based Feedback" [RFC4585] to reduce synchronization time when an RTP receiver joins a multicast stream at a random point in time. Levin & Vax Expires April 30, 2009 [Page 1] Internet-Draft Extensions to RTCP for Burst Stream October 2008 Table of Contents 1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 3 4. Architectural Assumptions . . . . . . . . . . . . . . . . . . 4 5. Burst Mechanism Description . . . . . . . . . . . . . . . . . 6 6. Burst Mechanism Example Flow . . . . . . . . . . . . . . . . . 7 7. The RTCP Extensions: New Transport Layer Feedback Messages . . 9 7.1. Lack of Synch Indication (LSI) . . . . . . . . . . . . . . 9 7.1.1. Semantics . . . . . . . . . . . . . . . . . . . . . . 9 7.1.2. Format . . . . . . . . . . . . . . . . . . . . . . . . 9 7.2. Burst Bandwidth Indication (BBI) . . . . . . . . . . . . . 10 7.2.1. Semantics . . . . . . . . . . . . . . . . . . . . . . 10 7.2.2. Format . . . . . . . . . . . . . . . . . . . . . . . . 10 7.3. Synch Completed Indication (SCI) . . . . . . . . . . . . . 11 7.3.1. Semantics . . . . . . . . . . . . . . . . . . . . . . 11 7.3.2. Format . . . . . . . . . . . . . . . . . . . . . . . . 11 8. Establishing the Retransmission RTP Session with Burst using SDP . . . . . . . . . . . . . . . . . . . . . . . . . . 12 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 9.1. New Transport Layer Feedback Messages . . . . . . . . . . 12 9.2. New SDP attributes . . . . . . . . . . . . . . . . . . . . 12 10. Security Considerations . . . . . . . . . . . . . . . . . . . 12 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 12.1. Normative References . . . . . . . . . . . . . . . . . . . 13 12.2. Informational References . . . . . . . . . . . . . . . . . 14 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14 Intellectual Property and Copyright Statements . . . . . . . . . . 16 Levin & Vax Expires April 30, 2009 [Page 2] Internet-Draft Extensions to RTCP for Burst Stream October 2008 1. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in "Key words for use in RFCs to Indicate Requirement Levels " [RFC2119]. 2. Introduction Sections 4 and 5 of "Unicast-Based Rapid Synchronization with RTP Multicast Sessions" [I-D.versteeg-avt-rapid-synchronization-for-rtp] describe possible reasons for a synchronization delay while joining a multimedia stream in a random point in time. Over the years, different techniques have been developed in the industry in order to cope with these problems. Today, organizations such as DVB and ATIS are standardizing applications and topologies in the IPTV arena that require a smooth user experience while joining a multimedia multicast stream at a random point in time. We believe that the IETF needs to define a set of standard tools to be used by these and other applications, while deferring the application framework to other standardization bodies. We believe that the required tools can be built as extensions to existing RTP and RTCP mechanisms. Specifically, this document proposes extensions to "RTCP-Based Feedback" [RFC4585] to reduce synchronization time when an RTP receiver joins a multicast stream at a random point in time. The defined mechanism relies on the definitions and the mechanisms introduced in "RTP Retransmission Payload Format" [RFC4588] and "RTCP Extensions for Single-Source Multicast Sessions with Unicast Feedback" [I-D.ietf-avt-rtcpssm]. 3. Definitions The following terms are used in this document: Media Session: Media session as defined in "RTP: A Transport Protocol for Real-Time Applications" [RFC3550]. Original Stream: The one-to-many RTP stream of single source multicast (SSM) RTP packets to which an RTP receiver joins at a random point in time. Levin & Vax Expires April 30, 2009 [Page 3] Internet-Draft Extensions to RTCP for Burst Stream October 2008 Feedback Target: (Unicast RTCP) feedback target as defined in "RTCP Extensions for Single-Source Multicast Sessions with Unicast Feedback" [I-D.ietf-avt-rtcpssm]. Retransmission Packet: A "retransmission packet" as defined in "RTP Retransmission Payload Format" [RFC4588]. Burst Packet: An RTP packet constructed according to definitions of "RTP Retransmission Payload Format" [RFC4588] and generated upon a request from the receiver as defined in this document. Retransmission Stream: The stream of retransmission and burst packets associated with the original multicast stream and transmitted in a separate unicast RTP session in accordance with standard RTP rules. Burst Stream: The stream of burst packets associated with the original multicast stream and typically transmitted at an accelerated rate. A burst stream is a logical subset of a retransmission stream (i.e., transmitted in the same RTP session). Retransmission Source: The RTP/RTCP endpoint generating retransmission stream that can be triggered and controlled by mechanisms defined in "RTP Retransmission Payload Format" [RFC4588] and in this document. Media and Reference Information: Media and reference information is a media stream containing the media content and the metadata about it sufficient to reconstruct and use the content in the context of a specific application. The meaning, format, and the size of this information are specific to the application and are out of scope of this document. Nominal Original Bandwidth: The actual bitrate of the original multicast stream. The burst mechanism defined in this document assumes that the nominal bandwidth of the original multicast stream is lower than the maximum bandwidth that the receiver can accommodate for incoming traffic. Maximal Burst Bandwidth: The maximal bitrate for the unicast burst stream, which is also the maximum bitrate that the receiver can accommodate for incoming traffic. 4. Architectural Assumptions The burst mechanism defined in this document assumes that a receiver Levin & Vax Expires April 30, 2009 [Page 4] Internet-Draft Extensions to RTCP for Burst Stream October 2008 can accommodate an incoming media and reference information stream at a bandwidth higher than the nominal bandwidth of the original multicast stream. The burst mechanism defined in this document is performed on the transport layer, i.e., it is independent of the particular codec or application in use. The burst mechanisms defined in this document MUST support an architecture where the original multicast source, its feedback target, and the retransmission source are logical entities that are either collocated, or implemented by different physical entities in the network. The communications between these logical entities are out of scope for this document. The mechanism defined in this document builds on the existing IETF mechanisms as described in this section below: The retransmission source and the receiver both support "RTP Retransmission Payload Format" [RFC4588]. Specifically, they support the session multiplexing mode as required for the multicast case. The receiver learns about the addresses of the multicast source and the RTP session used for sending the retransmission stream by out-of- band means (e.g., SDP). A unicast RTCP session is signaled out-of-band and used for sending feedback messages to the original multicast stream in accordance with the concepts defined in "RTCP Extensions for Single-Source Multicast Sessions with Unicast Feedback" [I-D.ietf-avt-rtcpssm]. Specifically, this unicast session is used for sending NACK messages to trigger retransmission of the original packets over a separate unicast RTP session as defined in "RTP Retransmission Payload Format" [RFC4588]. The same unicast RTCP session between the receiver and the feedback target is used for sending the new RTCP feedback primitives as defined in this document to trigger and control the burst stream of packets. The same unicast retransmission RTP session is used to carry the burst stream of packets that are formatted according to "RTP Retransmission Payload Format" [RFC4588] from the retransmission source to the receiver. The retransmission stream carrying both burst and retransmission packets MUST comply with "RTP Retransmission Payload Format" [RFC4588]. Specifically, the sequence number has the standard RTP definition, i.e., it MUST be one higher than the sequence number of Levin & Vax Expires April 30, 2009 [Page 5] Internet-Draft Extensions to RTCP for Burst Stream October 2008 the preceding packet sent in the retransmission stream; the retransmission packet timestamp MUST be set to the original timestamp, i.e., to the timestamp of the original multicast packet. 5. Burst Mechanism Description The set of tools defined in this document is designed to facilitate a simple "burst mechanism" as described below: Before joining the original multicast media session, a new receiver learns about the addresses of the multicast source, its feedback target, and the RTP session used for sending retransmission packets by out-of-band means (e.g., SDP). The receiver indicates that it needs to receive media and reference information "as soon as possible" within the bandwidth limits (i.e., maximal burst bandwidth) known to the receiver by sending a new RTCP Feedback "Lack of Synchronization Indication" (LSI) to the feedback target. Upon receiving the indication, the feedback target calculates the actual burst rate based on the received value and its own local policy and sends a new RTCP Feedback "Burst Bandwidth Indication" (BBI) containing the expected bandwidth to the receiver. Then the retransmission source proceeds to stream the media and reference information of the indicated original stream using the retransmission packet format at an accelerated rate (i.e. at the rate indicated in the BBI, which is some rate higher than the nominal original bandwidth). Note that as a general rule, if the streaming rate needs to be adjusted according to the retransmission local policy, the feedback target first sends a new RTCP Feedback BBI containing the updated bandwidth and then the retransmission source proceeds to stream at the newly indicated bitrate. Once the information in the burst stream matches the information being streamed in the original stream (i.e. the burst stream "catches up" with the original multicast media session), the feedback target sends a new RTCP Feedback BBI and the retransmission source drops to the nominal original bandwidth or a lower rate, subject to local application policy. At any stage, the receiver can join the original multicast stream and ask to terminate the burst stream by sending a new RTCP Feedback "Synchronization Completed Indication" (SCI) to the feedback target. Levin & Vax Expires April 30, 2009 [Page 6] Internet-Draft Extensions to RTCP for Burst Stream October 2008 6. Burst Mechanism Example Flow Figures 1 and 2 below show an example of how a simple burst mechanism can be implemented using the extensions defined in this document. The flow can be tailored to various applications' needs and constraints, which are out of scope for this document. Figure 2 also illustrates how the burst stream can be followed by retransmission packets, and then the client can close both the retransmission and the original sessions by sending RTCP BYE packets to each. ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, , +-----------+ +--------------+ , , |Feedback | |Retransmission| , , |Target | |Source | , , +-----------+ +--------------+ , ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ^ * . | * . | * . | * v +---------+ +--------+ +--------+ +---------+ | | | | | |.....>| | |Multicast| | Router | | Router | |Receiver | |Source | | | | |******| | | |- - ->| |- - ->| |- - ->| | | | | | | |<=====| | +---------+ +--------+ +--------+ +---------+ Key: - - -> Multicast RTP ****** Unicast RTCP .....> Unicast RTP =====> IGMP Figure 1: Example of the Burst Mechanism Topology Levin & Vax Expires April 30, 2009 [Page 7] Internet-Draft Extensions to RTCP for Burst Stream October 2008 Multicast Feedback Retransmission Router Receiver Source Target Source | | | | | | RTP multicast original session (at nominal bitrate) | |==========================================>| | | | | | | | |RTCP Feedback LSI (maximal bitrate) | | |<-------------------------------------------| | | | | | | |RTCP Feedback BBI (actual bitrate) | | |------------------------------------------->| | | | | | | | RTP unicast burst (at actual bitrate)| | | |=================================>| | | | | | | |RTCP Feedback BBI (new bitrate) | | |------------------------------------------->| | | | | | | | |RTP unicast (at new bitrate) | | | |=================================>| | | | | | | | | | IGMP Join | | | | |<------------| | | | | | | RTP multicast original session (at nominal bitrate) | |==========================================>|============>| | | | | | | |RTCP Feedback SCI | | | |<-------------------------------------------| | | | | | | | |RTCP Feedback NACK | | | |<-------------------------------------------| | | | | | | | RTP unicast retransmission packet(s)| | | |=================================>| | | | | | | | |RTCP BYE | | | | |<---------------------------------| | | | | | | | |RTCP BYE | | | |<-------------------------------------------| | | | | | Figure 2: Example of the Use of the Burst Mechanism Levin & Vax Expires April 30, 2009 [Page 8] Internet-Draft Extensions to RTCP for Burst Stream October 2008 7. The RTCP Extensions: New Transport Layer Feedback Messages 7.1. Lack of Synch Indication (LSI) The LSI FB message is identified by PT=RTPFB and FMT=2. There MUST be exactly one LSI contained in the FCI field. 7.1.1. Semantics With the Lack of Sync Indication, a receiver can inform a feedback target that it will be joining the original multicast media session and therefore it needs to receive media and reference information over the retransmission RTP session at an accelerated rate. The LSI includes a Bitrate value which identifies the maximum bitrate that the receiver will accommodate for the incoming unicast burst stream. 7.1.2. Format The Lack of Synch Indication uses additional FCI fields, the contents of which are depicted in Figure 3. The length of the FB message MUST be set to 3+n, with n being the number of 32-bit words comprising the "Extensions" contained in the LSI field. If the "Extensions" does not fall on a 32-bit boundary, then the last word MUST be padded to the boundary using further bits set to 0. 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Bitrate | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Extensions | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 3: Syntax of the Lack of Synch Indication (LSI) Bitrate: 32 bits - Bitrate indicated by the receiver in bits per second - this is the maximum bitrate of RTP stream it can accommodate. Levin & Vax Expires April 30, 2009 [Page 9] Internet-Draft Extensions to RTCP for Burst Stream October 2008 Extensions: Optional extended parameters encoded using Type/Length/ Value (TLV) elements as described below: Type: A single-octet identifier that defines the type of the parameter represented in this TLV element. Length: A two-octet field that indicates the length of the Value field. Value: Variable sized set of octets that contains the specific value for the parameter. 7.2. Burst Bandwidth Indication (BBI) The BBI FB message is identified by PT=RTPFB and FMT=3. There MUST be exactly one BBI contained in the FCI field. 7.2.1. Semantics When the streaming rate needs to be changed due to a target feedback local policy, the target feedback first sends BBI message containing an updated bandwidth and then the retransmission source proceeds with the streaming accordingly. 7.2.2. Format The Burst Bandwidth Indication uses additional FCI fields, the content of which are depicted in Figure 4. The length of the FB message MUST be set to 3+n, with n being the number of 32-bit words comprising the "Extensions" contained in the BBI field. If the "Extensions" does not fall on a 32-bit boundary, then the last word MUST be padded to the boundary using further bits set to 0. 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Bitrate | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Extensions | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 4: Syntax of the Burst Bandwidth Indication (BBI) Levin & Vax Expires April 30, 2009 [Page 10] Internet-Draft Extensions to RTCP for Burst Stream October 2008 Bitrate: 32 bits - Bitrate indicated by the sender in bits per second - this is the actual bitrate of the RTP stream that follows. Extensions: Optional extended parameters encoded using Type/Length/ Value (TLV) elements as described below: Type: A single-octet identifier that defines the type of the parameter represented in this TLV element. Length: A two-octet field that indicates the length of the Value field. Value: Variable sized set of octets that contains the specific value for the parameter. 7.3. Synch Completed Indication (SCI) The SCI FB message is identified by PT=RTPFB and FMT=4. There MUST be exactly one SCI contained in the FCI field. 7.3.1. Semantics The receiver sends this indication to the feedback target to indicate that the burst stream can be terminated. 7.3.2. Format The Synch Completed Indication uses additional FCI fields, the content of which are depicted in Figure 5. The length of the FB message MUST be set to 2+n, with n being the number of 32-bit words comprising the "Extensions" contained in the SCI field. If the "Extensions" does not fall on a 32-bit boundary, then the last word MUST be padded to the boundary using further bits set to 0. 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Extensions | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 5: Syntax of the Synch Completed Indication (SCI) Levin & Vax Expires April 30, 2009 [Page 11] Internet-Draft Extensions to RTCP for Burst Stream October 2008 Extensions: Optional extended parameters encoded using Type/Length/ Value (TLV) elements as described below: Type: A single-octet identifier that defines the type of the parameter represented in this TLV element. Length: A two-octet field that indicates the length of the Value field. Value: Variable sized set of octets that contains the specific value for the parameter. 8. Establishing the Retransmission RTP Session with Burst using SDP This section will specify one of the possible ways to use an "out-of- band" signaling to establish the retransmission RTP Session with burst as defined in this document. One method is to use the SDP definitions introduced in "RTP Retransmission Payload Format" [RFC4588] and "RTCP Extensions for Single-Source Multicast Sessions with Unicast Feedback" [I-D.ietf-avt-rtcpssm], and new SDP attributes (if needed) for the burst mechanism defined in this document. 9. IANA Considerations 9.1. New Transport Layer Feedback Messages Three new RTCP Transport Layer Feedback Messages will be registered through this document: "Lack of Synch Indication" (LSI), "Burst Bandwidth Indication" (BBI), and "Synch Completed Indication" (SCI). 9.2. New SDP attributes New SDP attributes will be registered through this document (if needed) for the "out-of-band" signaling specific to the mechanism defined in this document. 10. Security Considerations Security considerations presented in "Why RTP Does Not Mandate a Single Security Mechanism" [I-D.ietf-avt-srtp-not-mandatory] apply to the mechanism defined in this document. Levin & Vax Expires April 30, 2009 [Page 12] Internet-Draft Extensions to RTCP for Burst Stream October 2008 The new protocols' extensions don't introduce security considerations beyond those presented in "RTP: A Transport Protocol for Real-Time Applications" [RFC3550], "RTCP-Based Feedback" [RFC4585] and "RTCP Extensions for Single-Source Multicast Sessions with Unicast Feedback" [I-D.ietf-avt-rtcpssm]. The normal RTP security mechanism (defined in Section 9 of "RTP: A Transport Protocol for Real-Time Applications" [RFC3550]) and "Extended Secure RTP Profile for RTCP-Based Feedback" [RFC5124] apply to the extensions defined in this document. 11. Acknowledgements The authors would like to thank Majd Bakar and Guy Hirson for their contribution to this document. 12. References 12.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2327] Handley, M. and V. Jacobson, "SDP: Session Description Protocol", RFC 2327, April 1998. [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, July 2003. [RFC3556] Casner, S., "Session Description Protocol (SDP) Bandwidth Modifiers for RTP Control Protocol (RTCP) Bandwidth", RFC 3556, July 2003. [RFC4585] Ott, J., Wenger, S., Sato, N., Burmeister, C., and J. Rey, "Extended RTP Profile for Real-time Transport Control Protocol (RTCP)-Based Feedback (RTP/AVPF)", RFC 4585, July 2006. [RFC4588] Rey, J., Leon, D., Miyazaki, A., Varsa, V., and R. Hakenberg, "RTP Retransmission Payload Format", RFC 4588, July 2006. [I-D.ietf-avt-rtcpssm] Ott, J., "RTCP Extensions for Single-Source Multicast Sessions with Unicast Feedback", draft-ietf-avt-rtcpssm-17 Levin & Vax Expires April 30, 2009 [Page 13] Internet-Draft Extensions to RTCP for Burst Stream October 2008 (work in progress), January 2008. 12.2. Informational References [RFC3611] Friedman, T., Caceres, R., and A. Clark, "RTP Control Protocol Extended Reports (RTCP XR)", RFC 3611, November 2003. [RFC5124] Ott, J. and E. Carrara, "Extended Secure RTP Profile for Real-time Transport Control Protocol (RTCP)-Based Feedback (RTP/SAVPF)", RFC 5124, February 2008. [I-D.versteeg-avt-rapid-synchronization-for-rtp] Steeg, B., Begen, A., and T. Caenegem, "Unicast-Based Rapid Synchronization with RTP Multicast Sessions", draft-versteeg-avt-rapid-synchronization-for-rtp-00 (work in progress), July 2008. [I-D.ietf-avt-rtcp-guidelines] Ott, J. and C. Perkins, "Guidelines for Extending the RTP Control Protocol (RTCP)", draft-ietf-avt-rtcp-guidelines-00 (work in progress), July 2008. [I-D.ietf-avt-srtp-not-mandatory] Perkins, C. and M. Westerlund, "Why RTP Does Not Mandate a Single Security Mechanism", draft-ietf-avt-srtp-not-mandatory-00 (work in progress), July 2008. Authors' Addresses Orit Levin Microsoft Corporation One Microsoft Way Redmond, WA 98052 USA Phone: +1 425-722-2225 Email: oritl@microsoft.com Levin & Vax Expires April 30, 2009 [Page 14] Internet-Draft Extensions to RTCP for Burst Stream October 2008 Zeev Vax Microsoft Corporation 1065 La Avenida St Mountain View, CA 94043 USA Phone: +1 650-693-2353 Email: zeevvax@microsoft.com Levin & Vax Expires April 30, 2009 [Page 15] Internet-Draft Extensions to RTCP for Burst Stream October 2008 Full Copyright Statement Copyright (C) The IETF Trust (2008). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Levin & Vax Expires April 30, 2009 [Page 16]