Network Working Group Q. Xie Internet-Draft Motorola Expires: July 8, 2006 R. Kapoor Qualcomm January 4, 2006 Enhancements to RTP Format for EVRC Family Codecs draft-ietf-avt-compact-bundled-evrc-00.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 July 8, 2006. Copyright Notice Copyright (C) The Internet Society (2006). Abstract This document defines several enhancements and extensions to RFC3558 EVRC RTP payload format. In particular, it defines the support for a compact bundled format and EVRC-B codec, as well as discontinuous transmission (DTX) support for EVRC and EVRC-B encoded speech transported via RTP sessions. Some VoIP applications, such as Push- to-Talk and VoIP over low bandwidth dial-up and wireless networks, require such enhancements for efficient use of the bandwidth. Xie & Kapoor Expires July 8, 2006 [Page 1] Internet-Draft EVRC RTP Format Enhancements January 2006 Table of Contents 1. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2.1 Support of EVRC-B Codec . . . . . . . . . . . . . . . . . 3 2.2 Compact (Header-free) Bundled Format . . . . . . . . . . . 3 2.3 Discontinuous Transmission (DTX) . . . . . . . . . . . . . 4 3. EVRC-B Codec . . . . . . . . . . . . . . . . . . . . . . . . . 5 4. Compact Bundled Format . . . . . . . . . . . . . . . . . . . . 5 4.1 Single Rate Operation . . . . . . . . . . . . . . . . . . 5 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 5.1 Registration of Media Type EVRCB . . . . . . . . . . . . . 6 5.2 Registration of Media Type EVRC1 . . . . . . . . . . . . . 7 5.3 Registration of Media Type EVRCB1 . . . . . . . . . . . . 8 5.4 Payload Format Parameters for DTX . . . . . . . . . . . . 9 5.5 Mapping MIME Parameters into SDP . . . . . . . . . . . . . 11 5.6 Usage in Offer/Answer . . . . . . . . . . . . . . . . . . 12 6. Security Considerations . . . . . . . . . . . . . . . . . . . 12 7. Changes from Last Revision . . . . . . . . . . . . . . . . . . 12 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 8.1 Normative References . . . . . . . . . . . . . . . . . . . 13 8.2 Informative References . . . . . . . . . . . . . . . . . . 13 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 14 Intellectual Property and Copyright Statements . . . . . . . . 15 Xie & Kapoor Expires July 8, 2006 [Page 2] Internet-Draft EVRC RTP Format Enhancements January 2006 1. Conventions The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, NOT RECOMMENDED, MAY, and OPTIONAL, when they appear in this document, are to be interpreted as described in [2]. 2. Introduction This document defines the RTP payload format for EVRC-B, a complementing compact bundled format for EVRC and EVRC-B, and updates to RFC3558 [5] formats with discontinuous transmission (DTX) support. Some VoIP applications, such as Push-to-Talk and VoIP over low bandwidth dial-up and wireless networks, require such EVRC RTP payload capabilities for efficient use of the bandwidth. 2.1 Support of EVRC-B Codec EVRC-B [4] is an extension to [3] developed in 3GPP2. EVRC-B [4] compresses each 20 milliseconds of 16-bit sampled speech input into output frames of one of the four different sizes: Rate 1 (171 bits), Rate 1/2 (80 bits), Rate 1/4 (40 bits), or Rate 1/8 (16 bits). In addition, there are two zero bit codec frame types: null frames and erasure frames, similar to EVRC [3]. One significant enhancement in EVRC-B is that there are Rate 1/4 frames that were not used in EVRC. This provides lower average data rates (ADRs) compared to EVRC, for a given voice quality. Since EVRC-B encoded speech frames are different from those of EVRC, EVRC-B and EVRC codecs do not interoperate with each other. At the initiation of a RTP session, the RTP sender and receiver need to indicate (e.g., using MIME subtypes that are separate from those of EVRC) that EVRC-B is to be used for the ensuing session. 2.2 Compact (Header-free) Bundled Format The current interleaved/bundled packet format defined in RFC 3558 allows bundling of multiple speech frames of different rate in a single RTP packet, sending rate change request, and interleaving. To support these functions, a Table of Content (ToC) is used in each RTP packet in addition to the standard RTP header. The size of the ToC is variable, depending on the number of EVRC frames carried in the packet [5]. The current header-free packet format defined in RFC 3558 is more compact and optimized for use over wireless links. It eliminates the need for a ToC by requiring that each RTP packet contains only one speech frame (of any allowable rate), i.e., bundling is not allowed. Xie & Kapoor Expires July 8, 2006 [Page 3] Internet-Draft EVRC RTP Format Enhancements January 2006 Moreover, interleaving and rate change request are not supported in the header-free format [5]. Since the biggest EVRC/EVRC-B speech frame is 171 bits (full rate), it is therefore very inefficient in terms of bandwidth utilization to send EVRC/EVRC-B speech frames one at a time over RTP/UDP/IP, as being required by the header-free format. It is assumed that this shortcoming of the header-free format will be overcome or at least greatly alleviated in practice by the use of RTP/UDP/IP header compression or removal techniques such as ROHC [9]. However, in many wireless systems such as 3GPP and 3GPP2, header compression is only applied between the mobile station and the radio access network. ROHC is not an end-to-end compression scheme, there will be many hops between the EVRC/EVRC-B sender and the EVRC/EVRC-B receiver where such overheads may be an issue. As speech will be carried one speech frame per RTP packet with full RTP/UDP/IP headers, it would result in very poor bandwidth utilization in that part of the network. The compact bundled format described in this document presents the user an alternative to the header-free format defined in RFC 3558. The compact bundled format is wireless-friendly since it does not use a ToC. It also allows bundling of multiple EVRC or EVRC-B frames and will not create bandwidth inefficiency problems in the network. However, to use this compact bundled format the compromise one has to make is that only one EVRC/EVRC-B rate (full rate or 1/2 rate) can be used in the session. Similar to the header-free format defined in RFC 3558, interleaving and rate change request are not supported in the compact bundled format. [Editor's note: it may be worthwhile to consider an alternate to the above single rate operation - defining 2 payload formats (EVRC1-Full and EVRC1-Half) and allow rate switching on a packet-to-packet basis. If rate switching is undesirable, the endpoints could always limit the session to one rate at the setup via SDP signaling.] 2.3 Discontinuous Transmission (DTX) Originally, EVRC codec did not provide DTX support; in variable rate operation mode the encoder sends 1/8 rate frames during periods of silence, while in single rate operation mode (see 4.1 ???), silence is encoded and sent in silence frames of the same rate as that of speech frames. Silence or 1/8 rate frames of EVRC and EVRC-B codecs vary little during periods of silence. The transmission of these 1/8 rate frames (or silence frames in the single rate operation mode) across the Xie & Kapoor Expires July 8, 2006 [Page 4] Internet-Draft EVRC RTP Format Enhancements January 2006 radio interface in a wireless system is expensive in terms of capacity, and therefore, suppression of these frames is desirable. Suppression of silence frames is accomplished using DTX. When DTX is applied, the first few 1/8 rate frames (or silence frames in the single rate operation mode) are transmitted to establish background noise during the period of silence. Then a portion of the stream of subsequent 1/8 rate frames (or silence frames in the single rate operation mode) are not transmitted and discarded at the encoder. At the receiver, background or comfort noise should be created by using the previously received 1/8th rate frames (or silence frames in the single rate operation mode). 3. EVRC-B Codec Two RTP modes are supported for EVRC-B codec - the interleaved/ bundled packet format and compact bundled packet format. For the interleaved/bundled packet format, the operational details and capabilities, such as ToC, interleaving, and bundling, of EVRC-B are exactly the same as those of EVRC, as defined in RFC3558 [5]. The compact bundled packet format for EVRC-B is defined in Section 4 of this document. 4. Compact Bundled Format A packet in the compact bundled format consists of an RTP header followed by a sequence of one or more consecutive EVRC/EVRC-B codec data frames of the same rate, as shown below: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | RTP Header [4] | +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ | | | One or more EVRC/EVRC-B data frames of same rate | | .... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The vocoder date frames MUST be generated from the output of the vocoder following the procedure described in 5.2 in RFC 3558 [5] and they all MUST be of the same rate and size. 4.1 Single Rate Operation As mentioned earlier, to use the compact bundled format, all the EVRC/EVRC-B data frames in the session MUST be of the same rate (either 1 or 1/2 rate). To some VoIP applications, such as Push-to- Xie & Kapoor Expires July 8, 2006 [Page 5] Internet-Draft EVRC RTP Format Enhancements January 2006 Talk over cellular, this is not viewed as much of a limitation due to their unique communication style where rate changes in a session are often difficult and sometimes even undesirable. For a session that uses the compact bundled format, the rate for the session can be determined during the session setup signaling, for example, via SDP exchanges. See Section 5 below for more details. 5. IANA Considerations Three (3) new MIME subtype registration are required for the EVRC-B support and compact bundled format payload types, and four (4) optional parameters - "silencesupp", "dtxmax", "dtxmin", and "hangover" - are defined and used in DTX, as described below. 5.1 Registration of Media Type EVRCB MIME media type name: audio MIME subtype names: EVRCB Required parameters: none Optional parameters: see RFC 3558 [5]. Encoding considerations: This media type is defined for transfer of EVRC-B encoded data via RTP using the Interleaved/Bundled packet format specified in RFC 3558 [5] and RFC XXXX. Security considerations: See Section 6 of RFC XXXX. Interoperability considerations: none Published specification: The EVRC-B vocoder is specified in 3GPP2 C.S0014-B [4]. Transfer method with Interleaved/Bundled packet format via RTP is specified in RFC 3558 and RFC XXXX. Applications which use this media type: It is expected that many VoIP applications (as well as mobile applications) will use this type. Additional information: none Person & email address to contact for further information: Qiaobing.Xie@motorola.com Xie & Kapoor Expires July 8, 2006 [Page 6] Internet-Draft EVRC RTP Format Enhancements January 2006 Intended usage: COMMON Restrictions on usage: This type is only defined for transfer via RTP [6]. Author: Qiaobing Xie Change controller: IETF Audio/Video Transport working group delegated from the IESG. 5.2 Registration of Media Type EVRC1 MIME media type name: audio MIME subtype names: EVRC1 Required parameters: none Optional parameters: ptime: see RFC 2327 [8]. maxptime: The maximum amount of media which can be encapsulated in each packet, expressed as time in milliseconds. The time SHALL be calculated as the sum of the time the media present in the packet represents. The time SHOULD be a multiple of the duration of a single codec data frame (20 msec). If not signaled, the default maxptime value SHALL be 200 milliseconds. evrcfixedrate: Indicates the EVRC rate of the session while in single rate operation. Valid values include: 0.5 and 1, where a value of 0.5 indicates the 1/2 rate while a value of 1 indicates the full rate. If this parameter is not present, 1/2 rate is assumed. Encoding considerations: These types are defined for transfer of EVRC encoded data via RTP using the compact bundled format as described in RFC XXXX. Security considerations: See Section 6 of RFC XXXX. Published specification: The EVRC vocoder is specified in 3GPP2 C.S0014. Transfer method with compact bundled RTP format is specified in RFC XXXX. Xie & Kapoor Expires July 8, 2006 [Page 7] Internet-Draft EVRC RTP Format Enhancements January 2006 Applications which use this media type: It is expected that many VoIP applications (as well as mobile applications) will use this type. Additional information: none Person & email address to contact for further information: Qiaobing.Xie@motorola.com Intended usage: COMMON Restrictions on usage: This type is only defined for transfer via RTP [6]. Author: Qiaobing Xie Change controller: IETF Audio/Video Transport working group delegated from the IESG. 5.3 Registration of Media Type EVRCB1 MIME media type name: audio MIME subtype names: EVRCB1 Required parameters: none Optional parameters: ptime: see RFC 2327 [8]. maxptime: The maximum amount of media which can be encapsulated in each packet, expressed as time in milliseconds. The time SHALL be calculated as the sum of the time the media present in the packet represents. The time SHOULD be a multiple of the duration of a single codec data frame (20 msec). If not signaled, the default maxptime value SHALL be 200 milliseconds. evrcfixedrate: Indicates the EVRC-B rate of the session while in single rate operation. Valid values include: 0.5 and 1, where a value of 0.5 indicates the 1/2 rate while a value of 1 indicates the full rate. If this parameter is not present, 1/2 rate is assumed. Encoding considerations: These types are defined for transfer of EVRC-B encoded data via RTP using the compact bundled format as described in RFC XXXX. Xie & Kapoor Expires July 8, 2006 [Page 8] Internet-Draft EVRC RTP Format Enhancements January 2006 Security considerations: See Section 6 of RFC XXXX. Published specification: The EVRC-B vocoder is specified in 3GPP2 C.S0014-B. Transfer method with compact bundled RTP format is specified in RFC XXXX. Applications which use this media type: It is expected that many VoIP applications (as well as mobile applications) will use this type. Additional information: none Person & email address to contact for further information: Qiaobing.Xie@motorola.com Intended usage: COMMON Restrictions on usage: This type is only defined for transfer via RTP [6]. Author: Qiaobing Xie Change controller: IETF Audio/Video Transport working group delegated from the IESG. 5.4 Payload Format Parameters for DTX For all the EVRC and EVRC-B RTP payload formats defined in RFC 3558 [5] and RFC XXXX, four additional optional parameters - "silencesupp", "dtxmax", "dtxmin", and "hangover" - are defined and used in DTX, as described below. silencesupp: Permissible values are 0 and 1. A value of 1 indicates that the sender of this parameter is capable of and desires to support silence suppression using DTX. A value of 0 indicates that the sender of this parameter is either incapable or unwilling to use silence suppression using DTX. An RTP receiver may use this parameter to declare its ability and desire to support silence suppression using DTX. If this parameter is not present, the default value MUST be assumed. [Editor's note: Default value is 1 and will be specified in a 3GPP2 TSG-C 1.1 document. Furthermore, the backward compatibility issue with this default value is studied and understood by 3GPP2 TSG-C 1.1.] If the RTP receiver indicates that it is incapable of or unwilling to use silence suppression using DTX at the beginning of a Xie & Kapoor Expires July 8, 2006 [Page 9] Internet-Draft EVRC RTP Format Enhancements January 2006 session, silence suppression using DTX MUST NOT be used for the session. dtxmax: indicates the maximum DTX update interval in number of frames. During DTX, the RTP sender occasionally updates the RTP receiver about the change in background noise characteristics, etc., by sending a new 1/8 rate frame (or silence frame in the single rate operation mode) to the RTP receiver. The RTP receiver may use 'dtxmax' to indicate to the RTP sender the maximum interval (in number of frames) between any two DTX updates it expects to receive from the RTP sender. If this parameter is not present in a session that uses DTX, the default value MUST be assumed. [Editor's note: Default value is 50 and will be specified in a 3GPP2 TSG-C 1.1 document]. This parameter MUST be ignored if silence suppression using DTX is not used for the session. dtxmin: indicates the minimum DTX update interval in number of frames. The RTP receiver may use 'dtxmin' to indicate to the RTP sender the minimal interval (in number of frames) between any two DTX updates it expects to receive from the RTP sender. If this parameter is not present, the default value MUST be assumed. [Editor's note: Default value is 8 and will be specified in a 3GPP2 TSG-C 1.1 document.] This parameter MUST be ignored if silence suppression using DTX is not used for the session. hangover: indicates the number of 1/8 rate frames (or silence frames in the single rate operation mode) transmitted at the end of active speech but before DTX actions begin. When setting up an RTP session that uses DTX, an RTP receiver can use this parameter to signal the number of 1/8 rate frames (or silence frames in the single rate operation mode) that SHOULD be transmitted by the RTP sender prior to beginning DTX actions. Note, the RTP sender SHOULD always follow the hangover specified by the RTP receiver. While hangover=0 is allowed, it is RECOMMENDED that hangover be set to 1 or greater since the presence of 1/8th rate frames (or silence frames in the single rate operation mode) at the end of active speech can help the RTP receiver to identify the beginning of the DTX period. If this parameter is not present for a session that uses DTX, the default value MUST be assumed. Xie & Kapoor Expires July 8, 2006 [Page 10] Internet-Draft EVRC RTP Format Enhancements January 2006 [Editor's note: Default value is 1 and will be specified in a 3GPP2 TSG-C 1.1 document.] This parameter MUST be ignored if silence suppression using DTX is not used for the session. 5.5 Mapping MIME Parameters into SDP The information carried in the MIME media type specification has a specific mapping to fields in the Session Description Protocol (SDP) [8], which is commonly used to describe RTP sessions. When SDP is used to specify sessions employing the compact bundled format for EVRC/EVRC-B encoded speech, the mapping is as follows: o The MIME type ("audio") goes in SDP "m=" as the media name. o The MIME subtype ("EVRCB", "EVRC1", or "EVRCB1") goes in SDP "a=rtpmap" as the encoding name. o The optional parameters "ptime" and "maxptime" go in the SDP "a=ptime" and "a=maxptime" attributes, respectively. o The optional parameter "evrcfixedrate" (for subtypes EVRC1 and EVRCB1) goes in "a=fmtp" attribute by copying it directly from the MIME media type string as "evrcfixedrate=value". o The optional parameters "silencesupp", "dtxmax", "dtxmin", and "hangover" go in "a=fmtp" attribute by copying it directly from the MIME media type string as "silencesupp=value", "dtxmax=value", "dtxmin=value", and "hangover=value", respectively. Example of usage of EVRCB: m=audio 49120 RTP/AVP 97 a=rtpmap:97 EVRCB/8000 a=maxptime:120 Example of usage of EVRC1: m=audio 49120 RTP/AVP 97 a=rtpmap:97 EVRC1/8000 a=fmtp:97 evrcfixedrate=0.5 a=maxptime:120 Example of usage of EVRCB1: Xie & Kapoor Expires July 8, 2006 [Page 11] Internet-Draft EVRC RTP Format Enhancements January 2006 m=audio 49120 RTP/AVP 97 a=rtpmap:97 EVRCB1/8000 a=fmtp:97 evrcfixedrate=0.25 a=maxptime:100 Example of usage of EVRC1 with DTX: m=audio 49120 RTP/AVP 97 a=rtpmap:97 EVRC1/8000 a=fmtp:97 evrcfixedrate=0.5 a=fmtp:97 silencesupp=1 dtxmax=50 dtxmin=8 hangover=2 a=maxptime:120 5.6 Usage in Offer/Answer All SDP parameters in this payload format are declarative, and all reasonable values are expected to be supported. Thus, the standard usage of Offer/Answer as described in RFC 3264 [7] should be followed. 6. Security Considerations Implementations using the payload defined in this specification are subject to the security considerations discussed in RFC 3558 [5], RFC 3550 [6], and any appropriate profile (for example RFC3551 [10]). This payload does not specify any different security services. 7. Changes from Last Revision (This section is temporary and will be removed when the work on the draft finishes) - updated MIME definition text to follow new template/rules - separate MIME subtypes EVRC1 and EVRCB1 into two subsections - added ref to RFC3558 in security consideration sections - clarification that silencesupp is an RTP receiver declaration - some editorial changes per Magnus's comments - re-defined 'dtxmax' and 'dtxmin' as "update intervals" - revised the wording of DTX parameter definitions, including clarification to the hangover usage - removed the old RTP marker bit usage section. 8. References Xie & Kapoor Expires July 8, 2006 [Page 12] Internet-Draft EVRC RTP Format Enhancements January 2006 8.1 Normative References [1] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996. [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [3] "Enhanced Variable Rate Codec, Speech Service Option 3 for Wideband Spread Spectrum Digital Systems", 3GPP2 C.S0014, January 1997. [4] "Enhanced Variable Rate Codec, Speech Service Option XX for Wideband Spread Spectrum Digital Systems", 3GPP2 C.S0014-B, in progress. [5] Li, A., "RTP Payload Format for Enhanced Variable Rate Codecs (EVRC) and Selectable Mode Vocoders (SMV)", RFC 3558, July 2003. [6] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", RFC 3550, July 2003. [7] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with the Session Description Protocol (SDP)", RFC 3264, June 2002. [8] Handley, M. and V. Jacobson, "SDP: Session Description Protocol", RFC 2327, April 1998. 8.2 Informative References [9] Bormann, C., "RObust Header Compression (ROHC): Framework and four profiles: RTP, UDP, ESP, and uncompressed", RFC 3095, July 2001. [10] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and Video Conferences with Minimal Control", RFC 3551, July 2003. Xie & Kapoor Expires July 8, 2006 [Page 13] Internet-Draft EVRC RTP Format Enhancements January 2006 Authors' Addresses Qiaobing Xie Motorola, Inc. 1501 W. Shure Drive, 2-F9 Arlington Heights, IL 60004 US Phone: +1-847-632-3028 Email: qxie1@email.mot.com Rohit Kapoor Qualcomm Inc. US Phone: +1-858-845-1161 Email: rkapoor@qualcomm.com Xie & Kapoor Expires July 8, 2006 [Page 14] Internet-Draft EVRC RTP Format Enhancements January 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. Xie & Kapoor Expires July 8, 2006 [Page 15]