Audio/Video Transport J. Lennox Internet-Draft Layered Media Expires: December 21, 2006 June 19, 2006 Marking and Selectively Retransmitting High-Priority Packets in the Real-Time Transport Protocol (RTP) draft-lennox-avt-recoverable-packets-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 December 21, 2006. Copyright Notice Copyright (C) The Internet Society (2006). Abstract In some circumstances, it is useful and desirable for the sender of an RTP stream to be able to deliver a subset of its RTP packets reliably. One example of this is a video codec which can encode a video stream such that decoder state can be maintained using just a subset of the packets encoded. However, existing RTP reliability mechanisms only define mechanisms which retransmit all the packets of an RTP stream. Lennox Expires December 21, 2006 [Page 1]
Internet-Draft Recoverable High-Priority RTP Packets June 2006 This document describes a mechanism by which the sender of an RTP stream can mark a subset of the packets of an RTP stream as high- priority recoverable packets, and by which the receiver of the stream can request retransmission of the high-priority packets. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 4. Use of R Packets With Video Streams . . . . . . . . . . . . . 4 5. RTP Header Extension to Indicate R Packets . . . . . . . . . . 5 6. RTCP Feedback Messages . . . . . . . . . . . . . . . . . . . . 8 7. Security Considerations . . . . . . . . . . . . . . . . . . . 9 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 9.1. Normative References . . . . . . . . . . . . . . . . . . . 10 9.2. Informative References . . . . . . . . . . . . . . . . . . 10 Appendix A. Requirements . . . . . . . . . . . . . . . . . . . . 11 Appendix B. Analysis of Alternate Approaches . . . . . . . . . . 12 B.1. Generic NACK . . . . . . . . . . . . . . . . . . . . . . . 12 B.2. Generic NACK with Codec knowledge . . . . . . . . . . . . 12 B.3. Codec-Specific NACK . . . . . . . . . . . . . . . . . . . 13 B.4. Multiple streams . . . . . . . . . . . . . . . . . . . . . 13 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 14 Intellectual Property and Copyright Statements . . . . . . . . . . 15 Lennox Expires December 21, 2006 [Page 2]
Internet-Draft Recoverable High-Priority RTP Packets June 2006 1. Introduction In many circumstances, it is useful to allow a subset of the packets in a Real-Time Transport Protocol (RTP) [RFC3550] media stream to be transmitted reliably (i.e. that they be retransmitted if they are lost). However, current mechanisms require either that any lost packet be retransmitted, or that none are. There is no way for the sender of an RTP stream to select some packets of a stream to be retransmittable. For example, modern flexible video codecs such as H.264 [ITU.H264.2005] allow video streams to be encoded flexibly. Unlike in earlier video codecs, inter-picture image prediction may be based not just on an immediately preceding picture, but optionally instead on earlier pictures transmitted in the video stream. As a result, it is possible for a video encoder to encode its stream such that in high packet loss situations, stream state can be maintained or re- established using only a fraction of the RTP packets transmitted in the stream. If a media stream experiences transient packet loss, a decoder can avoid reporting all lost packets, and an encoder does not need to retransmit all the missed packets, in order for the decoder to fully re-establish state. To achieve this desirable property, however, a decoder must be able to determine, based only on the packets it has received, whether a packet it has missed was one that it needed to receive reliably to reestablish stream state. This document describes a payload-format independent mechanism by which a receiver (or intermediate media- aware network entity) can quickly determine whether essential packets have been lost and can request their retransmission. The mechanism described by this document is also applicable to other application scenarios -- for example, DTMF [RFC2833] tones in an audio stream -- in which it is useful for some, but not all, of the packets in an RTP stream to be transmitted reliably. Appendix A lists the requirements for this protocol, and Appendix B evaluates some alternate approaches to the problem described. 2. Terminology In this document, the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as described in RFC 2119 [RFC2119] and indicate requirement levels for compliant implementations. Lennox Expires December 21, 2006 [Page 3]
Internet-Draft Recoverable High-Priority RTP Packets June 2006 3. Overview When sending a stream of RTP packets, a media sender may choose to mark a subset of the stream's packets as high-reliability packets. This subset of the RTP packets is named "R packets," for "recoverable" packets. Other packets are called "Non-R packets". An RTP stream can contain several independent series of R packets. (A given R packet can belong to only one series of R packets). Every R packet is identified with an R packet sequence number (RSeq), unique (modulo 2^16) within its series. R packets within a series are numbered in order, and a receiver detects missing R packets by noting gaps in the R packet sequence numbers. R packets sequence numbers are identified using an RTP header extension element, defined in Section 5. This header extension element is also used in non-R packets, to identify the RTP stream's most recently transmitted R packet in each series. Thus, receivers can detect missing R packets based on non-R packets as well as R packets. Since R packets can be sent at a fairly low rate relative to the overall packet sending rate of the RTP stream, this allows receivers to detect missing R packets much more quickly. If multiple series of R packets are being sent, R packet from one series can also identify the most recently sent R packets from the other active series. When a receiver detects that it has missed an R packet, it sends an R packet NACK message (RNACK), described in Section 6, using the RTCP feedback (AVPF) [I-D.ietf-avt-rtcp-feedback] mechanism. On receiving an RNACK message, the sender can then retransmit the missing packet. If a sender determines that some R packets, sent in the past, are no longer needed by the receiver, it can send a new R packet indicating that the earlier ones are no longer needed. This R packet is called a superseding R packet, as receipt of a superseding R packet indicates that earlier R packets need not be requested by a receiver. The first R packet of an RTP stream is always encoded such that it supersedes all the previous (non-existent) R packets in the stream. 4. Use of R Packets With Video Streams For several video formats, it is possible for a video encoder to encode and packetize its media so that a subset of the packets of an RTP [RFC3550] stream are sufficient for a stream decoder to fully reestablish the correct decoding state. In order to take advantage of R packets, an encoder periodically Lennox Expires December 21, 2006 [Page 4]
Internet-Draft Recoverable High-Priority RTP Packets June 2006 encodes a frame (or other unit of the media data) in a way that either depends on no previous data (an intra-encoded R frame) or that depends only on previously transmitted R packets (a P-encoded R frame). Frames transmitted in non-R packets can then reference the frames encoded in R packets. If transient packet loss occurs, a decoder need only request retransmission of the R packets it has missed in order to re-establish decoder state; missed non-R packets can be safely ignored. Missed R packets are useful (and necessary) for maintaining the continuity of the media stream. In some cases even if retransmissions of R packets arrive at the decoder too late to be played out, the decoder can "fast-forward" through a subset of the stream in order to catch up to the stream's current playout point. It is not necessary to receive every R packet ever transmitted on a media stream in order to reestablish the stream state. As mentioned, while some R packets (P frames) depend on previous data transmitted in a stream, others (intra frames) depend on no previous data and imply full stream state. Thus, the R packets carrying intra frames are encoded such that they supersede all the R packets prior to the first packet of the intra frame. Furthermore, when an encoder receives a report about a lost R packet, it is possible for it to decide to encode a fresh R frame (based only on R frames it believes have been received correctly) rather than retransmitting the lost packet. This frame's R packets are then marked as superseding the R packets of the frames which are no longer used for dependency tracking. In layered encodings, there can be more than one series of required packets, e.g. a base-layer I-frame eliminates the need for previous base-layer long-term reference frames, but not for enhancement-layer long-term reference frames. In this case, each layer's R frames are identified by a different R packet series. 5. RTP Header Extension to Indicate R Packets This section describes the RTP header extension element used to indicate R packets. In an RTP stream containing R packets, packets are marked with an RTP header extension element using the Named RTP Header Extension mechanism [I-D.ietf-avt-rtp-hdrext]. The R packet header extension element identifies both R packets themselves and previously-sent R packets. This header extension element has the name "org.ietf.avt.r-packet/200606". Every R packet Lennox Expires December 21, 2006 [Page 5]
Internet-Draft Recoverable High-Priority RTP Packets June 2006 includes, and every non-R packet SHOULD include, at least one header extension element of this form. It MAY occur multiple times in a header extension if multiple R packet series are in use, but MUST occur only once for any given series. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ID | len |R| MBZ | SER | RSEQ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SUPERSEDE_START [opt] | SUPERSEDE_END [opt] | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 1: R packet header extension element The structure of this header extension element is illustrated in Figure 1. Its fields are defined as follows: ID: 4 bits The local identifier negotiated for this header extension element, as defined in [I-D.ietf-avt-rtp-hdrext]. Length (len): 4 bits The length minus one of the data bytes of this header extension element, not counting the header byte (ID and len), as defined in [I-D.ietf-avt-rtp-hdrext]. This will have the value 6 if the second word (the superseded range) is present, and 2 if it is not. Its value MUST either be 2 or 6. R: 1 bit A bit indicating that the packet containing this header extension element is an R packet. If this bit is set (1), this header extension element identifies the current packet as an R packet in series SER with R sequence number RSEQ. If it is not set (0), this header extension element instead indicates that the media stream's most recent R packet in series SER had R sequence number RSEQ. (This latter case is known as a "mark element".) An R packet is a packet where exactly one header extension element has the R bit set, whereas a non-R packet is a packet where no header header extension element has the R bit set. If this bit is not set, the superseded range SHOULD NOT be present for that header extension element (i.e. the len field SHOULD be 2) and MUST be ignored if present. Reserved, Must Be Zero (MBZ): 3 bits Reserved bits. These MUST be set to zero on transmit and ignored on receive. Series ID (SER): 4 bits An identifier of which series of R packets is being described by this header extension element. If a media encoder is describing only a single series of R packets, this SHOULD have the value 0. Lennox Expires December 21, 2006 [Page 6]
Internet-Draft Recoverable High-Priority RTP Packets June 2006 R Packet Sequence Number (RSEQ): 16 bits An unsigned sequence number indicating the number of this R packet within the series SER. This value is incremented by 1 (modulo 2^16) for every R packet sent in a given series. RSEQ values for separate series are independent. Start of Superseded Range (SUPERSEDE_START): 16 bits The R sequence number of the earliest R packet, inclusive, superseded by this R packet, calculated modulo 2^16. (Since this value uses modulo arithmetic, the value RSEQ + 1 MAY be used for SUPERSEDE_START to indicate that all R packets prior to the end of the superseded range have been superseded.) This field is optional, and is only present when len=6. End of Superseded Range (SUPERSEDE_END): 16 bits The R sequence number of the final R packet, inclusive, superseded by this R packet, calculated modulo 2^16. This value MUST lie in the closed range [SUPERSEDE_START .. RSEQ] modulo 2^16. This field is optional, and is only present when len=6. An RTP packet MAY contain multiple R packet mark elements, so long as each of these elements has a different value for SER. However, an RTP MUST NOT contain more than one of these header extension elements with the R bit set, i.e. an R packet may not belong to more than one series. All RTP packets in a media stream using R packets SHOULD include a mark element for all active series. When the second word of this header extension element is present, it indicates that this R packet supersedes some previously-received R packets, meaning that these packets are no longer necessary in order to reconstruct stream state. This second word MUST only appear in a header extension element which has its R bit set. An R packet can only supersede R packets in the series identified by the element's SER field. R packets cannot supersede packets in other series. It is valid for a supersede element to have SUPERSEDE_END=RSEQ. This indicates that the R packet supersedes itself, i.e. that this R packet immediately becomes irrelevant to the stream state. The most common reason to do this would be to end a series; this can be done by sending an empty packet (e.g. an RTP No-op [I-D.ietf-avt-rtp-no-op] packet) with the superseded range (SUPERSEDE_START, SUPERSEDE_END) = (RSEQ+1, RSEQ), so that the series no longer contains any non-superseded packets. The first R packet sent in a series SHOULD be sent with a superseded range such that SUPERSEDE_START = RSEQ+1, to make it clear that no Lennox Expires December 21, 2006 [Page 7]
Internet-Draft Recoverable High-Priority RTP Packets June 2006 previous R packets are present in the range. R packets MAY redundantly include already-superseded packets in their range of packets to be superseded. If a group of superseding R packets are sent together (e.g., if a number of packets together encode an intra frame), they SHOULD all be marked as superseding the same range of R packets. 6. RTCP Feedback Messages This section describes the RTCP feedback message used to indicate that R packets have been lost. The R Packet Negative Acknowledgement (RNACK) Message is an RTCP Feedback (AVPF) [I-D.ietf-avt-rtcp-feedback] message identified by PT=RTPFB and FMT=4 (value tentatively chosen). The FCI field MUST contain at least one and MAY contain more than one RNACK. The RNACK packet is used to indicate the loss of one or more R packets. The lost packet(s) are identified by means of a packet sequence number, the series identifier, and a bit mask. The structure and semantics of the RNACK message are similar to that of the AVPF Generic NACK message. The RNACK Feedback Control Information (FCI) field has the following syntax Figure 2: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | RSEQ | SER | BLR | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 2: Feedback Control Information for R Packet Negative Acknowledgment (RNACK) R Packet Sequence Number (RSEQ): 16 bits The RSEQ field indicates a RSEQ value that the receiver has not received. Series ID (SER): 4 bits An identifier of which series of R packets is being described as being lost by this header extension element. Bitmask of following Lost R Packets (BLR): 12 bits The BLR allows for reporting losses of any of the 12 R Packets packets immediately following the RTP packet indicated by RSEQ. Denoting the BLP's least significant bit as bit 1, and its most significant bit as bit 12, then bit i of the bit mask is set to 1 if the receiver has not received R packet number (RSEQ+i) in the series SER (modulo Lennox Expires December 21, 2006 [Page 8]
Internet-Draft Recoverable High-Priority RTP Packets June 2006 2^16) and indicates this packet is lost; bit i is set to 0 otherwise. Note that the sender MUST NOT assume that a receiver has received an R packet because its bit mask was set to 0. For example, the least significant bit of the BLR would be set to 1 if the packet corresponding to RSEQ and the following R packet in the series had been lost. However, the sender cannot infer that packets RSEQ+2 through RSEQ+16 have been received simply because bits 2 through 15 of the BLR are 0; all the sender knows is that the receiver has not reported them as lost at this time. When a receiver detects that it has not received a non-superseded R packet, it sends an RNACK message as soon as possible, subject to the rules of RTCP feedback [I-D.ietf-avt-rtcp-feedback]. (In multipoint scenarios, this includes listening for RNACK packets from other receivers and not sending an RNACK for a lost R packet that has already been reported.) When a sender receives an RNACK packet, it checks whether the packet has been superseded. If it has not, it retransmits the packet for which an RNACK was sent (using, e.g., the RTP retransmission payload [I-D.ietf-avt-rtp-retransmission]). If the packet has been superseded, it retransmits the most recent packet whose R packet element indicated a superseded packet range including the packet requested. A sender MAY choose to generate and send a new R packet superseding the one requested in an RNACK, rather than retransmitting a packet that has been sent previously. If, after some period of time, a receiver has not received either a retransmission of the R packet for which an RNACK was sent, or an R packet superseding that packet, it SHOULD retransmit the RNACK message. A receiver MUST NOT send RNACK messages more often than permitted by AVPF. It SHOULD perform estimation of the round-trip time to the sender, if possible, and SHOULD NOT send RNACK messages more often than once per round-trip time. (If the receiver is also acting as an RTP sender, and the sender is sending RTCP reception reports for the receiver's stream, round-trip times can be inferred from the sender report's LSR and DLSR fields.) If the round-trip time is not available, receivers SHOULD NOT send RNACK messages more often than once per 100 milliseconds. [TODO: this value is a complete guess.] 7. Security Considerations All security considerations of RTP [RFC3550] apply here as well. Lennox Expires December 21, 2006 [Page 9]
Internet-Draft Recoverable High-Priority RTP Packets June 2006 A receiver MUST NOT assume that an R packet bitstream it receives actually provides complete decoder state; the bitstream MUST still be validated. 8. IANA Considerations This document defines an org.ietf RTP header extension element: 'org.ietf.r-packet/200606'. Its format is defined in Section 5 . This header extension element should be registered by IANA as described in [I-D.ietf-avt-rtp-hdrext]. This document defines an RTCP transport-layer feedback message: 'RNACK'. Its format is defined in Section 6. It should be defined in the RTPFB FMT as follows: Name: RNACK Long name: R Packet Negative Acknowledgment Value: 4 (tentatively chosen) Reference: RFC XXXX. 9. References 9.1. Normative References [I-D.ietf-avt-rtcp-feedback] Ott, J. and S. Wenger, "Extended RTP Profile for RTCP- based Feedback(RTP/AVPF)", draft-ietf-avt-rtcp-feedback-11 (work in progress), August 2004. [I-D.ietf-avt-rtp-hdrext] Singer, D., "A general mechanism for RTP Header Extensions", draft-ietf-avt-rtp-hdrext-03 (work in progress), June 2006. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, July 2003. 9.2. Informative References [I-D.ietf-avt-rtp-no-op] Andreasen, F., "A No-Op Payload Format for RTP", draft-ietf-avt-rtp-no-op-00 (work in progress), May 2005. Lennox Expires December 21, 2006 [Page 10]
Internet-Draft Recoverable High-Priority RTP Packets June 2006 [I-D.ietf-avt-rtp-retransmission] Rey, J., "RTP Retransmission Payload Format", draft-ietf-avt-rtp-retransmission-12 (work in progress), September 2005. [I-D.ietf-avt-ulp] Li, A., "RTP Payload Format for Generic Forward Error Correction", draft-ietf-avt-ulp-17 (work in progress), March 2006. [ITU.H264.2005] International Telecommunications Union, "Advanced video coding for generic audiovisual services", ITU- T Recommendation H.264 (2005), ISO Standard 14496-10:2005, March 2005. [RFC2833] Schulzrinne, H. and S. Petrack, "RTP Payload for DTMF Digits, Telephony Tones and Telephony Signals", RFC 2833, May 2000. [RFC3984] Wenger, S., Hannuksela, M., Stockhammer, T., Westerlund, M., and D. Singer, "RTP Payload Format for H.264 Video", RFC 3984, February 2005. Appendix A. Requirements This appendix describes the requirements motivating the design of the protocol described in the rest of this document. (This appendix is not normative; it thus does not use the formal upper-case versions of the RFC 2119 [RFC2119] terms for its requirements.) An encoder must be able to indicate a subset of the packets in a generated RTP stream as being high-priority (R) packets. A decoder must be able to determine when it has lost R packets, whenever any packet of the stream is received, and regardless of the dependency structure of the encoded stream. Similarly, a decoder must be able to determine that it has not lost any R packets as of the latest packet that has been received, regardless of how many other non-R packets have been lost. An encoder must be able to split a frame into any number of R packets, either in a codec-aware manner (e.g. H.264 [ITU.H264.2005] slices) or a codec-unaware manner (e.g. RFC 3984 [RFC3984] fragmentation units). Lennox Expires December 21, 2006 [Page 11]
Internet-Draft Recoverable High-Priority RTP Packets June 2006 An encoder must be able to state that an R packet supersedes previous R packets, i.e. that some previous R packets are no longer necessary in order to establish the stream state. This includes both being able to state that all R packets before a given one have been superseded, and that a range of R packets are superseded. It must be possible for an encoder to apply forward error correction [I-D.ietf-avt-ulp] to its media stream, either to all packets or selectively only to R packets, in a way that allows R packet state to be recovered from the FEC stream. An encoder must be able to describe multiple separate series of R packets, such that an R packet may supersede all previous R packets of one series without altering the need for other series. It must also be able to describe the most recent R packet of multiple series. Appendix B. Analysis of Alternate Approaches This appendix describes some alternate approaches that could be considered to provide a reliable substream of a media stream. It describes how they fail to satisfy the requirements listed in Appendix A. B.1. Generic NACK This approach uses the Generic NACK mechanism [I-D.ietf-avt-rtcp- feedback]. A receiver of a stream sends a Generic NACK for every RTP packet it misses. The stream sender then re-sends only those packets it knows are needed for the reliable subset of the stream. In addition to causing many more NACK messages to be sent than are necessary for the stream, this approach's primary difficulty is that there is no way for a receiver to know when it should stop sending NACK messages for those packets which it will not receive. B.2. Generic NACK with Codec knowledge This approach is like the previous one, except that decoders track codec-specific dependency state to infer whether a missed packet was an R packet or not, and they only send Generic NACK messages for the packets that they conclude were R packets. This conclusion is not in general possible, if a receiver misses both an R packet and a subsequent non-R packet directly dependent on it. Additionally, if an R frame is fragmented or sliced, a decoder can't determine which packets were part of the sliced or fragmented R frame. Lennox Expires December 21, 2006 [Page 12]
Internet-Draft Recoverable High-Priority RTP Packets June 2006 B.3. Codec-Specific NACK This approach is also like the previous one, except that decoders send codec-specific NACK messages (in RPSI messages) listing specific parts of frames that have been missed. It is not in general possible to tell whether a missed frame was an R packet, and the layering mechanisms don't support media-independent fragmentation (for example RFC 3984 [RFC3984] fragmentation units). B.4. Multiple streams In this approach, R packets are sent on a separate RTP session than the the non-R packets. RTP NACK messages are sent for packets on the R packet session only. This approach has the drawback that receipt of a non-R packet does not trigger a NACK request for a missed R packet; only the next R packet does that, unless the receiver has knowledge of the sender's timing of R packets and thus can pro-actively send a NACK for a packet it does not actually know it has missed. Since R packets tend to be spaced far apart, this can greatly delay stream recovery. Lennox Expires December 21, 2006 [Page 13]
Internet-Draft Recoverable High-Priority RTP Packets June 2006 Author's Address Jonathan Lennox Layered Media, Inc. 350 W. Passaic St Fourth Floor Rochelle Park, NJ 07662 US Email: jonathan at layeredmedia.com Lennox Expires December 21, 2006 [Page 14]
Internet-Draft Recoverable High-Priority RTP Packets June 2006 Intellectual Property Statement 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. Disclaimer of Validity 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 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. Copyright Statement Copyright (C) The Internet Society (2006). 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. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Lennox Expires December 21, 2006 [Page 15]