5.3.2.1. Properties of CCE()
Aside from the updating properties of the inner packet type carried
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
2, 1, and 0, regardless of the current mode of operation [2].
CCE() may be used when the checksum coverage deviates from the change
pattern assumed by the compressor, where the field could previously
be compressed. This packet is useful if the occurrence of such
deviations is rare.
5.3.2.2. Properties of CCE(ON)
In addition to the updating properties of the inner packet type,
CCE(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 precludes its compression.
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
[2]. Specifically, R-0 and R-1* headers MUST NOT be extended by
using CCE(ON).
5.3.2.3. Properties of CCE(OFF)
In addition to the updating properties of the inner packet type,
CCE(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.
CCE(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. Note that when context(CFI) is updated by using
packet type CCE(OFF), a match of field(Checksum Coverage) with the
packet length always has precedence over a match with
context(Checksum Coverage). Finally, context(UDP-Lite Checksum
Coverage) is also updated by CCE(OFF).
Similarly to CCE(ON), CCE(OFF) can extend any of the context updating
packets of type 2, 1, and 0 [2].
5.4. Compressor Logic
If hdr(UDP-Lite Checksum Coverage) is different from context(UDP-Lite
Checksum Coverage) and different from the packet length when
context(CFP) is zero, the Checksum Coverage field cannot be
compressed. In addition, if hdr(UDP-Lite Checksum Coverage) is
different from the packet length when context(CFP) is zero and
context(CFI) is nonzero, the Checksum Coverage field cannot be
compressed by either. For both cases, the field must be sent
uncompressed using a CCE packet, or the context must be reinitialized
by using an IR packet.
5.5. Decompressor Logic
For packet types other than IR, IR-DYN, and CCE that are received
when the value of context(CFP) is zero, the Checksum Coverage field
must be decompressed by 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.
5.6. Additional Mode Transition Logic
The profiles defined in this document allow the compressor to decline
a mode transition requested by the decompressor. This is achieved by
redefining the Mode parameter for the value mode = 0 (in packet types
UOR-2, IR, and IR-DYN) as follows (see also [3], section 3.4):
Mode: Compression mode. 0 = (C)ancel Mode Transition
Upon receiving the Mode parameter set to 0, the decompressor MUST
stay in its current mode of operation and SHOULD refrain from sending
further mode transition requests for the declined mode.
5.7. The CONTEXT_MEMORY Feedback Option
This feedback option informs the compressor that the decompressor
does not have sufficient memory resources to handle the context of
the packet stream required by the current compressed structure.
0 1 2 3 4 5 6 7
+---+---+---+---+---+---+---+---+
| Opt Type = 9 | Opt Len = 0 |
+---+---+---+---+---+---+---+---+
When receiving a CONTEXT_MEMORY option, the compressor SHOULD take
actions to compress the packet stream in a way that requiring less
decompressor memory resources or stop compressing the packet stream.
5.8. Constant IP-ID
The profiles for UDP-Lite support compression of the IP-ID field with
constant behavior, with the addition of the Static IP Identifier
(SID) flag within the dynamic part of the chain used to initialize
the IPv4 header, as follows (see also [3], section 3.3):
Dynamic part:
+---+---+---+---+---+---+---+---+
| Type of Service |
+---+---+---+---+---+---+---+---+
| Time to Live |
+---+---+---+---+---+---+---+---+
/ Identification / 2 octets
+---+---+---+---+---+---+---+---+
| DF|RND|NBO|SID| 0 |
+---+---+---+---+---+---+---+---+
/ Generic extension header list / variable length
+---+---+---+---+---+---+---+---+
SID: Static IP Identifier.
For IR and IR-DYN packets:
The logic is the same as that for the respective ROHC
profiles for UDP, with the addition that field (SID)
must be kept in the context.
For compressed headers other than IR and IR-DYN:
If value(RND) = 0 and context(SID) = 0, hdr(IP-ID) is
compressed by using Offset IP-ID encoding (see [2], section
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
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
is then passed as additional octets at the end of the
compressed header, after any extensions.
Note: Only IR and IR-DYN packets can update context(SID).
Note: All other fields are the same as for the respective ROHC
profiles for UDP [2].
6. Security Considerations
The security considerations of RFC 3095 [2] apply integrally to this
document, without modification.
7. IANA Considerations
ROHC profile identifiers 0x0007 (ROHC RTP/UDP-Lite) and 0x0008 (ROHC
UDP-Lite) have been reserved by the IANA for the profiles defined in
this document (RFC 4019).
Two ROHC profile identifiers must be reserved by the IANA for the
profiles defined in this document. Since profile number 0x0006 is
being saved for the TCP/IP (ROHC-TCP) profile, profile numbers 0x0007
and 0x0008 are the most suitable unused identifiers available, and
should thus be used. As for previous ROHC profiles, profile numbers
0xnn07 and 0xnn08 must also be reserved for future variants of these
profiles. The registration suggested for the "RObust Header
Compression (ROHC) Profile Identifiers" name space:
OLD: 0x0006-0xnn7F To be Assigned by IANA
NEW: 0xnn06 To be Assigned by IANA
0x0007 ROHC RTP/UDP-Lite [RFC4019]
0xnn07 Reserved
0x0008 ROHC UDP-Lite [RFC4019]
0xnn08 Reserved
0x0009-0xnn7F To be Assigned by IANA
8. Acknowledgments
The author would like to thank Lars-Erik Jonsson, Kristofer Sandlund,
Mark West, Richard Price, Gorry Fairhurst, Fredrik Linstroem and Mats
Nordberg for useful reviews and discussions around this document.
9. References
9.1. Normative References
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[2] Bormann, C., Burmeister, C., Degermark, M., Fukushima, H.,
Hannu, H., Jonsson, L-E., Hakenberg, R., Koren, T., Le, K., Liu,
Z., Martensson, A., Miyazaki, A., Svanbro, K., Wiebke, T.,
Yoshimura, T., and H. Zheng, "RObust Header Compression (ROHC):
Framework and four profiles: RTP, UDP, ESP, and uncompressed",
RFC 3095, July 2001.
[3] Jonsson, L-E. and G. Pelletier, "RObust Header Compression
(ROHC): A Compression Profile for IP", RFC 3843, June 2004.
[4] Larzon, L-A., Degermark, M., Pink, S., Jonsson, L-E., and G.
Fairhurst, "The Lightweight User Datagram Protocol (UDP-Lite)",
RFC 3828, July 2004.
9.2. Informative References
[5] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981.
[6] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6)
Specification", RFC 2460, December 1998.
[7] Postel, J., "User Datagram Protocol", STD 6, RFC 768, August
1980.
[8] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson,
"RTP: A Transport Protocol for Real-Time Applications", STD 64,
RFC 3550, July 2003.
Appendix A. Detailed Classification of Header Fields
This section summarizes the difference from the classification found
in the corresponding appendix in RFC 3095 [2] 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 use the expected change
patterns described in section 3.2 of this document.
A.1. UDP-Lite Header Fields
The following table summarizes a possible classification for the UDP-
Lite header fields in comparison with the classification for UDP,
using the same classes as in RFC 3095 [2].
Header fields of UDP-Lite and UDP:
+-------------------+-------------+
| 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 |
+-------------------+--------+-------------------+-------------+
Source and Destination Port
Same as for UDP. Specifically, these fields are part of the
definition of a stream and must thus be constant for all packets in
the stream. The fields are therefore classified as STATIC-DEF.
Checksum Coverage
This field specifies which part of the UDP-Lite datagram is covered
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
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.
Checksum
The information used for the calculation of the UDP-Lite checksum
is governed by the value of the checksum coverage and minimally
includes the UDP-Lite header. The checksum is a changing field
that must always be sent as-is.
The total size of the fields in each class, for each expected change
pattern (see section 3.2), is summarized in the tables below:
Pattern 1:
+------------+---------------+
| Class | Size (octets) |
+------------+---------------+
| INFERRED | 2 | Checksum Coverage
| STATIC-DEF | 4 | Source Port / Destination Port
| CHANGING | 2 | Checksum
+------------+---------------+
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 [2] (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 (Patterns #1 and #2)
A.2.2. Transmit as-is in all packets
UDP-Lite Checksum
UDP-Lite Checksum Coverage (Pattern #3)
Appendix B. Detailed Format of the CCE Packet Type
This section provides an expanded view of the format of the CCE
packet, based on the general ROHC RTP compressed header [2] and the
general format of a compressed header of the ROHC IP-Only profile
[3]. The modifications necessary to carry the base header of a
packet of type 2, 1 or 0 [2] within the CCE packet format, along with
the additional fields to properly handle compression of multiple IP
headers, result in the following structure for the CCE 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
+---+---+---+---+---+---+---+---+
0 1 2 3 4 5 6 7
--- --- --- --- --- --- --- ---
: :
/ Extension / 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.
--- --- --- --- --- --- --- ---
: :
+ GRE checksum + 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.
--- --- --- --- --- --- --- ---
: :
+ GRE checksum + See RFC 3095 [2], section 5.7.
: :
--- --- --- --- --- --- --- ---
: List of : Variable, given by static chain
/ dynamic chains / (includes no SN).
: for additional IP headers : See [3], section 3.2.
--- --- --- --- --- --- --- ---
: :
+ 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 CCE();
F,K = 10 indicates CCE(ON);
F,K = 11 indicates CCE(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.
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
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at ietf-
ipr@ietf.org.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.