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 <draft-ietf-rohc-epic-lite-01.txt>
-02: Revised pseudo-code
-01: Document split into two Internet Drafts:
<draft-ietf-rohc-tcp-epic-01.txt> for the basic TCP/IP profile
<draft-price-rohc-epic-02.txt> 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]