Network Working Group C. Alexander, Ed. Internet-Draft J. Babiarz Expires: August 15, 2005 J. Matthews Nortel February 11, 2005 Admission Control Use Case for Real-time ECN draft-alexander-rtecn-admission-control-use-case-00.txt Status of this Memo This document is an Internet-Draft and is subject to all provisions of Section 3 of RFC 3667. 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 become aware will be disclosed, in accordance with RFC 3668. 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 August 15, 2005. Copyright Notice Copyright (C) The Internet Society (2005). Abstract This document describes Admission Control as a use case for the mechanisms described in "Congestion Notification Process for Real-Time Traffic" [1] and the RTP payload format defined in "RTP Payload Format for ECN Probing" [2]. Alexander, et al. Expires August 15, 2005 [Page 1] Internet-Draft Real-time ECN Admission Control February 2005 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Admission Control . . . . . . . . . . . . . . . . . . . . . . 6 3.1 Probing Mechanism . . . . . . . . . . . . . . . . . . . . 6 3.2 Usage Examples . . . . . . . . . . . . . . . . . . . . . . 6 3.2.1 One-way Mechanism without Cheater Detection . . . . . 6 3.2.2 Two-way/Loop-back Mechanism without Cheater Detection . . . . . . . . . . . . . . . . . . . . . . 8 3.2.3 One-way Mechanism with Cheater Detection . . . . . . . 11 3.2.4 Two-way/Loop-back Mechanism with Cheater Detection . . 13 4. Security Considerations . . . . . . . . . . . . . . . . . . . 18 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 6. IAB Considerations . . . . . . . . . . . . . . . . . . . . . . 20 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 21 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 22 8.1 Normative References . . . . . . . . . . . . . . . . . . . 22 8.2 Informative References . . . . . . . . . . . . . . . . . . 22 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 22 Intellectual Property and Copyright Statements . . . . . . . . 24 Alexander, et al. Expires August 15, 2005 [Page 2] Internet-Draft Real-time ECN Admission Control February 2005 1. Introduction Converged networks that are configured to provide multi-services normally are engineered to provide the required quality of service using Diffserv technologies. Real-time inelastic traffic (e.g. voice) normally is configured to use Expedited Forwarding (EF) PHB to provide very low delay, loss and jitter transport. To stay within that engineered quality of service, and to ensure a quality of service level for that traffic, some type of admission control mechanism is necessary. Due to the sensitive nature of voice and other telephony applications (video conferencing, multi-media streaming), freely allowing these types of sessions onto a network where resources are limited can quickly lead to degradation of service that users may not tolerate. And in a packet based network, the degradation is not limited to the offending flows, which the provider may not tolerate. This document proposes an admission control solution based on "Congestion Notification Process for Real-Time Traffic" [1] and "RTP Payload Format for ECN Probing" [2]. The gist of the solution is that nodes at selected points in the network, where congestion is most likely to occur, measure traffic flow per service class and mark the ECN bits in the IP header based on observed traffic level(s). During session setup a probing mechanism is used between endpoints to verify traffic level (or congestion) along the path. The probing travels along the media path between the endpoints, where the endpoints are on either side of one or more bandwidth constrained links. At the links, ECN-capable nodes are provisioned with congestion thresholds based on a traffic type's real-time service class. The nodes mark the ECN bits in the IP headers of the probe packets according to the nodes' experienced level of congestion for the particular service class. As packets arrive, the ECN-capable endpoints recognize any ECN markings and make an admission control decision according to the indicated congestion level and session precedence. The Real-Time ECN process offers two levels of congestion indication. There is an intermediate congestion indication in addition to a maximum congestion indication. This adds flexibility to admission control decisions. The intermediate congestion indication essentially warns endpoint applications that network congestion is relatively high but that there is still some available bandwidth. Using this information, applications can possibly decide to filter out certain types of sessions for admission in favor of other types. Applications demanding a large amount of bandwidth like video conferencing might be denied, while less bandwidth-intensive voice sessions could be admitted. Whatever the admission control basis, Real-Time ECN enables some discernment in the decision making rather Alexander, et al. Expires August 15, 2005 [Page 3] Internet-Draft Real-time ECN Admission Control February 2005 than wholesale denial of sessions. Also, Real-Time ECN does not introduce a significant amount of overhead to the network. Not every node in the network needs to be ECN-capable. Only those nodes located at congestion points need the capability. At the nodes, ECN metering and marking is quick. There is practically no real-time hit to the routing. An ECN node does not maintain flow state and does not add delay with any intricate policy decisions. It's impact on the network is very low. The remainder of this memo provides four examples depicting ECN-based probing for admission control. While the examples provided are protocol-agnostic, general recommendations are provided as to how the payload format defined in [2] should be used in the context of admission control. No protocol-specific signaling is defined or suggested herein to show how to use the payload while admitting a new session. Alexander, et al. Expires August 15, 2005 [Page 4] Internet-Draft Real-time ECN Admission Control February 2005 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 [9] and indicate requirement levels for compliant implementations. Alexander, et al. Expires August 15, 2005 [Page 5] Internet-Draft Real-time ECN Admission Control February 2005 3. Admission Control Admission control can use a probing mechanism to determine whether there is available bandwidth for a session. The endpoints of a session perform this probing which occurs during session setup. Depending upon results of the probing mechanism, the session will be either admitted or denied. This decision can be made within an endpoint, or by a session server. 3.1 Probing Mechanism The probing mechanism makes use of "Congestion Notification Process for Real-Time Traffic" [1] and "RTP Payload Format for ECN Probing" [2]. It can be either uni-directional or bi-directional, but in either case is end-to-end. 3.2 Usage Examples Four usage examples are provided. These cover use of the RTP payload format in [2] in both one-way and two-way loop-back mechanisms, both with and without detection of Cheaters along the media path. The terminology used is defined in [2], as well. All examples presume that probing starts at a point during session setup when the Responder endpoint addressing information is known by the Sender, and the dynamic payload type used for the packets carrying the payload has been determined. As the immediate application is admission control, the endpoints involved SHOULD NOT begin alerting or otherwise notifying the user of a new session until the admission control procedures determine whether to admit the new session. All examples list the relevant field contents where necessary. In a real implementation, it is recommended that the payload be secured. In order to ensure there is no confusion between different versions of the referenced drafts, the following ECN bit definitions are used in the four examples: 00 Not ECN-capable 10 ECN-capable, with no congestion experienced 11 ECN-capable, with congestion experienced at the first level 01 ECN-capable, with congestion experienced at the second level 3.2.1 One-way Mechanism without Cheater Detection A one-way probing mechanism without cheater detection is the simplest possible use of the payload format defined in [2]. The ECN field in Alexander, et al. Expires August 15, 2005 [Page 6] Internet-Draft Real-time ECN Admission Control February 2005 the IP header MUST be set to 10, indicating that the endpoint is ECN-capable. The Version field MUST be set appropriately, i.e., for this memo, to zero. The remaining fields SHOULD be set to zero. If the session for which admission control is two-way, then two of these one-way mechanisms can be used for admission control, one in each direction. (1) (3) +------+ +----------+ +------+ | | | | | | | EP A | ----> | Router A | ----> + EP B | (5) | | | | | | +------+ +----------+ +------+ (2) (4) Figure 1: One-way Mechanism without Cheater Detection 1. Endpoint (EP) A starts the process. It creates a Request Probe Packet and sends it to the address and port it has for EP B. IP Header: DSCP: ECN: 10, indicating endpoint is ECN-capable RTP Header: Payload Type: admcntl Payload: Version: 0000 SCI: 00 RCI: 00 SCI Sequence Number: 0000 0000 0000 0000 Reserved: 0000 0000 2. Router A receives the Request Probe Packet, and factors it into the methods described in [1] for real-time inelastic traffic. 3. Router A re-marks the ECN field in the IP header of the Request Probe Packet as described in [1], then forwards the packet. IP Header: DSCP: ECN: RTP Header: Payload Type: admcntl Payload: Alexander, et al. Expires August 15, 2005 [Page 7] Internet-Draft Real-time ECN Admission Control February 2005 Version: 0000 SCI: 00 RCI: 00 SCI Sequence Number: 0000 0000 0000 0000 Reserved: 0000 0000 4. EP B receives the Request Probe Packet. The ECN value, ReqECN, in the IP header indicates the highest level of congestion on the path towards EP B. IP Header: DSCP: ECN: RTP Header: Payload Type: admcntl Payload: Version: 0000 SCI: 00 RCI: 00 SCI Sequence Number: 0000 0000 0000 0000 Reserved: 0000 0000 5. EP B inspects the ECN value, ReqECN, in the IP header, then knows the highest level of congestion on the path towards EP B. Based on this, EP B can determine whether the session should be admitted. 3.2.2 Two-way/Loop-back Mechanism without Cheater Detection The two-way probing mechanism without cheater detection is not that much more complicated than the one-way probing mechanism, although it does utilize one additional payload field. The most noticable difference is that a Response Probe Packet is sent in response to the Request Probe Packet. The ECN field in the IP headers MUST be set to 10, indicating that the endpoints are ECN-capable. The Version field MUST be set appropriately, i.e., for this memo, to zero. The SCI field in the Request Probe Packet SHOULD be set to zero, and in the Response Probe Packet should be set to the ECN value in the IP header of the associated Request Probe Packet. The remaining fields SHOULD be set to zero. With a two-way/loop-back probing mechanism, the congestion indication for both the upstream and downstream packet flows can be determined with a single procedure, as illustrated by this example. Alexander, et al. Expires August 15, 2005 [Page 8] Internet-Draft Real-time ECN Admission Control February 2005 (1) (2) (3) (4) +------+ +----------+ +------+ | | ----> | Router A | ----> | | | | +----------+ | | (9) | EP A | | EP B | | | +----------+ | | | | <---- | Router B | <---- | | +------+ +----------+ +------+ (8) (7) (6) (5) Figure 2: Two-way/Loop-back Mechanism without Cheater Detection 1. Endpoint (EP) A starts the process. It creates a Request Probe Packet and sends it to the address and port it has for EP B. IP Header: DSCP: ECN: 10, indicating endpoint is ECN-capable RTP Header: Payload Type: admcntl Payload: Version: 0000 SCI: 00 RCI: 00 SCI Sequence Number: 0000 0000 0000 0000 Reserved: 0000 0000 2. Router A receives the Request Probe Packet, and factors it into the methods described in [1] for real-time inelastic traffic. 3. Router A re-marks the ECN field in the IP header of the Request Probe Packet as described in [1], then forwards the packet. IP Header: DSCP: ECN: RTP Header: Payload Type: admcntl Payload: Version: 0000 SCI: 00 RCI: 00 SCI Sequence Number: 0000 0000 0000 0000 Reserved: 0000 0000 4. EP B receives the Request Probe Packet. The ECN value, ReqECN, in the IP header indicates the highest level of congestion on the Alexander, et al. Expires August 15, 2005 [Page 9] Internet-Draft Real-time ECN Admission Control February 2005 path towards EP B. This completes the first half of the two-way/loop-back probe. IP Header: DSCP: ECN: RTP Header: Payload Type: admcntl Payload: Version: 0000 SCI: 00 RCI: 00 SCI Sequence Number: 0000 0000 0000 0000 Reserved: 0000 0000 5. EP B creates a Response Probe Packet and sends it to the address and port it has for EP A. Note the payload difference between the Request Probe Packet sent by EP A and the Response Probe Packet sent by EP B. First, the SCI field contains the ReqECN value from the Request Probe Packet. Second, the SCI Sequence Number field contains the value of the Sequence Number field in the RTP header of the Request Probe Packet. IP Header: DSCP: ECN: 10, indicating endpoint is ECN-capable RTP Header: Payload Type: admcntl Payload: Version: 0000 SCI: RCI: 00 SCI Sequence Number: Reserved: 0000 0000 6. Router B receives the Response Probe Packet, and factors it into the methods described in [1] for real-time inelastic traffic. 7. Router B re-marks the ECN field in the IP header of the Response Probe Packet as described in [1], then forwards the packet. IP Header: Alexander, et al. Expires August 15, 2005 [Page 10] Internet-Draft Real-time ECN Admission Control February 2005 DSCP: ECN: RTP Header: Payload Type: admcntl Payload: Version: 0000 SCI: RCI: 00 SCI Sequence Number: Reserved: 0000 0000 8. EP A receives the Response Probe Packet. The ECN value, RspECN, in the IP header indicates the highest level of congestion on path towards EP A. This completes the second half of the two-way/loop-back probe. IP Header: DSCP: ECN: RTP Header: Payload Type: admcntl Payload: Version: 0000 SCI: RCI: 00 SCI Sequence Number: Reserved: 0000 0000 9. EP A inspects the two ECN values, RspECN (in the IP header) and ReqECN (in the admcntl payload), then knows the highest level of congestion on the paths between EP A and EP B. Based on this, EP A can determine whether the session should be admitted. 3.2.3 One-way Mechanism with Cheater Detection A one-way probing mechanism with cheater detection differs from the first example in two respects. First, the SCI field in the Request Probe Packet contains the ECN value set in the ECN field in the IP header. Second, additional processing in EP B is necessary to determine if there are Cheaters present on the path towards EP B. In order to perform Cheater detection, more than one Request Probe Alexander, et al. Expires August 15, 2005 [Page 11] Internet-Draft Real-time ECN Admission Control February 2005 Packet must be sent, each with different ECN values in the IP header, as described in [1]. (1) (3) +------+ +----------+ +------+ | | | | | | | EP A | ----> | Router A | ----> + EP B | (5) | | | | | | +------+ +----------+ +------+ (2) (4) Figure 3: One-way Mechanism with Cheater Detection 1. Endpoint (EP) A starts the process. It creates a Request Probe Packet and sends it to the address and port it has for EP B. At least three Request Probe Packets are sent. A random ordering of the three ECN value 10, 11, or 01 is chosen, and these values are used in sequential Request Probe Packets for the ECN value in the IP header and the SCI field in the admcntl payload. Refer to [1] for additional details. At least three Request Probe Packets are needed so that three sequential packets are received by the Responder in order to determine the actual marking from the routers along the network path. IP Header: DSCP: ECN: <10, 11, or 01; Refer to [1] for details> RTP Header: Payload Type: admcntl Payload: Version: 0000 SCI: RCI: 00 SCI Sequence Number: 0000 0000 0000 0000 Reserved: 0000 0000 2. Router A receives the Request Probe Packet, and factors it into the methods described in [1] for real-time inelastic traffic. 3. Router A re-marks the ECN field in the IP header of the Request Probe Packet as described in [1], then forwards the packet. IP Header: DSCP: Alexander, et al. Expires August 15, 2005 [Page 12] Internet-Draft Real-time ECN Admission Control February 2005 ECN: RTP Header: Payload Type: admcntl Payload: Version: 0000 SCI: RCI: 00 SCI Sequence Number: 0000 0000 0000 0000 Reserved: 0000 0000 4. EP B receives the Request Probe Packet. EP B tracks the ECN value, ReqECN, from the IP header, and the SCI value from the admcntl payload until it receives at least three out of four sequential Request Probe Packets. IP Header: DSCP: ECN: RTP Header: Payload Type: admcntl Payload: Version: 0000 SCI: RCI: 00 SCI Sequence Number: 0000 0000 0000 0000 Reserved: 0000 0000 5. Once EP B has received three sequential Request Probe Packets, it can follow the steps described in [1] to both detect if Cheaters are present on the path towards EP B, and to filter out the highest actual level of congestion on path towards EP B. The decision to admit is made based on whether Cheaters are present and the level of congestion indicated by the ECN markings. 3.2.4 Two-way/Loop-back Mechanism with Cheater Detection The two-way probing mechanism with cheater detection differs from the second example mainly with respect to the content of the admcntl fields in the Response Probe Packet. In the Response Probe Packet, the SCI field contains the ECN value in the IP header of the associated Request Probe Packet. The SCI Sequence Number field contains the sequence number from the RTP header of the associated Request Probe Packet. Alexander, et al. Expires August 15, 2005 [Page 13] Internet-Draft Real-time ECN Admission Control February 2005 In the Request Probe Packet, all admcntl payload fields SHOULD be set to zero. (1) (2) (3) (4) +------+ +----------+ +------+ | | ----> | Router A | ----> | | | | +----------+ | | (9) | EP A | | EP B | | | +----------+ | | | | <---- | Router B | <---- | | +------+ +----------+ +------+ (8) (7) (6) (5) Figure 4: Two-way/Loop-back Mechanism with Cheater Detection 1. Endpoint (EP) A starts the process. It creates a Request Probe Packet and sends it to the address and port it has for EP B. At least three Request Probe Packets are sent. A random ordering of the three ECN value 10, 11, or 01 is chosen, and these values are used in sequential Request Probe Packets for the ECN value in the IP header and the SCI field in the admcntl payload. Refer to [1] for additional details. At least three Request Probe Packets are needed so that three sequential packets are received by the Responder in order to determine the actual marking from the routers along the network path. EP A must track the ECN value used by sequence number for use in steps 8 and 9 below. Refer to [1] for additional details. All other admcntl fields are zero IP Header: DSCP: ECN: <10, 11, or 01; Refer to [1] for details> RTP Header: Payload Type: admcntl Payload: Version: 0000 SCI: 00 RCI: 00 SCI Sequence Number: 0000 0000 0000 0000 Reserved: 0000 0000 2. Router A receives the Request Probe Packet, and factors it into the methods described in [1] for real-time inelastic traffic. 3. Router A re-marks the ECN field in the IP header of the Request Probe Packet as described in [1], then forwards the packet. Alexander, et al. Expires August 15, 2005 [Page 14] Internet-Draft Real-time ECN Admission Control February 2005 IP Header: DSCP: ECN: RTP Header: Payload Type: admcntl Payload: Version: 0000 SCI: 00 RCI: 00 SCI Sequence Number: 0000 0000 0000 0000 Reserved: 0000 0000 4. EP B receives the Request Probe Packet. The ECN value, ReqECN, in the IP header indicates the highest level of congestion on the path towards EP B. This completes the first half of the two-way/loop-back probe. IP Header: DSCP: ECN: RTP Header: Payload Type: admcntl Payload: Version: 0000 SCI: 00 RCI: 00 SCI Sequence Number: 0000 0000 0000 0000 Reserved: 0000 0000 5. EP B creates a Response Probe Packet and sends it to the address and port it has for EP A. Note the payload difference between the Request Probe Packet sent by EP A and the Response Probe Packet sent by EP B. First, the SCI field contains the ReqECN value from the Request Probe Packet. Second, the SCI Sequence Number field contains the value of the Sequence Number field in the RTP header of the Request Probe Packet. Similar to the Request Probe Packet, the ECN value in the IP header of the Response Probe Packet and the SCI field in the admcntl payload are set with one of 10, 11, or 01. IP Header: DSCP: Alexander, et al. Expires August 15, 2005 [Page 15] Internet-Draft Real-time ECN Admission Control February 2005 ECN: <10, 11, or 01; Refer to [1] for details> RTP Header: Payload Type: admcntl Payload: Version: 0000 SCI: RCI: SCI Sequence Number: Reserved: 0000 0000 6. Router B receives the Response Probe Packet, and factors it into the methods described in [1] for real-time inelastic traffic. 7. Router B re-marks the ECN field in the IP header of the Response Probe Packet as described in [1], then forwards the packet. IP Header: DSCP: ECN: RTP Header: Payload Type: admcntl Payload: Version: 0000 SCI: RCI: SCI Sequence Number: Reserved: 0000 0000 8. EP A receives the Response Probe Packet. EP A tracks the ECN values ReqECN (from the SCI field in the admcntl payload), RspECN (from the ECN field in the IP header of the Response Probe Packet), and RCI from the admcntl payload. It uses the SCI Sequence Number value to associate these three values with the appropriate ECN value used step 1 above. It tracks these values until it receives at least three sequential Request Probe Packets. IP Header: Alexander, et al. Expires August 15, 2005 [Page 16] Internet-Draft Real-time ECN Admission Control February 2005 DSCP: ECN: RTP Header: Payload Type: admcntl Payload: Version: 0000 SCI: RCI: SCI Sequence Number: Reserved: 0000 0000 9. Once EP A has received three sequential Response Probe Packets, it can follow the steps described in [1] to both detect if Cheaters are present on both of the paths, towards EP B and towards EP B, and to filter out the highest actual level of congestion on both of the paths. The decision to admit is made based on whether Cheaters are present and the level of congestion indicated by the ECN markings. Alexander, et al. Expires August 15, 2005 [Page 17] Internet-Draft Real-time ECN Admission Control February 2005 4. Security Considerations Refer to "Congestion Notification Process for Real-Time Traffic" [1] and "RTP Payload Format for ECN Probing" [2] for security-related considerations. Alexander, et al. Expires August 15, 2005 [Page 18] Internet-Draft Real-time ECN Admission Control February 2005 5. IANA Considerations There are no IANA considerations. Alexander, et al. Expires August 15, 2005 [Page 19] Internet-Draft Real-time ECN Admission Control February 2005 6. IAB Considerations There are no IAB considerations. Alexander, et al. Expires August 15, 2005 [Page 20] Internet-Draft Real-time ECN Admission Control February 2005 7. Acknowledgements The authors acknowledge a great many inputs, including the following: John Rutledge, Marvin Krym, Stephen Dudley, and Kwok Ho Chan. Alexander, et al. Expires August 15, 2005 [Page 21] Internet-Draft Real-time ECN Admission Control February 2005 8. References 8.1 Normative References [1] Babiarz, J., Chan, K. and V. Firoiu, "Congestion Notification Process for Real-Time Traffic, draft-babiarz-tsvwg-rtecn-03", Internet-Draft Work in Progress, February 2005. [2] Alexander, C., Ed. and J. Babiarz, "RTP Payload Format for ECN Probing, draft-alexander-rtp-payload-for-ecn-probing-00", Internet-Draft Work in Progress, February 2005. 8.2 Informative References [3] Ramakrishnan, K., Floyd, S. and D. Black, "The Addition of Explicit Congestion Notification (ECN) to IP", RFC 3168, September 2001. Authors' Addresses Corey W. Alexander (editor) Nortel MS 08704A30 2370 Performance Drive Richardson, TX 75287 USA Phone: +1 972 684-8320 Email: coreya@nortel.com Jozef Z. Babiarz Nortel MS 04331C04 3500 Carling Avenue Nepean, Ontario K2H 8E9 Canada Phone: +1 613 763-6098 Email: babiarz@nortel.com Alexander, et al. Expires August 15, 2005 [Page 22] Internet-Draft Real-time ECN Admission Control February 2005 Jeremy P. Matthews Nortel MS 08704A30 2370 Performance Drive Richardson, TX 75082 USA Phone: +1 972 684-0336 Email: jeremym@nortel.com Alexander, et al. Expires August 15, 2005 [Page 23] Internet-Draft Real-time ECN Admission Control February 2005 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 (2005). 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. Alexander, et al. Expires August 15, 2005 [Page 24]