Network Working Group R. Price Internet-Draft R. Hancock Expires: August 23, 2002 S. McCann A. Surtees P. Ollis M. West Siemens/Roke Manor February 22, 2002 Enhanced TCP/IP Compression for ROHC draft-price-rohc-epic-03.txt Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. 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 23, 2002. Copyright Notice Copyright (C) The Internet Society (2002). All Rights Reserved. Abstract This draft describes an optional enhancement to the ROHC profile specified in EPIC-LITE [2] for the robust compression of protocol headers. The RObust Header Compression (ROHC) [1] scheme is designed to compress packet headers over error prone channels. It is built around an extensible core framework that can be tailored to compress Price, et al. Expires August 23, 2002 [Page 1] Internet-Draft Enhanced TCP/IP Compression for ROHC February 2002 new protocol stacks by adding additional ROHC profiles. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Differences between EPIC and EPIC-lite . . . . . . . . . . . . 3 4. Worked example . . . . . . . . . . . . . . . . . . . . . . . . 4 5. Changes required to implement EPIC . . . . . . . . . . . . . . 6 6. Statement of optimal efficiency . . . . . . . . . . . . . . . 16 7. Security Considerations . . . . . . . . . . . . . . . . . . . 16 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 17 9. Intellectual Property Considerations . . . . . . . . . . . . . 17 References . . . . . . . . . . . . . . . . . . . . . . . . . . 17 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 18 Full Copyright Statement . . . . . . . . . . . . . . . . . . . 20 Revision history -03: Pseudo-code updated to reflect latest version of EPIC-lite framework -02: Revised pseudo-code -01: Document split into two Internet Drafts: for the basic TCP/IP profile for an enhanced TCP/IP profile Major updates to every section: Pseudocode added for all parts of the scheme Language added for the succinct description of new ROHC profiles Support for IR and IR-DYN packets included Finite state machine adapted from ROHC RTP ROHC profile for compression of TCP/IP updated -00: Document created for robust compression of TCP/IP Price, et al. Expires August 23, 2002 [Page 2] Internet-Draft Enhanced TCP/IP Compression for ROHC February 2002 1. Introduction This document describes an enhanced method for compressing headers within the ROHC [1] framework. A companion draft EPIC-lite [2] describes a version of EPIC known as EPIC-lite. This draft describes the delta changes required to implement EPIC itself. The difference between the two schemes is that EPIC has a higher compression ratio than EPIC-lite. In fact, in a well-defined sense the compressed headers produced by EPIC are optimally efficient: i.e. the compression ratio achieved by EPIC is provably the maximum possible for the chosen level of robustness. 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 RFC-2119 [7]. 3. Differences between EPIC and EPIC-lite In general the EPIC and EPIC-lite schemes are very similar. Both share the same input language for creating new ROHC profiles, and both employ the same library of encoding methods. The only difference lies in the way the value of each compressed field is communicated to the decompressor. As stated in EPIC-lite [2] each compressed header generated by the EPIC-lite scheme is divided into two distinct parts: the indicator flags and the compressed fields. This situation is illustrated below: +---+---+---+---+--------------------+--------------------+--- | 0 | 1 | 1 | 0 | Compressed Field 1 | Compressed Field 2 |... +---+---+---+---+--------------------+--------------------+--- \ \ / / \ / \ \ / / \ / Indicator Flags Compressed Fields Figure 1 : Structure of an EPIC-lite compressed header The indicator flags specify which compressed fields are present in the header, whilst the compressed fields contain enough information to transmit each field from the compressor to the decompressor. Price, et al. Expires August 23, 2002 [Page 3] Internet-Draft Enhanced TCP/IP Compression for ROHC February 2002 In contrast, the headers generated by the full EPIC scheme do not distinguish between compressed headers and indicator flags: +--------------------+--------------------+--- | Compressed Field 1 | Compressed Field 2 |... +--------------------+--------------------+--- Figure 2 : Structure of an EPIC compressed header Rather than prefix the compressed header with explicit indicator flags, EPIC reserves certain bit patterns in each compressed field to indicate whether or not further compressed fields follow. This approach is very efficient because the probability that further compressed fields are needed may be low, in which case only a few bit patterns need be reserved to indicate their presence. 4. Worked example The key difference between EPIC and EPIC-lite can be illustrated effectively by a worked example. Suppose that the schemes are used to compress TCP/IP headers, and for simplicity assume that there is only one context and no robustness (i.e. no context identifier, no CRC checksum and no sequence number in the compressed packet). The only information required in every compressed header is the TCP Checksum, which must be passed through untouched to preserve end-to- end integrity. If this were the only information that needed to be sent, it can be seen that EPIC-lite could compress a header down to a minimum of 3 octets as shown below: Price, et al. Expires August 23, 2002 [Page 4] Internet-Draft Enhanced TCP/IP Compression for ROHC February 2002 +---+---+---+---+---+---+---+---+ | 0 X X X X X X X | +---+---+---+---+---+---+---+---+ | | + TCP Checksum + Base headers | | +---+---+---+---+---+---+---+---+ +---+---+---+---+---+---+---+---+ | 1 X X X X X X X | +---+---+---+---+---+---+---+---+ | | + TCP Checksum + | | Extension headers +---+---+---+---+---+---+---+---+ : : / Extension Fields / : : +---+---+---+---+---+---+---+---+ Figure 3 : Compressed TCP/IP headers using EPIC-lite The base headers contain 2 octets for the TCP Checksum, plus an additional octet to hold an indicator flag to distinguish between base headers and extension headers. The remaining bits in the first octet are not needed, although they can be filled with sequence number or CRC to improve robustness if desired. In contrast, EPIC only requires 2 octets for the majority of the base headers. The TCP Checksum values 0x0000 through to 0xDFDF inclusive are carried using 2 octets as shown below: +---+---+---+---+---+---+---+---+ | 0 0 0 0 0 0 0 0 | Base header +---+---+---+---+---+---+---+---+ | 0 0 0 0 0 0 0 0 | (Checksum value 0x0000) +---+---+---+---+---+---+---+---+ : : : : : : +---+---+---+---+---+---+---+---+ | 1 1 0 1 1 1 1 1 | Base header +---+---+---+---+---+---+---+---+ | 1 1 0 1 1 1 1 0 | (Checksum value 0xDFDF) +---+---+---+---+---+---+---+---+ The remaining checksum values 0xDFE0 through to 0xFFFF must be Price, et al. Expires August 23, 2002 [Page 5] Internet-Draft Enhanced TCP/IP Compression for ROHC February 2002 carried using 3 octets as illustrated below: +---+---+---+---+---+---+---+---+ | 1 1 0 1 1 1 1 1 | +---+---+---+---+---+---+---+---+ Base header | 1 1 0 1 1 1 1 1 | +---+---+---+---+---+---+---+---+ (Checksum value 0xDFE0) | 0 0 0 0 0 0 0 0 | +---+---+---+---+---+---+---+---+ : : : : : : +---+---+---+---+---+---+---+---+ | 1 1 0 1 1 1 1 1 | +---+---+---+---+---+---+---+---+ Base header | 1 1 1 1 1 1 1 1 | +---+---+---+---+---+---+---+---+ (Checksum value 0xFFFF) | 0 0 1 0 0 0 0 0 | +---+---+---+---+---+---+---+---+ Finally, the remaining bit patterns are reserved for extension headers and for the ROHC framework: +---+---+---+---+---+---+---+---+ | 1 1 0 1 1 1 1 1 | +---+---+---+---+---+---+---+---+ | 1 1 1 1 1 1 1 1 | +---+---+---+---+---+---+---+---+ | 0 0 1 0 0 0 0 1 | Extension headers +---+---+---+---+---+---+---+---+ : : / Extension Fields / : : +---+---+---+---+---+---+---+---+ Figure 4 : Compressed TCP/IP headers using EPIC Note that the exact structure of the compressed headers for both schemes depends on the input code defined in Section 4 of EPIC-lite [2]. 5. Changes required to implement EPIC This chapter describes the delta changes to EPIC-lite [2] required to implement the full version of EPIC. The largest change is to the offline processing section (Appendix A.3) which is a new BUILD-FLAGS Price, et al. Expires August 23, 2002 [Page 6] Internet-Draft Enhanced TCP/IP Compression for ROHC February 2002 procedure. There also needs to be a new INDICATOR-FLAGS and a new READ-FLAGS procedure but these are simpler than the ones in EPIC-lite [2]. The new version of the BUILD-FLAGS procedure uses the following variables: bit_alignment bit_alignment is a variable specified in each profile which is used to ensure headers are a multiple of a specific number of bits long. This variable can be any integer of 0 or greater. npatterns npatterns is another variable specified in the profile. It is used to make sure that the bit pattern '111' is not used by the indicator flags for the CO_packet for compatability with ROHC Each Node also described as list_item in EPIC-lite of the Huffman Tree has the following parts: P Probability that each compressed header format will occur (Identical to EPIC LITE) Num The number of headers which will have the format (each with equal probability). listpointer1/2/3 Indicates a parent of the current node Numpoint3 This indicates the number of headers which follow listpointer3 when the Node splits. Numpoint2 This indicates the number of headers which follow listpointer2 when the Node splits. The new version of the procedure is given below: Price, et al. Expires August 23, 2002 [Page 7] Internet-Draft Enhanced TCP/IP Compression for ROHC February 2002 procedure BUILD-FLAGS (main_list, do_reserve) var work_list var u, # Pointer to main_list. v, # Pointer to work_list which is created within this # procedure w, # Indicator to empty part of "v" part oflist. base, # Indicator to smallest P which can be in the # "v" or "w" part of the list. z # var flag_list # has elements length, N, flags var length_list # has elements length, num var scratch_list # has elements length, num, point var i, flag, value, prev_length, num_formats, total_n, extra_n, mod_value # From EPIC-lite each entry in the list has a probabibility P, a format id # and a number of bits it represents N. N can express 2^N headers each of # which would have probability P/(2^N). This EPIC procedure works with the # total number of headers and their probibilities so work these out for # each element in the list. for each item in main_list item.num = 2^item.N item.P = item.P / item.num total_n = total_n + item.num end loop sort-natural (main_list, COMPARE) # work out whether another item with probability 0 needs to be added to # the list to ensure the indicator flags don't use the bit pattern '111' # if in CO state. if compressor_state = "CO" mod_value = (2^bit_alignment) - 1 total_n = total_n mod mod_value extra_n = (npatterns + mod_value - total_n) mod mod_value if extra_n <> 0 then # make sure main_list has max_formats - 1 elements as one more # will be added DISCARD (main_list, max_formats - 1) # add an extra element with probability zero Price, et al. Expires August 23, 2002 [Page 8] Internet-Draft Enhanced TCP/IP Compression for ROHC February 2002 item.num = extra_n item.P = 0 prepend (main_list, item) else DISCARD (main_list, max_formats) endif else DISCARD (main_list, max_formats) endif empty (work_list) num_formats = size-of (main-list) u = head-of(main_list) v = head-of(work_list) first_loop = 1 # the work_list starts empty, so v is 'null'. However, as soon as # the first item is added to the work list, v references this item, # which is why there is a condition & re-initialisation of v at the # bottom of the loop #--------Build the list ------------------------------- while (not at-end(u)) and (not at-end(v)) # --- Find the smallest value and decide if it is # in main_list or work_list and set start values if (at-end(v) or ( not at-end (u) and (u.P <= v.P))) then chosen = 0 base = u else chosen = 1 base = v endif if base.Num mod (2^bit_alignment) = 0 then # X operation in Huffman branch append(work_list,w) Price, et al. Expires August 23, 2002 [Page 9] Internet-Draft Enhanced TCP/IP Compression for ROHC February 2002 w.P = base.P * (2^bit_alignment) w.Num = base.Num / (2^bit_alignment) base.listpointer1 = w if chosen = 0 then u = next-item(u) else v = next-item(v) endif else if base.Num > 2^bit_alignment then # D followed by X operation in branch append(work_list,w) w.P = base.P * (2^bit_alignment) w.Num = base.Num / (2^bit_alignment) # Modify original entry in list base.Num = base.Num mod (2^bit_alignment) base.listpointer1 = w else # Join Nodes operation # First of all put base.Num into new node # then find next smallest node and add that in - # keep going till w.Num >= 2^bit_alignment append(work_list,w) while (w.Num < 2^bit_alignment) w.P = w.P + base.P * base.Num w.Num = w.Num + base.Num base.listpointer2 = w if (w.Num < 2^bit_alignment) base.Numpoint2 = base.Num endif if chosen = 0 then u = next-item(u) else v = next-item(v) endif Price, et al. Expires August 23, 2002 [Page 10] Internet-Draft Enhanced TCP/IP Compression for ROHC February 2002 # Find next smallest if (at-end(v) or ( not at-end (u) and (u.P <= v.P))) then chosen = 0 base = u else chosen = 1 base = v endif end while if (w.Num = (2^bit_alignment)) then # Joining of nodes gives exactly Num = 2^bit_alignment # so no modification of base node needed base.listpointer2 = w base.Numpoint2 = base.Num if chosen = 0 then u = next-item(u) else v = next-item(v) endif else # Joining of nodes gave Num > 2^bit_alignment # so modify base node to have remaing Num base.listpointer3 = w base.Numpoint3 =(2^bit_alignment)- w.Num + base.Num base.Num = w.Num - (2^bit_alignment) endif endif if first_loop = 1 then v = head_of (work_list) first_loop = 0 endif end while #--------Calculate lengths------------------------- Price, et al. Expires August 23, 2002 [Page 11] Internet-Draft Enhanced TCP/IP Compression for ROHC February 2002 cumulative_N = 0 empty (flag_list) # Go through original list from the largest P for each w in reverse main_list empty (length_list) empty (scratch_list) this_N = w.num # follow the listpointer1 route taking all listpointer1's # that are set and storing the information in listpointers # 2 and 3 in a scratchpad list to come back to (this includes # the final element where listpointer1 is no longer set). z = w length = 0 Xcount = 0 while (z <> NULL) if (listpointer2 <> null) then scratch_new.length = length + 1 scratch_new.num = z.numpoint2 * 2^(bit_alignment * xcount) scratch_new.point = listpointer2 this_num = this_num - scratch_new.num append (scratch_list, scratch_new) endif if (listpointer3 <> null) then scratch_new.length = length + 1 scratch_new.num = z.numpoint3 * 2^(bit_alignment * xcount) scratch_new.point = listpointer3 this_num = this_num - scratch_new.num append (scratch_list, scratch_new) endif Xcount = Xcount + 1 length = length + 1 z = z.listpointer1 end while Price, et al. Expires August 23, 2002 [Page 12] Internet-Draft Enhanced TCP/IP Compression for ROHC February 2002 # Work through the scratch list to find the length to # the root of the tree. Store in a length_list. # The length_list should automatically end up in ascending # order of lengths. for each scratch_p in scratch_list length = scratch_p.length z = scratch_p.point while (z.listpointer2 <> NULL) or (z.listpointer3 <> NULL)) length = length + 1 if (z.listpointer2 <> NULL) then z = z.listpointer2 else if z.listpointer3 <> NULL) z = z.listpointer3 end while length_elt = head-of (length_list) found_same_length = 0 while (length_elt <> NULL and found_same_length = 0) if length_elt.length = length then found_same_length = 1 endif end while if found_same_length = 0 then length_elt.num = scratch_p.num length_elt.length = length append (length_list, length_elt) else length_elt.num = length_elt.num + scratch_p.num endif end loop # Combine this length_list into the overall flag_list # (which will again be in ascending order of lengths) for each length_elt in length_list cumulative_N = cumulative_N + length_elt.num append (w.length_list, length_elt.length) append (cum_N_list, cumulative_N) found_same_length = 0 fl_elt = head-of (flag_list) Price, et al. Expires August 23, 2002 [Page 13] Internet-Draft Enhanced TCP/IP Compression for ROHC February 2002 while (fl_elt <> NULL and found_same_length = 0) if fl_elt_length = length_elt.length then found_same_length = 1 endif end while if found_same_length = 0 then fl_elt.N = cumulative_N fl_elt.length = length_elt.length append (flag_list, fl_elt) else fl_elt.N = fl_elt.N + length_elt.num endif end loop end loop #--------Generate Huffman flags------------------- flag_item.N = 0 flag_item.length = 0 flag_item.flags = 0 prepend(flag_list,flag_item) fl_3 = head-of (flag_list) fl_2 = next-item (fl_3) fl_2.flags = str(fl_2.length,0) fl_1 = next-item(fl_2) while (fl_1 <> NULL) fl_1.flags = str(fl_1.length,(fl_2.flags + (fl_2.N - fl_3.N)) * 2 ^ (fl_1.length - fl_2.length)) fl_1 = next-item (fl_1) fl_2 = next-item (fl_2) fl_3 = next-item (fl_3) end while end BUILD-FLAGS Price, et al. Expires August 23, 2002 [Page 14] Internet-Draft Enhanced TCP/IP Compression for ROHC February 2002 procedure INDICATOR-FLAGS var n, bit, temp var temp temp = compressed_data # Returns the indicator flags which are actually the full # compressed header which is aligned to bit_alignment. get-indicator-flags (method_chosen, flags_list_elt, temp) empty (compressed_data) compressed_data = flags_list_elt # add the uncompressed fields after the compressed header add (compressed_data, unc_fields) # add the payload after the uncompressed fields add (compressed_data, uncompressed_data) end INDICATOR-FLAGS Price, et al. Expires August 23, 2002 [Page 15] Internet-Draft Enhanced TCP/IP Compression for ROHC February 2002 procedure READ-FLAGS var temp, flags, n decode-indicator-flags (received_data, method_chosen, flags) n = length (flags) # put the compressed header on the compressed data stack pop (received_data, n, temp) push (compressed_data, flags) # put the rest of the received packet on the unc_fields stack size = stack-size (received_data) pop (received_data, size, temp) push (unc_fields, temp) end READ-FLAGS 6. Statement of optimal efficiency An important property of the compressed headers built by EPIC is that they are optimally efficient. This means that the average compressed header size of EPIC is provably the minimum possible for the chosen protocol stack. The precise statement of optimal efficiency is given below: "If every compressed header format specified by EPIC is used with the claimed probability, and if the distribution of headers using each format is uniform, then the EPIC compressed headers are optimally efficient for the chosen level of robustness and bit alignment". Note that the two caveats in the statement just ensure that the input code is programmed correctly for the protocol stack it is compressing. If the input to EPIC states that Field 1 will need LSB(4,0,20%) encoding time then optimal efficiency is only achieved if this really is the case. If the probabilities specified in the code do not match the probabilities for the header stream being compressed then the efficiency will not be optimal; however the closer the match the better the compression ratio. 7. Security Considerations EPIC generates compressed header formats for direct use in ROHC profiles. Consequently the security considerations for EPIC match Price, et al. Expires August 23, 2002 [Page 16] Internet-Draft Enhanced TCP/IP Compression for ROHC February 2002 those of ROHC [1]. 8. Acknowledgements Header compression schemes from ROHC [1] have been important sources of ideas and knowledge. Basic Huffman encoding [3] was enhanced for the specific tasks of robust, efficient header compression. Thanks to Carsten Bormann (cabo@tzi.org) Christian Schmidt (christian.schmidt@icn.siemens.de) Max Riegel (maximilian.riegel@icn.siemens.de) Casper Coetzer (casper.coetzer@roke.co.uk) for valuable input and review. 9. Intellectual Property Considerations This proposal in is full conformity with RFC-2026 [6]. Siemens may have patent rights on technology described in this document which employees of Siemens contribute for use in IETF standards discussions. In relation to any IETF standard incorporating any such technology, Siemens hereby agrees to license on fair, reasonable and non-discriminatory terms, based on reciprocity, any patent claims it owns covering such technology, to the extent such technology is essential to comply with such standard. References [1] Bormann, C., Burmeister, C., Degermark, M., Fukushima, H., Hannu, H., Jonsson, L-E., Hakenberg, R., Koren, T., Le, K., Liu, Z., Martensson, A., Miyazaki, A., Svanbro, K., Wiebke, T., Yoshimura, T. and H. Zheng, "RObust Header Compression (ROHC): Framework and four profiles: RTP, UDP, ESP, and uncompressed", RFC 3095, July 2001. [2] Price, R., Hancock, R., Ollis, P., Surtees, A. and M. West, "Framework for EPIC-lite", draft-ietf-rohc-epic-lite-01.txt (work in progress), February 2002. [3] Nelson, M. and J-L. Gailly, "The Data Compression Book", M&T Books , 1995. [4] Jacobson, V., "Compressing TCP/IP headers for low-speed serial links", RFC 1144, February 1990. Price, et al. Expires August 23, 2002 [Page 17] Internet-Draft Enhanced TCP/IP Compression for ROHC February 2002 [5] Deutsch, P., "DEFLATE Compressed Data Format Specification version 1.3", RFC 1951, May 1996. [6] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996. [7] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. Authors' Addresses Richard Price Siemens/Roke Manor Roke Manor Research Ltd. Romsey, Hants SO51 0ZN UK Phone: +44 (0)1794 833681 EMail: richard.price@roke.co.uk URI: http://www.roke.co.uk Robert Hancock Siemens/Roke Manor Roke Manor Research Ltd. Romsey, Hants SO51 0ZN UK Phone: +44 (0)1794 833601 EMail: robert.hancock@roke.co.uk URI: http://www.roke.co.uk Stephen McCann Siemens/Roke Manor Roke Manor Research Ltd. Romsey, Hants SO51 0ZN UK Phone: +44 (0)1794 833341 EMail: stephen.mccann@roke.co.uk URI: http://www.roke.co.uk Price, et al. Expires August 23, 2002 [Page 18] Internet-Draft Enhanced TCP/IP Compression for ROHC February 2002 Abigail Surtees Siemens/Roke Manor Roke Manor Research Ltd. Romsey, Hants SO51 0ZN UK Phone: +44 (0)1794 833131 EMail: abigail.surtees@roke.co.uk URI: http://www.roke.co.uk Paul Ollis Siemens/Roke Manor Roke Manor Research Ltd. Romsey, Hants SO51 0ZN UK Phone: +44 (0)1794 833168 EMail: paul.ollis@roke.co.uk URI: http://www.roke.co.uk Mark A. West Siemens/Roke Manor Roke Manor Research Ltd. Romsey, Hants SO51 0ZN UK Phone: +44 (0)1794 833311 EMail: mark.a.west@roke.co.uk URI: http://www.roke.co.uk Price, et al. Expires August 23, 2002 [Page 19] Internet-Draft Enhanced TCP/IP Compression for ROHC February 2002 Full Copyright Statement Copyright (C) The Internet Society (2002). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society. Price, et al. Expires August 23, 2002 [Page 20]