Robust Header Compression C. Bormann, Ed. Internet-Draft Universitaet Bremen TZI Expires: August 18, 2006 Z. Liu Nokia Research Center R. Price Cogent Defence and Security Networks G. Camarillo Ericsson February 14, 2006 Applying Signaling Compression (SigComp) to the Session Initiation Protocol (SIP) draft-ietf-rohc-sigcomp-sip-02.txt 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 August 18, 2006. Copyright Notice Copyright (C) The Internet Society (2006). Abstract This document describes some specifics that apply when Signaling Bormann, et al. Expires August 18, 2006 [Page 1] Internet-Draft Applying SigComp to SIP February 2006 Compression (SigComp) is applied to the Session Initiation Protocol (SIP), such as default minimum values of SigComp parameters, compartment and state management, and a few issues on SigComp over TCP. Any implementation of SigComp for use with SIP must conform to this document, in addition to SigComp and support of the SIP and Session Description Protocol (SDP) static dictionary. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Minimum Values of SigComp Parameters for SIP/SigComp . . . . . 3 3.1. decompression_memory_size (DMS) for SIP/SigComp . . . . . 4 3.2. state_memory_size (SMS) for SIP/SigComp . . . . . . . . . 4 3.3. cycles_per_bit (CPB) for SIP/SigComp . . . . . . . . . . . 5 3.4. SigComp_version (SV) for SIP/SigComp . . . . . . . . . . . 5 3.5. locally available state (LAS) for SIP/SigComp . . . . . . 5 4. Delimiting SIP Messages and SigComp Messages on the Same Port . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 5. Continuous Mode over TCP . . . . . . . . . . . . . . . . . . . 6 6. Compartment and State Management for SIP/SigComp . . . . . . . 7 6.1. Remote Application Identifiers . . . . . . . . . . . . . . 7 6.2. Compartment Opening and Closure . . . . . . . . . . . . . 7 6.3. Compartment Valid During a Transaction . . . . . . . . . . 9 6.4. Compartment Valid During a Registration . . . . . . . . . 9 6.5. Compartment Valid During a Dialog . . . . . . . . . . . . 10 7. Recommendations for Network Administrators . . . . . . . . . . 10 8. Security Considerations . . . . . . . . . . . . . . . . . . . 11 9. Private Agreements . . . . . . . . . . . . . . . . . . . . . . 11 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11 12. Normative References . . . . . . . . . . . . . . . . . . . . . 11 Appendix A. Shim header for sending uncompressed messages . . . . 12 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14 Intellectual Property and Copyright Statements . . . . . . . . . . 15 Bormann, et al. Expires August 18, 2006 [Page 2] Internet-Draft Applying SigComp to SIP February 2006 1. Introduction SigComp [RFC3320] is a solution for compressing messages generated by application protocols. Although its primary driver is to compress SIP [RFC3261] messages, the solution itself has been intentionally designed to be application agnostic so that it can be applied to any application protocol. (This is denoted as ANY/SigComp.) Consequently, many application dependent specifics are left out of the base standard. It is intended that a separate specification is used to describe those specifics when SigComp is applied to a particular application protocol. This document binds SigComp and SIP (denoted as SIP/SigComp). Any SigComp implementation that is used for the compression of SIP messages must conform to this document, as well as to [RFC3320] and must support the SIP/SDP static dictionary as specified in [RFC3485]. Note: the mechanism of discovering SigComp support at the SIP layer is specified in [RFC3486]. 2. 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 BCP 14 [RFC2119]. 3. Minimum Values of SigComp Parameters for SIP/SigComp In order to support a wide range of capabilities among endpoints implementing SigComp, SigComp defines a few parameters to describe SigComp behavior (see section 3.3 of [RFC3320]). For each parameter, [RFC3320] specifies a minimum value that any SigComp endpoint MUST support for ANY/SigComp. Those minimum values were determined with the consideration of all imaginable devices in which SigComp may be implemented. Scalability was also considered as a key factor. However, some of the minimum values specified in [RFC3320] are too small to allow good performance for SIP message compression. Therefore, they are increased for SIP/SigComp as specified in the following sections. For completeness, those parameters that are the same for SIP/SigComp as they are for ANY/SigComp are also listed. Note: the new minimum values are specific to SIP/SigComp. They do not apply to any other application protocols. Note: a SigComp endpoint MAY offer additional resources if available; Bormann, et al. Expires August 18, 2006 [Page 3] Internet-Draft Applying SigComp to SIP February 2006 these resources can be advertised to remote endpoints as described in section 9.4.9 of [RFC3320]. 3.1. decompression_memory_size (DMS) for SIP/SigComp Minimum value for ANY/SigComp: 2048 bytes, as specified in section 3.3.1 of [RFC3320]. Minimum value for SIP/SigComp: 8192 bytes. Reason: a DMS of 2048 bytes is too small for SIP message compression, as it seriously limits the compression ratio and even makes compression impossible for certain messages. For example, the condition set by [RFC3320] for SigComp over UDP means: C + 2*B + R + 2*S + 128 < DMS (each term is described below). On the other hand, 8KB additional memory should not cause any problem for an endpoint that already implements SIP, SigComp, and applications that use SIP, as DMS is memory only temporarily needed during decompression of a SigComp message (the memory can be reclaimed when the message has been decompressed). C size of compressed application message, depending on R B size of bytecode (note: two copies -- one as part of the SigComp message and one in UDVM memory) R size of ring buffer in UDVM memory S any additional state uploaded other than that created from the content of the ring buffer at the end of decompression (similar to B, two copies of S are needed) 128 the smallest address in UDVM memory to copy bytecode to 3.2. state_memory_size (SMS) for SIP/SigComp Minimum value for ANY/SigComp: 0 (zero) bytes, as specified in section 3.3.1 of [RFC3320]. Minimum value for SIP/SigComp: 2048 bytes. Reason: a non-zero SMS allows an endpoint to upload a state in the first SIP message sent to a remote endpoint without the uncertainty of whether or not it can be created in the remote endpoint. A non- zero SMS obviously requires the SIP/SigComp implementation to keep state. Based on the observation that there is little gain from stateless SigComp compression, the assumption is that purely stateless SIP implementations are unlikely to provide a SigComp function. Stateful implementations should have little problem to keep 2K additional state for each compartment (see Section 6). Note: SMS is a parameter that applies to each individual compartment. Bormann, et al. Expires August 18, 2006 [Page 4] Internet-Draft Applying SigComp to SIP February 2006 An endpoint MAY offer different SMS values for different compartments as long as the SMS value is not less than 2048 bytes. Compressors that make use of initial state memory MUST implement the SigComp Negative Acknowledgement (NACK) Mechanism [I-D.ietf-rohc- sigcomp-nack]. (Note that there is no such requirement on decompressors, but see also Section 6.) For this requirement, initial state memory is defined as the assumption of a non-zero SMS value before having received an advertisement of non-zero SMS (e.g., via returned parameters as specified in section 9.4.9 of [RFC3320]); ANY/SigComp as defined in [RFC3320] does not have initial state memory. 3.3. cycles_per_bit (CPB) for SIP/SigComp Minimum value for ANY/SigComp: 16, as specified in section 3.3.1 of [RFC3320]. Minimum value for SIP/SigComp: 16 (same as above) 3.4. SigComp_version (SV) for SIP/SigComp For ANY/SigComp: 0x01, as specified in section 3.3.2 of [RFC3320]. OPEN ISSUE: what SigComp version(s) should be required for SIP/ SigComp? Version >= 0x01 (i.e. any SigComp) Version >= 0x02 (i.e. at least SigComp + NACK) Version == 0x01 | 0x02 (base SigComp or SigComp + NACK) Version == 0x02 (only SigComp with NACK) For SIP/SigComp: 0x01 (same as above) 3.5. locally available state (LAS) for SIP/SigComp Minimum LAS for ANY/SigComp: none, see section 3.3.3 of [RFC3320]. Minimum LAS for SIP/SigComp: the SIP/SDP static dictionary as defined in [RFC3485]. 4. Delimiting SIP Messages and SigComp Messages on the Same Port In order to limit the number of ports required by a SigComp-aware endpoint, it is possible to allow both SigComp messages and 'vanilla' SIP messages (i.e. uncompressed SIP messages with no SigComp header) to arrive on the same port. Bormann, et al. Expires August 18, 2006 [Page 5] Internet-Draft Applying SigComp to SIP February 2006 For a message-based transport such as UDP or SCTP, this can be done per message. The receiving endpoint checks the first octet of the UDP/SCTP payload to determine whether the message has been compressed using SigComp. If the MSBs of the octet are "11111" then the message is considered to be a SigComp message and is parsed as per [RFC3320]. If the MSBs of the octet take any other value, then the message is assumed to be an uncompressed SIP message, and is passed directly to the application with no further effect on the SigComp layer. For a stream-based transport such as TCP, the distinction is per connection. The receiving endpoint checks the first octet of the TCP data stream to determine whether the stream has been compressed using SigComp. If the MSBs of the octet are "11111" then the stream is considered to contain SigComp messages and is parsed as per [RFC3320]. If the MSBs of the octet take any other value, then the stream is assumed to contain uncompressed SIP messages, and is passed directly to the application with no further effect on the SigComp layer. Note that SigComp message delimiters MUST NOT be used if the stream contains uncompressed SIP messages. Applications MUST NOT mix SIP messages and SigComp messages on a single TCP connection. If the TCP connection is used to carry SigComp messages then all messages sent over the connection MUST have a SigComp header and be delimited by the use of 0xFFFF as described in [RFC3320]. Note: Appendix A shows how to send uncompressed messages in a SigComp structured TCP connection using a "well-known shim header". Should it for any reason not be desirable to set up more than one TCP connection to a SIP implementation, but the flexibility to send both compressed and uncompressed SIP messages be required, the compressor can set up a SigComp structured connection and send any uncompressed SIP messages using the well-known shim header. 5. Continuous Mode over TCP Continuous Mode is a special feature of SigComp, which is designed to improve the overall compression ratio for long-lived connections. Its use requires pre-agreement between the SigComp compressor and decompressor. Continuous mode is not used with SIP/SigComp. Reason: continuous mode requires the transport itself to provide a certain level of protection against denial of service attacks. TCP alone is not considered to provide enough protection. Bormann, et al. Expires August 18, 2006 [Page 6] Internet-Draft Applying SigComp to SIP February 2006 6. Compartment and State Management for SIP/SigComp An application exchanging compressed traffic with a remote application has a compartment that contains state information needed to compress outgoing messages and to decompress incoming messages. To increase the compression efficiency, the application must assign distinct compartments to distinct remote applications. 6.1. Remote Application Identifiers SIP/SigComp applications identify remote applications by their FQDN (Fully Qualified Domain Name) or by their IP address. For outgoing requests, the remote application identifier is the host part of the URI to which the request is sent. For incoming responses, the remote application identifier is the same as the one for the previously-sent request that initiated the transaction the response belongs to. For incoming requests and outgoing responses, the remote application identifier is the sent-by parameter of the top-most Via entry. A given remote application identifier is mapped to a particular SigComp compartment ID following the rules given in the following sections. OPEN ISSUE: this is an implicit way of identifying remote applications. It assumes that two remote applications are different if the host parts of their URIs are different. However, if a proxy farm shares dictionary state among its proxies and these proxies use different host parts (e.g., proxy1.example.com and proxy2.example.com), they will be considered like different remote applications, when they should have been considered a single remote application. If implementers intend to implement state sharing this way, we could use explicit application identifiers instead. These identifiers could be placed in a SIP URI parameter (e.g., sip:p1.example.net;id="12wsfeQ45") and in a Via parameter. 6.2. Compartment Opening and Closure SIP applications need to know when to open a new compartment and when to close it. The lifetime of a compartment depends on how the SIP application obtained the remote application identifier (e.g., in a Record-Route header field of an incoming SIP message). There are compartments that are valid for the duration of a registration, of a dialog, and of a single transaction. The following sections specify how a SIP application decides the lifetime of a particular compartment. If following the rules in the following sections, a SIP application Bormann, et al. Expires August 18, 2006 [Page 7] Internet-Draft Applying SigComp to SIP February 2006 is supposed to open a compartment for a remote application identifier for which it already has a compartment, the SIP application MUST use the already existing compartment. That is, the SIP application MUST NOT open a new compartment. Additionally, the SIP application MUST adjust the closure time for the compartment so that it is only closed when the SIP application does not need it any longer. For example, a SIP application may open a compartment valid for the duration of a registration for a particular remote application identifier. At a later point, the application is supposed to open a new compartment for the duration of a particular dialog for the same remote application identifier. Following the previous rule, the SIP application does not open a new compartment but use the already existing one for that remote application identifier. However, the SIP application must not close that compartment until both, the registration and the dialog are over. So, if the registration finishes before the dialog, the compartment will not be closed (because the dialog is still active) even though the compartment was originally open for the registration. Usually, any states created during the lifetime of a compartment will be "logically" deleted when the compartment is closed. (As described in section 6.2 of [RFC3320], a logical deletion can become a physical deletion only when no compartment continues to exist that created the (same) state.) A SigComp endpoint may offer to keep a state created upon request from a SigComp peer endpoint beyond the default lifetime of a compartment. This may be used to improve compression efficiency of subsequent SIP messages generated by the same remote application at the SigComp peer endpoint. To indicate that such state will continue to be available, the SigComp endpoint can inform its peer SigComp endpoint by announcing the (partial) state ID in the returned SigComp parameters at the end of the registration, dialog, or transaction that was supposed to limit the lifetime of the SigComp state. That signals the state will be maintained. As there is no way to signal any limit to the lifetime of this state, both decompressors that intend to offer state with possibly limited lifetimes as well as compressors that make use of such state SHOULD implement the SigComp Negative Acknowledgement (NACK) Mechanism [I-D.ietf-rohc-sigcomp- nack]. As an operational concern, bugs in the compartment management implementation are likely to lead to sporadic, hard to diagnose failures. Decompressors may therefore want to cache old state and, if still available, allow access while logging diagnostic information. Both compressors and decompressors are RECOMMENDED to implement the SigComp Negative Acknowledgement (NACK) Mechanism Bormann, et al. Expires August 18, 2006 [Page 8] Internet-Draft Applying SigComp to SIP February 2006 [I-D.ietf-rohc-sigcomp-nack], which facilitates recovery in a situation where such old state may no longer be available. 6.3. Compartment Valid During a Transaction A SIP application that needs to send a compressed SIP request SHOULD open a compartment for the request's remote application identifier. This compartment will be used to receive compressed responses for the request. The application can close the compartment when the transaction is over. A SIP application receives a compressed SIP request SHOULD open a compartment for the request's remote application identifier. This compartment will be used to send compressed responses for the request. The application SHOULD NOT close the compartment until the transaction is over. The previous rules ensure that SIP applications always have an already existing compartment to send and receive responses. 6.4. Compartment Valid During a Registration A REGISTER transaction can cause an application to open a new compartment to be valid for the duration of the registration established by the REGISTER transaction. A 200 (OK) response for a register may contain a Path [RFC3327] and a Service-Route [RFC3308] header field. These header fields indicate the route future incoming and outgoing requests will follow. On receiving a 200 (OK) response for a REGISTER, a SIP application that inserted itself in the Contact (i.e., because it is the user agent) or in the Path header field of the REGISTER, constructs the route future incoming requests will follow (using the Contact and the Path header fields) and the route future outgoing requests will follow (using the Contact and the Service-Route header fields). The application checks whether the URIs of its adjacent applications in both routes have the comp=sigcomp parameter. The application SHOULD open a new compartment for the remote application identifier of the URIs with that parameter. The application SHOULD NOT close the compartments until the registration is over. Note that the route for incoming requests is typically the same (although traversed in the opposite direction) as the route for outgoing requests. Note that some user agents use several registration in parallel to improve service reliability. Different registration typically have Bormann, et al. Expires August 18, 2006 [Page 9] Internet-Draft Applying SigComp to SIP February 2006 different associated route vectors. Messages sent to different remote application identifiers will use different compartments, even if those messages are generated by the same user agent. It is assumed that the remote applications do not share SIP/SigComp state among them. 6.5. Compartment Valid During a Dialog A transaction that establishes a dialog can cause an application to open a new compartment to be valid for the duration of the dialog established by the transaction. A SIP message that establishes a dialog (e.g., a 2xx response for an INVITE) may contain a Record-Route header field. This header field indicates the route future requests within the dialog will follow. On receiving such a SIP message, a SIP application that inserted itself in the Contact (i.e., because it is the user agent) or in the Record-Route header field of the request, constructs (using the Contact, and the Record-Route header fields) the route requests within the dialog will follow. The application checks whether the URIs of its adjacent applications in that route have the "comp=sigcomp" parameter. The application SHOULD open a new compartment for the remote application identifier of the URIs with that parameter. The application SHOULD NOT close the compartments until the dialog is over. 7. Recommendations for Network Administrators Network administrators can configure their networks so that the compression efficiency achieved is increased. The following recommendations help network administrators perform their task. For a given user agent, the route sets for incoming requests (created by a Path header field) and for outgoing requests (created by a Service-Route header field) are typically the same. However, registrars can, if they wish, insert proxies in the latter route that do not appear in the former route and vice versa. It is RECOMMENDED that registrars are configured so that proxies performing SigComp compression appear in both routes. The routes described previously apply to requests sent outside a dialog. Requests inside a dialog follow a route constructed using Record-Route header fields. It is RECOMMENDED that the proxies performing SigComp that are in the route for requests outside a dialog are configured to place themselves (by inserting themselves in the Record-Route header fields) in the routes used for requests Bormann, et al. Expires August 18, 2006 [Page 10] Internet-Draft Applying SigComp to SIP February 2006 inside dialogs. 8. Security Considerations The same security considerations as described in [RFC3320] apply to this document. Note that keeping SigComp states longer than the duration of a SIP dialog should not pose new security risks for two reasons: a) the state has been allowed to be created in the first place; and b) this is on voluntary basis and a SigComp endpoint can choose not to offer it. 9. Private Agreements SIP/SigComp implementations that are subject to private agreements MAY deviate from this specification, if the private agreements unambiguously specify so. Plausible candidates for such deviations include: o Minimum values (Section 3). o Compartment definition (Section 6). o Use of continuous mode (Section 5). 10. IANA Considerations This specification does not require any actions from the IANA. 11. Acknowledgements Abigail Surtees provided the code and text for Appendix A. The authors would like to thank the following people for their comments and suggestions: Abigail Surtees, Jan Christoffersson, Joerg Ott, Mark West, Pekka Pessi, Robert Sugar, and Adam Roach. 12. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002. Bormann, et al. Expires August 18, 2006 [Page 11] Internet-Draft Applying SigComp to SIP February 2006 [RFC3308] Calhoun, P., Luo, W., McPherson, D., and K. Peirce, "Layer Two Tunneling Protocol (L2TP) Differentiated Services Extension", RFC 3308, November 2002. [RFC3320] Price, R., Bormann, C., Christoffersson, J., Hannu, H., Liu, Z., and J. Rosenberg, "Signaling Compression (SigComp)", RFC 3320, January 2003. [RFC3327] Willis, D. and B. Hoeneisen, "Session Initiation Protocol (SIP) Extension Header Field for Registering Non-Adjacent Contacts", RFC 3327, December 2002. [RFC3485] Garcia-Martin, M., Bormann, C., Ott, J., Price, R., and A. Roach, "The Session Initiation Protocol (SIP) and Session Description Protocol (SDP) Static Dictionary for Signaling Compression (SigComp)", RFC 3485, February 2003. [RFC3486] Camarillo, G., "Compressing the Session Initiation Protocol (SIP)", RFC 3486, February 2003. [I-D.ietf-rohc-sigcomp-nack] Roach, A., "A Negative Acknowledgement Mechanism for Signaling Compression", draft-ietf-rohc-sigcomp-nack-02 (work in progress), October 2004. Appendix A. Shim header for sending uncompressed messages This appendix presents bytecode that simply instructs the decompressor to output the entire message (effectively sending it uncompressed but within a SigComp message). The mnemonic code is: Bormann, et al. Expires August 18, 2006 [Page 12] Internet-Draft Applying SigComp to SIP February 2006 at (0) :udvm_memory_size pad (2) :cycles_per_bit pad (2) :sigcomp_version pad (2) :partial_state_id_length pad (2) :state_length pad (2) :reserved pad (2) at (64) :byte_copy_left pad (2) :byte_copy_right pad (2) :input_bit_order pad (2) :stack_location pad (2) ; Simple loop ; Read a byte ; Output a byte ; Until there are no more bytes! at (128) :start INPUT-BYTES (1, byte_copy_left, end) OUTPUT (byte_copy_left, 1) JUMP (start) :end END-MESSAGE (0,0,0,0,0,0,0) which translates to give the following initial 13 bytes of the SigComp message (in hexadecimal): f8 00 a1 1c 01 86 09 22 86 01 16 f9 23 As an implementation optimization, a SigComp implementation MAY compare the initial 13 bytes of each incoming message with the 13 bytes given (the "well-known shim header"), and, in case of a match, simply copy the SigComp message data that follow the shim header without even setting up a UDVM. (Note that, before a SigComp message is formed from the incoming TCP data, the record marking protocol defined in section 4.2.2 of [RFC3320] has to be performed.) To obtain the maximum benefit from this optimization, compressors SHOULD employ exactly the well-known shim header given (and none of the other conceivable byte code sequences for just copying input to output) to send uncompressed data in a SigComp channel. Bormann, et al. Expires August 18, 2006 [Page 13] Internet-Draft Applying SigComp to SIP February 2006 Authors' Addresses Carsten Bormann (editor) Universitaet Bremen TZI Postfach 330440 Bremen D-28334 Germany Phone: +49 421 218 7024 Fax: +49 421 218 7000 Email: cabo@tzi.org Zhigang Liu Nokia Research Center 6000 Connection Drive Irving, TX 75039 USA Phone: +1 972 894-5935 Email: zhigang.c.liu@nokia.com Richard Price Cogent Defence and Security Networks Queensway Meadows Industrial Estate Meadows Road Newport, Gwent NP19 4SS Phone: +44 (0)1794 833681 Email: richard.price@cogent-dsn.com URI: http://www.cogent-dsn.com Gonzalo Camarillo Ericsson Hirsalantie 11 Jorvas 02420 Finland Email: Gonzalo.Camarillo@ericsson.com Bormann, et al. Expires August 18, 2006 [Page 14] Internet-Draft Applying SigComp to SIP February 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. Bormann, et al. Expires August 18, 2006 [Page 15]