draft-ietf-rohc-udp-lite-04.txt   rfc4019.txt 
Network Working Group Ghyslain Pelletier Network Working Group G. Pelletier
INTERNET-DRAFT Ericsson AB Request for Comments: 4019 Ericsson AB
Expires: December 2004 Category: Standards Track April 2005
June 9, 2004
RObust Header Compression (ROHC): RObust Header Compression (ROHC):
Profiles for UDP-Lite Profiles for User Datagram Protocol (UDP) Lite
<draft-ietf-rohc-udp-lite-04.txt>
Status of this memo
By submitting this Internet-Draft, I (we) certify that any applicable
patent or other IPR claims of which I am (we are) aware have been
disclosed, and any of which I (we) become aware will be disclosed, in
accordance with RFC 3668 (BCP 79).
By submitting this Internet-Draft, I (we) accept the provisions of
Section #3 of RFC 3667 (BCP 78).
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 Status of This Memo
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or cite them other than as "work in progress".
The list of current Internet-Drafts can be accessed at This document specifies an Internet standards track protocol for the
http://www.ietf.org/ietf/lid-abstracts.txt Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Official Protocol Standards" (STD 1) for the standardization state
and status of this protocol. Distribution of this memo is unlimited.
The list of Internet-Draft Shadow Directories can be accessed at Copyright Notice
http://www.ietf.org/shadow.html
This document is a submission of the IETF ROHC WG. Comments should be Copyright (C) The Internet Society (2005).
directed to the ROHC WG mailing list, rohc@ietf.org.
Abstract Abstract
This document defines ROHC (Robust Header Compression) profiles for This document defines Robust Header Compression (ROHC) profiles for
compression of RTP/UDP-Lite/IP packets (Real-Time Transport Protocol, compression of Real-Time Transport Protocol, User Datagram Protocol-
User Datagram Protocol Lite, Internet Protocol) and UDP-Lite/IP. Lite, and Internet Protocol (RTP/UDP-Lite/IP) packets and UDP-
These profiles are defined based on their differences with the Lite/IP. These profiles are defined based on their differences with
profiles for UDP specified in RFC 3095. the profiles for UDP as specified in RFC 3095.
Table of Contents Table of Contents
1. Introduction.....................................................3 1. Introduction.................................................. 2
2. Terminology......................................................4 2. Terminology................................................... 3
3. Background.......................................................4 3. Background.................................................... 3
3.1. Overview of the UDP-Lite Protocol...........................4 3.1. Overview of the UDP-Lite Protocol....................... 3
3.2. Expected Behaviours of UDP-Lite Flows.......................5 3.2. Expected Behaviours of UDP-Lite Flows................... 5
3.2.1. Per-packet behavior....................................5 3.2.1. Per-Packet Behavior............................. 5
3.2.2. Inter-packet behavior..................................5 3.2.2. Inter-Packet Behavior........................... 5
3.2.3. Per-flow behavior......................................6 3.2.3. Per-Flow Behavior............................... 5
3.3. Header Field Classification.................................6 3.3. Header Field Classification............................. 5
4. Rationale behind the Design of ROHC Profiles for UDP-Lite........7 4. Rationale behind the Design of ROHC Profiles for UDP-Lite..... 6
4.1. Design Motivations..........................................7 4.1. Design Motivations...................................... 6
4.2. ROHC Considerations.........................................7 4.2. ROHC Considerations..................................... 6
5. ROHC Profiles for UDP-Lite.......................................7 5. ROHC Profiles for UDP-Lite.................................... 6
5.1. Context Parameters..........................................8 5.1. Context Parameters...................................... 7
5.2. Initialization..............................................9 5.2. Initialization.......................................... 8
5.2.1. Initialization of the UDP-Lite Header [1]..............9 5.2.1. Initialization of the UDP-Lite Header [1]....... 8
5.2.2. Compressor and Decompressor Logic......................9 5.2.2. Compressor and Decompressor Logic............... 9
5.3. Packet Formats.............................................10 5.3. Packet Formats.......................................... 9
5.3.1. General Packet Format.................................10 5.3.1. General Packet Format........................... 9
5.3.2. Packet Type CCE: CCE(), CCE(ON) and CCE(OFF)..........11 5.3.2. Packet Type CCE: CCE(), CCE(ON), and CCE(OFF)... 10
5.3.2.1. Properties of CCE():.............................12 5.3.2.1. Properties of CCE():.................. 11
5.3.2.2. Properties of CCE(ON):...........................12 5.3.2.2. Properties of CCE(ON):................ 11
5.3.2.3. Properties of CCE(OFF):..........................12 5.3.2.3. Properties of CCE(OFF):............... 12
5.4. Compressor Logic...........................................13 5.4. Compressor Logic........................................ 12
5.5. Decompressor Logic.........................................13 5.5. Decompressor Logic...................................... 12
5.6. Additional Mode Transition Logic...........................13 5.6. Additional Mode Transition Logic........................ 13
5.7. The CONTEXT_MEMORY Feedback Option.........................13 5.7. The CONTEXT_MEMORY Feedback Option...................... 13
5.8. Constant IP-ID.............................................14 5.8. Constant IP-ID.......................................... 13
6. Security Considerations.........................................15 6. Security Considerations....................................... 14
7. IANA Considerations.............................................15 7. IANA Considerations........................................... 14
8. Acknowledgments.................................................15 8. Acknowledgments............................................... 15
9. Author's Address................................................15 9. References.................................................... 15
10. References.....................................................16 9.1. Normative References.................................... 15
10.1. Normative References......................................16 9.2. Informative References.................................. 15
10.2. Informative References....................................16 Appendix A. Detailed Classification of Header Fields............. 17
Appendix A - Detailed Classification of Header Fields..............17 Appendix B. Detailed Format of the CCE Packet Type............... 20
Appendix B - Detailed Format of the CCE Packet Type................20 Author's Address.................................................. 22
Full Copyright Statement.......................................... 23
1. Introduction 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 compression strategies. Due to the demands of the cellular industry
cellular industry for an efficient way of transporting voice over IP for an efficient way to transport voice over IP over wireless, ROHC
over wireless, ROHC [2] has mainly focused on compression of [2] has mainly focused on compression of IP/UDP/RTP headers, which
IP/UDP/RTP headers, which are generous in size, especially compared are generous in size, especially compared to the payloads often
to the payloads often carried by packets with these headers. carried by packets with 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 [1] is a transport protocol similar to the UDP protocol [7]. UDP-Lite [4] is a transport protocol similar to the UDP protocol [7].
UDP-Lite is useful for applications that are designed with the UDP-Lite is useful for applications designed with the capability to
capability to tolerate errors in the payload and for which receiving tolerate errors in the payload, for which receiving damaged data is
damaged data is better than dealing with the loss of entire packets. better than dealing with the loss of entire packets. This may be
This may be particularly suitable when packets are transported over particularly suitable when packets are transported over link
link technologies where data can be partially damaged, such as technologies in which data can be partially damaged, such as wireless
wireless links. links.
Although both transport protocols are very similar, ROHC profiles Although these 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 UDP-Lite does not share the same protocol identifier with because UDP-Lite does not share the same protocol identifier with
UDP. Also, the UDP-Lite Checksum Coverage field does not share the UDP. Also, the UDP-Lite Checksum Coverage field does not share the
semantics of the corresponding UDP Length field and as a consequence semantics of the corresponding UDP Length field, and as a consequence
it cannot always be inferred anymore. it cannot always be inferred anymore.
This document defines two ROHC profiles for efficient compression of This document defines two ROHC profiles for efficient compression of
UDP-Lite headers. The objective of this document is to provide simple UDP-Lite headers. The objective of this document is to provide
modifications to the corresponding ROHC profiles for UDP specified in simple modifications to the corresponding ROHC profiles for UDP,
RFC 3095 [2]. In addition, the ROHC profiles for UDP-Lite support specified in RFC 3095 [2]. In addition, the ROHC profiles for UDP-
some of the mechanisms defined in the profile for compression of IP Lite support some of the mechanisms defined in the profile for
headers [3] (ROHC IP-Only). This specification includes support for compression of IP headers [3] (ROHC IP-Only). This specification
compression of multiple IP headers and for compressing IP-ID fields includes support for compression of multiple IP headers and for
with constant behavior, as well as improved mode transition logic and compressing IP-ID fields with constant behavior, as well as improved
a feedback option for decompressors with limited memory resources. mode transition logic and a feedback option for decompressors with
limited memory resources.
2. Terminology 2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", In this document, the key words "MUST", "MUST NOT", "REQUIRED",
"SHOULD, "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHALL", "SHALL NOT", "SHOULD, "SHOULD NOT", "RECOMMENDED", "MAY",
document are to be interpreted as described in RFC 2119 [1]. and "OPTIONAL" are to be interpreted as described in RFC 2119 [1].
ROHC RTP : RTP/UDP/IP profile 0x0001 defined in RFC 3095 [2]. ROHC RTP : RTP/UDP/IP profile 0x0001 defined in RFC 3095 [2].
ROHC UDP : UDP/IP profile 0x0002 defined in RFC 3095 [2]. ROHC UDP : UDP/IP profile 0x0002 defined in RFC 3095 [2].
ROHC UDP-Lite : UDP-Lite/IP profile defined in this document. 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/UDP-Lite: RTP/UDP-Lite/IP profile defined in this document.
3. Background 3. Background
3.1. Overview of the UDP-Lite Protocol 3.1. Overview of the UDP-Lite Protocol
UDP-Lite is a transport protocol defined as an independent variant of UDP-Lite is a transport protocol defined as an independent variant of
the UDP transport protocol. UDP-Lite is very similar to UDP, and it the UDP transport protocol. UDP-Lite is very similar to UDP, and it
allows applications that can tolerate errors in the payload to use a allows applications that can tolerate errors in the payload to use a
checksum with an optional partial coverage. This is particularly checksum with an optional partial coverage. This is particularly
useful with IPv6 [6], where the use of the transport-layer checksum useful with IPv6 [6], in which the use of the transport-layer
is mandatory. checksum is mandatory.
UDP-Lite replaces the Length field of the UDP header with a Checksum UDP-Lite replaces the Length field of the UDP header with a Checksum
Coverage field. This field indicates the number of octets covered by Coverage field. This field indicates the number of octets covered by
the 16-bit checksum, which is applied on a per-packet basis. The the 16-bit checksum, which is applied on a per-packet basis. The
coverage area always include the UDP-Lite header and may cover the coverage area always includes the UDP-Lite header and may cover the
entire packet, in which case UDP-Lite becomes semantically identical entire packet, in which case UDP-Lite becomes semantically identical
to UDP. UDP-Lite and UDP do not share the same protocol identifier. to UDP. UDP-Lite and UDP do not share the same protocol identifier.
The UDP-Lite header format: The UDP-Lite header format:
0 15 16 31 0 15 16 31
+--------+--------+--------+--------+ +--------+--------+--------+--------+
| Source | Destination | | Source | Destination |
| Port | Port | | Port | Port |
+--------+--------+--------+--------+ +--------+--------+--------+--------+
| Checksum | | | Checksum | |
| Coverage | Checksum | | Coverage | Checksum |
+--------+--------+--------+--------+ +--------+--------+--------+--------+
| | | |
: Payload : : Payload :
| | | |
+-----------------------------------+ +-----------------------------------+
The UDP-Lite checksum, like the UDP checksum, is an end-to-end Like the UDP checksum, the UDP-Lite checksum is an end-to-end
mechanism against erroneous delivery of error sensitive data. mechanism against erroneous delivery of error sensitive data. This
This checksum is mandatory with IPv6 [5] for both protocols. checksum is mandatory with IPv6 [5] for both protocols. However,
However, as opposed to UDP, the UDP-Lite checksum may not be unlike its UDP counterpart, the UDP-Lite checksum may not be
transmitted as all zeroes and cannot be disabled for IPv4 [5]. transmitted as all zeroes and cannot be disabled for IPv4 [5]. For
UDP, if the checksum is disabled (IPv4 only), the Checksum field
For UDP, in the case where the checksum is disabled (IPv4 only), the maintains a constant value and is normally not sent by the header
Checksum field maintains a constant value and is normally not sent by compression scheme. If the UDP checksum is enabled (mandatory for
the header compression scheme. In the case where the UDP checksum is IPv6), such an unpredictable field cannot be compressed and is sent
enabled (mandatory for IPv6), such an unpredictable field cannot be uncompressed. The UDP Length field, however, is always redundant and
compressed and is sent uncompressed. The UDP Length field, however, can be provided by the IP module. Header compression schemes do not
is always redundant and can be provided by the IP module. Header normally transmit any bits of information for this field, as its
compression schemes do not normally transmit any bits of information value can be inferred from the link layer.
for this field, as its value can be inferred from the link layer.
For UDP-Lite, the checksum also has unpredictable values and this For UDP-Lite, the checksum also has unpredictable values, and this
field must always be included as-is in the compressed header, for field must always be included as-is in the compressed header for both
both IPv4 and IPv6. Furthermore, as the UDP Length field is redefined IPv4 and IPv6. Furthermore, as the UDP Length field is redefined as
as the Checksum Coverage field by UDP-Lite, this leads to different the Checksum Coverage field by UDP-Lite, this leads to different
properties for this field from a header compression perspective. properties for this field from a header-compression perspective.
The following summarizes the relationship between UDP and UDP-Lite: The following summarizes the relationship between UDP and UDP-Lite:
- UDP-Lite and UDP have different protocol identifiers; - UDP-Lite and UDP have different protocol identifiers.
- The UDP-Lite checksum cannot be disabled for IPv4; - The UDP-Lite checksum cannot be disabled for IPv4.
- UDP-Lite redefines the UDP Length field as the Checksum - UDP-Lite redefines the UDP Length field as the Checksum Coverage
Coverage field, with different semantics; field, with different semantics.
- UDP-Lite is semantically equivalent to UDP when the Checksum - UDP-Lite is semantically equivalent to UDP when the Checksum
Coverage field indicates the total length of the packet. Coverage field indicates the total length of the packet.
The next section provides a more detailed discussion of the behavior The next section provides a more detailed discussion of the behavior
of the Checksum Coverage field of UDP-Lite in relation to header of the Checksum Coverage field of UDP-Lite in relation to header
compression. compression.
3.2. Expected Behaviours of UDP-Lite Flows 3.2. Expected Behaviours of UDP-Lite Flows
3.2.1. Per-packet behavior 3.2.1. Per-Packet Behavior
As mentioned in the previous section, the checksum coverage value As mentioned in the previous section, the checksum coverage value is
is applied independently of other packets that may belong to the applied independently of other packets that may belong to the same
same flow. Specifically, the value of the checksum coverage may flow. Specifically, the value of the checksum coverage may indicate
indicate that the UDP-Lite packet is either entirely covered by the that the UDP-Lite packet is either entirely covered by the checksum
checksum, or covered up to some boundary less than the packet size or covered up to some boundary less than the packet size but
but including the UDP-Lite header. including the UDP-Lite header.
3.2.2. Inter-packet behavior 3.2.2. Inter-Packet Behavior
In relation to each other, UDP-Lite packets may exhibit either one In relation to each other, UDP-Lite packets may exhibit one of three
of three possible change patterns, where within a sequence of possible change patterns, where within a sequence of packets the
packets the value of the Checksum Coverage field is: value of the Checksum Coverage field is
1. changing, while covering the entire packet; 1. changing, while covering the entire packet;
2. unchanging, covering up to a fixed boundary within the packet; 2. unchanging, covering up to a fixed boundary within the packet; or
3. changing, but does not follow any specific pattern. 3. changing, but it does not follow any specific pattern.
The first pattern above corresponds to the semantics of UDP, when
the UDP checksum is enabled. For this case, the checksum coverage
field varies according to the packet length and may be inferred
from the IP header similarly as for the UDP Length field.
The second pattern corresponds to the case where the coverage is The first pattern above corresponds to the semantics of UDP, when the
the same from one packet to another within a particular sequence. UDP checksum is enabled. For this case, the checksum coverage field
For this case, the Checksum Coverage field may be a static value varies according to the packet length and may be inferred from the IP
defined in the context and it does not need to be sent in the header, as is the UDP Length field value.
compressed header.
For the third case, no useful change pattern can be identified from The second pattern corresponds to the case where the coverage is the
packet to packet for the value of the checksum coverage field, and same from one packet to another within a particular sequence. For
it must be included in the compressed header. this case, the Checksum Coverage field may be a static value defined
in the context, and it does not have to be sent in the compressed
header. For the third case, no useful change pattern can be
identified from packet to packet for the value of the checksum
coverage field, and it must be included in the compressed header.
3.2.3. Per-flow behavior 3.2.3. Per-Flow behavior
It can be expected that any one of the above change patterns for It can be expected that any one of the above change patterns for
sequences of packets may be predominant at any time during the sequences of packets may be predominant at any time during the
lifetime of the UDP-Lite flow. A flow that predominantly follows lifetime of the UDP-Lite flow. A flow that predominantly follows the
the first two change patterns described above may provide first two change patterns described above may provide opportunities
opportunities for compressing the Checksum Coverage field for most for compressing the Checksum Coverage field for most of the packets.
of the packets.
3.3. Header Field Classification 3.3. Header Field Classification
In relation to the header field classification of RFC 3095 [2], the In relation to the header field classification of RFC 3095 [2], the
first two patterns represent the case where the value of the first two patterns represent the case where the value of the Checksum
Checksum Coverage field behavior is fixed and may be either Coverage field behavior is fixed and may be either INFERRED (pattern
INFERRED (pattern 1) or STATIC (pattern 2); pattern 3 is for the 1) or STATIC (pattern 2). Pattern 3 is for the case where the value
case where the value varies unpredictably, the field is CHANGING varies unpredictably, the field is CHANGING, and the value must be
and the value must be sent along with every packet. sent along with every packet.
Additional information regarding the analysis of the behavior of Additional information regarding the analysis of the behavior of the
the UDP-Lite fields may be found in Appendix A. UDP-Lite fields may be found in Appendix A.
4. Rationale behind the Design of ROHC Profiles for UDP-Lite 4. Rationale behind the Design of ROHC Profiles for UDP-Lite
4.1. Design Motivations 4.1. Design Motivations
Simplicity is a strong motivation for the design of the UDP-Lite Simplicity is a strong motivation for the design of the UDP-Lite
header compression profiles. The profiles defined for UDP-Lite should header compression profiles. The profiles defined for UDP-Lite
entail only a few simple modifications to the corresponding profiles should entail only a few simple modifications to the corresponding
defined for UDP in RFC 3095 [2]. In addition, it is desirable to profiles defined for UDP in RFC 3095 [2]. In addition, it is
include some of the improvements found in the ROHC IP-Only profile desirable to include some of the improvements found in the ROHC IP-
[3]. Finally, whenever UDP-Lite is used in a manner that is Only profile [3]. Finally, whenever UDP-Lite is used in a manner
semantically identical to UDP, the compression efficiency should be that is semantically identical to UDP, the compression efficiency
similar. should be similar.
4.2. ROHC Considerations 4.2. ROHC Considerations
The simplest approach to the definition of ROHC profiles for UDP-Lite The simplest approach to the definition of ROHC profiles for UDP-Lite
is to treat the Checksum Coverage field as an irregular value, and to is to treat the Checksum Coverage field as an irregular value, and to
send it uncompressed for every packet. This may be achieved simply by send it uncompressed for every packet. This may be achieved simply
adding the field to the definition of the general packet format [2]. by adding the field to the definition of the general packet format
However, the compression efficiency would then always be less than [2]. However, then the compression efficiency would always be less
for UDP. than for UDP.
Some care should be given to achieve similar compression efficiency Some care should be given to achieve compression efficiency for UDP-
for UDP-Lite as for UDP when the Checksum Coverage field behaves like Lite similar to that for UDP when the Checksum Coverage field behaves
the UDP Length field. This requires the possibility to infer the like the UDP Length field. This requires the possibility to infer
Checksum Coverage field when it is equal to the length of the packet. the Checksum Coverage field when it is equal to the length of the
This would otherwise put the UDP-Lite protocol at a disadvantage over packet. Otherwise, this would put the UDP-Lite protocol at a
links where header compression is used, when its behavior is made disadvantage over links where header compression is used, when its
similar to the semantics of UDP. behavior is made similar to the semantics of UDP.
A mechanism to detect the presence of the Checksum Coverage field in A mechanism to detect the presence of the Checksum Coverage field in
compressed headers is thus needed. This is achieved by defining a new compressed headers is thus needed. This is achieved by defining a
packet type with the identifiers left unused in RFC 3095 [2]. new packet type with the identifiers left unused in RFC 3095 [2].
5. ROHC Profiles for UDP-Lite 5. ROHC Profiles for UDP-Lite
This section defines two ROHC profiles: This section defines two ROHC profiles:
- RTP/UDP-Lite/IP compression (profile 0x0007) - RTP/UDP-Lite/IP compression (profile 0x0007)
- UDP-Lite/IP compression (profile 0x0008) - UDP-Lite/IP compression (profile 0x0008)
These profiles build on the specifications found in RFC 3095 [2],
These profiles build on the specifications found in RFC 3095 [2] with with as little modification as possible. Unless it is explicitly
as little modifications as possible. Unless explicitly stated stated otherwise, the profiles defined herein follow the
otherwise, the profiles defined herein follow the specifications of specifications of ROHC UDP and ROHC RTP, respectively.
ROHC UDP and ROHC RTP, respectively.
Note also that this document reuses the notation found in [2]. Note also that this document reuses the notation found in [2].
5.1. Context Parameters 5.1. Context Parameters
As described in [2], information about previous packets is maintained As described in [2], information about previous packets is maintained
in a context. This includes information describing the packet stream, in a context. This includes information describing the packet stream
and compression parameters. While the UDP and UDP-Lite protocols and compression parameters. Although the UDP and UDP-Lite protocols
share many commonalities, the differences in semantics as described share many commonalities, the differences in semantics as described
earlier renders the following parameter inapplicable: earlier render the following parameter inapplicable:
The parameter context(UDP Checksum) The parameter context(UDP Checksum)
The UDP-Lite checksum cannot be disabled, as opposed to UDP. The The UDP-Lite checksum cannot be disabled, as opposed to UDP. The
parameter context(UDP Checksum) defined in [2] (section 5.7) is parameter context(UDP Checksum) defined in [2] (section 5.7) is
therefore not used for compression of UDP-Lite. therefore not used for compression of UDP-Lite.
In addition, the UDP-Lite checksum is always sent as-is in every In addition, the UDP-Lite checksum is always sent as-is in every
compressed packet. However, the Checksum Coverage field may not compressed packet. However, the Checksum Coverage field may not
always be sent in each compressed packet, and the following context always be sent in each compressed packet, and the following context
parameter is used to indicate whether or not the field is sent: parameter is used to indicate whether the field is sent:
The parameter context(UDP-Lite Coverage Field Present) The parameter context(UDP-Lite Coverage Field Present)
Whether the UDP-Lite Checksum Coverage field is present or not in Whether the UDP-Lite Checksum Coverage field is present or not in
the general packet format (see section 5.3.1) is controlled by the the general packet format (see section 5.3.1) is controlled by the
value of the Coverage Field Present (CFP) flag in the context. value of the Coverage Field Present (CFP) flag in the context.
If context(CFP) is nonzero, the Checksum Coverage field is not If context(CFP) is nonzero, the Checksum Coverage field is not
compressed and it is present within compressed packets. If compressed, and it is present within compressed packets. If
context(CFP) is zero, the Checksum Coverage field is compressed and context(CFP) is zero, the Checksum Coverage field is compressed,
it is not sent. This is the case when the value of the Checksum and it is not sent. This is the case when the value of the
Coverage field follows a stable inter-packet change pattern; the Checksum Coverage field follows a stable inter-packet change
field has either a constant value or it has a value equal to the pattern; the field has either a constant value or it has a value
packet length for most packets in a sequence (see section 3.2). equal to the packet length for most packets in a sequence (see
section 3.2).
Finally, the following context parameter is needed to indicate Finally, the following context parameter is needed to indicate
whether the field should be inferred or taken from a value previously whether the field should be inferred or taken from a value previously
saved in the context: saved in the context:
The parameter context(UDP-Lite Coverage Field Inferred) The parameter context(UDP-Lite Coverage Field Inferred)
When the UDP-Lite Checksum Coverage field is not present in the When the UDP-Lite Checksum Coverage field is not present in the
compressed header (CFP=0), whether it is inferred or not is compressed header (CFP=0), whether it is inferred is controlled by
controlled by the value of the Coverage Field Inferred (CFI) flag the value of the Coverage Field Inferred (CFI) flag in the context.
in the context.
If context(CFI) is nonzero, the Checksum Coverage field is inferred If context(CFI) is nonzero, the Checksum Coverage field is inferred
from the packet length, similarly as for the UDP Length field in from the packet length, similarly as for the UDP Length field in
ROHC RTP. If context(CFI) is zero, the Checksum Coverage field is ROHC RTP. If context(CFI) is zero, the Checksum Coverage field is
decompressed using context(UDP-Lite Checksum Coverage). Therefore, decompressed by using context(UDP-Lite Checksum Coverage).
when context(CFI) is updated to a nonzero value, the value of the Therefore, when context(CFI) is updated to a nonzero value, the
Checksum Coverage field stored in the context must also be updated. value of the Checksum Coverage field stored in the context must
also be updated.
5.2. Initialization 5.2. Initialization
Unless stated otherwise, the mechanisms of ROHC RTP and ROHC UDP Unless it is stated otherwise, the mechanisms of ROHC RTP and ROHC
found in [2] are used also for the ROHC RTP/UDP-Lite and the ROHC UDP found in [2] are used also for the ROHC RTP/UDP-Lite and the ROHC
UDP-Lite profiles, respectively. UDP-Lite profiles, respectively.
In particular, the considerations of ROHC UDP regarding the UDP SN In particular, the considerations of ROHC UDP regarding the UDP SN
taking the role of the RTP Sequence Number apply to ROHC UDP-Lite. taking the role of the RTP Sequence Number apply to ROHC UDP-Lite.
Also, the static context for ROHC UDP-Lite may be initialized by Also, the static context for ROHC UDP-Lite may be initialized by
reusing an existing context belonging to a stream compressed using reusing an existing context belonging to a stream compressed by using
ROHC RTP/UDP-Lite (profile 0x0007), similarly as for ROHC UDP. ROHC RTP/UDP-Lite (profile 0x0007), similarly as for ROHC UDP.
5.2.1. Initialization of the UDP-Lite Header [1] 5.2.1. Initialization of the UDP-Lite Header [1]
The structure of the IR and IR-DYN packets and the initialization The structure of the IR and IR-DYN packets and the initialization
procedures are the same as for the ROHC profiles for UDP [2], with procedures are the same as for the ROHC profiles for UDP [2], with
the exception of the dynamic part as specified for UDP. A 2-octet the exception of the dynamic part as specified for UDP. A 2-octet
field containing the checksum coverage is added before the Checksum field containing the checksum coverage is added before the Checksum
field. This affects the format of dynamic chains in both IR and IR- field. This affects the format of dynamic chains in both IR and IR-
DYN packets. DYN packets.
skipping to change at page 9, line 49 skipping to change at page 9, line 16
The following logic must be used by both the compressor and the The following logic must be used by both the compressor and the
decompressor for assigning values to the parameters context(CFP) and decompressor for assigning values to the parameters context(CFP) and
context(CFI) during initialization: context(CFI) during initialization:
Context(CFP) Context(CFP)
During context initialization, the value of context(CFP) MUST be During context initialization, the value of context(CFP) MUST be
set to a nonzero value if the Checksum Coverage field differs from set to a nonzero value if the Checksum Coverage field differs from
the length of the UDP-Lite packet, for any one IR or IR-DYN packet the length of the UDP-Lite packet, for any one IR or IR-DYN packet
sent (compressor) or received (decompressor); otherwise the value sent (compressor) or received (decompressor); otherwise, the value
MUST be set to zero. MUST be set to zero.
Context(CFI) Context(CFI)
During context initialization, the value of context(CFI) MUST be During context initialization, the value of context(CFI) MUST be
set to a nonzero value if the Checksum Coverage field is equal to set to a nonzero value if the Checksum Coverage field is equal to
the length of the UDP-Lite packet within an IR or an IR-DYN packet the length of the UDP-Lite packet within an IR or an IR-DYN packet
sent (compressor) or received (decompressor); otherwise the value sent (compressor) or received (decompressor); otherwise, the value
MUST be set to zero. MUST be set to zero.
5.3. Packet Formats 5.3. Packet Formats
The general packet format as defined in RFC 3095 [2] is modified to The general packet format, as defined in RFC 3095 [2], is modified to
include an additional field for the UDP-Lite checksum coverage. A include an additional field for the UDP-Lite checksum coverage. A
packet type is also defined to handle the specific semantics and packet type is also defined to handle the specific semantics and
characteristics of this field. characteristics of this field.
5.3.1. General Packet Format 5.3.1. General Packet Format
The general packet format of a compressed ROHC UDP-Lite header is The general packet format of a compressed ROHC UDP-Lite header is
similar to the compressed ROHC RTP header ([2], section 5.7), with similar to the compressed ROHC RTP header ([2], section 5.7), with
modifications to the Checksum field, as well as additional fields for modifications to the Checksum field, as well as additional fields for
handling multiple IP headers and for the UDP-Lite checksum coverage: handling multiple IP headers and for the UDP-Lite checksum coverage:
skipping to change at page 10, line 42 skipping to change at page 10, line 20
: : 2 octets, : : 2 octets,
+ UDP-Lite Checksum Coverage + if context(CFP) = 1 or + UDP-Lite Checksum Coverage + if context(CFP) = 1 or
: : if packet type = CCE (see 5.3.2) : : if packet type = CCE (see 5.3.2)
--- --- --- --- --- --- --- --- --- --- --- --- --- --- --- ---
: : : :
+ UDP-Lite Checksum + 2 octets + UDP-Lite Checksum + 2 octets
: : : :
--- --- --- --- --- --- --- --- --- --- --- --- --- --- --- ---
The list of dynamic header chains carries the dynamic header part for The list of dynamic header chains carries the dynamic header part for
each IP header in excess of the initial two, if any (as indicated by each IP header in excess of the initial two, if there is any (as
the presence of corresponding header parts in the static chain). Note indicated by the presence of corresponding header parts in the static
that there is no sequence number at the end of the chain, as SN is chain). Note that there is no sequence number at the end of the
present within compressed base headers. chain, as SN is present within compressed base headers.
The order of the fields following the optional extension of the The order of the fields following the optional extension of the
general ROHC packet format is the same as the order between the general ROHC packet format is the same as the order between the
fields in the uncompressed header. fields in the uncompressed header.
When calculating the CRC, the Checksum Coverage field is CRC-DYNAMIC. When the CRC is calculated, the Checksum Coverage field is CRC-
DYNAMIC.
5.3.2. Packet Type CCE: CCE(), CCE(ON) and CCE(OFF) 5.3.2. Packet Type CCE: CCE(), CCE(ON), and CCE(OFF)
The ROHC profiles for UDP-Lite defines a packet type to handle the The ROHC profiles for UDP-Lite define a packet type to handle the
various possible change patterns of the checksum coverage. This various possible change patterns of the checksum coverage. This
packet type may be used to manipulate the context values that control packet type may be used to manipulate the context values that control
the presence of the Checksum Coverage field within the general packet the presence of the Checksum Coverage field within the general packet
format, i.e. context(CFP), and how the field is decompressed, i.e. format (i.e., context(CFP)) and how the field is decompressed (i.e.,
context(CFI). The 2-octet Checksum Coverage field is always present context(CFI)). The 2-octet Checksum Coverage field is always present
within the format of this packet (see section 5.3.1). within the format of this packet (see section 5.3.1).
This type of packet is named Checksum Coverage Extension, or CCE, and This type of packet is named Checksum Coverage Extension, or CCE, and
its updating properties depend on the final two bits of the packet its updating properties depend on the final two bits of the packet
type octet (see format below). A naming scheme of the form type octet (see format below). A naming scheme of the form
CCE(<some_property>) is used to uniquely identify the properties of a CCE(<some_property>) is used to uniquely identify the properties of a
particular CCE packet. particular CCE packet.
Although this packet type defines its own format, it may be Although this packet type defines its own format, it may be
considered as an extension mechanism for packets of type 2, 1 or 0 considered as an extension mechanism for packets of type 2, 1, or 0
[2]. This is achieved by substitution of the packet type identifier [2]. This is achieved by substitution of the packet type identifier
of the first octet of the base header (the "outer" identifier) with of the first octet of the base header (the "outer" identifier) with
one of the unused packet types from RFC 3095 [2]. The substituted one of the unused packet types from RFC 3095 [2]. The substituted
identifier is then moved to the first octet of the remainder of the identifier is then moved to the first octet of the remainder of the
base header (the "inner" identifier). base header (the "inner" identifier).
The format of the ROHC UDP-Lite CCE packet type: The format of the ROHC UDP-Lite CCE packet type is as follows:
0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
+---+---+---+---+---+---+---+---+ +---+---+---+---+---+---+---+---+
| 1 1 1 1 1 0 F | K | Outer packet type identifier | 1 1 1 1 1 0 F | K | Outer packet type identifier
+===+===+===+===+===+===+===+===+ +===+===+===+===+===+===+===+===+
: : (with inner type identifier) : : (with inner type identifier)
/ Inner Base header / variable number of bits, given by / Inner Base header / variable number of bits, given by
: : the inner packet type identifier : : the inner packet type identifier
+---+---+---+---+---+---+---+---+ +---+---+---+---+---+---+---+---+
F,K: F,K = 00 is reserved at framework level (IR-DYN); F,K: F,K = 00 is reserved at framework level (IR-DYN);
F,K = 01 indicates CCE(); F,K = 01 indicates CCE();
F,K = 10 indicates CCE(ON); F,K = 10 indicates CCE(ON);
F,K = 11 indicates CCE(OFF). F,K = 11 indicates CCE(OFF).
Updating properties: The updating properties of the inner packet Updating properties: The updating properties of the inner packet
type carried within any of the CCE packets are always type carried within any of the CCE packets are always
maintained. CCE(ON) and CCE(OFF) MUST NOT be used to extend maintained. CCE(ON) and CCE(OFF) MUST NOT be used to extend
R-0 and R-1* headers. In addition, CCE(ON) always update R-0 and R-1* headers. In addition, CCE(ON) always updates
context(CFP); CCE(OFF) always update context(CFP), context(CFP); CCE(OFF) always updates context(CFP),
context(CFI) and context(UDP-Lite Checksum Coverage). context(CFI), and context(UDP-Lite Checksum Coverage).
Appendix B provides an expanded view of the resulting format of the Appendix B provides an expanded view of the resulting format of the
CCE packet type. CCE packet type.
5.3.2.1. Properties of CCE(): 5.3.2.1. Properties of CCE()
Aside from the updating properties of the inner packet type carried Aside from the updating properties of the inner packet type carried
within CCE(), this packet does not update any other context values. within CCE(), this packet does not update any other context values.
CCE() thus is mode-agnostic, e.g. it can extend any of packet types CCE() thus is mode-agnostic; e.g., it can extend any of packet types
2, 1 and 0, regardless of the current mode of operation [2]. 2, 1, and 0, regardless of the current mode of operation [2].
CCE() may be used when the checksum coverage deviates from the CCE() may be used when the checksum coverage deviates from the change
change pattern assumed by the compressor, where the field could pattern assumed by the compressor, where the field could previously
previously be compressed. This packet is useful if the occurrence be compressed. This packet is useful if the occurrence of such
of such deviations is rare. deviations is rare.
5.3.2.2. Properties of CCE(ON): 5.3.2.2. Properties of CCE(ON)
In addition to the updating properties of the inner packet type, In addition to the updating properties of the inner packet type,
CCE(ON) updates context(CFP) to a nonzero value, i.e. it CCE(ON) updates context(CFP) to a nonzero value; i.e., it effectively
effectively turns on the presence of the Checksum Coverage field turns on the presence of the Checksum Coverage field within the
within the general packet format. This is useful when the general packet format. This is useful when the predominant change
predominant change pattern of the checksum coverage preclude its pattern of the checksum coverage precludes its compression.
compression.
CCE(ON) can extend any of the context updating packets of type 2, 1 CCE(ON) can extend any of the context-updating packets of type 2, 1,
and 0, that is packets with a compressed header containing a CRC and 0; that is, packets with a compressed header containing a CRC
[2]. Specifically, R-0 and R-1* headers MUST NOT be extended using [2]. Specifically, R-0 and R-1* headers MUST NOT be extended by
CCE(ON). using CCE(ON).
5.3.2.3. Properties of CCE(OFF): 5.3.2.3. Properties of CCE(OFF)
In addition to the updating properties of the inner packet type, In addition to the updating properties of the inner packet type,
CCE(OFF) updates context(CFP) to a value of zero, i.e. it CCE(OFF) updates context(CFP) to a value of zero; i.e., it
effectively turns off the presence of the Checksum Coverage field effectively turns off the presence of the Checksum Coverage field
within the general packet format. This is useful when the change within the general packet format. This is useful when the change
pattern of the checksum coverage seldom deviates from the pattern pattern of the checksum coverage seldom deviates from the pattern
assumed by the compressor. assumed by the compressor.
CCE(OFF) also updates context(CFI) to a nonzero value, if CCE(OFF) also updates context(CFI) to a nonzero value, if field(UDP-
field(UDP-Lite Checksum Coverage) is equal to the packet length; Lite Checksum Coverage) is equal to the packet length; otherwise, it
otherwise it must be set to zero. Note that when updating must be set to zero. Note that when context(CFI) is updated by using
context(CFI) using packet type CCE(OFF), a match of field(Checksum packet type CCE(OFF), a match of field(Checksum Coverage) with the
Coverage) with the packet length always has precedence over a match packet length always has precedence over a match with
with context(Checksum Coverage). Finally, context(UDP-Lite Checksum context(Checksum Coverage). Finally, context(UDP-Lite Checksum
Coverage) is also updated by CCE(OFF). Coverage) is also updated by CCE(OFF).
Similarly to CCE(ON), CCE(OFF) can extend any of the context Similarly to CCE(ON), CCE(OFF) can extend any of the context updating
updating packets of type 2, 1 and 0 [2]. packets of type 2, 1, and 0 [2].
5.4. Compressor Logic 5.4. Compressor Logic
Should hdr(UDP-Lite Checksum Coverage) be different from context(UDP- If hdr(UDP-Lite Checksum Coverage) is different from context(UDP-Lite
Lite Checksum Coverage) and different from the packet length when Checksum Coverage) and different from the packet length when
context(CFP) is zero, the Checksum Coverage field cannot be context(CFP) is zero, the Checksum Coverage field cannot be
compressed. In addition, should hdr(UDP-Lite Checksum Coverage) be compressed. In addition, if hdr(UDP-Lite Checksum Coverage) is
different from the packet length when context(CFP) is zero and different from the packet length when context(CFP) is zero and
context(CFI) is nonzero, the Checksum Coverage field cannot be context(CFI) is nonzero, the Checksum Coverage field cannot be
compressed either. For both cases, the field must be sent compressed by either. For both cases, the field must be sent
uncompressed using a CCE packet or the context must be reinitialized uncompressed using a CCE packet, or the context must be reinitialized
using an IR packet. by using an IR packet.
5.5. Decompressor Logic 5.5. Decompressor Logic
For packet types other than IR, IR-DYN and CCE that are received when For packet types other than IR, IR-DYN, and CCE that are received
the value of context(CFP) is zero, the Checksum Coverage field must when the value of context(CFP) is zero, the Checksum Coverage field
be decompressed using the value stored in the context if the value of must be decompressed by using the value stored in the context if the
context(CFI) is zero; otherwise the field is inferred from the length value of context(CFI) is zero; otherwise, the field is inferred from
of the UDP-Lite packet derived from the IP module. the length of the UDP-Lite packet derived from the IP module.
5.6. Additional Mode Transition Logic 5.6. Additional Mode Transition Logic
The profiles defined in this document allow the compressor to decline The profiles defined in this document allow the compressor to decline
a mode transition requested by the decompressor. This is achieved by a mode transition requested by the decompressor. This is achieved by
redefining the Mode parameter for the value mode = 0 (in packet types redefining the Mode parameter for the value mode = 0 (in packet types
UOR-2, IR and IR-DYN) as follow (see also [3], section 3.4): UOR-2, IR, and IR-DYN) as follows (see also [3], section 3.4):
Mode: Compression mode. 0 = (C)ancel Mode Transition Mode: Compression mode. 0 = (C)ancel Mode Transition
Upon receiving the Mode parameter set to '0', the decompressor MUST Upon receiving the Mode parameter set to 0, the decompressor MUST
stay in its current mode of operation and SHOULD refrain from sending stay in its current mode of operation and SHOULD refrain from sending
further mode transition requests for the declined mode for a certain further mode transition requests for the declined mode.
amount of time.
5.7. The CONTEXT_MEMORY Feedback Option 5.7. The CONTEXT_MEMORY Feedback Option
This feedback option informs the compressor that the decompressor This feedback option informs the compressor that the decompressor
does not have sufficient memory resources to handle the context of does not have sufficient memory resources to handle the context of
the packet stream required by the current compressed structure. the packet stream required by the current compressed structure.
0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
+---+---+---+---+---+---+---+---+ +---+---+---+---+---+---+---+---+
| Opt Type = 9 | Opt Len = 0 | | Opt Type = 9 | Opt Len = 0 |
+---+---+---+---+---+---+---+---+ +---+---+---+---+---+---+---+---+
When receiving a CONTEXT_MEMORY option, the compressor SHOULD take When receiving a CONTEXT_MEMORY option, the compressor SHOULD take
actions to compress the packet stream in a way that requires less actions to compress the packet stream in a way that requiring less
decompressor memory resources, or stop compressing the packet stream. decompressor memory resources or stop compressing the packet stream.
5.8. Constant IP-ID 5.8. Constant IP-ID
The profiles for UDP-Lite support compression of the IP-ID field with The profiles for UDP-Lite support compression of the IP-ID field with
constant behavior with the addition of the Static IP Identifier (SID) constant behavior, with the addition of the Static IP Identifier
flag within the dynamic part of the chain used to initialize the IPv4 (SID) flag within the dynamic part of the chain used to initialize
header, as follow (see also [3], section 3.3): the IPv4 header, as follows (see also [3], section 3.3):
Dynamic part: Dynamic part:
+---+---+---+---+---+---+---+---+ +---+---+---+---+---+---+---+---+
| Type of Service | | Type of Service |
+---+---+---+---+---+---+---+---+ +---+---+---+---+---+---+---+---+
| Time to Live | | Time to Live |
+---+---+---+---+---+---+---+---+ +---+---+---+---+---+---+---+---+
/ Identification / 2 octets / Identification / 2 octets
+---+---+---+---+---+---+---+---+ +---+---+---+---+---+---+---+---+
skipping to change at page 14, line 25 skipping to change at page 14, line 4
| Type of Service | | Type of Service |
+---+---+---+---+---+---+---+---+ +---+---+---+---+---+---+---+---+
| Time to Live | | Time to Live |
+---+---+---+---+---+---+---+---+ +---+---+---+---+---+---+---+---+
/ Identification / 2 octets / Identification / 2 octets
+---+---+---+---+---+---+---+---+ +---+---+---+---+---+---+---+---+
| DF|RND|NBO|SID| 0 | | DF|RND|NBO|SID| 0 |
+---+---+---+---+---+---+---+---+ +---+---+---+---+---+---+---+---+
/ Generic extension header list / variable length / Generic extension header list / variable length
+---+---+---+---+---+---+---+---+ +---+---+---+---+---+---+---+---+
SID: Static IP Identifier. SID: Static IP Identifier.
For IR and IR-DYN packets: For IR and IR-DYN packets:
For IR and IR-DYN packets, the logic is the same as for the The logic is the same as that for the respective ROHC
respective ROHC profiles for UDP, with the addition that profiles for UDP, with the addition that field (SID)
field(SID) must be kept in the context. must be kept in the context.
For compressed headers other than IR and IR-DYN: For compressed headers other than IR and IR-DYN:
If value(RND) = 0 and context(SID) = 0, hdr(IP-ID) is If value(RND) = 0 and context(SID) = 0, hdr(IP-ID) is
compressed using Offset IP-ID encoding (see [2], section compressed by using Offset IP-ID encoding (see [2], section
4.5.5) using p = 0 and default-slope(IP-ID offset) = 0. 4.5.5) using p = 0 and default-slope(IP-ID offset) = 0.
If value(RND) = 0 and context(SID) = 1, hdr(IP-ID) is constant If value(RND) = 0 and context(SID) = 1, hdr(IP-ID) is constant
and compressed away; hdr(IP-ID) is the value of context(IP-ID). and compressed away; hdr(IP-ID) is the value of context(IP-ID).
If value(RND) = 1, IP-ID is the uncompressed hdr(IP-ID). IP-ID If value(RND) = 1, IP-ID is the uncompressed hdr(IP-ID). IP-ID
is then passed as additional octets at the end of the is then passed as additional octets at the end of the
compressed header, after any extensions. compressed header, after any extensions.
Note: Only IR and IR-DYN packets can update context(SID). Note: Only IR and IR-DYN packets can update context(SID).
Note: All other fields are the same as for the respective ROHC Note: All other fields are the same as for the respective ROHC
profiles for UDP [2]. profiles for UDP [2].
6. Security Considerations 6. Security Considerations
The security considerations of RFC 3095 [2] apply integrally to this The security considerations of RFC 3095 [2] apply integrally to this
document without modifications. document, without modification.
7. IANA Considerations 7. IANA Considerations
ROHC profile identifiers 0x0007 (ROHC RTP/UDP-Lite) and 0x0008 (ROHC ROHC profile identifiers 0x0007 (ROHC RTP/UDP-Lite) and 0x0008 (ROHC
UDP-Lite) have been reserved by the IANA for the profiles defined in UDP-Lite) have been reserved by the IANA for the profiles defined in
this document. this document (RFC 4019).
{ NOTE TO IANA - TO BE REMOVED BEFORE PUBLICATION }
Two ROHC profile identifiers must be reserved by the IANA for the Two ROHC profile identifiers must be reserved by the IANA for the
profiles defined in this document. Since profile number 0x0006 is profiles defined in this document. Since profile number 0x0006 is
being saved for the TCP/IP (ROHC-TCP) profile, profile numbers being saved for the TCP/IP (ROHC-TCP) profile, profile numbers 0x0007
0x0007 and 0x0008 are the most suitable unused identifiers and 0x0008 are the most suitable unused identifiers available, and
available, and should thus be used. As for previous ROHC profiles, should thus be used. As for previous ROHC profiles, profile numbers
profile numbers 0xnn07 and 0xnn08 must also be reserved for future 0xnn07 and 0xnn08 must also be reserved for future variants of these
variants of these profiles. The registration suggested for the profiles. The registration suggested for the "RObust Header
"RObust Header Compression (ROHC) Profile Identifiers" name space: Compression (ROHC) Profile Identifiers" name space:
OLD: 0x0006-0xnn7F To be Assigned by IANA OLD: 0x0006-0xnn7F To be Assigned by IANA
NEW: 0xnn06 To be Assigned by IANA NEW: 0xnn06 To be Assigned by IANA
0x0007 ROHC RTP/UDP-Lite [RFCXXXX (this)] 0x0007 ROHC RTP/UDP-Lite [RFC4019]
0xnn07 Reserved 0xnn07 Reserved
0x0008 ROHC UDP-Lite [RFCXXXX (this)] 0x0008 ROHC UDP-Lite [RFC4019]
0xnn08 Reserved 0xnn08 Reserved
0x0009-0xnn7F To be Assigned by IANA 0x0009-0xnn7F To be Assigned by IANA
{ END OF NOTE }
8. Acknowledgments 8. Acknowledgments
The author would like to thank Lars-Erik Jonsson, Kristofer Sandlund, The author would like to thank Lars-Erik Jonsson, Kristofer Sandlund,
Mark West, Richard Price, Gorry Fairhurst, Fredrik Linstroem and Mats Mark West, Richard Price, Gorry Fairhurst, Fredrik Linstroem and Mats
Nordberg for useful reviews and discussions around this document. Nordberg for useful reviews and discussions around this document.
9. Author's Address 9. References
Ghyslain Pelletier
Ericsson AB
Box 920
SE-971 28 Lulea, Sweden
Phone: +46 920 20 24 32
Fax : +46 920 20 20 99
Email: ghyslain.pelletier@ericsson.com
10. References
10.1. Normative References 9.1. Normative References
[1] S. Bradner, "Key words for use in RFCs to Indicate Requirement [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", RFC 2119, March 1997. Levels", BCP 14, RFC 2119, March 1997.
[2] Bormann, C., Burmeister, C., Degermark, M., Fukushima, H., [2] Bormann, C., Burmeister, C., Degermark, M., Fukushima, H.,
Hannu, H., Jonsson, L., Hakenberg, R., Koren, T., Le, K., Liu, Hannu, H., Jonsson, L-E., Hakenberg, R., Koren, T., Le, K., Liu,
Z., Martensson, A., Miyazaki, A., Svanbro, K., Wiebke, T., Z., Martensson, A., Miyazaki, A., Svanbro, K., Wiebke, T.,
Yoshimura, T. and H. Zheng, "RObust Header Compression (ROHC): Yoshimura, T., and H. Zheng, "RObust Header Compression (ROHC):
Framework and four profiles: RTP, UDP, ESP, and uncompressed", Framework and four profiles: RTP, UDP, ESP, and uncompressed",
RFC 3095, July 2001. RFC 3095, July 2001.
<# Editor's Note: RFC number to be updated before publication #> [3] Jonsson, L-E. and G. Pelletier, "RObust Header Compression
<# for <draft-ietf-rohc-ip-only-05.txt> #> (ROHC): A Compression Profile for IP", RFC 3843, June 2004.
[3] Jonsson, L. and G. Pelletier, "RObust Header Compression (ROHC):
A compression profile for IP", RFCZZZZ, %Month% 2004.
<# Editor's Note: RFC number to be updated before publication #>
<# for <draft-ietf-tsvwg-udp-lite-02.txt> #>
[4] Larzon, L., Degermark, M., Pink, S., Jonsson, L. and G. [4] Larzon, L-A., Degermark, M., Pink, S., Jonsson, L-E., and G.
Fairhurst, "The UDP-Lite Protocol", RFCUUUU, %Month% 2004. Fairhurst, "The Lightweight User Datagram Protocol (UDP-Lite)",
RFC 3828, July 2004.
10.2. Informative References 9.2. Informative References
[5] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981. [5] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981.
[6] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) [6] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6)
Specification", RFC 2460, December 1998. Specification", RFC 2460, December 1998.
[7] Postel, J., "User Datagram Protocol", STD 6, RFC 768, August [7] Postel, J., "User Datagram Protocol", STD 6, RFC 768, August
1980. 1980.
[8] Schulzrinne, H., Casner S., Frederick, R. and V. Jacobson, "RTP: [8] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson,
A Transport Protocol for Real-Time Applications", RFC 1889, "RTP: A Transport Protocol for Real-Time Applications", STD 64,
January 1996. RFC 3550, July 2003.
Appendix A - Detailed Classification of Header Fields Appendix A. Detailed Classification of Header Fields
This section summarizes the difference from the classification found This section summarizes the difference from the classification found
in the corresponding appendix in RFC 3095 [2], and similarly provides in the corresponding appendix in RFC 3095 [2] and similarly provides
conclusions about how the various header fields should be handled by conclusions about how the various header fields should be handled by
the header compression scheme to optimize compression and the header compression scheme to optimize compression and
functionality. These conclusions are separated based on the behavior functionality. These conclusions are separated based on the behavior
of the UDP-Lite Checksum Coverage field and uses the expected change of the UDP-Lite Checksum Coverage field and use the expected change
patterns described in section 3.2 of this document. patterns described in section 3.2 of this document.
A.1. UDP-Lite Header Fields A.1. UDP-Lite Header Fields
The following table summarizes a possible classification for the UDP- The following table summarizes a possible classification for the UDP-
Lite header fields in comparison with the classification for UDP, Lite header fields in comparison with the classification for UDP,
using the same classes as in RFC 3095 [2]. using the same classes as in RFC 3095 [2].
Header fields of UDP-Lite and UDP: Header fields of UDP-Lite and UDP:
skipping to change at page 17, line 47 skipping to change at page 17, line 47
Source and Destination Port Source and Destination Port
Same as for UDP. Specifically, these fields are part of the Same as for UDP. Specifically, these fields are part of the
definition of a stream and must thus be constant for all packets in definition of a stream and must thus be constant for all packets in
the stream. The fields are therefore classified as STATIC-DEF. the stream. The fields are therefore classified as STATIC-DEF.
Checksum Coverage Checksum Coverage
This field specifies which part of the UDP-Lite datagram is covered This field specifies which part of the UDP-Lite datagram is covered
by the checksum. It may have a value of zero or equal to the by the checksum. It may have a value of zero or be equal to the
datagram length if the checksum covers the entire datagram, or it datagram length if the checksum covers the entire datagram, or it
may have any value between eight octets and the length of the may have any value between eight octets and the length of the
datagram to specify the number of octets protected by the checksum, datagram to specify the number of octets protected by the checksum,
calculated from the first octet of the UDP-Lite header. The value 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 of this field may vary for each packet, and this makes the value
unpredictable from a header compression perspective. unpredictable from a header-compression perspective.
Checksum Checksum
The information used for the calculation of the UDP-Lite checksum The information used for the calculation of the UDP-Lite checksum
is governed by the value of the checksum coverage, and minimally is governed by the value of the checksum coverage and minimally
includes the UDP-Lite header. The checksum is a changing field that includes the UDP-Lite header. The checksum is a changing field
must always be sent as-is. that must always be sent as-is.
The total size of the fields in each class, for each expected change The total size of the fields in each class, for each expected change
patterns (see section 3.2), is summarized in the tables below: pattern (see section 3.2), is summarized in the tables below:
Pattern 1: Pattern 1:
+------------+---------------+ +------------+---------------+
| Class | Size (octets) | | Class | Size (octets) |
+------------+---------------+ +------------+---------------+
| INFERRED | 2 | Checksum Coverage | INFERRED | 2 | Checksum Coverage
| STATIC-DEF | 4 | Source Port / Destination Port | STATIC-DEF | 4 | Source Port / Destination Port
| CHANGING | 2 | Checksum | CHANGING | 2 | Checksum
+------------+---------------+ +------------+---------------+
skipping to change at page 19, line 8 skipping to change at page 19, line 8
+------------+---------------+ +------------+---------------+
| Class | Size (octets) | | Class | Size (octets) |
+------------+---------------+ +------------+---------------+
| STATIC-DEF | 4 | Source Port / Destination Port | STATIC-DEF | 4 | Source Port / Destination Port
| CHANGING | 4 | Checksum Coverage / Checksum | CHANGING | 4 | Checksum Coverage / Checksum
+------------+---------------+ +------------+---------------+
A.2. Header Compression Strategies for UDP-Lite A.2. Header Compression Strategies for UDP-Lite
The following table revisits the corresponding table (table A.1) for The following table revisits the corresponding table (table A.1) for
UDP from [2] (section A.2), and classifies the changing fields based UDP from [2] (section A.2) and classifies the changing fields based
on the change patterns previously identified in section 3.2. on the change patterns previously identified in section 3.2.
Header compression strategies for UDP-Lite: Header compression strategies for UDP-Lite:
+----------+---------+-------------+-----------+-----------+ +----------+---------+-------------+-----------+-----------+
| Field | Pattern | Value/Delta | Class | Knowledge | | Field | Pattern | Value/Delta | Class | Knowledge |
+==========+=========+=============+===========+===========+ +==========+=========+=============+===========+===========+
| | #1 | Value | CHANGING | INFERRED | | | #1 | Value | CHANGING | INFERRED |
| Checksum |---------+-------------+-----------+-----------+ | Checksum |---------+-------------+-----------+-----------+
| Coverage | #2 | Value | RC | UNKNOWN | | Coverage | #2 | Value | RC | UNKNOWN |
| |---------+-------------+-----------+-----------+ | |---------+-------------+-----------+-----------+
| | #3 | Value | IRREGULAR | UNKNOWN | | | #3 | Value | IRREGULAR | UNKNOWN |
+----------+---------+-------------+-----------+-----------+ +----------+---------+-------------+-----------+-----------+
| Checksum | All | Value | IRREGULAR | UNKNOWN | | Checksum | All | Value | IRREGULAR | UNKNOWN |
+----------+---------+-------------+-----------+-----------+ +----------+---------+-------------+-----------+-----------+
A.2.1. Transmit initially, but be prepared to update A.2.1. Transmit initially but be prepared to update
UDP-Lite Checksum Coverage (Patterns #1 and #2) UDP-Lite Checksum Coverage (Patterns #1 and #2)
A.2.2. Transmit as-is in all packets A.2.2. Transmit as-is in all packets
UDP-Lite Checksum UDP-Lite Checksum
UDP-Lite Checksum Coverage (Pattern #3) UDP-Lite Checksum Coverage (Pattern #3)
Appendix B - Detailed Format of the CCE Packet Type Appendix B. Detailed Format of the CCE Packet Type
This section provides an expanded view of the format of the CCE This section provides an expanded view of the format of the CCE
packet, based on the general ROHC RTP compressed header [2] and the packet, based on the general ROHC RTP compressed header [2] and the
general format of a compressed header of the ROHC IP-Only profile general format of a compressed header of the ROHC IP-Only profile
[3]. The modifications necessary to carry the base header of a packet [3]. The modifications necessary to carry the base header of a
of type 2, 1 or 0 [2] within the CCE packet format along with the packet of type 2, 1 or 0 [2] within the CCE packet format, along with
additional fields to properly handle compression of multiple IP the additional fields to properly handle compression of multiple IP
headers results in the following structure for the CCE packet type: headers, result in the following structure for the CCE packet type:
0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
--- --- --- --- --- --- --- --- --- --- --- --- --- --- --- ---
: Add-CID octet : if for small CIDs and CID 1-15 : Add-CID octet : If for small CIDs and CID 1 - 15
+---+---+---+---+---+---+---+---+ +---+---+---+---+---+---+---+---+
| 1 1 1 1 1 0 F | K | Outer packet type identifier | 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 / 0, 1, or 2 octets of CID / 1-2 octets if large CIDs
: : : :
+---+---+---+---+---+---+---+---+ +---+---+---+---+---+---+---+---+
| First octet of base header | (with "inner" type indication) | First octet of base header | (with "inner" type indication)
+---+---+---+---+---+---+---+---+ +---+---+---+---+---+---+---+---+
/ Remainder of base header / variable number of bits / Remainder of base header / Variable number of bits
+---+---+---+---+---+---+---+---+ +---+---+---+---+---+---+---+---+
0 1 2 3 4 5 6 7
--- --- --- --- --- --- --- ---
: : : :
/ Extension / See RFC 3095 [2], section 5.7. / Extension / See RFC 3095 [2], section 5.7.
: : : :
--- --- --- --- --- --- --- --- --- --- --- --- --- --- --- ---
: : : :
+ IP-ID of outer IPv4 header + See RFC 3095 [2], section 5.7. + IP-ID of outer IPv4 header + See RFC 3095 [2], section 5.7.
: : : :
--- --- --- --- --- --- --- --- --- --- --- --- --- --- --- ---
/ AH data for outer list / See RFC 3095 [2], section 5.7. / AH data for outer list / See RFC 3095 [2], section 5.7.
--- --- --- --- --- --- --- --- --- --- --- --- --- --- --- ---
skipping to change at page 20, line 54 skipping to change at page 21, line 31
+ IP-ID of inner IPv4 header + See RFC 3095 [2], section 5.7. + IP-ID of inner IPv4 header + See RFC 3095 [2], section 5.7.
: : : :
--- --- --- --- --- --- --- --- --- --- --- --- --- --- --- ---
/ AH data for inner list / See RFC 3095 [2], section 5.7. / AH data for inner list / See RFC 3095 [2], section 5.7.
--- --- --- --- --- --- --- --- --- --- --- --- --- --- --- ---
: : : :
+ GRE checksum + See RFC 3095 [2], section 5.7. + GRE checksum + See RFC 3095 [2], section 5.7.
: : : :
--- --- --- --- --- --- --- --- --- --- --- --- --- --- --- ---
: List of : Variable, given by static chain : List of : Variable, given by static chain
/ dynamic chains / (includes no SN) / dynamic chains / (includes no SN).
: for additional IP headers : See [3], section 3.2. : for additional IP headers : See [3], section 3.2.
--- --- --- --- --- --- --- --- --- --- --- --- --- --- --- ---
: : : :
+ UDP-Lite Checksum Coverage + 2 octets + UDP-Lite Checksum Coverage + 2 octets
: : : :
+---+---+---+---+---+---+---+---+ +---+---+---+---+---+---+---+---+
: : : :
+ UDP-Lite Checksum + 2 octets + UDP-Lite Checksum + 2 octets
: : : :
+---+---+---+---+---+---+---+---+ +---+---+---+---+---+---+---+---+
skipping to change at page 22, line 5 skipping to change at page 22, line 5
F,K: F,K = 00 is reserved at framework level (IR-DYN); F,K: F,K = 00 is reserved at framework level (IR-DYN);
F,K = 01 indicates CCE(); F,K = 01 indicates CCE();
F,K = 10 indicates CCE(ON); F,K = 10 indicates CCE(ON);
F,K = 11 indicates CCE(OFF). F,K = 11 indicates CCE(OFF).
Note that this document does not define (F,K) = 00, as this would 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 collide with the IR-DYN packet type already reserved at the ROHC
framework level. framework level.
Intellectual Property Statement Author's Address
Ghyslain Pelletier
Ericsson AB
Box 920
SE-971 28 Lulea, Sweden
Phone: +46 840 429 43
Fax : +46 920 996 21
EMail: ghyslain.pelletier@ericsson.com
Full Copyright Statement
Copyright (C) The Internet Society (2005).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information made any independent effort to identify any such rights. Information
on the IETF's procedures with respect to rights in IETF Documents can on the procedures with respect to rights in RFC documents can be
be found in RFC 3667 (BCP 78) and RFC 3668 (BCP 79). found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr. http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at ietf- this standard. Please address the information to the IETF at ietf-
ipr@ietf.org. ipr@ietf.org.
Copyright Statement Acknowledgement
Copyright (C) The Internet Society (2004). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
Disclaimer of Validity
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
This Internet-Draft expires December 9, 2004. Funding for the RFC Editor function is currently provided by the
Internet Society.
 End of changes. 

This html diff was produced by rfcdiff 1.25, available from http://www.levkowetz.com/ietf/tools/rfcdiff/