< draft-pelletier-rohc-udplite-00.txt   draft-pelletier-rohc-udplite-01.txt >
Network Working Group Ghyslain Pelletier Network Working Group Ghyslain Pelletier
INTERNET-DRAFT Ericsson INTERNET-DRAFT Ericsson AB
Expires: August 2002 Expires: May 2003
February 22, 2002 January 31, 2003
RObust Header Compression (ROHC): RObust Header Compression (ROHC):
Profiles for UDP Lite Profiles for UDP-Lite
<draft-pelletier-rohc-udplite-00.txt> <draft-pelletier-rohc-udplite-01.txt>
Status of this memo Status of this memo
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026. all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that other Task Force (IETF), its areas, and its working groups. Note that other
groups may also distribute working documents as Internet-Drafts. groups may also distribute working documents as Internet-Drafts.
skipping to change at page 1, line 38 skipping to change at page 1, line 38
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html http://www.ietf.org/shadow.html
This document is an individual submission to the IETF. Comments This document is an individual submission to the IETF. Comments
should be directed to the authors. should be directed to the authors.
Abstract Abstract
This document defines ROHC (Robust Header Compression) profiles for This document defines ROHC (Robust Header Compression) profiles for
compression of IP/UDP Lite/RTP packets (Internet Protocol, User compression of RTP/UDP-Lite/IP packets (Real-Time Transport Protocol,
Datagram Protocol Lite, Real-Time Transport Protocol) and IP/UDP User Datagram Protocol Lite, Internet Protocol) and UDP-Lite/IP.
Lite. These profiles are defined based on their differences with the These profiles are defined based on their differences with the
profiles specified in [RFC-3095] for the classic UDP [RFC-768]. profiles specified in [RFC-3095] for UDP [RFC-768].
Although both transport protocols are very similar, ROHC profiles Although both transport protocols are very similar, ROHC profiles
must be defined separately for robust compression of UDP Lite headers must be defined separately for robust compression of UDP-Lite headers
because it does not share protocol identifier with the classic UDP. because it does not share protocol identifier with UDP. Also, the
Also, the UDP Lite Checksum Coverage field does not either share the UDP-Lite Checksum Coverage field does not share the semantics of the
semantics of the corresponding classic UDP Length field and as a corresponding UDP Length field and as a consequence cannot always be
consequence cannot always be inferred anymore. In addition, this inferred anymore.
coverage field may open new possibilities for additional compression
efficiency when compared to the UDP profiles defined in [RFC-3095].
Table of contents Table of contents
1. Introduction....................................................3 1. Introduction....................................................3
2. Terminology.....................................................4 2. Terminology.....................................................3
3. Background......................................................4 3. Background......................................................4
3.1. The UDP Lite Protocol....................................4 3.1. Overview of the UDP-Lite protocol.........................4
3.2. Checksum Coverage........................................6 3.2. Expected behaviours of UDP-Lite flows.....................5
3.3. Header field classification...............................6
4. Rationale behind the design of UDP Lite ROHC profiles...........8 4. Rationale behind the design of ROHC profiles for UDP-Lite.......6
4.1. UDP Lite Considerations..................................8 4.1. Design motivations........................................6
4.2. ROHC Considerations......................................8 4.2. ROHC considerations.......................................6
4.3. Header Compression strategies for UDP Lite...............9
4.4. UPD Lite checksum and ROHC CRC..........................10
5. ROHC UDP Lite profiles.........................................10 5. ROHC profiles for UDP-Lite......................................7
5.1. Initialization of the UDP Lite header [UDPLITE]..........11 5.1. Context parameters........................................7
5.2. States and modes.........................................11 5.2. Initialization............................................8
5.3. Packet type format.......................................11 5.2.1. Initialization of the UDP-Lite header [UDP-Lite]........8
5.4. IP/UDP Lite/RTP compression: ROHC RTP/UDPLite............12 5.2.2. Compressor and decompressor logic.......................9
5.4.1. Initialization........................................12 5.3. Packet formats............................................9
5.4.2. Packet types..........................................12 5.3.1. General packet format...................................9
5.4.2.1 Packet type 0: TBD...................................12 5.3.2. Packet type CE: CE(), CE(ON) and CE(OFF)...............10
5.4.2.2 Packet type 1: TBD...................................13 5.4. Compression logic........................................11
5.4.2.3 Packet types 2, IR, IR-DYN and extensions............13 5.5. Decompression logic......................................12
5.5. Non-RTP IP/UPD Lite compression: ROHC UDPLite............13
5.5.1. Initialization........................................13
5.5.2. Packet types..........................................13
6. Security considerations........................................13 6. Security considerations........................................12
7. Acknowledgements...............................................14 7. IANA considerations............................................12
8. Intellectual Property Right Claim Considerations...............14 8. Acknowledgements...............................................12
9. References.....................................................14 9. References.....................................................12
10. Authors address................................................14 10. Authors address...............................................13
1. Introduction
Appendix A. Detailed classification of header fields..............14
A.1. UDP-Lite header fields...................................14
A.2. Header compression strategies for UDP-Lite...............16
Appendix B. Detailed format of the CE packet type.................17
1. Introduction
The ROHC WG has developed a header compression framework on top of The ROHC WG has developed a header compression framework on top of
which various profiles can be defined for different protocol sets, or which various profiles can be defined for different protocol sets, or
for different compression strategies. Due to the demands of the for different compression strategies. Due to the demands of the
cellular industry for an efficient way of transporting voice over IP cellular industry for an efficient way of transporting voice over IP
over wireless, the main focus of ROHC [RFC-3095] has so far been on over wireless, ROHC [RFC-3095] has mainly focused on compression of
compression of IP/UDP/RTP headers, which are generous in size, IP/UDP/RTP headers, which are generous in size, especially compared
especially compared to the payloads often carried by the packets with to the payloads often carried by packets with these headers.
these headers.
ROHC RTP has become a very efficient, robust and capable compression ROHC RTP has become a very efficient, robust and capable compression
scheme, able to compress the headers down to a total size of one scheme, able to compress the headers down to a total size of one
octet only. Also, transparency is guaranteed to an extremely high octet only. Also, transparency is guaranteed to an extremely high
extent even when residual bit errors are present in compressed extent even when residual bit errors are present in compressed
headers delivered to the decompressor. headers delivered to the decompressor.
UDP Lite is a transport protocol similar to the classic UDP protocol UDP-Lite [UDP-Lite] is a transport protocol similar to the UDP
[RFC-768]. UDP Lite is useful for applications that are designed with protocol [RFC-768]. UDP-Lite is useful for applications that are
the capability to tolerate errors in the payload and for which designed with the capability to tolerate errors in the payload and
receiving damaged data is better than dealing with the loss of entire for which receiving damaged data is better than dealing with the loss
packets. The protocol is particularly suitable for link technologies of entire packets. This may be particularly suitable when packets are
where data can be partially damaged, such as wireless links. transported over link technologies where data can be partially
damaged, such as wireless links.
New ROHC profiles are needed for UDP Lite because it does not share
protocol identifier with the classic UDP. Also, the UDP Lite Checksum
Coverage field does not either share the semantics of the
corresponding Length field of the classic UDP and cannot always be
inferred. In addition, the coverage field may open new possibilities
for additional compression efficiency when compared to ROHC RTP.
This document thus defines two ROHC profiles to allow compression of
UDP Lite headers. The objectives of these profiles are to provide
simple modifications to the existing profiles for compressing classic
UDP headers, as well as introducing a simple method by which the UDP
Lite checksum may be entirely compressed away in certain specific
scenarios, without threats to the end-to-end nature of this checksum.
This document therefore focuses on differences to the compression
profiles for classic UDP headers, as specified in [RFC-3095], to
define corresponding profiles for UDP Lite header compression.
Revision history: Separate ROHC profiles are needed for UDP-Lite because it does not
00: First version of this document, including: share protocol identifier with UDP. Also, the UDP-Lite Checksum
Motivation for the work, the problematic and some possible Coverage field does not share the semantics of the corresponding UDP
directions. Length field and cannot always be inferred.
This first draft is currently showing the initial state of the work, This document defines two ROHC profiles for efficient compression of
and will hopefully generate fruitful discussions around header UDP-Lite headers. The objectives of these profiles are to provide
compression for UDP Lite within the ROHC WG. simple modifications to the corresponding ROHC profiles for UDP, as
specified in [RFC-3095]. In addition, the ROHC profiles for UDP-Lite
support compression of multiple IP headers using the mechanisms
defined in [IP-ONLY].
2. Terminology 2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119. document are to be interpreted as described in RFC 2119.
ROHC Robust Header Compression ROHC RTP : RTP/UDP/IP profile 0x0001 defined in [RFC-3095].
Classic UDP Classic UDP, as defined in [RFC-768] ROHC UDP : UDP/IP profile 0x0002 defined in [RFC-3095].
UDP Lite UDP Lite, as defined in [UDPLite] ROHC UDP-Lite : UDP-Lite/IP profile defined in this document.
ROHC RTP/UDP-Lite : RTP/UDP-Lite/IP profile defined in this document.
ROHC RTP 3. Background
ROHC RTP in this document refers to the RTP/UDP/IP profile 0x0001 3.1. Overview of the UDP-Lite protocol
as defined in [RFC-3095].
ROHC UDP UDP-Lite is a transport protocol defined as an independent variant of
the UDP transport protocol. UDP-Lite is very similar to UDP, and
allow applications that can tolerate errors in the payload to use a
checksum with an optional partial coverage. This is particularly
useful with IPv6 [RFC-2460], where the use of the transport-layer
checksum is mandatory.
ROHC UDP in this document refers to the non-RTP UDP/IP profile UDP-Lite replaces the Length field of the UDP header with a Checksum
0x0002 as defined in [RFC-3095]. Coverage field. This field indicates the number of octets covered by
the 16-bit checksum, and it is applied on a per-packet basis. The
coverage area must always include the UDP-Lite header and may cover
the entire packet, in which case UDP-Lite becomes semantically
identical to UDP. UDP-Lite and UDP do not share protocol identifier.
ROHC UDPLite The UDP-Lite header format:
ROHC UDPLite in this document refers to the non-RTP UDP Lite/RTP 0 15 16 31
profile, as defined in this document. +--------+--------+--------+--------+
| Source | Destination |
| Port | Port |
+--------+--------+--------+--------+
| Checksum | |
| Coverage | Checksum |
+--------+--------+--------+--------+
| |
: Payload :
| |
+-----------------------------------+
ROHC RTP/UDPLite The UDP-Lite checksum, like the UDP checksum, is an end-to-end
mechanism against erroneous delivery of error sensitive data.
However, as opposed to UDP, the UDP-Lite checksum may not be
transmitted as all zeroes and cannot be disabled for IPv4 [RFC-791].
ROHC RTP/UDPLite in this document refers to the RTP/UDP Lite For UDP, in the case where the checksum is disabled (IPv4 only), the
profile, as defined in this document. Checksum field maintains a constant value and is normally not sent by
the header compression scheme. In the case where the UDP checksum is
enabled (mandatory for IPv6), such an unpredictable field cannot be
compressed and is sent uncompressed. The UDP Length field, however,
is always redundant and can be provided by the IP module. Header
compression schemes do not normally transmit any bits of information
for this field, as its value can be inferred from the link layer.
3. Background For UDP-Lite, the checksum has also completely random values and this
field must always be included as-is in the compressed header, for
both IPv4 and IPv6. Furthermore, as the UDP Length field is redefined
as the Checksum Coverage field by UDP-Lite, this leads to different
properties for this field from a header compression perspective.
3.1. The UDP Lite Protocol The following summarizes the relationship between UDP and UDP-Lite:
UDP Lite is a datagram transport protocol defined as an independant - UDP-Lite and UDP have different protocol identifiers;
variant of the classic UDP transport protocol [RFC-768]. UDP Lite is - The UDP-Lite checksum cannot be disabled for IPv4;
very similar to the classic UDP, and allow applications that can - UDP-Lite redefines the UDP Length field as the Checksum
tolerate errors in the payload to use a checksum with optionally Coverage field, with different semantics;
partial coverage. See [UDPLite] for further information about the - UDP-Lite is semantically equivalent to UDP when the Checksum
motivations and benefits of the protocol. Coverage field indicates the total length of the packet.
UDP Lite replaces the classic UDP Length field of the header with a The next section provides a more detailed discussion of the behavior
Checksum Coverage field indicating the number of octets covered by of the Checksum Coverage field of UPD-Lite in relation to header
the 16-bit checksum, applied on a per-packet basis. The coverage area compression.
must minimally always include the entire UDP Lite header and may
cover the entire datagram, in which case UDP Lite becomes
semantically identical to the classic UDP. However, UDP Lite and
classic UDP do not share protocol identifier.
UDP Lite Header Format: 3.2. Expected behaviours of UDP-Lite flows
0 15 16 31
+--------+--------+--------+--------+
| Source | Destination |
| Port | Port |
+--------+--------+--------+--------+
| Checksum | |
| Coverage | Checksum |
+--------+--------+--------+--------+
| |
| data bytes ... |
+---------------- ...---------------+
The UDP Lite checksum, like the classic UDP checksum, is an end-to- Per-packet behavior
end mechanism against erroneous delivery of error sensitive data.
In the case where the checksum is enabled for classic UDP (mandatory As mentioned in the previous section, the checksum coverage value
for IPv6 [RFC-2460]), such an unpredictable field cannot be is applied independently of other packets that may belong to the
compressed and is sent unmodified. The classic UDP Length field, same flow. Specifically, the value of the checksum coverage may
however, is redundant and can be provided by the IP module. Header indicate that the UDP-Lite packet is either entirely covered by the
compression schemes do not normally transmit any bits of information checksum, or covered up to some boundary less than the packet size
for this field, as its value can be inferred. but including the UDP-Lite header.
For UDP Lite, the Length field being redefined as the Checksum Inter-packet behavior
Coverage field leads to different properties for both the Checksum
Coverage and the Checksum fields from a header compression
perspective. The following table summarizes a possible classification
for the UDP Lite header fields, using the same classes as in [RFC-
3095].
UDP Lite header fields and Classic UDP fields: In relation to each other, UDP-Lite packets may exhibit either one
+-------------------+-------------+ of three possible change patterns, where within a sequence of
| UDP Lite | Classic UDP | packets the value of the Checksum Coverage field is:
+-------------------+--------+-------------------+-------------+
| Header | Size | Class | Class |
| Field | (bits) | | |
+-------------------+--------+-------------------+-------------+
| Source Port | 16 | STATIC-DEF | STATIC-DEF |
| Destination Port | 16 | STATIC-DEF | STATIC-DEF |
| Checksum Coverage | 16 | CHANGING/INFERRED | |
| Length | 16 | | INFERRED |
| Checksum | 16 | CHANGING/INFERRED | CHANGING |
+-------------------+--------+-------------------+-------------+
One difference from the classic UDP header fields behavior is that 1. changing, while covering the entire packet;
only in some cases may the Checksum Coverage be inferred, more 2. unchanging, covering up to a fixed boundary within the packet;
specifically when either only the header(s) (UDP Lite header only or 3. changing, but does not follow any specific pattern.
UDP Lite/RTP headers) or the entire datagram is covered.
Another difference lies in the nature of the UDP Lite checksum field The first pattern above corresponds to the semantics of UDP, when
itself: the checksum value depends on the Checksum Coverage field and the UDP checksum is enabled. For this case, the checksum coverage
may exclude payload. An interesting consideration from a header field varies according to the packet length and may be inferred
compression perspective is that it may be acceptable under certain from the IP module similarly as for the UDP Length field.
circumstances to replace the UDP Lite checksum and its functionality
by a stronger cyclic redundancy check (CRC) using less bits, similar
to the CRC currently used in ROHC profiles. Using the ROHC CRC could
in some specific and potentially frequently occurring cases allow the
UDP Lite checksum to be replaced and inferred at the receiver. In
this respect, the presence of a stronger CRC using less bits would
thus make the Checksum field redundant and make it acceptable not to
transmit its uncompressed value.
3.2. Checksum Coverage The second pattern corresponds to the case where the coverage is
the same from one packet to another within a particular sequence.
For this case, the Checksum Coverage field may be a static value
defined in the context and it does not need to be sent in the
compressed header.
It is of interest to consider the semantics of the UDP Lite checksum For the third pattern, the checksum coverage field has completely
when considering header compression, to find out if those semantics random values from packet to packet, and it must be included in the
allow for some additional compression efficiency gains. Referring to compressed header.
[RFC-1144] section 3.1, when addressing the IP checksum:
It seems rather silly to protect the transmission of Per-flow behavior
information that is not being transmitted.
The semantics of the UDP Lite Checksum allow for partial coverage of Finally, it can be expected that any one of these change patterns
the datagram. It must minimally cover the transport-layer header for sequences of packets may be predominant at any time during the
[UDPLite]. This is particularly useful with IPv6, where the lifetime of the UDP-Lite flow. A flow that predominantly follows
transport-layer checksum is mandatory [RFC-2460]. In this specific the first two change patterns described above may provide
case, no information other than the checksum coverage and the actual opportunities for compressing the Checksum Coverage field for most
checksum needs to be transmitted in the header compressed stream. It of the packets.
thus seem justified to not transmit those four octets, as this
checksum in this case protects bits that are not transmitted.
Moving forward in this line of reasoning, the case where the checksum 3.3. Header field classification
also covers the entire RTP header in addition to the UDP Lite header
may offer a similar opportunity. When operating with a high
compression ratio, very few information bits are being sent as part
of the compressed stream. It this case, it may also be acceptable to
not transmit the checksum value, provided equal or superior
protection is provided within the header compression scheme to
replace the checksum functionality, for example transmitting a strong
enough CRC within the compressed header. At the receiver, the
checksum may then be regenerated locally when decompressing the
headers and then validated using the CRC.
The following figure shows the relationship between the possible UDP In relation to the header field classification from [RFC-3095], the
Lite checksum coverage and the ROHC CRC coverage. first two patterns represent the case where the value of the
Checksum Coverage field behavior is fixed and may be either
INFERRED (pattern 1) or STATIC (pattern 2); pattern 3 is for the
case where the value varies unpredictably, the field is CHANGING
and the value must be sent along with every packet.
UDP Lite Checksum and ROHC CRC coverage: Additional information regarding the analysis of the behavior of
+--------+--------------+---------+-------------+ the UDP-Lite fields may be found in the Appendix A.
| IP hdr | UDP Lite hdr | RTP hdr | RTP Payload |
+--------+--------------+---------+-------------+
<----- ROHC CRC coverage -------->
<- UDP Lite Checksum --><- Optional coverage -->
The UDP Lite Checksum Coverage field has four possible different 4. Rationale behind the design of ROHC profiles for UDP-Lite
behaviors embodied via the following assignments for its value:
a. set to the UDP datagram length (or is set to 0) 4.1. Design motivations
b. set to the UDP Lite header size (set to 8)
c. set to the UDP Lite/RTP header size
d. set to an unpredictable value, fluctuating between the UDP Lite
(or UDP Lite/RTP) header length and the entire datagram length.
The semantics of the Checksum Coverage field thus yields a number of Simplicity is a strong motivation for the design of the UDP-Lite
different transport scenarios each having different properties from a header compression profiles. The profiles defined for UDP-Lite should
header compression perspective. These properties are further entail only a few simple modifications to the corresponding profiles
summarized in the following figures, for each identified scenarios. defined for UDP in [RFC-3095]. In addition, whenever UDP-Lite is used
in a manner that is semantically identical to UDP, the compression
efficiency should be similar.
Note that c is a special case of d, for which optimal compression 4.2. ROHC considerations
efficiency may also be desirable.
Note also that it is possible that an application use any of the The simplest approach to the definition of ROHC profiles for UDP-Lite
possible coverage values within a single packet stream, and this is is to treat the Checksum Coverage field as an entirely random value,
unpredictable from a header compression perspective. and to send it uncompressed for every packet. This may be achieved
simply by adding the field to the definition of the general packet
format [RFC-3095]. However, the compression efficiency would then
always be less than for UDP.
Total size of the fields in each class, for each scenarios: Some care should be given to achieve similar compression efficiency
for UDP-Lite as for UDP when the Checksum Coverage field behaves like
the UDP Length field. This requires the possibility to infer the
Checksum Coverage field when it is equal to the length of the packet.
This would otherwise put the UDP-Lite protocol at a disadvantage over
links where header compression is used, when its behavior is made
similar to the semantics of UDP.
Scenario #1 û Assignment a.: A mechanism to detect the presence of the Checksum Coverage field in
+------------+---------------+ compressed headers is thus needed. This is achieved by defining a new
| Class | Size (octets) | packet type, using the unused identifiers from [RFC-3095].
+------------+---------------+
| INFERRED | 2 | Checksum Coverage
| STATIC-DEF | 4 | Source Port / Destination Port
| CHANGING | 2 | Checksum
+------------+---------------+
Scenario #2 û Assignment b. or c.: 5. ROHC profiles for UDP-Lite
+------------+---------------+
| Class | Size (octets) |
+------------+---------------+
| INFERRED | 4 | Checksum Coverage / Checksum
| STATIC-DEF | 4 | Source Port / Destination Port
| CHANGING | 0 |
+------------+---------------+
Scenario #3 û Assignment d.: This section describes two ROHC profiles:
+------------+---------------+
| Class | Size (octets) |
+------------+---------------+
| INFERRED | 0 |
| STATIC-DEF | 4 | Source Port / Destination Port
| CHANGING | 4 | Checksum Coverage / Checksum
+------------+---------------+
For scenario #1, corresponding to the classic UDP semantics, the - RTP/UDP-Lite/IP compression (profile 0x0007)
checksum coverage field is inferred as in classic UDP case. The - UDP-Lite/IP compression (profile 0x0008)
checksum (if enabled for IPv4) has completely random values and this
field must be included as-is in the compressed header.
For scenario #2, the checksum coverage field may be inferred from the These profiles build on the specifications found in [RFC-3095] with
size of the UDP Lite (UDP Lite or UDP Lite/RTP streams) or the size as little modifications as possible. Unless explicitly stated
of the UDP Lite/RTP header (UDP Lite/RTP streams only). The checksum otherwise, the profiles defined herein follow the specifications of
field can then be recalculated at the receiver and the ROHC CRC ROHC UDP and ROHC RTP, respectively.
applied on the entire decompressed to validate the checksum
recalculation.
For scenario #3, the checksum coverage field and the checksum field Note that this document also reuses the notation found in [RFC-3095].
have completely random values and these fields must both be included
as-is in the compressed header.
4. Design Rationale for UDP Lite ROHC profiles 5.1. Context parameters
A strong motivation for the design of the UDP Lite header compression As described in [RFC-3095], information relevant to previous packets
profiles is to use the semantics and properties of the UDP Lite is maintained in a context. This includes information describing the
checksum coverage to improve efficiency when the transport-layer packet stream, or parameters. While the UDP and UDP-Lite protocols
checksum is enabled. share many commonalities, the differences in semantics as described
earlier renders the following parameter inapplicable:
4.1. UDP Lite considerations The parameter context(UDP Checksum)
The UDP Lite checksum, like the classic UDP checksum, is an end-to- The UDP-Lite checksum cannot be disabled, as opposed to UDP. The
end mechanism against erroneous delivery of error sensitive data. parameter context(UDP Checksum) of [RFC-3095, section 5.7] is
Care must be taken not to violate this end-to-end functionality. therefore not used for compression of UDP-Lite.
The checksum coverage of UDP Lite is applied on a per-packet basis. In addition, the UDP-Lite checksum is always sent as-is in every
As per the protocol definition, there is no guarantee that one of the compressed packet. However, the Checksum Coverage field may not
scenarios identified in section 3.2 will occur more often than always be sent in each compressed packet, and the following context
another. This in turn makes it difficult to maintain state in a parameter is used to indicate whether or not the field is sent:
header compression for the coverage field.
The UDP Lite Checksum Coverage field may vary unpredictably and thus The parameter context(UDP-Lite Coverage Field Present)
cannot always be inferred, as opposed to the corresponding Length
field of the classic UDP.
4.2. ROHC considerations Whether the UDP-Lite Checksum Coverage field is present or not in
the general packet format (see 5.3.1.) is controlled by the value
of the Coverage Field Present (CFP) flag in the context.
The ROHC CRC If context(CFP) is nonzero, the Checksum Coverage field is not
compressed and it is present within compressed packets. If
context(CFP) is zero, the Checksum Coverage field is compressed and
it is not sent. This is the case when the value of the Checksum
Coverage field follows a stable inter-packet change pattern; the
field has either a constant value or it has a value equal to the
packet length for most packets in a sequence (see 3.2.).
ROHC packets may carry a CRC calculated over the uncompressed Finally, the following context parameter is needed to indicate
header. This CRC is defined at the framework level and is used by whether the field should be inferred or taken from a value previously
the decompressor to verify that the decompressed header is correct. saved in the context:
This verification serves three purposes:
- Detection of longer losses than can be covered by the sequence The parameter context(UDP-Lite Coverage Field Inferred)
number LSBs
- Protection against failures caused by residual bit errors in the
compressed header
- Protection against faulty implementations or other error causes
Replacing the transport-layer checksum When the UDP-Lite Checksum Coverage field is not present in the
compressed header (CFP=0), whether it is inferred or not is
controlled by the value of the Coverage Field Inferred (CFI) flag
in the context.
Since this document suggests that the end-to-end UDPLite checksum If context(CFI) is nonzero, the Checksum Coverage field is inferred
may be completely compressed away and replaced by the ROHC CRC, from the packet length, similarly as for the UDP Length field in
care must be taken to ensure that the CRC used offers equal or ROHC RTP. If context(CFI) is zero, the Checksum Coverage field is
stronger robustness than what is provided by the UDP Lite checksum. decompressed using context(UDP-Lite Checksum Coverage). Therefore,
Specifically, the ROHC CRC cannot replace the UDP Lite checksum when context(CFI) is updated to a nonzero value, the value of the
unless the UDP Lite Checksum Coverage field covers only the UDP Checksum Coverage field stored in the context must also be updated.
Lite or the UDP Lite/RTP headers. Otherwise, it must be sent
uncompressed. This is necessary to ensure that the end-to-end
nature of the checksum is maintained.
It is thus reasonable to assume that compression and decompression 5.2. Initialization
transparency can be guaranteed even without explicitly carrying the
uncompressed UPD Lite coverage field and/or uncompressed UDP Lite
Checksum field in header compressed packets, in certain specific
cases.
Reuse of ROHC RTP and ROHC UDP mechanisms Unless stated otherwise, the mechanisms of ROHC RTP and ROHC UDP
found in [RFC-3095] are used also for the ROHC RTP/UDP-Lite and the
ROHC UDP-Lite profiles, respectively.
A ROHC compressor will initially behave as for ROHC RTP, however In particular, the considerations of ROHC UDP regarding the UDP SN
based on the UDP Lite profile identifier. taking the role of the RTP Sequence Number applies to ROHC UDP-Lite.
Also, the static context for ROHC UDP-Lite may be initialized by
reusing an existing context belonging to a stream compressed using
ROHC RTP/UDP-Lite (profile 0x0007), similarly as for ROHC UDP.
The initialization of other headers than the UDP Lite header (IPv4, 5.2.1. Initialization of the UDP-Lite header [UDP-Lite]
IPv6, RTP) is the same as [RFC-3095].
The same actions are taken upon CRC failure as in ROHC 5.3.2.2.3. The structure of the IR and IR-DYN packets and the initialization
procedures are the same as for the ROHC profiles for UDP [RFC-3095],
with the exception of the dynamic part as specified for UDP. A 2-
octet field containing the checksum coverage is added before the
Checksum field. This affects the format of dynamic chains in both IR
and IR-DYN packets.
Additional notes Dynamic part:
A mechanism, for example via the definition of new packet types, +---+---+---+---+---+---+---+---+
must be defined to allow the compressor to segregate the different / Checksum Coverage / 2 octets
scenarios from each other (section 3.2), to allow the proper +---+---+---+---+---+---+---+---+
parsing and decompression of both the coverage and checksum fields, / Checksum / 2 octets
if these scenarios are to be used as a basis to improve compression +---+---+---+---+---+---+---+---+
efficiency. This mechanism may be defined in combination with a
context value indicating if the checksum is enabled or not, similar
to [RFC-3095].
Additionally, for scenario #2 (section 3.2) it may be possible to CRC-DYNAMIC: Checksum Coverage field, Checksum field (octets 5-8).
achieve a minimal compressed header of one octet, similar to PT-0
defined for ROHC RTP, even for IPv6 when the transport protocol
checksum is mandated.
4.3. Header compression strategies for UDP Lite CRC-STATIC: All other fields (octets 1-4).
This table revisits the corresponding table for the classic UDP from 5.2.2. Compressor and decompressor logic
[RFC-3095] section A.3 and classifies the changing fields, based on
the previously identified scenarios and for the case when the UDP
Lite checksum is enabled.
Header compression strategies for UDP Lite: The following logic must be used by both the compressor and the
+----------------------------+-------------+-----------+-----------+ decompressor for assigning values to the parameters context(CFP) and
| Field | Value/Delta | Class | Knowledge | context(CFI) during initialization:
+============================+=============+===========+===========+
| Datagram| Value | STATIC | KNOWN |
+ --------+-------------+-----------+-----------+
| Checksum Coverage: Header | Value | STATIC | KNOWN |
+ --------+-------------+-----------+-----------+
| Partial | Value | IRREGULAR | UNKNOWN |
+----------------------------+-------------+-----------+-----------+
| Datagram| Value | IRREGULAR | UNKNOWN |
+ --------+-------------+-----------+-----------+
| Checksum(Enabled): Header | Value | IRREGULAR | UNKNOWN |
+ --------+-------------+-----------+-----------+
| Partial | Value | IRREGULAR | UNKNOWN |
+----------------------------+-------------+-----------+-----------+
Datagram: Scenario #1; Header: Scenario #2; Partial: Scenario #3
4.4. UPD Lite checksum and ROHC CRC Context(CFP)
It is possible to replace the transport-layer checksum and the ROHC During context initialization, the value of context(CFP) MUST be
checksum by a stronger CRC, without removing the protection required set to a nonzero value if the Checksum Coverage field differs from
by the transport-layer. the length of the UDP-Lite packet, for any one IR or IR-DYN packet
sent (compressor) or received (decompressor); otherwise the value
MUST be set to zero.
Note well that the idea is to maintain the transport-layer checksum Context(CFI)
protection and keep the strong CRC for header reconstruction
verification. Specifically, it consists into having both the header
compression CRC and the transport-layer checksum replaced with a
single checksum with the following properties:
- offers equal or stronger protection than transport-layer checksum During context initialization, the value of context(CFI) MUST be
- protects all bits covered by the transport-layer checksum set to a nonzero value if the Checksum Coverage field is equal to
- offers equal or stronger robustness than the header compression CRC the length of the UDP-Lite packet within an IR or an IR-DYN packet
- protects the original transport-layer checksum sent (compressor) or received (decompressor); otherwise the value
MUST be set to zero.
A header compression CRC having these properties would allow the 5.3. Packet formats
transport-layer checksum to be recalculated at the decompressor side
before the entire decompressed header, including the recalculated
checksum, is verified and validated using the CRC.
5. ROHC UDP Lite profiles The general packet format as defined in [RFC-3095] is modified to
include an additional field for the UDP-Lite checksum coverage. A
packet type is also defined to handle the specific semantics and
characteristics of this field.
The profiles defined in this document borrows as much as possible the 5.3.1. General packet format
mechanisms defined in [RFC-3095]. This section summarizes the
necessary additions and exceptions required from section 5.11 of
[RFC-3095].
This chapter is incomplete and is an initial proposal for directions. The general packet format of a compressed ROHC UDP-Lite header is
similar to the compressed ROHC RTP header [RFC-3095, section 5.7],
with modifications to the Checksum field, as well as additional
fields for handling multiple IP headers [IP-ONLY, section 3.3.] and
for the UDP-Lite checksum coverage:
5.1. Initialization of the UDP Lite header [UDPLITE] --- --- --- --- --- --- --- ---
: List of :
/ dynamic chains / variable, given by static chain
: for additional IP headers : see [IP-ONLY, section 3.3].
--- --- --- --- --- --- --- ---
: : 2 octets,
+ UDP-Lite Checksum Coverage + if context(CFP) = 1 or
: : if packet type = CE (see 5.3.2.)
--- --- --- --- --- --- --- ---
: :
+ UDP-Lite Checksum + 2 octets
: :
--- --- --- --- --- --- --- ---
The IR and IR-DYN packets structure and initialization procedures are Note that the order of the fields following the optional extension of
the same as for ROHC UDP, unless explicitly stated otherwise. the general ROHC packet format is the same as the order between the
fields in the uncompressed header.
For ROHC UDPLite, the dynamic part of a UDP packet is different than Note also that when calculating the CRC for this profile, the
from [RFC-3095] (sections 5.11.1 and 5.7.7.5): a two-octet field Checksum Coverage field is CRC-DYNAMIC.
containing the UDP Lite Checksum Coverage field is added before the
Checksum field. This affects the format of dynamic chains in IR and
IR-DYN packets.
Static part: 5.3.2. Packet type CE: CE(), CE(ON) and CE(OFF)
+---+---+---+---+---+---+---+---+ The ROHC profiles for UDP-Lite defines a packet type to handle the
/ Source Port / 2 octets various possible change patterns of the checksum coverage. This
+---+---+---+---+---+---+---+---+ packet type may be used to manipulate the context values that control
/ Destination Port / 2 octets the presence of the Checksum Coverage field within the general packet
+---+---+---+---+---+---+---+---+ format, i.e. context(CFP), and how the field is decompressed, i.e.
context(CFI). The 2-octet Checksum Coverage field is always present
within the format of this packet (see 5.3.1.).
Dynamic part: This packet is named Coverage Extension, or CE, and its updating
properties depend on the final two bits of the packet type octet (see
format below). A naming scheme of the form CE(<some property>) is
used to uniquely identify the properties of a particular CE packet.
+---+---+---+---+---+---+---+---+ Although this packet type defines its own format, it may be
/ Checksum Coverage / 2 octets considered as an extension mechanism for packets of type 2, 1 or 0
+---+---+---+---+---+---+---+---+ [RFC-3095]. This is achieved by substitution of the packet type
/ Checksum / 2 octets identifier of the first octet of the base header (the "outer"
+---+---+---+---+---+---+---+---+ identifier) with one of the unused packet types from [RFC-3095]. The
substituted identifier is then moved to the first octet of the
remainder of the base header (the "inner" identifier).
CRC-DYNAMIC: Checksum Coverage field, Checksum (octets 5-8). The format of the ROHC UDP-Lite CE packet type:
CRC-STATIC: All other fields (octets 1-4). 0 1 2 3 4 5 6 7
+---+---+---+---+---+---+---+---+
| 1 1 1 1 1 0 F | K | Outer packet type identifier
+===+===+===+===+===+===+===+===+
: : (with inner type identifier)
/ Inner Base header / variable number of bits, given by
: : the inner packet type identifier
+---+---+---+---+---+---+---+---+
5.2. States and modes F,K: F,K = 00 is reserved at framework level (IR-DYN);
F,K = 01 indicates CE();
F,K = 10 indicates CE(ON);
F,K = 11 indicates CE(OFF).
ROHC UDPLite uses the same states, state logic and transitions as Updating properties: The updating properties of the inner packet
ROHC UDP, except when explicitly stated otherwise. type carried within any of the CE packets are always maintained. In
addition, CE(ON) always update context(CFP); CE(OFF) always update
context(CFP), context(CFI) and context(UDP-Lite Checksum Coverage).
It has not yet been determined whether ROHC UDPLite can use the same Appendix B provides an expanded view of the resulting format of the
modes as ROHC RTP, and if so - how. This will require more CE packet type.
explanations.
5.3. Packet type format Properties of CE():
The general format of a ROHC UDPLite packet is the same as for ROHC Aside from the updating properties of the inner packet type carried
UDP (see [RFC-3095] section 5.11). Padding and CIDs are the same, as within CE(), this packet does not update any other context values.
are the feedback packet type (see [RFC-3095] section 5.7.6.1) and the CE() thus is mode-agnostic, e.g. it can extend any of packet types
feedback. IR and IR-DYN packets differ as described in section 5.1. 2, 1 and 0, regardless of the current mode of operation [RFC-3095].
The general format of compressed packets is also the same, but there CE() may be used when the checksum coverage deviates from the
are differences in specific formats as detailed below. These change pattern assumed by the compressor, while the field could
differences are introduced by the UPD Lite semantics of the Checksum previously be compressed. This packet is useful if the occurrence
Coverage field and the Checksum. of such deviations are seldom.
The same notation as in ROHC RTP is used in this section: Properties of CE(ON):
<mode format is used in>-<packet type number>-<some property>
5.4. IP/UPD Lite/RTP compression: ROHC RTP/UDPLite (Profile TBD) In addition to the updating properties of the inner packet type,
CE(ON) updates context(CFP) to a nonzero value, i.e. it effectively
turns on the presence of the Checksum Coverage field within the
general packet format. This is useful when the predominant change
pattern of the checksum coverage preclude its compression.
Unless stated otherwise, the mechanisms of ROHC RTP are used also for CE(ON) can extend any of the context updating packets of type 2, 1
ROHC RTP/UDPLite. and 0, that is packets with a compressed header containing a CRC
[RFC-3095]. Specifically, R-0 and R-1* headers MUST NOT be extended
using CE(ON).
5.4.1. Initialization Properties of CE(OFF):
The static context is initialized in the same way as for ROHC RTP In addition to the updating properties of the inner packet type,
([RFC-3095], section 5.11.1). CE(OFF) updates context(CFP) to a value of zero, i.e. it
effectively turns off the presence of the Checksum Coverage field
within the general packet format. This is useful when the change
pattern of the checksum coverage seldom deviates from the pattern
assumed by the compressor.
5.4.2 Packet types CE(OFF) also updates context(CFI) to a nonzero value, if field(UDP-
Lite Checksum Coverage) is equal to the packet length; otherwise it
must be set to zero. Finally, context(UDP-Lite Checksum Coverage)
is also updated by CE(OFF).
The notation used in this section is the same as in [RFC-3095] Similarly to CE(ON), CE(OFF) can extend any of the context updating
section 5.7. The general packet format is the same as for a packets of type 2, 1 and 0 [RFC-3095].
compressed ROHC RTP header, with an exception for the field
pertaining to the UDP Lite checksum and the addition of a field for
the Checksum Coverage.
--- --- --- --- --- --- --- --- 5.4. Compressor logic
: :
+ UDP Lite Checksum Coverage + 2 octets,
: : if context(UDP Lite Checksum) != 0
--- --- --- --- --- --- --- ---
: :
+ UDP Lite Checksum + 2 octets,
: : if context(UDP Lite Checksum) != 0
--- --- --- --- --- --- --- ---
Note that the order of the fields following the optional extension is Should hdr(UDP-Lite Checksum Coverage) be different from context(UDP-
the same as the order between the fields in an uncompressed header. Lite Checksum Coverage) and different from the packet length when
context(CFP) is zero, the Checksum Coverage field cannot be
compressed. In addition, should hdr(UDP-Lite Checksum Coverage) be
different from the packet length when context(CFP) is zero and
context(CFI) is nonzero, the Checksum Coverage field cannot be
compressed either. For both cases, the field must be sent
uncompressed using a CE packet or the context must be reinitialized
using an IR packet.
Note that the presence of the UDP Lite Checksum and Checksum Coverage 5.5. Decompressor logic
fields is inferred in a similar manner than for [RFC-3095] for every
packet formats, with the exception of PT-0 and PT-1 where it is
instead dependent on the packet format.
5.4.2.1 Packet type 0: PT-0 For packet types other than IR, IR-DYN and CE that are received when
the value of context(CFP) is zero, the Checksum Coverage field must
be decompressed using the value stored in the context if the value of
context(CFI) is zero; otherwise the field is inferred from the length
of the UDP-Lite packet derived from the IP module.
PT-0: TBA 6. Security considerations
It has not yet been determined if a 3-bit CRC is suitable to achieve The security considerations of [RFC-3095] apply integrally to this
the desired properties mentioned in section 4.4, and as a consequence document without modifications.
if the U/O-0 packet format of ROHC RTP could be used as PT-0 for this
profile.
5.4.2.2 Packet type 1: TBD 7. IANA considerations
Packet type 1: TBA A ROHC profile identifier must be reserved by the IANA for each of
the profiles defined in this document, preferably as listed below:
The following header bits should be useful when defining PT-1: Profile Document Usage
Identifier
- Packet type (2 bits) : 1 0, for packet type 1 0x0007 RFCthis ROHC RTP/UDP-Lite
- Checksum Coverage Flag (1 bit): 1, if field is present 0x0008 RFCthis ROHC UDP-Lite
- Checksum Flag (1 bit) : 1, if field is present
- CRC (? bits) : ROHC ?-bit CRC
([ROHC], section 5.9.2)
- Other bits, depending on the packet type properties, based on ROHC
RTP PT-0 and PT-1.
Note that the flags are used to identify how the values of the 8. Acknowledgements
Checksum Coverage and Checksum fields are to be decompressed, based
on the different scenarios described in section 3.2.
5.4.2.3 Packet types 2, IR, IR-DYN and extensions The author would like to thank Lars-Erik Jonsson, Mats Nordberg for
reviews and discussions around this document.
Packet type 2 and extensions are the same as [RFC-3095]. Packet types 9. References
IR and IR-DYN are the same as in [RFC-3095], except for the changes
of section 5.1.
5.5. Non-RTP IP/UPD Lite compression: ROHC UDPLite (Profile TBD) [RFC-3095] Bormann, C., Burmeister, C., Degermark, M., Fukushima,
H., Hannu, H., Jonsson, L., 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.
Unless stated otherwise, the mechanisms of ROHC UDP are used also for [IP-ONLY] Jonsson, L., "RObust Header Compression (ROHC): A
ROHC UDPLite, with the same considerations regarding the UDP SN compression profile for IP", Internet draft (work in
taking the role of the RTP Sequence Number ([RFC-3095] section 5.11). progress), January 2003, <draft-ietf-rohc-ip-only-
01.txt>
5.5.1. Initialization [RFC-791] Postel, J., "Internet Protocol", STD 5, RFC 791,
September 1981.
The static context for ROHC UDPLite streams can be initialized in [RFC-2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6
similar ways as for ROHC UDP, however using the modified IR packet (IPv6) Specification", RFC 2460, December 1998.
from section 5.1 and with the profile value set to (TBD) or reusing
an existing context of a stream compressed using ROHC RTP/UDPLite.
Note: In the case where an existing context is reused, the stream may [RFC-768] Postel, J., "User Datagram Protocol", STD 6, RFC 768,
have originally been assumed a UDP Lite/RTP stream, based on the UDP August 1980.
Lite protocol identifier (as opposed to assuming profile 0x0001).
5.5.2. Packet types [UDP-Lite] Larzon, L., Degermark, M., Pink, S., Jonsson, L.,
Fairhurst, G., "The UDP-Lite Protocol", Internet draft
(work in progress), December 2002, <draft-ietf-tsvwg-
udp-lite-01.txt>
TBA [RFC-1889] Schulzrinne, H., Casner S., Frederick, R. and V.
Jacobson, "RTP: A Transport Protocol for Real-Time
Applications", RFC 1889, January 1996.
6. Security considerations 10. Authors address
The security considerations of [RFC-3095] apply integrally to this Ghyslain Pelletier Tel: +46 920 20 24 32
document without modifications. Ericsson AB Fax: +46 920 20 20 99
Box 920
SE-971 28 Lulea
Sweden EMail: ghyslain.pelletier@epl.ericsson.se
7. Acknowledgements Appendix A. Detailed classification of header fields
The author would like to thank Lars-Erik Jonsson, Krister Svanbro for This section summarizes the difference from the classification found
reviews and discussions around this document. in the corresponding appendix in [RFC-3095], and similarly provides
conclusions about how the various header fields should be handled by
the header compression scheme to optimize compression and
functionality. These conclusions are separated based on the behavior
of the UDP-Lite Checksum Coverage field and uses the expected change
patterns described in section 3.2 of this document.
8. Intellectual Property Right Claim Considerations A.1. UDP-Lite header fields
The IETF has been notified of intellectual property rights claimed in The following table summarizes a possible classification for the UDP-
regard to some or all of the specification contained in this Lite header fields in comparison with the classification for UDP,
document. For more information consult the online list of claimed using the same classes as in [RFC-3095].
rights.
9. References UDP-Lite header fields and UDP fields:
[RFC-3095] C. Bormann, "Robust Header Compression (ROHC)", +-------------------+-------------+
RFC 3095, July 2001. | UDP-Lite | UDP |
+-------------------+--------+-------------------+-------------+
| Header | Size | Class | Class |
| Field | (bits) | | |
+-------------------+--------+-------------------+-------------+
| Source Port | 16 | STATIC-DEF | STATIC-DEF |
| Destination Port | 16 | STATIC-DEF | STATIC-DEF |
| Checksum Coverage | 16 | INFERRED | |
| | | STATIC | |
| | | CHANGING | |
| Length | 16 | | INFERRED |
| Checksum | 16 | CHANGING | CHANGING |
+-------------------+--------+-------------------+-------------+
[UDPLite] L. Larzon, M. Degermark, "The UDP Lite Protocol", Source and Destination Port
Internet draft (work in progress), January 2002.
<draft-ietf-tsvwg-udp-lite-00.txt>
[RFC-1144] V. Jacobson, "Compressing TCP/IP Headers for Low-Speed Same as for UDP. Specifically, these fields are part of the
Serial Links", RFC 1144, February 1990. definition of a stream and must thus be constant for all packets in
the stream. The fields are therefore classified as STATIC-DEF.
[RFC-791] J. Postel, "Internet Protocol", RFC 791, September 1981. Checksum Coverage
[RFC-2460] S. Deering, R. Hinden, "Internet Protocol, Version 6 This field specifies which part of the UDP-Lite datagram is covered
(IPv6) Specification", RFC 2460, December 1998. by the checksum. It may have a value of zero or equal to the
datagram length if the checksum covers the entire datagram, or it
may have any value between eight octets and the length of the
datagram to specify the number of octets protected by the checksum,
calculated from the first octet of the UDP-Lite header. The value
of this field may vary for each packet, and this makes the value
unpredictable from a header compression perspective.
[RFC-768] J. Postel, "User Datagram Protocol", RFC 768, August Checksum
1980.
[RFC-1889] H. Schulzrinne, S. Casner, R. Frederick, V. Jacobson, The information used for the calculation of the UDP-Lite checksum
"RTP: A Transport Protocol for Real-Time Applications", is governed by the value of the checksum coverage, and minimally
RFC 1889, January 1996. includes the UDP-Lite header. The checksum is a changing field that
must always be sent as-is.
10. Authors address The total size of the fields in each class, for each expected change
patterns (see section 3.2), is summarized in the tables below:
Ghyslain Pelletier Tel: +46 920 20 24 32 Pattern 1:
Ericsson Erisoft AB Fax: +46 920 20 20 99 +------------+---------------+
Box 920 | Class | Size (octets) |
SE-971 28 Lulea +------------+---------------+
Sweden EMail: ghyslain.pelletier@epl.ericsson.se | INFERRED | 2 | Checksum Coverage
| STATIC-DEF | 4 | Source Port / Destination Port
| CHANGING | 2 | Checksum
+------------+---------------+
This Internet-Draft expires August 22, 2002. Pattern 2:
+------------+---------------+
| Class | Size (octets) |
+------------+---------------+
| STATIC-DEF | 4 | Source Port / Destination Port
| STATIC | 2 | Checksum Coverage
| CHANGING | 2 | Checksum
+------------+---------------+
Pattern 3:
+------------+---------------+
| Class | Size (octets) |
+------------+---------------+
| STATIC-DEF | 4 | Source Port / Destination Port
| CHANGING | 4 | Checksum Coverage / Checksum
+------------+---------------+
A.2. Header compression strategies for UDP-Lite
The following table revisits the corresponding table (table A.1) for
UDP from [RFC-3095, section A.2] and classifies the changing fields,
based on the change patterns previously identified in section 3.2.
Header compression strategies for UDP-Lite:
+----------+---------+-------------+-----------+-----------+
| Field | Pattern | Value/Delta | Class | Knowledge |
+==========+=========+=============+===========+===========+
| | #1 | Value | CHANGING | INFERRED |
| Checksum |---------+-------------+-----------+-----------+
| Coverage | #2 | Value | RC | UNKNOWN |
| |---------+-------------+-----------+-----------+
| | #3 | Value | IRREGULAR | UNKNOWN |
+----------+---------+-------------+-----------+-----------+
| Checksum | All | Value | IRREGULAR | UNKNOWN |
+----------+---------+-------------+-----------+-----------+
A.2.1. Transmit initially, but be prepared to update
UDP-Lite Checksum Coverage (Pattern #1 and #2)
A.2.2. Transmit as-is in all packets
UDP-Lite Checksum
UDP-Lite Checksum Coverage (Patterns #3)
Appendix B. Detailed format of the CE packet type
This section provides an expanded view of the format of the CE
packet, based on the general ROHC RTP compressed header [RFC-3095]
and the general format of a compressed header [IP-ONLY]. The
modifications necessary to carry the base header of a packet of type
2, 1 or 0 [RFC-3095] within the CE packet format along with the
additional fields to properly handle compression of multiple IP
headers results in the following structure for the CE packet type:
0 1 2 3 4 5 6 7
--- --- --- --- --- --- --- ---
: Add-CID octet : if for small CIDs and CID 1-15
+---+---+---+---+---+---+---+---+
| 1 1 1 1 1 0 F | K | Outer packet type identifier
+---+---+---+---+---+---+---+---+
: :
/ 0, 1, or 2 octets of CID / 1-2 octets if large CIDs
: :
+---+---+---+---+---+---+---+---+
| First octet of base header | (with "inner" type indication)
+---+---+---+---+---+---+---+---+
/ Remainder of base header / variable number of bits
+---+---+---+---+---+---+---+---+
: :
/ Extension / See [RFC-3095], section 5.7.
: :
--- --- --- --- --- --- --- ---
: :
+ IP-ID of outer IPv4 header + See [RFC-3095], section 5.7.
: :
--- --- --- --- --- --- --- ---
/ AH data for outer list / See [RFC-3095], section 5.7.
--- --- --- --- --- --- --- ---
: :
+ GRE checksum + See [RFC-3095], section 5.7.
: :
--- --- --- --- --- --- --- ---
: :
+ IP-ID of inner IPv4 header + See [RFC-3095], section 5.7.
: :
--- --- --- --- --- --- --- ---
/ AH data for inner list / See [RFC-3095], section 5.7.
--- --- --- --- --- --- --- ---
: :
+ GRE checksum + See [RFC-3095], section 5.7.
: :
--- --- --- --- --- --- --- ---
: List of :
/ dynamic chains / See [IP-ONLY], section 3.3.
: for additional IP headers :
--- --- --- --- --- --- --- ---
: :
+ UDP-Lite Checksum Coverage + 2 octets
: :
+---+---+---+---+---+---+---+---+
: :
+ UDP-Lite Checksum + 2 octets
: :
+---+---+---+---+---+---+---+---+
F,K: F,K = 00 is reserved at framework level (IR-DYN);
F,K = 01 indicates CE();
F,K = 10 indicates CE(ON);
F,K = 11 indicates CE(OFF).
Note that this document does not define (F,K) = 00, as this would
collide with the IR-DYN packet type already reserved at the ROHC
framework level.
Full Copyright Statement
Copyright (C) The Internet Society (2003). 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.
This Internet-Draft expires July 31, 2003.
 End of changes. 148 change blocks. 
493 lines changed or deleted 492 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/