Audio/Video Transport (avt) T. Taylor (Ed.) Internet-Draft P. Boudreaux Expires: November 2, 2006 C. Chu R. Rabipour Nortel May 2006 Time Alignment Using RTCP Feedback draft-taylor-avt-time-align-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 November 2, 2006. Copyright Notice Copyright (C) The Internet Society (2006). Abstract This memo describes the use of RTCP-based feedback to reduce end-to- end delay through the use of time alignment between the source and receiver. Time alignment is useful, for example, in certain gateway-to-gateway scenarios and certain gateway-to-VoIP-terminal scenarios. It is the Taylor (Ed.), et al. Expires November 2, 2006 [Page 1] Internet-Draft Time Alignment Using RTCP Feedback May 2006 ability for a receiver to request that the sender shift the time reference for packetization by a specified amount. When a receiver with strict packet timing limitations, e.g., due to a 3G UMTS Iu interface, is connected to an sender at a peer endpoint capable of responding to time alignment requests, e.g., with an AMR encoder associated with a PCM interface to the PSTN, this allows the endpoints to reduce delay in the speech path by as much as the 20 ms frame-block duration, depending on the degree of misalignment in the time reference. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 1.2. Requirements and Applicability . . . . . . . . . . . . . . 3 2. Use of RTCP Feedback . . . . . . . . . . . . . . . . . . . . . 8 2.1. Signalling Considerations . . . . . . . . . . . . . . . . 8 2.2. Time Alignment Feedback Message Syntax . . . . . . . . . . 8 2.3. Time Alignment Behaviour . . . . . . . . . . . . . . . . . 10 2.3.1. Sender Behaviour . . . . . . . . . . . . . . . . . . . 10 2.3.2. Receiver Behaviour . . . . . . . . . . . . . . . . . . 11 3. Security Considerations . . . . . . . . . . . . . . . . . . . 13 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 6.1. Normative References . . . . . . . . . . . . . . . . . . . 16 6.2. Informative References . . . . . . . . . . . . . . . . . . 16 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17 Intellectual Property and Copyright Statements . . . . . . . . . . 18 Taylor (Ed.), et al. Expires November 2, 2006 [Page 2] Internet-Draft Time Alignment Using RTCP Feedback May 2006 1. Introduction 1.1. 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 [1]. In this document, "sender" and "receiver" always refer to the sender and receiver of the packetized media flow. RTCP feedback messages always pass in the reverse direction, from the receiver to the sender. 1.2. Requirements and Applicability Consider a situation where RTP packets are sent to a receiving gateway (or possibly an user device) that is able to process these packets only at a series of fixed instants in time. To simplify subsequent discussion, let us call these the "acceptance times", and the period between them (assumed to be constant) the "inter- acceptance period". Of course, in steady state the inter-acceptance period will equal the packetization period at the sender. Now if a packet arrives just after an acceptance time, it will have to wait for almost the entire length of the inter-acceptance period before it can be processed. If, on the other hand, it arrives just before an acceptance time, it will wait very little until it can be processed. Suppose that the sender of these packets is able to adjust the time at which it sends them. Suppose further that the receiver can ask the sender to make such an adjustment, so that packets arrive at the receiver as close to their acceptance times as possible. Then the end-to-end delay entailed in delivery of the media flow will be reduced compared with the situation where no adjustments are possible. Averaged over a number of sessions, the reduction will amount to half of an inter-acceptance period. For sessions at the extreme, it will equal almost a whole inter-acceptance period. For VoIP applications in particular, especially for wireless, this reduction in end-to-end delay is significant. This argument continues to hold even taking into account the effect of jitter in real-life IP networks. The difference is that a packet arriving at the receiver will on the average wait for at least the duration of the jitter buffer before being accepted. If the sender and receiver are not time-aligned, the packet will wait longer, until the next acceptance time. This is illustrated in Figure 1. In this figure, the horizontal axis shows successive acceptance times at the receiver. The vertical axis shows successive packet generation times at the sender. The line shows the trajectory of a given packet Taylor (Ed.), et al. Expires November 2, 2006 [Page 3] Internet-Draft Time Alignment Using RTCP Feedback May 2006 through time. Here TO is the time it is sent, TA is the expected time of arrival, and TB is the expected time for it to pass through the jitter buffer. However, because of misalignment, it is not actually accepted until TC. The amount TC-TB is the measure of schedule misalignment between the sender and the receiver. | Sender's + packet | schedule | | | + | \ |Intended | | | \ |jitter | | | \ |buffer | ---- Misalignment | \ |delay | / | + \ |<------->|<->| | \| | | | |\ | | | | \ | | | | \ | | Receiver's + | \ | | packet | | \| | schedule --------+-----|---+-----|---+---------+ TO TA TB TC Figure 1: Increase in end-to-end delay due to schedule misalignment More formally, the time any individual packet waits at the receiver before being accepted is given by: (1) Total wait = Rand + Intended jitter buffer delay + Misalignment In this expression, Rand is a random jitter amount, positive or negative depending on whether the packet arrives early or late, but with average value zero. Rearranging (1) and averaging, we arrive at an estimate (2) for the amount of misalignment between the sender and the receiver. One statistical rule of thumb suggests that to obtain a reasonably accurate estimate from (2) requires an average using the observed total wait times for about thirty packets. (2) Misalignment (estimated) = average (Total wait - Intended jitter buffer duration) Taylor (Ed.), et al. Expires November 2, 2006 [Page 4] Internet-Draft Time Alignment Using RTCP Feedback May 2006 Since Misalignment in the above expression is the average extra time a packet has to wait beyond what was intended in setting the jitter buffer, it would be eliminated if the sender shifted its schedule to release its packets later by that amount. This is illustrated in Figure 2. The old time trajectory is shown by dots, parallel to the new one. Times TO', TA', and TB' are all increased relative to TO, TA, and TB, by the amount of the adjustment. The result of the adjustment is to make TB', the expected time of exit from the jitter buffer, exactly equal to TC, the time the packet is accepted. | Sender's x packet | schedule | (x is old, + is new) + | \ x \ | . \ | Intended | | . \ | jitter | + . \ | buffer | | . \ | delay | x . \ |<-------->| | . \ | | . | \ | + . \ | | | . \ | Receiver's x | . \ | packet | | . \| schedule --------+--------|+---------+---------+ TO' TA' TB' = TC Figure 2: Elimination of misalignment by schedule delay Figure 2 showed alignment through a shift in packet scheduling at the sender achieved by a delay in packet transmission. Assuming that the sender maintains the packet size (i.e., the time period covered by a single packet), this means that the sender actually discards a portion of the media flow while it is forming the first packet of the new schedule. For the receiving user, this may be perceptible as a one-time impairment. As an alternative to requesting a schedule delay, the receiver could ask that the sending of packets be advanced, so that they are received in time to be processed one acceptance time earlier than they would be without the adjustment. This is illustrated in Figure 3. A packet that would have been sent at time TO in the Taylor (Ed.), et al. Expires November 2, 2006 [Page 5] Internet-Draft Time Alignment Using RTCP Feedback May 2006 unadjusted schedule is now sent at TO". It is expected to arrive at TA", pass through the jitter buffer at TB", and immediately be accepted. Note that the new acceptance time is TC", which is one acceptance time earlier than the unadjusted TC. | Sender's x packet | schedule + (x = old, + = new) | | x | . |Intended| + . | jitter | |\ . | buffer | | \ . delay | x \ |<.----->| | \ | . | + \ . | | | \ .| | | \ |. Receiver's x | \ | . packet | | \| . schedule --------+|--------+---------+---------+ TO" TA" TB" = TC" TC Figure 3: Elimination of misalignment by schedule advancement Advancing the packet schedule may also cause a perceived impairment for the receiving user, since to maintain a constant packet size the sender will have to pad the first packet of the new schedule. As a pragmatic matter, it is best to leave the decision whether to ask for a one-time delay or a one-time advancement in packet scheduling to the individual implementation. This memo assumes a convention that a positive adjustment value requests a delay, while a negative one requests that transmission be scheduled earlier. Following that convention, the value of the required adjustment using schedule advancement is given by: (3) Adjustment for schedule advancement = Estimated misalignment - Inter-acceptance period where "Estimated misalignment" is given by (2) above. Note that time alignment is an optimization that reduces delay by adjusting the sender's packet transmission phase so that the packet Taylor (Ed.), et al. Expires November 2, 2006 [Page 6] Internet-Draft Time Alignment Using RTCP Feedback May 2006 arrives just in time for consumption. When the delay statistics change substantially during a call because of: o a change in sender or receiver scheduling, perhaps due to mobile handoff, or o a change in the intended jitter buffer delay then delay optimization will benefit from re-invocation of time alignment. However, to avoid excessively repeated requests for time alignment it is recommended to issue a new time alignment request only after the delay/jitter statistics for the flow have stabilized. In environments where the delay or jitter continuously varies, the usefulness of time alignment is significantly reduced. In this case the receiver will be out of alignment most of the time, and sent requests may become dated even before the media sender has managed to implement them. The time alignment procedure should include a means for detecting this condition, to minimize the both the amount of transmission impairment and the consumption of processing and network resources due to the use of the time alignment procedure when this procedure will be ineffective. This memo proposes an adjustment signalling mechanism based on RTCP feedback [6]. Because RTCP is typically transported unreliably, individual feedback messages requesting time alignment may be lost. Thus the receiver will have a need to repeat a request if it determines that its previous attempt had no effect. However, the previous paragraph pointed out that an additional adjustment may be needed during the course of a call. This raises the possibility that upon rare occasion the sender needs to distinguish between a repetition of an earlier time alignment request that it has already received and a new time alignment request. The mechanism must therefore provide some means whereby different requests can be distinguished. As a final point, this discussion clearly applies only to the case of point-to-point packet streams. Attempts to regulate a multicast stream would enmesh the sender in a tangle of conflicting adjustment requests from different receivers. If a sender determines that it is involved in such a situation, the time alignment procedures should allow it to ignore time alignment requests. Taylor (Ed.), et al. Expires November 2, 2006 [Page 7] Internet-Draft Time Alignment Using RTCP Feedback May 2006 2. Use of RTCP Feedback The time alignment process described in the preceding section postulated a means whereby the receiver could indicate the amount of a desired adjustment, positive or negative, to be applied to packet scheduling at the sender. This memo proposes the use of the RTCP feedback mechanism described in [6] to meet that requirement. The use of this mechanism requires the definition of a new feedback message format and a definition of the behaviour associated with such reports. 2.1. Signalling Considerations The mechanism defined in this memo is designed so that the receiver can try to use it even if the sender does not support time alignment. Of course, in that case the attempts will fail, but the mechanism is designed for this possibility to cover the case where the sender and receiver do not signal their capabilities to each other in advance of the media connection. Where the Session Description Protocol (SDP) [5] is used to establish the session description in advance of the media flow, the receiver MUST follow the procedures specified in section 4.2 of [6]. In support of those procedures, this document extends the syntax of the "rtcp-fb" attribute using the notation of section 3.3 of [4]: rtcp-fb-val =/ "taln" This conforms to the general syntax defined in section 4.2 of [6] with 'rtcp-fb-id' set equal to "taln" and 'rtcp-fb-param' made empty. 2.2. Time Alignment Feedback Message Syntax This section defines a new RTCP feedback message type based on section 6 of [6]. Time alignment is in principle a codec-independent procedure. Thus this memo defines a transport layer feedback message. Figure 4 below, which is based on Figure 3 of [6], shows the packet format for this message. Taylor (Ed.), et al. Expires November 2, 2006 [Page 8] Internet-Draft Time Alignment Using RTCP Feedback May 2006 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |V=2|P| FMT=2 | PT = 205 | length = 3 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SSRC of packet sender (note) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SSRC of media source | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Time Alignment Feedback Control Information (FCI) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Note: This is the SSRC of the "receiver" as the term is used in this document. Figure 4: Packet Format for Time Alignment Feedback Messages Since this memo defines a transport layer feedback message, the payload type (PT) field in the common RTCP header as shown in Figure 4 MUST have the value 205 (RTPFB). This memo assigns the value 2 to the FMT field, designating a Time Alignment feedback message. The length field MUST have value 3, designating a total of four 32-bit words. This provides for a single instance of the Time Alignment Feedback Control Information, the format of which is shown in Figure 5. This message does not contain padding, so the P field MUST have value 0. The remaining header fields are as described in [6]. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |S| sequence | reserved | amag (ms) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 5: Format of the Time Alignment Feedback Control Information (FCI) In Figure 5, S is the sign bit. If S is 0, the receiver is requesting a one-time delay in packet scheduling at the sender. If S is 1, the receiver is requesting a one-time advance in packet scheduling. The 'sequence' field allows the sender to distinguish between different Time Alignment requests, as described below. The bits marked "reserved" in the Time Alignment FCI MUST be set to 0 by the requesting entity (i.e., the receiver), and MUST be ignored by the to which the request is directed (i.e., the sender). Finally, the amag field in the Time Alignment FCI is a binary integer between 0 and 255 indicating the magnitude of the desired scheduling adjustment, in 500 microsecond (0.5 millisecond) increments. Taylor (Ed.), et al. Expires November 2, 2006 [Page 9] Internet-Draft Time Alignment Using RTCP Feedback May 2006 2.3. Time Alignment Behaviour 2.3.1. Sender Behaviour This subsection assumes that the sender is able and willing to act upon Time Alignment feedback messages. If it is not, it ignores them, as specified in section 6.1 of [2] and section 4.2 of [6]. The sender MUST save the value of the sequence number of the last Time Alignment feedback message it acted on. If a given Time Alignment feedback message is the first that the sender has received for a given media flow, the sender delays or advances its packetization schedule as requested, to the extent possible. If a subsequent message is received, the sender MUST first check the value of the sequence number of the new message. The sender MUST ignore the message if the sequence number of that message is less than or equal to the saved sequence number value. For saved sequence number values near the upper limit of the range of the sequence number field, the sender MUST apply wrap-around logic in making this decision. As indicated in Section 1.2, a delay in packetization implies that some media content must be discarded before the initial packet of the new schedule is generated. The RTP timestamps of that initial packet of the new schedule and its successors MUST reflect the time at which they should be played out relative to the preceding packets in the same media flow. For example, if a delay of 2 ms is requested and acted upon by waiting 2 ms before starting to fill the initial packet of the new schedule, the timestamp of that initial packet will be larger than it would have been without the time adjustment by the equivalent of 2 ms. At a timestamp rate of 8000 per second, for instance, the timestamp of the initial packet and its successors is greater by 16 than it would have been in the absence of the adjustment. An advance in scheduling implies that the sender may have to add some redundant (interpolated) content to the first packet sent according to the new schedule to fill out the packet, depending on the specific codec involved. This document does not specify whether the interpolated content is added at the beginning or end of the packet, but the timestamp of the initial and succeeding packets in either case MUST reflect the time adjustment. Codec-specific considerations may govern the decision on when the sender makes the schedule change. For instance, the codec may involve natural boundaries after which material may be added or Taylor (Ed.), et al. Expires November 2, 2006 [Page 10] Internet-Draft Time Alignment Using RTCP Feedback May 2006 dropped as required. Codec-specific considerations may also require adjustment of time related values within the payload. 2.3.2. Receiver Behaviour Time Alignment feedback message sequence numbers MUST begin at 0 for the first message of a media flow, incrementing by 1 for subsequent adjustment requests. If the sequence number reaches the maximum value of its range, the number sequence MUST be continued by starting at 0 again. The receiver MAY send an initial Time Alignment feedback message as soon as it has formed a stable estimate of the value of Misalignment as defined in Section 1.2 for the media flow, or it MAY wait to incorporate the message in a compound RTCP packet at the regularly scheduled time. After the initial Time Alignment feedback message has been sent, the interval between consecutive Time Alignment feedback messages MUST NOT be less than one second. In any case, the receiver MUST comply with the rules for scheduling of RTCP feedback messages as described in [6]. When the receiver has sent a Time Alignment feedback message, it SHOULD monitor for a packet scheduling change indicating that the sender has acted on its request. If the receiver concludes that the request was not honoured, possibly due to loss of the RTCP packet, it MAY reissue the request. In this case, it MUST use the same sequence number value as the original request. The receiver MUST NOT generate more than three instances of a given request, since it is unlikely under the stated timing rules that all three instances were lost in transmission. The receiver MAY continue to form new estimates of Misalignment throughout the RTP session. Before further requests for time alignment are issued, the estimate of Misalignment SHOULD pass two tests. The first is whether the estimate is stable. This can be tested by determining whether the difference between two estimates of Misalignment based on independent samples is statistically insignificant. If this test is passed, the second test is whether the observed estimates are due to random effects only, or represent true a true misalignment. This may be tested by determining whether the difference between the estimate of Misalignment and zero is statistically significant. If both these tests are passed, the receiver MAY issue a new request based on an estimate of Misalignment based on the combined sample. For a new request generated according to these rules, the receiver MUST use an incremented value of the sequence number as described above. Taylor (Ed.), et al. Expires November 2, 2006 [Page 11] Internet-Draft Time Alignment Using RTCP Feedback May 2006 One possible measure of a statistically significant difference in the above paragraph may be the latest estimate of packet jitter multiplied by a suitable constant which itself is based on the sample size used for each estimate of Misalignment. [The necessary statistical calculations to implement this may be added as an appendix in a later version of this document if this is seen as desirable. It may make more sense to use the sample standard deviation.] Taylor (Ed.), et al. Expires November 2, 2006 [Page 12] Internet-Draft Time Alignment Using RTCP Feedback May 2006 3. Security Considerations The protocol around Time Alignment feedback messages introduces no new security threats not already presented by RTCP messages in general. However, the Time Alignment procedure at the semantic level introduces an opportunity for an attacker to degrade the quality of a media flow. The lesser threat is that the attacker injects a series of Time Alignment feedback messages into the RTCP stream, each causing a momentary impairment in the media flow by requesting a scheduling delay. The greater threat is that either through message injection or modification of genuine messages the attacker causes the end-to-end delay to increase rather than decrease. These threats introduce a requirement for message authentication and integrity protection of the Time Alignment feedback messages. For this reason, applications using the Time Alignment procedure SHOULD use SRTP [3] for protection of the RTCP stream. Note that the method of key exchange for SRTP is still an open question, and may vary with the specific application. In some cases a method of protection other than SRTP may be more appropriate. Taylor (Ed.), et al. Expires November 2, 2006 [Page 13] Internet-Draft Time Alignment Using RTCP Feedback May 2006 4. IANA Considerations This document registers an additional value "taln" as defined in this document, for the attribute "rtcp-fb" as defined in [6]: Value name: taln Long name: Time alignment. Reference: RFC XXXX. The value "taln" has no additional arguments. This document further registers the following format (FMT) value within the subregistry corresponding to the RTCP control packet type "RTPFB": Name: Taln Long name: Time Alignment. Value: 2 Reference: RFC XXXX. The Time Alignment format value requires that the packet contain a single instance of the Time Alignment Feedback Control Information as described in Section 2.2 of RFC XXXX. NOTE TO THE RFC EDITOR: Please replace all occurrences of RFC XXXX by the RFC number assigned to this document. Taylor (Ed.), et al. Expires November 2, 2006 [Page 14] Internet-Draft Time Alignment Using RTCP Feedback May 2006 5. Acknowledgements Richard Ejzak first raised the topic of time alignment in an earlier Internet Draft. This contribution has borrowed some of his words. Taylor (Ed.), et al. Expires November 2, 2006 [Page 15] Internet-Draft Time Alignment Using RTCP Feedback May 2006 6. References 6.1. Normative References [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [2] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, July 2003. [3] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. Norrman, "The Secure Real-time Transport Protocol (SRTP)", RFC 3711, March 2004. [4] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 4234, October 2005. [5] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session Description Protocol", RFC TBD. [6] Ott, J., Wenger, S., Sato, N., Burmeister, C., and J. Rey, "Extended RTP Profile for RTCP-based Feedback (RTP/AVPF)", RFC TBD. 6.2. Informative References [7] Schulzrinne, H. and T. Taylor, "RTP Payload for DTMF Digits, Telephony Tones and Telephony Signals", RFC TBD. Taylor (Ed.), et al. Expires November 2, 2006 [Page 16] Internet-Draft Time Alignment Using RTCP Feedback May 2006 Authors' Addresses Tom Taylor Nortel 1852 Lorraine Ave Ottawa, Ontario K1H 6Z8 CA Email: taylor@nortel.com Paul Boudreaux Nortel 2201 Lakeside Blvd Richardson, Texas 75083 USA Email: paulbx@nortel.com Chung-Cheung Chu Nortel 2351 Boulevard Alfred-Nobel St. Laurent, Quebec H4S 2A9 Canada Email: ccheung@nortel.com Rafi Rabipour Nortel 2351 Boulevard Alfred-Nobel St. Laurent, Quebec H4S 2A9 Canada Email: rabipour@nortel.com Taylor (Ed.), et al. Expires November 2, 2006 [Page 17] Internet-Draft Time Alignment Using RTCP Feedback May 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. Taylor (Ed.), et al. Expires November 2, 2006 [Page 18]