draft-ietf-rohc-rfc3095bis-rohcv2-profiles-06.txt   rfc5225.txt 
Robust Header Compression G. Pelletier Network Working Group G. Pelletier
Internet-Draft K. Sandlund Request for Comments: 5225 K. Sandlund
Intended status: Standards Track Ericsson Category: Standards Track Ericsson
Expires: September 20, 2008 March 19, 2008 RObust Header Compression Version 2 (ROHCv2):
Profiles for RTP, UDP, IP, ESP and UDP-Lite
RObust Header Compression Version 2 (ROHCv2): Profiles for RTP, UDP, IP,
ESP and UDP Lite
draft-ietf-rohc-rfc3095bis-rohcv2-profiles-06
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on September 20, 2008.
Copyright Notice Status of This Memo
Copyright (C) The IETF Trust (2008). This document specifies an Internet standards track protocol for the
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.
Abstract Abstract
This document specifies ROHC (Robust Header Compression) profiles This document specifies ROHC (Robust Header Compression) profiles
that efficiently compress RTP/UDP/IP (Real-Time Transport Protocol, that efficiently compress RTP/UDP/IP (Real-Time Transport Protocol,
User Datagram Protocol, Internet Protocol), RTP/UDP-Lite/IP (User User Datagram Protocol, Internet Protocol), RTP/UDP-Lite/IP (User
Datagram Protocol Lite), UDP/IP, UDP-Lite/IP, IP and ESP/IP Datagram Protocol Lite), UDP/IP, UDP-Lite/IP, IP and ESP/IP
(Encapsulating Security Payload) headers. (Encapsulating Security Payload) headers.
This specification defines a second version of the profiles found in This specification defines a second version of the profiles found in
RFC 3095, RFC 3843 and RFC 4019; it supersedes their definition, but RFC 3095, RFC 3843 and RFC 4019; it supersedes their definition, but
does not obsolete them. does not obsolete them.
The ROHCv2 profiles introduce a number of simplifications to the The ROHCv2 profiles introduce a number of simplifications to the
rules and algorithms that govern the behavior of the compression rules and algorithms that govern the behavior of the compression
endpoints. It also defines robustness mechanisms that may be used by endpoints. It also defines robustness mechanisms that may be used by
a compressor implementation to increase the probability of a compressor implementation to increase the probability of
decompression success when packets can be lost and/or reordered on decompression success when packets can be lost and/or reordered on
the ROHC channel. Finally, the ROHCv2 profiles define its own the ROHC channel. Finally, the ROHCv2 profiles define their own
specific set of header formats, using the ROHC formal notation. specific set of header formats, using the ROHC formal notation.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Acronyms . . . . . . . . . . . . . . . . . . . . . . . . . . 6 3. Acronyms . . . . . . . . . . . . . . . . . . . . . . . . . . 7
4. Background (Informative) . . . . . . . . . . . . . . . . . . 7 4. Background (Informative) . . . . . . . . . . . . . . . . . . 7
4.1. Classification of Header Fields . . . . . . . . . . . . . 7 4.1. Classification of Header Fields . . . . . . . . . . . . . 7
4.2. Improvements of ROHCv2 over RFC 3095 Profiles . . . . . . 8 4.2. Improvements of ROHCv2 over RFC 3095 Profiles . . . . . . 8
4.3. Operational Characteristics of ROHCv2 Profiles . . . . . 10 4.3. Operational Characteristics of ROHCv2 Profiles . . . . . 10
5. Overview of the ROHCv2 Profiles (Informative) . . . . . . . . 10 5. Overview of the ROHCv2 Profiles (Informative) . . . . . . . . 10
5.1. Compressor Concepts . . . . . . . . . . . . . . . . . . . 11 5.1. Compressor Concepts . . . . . . . . . . . . . . . . . . . 11
5.1.1. Optimistic Approach . . . . . . . . . . . . . . . . . 11 5.1.1. Optimistic Approach . . . . . . . . . . . . . . . . . 11
5.1.2. Tradeoff between Robustness to Losses and to 5.1.2. Tradeoff between Robustness to Losses and to
Reordering . . . . . . . . . . . . . . . . . . . . . 11 Reordering . . . . . . . . . . . . . . . . . . . . . 11
5.1.3. Interactions with the Decompressor Context . . . . . 13 5.1.3. Interactions with the Decompressor Context . . . . . 13
5.2. Decompressor Concepts . . . . . . . . . . . . . . . . . . 14 5.2. Decompressor Concepts . . . . . . . . . . . . . . . . . . 14
5.2.1. Decompressor State Machine . . . . . . . . . . . . . 14 5.2.1. Decompressor State Machine . . . . . . . . . . . . . 14
5.2.2. Decompressor Context Management . . . . . . . . . . . 17 5.2.2. Decompressor Context Management . . . . . . . . . . . 17
5.2.3. Feedback Logic . . . . . . . . . . . . . . . . . . . 19 5.2.3. Feedback Logic . . . . . . . . . . . . . . . . . . . 19
6. ROHCv2 Profiles (Normative) . . . . . . . . . . . . . . . . . 19 6. ROHCv2 Profiles (Normative) . . . . . . . . . . . . . . . . . 19
6.1. Channel Parameters, Segmentation and Reordering . . . . . 19 6.1. Channel Parameters, Segmentation, and Reordering . . . . 19
6.2. Profile Operation, Per-context . . . . . . . . . . . . . 19 6.2. Profile Operation, Per-context . . . . . . . . . . . . . 20
6.3. Control Fields . . . . . . . . . . . . . . . . . . . . . 20 6.3. Control Fields . . . . . . . . . . . . . . . . . . . . . 21
6.3.1. Master Sequence Number (MSN) . . . . . . . . . . . . 21 6.3.1. Master Sequence Number (MSN) . . . . . . . . . . . . 21
6.3.2. Reordering Ratio . . . . . . . . . . . . . . . . . . 21 6.3.2. Reordering Ratio . . . . . . . . . . . . . . . . . . 21
6.3.3. IP-ID Behavior . . . . . . . . . . . . . . . . . . . 22 6.3.3. IP-ID Behavior . . . . . . . . . . . . . . . . . . . 22
6.3.4. UDP-Lite Coverage Behavior . . . . . . . . . . . . . 22 6.3.4. UDP-Lite Coverage Behavior . . . . . . . . . . . . . 22
6.3.5. Timestamp Stride . . . . . . . . . . . . . . . . . . 22 6.3.5. Timestamp Stride . . . . . . . . . . . . . . . . . . 22
6.3.6. Time Stride . . . . . . . . . . . . . . . . . . . . . 22 6.3.6. Time Stride . . . . . . . . . . . . . . . . . . . . . 22
6.3.7. CRC-3 for Control Fields . . . . . . . . . . . . . . 22 6.3.7. CRC-3 for Control Fields . . . . . . . . . . . . . . 23
6.4. Reconstruction and Verification . . . . . . . . . . . . . 23 6.4. Reconstruction and Verification . . . . . . . . . . . . . 23
6.5. Compressed Header Chains . . . . . . . . . . . . . . . . 23 6.5. Compressed Header Chains . . . . . . . . . . . . . . . . 24
6.6. Header Formats and Encoding Methods . . . . . . . . . . . 25 6.6. Header Formats and Encoding Methods . . . . . . . . . . . 25
6.6.1. baseheader_extension_headers . . . . . . . . . . . . 25 6.6.1. baseheader_extension_headers . . . . . . . . . . . . 26
6.6.2. baseheader_outer_headers . . . . . . . . . . . . . . 26 6.6.2. baseheader_outer_headers . . . . . . . . . . . . . . 26
6.6.3. inferred_udp_length . . . . . . . . . . . . . . . . . 26 6.6.3. inferred_udp_length . . . . . . . . . . . . . . . . . 26
6.6.4. inferred_ip_v4_header_checksum . . . . . . . . . . . 26 6.6.4. inferred_ip_v4_header_checksum . . . . . . . . . . . 26
6.6.5. inferred_mine_header_checksum . . . . . . . . . . . . 27 6.6.5. inferred_mine_header_checksum . . . . . . . . . . . . 27
6.6.6. inferred_ip_v4_length . . . . . . . . . . . . . . . . 28 6.6.6. inferred_ip_v4_length . . . . . . . . . . . . . . . . 28
6.6.7. inferred_ip_v6_length . . . . . . . . . . . . . . . . 28 6.6.7. inferred_ip_v6_length . . . . . . . . . . . . . . . . 28
6.6.8. Scaled RTP Timestamp Compression . . . . . . . . . . 28 6.6.8. Scaled RTP Timestamp Compression . . . . . . . . . . 29
6.6.9. timer_based_lsb . . . . . . . . . . . . . . . . . . . 30 6.6.9. timer_based_lsb . . . . . . . . . . . . . . . . . . . 30
6.6.10. inferred_scaled_field . . . . . . . . . . . . . . . . 31 6.6.10. inferred_scaled_field . . . . . . . . . . . . . . . . 31
6.6.11. control_crc3_encoding . . . . . . . . . . . . . . . . 32 6.6.11. control_crc3_encoding . . . . . . . . . . . . . . . . 32
6.6.12. inferred_sequential_ip_id . . . . . . . . . . . . . . 33 6.6.12. inferred_sequential_ip_id . . . . . . . . . . . . . . 33
6.6.13. list_csrc(cc_value) . . . . . . . . . . . . . . . . . 33 6.6.13. list_csrc(cc_value) . . . . . . . . . . . . . . . . . 34
6.7. Encoding Methods With External Parameters as Arguments . 37 6.7. Encoding Methods with External Parameters as Arguments . 38
6.8. Header Formats . . . . . . . . . . . . . . . . . . . . . 39 6.8. Header Formats . . . . . . . . . . . . . . . . . . . . . 40
6.8.1. Initialization and Refresh Header Format (IR) . . . . 39 6.8.1. Initialization and Refresh Header Format (IR) . . . . 40
6.8.2. Compressed Header Formats (CO) . . . . . . . . . . . 40 6.8.2. Compressed Header Formats (CO) . . . . . . . . . . . 41
6.9. Feedback Formats and Options . . . . . . . . . . . . . . 99 6.9. Feedback Formats and Options . . . . . . . . . . . . . . 100
6.9.1. Feedback Formats . . . . . . . . . . . . . . . . . . 99 6.9.1. Feedback Formats . . . . . . . . . . . . . . . . . . 100
6.9.2. Feedback Options . . . . . . . . . . . . . . . . . . 101 6.9.2. Feedback Options . . . . . . . . . . . . . . . . . . 102
7. Security Considerations . . . . . . . . . . . . . . . . . . . 103 7. Security Considerations . . . . . . . . . . . . . . . . . . . 104
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 104 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 105
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 105 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 105
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 106 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 106
10.1. Normative References . . . . . . . . . . . . . . . . . . 106 10.1. Normative References . . . . . . . . . . . . . . . . . . 106
10.2. Informative References . . . . . . . . . . . . . . . . . 107 10.2. Informative References . . . . . . . . . . . . . . . . . 107
Appendix A. Detailed Classification of Header Fields . . . . . 107 Appendix A. Detailed Classification of Header Fields . . . . . 108
Appendix A.1. IPv4 Header Fields . . . . . . . . . . . . . . . . 108 A.1. IPv4 Header Fields . . . . . . . . . . . . . . . . . . . 109
Appendix A.2. IPv6 Header Fields . . . . . . . . . . . . . . . . 110 A.2. IPv6 Header Fields . . . . . . . . . . . . . . . . . . . 112
Appendix A.3. UDP Header Fields . . . . . . . . . . . . . . . . 112 A.3. UDP Header Fields . . . . . . . . . . . . . . . . . . . 113
Appendix A.4. UDP-Lite Header Fields . . . . . . . . . . . . . . 112 A.4. UDP-Lite Header Fields . . . . . . . . . . . . . . . . . 114
Appendix A.5. RTP Header Fields . . . . . . . . . . . . . . . . 113 A.5. RTP Header Fields . . . . . . . . . . . . . . . . . . . . 115
Appendix A.6. ESP Header Fields . . . . . . . . . . . . . . . . 115 A.6. ESP Header Fields . . . . . . . . . . . . . . . . . . . . 117
Appendix A.7. IPv6 Extension Header Fields . . . . . . . . . . . 115 A.7. IPv6 Extension Header Fields . . . . . . . . . . . . . . 117
Appendix A.8. GRE Header Fields . . . . . . . . . . . . . . . . 116 A.8. GRE Header Fields . . . . . . . . . . . . . . . . . . . . 118
Appendix A.9. MINE Header Fields . . . . . . . . . . . . . . . . 117 A.9. MINE Header Fields . . . . . . . . . . . . . . . . . . . 119
Appendix A.10. AH Header Fields . . . . . . . . . . . . . . . . . 118 A.10. AH Header Fields . . . . . . . . . . . . . . . . . . . . 120
Appendix B. Compressor Implementation Guidelines . . . . . . . 118 Appendix B. Compressor Implementation Guidelines . . . . . . . 121
Appendix B.1. Reference Management . . . . . . . . . . . . . . . 119 B.1. Reference Management . . . . . . . . . . . . . . . . . . 121
Appendix B.2. Window-based LSB Encoding (W-LSB) . . . . . . . . 119 B.2. Window-based LSB Encoding (W-LSB) . . . . . . . . . . . 121
Appendix B.3. W-LSB Encoding and Timer-based Compression . . . . 119 B.3. W-LSB Encoding and Timer-based Compression . . . . . . . 122
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 120
Intellectual Property and Copyright Statements . . . . . . . . . 122
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
compression requirements. The ROHC framework was first documented in compression requirements. The ROHC framework was first documented in
[RFC3095], together with profiles for compression of RTP/UDP/IP [RFC3095], together with profiles for compression of RTP/UDP/IP
(Real-Time Transport Protocol, User Datagram Protocol, Internet (Real-Time Transport Protocol, User Datagram Protocol, Internet
Protocol), UDP/IP, IP and ESP/IP (Encapsulating Security Payload) Protocol), UDP/IP, IP and ESP/IP (Encapsulating Security Payload)
headers. Additional profiles for compression of IP headers [RFC3843] headers. Additional profiles for compression of IP headers [RFC3843]
and UDP-Lite (User Datagram Protocol Lite) headers [RFC4019] were and UDP-Lite (User Datagram Protocol Lite) headers [RFC4019] were
later specified to complete the initial set of ROHC profiles. later specified to complete the initial set of ROHC profiles.
This document defines an updated version for each of the above This document defines an updated version for each of the above
mentioned profiles, and its definition is based on the specification mentioned profiles, and the definitions depend on the ROHC framework
of the ROHC framework as found in [RFC4995]. as found in [RFC4995]. The framework is required reading to
understand the profile definitions, rules, and their role.
Specifically, this document defines header compression schemes for: Specifically, this document defines header compression schemes for:
o RTP/UDP/IP : profile 0x0101 o RTP/UDP/IP : profile 0x0101
o UDP/IP : profile 0x0102 o UDP/IP : profile 0x0102
o ESP/IP : profile 0x0103 o ESP/IP : profile 0x0103
o IP : profile 0x0104 o IP : profile 0x0104
o RTP/UDP-Lite/IP : profile 0x0107 o RTP/UDP-Lite/IP : profile 0x0107
o UDP-Lite/IP : profile 0x0108 o UDP-Lite/IP : profile 0x0108
ROHCv2 compresses the following type of extension headers: Each of the profiles above can compress the following type of
extension headers:
o AH [RFC4302] o AH [RFC4302]
o GRE [RFC2784][RFC2890] o GRE [RFC2784][RFC2890]
o MINE [RFC2004] o MINE [RFC2004]
o IPv6 Destination Options header[RFC2460] o IPv6 Destination Options header[RFC2460]
o IPv6 Hop-by-hop Options header[RFC2460] o IPv6 Hop-by-hop Options header[RFC2460]
o IPv6 Routing header [RFC2460].
o IPv6 Routing header [RFC2460]
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 [RFC2119]. document are to be interpreted as described in RFC 2119 [RFC2119].
This document is consistent with the terminology found in the ROHC This document is consistent with the terminology found in the ROHC
framework [RFC4995] and in the formal notation for ROHC [RFC4997]. framework [RFC4995] and in the formal notation for ROHC [RFC4997].
In addition, this document uses or defines the following terms: In addition, this document uses or defines the following terms:
skipping to change at page 5, line 25 skipping to change at page 5, line 32
fields. Chaining is achieved by appending an item to the chain fields. Chaining is achieved by appending an item to the chain
for each header in its order of appearance in the uncompressed for each header in its order of appearance in the uncompressed
packet. Chaining is useful to construct compressed headers from packet. Chaining is useful to construct compressed headers from
an arbitrary number of any of the protocol headers for which a an arbitrary number of any of the protocol headers for which a
ROHCv2 profile defines a compressed format. ROHCv2 profile defines a compressed format.
CRC-3 Control Fields Validation CRC-3 Control Fields Validation
The CRC-3 control fields validation refers to the validation of The CRC-3 control fields validation refers to the validation of
the control fields. This validation is performed by the the control fields. This validation is performed by the
decompressor when it receives a CO header that contains a 3-bit decompressor when it receives a Compressed (CO) header that
CRC calculated over control fields. This 3-bit CRC covers contains a 3-bit Cyclic Redundancy Check (CRC) calculated over
controls fields carried in the CO header as well as specific control fields. This 3-bit CRC covers controls fields carried in
control fields in the context. In the formal definition of the the CO header as well as specific control fields in the context.
header formats, this 3-bit CRC is labeled "control_crc3" and uses In the formal definition of the header formats, this 3-bit CRC is
the "control_crc3_encoding" (See also Section 6.6.11). labeled "control_crc3" and uses the control_crc3_encoding (See
also Section 6.6.11).
Delta Delta
The delta refers to the difference in the absolute value of a The delta refers to the difference in the absolute value of a
field between two consecutive packets being processed by the same field between two consecutive packets being processed by the same
compression endpoint. compression endpoint.
Reordering Depth Reordering Depth
The number of packets by which a packet is received late within The number of packets by which a packet is received late within
skipping to change at page 7, line 21 skipping to change at page 7, line 26
MINE Minimal Encapsulation in IP. MINE Minimal Encapsulation in IP.
MSB Most Significant Bits. MSB Most Significant Bits.
MSN Master Sequence Number. MSN Master Sequence Number.
NC No Context state (decompressor). NC No Context state (decompressor).
OA Optimistic Approach. OA Optimistic Approach.
RC Repair Context state (decompressor). RC Repair Context state (decompressor).
ROHC Header compression framework (RFC 4995). ROHC Header compression framework (RFC 4995).
ROHCv2 Set of header compression profiles defined in this document. ROHCv2 Set of header compression profiles defined in this document.
RTP Real-time Transport Protocol. RTP Real-time Transport Protocol.
SSRC Synchronization source. Field in RTP header. SSRC Synchronization source. Field in RTP header.
CSRC Contributing source. The RTP header contains an optional list CSRC Contributing source. The RTP header contains an optional
of contributing sources. list of contributing sources.
TC Traffic Class. Field in the IPv6 header. See also TOS. TC Traffic Class. Field in the IPv6 header. See also TOS.
TOS Type Of Service. Field in the IPv4 header. See also TC. TOS Type Of Service. Field in the IPv4 header. See also TC.
TS RTP Timestamp. TS RTP Timestamp.
TTL Time to Live. Field in the IPv4 header. TTL Time to Live. Field in the IPv4 header.
UDP User Datagram Protocol. UDP User Datagram Protocol.
UDP-Lite User Datagram Protocol Lite. UDP-Lite User Datagram Protocol Lite.
4. Background (Informative) 4. Background (Informative)
This section provides background information on the compression This section provides background information on the compression
profiles defined in this document. The fundamentals of general profiles defined in this document. The fundamentals of general
header compression and of the ROHC framework may be found in section header compression and of the ROHC framework may be found in sections
3 and 4 of [RFC4995], respectively. The fundamentals of the formal 3 and 4 of [RFC4995], respectively. The fundamentals of the formal
notation for ROHC are defined in [RFC4997]. [RFC4224] describes the notation for ROHC are defined in [RFC4997]. [RFC4224] describes the
impacts of out-of-order delivery on profiles based on [RFC3095]. impacts of out-of-order delivery on profiles based on [RFC3095].
4.1. Classification of Header Fields 4.1. Classification of Header Fields
Section 3.1 of [RFC4995] explains that header compression is possible Section 3.1 of [RFC4995] explains that header compression is possible
due to the fact that there is much redundancy between field values due to the fact that there is much redundancy between field values
within the headers of a packet, especially between the headers of within the headers of a packet, especially between the headers of
consecutive packets. consecutive packets.
skipping to change at page 8, line 31 skipping to change at page 8, line 35
for each packet emitted by an RTP source. The RTP M-bit is expected for each packet emitted by an RTP source. The RTP M-bit is expected
to have the same value most of the time, but it needs to be to have the same value most of the time, but it needs to be
communicated explicitly on occasion. communicated explicitly on occasion.
For UDP, the Checksum field cannot be inferred or recalculated at the For UDP, the Checksum field cannot be inferred or recalculated at the
receiving end without violating its end-to-end properties, and is receiving end without violating its end-to-end properties, and is
thus sent as-is when enabled (mandatory with IPv6). The same applies thus sent as-is when enabled (mandatory with IPv6). The same applies
to the UDP-Lite Checksum (mandatory with both IPv4 and IPv6), while to the UDP-Lite Checksum (mandatory with both IPv4 and IPv6), while
the UDP-Lite Checksum Coverage may in some cases be compressible. the UDP-Lite Checksum Coverage may in some cases be compressible.
For IPv4, a similar correlation as the one of the RTP TS to the RTP For IPv4, a similar correlation as that of the RTP TS to the RTP SN
SN is often observed between the Identifier field (IP-ID) and the is often observed between the Identifier field (IP-ID) and the master
master sequence number used for compression (e.g., the RTP SN when sequence number (MSN) used for compression (e.g., the RTP SN when
compressing RTP headers). compressing RTP headers).
4.2. Improvements of ROHCv2 over RFC 3095 Profiles 4.2. Improvements of ROHCv2 over RFC 3095 Profiles
The ROHCv2 profiles can achieve compression efficiency and robustness The ROHCv2 profiles can achieve compression efficiency and robustness
that are both at least equivalent to RFC 3095 profiles [RFC3095], that are both at least equivalent to RFC 3095 profiles [RFC3095],
when used under the same operating conditions. In particular, the when used under the same operating conditions. In particular, the
size and bit layout of the smallest compressed header (i.e., PT-0 size and bit layout of the smallest compressed header (i.e., PT-0
format U/O-0 in RFC 3095, and pt_0_crc3 in ROHCv2) are identical. format U/O-0 in RFC 3095, and pt_0_crc3 in ROHCv2) are identical.
skipping to change at page 10, line 27 skipping to change at page 10, line 30
ROHCv2 profiles assume that the lower layer indicates the length ROHCv2 profiles assume that the lower layer indicates the length
of a compressed packet. ROHCv2 compressed headers do not contain of a compressed packet. ROHCv2 compressed headers do not contain
length information for the payload. length information for the payload.
Out-of-order delivery between compression endpoints Out-of-order delivery between compression endpoints
The definition of the ROHCv2 profiles places no strict requirement The definition of the ROHCv2 profiles places no strict requirement
on the delivery sequence between the compression endpoints, i.e., on the delivery sequence between the compression endpoints, i.e.,
packets may be received in a different order than the compressor packets may be received in a different order than the compressor
has sent them and still have a fair probability to be successfully has sent them and still have a fair probability of being
decompressed. successfully decompressed.
However, frequent out-of-order delivery and/or significant However, frequent out-of-order delivery and/or significant
reordering depth will negatively impact the compression reordering depth will negatively impact the compression
efficiency. More specifically, if the compressor can operate efficiency. More specifically, if the compressor can operate
using a proper estimate of the reordering characteristics of the using a proper estimate of the reordering characteristics of the
path between the compression endpoints, larger headers can be sent path between the compression endpoints, larger headers can be sent
more often to increase the robustness against decompression more often to increase the robustness against decompression
failures due to out-of-order delivery. Otherwise, the compression failures due to out-of-order delivery. Otherwise, the compression
efficiency will be impaired from an increase in the frequency of efficiency will be impaired from an increase in the frequency of
decompression failures and recovery attempts. decompression failures and recovery attempts.
skipping to change at page 11, line 15 skipping to change at page 11, line 15
5.1. Compressor Concepts 5.1. Compressor Concepts
Header compression can be conceptually characterized as the Header compression can be conceptually characterized as the
interaction of a compressor with a decompressor state machine, one interaction of a compressor with a decompressor state machine, one
per context. The responsibility of the compressor is to convey the per context. The responsibility of the compressor is to convey the
information needed to successfully decompress a packet, based on a information needed to successfully decompress a packet, based on a
certain confidence regarding the state of the decompressor context. certain confidence regarding the state of the decompressor context.
This confidence is obtained from the frequency and the type of This confidence is obtained from the frequency and the type of
information the compressor sends when updating the decompressor information the compressor sends when updating the decompressor
context, from the optimistic approach (Section 5.1.1) and optionally context from the optimistic approach (Section 5.1.1), and optionally
from feedback messages (See Section 6.9) received from the from feedback messages (See Section 6.9), received from the
decompressor. decompressor.
5.1.1. Optimistic Approach 5.1.1. Optimistic Approach
A compressor always uses the optimistic approach when it performs A compressor always uses the optimistic approach when it performs
context updates. The compressor normally repeats the same type of context updates. The compressor normally repeats the same type of
update until it is fairly confident that the decompressor has update until it is fairly confident that the decompressor has
successfully received the information. If the decompressor successfully received the information. If the decompressor
successfully receives any of the headers containing this update, successfully receives any of the headers containing this update, the
state will be available for the decompressor to process smaller state will be available for the decompressor to process smaller
compressed headers. compressed headers.
If field X in the uncompressed header changes value, the compressor If field X in the uncompressed header changes value, the compressor
uses a header type that contains an encoding of field X until it has uses a header type that contains an encoding of field X until it has
gained confidence that the decompressor has received at least one gained confidence that the decompressor has received at least one
packet containing the new value for X. The compressor normally packet containing the new value for X. The compressor normally
selects a compressed format with the smallest header that can convey selects a compressed format with the smallest header that can convey
the changes needed to achieve confidence. the changes needed to achieve confidence.
The number of repetitions that is needed to obtain this confidence is The number of repetitions that is needed to obtain this confidence is
normally related to the packet loss and out-of-order delivery normally related to the packet loss and out-of-order delivery
characteristics of the link where header compression is used; it is characteristics of the link where header compression is used; it is
thus not defined in this document and is left open to thus not defined in this document. It is outside the scope of this
implementations. specification and is left to implementors to decide.
5.1.2. Tradeoff between Robustness to Losses and to Reordering 5.1.2. Tradeoff between Robustness to Losses and to Reordering
The ability of a header compression algorithm to handle sequentially The ability of a header compression algorithm to handle sequentially
late packets is mainly limited by two factors: the interpretation late packets is mainly limited by two factors: the interpretation
interval offset of the sliding window used for lsb encoded fields interval offset of the sliding window used for lsb encoded fields
[RFC4997], and the optimistic approach (See Section 5.1.1) for seldom [RFC4997], and the optimistic approach (See Section 5.1.1) for seldom
changing fields. changing fields.
lsb encoded fields: lsb encoded fields:
skipping to change at page 14, line 14 skipping to change at page 14, line 20
has taken with respect to its assumptions regarding the validity of has taken with respect to its assumptions regarding the validity of
its context (Section 5.2.2); it indicates what type of compressed its context (Section 5.2.2); it indicates what type of compressed
header the decompressor can or cannot decompress. header the decompressor can or cannot decompress.
The decompressor has the means to detect decompression failures for The decompressor has the means to detect decompression failures for
any compressed (CO) header format, using the CRC verification. any compressed (CO) header format, using the CRC verification.
Depending on the frequency and/or on the type of the failure, it Depending on the frequency and/or on the type of the failure, it
might send a negative acknowledgement (NACK) or an explicit request might send a negative acknowledgement (NACK) or an explicit request
for a complete context update (STATIC-NACK). However, the for a complete context update (STATIC-NACK). However, the
decompressor does not have the means to identify the cause of the decompressor does not have the means to identify the cause of the
failure, and in particular decompression of what field(s) is failure, and in particular the decompression of what field(s) is
responsible for the failure. The compressor is thus always responsible for the failure. The compressor is thus always
responsible for determining what is the most suitable response to a responsible for determining the most suitable response to a negative
negative acknowledgement, using the confidence it has in the state of acknowledgement, using the confidence it has in the state of the
the decompressor context, when selecting the type of compressed decompressor context, when selecting the type of compressed header it
header it will use when compressing a header. will use when compressing a header.
5.2. Decompressor Concepts 5.2. Decompressor Concepts
The decompressor normally uses the last received and successfully The decompressor normally uses the last received and successfully
validated (IR packets) or verified (CO packets) header as the validated (IR packets) or verified (CO packets) header as the
reference for future decompression. reference for future decompression.
The decompressor is responsible for verifying the outcome of every The decompressor is responsible for verifying the outcome of every
decompression attempt, to update its context when successful and decompression attempt, to update its context when successful, and
finally to request context repairs by making coherent usage of finally to request context repairs by making coherent usage of
feedback, once it has started using feedback. feedback once it has started using feedback.
Specifically, the outcome of every decompression attempt is verified Specifically, the outcome of every decompression attempt is verified
using the CRC present in the compressed header; the decompressor using the CRC present in the compressed header; the decompressor
updates the context information when this outcome is successfully updates the context information when this outcome is successfully
verified; finally if the decompressor uses feedback once for a verified; finally, if the decompressor uses feedback once for a
compressed flow then it will continue to do so for as long as the compressed flow, then it will continue to do so for as long as the
corresponding context is associated with the same profile. corresponding context is associated with the same profile.
5.2.1. Decompressor State Machine 5.2.1. Decompressor State Machine
The decompressor operation may be represented as a state machine The decompressor operation may be represented as a state machine
defining three states: No Context (NC), Repair Context (RC) and Full defining three states: No Context (NC), Repair Context (RC), and Full
Context (FC). Context (FC).
The decompressor starts without a valid context, the NC state. Upon The decompressor starts without a valid context, the NC state. Upon
receiving an IR packet, the decompressor validates the integrity of receiving an IR packet, the decompressor validates the integrity of
its header using the CRC-8 validation. If the IR header is its header using the CRC-8 validation. If the IR header is
successfully validated, the decompressor updates the context and uses successfully validated, the decompressor updates the context and uses
this header as the reference header, and moves to the FC state. The this header as the reference header, and moves to the FC state. Once
decompressor state machine normally does not leave the FC state once the decompressor state machine has entered the FC state, it does not
it has entered this state; only repeated decompression failures will normally leave; only repeated decompression failures will force the
force the decompressor to transit downwards to a lower state. When decompressor to transit downwards to a lower state. When context
context damage is detected, the decompressor moves to the repair damage is detected, the decompressor moves to the repair context (RC)
context (RC) state, where it stays until it successfully verifies a state, where it stays until it successfully verifies a decompression
decompression attempt for a compressed header with a 7-bit CRC or attempt for a compressed header with a 7-bit CRC or until it
until it successfully validates an IR header. When static context successfully validates an IR header. When static context damage is
damage is detected, the decompressor moves back to the NC state. detected, the decompressor moves back to the NC state.
Below is the state machine for the decompressor. Details of the Below is the state machine for the decompressor. Details of the
transitions between states and decompression logic are given in the transitions between states and decompression logic are given in the
sub-sections following the figure. sub-sections following the figure.
CRC-8(IR) Validation CRC-8(IR) Validation
+----->----->----->----->----->----->----->----->----->----->----+ +----->----->----->----->----->----->----->----->----->----->----+
| CRC-8(IR) | | CRC-8(IR) |
| !CRC-8(IR) or CRC-7(CO) or or CRC-7(CO) | | !CRC-8(IR) or CRC-7(CO) or or CRC-7(CO) |
| PT not allowed CRC-8(IR) or CRC-3(CO) | | PT not allowed CRC-8(IR) or CRC-3(CO) |
skipping to change at page 16, line 38 skipping to change at page 16, line 39
limitation as described in Section 5.2.3. limitation as described in Section 5.2.3.
5.2.1.2. Repair Context (RC) State 5.2.1.2. Repair Context (RC) State
In the Repair Context (RC) state, the decompressor has successfully In the Repair Context (RC) state, the decompressor has successfully
decompressed packets for this context, but does not have confidence decompressed packets for this context, but does not have confidence
that the entire context is valid. that the entire context is valid.
Attempting decompression: Attempting decompression:
In the RC state, only headers covered by an 8-bit CRC (i.e. IR) In the RC state, only headers covered by an 8-bit CRC (i.e., IR)
or CO headers carrying a 7-bit CRC can be decompressed. or CO headers carrying a 7-bit CRC can be decompressed.
Upward transition: Upward transition:
The decompressor can move to the Full Context (FC) state when the The decompressor can move to the Full Context (FC) state when the
CRC verification succeeds for a CO header carrying a 7-bit CRC or CRC verification succeeds for a CO header carrying a 7-bit CRC or
validation of an 8-bit CRC in an IR header. when validation of an 8-bit CRC in an IR header succeeds.
Downward transition: Downward transition:
The decompressor moves back to the NC state if it assumes static The decompressor moves back to the NC state if it assumes static
context damage. context damage.
Feedback logic: Feedback logic:
In the RC state, the decompressor should send a STATIC-NACK when In the RC state, the decompressor should send a STATIC-NACK when
CRC-8 validation of an IR header fails, or when a CO header CRC-8 validation of an IR header fails, or when a CO header
skipping to change at page 18, line 23 skipping to change at page 18, line 23
unsuccessful repairs, the decompressor then assumes that the entire unsuccessful repairs, the decompressor then assumes that the entire
context, including the static part, needs to be repaired, i.e., context, including the static part, needs to be repaired, i.e.,
static context damage. Failure to validate the 3-bit CRC that static context damage. Failure to validate the 3-bit CRC that
protects control fields should be treated as a decompression failure protects control fields should be treated as a decompression failure
when the decompressor asserts the validity of its context. when the decompressor asserts the validity of its context.
Context Damage Detection Context Damage Detection
The assumption of context damage means that the decompressor will The assumption of context damage means that the decompressor will
not attempt decompression of a CO header that carries only a 3-bit not attempt decompression of a CO header that carries only a 3-bit
CRC, and will only attempt decompression of IR headers, or CO CRC, and will only attempt decompression of IR headers or CO
headers protected by a CRC-7. headers protected by a CRC-7.
Static Context Damage Detection Static Context Damage Detection
The assumption of static context damage means that the The assumption of static context damage means that the
decompressor refrains from attempting decompression of any type of decompressor refrains from attempting decompression of any type of
header other than the IR header. header other than the IR header.
How these assumptions are made, i.e., how context damage is detected, How these assumptions are made, i.e., how context damage is detected,
is open to implementations. It can be based on the residual error is open to implementations. It can be based on the residual error
rate, where a low error rate makes the decompressor assume damage rate, where a low error rate makes the decompressor assume damage
more often than on a high rate link. more often than on a high rate link.
The decompressor implements these assumptions by selecting the type The decompressor implements these assumptions by selecting the type
of compressed header for which it will attempt decompression. In of compressed header for which it will attempt decompression. In
other words, validity of the context refers to the ability of a other words, validity of the context refers to the ability of a
decompressor to attempt or not decompression of specific packet decompressor to attempt (or not) decompression of specific packet
types. types.
When ROHCv2 profiles are used over a channel that cannot guarantee When ROHCv2 profiles are used over a channel that cannot guarantee
in-order delivery, the decompressor may refrain from updating its in-order delivery, the decompressor may refrain from updating its
context with the content of a sequentially late packet that is context with the content of a sequentially late packet that is
successfully decompressed. This is to avoid updating the context successfully decompressed. This is to avoid updating the context
with information that is older than what the decompressor already has with information that is older than what the decompressor already has
in its context. in its context.
5.2.3. Feedback Logic 5.2.3. Feedback Logic
ROHCv2 profiles may be used in environments with or without feedback ROHCv2 profiles may be used in environments with or without feedback
capabilities from decompressor to compressor. ROHCv2 however assumes capabilities from decompressor to compressor. ROHCv2 however assumes
that if a ROHC feedback channel is available and if this channel is that if a ROHC feedback channel is available and if this channel is
used at least once by the decompressor for a specific context, this used at least once by the decompressor for a specific context, this
channel will be used during the entire compression operation for that channel will be used during the entire compression operation for that
context (i.e., bidirectional operation). context (i.e., bidirectional operation).
The ROHC framework defines 3 types of feedback messages: ACKs, NACKs The ROHC framework defines 3 types of feedback messages: ACKs, NACKs,
and STATIC-NACKs. The semantics of each message if defined in and STATIC-NACKs. The semantics of each message is defined in
section 5.2.4.1. of [RFC4995]. What feedback to send is coupled to Section 5.2.4.1. of [RFC4995]. What feedback to send is coupled with
the context management of the decompressor, i.e. to the the context management of the decompressor, i.e., with the
implementation of the context damage detection algorithms as implementation of the context damage detection algorithms as
described in Section 5.2.2. described in Section 5.2.2.
The decompressor should send a NACK when it assumes context damage, The decompressor should send a NACK when it assumes context damage,
and it should send a STATIC-NACK when it assumes static context and it should send a STATIC-NACK when it assumes static context
damage. The decompressor is not strictly expected to send ACK damage. The decompressor is not strictly expected to send ACK
feedback upon successful decompression, other than for the purpose of feedback upon successful decompression, other than for the purpose of
improving compression efficiency. improving compression efficiency.
When ROHCv2 profiles are used over a channel that cannot guarantee When ROHCv2 profiles are used over a channel that cannot guarantee
in-order delivery, the decompressor may refrain from sending ACK in-order delivery, the decompressor may refrain from sending ACK
feedback for a sequentially late packet that is successfully feedback for a sequentially late packet that is successfully
decompressed. decompressed.
The decompressor should limit the rate at which it sends feedback, The decompressor should limit the rate at which it sends feedback,
for both ACKs and STATIC-NACK/NACKs, and should avoid sending for both ACKs and STATIC-NACK/NACKs, and should avoid sending
unnecessary duplicates of the same type of feedback message that may unnecessary duplicates of the same type of feedback message that may
be associated to the same event. be associated with the same event.
6. ROHCv2 Profiles (Normative) 6. ROHCv2 Profiles (Normative)
6.1. Channel Parameters, Segmentation and Reordering 6.1. Channel Parameters, Segmentation, and Reordering
The compressor MUST NOT use ROHC segmentation (see [RFC4995] section The compressor MUST NOT use ROHC segmentation (see Section 5.2.5 of
5.2.5), i.e., MRRU MUST be set to 0, if the configuration of the ROHC [RFC4995]), i.e., the Maximum Reconstructed Reception Unit (MRRU)
channel contains at least one ROHCv2 profile in the list of supported MUST be set to 0, if the configuration of the ROHC channel contains
profiles (i.e., the PROFILES parameter) and if the channel cannot at least one ROHCv2 profile in the list of supported profiles (i.e.,
guarantee in-order delivery of packets between compression endpoints. the PROFILES parameter) and if the channel cannot guarantee in-order
delivery of packets between compression endpoints.
6.2. Profile Operation, Per-context 6.2. Profile Operation, Per-context
ROHCv2 profiles operate differently, per context, depending on how ROHCv2 profiles operate differently, per context, depending on how
the decompressor makes use of the feedback channel, if any. Once the the decompressor makes use of the feedback channel, if any. Once the
decompressor uses the feedback channel for a context, it establishes decompressor uses the feedback channel for a context, it establishes
the feedback channel for that CID. the feedback channel for that CID.
The compressor always starts with the assumption that the The compressor always starts with the assumption that the
decompressor will not send feedback when it initializes a new context decompressor will not send feedback when it initializes a new context
(see also the definition of a new context in section 5.1.1. of (see also the definition of a new context in Section 5.1.1. of
[RFC4995]), i.e., there is no established feedback channel for the [RFC4995], i.e., there is no established feedback channel for the new
new context. At this point, despite the use of the optimistic context. At this point, despite the use of the optimistic approach,
approach, decompression failure is still possible because the decompression failure is still possible because the decompressor may
decompressor may not have received sufficient information to not have received sufficient information to correctly decompress the
correctly decompress the packets; therefore, until the decompressor packets; therefore, until the decompressor has established a feedback
has established a feedback channel, the compressor SHOULD channel, the compressor SHOULD periodically send IR packets. The
periodically send IR packets. The periodicity can be based on periodicity can be based on timeouts, on the number of compressed
timeouts, on the number of compressed packets sent for the flow, or packets sent for the flow, or any other strategy the implementer
any other strategy the implementer chooses. chooses.
The reception of either positive feedback (ACKs) or negative feedback The reception of either positive feedback (ACKs) or negative feedback
(NACKs or STATIC-NACKs) from the decompressor establishes the (NACKs or STATIC-NACKs) from the decompressor establishes the
feedback channel for the context (CID) for which the feedback was feedback channel for the context (CID) for which the feedback was
received. Once there is an established feedback channel for a received. Once there is an established feedback channel for a
specific context, the compressor can make use of this feedback to specific context, the compressor can make use of this feedback to
estimate the current state of the decompressor. This helps to estimate the current state of the decompressor. This helps to
increase the compression efficiency by providing the information increase the compression efficiency by providing the information
needed for the compressor to achieve the necessary confidence level. needed for the compressor to achieve the necessary confidence level.
When the feedback channel is established, it becomes superfluous for When the feedback channel is established, it becomes superfluous for
the compressor to send periodic refreshes, and instead it can rely the compressor to send periodic refreshes, and instead it can rely
entirely on the optimistic approach and feedback from the entirely on the optimistic approach and feedback from the
decompressor. decompressor.
The decompressor MAY send positive feedback (ACKs) to initially The decompressor MAY send positive feedback (ACKs) to initially
establish the feedback channel for a particular flow. Either establish the feedback channel for a particular flow. Either
positive feedback (ACKs) or negative feedback (NACKs) establishes positive feedback (ACKs) or negative feedback (NACKs or STATIC-NACKs)
this channel. Once it has established a feedback channel for a CID, establishes this channel. Once it has established a feedback channel
the decompressor is REQUIRED to continue sending feedback for the for a CID, the decompressor is REQUIRED to continue sending feedback
lifetime of the context (i.e., until it receives an IR packet that for the lifetime of the context (i.e., until it receives an IR packet
associates the CID to a different profile), to send error recovery that associates the CID to a different profile), to send error
requests and (optionally) acknowledgments of significant context recovery requests and (optionally) acknowledgments of significant
updates. context updates.
Compression without an established feedback channel will be less Compression without an established feedback channel will be less
efficient, because of the periodic refreshes and from the lack of efficient, because of the periodic refreshes and the lack of feedback
feedback to trigger error recovery; there will also be a slightly to trigger error recovery; there will also be a slightly higher
higher probability of loss propagation compared to the case where the probability of loss propagation compared to the case where the
decompressor uses feedback. decompressor uses feedback.
6.3. Control Fields 6.3. Control Fields
ROHCv2 defines a number of control fields that are used by the ROHCv2 defines a number of control fields that are used by the
decompressor in its interpretation of the header formats received decompressor in its interpretation of the header formats received
from the compressor. The control fields listed in the following from the compressor. The control fields listed in the following
subsections are defined using the formal notation [RFC4997] in subsections are defined using the formal notation [RFC4997] in
Section 6.8.2.4. Section 6.8.2.4 of this document.
6.3.1. Master Sequence Number (MSN) 6.3.1. Master Sequence Number (MSN)
The Master Sequence Number (MSN) field is either taken from a field The Master Sequence Number (MSN) field is either taken from a field
that already exists in one of the headers of the protocol that the that already exists in one of the headers of the protocol that the
profile compresses (e.g., RTP SN), or alternatively it is created at profile compresses (e.g., RTP SN), or alternatively it is created at
the compressor. There is one MSN space per context (CID). the compressor. There is one MSN space per context.
The MSN field has the following two functions: The MSN field has the following two functions:
o Differentiating between reference headers when receiving feedback o Differentiating between reference headers when receiving feedback
data; data;
o Inferring the value of incrementing fields (e.g., IPv4 o Inferring the value of incrementing fields (e.g., IPv4
Identifier). Identifier).
There is one MSN field in every ROHCv2 header, i.e., the MSN is There is one MSN field in every ROHCv2 header, i.e., the MSN is
always present in each header type sent by the compressor. The MSN always present in each header type sent by the compressor. The MSN
is sent in full in IR headers, while it can be lsb encoded within CO is sent in full in IR headers, while it can be lsb encoded within CO
header formats. The decompressor always includes LSBs of the MSN in header formats. The decompressor always includes LSBs of the MSN in
the Acknowledgment Number field in feedback (see Section 6.9). The the Acknowledgment Number field in feedback (see Section 6.9). The
compressor can later use this field to infer what packet the compressor can later use this field to infer what packet the
decompressor is acknowledging. decompressor is acknowledging.
skipping to change at page 21, line 30 skipping to change at page 21, line 36
Identifier). Identifier).
There is one MSN field in every ROHCv2 header, i.e., the MSN is There is one MSN field in every ROHCv2 header, i.e., the MSN is
always present in each header type sent by the compressor. The MSN always present in each header type sent by the compressor. The MSN
is sent in full in IR headers, while it can be lsb encoded within CO is sent in full in IR headers, while it can be lsb encoded within CO
header formats. The decompressor always includes LSBs of the MSN in header formats. The decompressor always includes LSBs of the MSN in
the Acknowledgment Number field in feedback (see Section 6.9). The the Acknowledgment Number field in feedback (see Section 6.9). The
compressor can later use this field to infer what packet the compressor can later use this field to infer what packet the
decompressor is acknowledging. decompressor is acknowledging.
For profiles for which the MSN is created by the compressor (i.e. For profiles for which the MSN is created by the compressor (i.e.,
0x0102, 0x0104 and 0x0108), the following applies: 0x0102, 0x0104, and 0x0108), the following applies:
o The compressor only initializes the MSN for a context when that o The compressor only initializes the MSN for a context when that
context is first created or when the profile associated with a context is first created or when the profile associated with a
context changes; context changes;
o When the MSN is initialized, it is initialized to a random value; o When the MSN is initialized, it is initialized to a random value;
o The value of the MSN SHOULD be incremented by one for each packet o The value of the MSN SHOULD be incremented by one for each packet
that the compressor sends for a specific CID. that the compressor sends for a specific CID.
6.3.2. Reordering Ratio 6.3.2. Reordering Ratio
The control field reorder_ratio specifies how much reordering is The control field reorder_ratio specifies how much reordering is
handled by the lsb encoding of the MSN. This is useful when header handled by the lsb encoding of the MSN. This is useful when header
compression is performed over links with varying reordering compression is performed over links with varying reordering
characteristics. The reorder_ratio control field provides the means characteristics. The reorder_ratio control field provides the means
for the compressor to adjust the robustness characteristics of the for the compressor to adjust the robustness characteristics of the
skipping to change at page 22, line 19 skipping to change at page 22, line 23
random or constant (a constant value of zero, although not conformant random or constant (a constant value of zero, although not conformant
with [RFC0791], has been observed in practice). There is one IP-ID with [RFC0791], has been observed in practice). There is one IP-ID
behavior control field per IP header. The control field for the behavior control field per IP header. The control field for the
IP-ID behavior of the innermost IP header determines which set of IP-ID behavior of the innermost IP header determines which set of
header formats is used. The IP-ID behavior control field is also header formats is used. The IP-ID behavior control field is also
used to determine the contents of the irregular chain item, for each used to determine the contents of the irregular chain item, for each
IP header. IP header.
ROHCv2 profiles MUST NOT assign a sequential behavior (network byte ROHCv2 profiles MUST NOT assign a sequential behavior (network byte
order or byte-swapped) to any IP-ID but the one in the innermost IP order or byte-swapped) to any IP-ID but the one in the innermost IP
header, when compressing more than one level of IP headers. This is header when compressing more than one level of IP headers. This is
because only the IP-ID of the innermost IP header is likely to have a because only the IP-ID of the innermost IP header is likely to have a
sufficiently close correlation with the MSN to compress it as a sufficiently close correlation with the MSN to compress it as a
sequentially changing field. Therefore, a compressor MUST assign sequentially changing field. Therefore, a compressor MUST assign
either the constant zero IP-ID or the random IP-ID behavior to either the constant zero IP-ID or the random IP-ID behavior to
tunneling headers. tunneling headers.
6.3.4. UDP-Lite Coverage Behavior 6.3.4. UDP-Lite Coverage Behavior
The control field coverage_behavior specifies how the checksum The control field coverage_behavior specifies how the checksum
coverage field of the UDP-Lite header is compressed with RoHCv2. It coverage field of the UDP-Lite header is compressed with RoHCv2. It
can indicate one of the following encoding methods: irregular, static can indicate one of the following encoding methods: irregular,
or inferred encoding. static, or inferred encoding.
6.3.5. Timestamp Stride 6.3.5. Timestamp Stride
The ts_stride control field is used in scaled RTP timestamp encoding The ts_stride control field is used in scaled RTP timestamp encoding
(see Section 6.6.8). It defines the expected increase in the RTP (see Section 6.6.8). It defines the expected increase in the RTP
timestamp between consecutive RTP sequence numbers. timestamp between consecutive RTP sequence numbers.
6.3.6. Time Stride 6.3.6. Time Stride
The time_stride control field is used in timer-based compression The time_stride control field is used in timer-based compression
skipping to change at page 23, line 8 skipping to change at page 23, line 16
ROHCv2 profiles define a CRC-3 calculated over a number of control ROHCv2 profiles define a CRC-3 calculated over a number of control
fields. This 3-bit CRC protecting the control fields is present in fields. This 3-bit CRC protecting the control fields is present in
the header format for the co_common and co_repair header types. the header format for the co_common and co_repair header types.
The decompressor MUST always validate the integrity of the control The decompressor MUST always validate the integrity of the control
fields covered by this 3-bit CRC when processing a co_common or a fields covered by this 3-bit CRC when processing a co_common or a
co_repair compressed header. co_repair compressed header.
Failure to validate the control fields using this CRC should be Failure to validate the control fields using this CRC should be
considered as a decompression failure by the decompressor, in the considered as a decompression failure by the decompressor in the
algorithm that assesses the validity of the context. However, if the algorithm that assesses the validity of the context. However, if the
decompression attempt can be verified using either the CRC-3 or the decompression attempt can be verified using either the CRC-3 or the
CRC-7 calculated over the uncompressed header, the decompressor MAY CRC-7 calculated over the uncompressed header, the decompressor MAY
still forward the decompressed header to upper layers. This is still forward the decompressed header to upper layers. This is
because the protected control fields are not always used to because the protected control fields are not always used to
decompress the header (i.e., co_common or co_repair) that updates decompress the header (i.e., co_common or co_repair) that updates
their respective value. their respective value.
The CRC polynomial and coverage of this CRC-3 is defined in The CRC polynomial and coverage of this CRC-3 is defined in
Section 6.6.11. Section 6.6.11.
skipping to change at page 23, line 37 skipping to change at page 23, line 45
information in the IR header. Otherwise, if the IR cannot be information in the IR header. Otherwise, if the IR cannot be
validated, the context MUST NOT be updated and the IR header MUST validated, the context MUST NOT be updated and the IR header MUST
NOT be delivered to upper layers. NOT be delivered to upper layers.
Verification of CO headers (3-bit CRC or 7-bit CRC) Verification of CO headers (3-bit CRC or 7-bit CRC)
The decompressor MUST always verify the decompression of a CO The decompressor MUST always verify the decompression of a CO
header using the CRC carried within the compressed header. When header using the CRC carried within the compressed header. When
the decompression is verified and successful, the decompressor the decompression is verified and successful, the decompressor
updates the context with the information received in the CO updates the context with the information received in the CO
header; otherwise if the reconstructed header fails the CRC header; otherwise, if the reconstructed header fails the CRC
verification, these updates MUST NOT be performed. verification, these updates MUST NOT be performed.
A packet for which the decompression attempt cannot be verified A packet for which the decompression attempt cannot be verified
using the CRC MUST NOT be delivered to upper layers. using the CRC MUST NOT be delivered to upper layers.
Decompressor implementations may attempt corrective or repair Decompressor implementations may attempt corrective or repair
measures on CO headers prior to performing the above actions, and measures on CO headers prior to performing the above actions, and
the result of any decompression attempt MUST be verified using the the result of any decompression attempt MUST be verified using the
CRC. CRC.
6.5. Compressed Header Chains 6.5. Compressed Header Chains
Some header types use one or more chains containing sub-header Some header types use one or more chains containing sub-header
information. The function of a chain is to group fields based on information. The function of a chain is to group fields based on
similar characteristics, such as static, dynamic or irregular fields. similar characteristics, such as static, dynamic, or irregular
fields.
Chaining is done by appending an item for each header to the chain in Chaining is done by appending an item for each header to the chain in
their order of appearance in the uncompressed packet, starting from their order of appearance in the uncompressed packet, starting from
the fields in the outermost header. the fields in the outermost header.
In the text below, the term <protocol_name> is used to identify In the text below, the term <protocol_name> is used to identify
formal notation names corresponding to different protocol headers. formal notation names corresponding to different protocol headers.
The mapping between these is defined in the following table: The mapping between these is defined in the following table:
+----------------------------------+---------------+ +----------------------------------+---------------+
| Protocol | protocol_name | | Protocol | protocol_name |
+----------------------------------+---------------+ +----------------------------------+---------------+
| IPv4 RFC 0791 | ipv4 | | IPv4 RFC 0791 | ipv4 |
| IPv6 RFC 2460 | ipv6 | | IPv6 RFC 2460 | ipv6 |
| UDP RFC 0768 | udp | | UDP RFC 0768 | udp |
| RTP RFC 3550 | rtp | | RTP RFC 3550 | rtp |
| ESP RFC 4303 | esp | | ESP RFC 4303 | esp |
| UDP-Lite RFC 3828 | udp_lite | | UDP-Lite RFC 3828 | udp_lite |
| AH RFC 4302 | ah | | AH RFC 4302 | ah |
skipping to change at page 25, line 15 skipping to change at page 25, line 26
The structure of the irregular chain is analogous to the structure The structure of the irregular chain is analogous to the structure
of the static chain. For each compressed header that uses the of the static chain. For each compressed header that uses the
general format of Section 6.8, the irregular chain is appended at general format of Section 6.8, the irregular chain is appended at
a specific location in the general format of the compressed a specific location in the general format of the compressed
headers. In the formal description of the header formats, the headers. In the formal description of the header formats, the
irregular chain item for each header type is a format whose name irregular chain item for each header type is a format whose name
is suffixed by "_irregular". The irregular chain is used in all is suffixed by "_irregular". The irregular chain is used in all
CO headers, except for the co_repair format. CO headers, except for the co_repair format.
The format of the irregular chain for the innermost IP header The format of the irregular chain for the innermost IP header
differs from the format used for the outer IP headers, because differs from the format used for the outer IP headers, because the
this header is part of the compressed base header. In the innermost IP header is part of the compressed base header. In the
definition of the header formats using the formal notation, the definition of the header formats using the formal notation, the
argument "is_innermost" passed to the corresponding encoding argument "is_innermost", which is passed to the corresponding
method (ipv4 or ipv6) determines what irregular chain items to encoding method (ipv4 or ipv6), determines what irregular chain
use. The format of the irregular chain item for the outer IP items to use. The format of the irregular chain item for the
headers is also determined using one flag for TTL/Hop Limit and outer IP headers is also determined using one flag for TTL/Hop
TOS/TC. This flag is defined in the format of some of the Limit and TOS/TC. This flag is defined in the format of some of
compressed base headers. the compressed base headers.
ROHCv2 profiles compress extension headers as other headers, and thus ROHCv2 profiles compress extension headers as other headers, and thus
extension headers have a static chain, a dynamic chain and an extension headers have a static chain, a dynamic chain, and an
irregular chain. irregular chain.
ROHCv2 profiles define chains for all headers that can be compressed, ROHCv2 profiles define chains for all headers that can be compressed,
i.e., RTP [RFC3550], UDP [RFC0768], ESP [RFC4303], UDP Lite i.e., RTP [RFC3550], UDP [RFC0768], ESP [RFC4303], UDP-Lite
[RFC3828], IPv4 [RFC0791], IPv6 [RFC2460], AH [RFC4302], GRE [RFC3828], IPv4 [RFC0791], IPv6 [RFC2460], AH [RFC4302], GRE
[RFC2784][RFC2890], MINE [RFC2004], IPv6 Destination Options header [RFC2784][RFC2890], MINE [RFC2004], IPv6 Destination Options header
[RFC2460], IPv6 Hop-by-hop Options header [RFC2460] and IPv6 Routing [RFC2460], IPv6 Hop-by-hop Options header [RFC2460], and IPv6 Routing
header [RFC2460]. header [RFC2460].
6.6. Header Formats and Encoding Methods 6.6. Header Formats and Encoding Methods
The header formats are defined using the ROHC formal notation. Some The header formats are defined using the ROHC formal notation. Some
of the encoding methods used in the header formats are defined in of the encoding methods used in the header formats are defined in
[RFC4997], while other methods are defined in this section. [RFC4997], while other methods are defined in this section.
6.6.1. baseheader_extension_headers 6.6.1. baseheader_extension_headers
The baseheader_extension_headers encoding method skips over all The baseheader_extension_headers encoding method skips over all
fields of the extension headers of the innermost IP header, without fields of the extension headers of the innermost IP header, without
encoding any of them. Fields in these extension headers are instead encoding any of them. Fields in these extension headers are instead
encoded in the irregular chain. encoded in the irregular chain.
This encoding is used in CO headers (see Section 6.8.2). The This encoding is used in CO headers (see Section 6.8.2). The
innermost IP header is combined with other header(s) (i.e., UDP, UDP innermost IP header is combined with other header(s) (i.e., UDP, UDP-
Lite, RTP) to create the compressed base header. In this case, there Lite, RTP) to create the compressed base header. In this case, there
may be a number of extension headers between the IP headers and the may be a number of extension headers between the IP headers and the
other headers. other headers.
The base header defines a representation of the extension headers, to The base header defines a representation of the extension headers, to
comply with the syntax of the formal notation; this encoding method comply with the syntax of the formal notation; this encoding method
provides this representation. provides this representation.
6.6.2. baseheader_outer_headers 6.6.2. baseheader_outer_headers
skipping to change at page 26, line 34 skipping to change at page 26, line 46
6.6.3. inferred_udp_length 6.6.3. inferred_udp_length
The decompressor infers the value of the UDP length field as being The decompressor infers the value of the UDP length field as being
the sum of the UDP header length and the UDP payload length. The the sum of the UDP header length and the UDP payload length. The
compressor must therefore ensure that the UDP length field is compressor must therefore ensure that the UDP length field is
consistent with the length field(s) of preceding subheaders, i.e., consistent with the length field(s) of preceding subheaders, i.e.,
there must not be any padding after the UDP payload that is covered there must not be any padding after the UDP payload that is covered
by the IP Length. by the IP Length.
This encoding method is also used for the UDP-Lite Checksum Coverage This encoding method is also used for the UDP-Lite Checksum Coverage
field, when it behaves in the same manner as the UDP length field field when it behaves in the same manner as the UDP length field
(i.e., when the checksum always covers the entire UDP-Lite payload). (i.e., when the checksum always covers the entire UDP-Lite payload).
6.6.4. inferred_ip_v4_header_checksum 6.6.4. inferred_ip_v4_header_checksum
This encoding method compresses the header checksum field of the IPv4 This encoding method compresses the header checksum field of the IPv4
header. This checksum is defined in RFC 791 [RFC0791] as follows: header. This checksum is defined in RFC 791 [RFC0791] as follows:
Header Checksum: 16 bits Header Checksum: 16 bits
A checksum on the header only. Since some header fields change A checksum on the header only. Since some header fields change
skipping to change at page 27, line 13 skipping to change at page 27, line 19
point that the internet header is processed. point that the internet header is processed.
The checksum algorithm is: The checksum algorithm is:
The checksum field is the 16 bit one's complement of the one's The checksum field is the 16 bit one's complement of the one's
complement sum of all 16 bit words in the header. For purposes complement sum of all 16 bit words in the header. For purposes
of computing the checksum, the value of the checksum field is of computing the checksum, the value of the checksum field is
zero. zero.
As described above, the header checksum protects individual hops from As described above, the header checksum protects individual hops from
processing a corrupted header. There is no reason to transmit this processing a corrupted header. As the data that this checksum
checksum when almost all IP header information is compressed away, protects is mostly compressed away and is instead taken from state
and when decompression is verified by a CRC computed over the stored in the context, this checksum becomes cumulative to the ROHC
original header for every compressed packet; instead, the checksum CRC. When using this encoding method, the checksum is recomputed by
can be recomputed by the decompressor. the decompressor.
The "inferred_ip_v4_header_checksum" encoding method thus compresses The inferred_ip_v4_header_checksum encoding method thus compresses
the header checksum field of the IPv4 header down to a size of zero the header checksum field of the IPv4 header down to a size of zero
bits, i.e., no bits are transmitted in compressed headers for this bits, i.e., no bits are transmitted in compressed headers for this
field. Using this encoding method, the decompressor infers the value field. Using this encoding method, the decompressor infers the value
of this field using the computation above. of this field using the computation above.
The compressor MAY use the header checksum to validate the The compressor MAY use the header checksum to validate the
correctness of the header before compressing it, to avoid processing correctness of the header before compressing it, to avoid processing
a corrupted header. a corrupted header.
6.6.5. inferred_mine_header_checksum 6.6.5. inferred_mine_header_checksum
skipping to change at page 27, line 42 skipping to change at page 27, line 48
checksum. This checksum is defined in RFC 2004 [RFC2004] as follows: checksum. This checksum is defined in RFC 2004 [RFC2004] as follows:
Header Checksum Header Checksum
The 16-bit one's complement of the one's complement sum of all The 16-bit one's complement of the one's complement sum of all
16-bit words in the minimal forwarding header. For purposes of 16-bit words in the minimal forwarding header. For purposes of
computing the checksum, the value of the checksum field is 0. computing the checksum, the value of the checksum field is 0.
The IP header and IP payload (after the minimal forwarding The IP header and IP payload (after the minimal forwarding
header) are not included in this checksum computation. header) are not included in this checksum computation.
The "inferred_mine_header_checksum" encoding method compresses the The inferred_mine_header_checksum encoding method compresses the
minimal encapsulation header checksum down to a size of zero bits, minimal encapsulation header checksum down to a size of zero bits,
i.e., no bits are transmitted in compressed headers for this field. i.e., no bits are transmitted in compressed headers for this field.
Using this encoding method, the decompressor infers the value of this Using this encoding method, the decompressor infers the value of this
field using the above computation. field using the above computation.
The motivations for inferring this checksum are similar to the ones The motivations for inferring this checksum are similar to the ones
explained above in Section 6.6.4. explained above in Section 6.6.4.
The compressor MAY use the minimal encapsulation header checksum to The compressor MAY use the minimal encapsulation header checksum to
validate the correctness of the header before compressing it, to validate the correctness of the header before compressing it, to
skipping to change at page 28, line 18 skipping to change at page 28, line 24
This encoding method compresses the total length field of the IPv4 This encoding method compresses the total length field of the IPv4
header. The total length field of the IPv4 header is defined in RFC header. The total length field of the IPv4 header is defined in RFC
791 [RFC0791] as follows: 791 [RFC0791] as follows:
Total Length: 16 bits Total Length: 16 bits
Total Length is the length of the datagram, measured in octets, Total Length is the length of the datagram, measured in octets,
including internet header and data. This field allows the including internet header and data. This field allows the
length of a datagram to be up to 65,535 octets. length of a datagram to be up to 65,535 octets.
The "inferred_ip_v4_length" encoding method compresses the IPv4 The inferred_ip_v4_length encoding method compresses the IPv4 header
header checksum down to a size of zero bits, i.e., no bits are checksum down to a size of zero bits, i.e., no bits are transmitted
transmitted in compressed headers for this field. Using this in compressed headers for this field. Using this encoding method,
encoding method, the decompressor infers the value of this field by the decompressor infers the value of this field by counting in octets
counting in octets the length of the entire packet after the length of the entire packet after decompression.
decompression.
6.6.7. inferred_ip_v6_length 6.6.7. inferred_ip_v6_length
This encoding method compresses the payload length field in the IPv6 This encoding method compresses the payload length field in the IPv6
header. This length field is defined in RFC 2460 [RFC2460] as header. This length field is defined in RFC 2460 [RFC2460] as
follows: follows:
Payload Length: 16-bit unsigned integer Payload Length: 16-bit unsigned integer
Length of the IPv6 payload, i.e., the rest of the packet Length of the IPv6 payload, i.e., the rest of the packet
skipping to change at page 28, line 45 skipping to change at page 28, line 50
extension headers present are considered part of the payload, extension headers present are considered part of the payload,
i.e., included in the length count.) i.e., included in the length count.)
The "inferred_ip_v6_length" encoding method compresses the payload The "inferred_ip_v6_length" encoding method compresses the payload
length field of the IPv6 header down to a size of zero bits, i.e., no length field of the IPv6 header down to a size of zero bits, i.e., no
bits are transmitted in compressed headers for this field. Using bits are transmitted in compressed headers for this field. Using
this encoding method, the decompressor infers the value of this field this encoding method, the decompressor infers the value of this field
by counting in octets the length of the entire packet after by counting in octets the length of the entire packet after
decompression. decompression.
IPv6 headers using the jumbo payload option of RFC 2675 [RFC2675]
will not be compressible with this encoding method since the value of
the payload length field does not match the length of the packet.
6.6.8. Scaled RTP Timestamp Compression 6.6.8. Scaled RTP Timestamp Compression
This section provides additional details on encodings used to scale This section provides additional details on encodings used to scale
the RTP timestamp, as defined in the formal notation in the RTP timestamp, as defined in the formal notation in
Section 6.8.2.4. Section 6.8.2.4.
The RTP timestamp (TS) usually increases by a multiple of the RTP The RTP timestamp (TS) usually increases by a multiple of the RTP
Sequence Number's (SN) increase and is therefore a suitable candidate Sequence Number's (SN's) increase and is therefore a suitable
for scaled encoding. This scaling factor is labeled ts_stride in the candidate for scaled encoding. This scaling factor is labeled
definition of the profile in the formal notation. The compressor ts_stride in the definition of the profile in the formal notation.
sets the scaling factor based on the change in TS with respect to the The compressor sets the scaling factor based on the change in TS with
change in the RTP SN. respect to the change in the RTP SN.
The default value of the scaling factor ts_stride is 160, as defined The default value of the scaling factor ts_stride is 160, as defined
in Section 6.8.2.4. To use a different value for ts_stride, the in Section 6.8.2.4. To use a different value for ts_stride, the
compressor explicitly updates the value of ts_stride to the compressor explicitly updates the value of ts_stride to the
decompressor using one of the header formats that can carry this decompressor using one of the header formats that can carry this
information. information.
When the compressor uses a scaling factor that is different than the When the compressor uses a scaling factor that is different than the
default value of ts_stride, it can only use the new scaling factor default value of ts_stride, it can only use the new scaling factor
once it has enough confidence that the decompressor has successfully once it has enough confidence that the decompressor has successfully
skipping to change at page 29, line 47 skipping to change at page 30, line 6
residue of the scaling function is likely to change. When this residue of the scaling function is likely to change. When this
occurs, the compressor re-establishes the new residue value as occurs, the compressor re-establishes the new residue value as
described above. described above.
If the decompressor receives a compressed header containing scaled If the decompressor receives a compressed header containing scaled
timestamp bits while the ts_stride equals zero, it MUST NOT deliver timestamp bits while the ts_stride equals zero, it MUST NOT deliver
the packet to upper layers and it SHOULD treat this as a CRC the packet to upper layers and it SHOULD treat this as a CRC
verification failure. verification failure.
Whether or not the scaling is applied to the RTP TS field is up to Whether or not the scaling is applied to the RTP TS field is up to
the compressor implementation (i.e., The use of scaling is OPTIONAL), the compressor implementation (i.e., the use of scaling is OPTIONAL),
and is indicated by the tsc_indicator control field. In case scaling and is indicated by the tsc_indicator control field. In case scaling
is applied to the RTP TS field, the value of ts_stride used by the is applied to the RTP TS field, the value of ts_stride used by the
compressor is up to the implementation. A value of ts_stride that is compressor is up to the implementation. A value of ts_stride that is
set to the expected increase in RTP timestamp between consecutive set to the expected increase in the RTP timestamp between consecutive
unit increase of the RTP SN will provide the most gain for the scaled unit increases of the RTP SN will provide the most gain for the
encoding. Other values may provide the same gain in some situations, scaled encoding. Other values may provide the same gain in some
but may reduce the gain in others. situations, but may reduce the gain in others.
When scaled timestamp encoding is used for header formats that do not When scaled timestamp encoding is used for header formats that do not
transmit any lsb-encoded timestamp bits at all, the transmit any lsb-encoded timestamp bits at all, the
inferred_scaled_field encoding of Section 6.6.10 is used for encoding inferred_scaled_field encoding of Section 6.6.10 is used for encoding
the timestamp. the timestamp.
6.6.9. timer_based_lsb 6.6.9. timer_based_lsb
The timer-based compression encoding method, "timer_based_lsb", The timer-based compression encoding method, timer_based_lsb,
compresses a field whose change pattern approximates a linear compresses a field whose change pattern approximates a linear
function of the time of day. function of the time of day.
This encoding uses the local clock to obtain an approximation of the This encoding uses the local clock to obtain an approximation of the
value that it encodes. The approximated value is then used as a value that it encodes. The approximated value is then used as a
reference value together with the num_lsbs_param least-significant reference value together with the num_lsbs_param least-significant
bits received as the encoded value, where num_lsbs_param represents a bits received as the encoded value, where num_lsbs_param represents a
number of bits that is sufficient to uniquely represent the encoded number of bits that is sufficient to uniquely represent the encoded
value in the presence of jitter between compression endpoints. value in the presence of jitter between compression endpoints.
skipping to change at page 30, line 40 skipping to change at page 30, line 47
to use for the lsb encoding, i.e., the number of least significant to use for the lsb encoding, i.e., the number of least significant
bits and the interpretation interval offset, respectively. The bits and the interpretation interval offset, respectively. The
parameter "time_stride_param" represents the context value of the parameter "time_stride_param" represents the context value of the
control field time_stride. control field time_stride.
This encoding method always uses a scaled version of the field it This encoding method always uses a scaled version of the field it
compresses. compresses.
The value of the field is decoded by calculating an approximation of The value of the field is decoded by calculating an approximation of
the scaled value, using: the scaled value, using:
tsc_ref_advanced = tsc_ref + (a_n - a_ref) / time_stride. tsc_ref_advanced = tsc_ref + (a_n - a_ref) / time_stride.
where: where:
- tsc_ref is a reference value of the scaled representation - tsc_ref is a reference value of the scaled representation
of the field. of the field.
- a_n is the arrival time associated to the value to decode. - a_n is the arrival time associated with the value to decode.
- a_ref is the arrival time associated to the reference header. - a_ref is the arrival time associated with the reference header.
- tsc_ref_advanced is an approximation of the scaled value - tsc_ref_advanced is an approximation of the scaled value
of the field. of the field.
The lsb encoding is then applied using the num_lsbs_param bits The lsb encoding is then applied using the num_lsbs_param bits
received in the compressed header and tsc_ref_advanced as "ref_value" received in the compressed header and the tsc_ref_advanced as
(as per Section 4.11.5 of [RFC4997]). "ref_value" (as per Section 4.11.5 of [RFC4997]).
Appendix B.3 provides an example on how the compressor can calculate Appendix B.3 provides an example of how the compressor can calculate
jitter. jitter.
The control field time_stride controls whether or not the The control field time_stride controls whether or not the
timer_based_lsb method is used in the CO header. The decompressor timer_based_lsb method is used in the CO header. The decompressor
SHOULD send the CLOCK_RESOLUTION option with a zero value, if: SHOULD send the CLOCK_RESOLUTION option with a zero value, if:
o it receives a non-zero time_stride value, and o it receives a non-zero time_stride value, and
o it has not previously sent a CLOCK_RESOLUTION feedback with a non- o it has not previously sent a CLOCK_RESOLUTION feedback with a non-
zero value. zero value.
This is to allow compression to recover from the case where a This is to allow compression to recover from the case where a
compressor erroneously activates timer-based compression. compressor erroneously activates timer-based compression.
The support and usage of timer-based compression is OPTIONAL for both The support and usage of timer-based compression is OPTIONAL for both
the compressor and the decompressor; the compressor is not required the compressor and the decompressor; the compressor is not required
to set the time_stride control field to a non-zero value when it has to set the time_stride control field to a non-zero value when it has
received a non-zero value for the CLOCK_RESOLUTION option. received a non-zero value for the CLOCK_RESOLUTION option.
skipping to change at page 31, line 30 skipping to change at page 31, line 40
This is to allow compression to recover from the case where a This is to allow compression to recover from the case where a
compressor erroneously activates timer-based compression. compressor erroneously activates timer-based compression.
The support and usage of timer-based compression is OPTIONAL for both The support and usage of timer-based compression is OPTIONAL for both
the compressor and the decompressor; the compressor is not required the compressor and the decompressor; the compressor is not required
to set the time_stride control field to a non-zero value when it has to set the time_stride control field to a non-zero value when it has
received a non-zero value for the CLOCK_RESOLUTION option. received a non-zero value for the CLOCK_RESOLUTION option.
6.6.10. inferred_scaled_field 6.6.10. inferred_scaled_field
The "inferred_scaled_field" encoding method encodes a field that is The inferred_scaled_field encoding method encodes a field that is
defined as changing in relation to the MSN, and for which the defined as changing in relation to the MSN, and for which the
increase with respect to the MSN can be scaled by some scaling increase with respect to the MSN can be scaled by some scaling
factor. This encoding method is used in compressed header formats factor. This encoding method is used in compressed header formats
that do not contain any bits for the scaled field. In this case, the that do not contain any bits for the scaled field. In this case, the
decompressor infers the unscaled value of the scaled field from the decompressor infers the unscaled value of the scaled field from the
MSN field, which value is calculated according to the following MSN field. The unscaled value is calculated according to the
formula: following formula:
unscaled_value = delta_msn * stride + reference_unscaled_value unscaled_value = delta_msn * stride + reference_unscaled_value
Where "delta_msn" is the difference in MSN between the reference where "delta_msn" is the difference in MSN between the reference
value of the MSN in the context and the value of the MSN decompressed value of the MSN in the context and the value of the MSN decompressed
from this packet, "reference_unscaled_value" is the value of the from this packet, "reference_unscaled_value" is the value of the
field being scaled in the context, and "stride" is the scaling value field being scaled in the context, and "stride" is the scaling value
for this field. for this field.
For example, when this encoding method is applied to the RTP For example, when this encoding method is applied to the RTP
timestamp in the RTP profile, the calculation above becomes: timestamp in the RTP profile, the calculation above becomes:
timestamp = delta_msn * ts_stride + reference_timestamp timestamp = delta_msn * ts_stride + reference_timestamp
6.6.11. control_crc3_encoding 6.6.11. control_crc3_encoding
The "control_crc3_encoding" method provides a CRC calculated over a The control_crc3_encoding method provides a CRC calculated over a
number of control fields. The definition of this encoding method is number of control fields. The definition of this encoding method is
the same as for the "crc" encoding method specified in section 4.11.6 the same as for the "crc" encoding method specified in Section 4.11.6
of [RFC4997], with the difference that the data that is covered by of [RFC4997], with the difference being that the data covered by the
the CRC is given by a concatenated list of control fields. CRC is given by a concatenated list of control fields.
In other words, the definition of the control_crc3_encoding method is In other words, the definition of the control_crc3_encoding method is
equivalent to the following definition: equivalent to the following definition:
control_crc_encoding(ctrl_data_value, ctrl_data_length) control_crc_encoding(ctrl_data_value, ctrl_data_length)
{ {
UNCOMPRESSED { UNCOMPRESSED {
} }
COMPRESSED { COMPRESSED {
skipping to change at page 32, line 33 skipping to change at page 32, line 39
COMPRESSED { COMPRESSED {
control_crc3 =:= control_crc3 =:=
crc(3, 0x06, 0x07, ctrl_data_value, ctrl_data_length) [ 3 ]; crc(3, 0x06, 0x07, ctrl_data_value, ctrl_data_length) [ 3 ];
} }
} }
where the parameter "ctrl_data_value" binds to the concatenated where the parameter "ctrl_data_value" binds to the concatenated
values of the following control fields, in the order listed below: values of the following control fields, in the order listed below:
o reorder_ratio, 2 bits padded with 6 MSB of zeroes o reorder_ratio, 2 bits padded with 6 MSB of zeroes
o ts_stride, 32 bits (only for profiles 0x0101 and 0x0107) o ts_stride, 32 bits (only for profiles 0x0101 and 0x0107)
o time_stride, 32 bits (only for profiles 0x0101 and 0x0107) o time_stride, 32 bits (only for profiles 0x0101 and 0x0107)
o msn, 16 bits (not applicable for profiles 0x0101, 0x0103 and
o msn, 16 bits (not applicable for profiles 0x0101, 0x0103, and
0x0107) 0x0107)
o coverage_behavior, 2 bits padded with 6 MSB of zeroes (only to
o coverage_behavior, 2 bits padded with 6 MSB of zeroes (only for
profiles 0x0107 and 0x0108) profiles 0x0107 and 0x0108)
o ip_id_behavior, one octet for each IP header in the compressible o ip_id_behavior, one octet for each IP header in the compressible
header chain starting from the outermost header. Each octet header chain starting from the outermost header. Each octet
consists of 2 bits padded with 6 MSBs of zeroes consists of 2 bits padded with 6 MSBs of zeroes.
The "ctrl_data_length" binds to the sum of the length of the control The "ctrl_data_length" binds to the sum of the length of the control
field(s) that are applicable to the specific profile. field(s) that are applicable to the specific profile.
The decompressor uses the resulting 3-bit CRC to validate the control The decompressor uses the resulting 3-bit CRC to validate the control
fields that are updated by the co_common and co_repair header fields that are updated by the co_common and co_repair header
formats; this CRC cannot be used to verify the outcome of a formats; this CRC cannot be used to verify the outcome of a
decompression attempt. decompression attempt.
This CRC protects the update of control fields, as the updated values This CRC protects the update of control fields, as the updated values
are not always used to decompress the header that carries them and are not always used to decompress the header that carries them and
thus are not protected by the CRC-7 verification. This prevents thus are not protected by the CRC-7 verification. This prevents
impairments that could occur in case the decompression of a co_common impairments that could occur if the decompression of a co_common or
or of a co_repair succeeds and the decompressor would send positive of a co_repair succeeds and the decompressor sends positive feedback,
feedback, while for some reason the control fields would be while for some reason the control fields are incorrectly updated.
incorrectly updated.
6.6.12. inferred_sequential_ip_id 6.6.12. inferred_sequential_ip_id
This encoding method is used with a sequential IP-ID behavior This encoding method is used with a sequential IP-ID behavior
(sequential or sequential byte-swapped) and when there are no coded (sequential or sequential byte-swapped) and when there are no coded
IP-ID bits in the compressed header. In this case, the IP-ID offset IP-ID bits in the compressed header. In this case, the IP-ID offset
from the MSN is constant, and the IP-ID increases by the same amount from the MSN is constant, and the IP-ID increases by the same amount
as the MSN (similar to the inferred_scaled_field encoding method). as the MSN (similar to the inferred_scaled_field encoding method).
The decompressor calculates the value for the IP-ID according to the The decompressor calculates the value for the IP-ID according to the
skipping to change at page 34, line 29 skipping to change at page 34, line 42
When initializing the context: When initializing the context:
1) The complete representation of the list of CSRC identifiers is 1) The complete representation of the list of CSRC identifiers is
transmitted. transmitted.
Then, once the context has been initialized: Then, once the context has been initialized:
2) When the list is unchanged, a compressed header that does not 2) When the list is unchanged, a compressed header that does not
contain information about the list can be used. contain information about the list can be used.
3) When the list changes, a compressed list is sent in the
compressed header, including a representation of its structure and 3) When the list changes, a compressed list is sent in the compressed
order. Previously unknown items are sent uncompressed in the header, including a representation of its structure and order.
list, while previously known items are only represented by an Previously unknown items are sent uncompressed in the list, while
index pointing to the item stored in the context. previously known items are only represented by an index pointing
to the item stored in the context.
6.6.13.2. Table-based Item Compression 6.6.13.2. Table-based Item Compression
The table-based item compression compresses individual items sent in The table-based item compression compresses individual items sent in
compressed lists. The compressor assigns a unique identifier, compressed lists. The compressor assigns a unique identifier,
"Index", to each item "Item" of a list. "Index", to each item "Item" of a list.
Compressor Logic Compressor Logic
The compressor conceptually maintains an Item Table containing all The compressor conceptually maintains an item table containing all
items, indexed using "Index". The (Index, Item) pair is sent items, indexed using "Index". The (Index, Item) pair is sent
together in compressed lists until the compressor gains enough together in compressed lists until the compressor gains enough
confidence that the decompressor has observed the mapping between confidence that the decompressor has observed the mapping between
items and their respective index. Confidence is obtained from the items and their respective index. Confidence is obtained from the
reception of an acknowledgment from the decompressor, or by reception of an acknowledgment from the decompressor, or by
sending (Index, Item) pairs using the optimistic approach. Once sending (Index, Item) pairs using the optimistic approach. Once
confidence is obtained, the index alone is sent in compressed confidence is obtained, the index alone is sent in compressed
lists to indicate the presence of the item corresponding to this lists to indicate the presence of the item corresponding to this
index. index.
The compressor MAY reset its item table upon receiving negative The compressor MAY reset its item table upon receiving a negative
acknowledgement. acknowledgement.
The compressor MAY reassign an existing index to a new item, by The compressor MAY reassign an existing index to a new item by re-
re-establishing the mapping using the procedure described above. establishing the mapping using the procedure described above.
Decompressor Logic Decompressor Logic
The decompressor conceptually maintains an Item Table that The decompressor conceptually maintains an item table that
contains all (Index, Item) pairs received. The Item Table is contains all (Index, Item) pairs received. The item table is
updated whenever an (Index, Item) pair is received and updated whenever an (Index, Item) pair is received and
decompression is successful (CRC verification, or CRC-8 decompression is successful (CRC verification, or CRC-8
validation). The decompressor retrieves the item from the table validation). The decompressor retrieves the item from the table
whenever an Index is received without an accompanying Item. whenever an Index is received without an accompanying Item.
If an index is received without an accompanying Item and the If an index is received without an accompanying Item and the
decompressor does not have any context for this index, the decompressor does not have any context for this index, the
decompressor MUST NOT deliver the packet to upper layers. decompressor MUST NOT deliver the packet to upper layers.
6.6.13.3. Encoding of Compressed Lists 6.6.13.3. Encoding of Compressed Lists
Each item present in a compressed list is represented by: Each item present in a compressed list is represented by:
o an index into the table of items, and o an Index into the table of items, and a presence bit indicating if
o a presence bit indicating if a compressed representation of the a compressed representation of the item is present in the list.
item is present in the list.
o an item (if the presence bit is set) o an item (if the presence bit is set).
If the presence bit is not set, the item must already be known by the If the presence bit is not set, the item must already be known by the
decompressor. decompressor.
A compressed list of items uses the following encoding: A compressed list of items uses the following encoding:
0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
+---+---+---+---+---+---+---+---+ +---+---+---+---+---+---+---+---+
| Reserved |PS | m | | Reserved |PS | m |
+---+---+---+---+---+---+---+---+ +---+---+---+---+---+---+---+---+
| XI_1, ..., XI_m | m octets, or m * 4 bits | XI_1, ..., XI_m | m octets, or m * 4 bits
/ --- --- --- ---/ / --- --- --- ---/
| : Padding : if PS = 0 and m is odd | : Padding : if PS = 0 and m is odd
+---+---+---+---+---+---+---+---+ +---+---+---+---+---+---+---+---+
| | | |
/ item_1, ..., item_n / variable / Item_1, ..., Item_n / variable
| | | |
+---+---+---+---+---+---+---+---+ +---+---+---+---+---+---+---+---+
Reserved: MUST be set to zero; otherwise, the decompressor MUST Reserved: MUST be set to zero; otherwise, the decompressor MUST
discard the packet. discard the packet.
PS: Indicates size of XI fields: PS: Indicates size of XI fields:
PS = 0 indicates 4-bit XI fields; PS = 0 indicates 4-bit XI fields;
PS = 1 indicates 8-bit XI fields. PS = 1 indicates 8-bit XI fields.
m: Number of XI item(s) in the compressed list. Also the value of m: Number of XI item(s) in the compressed list. Also, the value
the cc_value argument of the list_csrc encoding (Section 6.6.13). of the cc_value argument of the list_csrc encoding (see
Section 6.6.13).
XI_1, ..., XI_m: m XI items. Each XI represents one item in the XI_1, ..., XI_m: m XI items. Each XI represents one item in the
list of item of the uncompressed header, in the same order as they list of items of the uncompressed header, in the same order as
appear in the uncompressed header. they appear in the uncompressed header.
The format of an XI item is as follows: The format of an XI item is as follows:
0 1 2 3 0 1 2 3
+---+---+---+---+ +---+---+---+---+
PS = 0: | X | Index | PS = 0: | X | Index |
+---+---+---+---+ +---+---+---+---+
0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
+---+---+---+---+---+---+---+---+ +---+---+---+---+---+---+---+---+
PS = 1: | X | Reserved | Index | PS = 1: | X | Reserved | Index |
+---+---+---+---+---+---+---+---+ +---+---+---+---+---+---+---+---+
X: Indicates whether the item is present in the list: X: Indicates whether the item is present in the list:
X = 1 indicates that the item corresponding to the Index is X = 1 indicates that the item corresponding to the Index is
sent in the item_1, ..., item_n list; sent in the Item_1, ..., Item_n list;
X = 0 indicates that the item corresponding to the Index is X = 0 indicates that the item corresponding to the Index is
not sent. not sent.
Reserved: MUST be set to zero; otherwise the decompressor MUST Reserved: MUST be set to zero; otherwise, the decompressor MUST
discard the packet. discard the packet.
Index: An index into the item table. See Section 6.6.13.4 Index: An index into the item table. See Section 6.6.13.4
When 4-bit XI items are used, the XI items are placed in octets When 4-bit XI items are used, the XI items are placed in octets
in the following manner: in the following manner:
0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
+---+---+---+---+---+---+---+---+ +---+---+---+---+---+---+---+---+
| XI_k | XI_k + 1 | | XI_k | XI_k + 1 |
+---+---+---+---+---+---+---+---+ +---+---+---+---+---+---+---+---+
Padding: A 4-bit padding field is present when PS = 0 and the
Padding: A 4-bit Padding field is present when PS = 0 and the
number of XIs is odd. The Padding field MUST be set to zero; number of XIs is odd. The Padding field MUST be set to zero;
otherwise, the decompressor MUST discard the packet. otherwise, the decompressor MUST discard the packet.
Item 1, ..., item n: Each item corresponds to an XI with X = 1 in Item 1, ..., item n: Each item corresponds to an XI with X = 1 in
XI 1, ..., XI m. Each entry in the item list is the uncompressed XI 1, ..., XI m. Each entry in the Item list is the uncompressed
representation of one CSRC identifier. representation of one CSRC identifier.
6.6.13.4. Item Table Mappings 6.6.13.4. Item Table Mappings
The item table for list compression is limited to 16 different items, The item table for list compression is limited to 16 different items,
since the RTP header can only carry at most 15 simultaneous CSRC since the RTP header can only carry at most 15 simultaneous CSRC
identifiers. The effect of having more than 16 items in the item identifiers. The effect of having more than 16 items in the item
table will only cause a slight overhead to the compressor when items table will only cause a slight overhead to the compressor when items
are swapped in/out of the item table. are swapped in/out of the item table.
6.6.13.5. Compressed Lists in Dynamic Chain 6.6.13.5. Compressed Lists in Dynamic Chain
A compressed list that is part of the dynamic chain must have all its A compressed list that is part of the dynamic chain must have all of
list items present, i.e., all X-bits in the XI list MUST be set. All its list items present, i.e., all X-bits in the XI list MUST be set.
items previously established in the item table that are not present All items previously established in the item table that are not
in the list decompressed from this packet MUST also be retained in present in the list decompressed from this packet MUST also be
the decompressor context. retained in the decompressor context.
6.7. Encoding Methods With External Parameters as Arguments 6.7. Encoding Methods with External Parameters as Arguments
A number of encoding methods in Section 6.8.2.4 have one or more A number of encoding methods in Section 6.8.2.4 have one or more
arguments for which the derivation of the parameter's value is arguments for which the derivation of the parameter's value is
outside the scope of the ROHC-FN specification of the header formats. outside the scope of the ROHC-FN [RFC4997] specification of the
header formats.
List of encoding methods with external parameters as arguments, from The following is a list of encoding methods with external parameters
Section 6.8.2.4: as arguments, from Section 6.8.2.4:
o udp(profile_value, reorder_ratio_value) o udp(profile_value, reorder_ratio_value)
o udp_lite(profile_value, reorder_ratio_value, o udp_lite(profile_value, reorder_ratio_value,
coverage_behavior_value) coverage_behavior_value)
o esp(profile_value, reorder_ratio_value) o esp(profile_value, reorder_ratio_value)
o rtp(profile_value, ts_stride_value, time_stride_value, o rtp(profile_value, ts_stride_value, time_stride_value,
reorder_ratio_value) reorder_ratio_value)
o ipv4(profile_value, is_innermost, outer_ip_flag, o ipv4(profile_value, is_innermost, outer_ip_flag,
ip_id_behavior_value, reorder_ratio_value)) ip_id_behavior_value, reorder_ratio_value))
o ipv6(profile_value, is_innermost, outer_ip_flag, o ipv6(profile_value, is_innermost, outer_ip_flag,
reorder_ratio_value)) reorder_ratio_value))
o iponly_baseheader(profile_value, outer_ip_flag, o iponly_baseheader(profile_value, outer_ip_flag,
ip_id_behavior_value, reorder_ratio_value) ip_id_behavior_value, reorder_ratio_value)
o udp_baseheader(profile_value, outer_ip_flag, ip_id_behavior_value, o udp_baseheader(profile_value, outer_ip_flag, ip_id_behavior_value,
reorder_ratio_value) reorder_ratio_value)
o udplite_baseheader(profile_value, outer_ip_flag, o udplite_baseheader(profile_value, outer_ip_flag,
ip_id_behavior_value, reorder_ratio_value) ip_id_behavior_value, reorder_ratio_value)
o esp_baseheader(profile_value, outer_ip_flag, ip_id_behavior_value, o esp_baseheader(profile_value, outer_ip_flag, ip_id_behavior_value,
reorder_ratio_value) reorder_ratio_value)
o rtp_baseheader(profile_value, ts_stride_value, time_stride_value, o rtp_baseheader(profile_value, ts_stride_value, time_stride_value,
outer_ip_flag, ip_id_behavior_value, reorder_ratio_value) outer_ip_flag, ip_id_behavior_value, reorder_ratio_value)
o udplite_rtp_baseheader(profile_value, ts_stride_value, o udplite_rtp_baseheader(profile_value, ts_stride_value,
time_stride_value, outer_ip_flag, ip_id_behavior_value, time_stride_value, outer_ip_flag, ip_id_behavior_value,
reorder_ratio_value, coverage_behavior_value) reorder_ratio_value, coverage_behavior_value)
The following applies for all parameters listed below: At the The following applies for all parameters listed below: At the
compressor, the value of the parameter is set according to the compressor, the value of the parameter is set according to the
recommendations for each parameter. At the decompressor, the value recommendations for each parameter. At the decompressor, the value
of the parameter is set to undefined and will get bound by encoding of the parameter is set to undefined and will get bound by encoding
methods, except where otherwise noted. methods, except where otherwise noted.
skipping to change at page 38, line 20 skipping to change at page 39, line 7
o udplite_rtp_baseheader(profile_value, ts_stride_value, o udplite_rtp_baseheader(profile_value, ts_stride_value,
time_stride_value, outer_ip_flag, ip_id_behavior_value, time_stride_value, outer_ip_flag, ip_id_behavior_value,
reorder_ratio_value, coverage_behavior_value) reorder_ratio_value, coverage_behavior_value)
The following applies for all parameters listed below: At the The following applies for all parameters listed below: At the
compressor, the value of the parameter is set according to the compressor, the value of the parameter is set according to the
recommendations for each parameter. At the decompressor, the value recommendations for each parameter. At the decompressor, the value
of the parameter is set to undefined and will get bound by encoding of the parameter is set to undefined and will get bound by encoding
methods, except where otherwise noted. methods, except where otherwise noted.
List of external arguments with their respective definition: The following is a list of external arguments with their respective
definition:
o profile_value: o profile_value:
Set to the 16-bit number that identifies the profile used to Set to the 16-bit number that identifies the profile used to
compress this packet. When processing the static chain at the compress this packet. When processing the static chain at the
decompressor, this parameter is set to the value of the profile decompressor, this parameter is set to the value of the profile
field in the IR header (see Section 6.8.1). field in the IR header (see Section 6.8.1).
o reorder_ratio_value: o reorder_ratio_value:
skipping to change at page 39, line 7 skipping to change at page 39, line 39
o coverage_behavior_value: o coverage_behavior_value:
Set to a 2-bit integer value, using one of the constants whose Set to a 2-bit integer value, using one of the constants whose
name begins with the prefix UDP_LITE_COVERAGE_ and as defined name begins with the prefix UDP_LITE_COVERAGE_ and as defined
in Section 6.8.2.4. in Section 6.8.2.4.
o outer_ip_flag: o outer_ip_flag:
This parameter is set to 1 if at least one of the TOS/TC or This parameter is set to 1 if at least one of the TOS/TC or
TTL/Hop Limit fields in outer IP headers has changed compared TTL/Hop Limit fields in outer IP headers has changed compared
to their reference values in the context, otherwise it is set to their reference values in the context; otherwise, it is set
to 0. This flag may only be set to 1 for the "co_common" to 0. This flag may only be set to 1 for the "co_common"
header format in the different profiles. header format in the different profiles.
o is_innermost: o is_innermost:
This boolean flag is set to 1 when processing the innermost of This boolean flag is set to 1 when processing the innermost of
the compressible IP headers; otherwise it is set to 0. the compressible IP headers; otherwise, it is set to 0.
o ts_stride_value o ts_stride_value
The value of this parameter should be set to the expected The value of this parameter should be set to the expected
increase in the RTP Timestamp between consecutive RTP sequence increase in the RTP Timestamp between consecutive RTP sequence
numbers. The value selected is implementation-specific. See numbers. The value selected is implementation-specific. See
also Section 6.6.8. also Section 6.6.8.
o time_stride_value o time_stride_value
skipping to change at page 39, line 44 skipping to change at page 40, line 33
ROHCv2 profiles use two different header types: the Initialization ROHCv2 profiles use two different header types: the Initialization
and Refresh (IR) header type, and the Compressed header type (CO). and Refresh (IR) header type, and the Compressed header type (CO).
The CO header type defines a number of header formats: there are two The CO header type defines a number of header formats: there are two
sets of base header formats, with a few additional formats that are sets of base header formats, with a few additional formats that are
common to both sets. common to both sets.
6.8.1. Initialization and Refresh Header Format (IR) 6.8.1. Initialization and Refresh Header Format (IR)
The IR header format uses the structure of the ROHC IR header as The IR header format uses the structure of the ROHC IR header as
defined in [RFC4995], section 5.2.2.1. defined in Section 5.2.2.1 of [RFC4995].
Header type: IR Header type: IR
This header format communicates the static part and the dynamic This header format communicates the static part and the dynamic
part of the context. part of the context.
The ROHCv2 IR header has the following format: The ROHCv2 IR header has the following format:
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 != 0) : Add-CID octet : if for small CIDs and (CID != 0)
+---+---+---+---+---+---+---+---+ +---+---+---+---+---+---+---+---+
| 1 1 1 1 1 1 0 1 | IR type octet | 1 1 1 1 1 1 0 1 | IR type octet
skipping to change at page 40, line 46 skipping to change at page 41, line 45
Static chain: See Section 6.5. Static chain: See Section 6.5.
Dynamic chain: See Section 6.5. Dynamic chain: See Section 6.5.
6.8.2. Compressed Header Formats (CO) 6.8.2. Compressed Header Formats (CO)
6.8.2.1. Design Rationale for Compressed Base Headers 6.8.2.1. Design Rationale for Compressed Base Headers
The compressed header formats are defined as two separate sets for The compressed header formats are defined as two separate sets for
each profile: one set for the headers where the innermost IP header each profile: one set for the headers where the innermost IP header
contains a sequential IP-ID (either network byte order or byte contains a sequential IP-ID (either network byte order or byte-
swapped), and one set for the headers without sequential IP-ID swapped), and one set for the headers without sequential IP-ID
(either random, zero, or no IP-ID). There are also a number of (either random, zero, or no IP-ID). There are also a number of
common header formats shared between both sets. In the description common header formats shared between both sets. In the description
below, the naming convention used for header formats that belong to below, the naming convention used for header formats that belong to
the sequential set is to include "seq" in the name of the format, the sequential set is to include "seq" in the name of the format,
while similarly "rnd" is used for those that belong to the non- while similarly "rnd" is used for those that belong to the non-
sequential set. sequential set.
The design of the header formats is derived from the field behavior The design of the header formats is derived from the field behavior
analysis found in Appendix A. analysis found in Appendix A.
skipping to change at page 41, line 30 skipping to change at page 42, line 25
o co_common: This format can be used to update the context when the o co_common: This format can be used to update the context when the
established change pattern of a dynamic field changes, for any of established change pattern of a dynamic field changes, for any of
the dynamic fields. However, not all dynamic fields are updated the dynamic fields. However, not all dynamic fields are updated
by conveying their uncompressed value; some fields can only be by conveying their uncompressed value; some fields can only be
transmitted using a compressed representation. This format is transmitted using a compressed representation. This format is
especially useful when a rarely changing field needs to be especially useful when a rarely changing field needs to be
updated. This format contains a set of flags to indicate what updated. This format contains a set of flags to indicate what
fields are present in the header, and its size can vary fields are present in the header, and its size can vary
accordingly. This format is protected by a 7-bit CRC. It can accordingly. This format is protected by a 7-bit CRC. It can
update control fields, and it thus also carries a 3-bit CRC to update control fields, and it thus also carries a 3-bit CRC to
protect those fields as well. This format is similar in purpose protect those fields. This format is similar in purpose to the
to the UOR-2-extension 3 format of [RFC3095]. UOR-2-extension 3 format of [RFC3095].
o co_repair: This format can be used to update the context of all o co_repair: This format can be used to update the context of all
the dynamic fields by conveying their uncompressed value. This is the dynamic fields by conveying their uncompressed value. This is
especially useful when context damage is assumed (e.g. from the especially useful when context damage is assumed (e.g., from the
reception of a NACK) and a context repair is performed. This reception of a NACK) and a context repair is performed. This
format is protected by a 7-bit CRC. It also carries a 3-bit CRC format is protected by a 7-bit CRC. It also carries a 3-bit CRC
over the control fields, which control fields it can also update. over the control fields that it can update. This format is
This format is similar in purpose to the IR-DYN format of similar in purpose to the IR-DYN format of [RFC3095] when
[RFC3095] when performing context repairs. performing context repairs.
o pt_0_crc3: This format conveys only the MSN; it can therefore only o pt_0_crc3: This format conveys only the MSN; it can therefore only
update the MSN and fields that are derived from the MSN, such as update the MSN and fields that are derived from the MSN, such as
IP-ID and the RTP Timestamp (for applicable profiles). It is IP-ID and the RTP Timestamp (for applicable profiles). It is
protected by a 3-bit CRC. This format is equivalent to the UO-0 protected by a 3-bit CRC. This format is equivalent to the UO-0
header format in [RFC3095]. header format in [RFC3095].
o pt_0_crc7: This format has the same properties as pt_0_crc3, but o pt_0_crc7: This format has the same properties as pt_0_crc3, but
is instead protected by a 7-bit CRC and contains a larger amount is instead protected by a 7-bit CRC and contains a larger amount
of lsb-encoded MSN bits. This format is useful in environments of lsb-encoded MSN bits. This format is useful in environments
where a high amount of reordering or a high residual error rate where a high amount of reordering or a high-residual error rate
can occur. can occur.
The following header format descriptions apply to profiles 0x0101 and The following header format descriptions apply to profiles 0x0101 and
0x0107. 0x0107.
o pt_1_rnd: This format can convey changes to the MSN, to the RTP o pt_1_rnd: This format can convey changes to the MSN and to the RTP
Marker bit and it can update the RTP timestamp using scaled Marker bit, and it can update the RTP timestamp using scaled
timestamp encoding. It is protected by a 3-bit CRC. It is timestamp encoding. It is protected by a 3-bit CRC. It is
similar in purpose to the UO-1 format in [RFC3095]. similar in purpose to the UO-1 format in [RFC3095].
o pt_1_seq_id: This format can convey changes to the MSN and to the o pt_1_seq_id: This format can convey changes to the MSN and to the
IP-ID. It is protected by a 3-bit CRC. It is similar in purpose IP-ID. It is protected by a 3-bit CRC. It is similar in purpose
to the UO-1-ID format in [RFC3095]. to the UO-1-ID format in [RFC3095].
o pt_1_seq_ts: This format can convey changes to the MSN, to the RTP o pt_1_seq_ts: This format can convey changes to the MSN and to the
Marker bit and it can update the RTP Timestamp using scaled RTP Marker bit, and it can update the RTP Timestamp using scaled
timestamp encoding. It is protected by a 3-bit CRC. It is timestamp encoding. It is protected by a 3-bit CRC. It is
similar in purpose to the UO-1-TS format in [RFC3095]. similar in purpose to the UO-1-TS format in [RFC3095].
o pt_2_rnd: This format can convey changes to the MSN, to the RTP o pt_2_rnd: This format can convey changes to the MSN, to the RTP
Marker bit and to the RTP Timestamp. It is protected by a 7-bit Marker bit, and to the RTP Timestamp. It is protected by a 7-bit
CRC. It is similar in purpose to the UOR-2 format in [RFC3095]. CRC. It is similar in purpose to the UOR-2 format in [RFC3095].
o pt_2_seq_id: This format can convey changes to the MSN and to the o pt_2_seq_id: This format can convey changes to the MSN and to the
IP-ID. It is protected by a 7-bit CRC. It is similar in purpose IP-ID. It is protected by a 7-bit CRC. It is similar in purpose
to the UO-2-ID format in [RFC3095]. to the UO-2-ID format in [RFC3095].
o pt_2_seq_ts: This format can convey changes to the MSN, to the RTP o pt_2_seq_ts: This format can convey changes to the MSN, to the RTP
Marker bit and it can update the RTP Timestamp using scaled Marker bit and it can update the RTP Timestamp using scaled
timestamp encoding. It is protected by a 7-bit CRC. It is timestamp encoding. It is protected by a 7-bit CRC. It is
similar in purpose to the UO-2-TS format in [RFC3095]. similar in purpose to the UO-2-TS format in [RFC3095].
o pt_2_seq_both: This format can convey changes to both the RTP o pt_2_seq_both: This format can convey changes to both the RTP
Timestamp and IP-ID, in addition to the MSN and to the Marker bit. Timestamp and the IP-ID, in addition to the MSN and to the Marker
It is protected by a 7-bit CRC. It is similar in purpose to the bit. It is protected by a 7-bit CRC. It is similar in purpose to
UOR-2-ID extension 1 format in [RFC3095]. the UOR-2-ID extension 1 format in [RFC3095].
The following header formats descriptions apply to profiles 0x0102, The following header format descriptions apply to profiles 0x0102,
0x0103, 0x0104 and 0x0108. 0x0103, 0x0104, and 0x0108.
o pt_1_seq_id: This format can convey changes to the MSN and to the o pt_1_seq_id: This format can convey changes to the MSN and to the
IP-ID. It is protected by a 7-bit CRC. It is similar in purpose IP-ID. It is protected by a 7-bit CRC. It is similar in purpose
to the UO-1-ID format in [RFC3095]. to the UO-1-ID format in [RFC3095].
o pt_2_seq_id: This format can convey changes to the MSN and to the o pt_2_seq_id: This format can convey changes to the MSN and to the
IP-ID. It is protected by a 7-bit CRC. It is similar in purpose IP-ID. It is protected by a 7-bit CRC. It is similar in purpose
to the UO-2-ID format in [RFC3095]. to the UO-2-ID format in [RFC3095].
6.8.2.2. co_repair Header Format 6.8.2.2. co_repair Header Format
skipping to change at page 43, line 36 skipping to change at page 44, line 32
+---+---+---+---+---+---+---+---+ +---+---+---+---+---+---+---+---+
| | | |
/ Dynamic chain / variable length / Dynamic chain / variable length
| | | |
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
r1: MUST be set to zero; otherwise, the decompressor MUST discard r1: MUST be set to zero; otherwise, the decompressor MUST discard
the packet. the packet.
CRC-7: A 7-bit CRC over the entire uncompressed header, computed CRC-7: A 7-bit CRC over the entire uncompressed header, computed
using the crc7(data_value, data_length) encoding method defined in using the crc7 (data_value, data_length) encoding method defined
Section 6.8.2.4, where data_value corresponds to the entire in Section 6.8.2.4, where data_value corresponds to the entire
uncompressed header chain and where data_length corresponds to the uncompressed header chain and where data_length corresponds to the
length of this header chain. length of this header chain.
r2: MUST be set to zero; otherwise, the decompressor MUST discard r2: MUST be set to zero; otherwise, the decompressor MUST discard
the packet. the packet.
CRC-3: Encoded using the control_crc3_encoding method defined in CRC-3: Encoded using the control_crc3_encoding method defined in
Section 6.6.11. Section 6.6.11.
Dynamic chain: See Section 6.5. Dynamic chain: See Section 6.5.
6.8.2.3. General CO Header Format 6.8.2.3. General CO Header Format
The CO header format communicates irregularities in the packet The CO header format communicates irregularities in the packet
header. All CO formats carry a CRC and can update the context. All header. All CO formats carry a CRC and can update the context. All
CO header formats use the general format defined in this section, CO header formats use the general format defined in this section,
with the exception of the co_repair format which is defined in with the exception of the co_repair format, which is defined in
Section 6.8.2.2 . Section 6.8.2.2 .
The general format for a compressed header is as follows: The general format for a compressed header is as follows:
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
+---+---+---+---+---+---+---+---+ +---+---+---+---+---+---+---+---+
| first octet of base header | (with type indication) | first octet of base header | (with type indication)
+---+---+---+---+---+---+---+---+ +---+---+---+---+---+---+---+---+
skipping to change at page 45, line 9 skipping to change at page 45, line 47
| 0x0103 | esp | | 0x0103 | esp |
| 0x0104 | ip | | 0x0104 | ip |
| 0x0107 | udplite_rtp | | 0x0107 | udplite_rtp |
| 0x0108 | udplite | | 0x0108 | udplite |
+------------------+----------------+ +------------------+----------------+
6.8.2.4. Header Formats in ROHC-FN 6.8.2.4. Header Formats in ROHC-FN
This section defines the complete set of base header formats for This section defines the complete set of base header formats for
ROHCv2 profiles. The base header formats are defined using the ROHC ROHCv2 profiles. The base header formats are defined using the ROHC
Formal notation [RFC4997] . Formal Notation [RFC4997].
// NOTE The irregular, static and dynamic chains (see section 6.5) // NOTE: The irregular, static, and dynamic chains (see Section 6.5)
// are defined across multiple encoding methods and are embodied // are defined across multiple encoding methods and are embodied
// in the correspondingly named formats within those encoding // in the correspondingly named formats within those encoding
// methods. In particular note that the static and dynamic // methods. In particular, note that the static and dynamic
// chains ordinarily go together. The uncompressed fields are // chains ordinarily go together. The uncompressed fields are
// defined across these two formats combined, rather than in one // defined across these two formats combined, rather than in one
// or the other of them. The irregular chain items are likewise // or the other of them. The irregular chain items are likewise
// combined with a baseheader format. // combined with a baseheader format.
//////////////////////////////////////////// ////////////////////////////////////////////
// Constants // Constants
//////////////////////////////////////////// ////////////////////////////////////////////
// IP-ID behavior constants // IP-ID behavior constants
skipping to change at page 99, line 48 skipping to change at page 100, line 39
header_crc =:= crc7(THIS.UVALUE, THIS.ULENGTH) [ 7 ]; header_crc =:= crc7(THIS.UVALUE, THIS.ULENGTH) [ 7 ];
msn =:= msn_lsb(8) [ 8 ]; msn =:= msn_lsb(8) [ 8 ];
} }
} }
6.9. Feedback Formats and Options 6.9. Feedback Formats and Options
6.9.1. Feedback Formats 6.9.1. Feedback Formats
This section describes the feedback format for ROHCv2 profiles, using This section describes the feedback format for ROHCv2 profiles, using
the formats described in section 5.2.3 of [RFC4995]. the formats described in Section 5.2.3 of [RFC4995].
The Acknowledgment Number field of the feedback formats contains the The Acknowledgment Number field of the feedback formats contains the
least significant bits of the MSN (see Section 6.3.1) that least significant bits of the MSN (see Section 6.3.1) that
corresponds to the reference header that is being acknowledged. A corresponds to the reference header that is being acknowledged. A
reference header is a header that has been successfully CRC-8 reference header is a header that has been successfully CRC-8
validated or CRC verified. If there is no reference header validated or CRC verified. If there is no reference header
available, the feedback MUST carry an ACKNUMBER-NOT-VALID option. available, the feedback MUST carry an ACKNUMBER-NOT-VALID option.
FEEDBACK-1 FEEDBACK-1
0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
+---+---+---+---+---+---+---+---+ +---+---+---+---+---+---+---+---+
| Acknowledgment Number | | Acknowledgment Number |
+---+---+---+---+---+---+---+---+ +---+---+---+---+---+---+---+---+
Acknowledgment Number: The eight least significant bits of the Acknowledgment Number: The eight least significant bits of the
MSN. MSN.
A FEEDBACK-1 is an ACK. In order to send a NACK or a STATIC-NACK, A FEEDBACK-1 is an ACK. In order to send a NACK or a STATIC-NACK,
FEEDBACK-2 must be used. FEEDBACK-2 must be used.
skipping to change at page 100, line 38 skipping to change at page 101, line 31
| Acknowledgment Number | | Acknowledgment Number |
+---+---+---+---+---+---+---+---+ +---+---+---+---+---+---+---+---+
| CRC | | CRC |
+---+---+---+---+---+---+---+---+ +---+---+---+---+---+---+---+---+
/ Feedback options / / Feedback options /
+---+---+---+---+---+---+---+---+ +---+---+---+---+---+---+---+---+
Acktype: Acktype:
0 = ACK 0 = ACK
1 = NACK 1 = NACK
2 = STATIC-NACK 2 = STATIC-NACK
3 is reserved (MUST NOT be used for parsability) 3 is reserved (MUST NOT be used for parsability)
Acknowledgment Number: The least significant bits of the MSN. Acknowledgment Number: The least significant bits of the MSN.
CRC: 8-bit CRC computed over the entire feedback payload including CRC: 8-bit CRC computed over the entire feedback payload including
any CID fields but excluding the feedback type, the 'Size' field any CID fields but excluding the feedback type, the 'Size' field,
and the 'Code' octet, using the polynomial defined in [RFC4995], and the 'Code' octet, using the polynomial defined in Section
Section 5.3.1.1. If the CID is given with an Add-CID octet, the 5.3.1.1 of [RFC4995]. If the CID is given with an Add-CID octet,
Add-CID octet immediately precedes the FEEDBACK-1 or FEEDBACK-2 the Add-CID octet immediately precedes the FEEDBACK-1 or
format. For purposes of computing the CRC, the CRC field is zero. FEEDBACK-2 format. For purposes of computing the CRC, the CRC
field is zero.
Feedback options: A variable number of feedback options, see Feedback options: A variable number of feedback options, see
Section 6.9.2. Options may appear in any order. Section 6.9.2. Options may appear in any order.
A FEEDBACK-2 of type NACK or STATIC-NACK is always implicitly an A FEEDBACK-2 of type NACK or STATIC-NACK is always implicitly an
acknowledgment for a successfully decompressed packet, which acknowledgment for a successfully decompressed packet, which
corresponds to a packet whose LSBs match the Acknowledgment Number of corresponds to a packet whose LSBs match the Acknowledgment Number of
the feedback element, unless the ACKNUMBER-NOT-VALID option the feedback element, unless the ACKNUMBER-NOT-VALID option (see
Section 6.9.2.2 appears in the feedback element. Section 6.9.2.2) appears in the feedback element.
The FEEDBACK-2 format always carry a CRC and is thus more robust than The FEEDBACK-2 format always carries a CRC and is thus more robust
the FEEDBACK-1 format. When receiving FEEDBACK-2, the compressor than the FEEDBACK-1 format. When receiving FEEDBACK-2, the
MUST verify the information by computing the CRC and comparing the compressor MUST verify the information by computing the CRC and
result with the CRC carried in the feedback format. If the two are comparing the result with the CRC carried in the feedback format. If
not identical, the feedback element MUST be discarded. the two are not identical, the feedback element MUST be discarded.
6.9.2. Feedback Options 6.9.2. Feedback Options
A feedback option has variable length and the following general A feedback option has variable length and the following general
format: format:
0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
+---+---+---+---+---+---+---+---+ +---+---+---+---+---+---+---+---+
| Opt Type | Opt Len | | Opt Type | Opt Len |
+---+---+---+---+---+---+---+---+ +---+---+---+---+---+---+---+---+
/ Option Data / Opt Len (octets) / Option Data / Opt Len (octets)
+---+---+---+---+---+---+---+---+ +---+---+---+---+---+---+---+---+
Opt Type: Unsigned integer that represents the type of the Opt Type: Unsigned integer that represents the type of the
feedback option. Sections Section 6.9.2.1 to Section 6.9.2.4 feedback option. Section 6.9.2.1 through Section 6.9.2.4
describe the ROHCv2 feedback options. describes the ROHCv2 feedback options.
Opt Len: The lenght of the Option Data field, in octets. Opt Len: Unsigned integer that represents the length of the Option
Data field, in octets.
Option Data: Feedback type specific data. Present if the value of Option Data: Feedback type specific data. Present if the value of
the Opt Len field is set to a non-zero value. the Opt Len field is set to a non-zero value.
6.9.2.1. The REJECT Option 6.9.2.1. The REJECT Option
The REJECT option informs the compressor that the decompressor does The REJECT option informs the compressor that the decompressor does
not have sufficient resources to handle the flow. not have sufficient resources to handle the flow.
0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
skipping to change at page 102, line 4 skipping to change at page 102, line 48
6.9.2.1. The REJECT Option 6.9.2.1. The REJECT Option
The REJECT option informs the compressor that the decompressor does The REJECT option informs the compressor that the decompressor does
not have sufficient resources to handle the flow. not have sufficient resources to handle the flow.
0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
+---+---+---+---+---+---+---+---+ +---+---+---+---+---+---+---+---+
| Opt Type = 2 | Opt Len = 0 | | Opt Type = 2 | Opt Len = 0 |
+---+---+---+---+---+---+---+---+ +---+---+---+---+---+---+---+---+
When receiving a REJECT option, the compressor MUST stop compressing When receiving a REJECT option, the compressor MUST stop compressing
the packet flow, and SHOULD refrain from attempting to increase the the packet flow, and SHOULD refrain from attempting to increase the
number of compressed packet flows for some time. The REJECT option number of compressed packet flows for some time. The REJECT option
MUST NOT appear more than once in the FEEDBACK-2 format, otherwise MUST NOT appear more than once in the FEEDBACK-2 format; otherwise,
the compressor MUST discard the entire feedback element. the compressor MUST discard the entire feedback element.
6.9.2.2. The ACKNUMBER-NOT-VALID Option 6.9.2.2. The ACKNUMBER-NOT-VALID Option
The ACKNUMBER-NOT-VALID option indicates that the Acknowledgment The ACKNUMBER-NOT-VALID option indicates that the Acknowledgment
Number field of the feedback is not valid. Number field of the feedback is not valid.
0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
+---+---+---+---+---+---+---+---+ +---+---+---+---+---+---+---+---+
| Opt Type = 3 | Opt Len = 0 | | Opt Type = 3 | Opt Len = 0 |
skipping to change at page 102, line 29 skipping to change at page 103, line 26
A compressor MUST NOT use the Acknowledgment Number of the feedback A compressor MUST NOT use the Acknowledgment Number of the feedback
to find the corresponding sent header when this option is present. to find the corresponding sent header when this option is present.
When this option is used, the Acknowledgment Number field of the When this option is used, the Acknowledgment Number field of the
FEEDBACK-2 format is set to zero. Consequently, a NACK or a STATIC- FEEDBACK-2 format is set to zero. Consequently, a NACK or a STATIC-
NACK feedback type sent with the ACKNUMBER-NOT-VALID option is NACK feedback type sent with the ACKNUMBER-NOT-VALID option is
equivalent to a STATIC-NACK with respect to the type of context equivalent to a STATIC-NACK with respect to the type of context
repair requested by the decompressor. repair requested by the decompressor.
The ACKNUMBER-NOT-VALID option MUST NOT appear more than once in the The ACKNUMBER-NOT-VALID option MUST NOT appear more than once in the
FEEDBACK-2 format, otherwise the compressor MUST discard the entire FEEDBACK-2 format; otherwise, the compressor MUST discard the entire
feedback element. feedback element.
6.9.2.3. The CONTEXT_MEMORY Option 6.9.2.3. The CONTEXT_MEMORY Option
The CONTEXT_MEMORY option informs the compressor that the The CONTEXT_MEMORY option informs the compressor that the
decompressor does not have sufficient memory resources to handle the decompressor does not have sufficient memory resources to handle the
context of the packet flow, as the flow is currently compressed. context of the packet flow, as the flow is currently compressed.
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 flow in a way that requires less actions to compress the packet flow in a way that requires less
decompressor memory resources, or stop compressing the packet flow. decompressor memory resources or stop compressing the packet flow.
The CONTEXT_MEMORY option MUST NOT appear more than once in the The CONTEXT_MEMORY option MUST NOT appear more than once in the
FEEDBACK-2 format, otherwise the compressor MUST discard the entire FEEDBACK-2 format; otherwise, the compressor MUST discard the entire
feedback element. feedback element.
6.9.2.4. The CLOCK_RESOLUTION Option 6.9.2.4. The CLOCK_RESOLUTION Option
The CLOCK_RESOLUTION option informs the compressor of the clock The CLOCK_RESOLUTION option informs the compressor of the clock
resolution of the decompressor. It also informs whether the resolution of the decompressor. It also informs whether or not the
decompressor supports timer-based compression of the RTP TS timestamp decompressor supports timer-based compression of the RTP TS timestamp
(see Section 6.6.9) or not. The CLOCK_RESOLUTION option is (see Section 6.6.9). The CLOCK_RESOLUTION option is applicable per
applicable per channel, i.e., it applies to any context associated channel, i.e., it applies to any context associated with a profile
with a profile for which the option is relevant between one for which the option is relevant between a compressor and
compressor and decompressor pair. decompressor pair.
0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
+---+---+---+---+---+---+---+---+ +---+---+---+---+---+---+---+---+
| Opt Type = 10 | Opt Len = 1 | | Opt Type = 10 | Opt Len = 1 |
+---+---+---+---+---+---+---+---+ +---+---+---+---+---+---+---+---+
| Clock resolution (ms) | | Clock resolution (ms) |
+---+---+---+---+---+---+---+---+ +---+---+---+---+---+---+---+---+
Clock resolution: Unsigned integer that represents the clock Clock resolution: Unsigned integer that represents the clock
resolution of the decompressor expressed in milliseconds. resolution of the decompressor expressed in milliseconds.
The smallest clock resolution which can be indicated is 1 The smallest clock resolution that can be indicated is 1 millisecond.
millisecond. The value zero has a special meaning: it indicates that The value zero has a special meaning: it indicates that the
the decompressor cannot do timer-based compression of the RTP decompressor cannot do timer-based compression of the RTP Timestamp.
Timestamp. The CLOCK_RESOLUTION option MUST NOT appear more than The CLOCK_RESOLUTION option MUST NOT appear more than once in the
once in the FEEDBACK-2 format, otherwise the compressor MUST discard FEEDBACK-2 format; otherwise, the compressor MUST discard the entire
the entire feedback element. feedback element.
6.9.2.5. Unknown Option Types 6.9.2.5. Unknown Option Types
If an option type other than those defined in this document is If an option type other than those defined in this document is
encountered, the compressor MUST discard the entire feedback element. encountered, the compressor MUST discard the entire feedback element.
7. Security Considerations 7. Security Considerations
A malfunctioning or malicious header compressor could cause the Impairments such as bit errors on the received compressed headers,
header decompressor to reconstitute packets that do not match the missing packets, and reordering between packets could cause the
original packets but still have valid IP, UDP and RTP headers and header decompressor to reconstitute erroneous packets, i.e., packets
possibly also valid UDP checksums. Such corruption may be detected that do not match the original packet, but still have a valid IP, UDP
with integrity mechanisms which will not be affected by the (or UDP-Lite), and RTP headers, and possibly also valid UDP (or UDP-
compression. Moreover, this header compression scheme uses an Lite) checksums.
internal checksum for verification of reconstructed headers. This
reduces the probability of producing decompressed headers not The header compression profiles defined herein use an internal
matching the original ones without this being noticed, which can be checksum for verification of reconstructed headers. This reduces the
useful in the case of malfunctioning compressors. probability that a header decompressor delivers erroneous packets to
upper layers without the error being noticed. In particular, the
probability that consecutive erroneous packets are not detected by
the internal checksum is close to zero.
This small but non-zero probability remains unchanged when integrity
protection is applied after compression and verified before
decompression, in the case where an attacker could discard or reorder
packets between the compression endpoints.
The impairments mentioned above could be caused by a malfunctioning
or malicious header compressor. Such corruption may be detected with
end-to-end integrity mechanisms that will not be affected by the
compression. Moreover, the internal checksum can also be useful in
the case of malfunctioning compressors.
Denial-of-service attacks are possible if an intruder can introduce Denial-of-service attacks are possible if an intruder can introduce
(for example) bogus IR or FEEDBACK packets onto the link and thereby (for example) bogus IR or FEEDBACK packets onto the link and thereby
cause compression efficiency to be reduced. However, an intruder cause compression efficiency to be reduced. However, an intruder
having the ability to inject arbitrary packets at the link layer in having the ability to inject arbitrary packets at the link layer in
this manner raises additional security issues that dwarf those this manner raises additional security issues that dwarf those
related to the use of header compression. related to the use of header compression.
8. IANA Considerations 8. IANA Considerations
The following ROHC profile identifiers have been reserved by the IANA The following ROHC profile identifiers have been assigned by the IANA
for the profiles defined in this document: for the profiles defined in this document:
Identifier Profile Identifier Profile
---------- ------- ---------- -------
0x0101 ROHCv2 RTP 0x0101 ROHCv2 RTP
0x0102 ROHCv2 UDP 0x0102 ROHCv2 UDP
0x0103 ROHCv2 ESP 0x0103 ROHCv2 ESP
0x0104 ROHCv2 IP 0x0104 ROHCv2 IP
0x0107 ROHCv2 RTP/UDP-Lite 0x0107 ROHCv2 RTP/UDP-Lite
0x0108 ROHCv2 UDP-Lite 0x0108 ROHCv2 UDP-Lite
<# Editor's Note: To be removed before publication #>
ROHC profile identifiers must be reserved by the IANA for the updated
profiles defined in this document. A suggested registration in the
"RObust Header Compression (ROHC) Profile Identifiers" name space
would then be:
Profile Identifier Usage Reference
------------------ ---------------------- ---------
0x0000 ROHC uncompressed RFC 3095
0xnn00 Reserved
0x0001 ROHC RTP RFC 3095
0x0101 ROHCv2 RTP [RFCXXXX (this)]
0xnn01 Reserved
0x0002 ROHC UDP RFC 3095
0x0102 ROHCv2 UDP [RFCXXXX (this)]
0xnn02 Reserved
0x0003 ROHC ESP RFC 3095
0x0103 ROHCv2 ESP [RFCXXXX (this)]
0xnn03 Reserved
0x0004 ROHC IP RFC 3843
0x0104 ROHCv2 IP [RFCXXXX (this)]
0xnn04 Reserved
0x0005 ROHC LLA RFC 4362
0x0105 ROHC LLA with R-mode RFC 3408
0xnn05 Reserved
0x0006 ROHC TCP RFC 4996
0xnn06 Reserved
0x0007 ROHC RTP/UDP-Lite RFC 4019
0x0107 ROHCv2 RTP/UDP-Lite [RFCXXXX (this)]
0xnn07 Reserved
0x0008 ROHC UDP-Lite RFC 4019
0x0108 ROHCv2 UDP-Lite [RFCXXXX (this)]
0xnn08 Reserved
0x0009-0xnn7F To be Assigned by IANA
0xnn80-0xnnFE To be Assigned by IANA
0xnnFF Reserved
9. Acknowledgements 9. Acknowledgements
The authors would like to thank Mark West, Robert Finking, Haipeng The authors would like to thank Mark West, Robert Finking, Haipeng
Jin and Rohit Kapoor for serving as committed document reviewers, and Jin, and Rohit Kapoor for serving as committed document reviewers,
also for constructive discussions during the development of this and also for constructive discussions during the development of this
document. Thanks to Carl Knutsson for his extensive contribution to document. Thanks to Carl Knutsson for his extensive contribution to
this specification, as well as to Jani Juvan and Anders Edqvist for this specification, as well as to Jani Juvan and Anders Edqvist for
useful comments and feedback. Thanks also to Elwyn Davies for his useful comments and feedback. Thanks also to Elwyn Davies for his
review as the General Area Review Team (Gen-ART) reviewer, and to review as the General Area Review Team (Gen-ART) reviewer, and to
Stephen Kent for his review on behalf of the IETF security Stephen Kent for his review on behalf of the IETF security
directorate, during IETF last-call. Finally, thanks to the many directorate, during IETF last-call. Finally, thanks to the many
people who have contributed to previous ROHC specifications and people who have contributed to previous ROHC specifications and
supported this effort. supported this effort.
10. References 10. References
skipping to change at page 107, line 7 skipping to change at page 107, line 10
RFC 4303, December 2005. RFC 4303, December 2005.
[RFC4995] Jonsson, L-E., Pelletier, G., and K. Sandlund, "The RObust [RFC4995] Jonsson, L-E., Pelletier, G., and K. Sandlund, "The RObust
Header Compression (ROHC) Framework", RFC 4995, July 2007. Header Compression (ROHC) Framework", RFC 4995, July 2007.
[RFC4997] Finking, R. and G. Pelletier, "Formal Notation for RObust [RFC4997] Finking, R. and G. Pelletier, "Formal Notation for RObust
Header Compression (ROHC-FN)", RFC 4997, July 2007. Header Compression (ROHC-FN)", RFC 4997, July 2007.
10.2. Informative References 10.2. Informative References
[RFC2675] Borman, D., Deering, S., and R. Hinden, "IPv6 Jumbograms",
RFC 2675, August 1999.
[RFC3095] Bormann, C., Burmeister, C., Degermark, M., Fukushima, H., [RFC3095] Bormann, C., Burmeister, C., Degermark, M., Fukushima, H.,
Hannu, H., Jonsson, L-E., Hakenberg, R., Koren, T., Le, Hannu, H., Jonsson, L-E., Hakenberg, R., Koren, T., Le,
K., Liu, Z., Martensson, A., Miyazaki, A., Svanbro, K., K., Liu, Z., Martensson, A., Miyazaki, A., Svanbro, K.,
Wiebke, T., Yoshimura, T., and H. Zheng, "RObust Header Wiebke, T., Yoshimura, T., and H. Zheng, "RObust Header
Compression (ROHC): Framework and four profiles: RTP, UDP, Compression (ROHC): Framework and four profiles: RTP, UDP,
ESP, and uncompressed", RFC 3095, July 2001. ESP, and uncompressed", RFC 3095, July 2001.
[RFC3843] Jonsson, L-E. and G. Pelletier, "RObust Header Compression [RFC3843] Jonsson, L-E. and G. Pelletier, "RObust Header Compression
(ROHC): A Compression Profile for IP", RFC 3843, (ROHC): A Compression Profile for IP", RFC 3843,
June 2004. June 2004.
skipping to change at page 107, line 43 skipping to change at page 108, line 26
behavior for the types of traffic that are expected to be the most behavior for the types of traffic that are expected to be the most
frequently compressed (e.g., RTP field behavior is based on voice frequently compressed (e.g., RTP field behavior is based on voice
and/or video traffic behavior). and/or video traffic behavior).
Fields are classified as belonging to one of the following classes: Fields are classified as belonging to one of the following classes:
INFERRED - These fields contain values that can be inferred from INFERRED - These fields contain values that can be inferred from
other values, for example the size of the frame carrying the packet, other values, for example the size of the frame carrying the packet,
and thus do not have to be included in compressed packets. and thus do not have to be included in compressed packets.
STATIC These fields are expected to be constant throughout the STATIC - These fields are expected to be constant throughout the
lifetime of the flow and any change to them only has to be possible lifetime of the flow; in general, it is sufficient to design a
to convey in IR packets. compressed format so that these fields are only updated by IR
packets.
STATIC-DEF - These fields are expected to be constant throughout the STATIC-DEF - These fields are expected to be constant throughout the
lifetime of the flow and whose values can be used to define a flow. lifetime of the flow and their values can be used to define a flow.
They are only sent in IR packets. They are only sent in IR packets.
STATIC-KNOWN - These fields are expected to have well-known values STATIC-KNOWN - These fields are expected to have well-known values
and therefore do not need to be communicated at all. and therefore do not need to be communicated at all.
SEMISTATIC These fields are unchanged most of the time. However, SEMISTATIC - These fields are unchanged most of the time. However,
occasionally the value changes but will revert to its original value. occasionally the value changes but will revert to its original value.
For ROHCv2, the values of such fields do not need to be possible to For ROHCv2, the values of such fields do not need to be possible to
change with the smallest compressed packet formats, but should be change with the smallest compressed packet formats, but should be
possible to change via slightly larger compressed packets. possible to change via slightly larger compressed packets.
RARELY CHANGING (RACH) These are fields that change their values RARELY CHANGING (RACH) - These are fields that change their values
occasionally and then keep their new values. For ROHCv2, the values occasionally and then keep their new values. For ROHCv2, the values
of such fields do not need to be possible to change with the smallest of such fields do not need to be possible to change with the smallest
compressed packet formats, but should be possible to change via compressed packet formats, but should be possible to change via
slightly larger compressed packets. slightly larger compressed packets.
IRREGULAR These are the fields for which no useful change pattern can IRREGULAR - These are the fields for which no useful change pattern
be identified and should be transmitted uncompressed in all can be identified and should be transmitted uncompressed in all
compressed packets. compressed packets.
PATTERN These are fields that change between each packet, but change PATTERN - These are fields that change between each packet, but
in a predictable pattern. change in a predictable pattern.
Appendix A.1. IPv4 Header Fields A.1. IPv4 Header Fields
+------------------------+----------------+ +------------------------+----------------+
| Field | Class | | Field | Class |
+------------------------+----------------+ +------------------------+----------------+
| Version | STATIC-KNOWN | | Version | STATIC-KNOWN |
| Header Length | STATIC-KNOWN | | Header Length | STATIC-KNOWN |
| Type Of Service | RACH | | Type Of Service | RACH |
| Packet Length | INFERRED | | Packet Length | INFERRED |
| Identification | | | Identification | |
| Sequential | PATTERN | | Sequential | PATTERN |
skipping to change at page 109, line 4 skipping to change at page 109, line 34
| More Fragments flag | STATIC-KNOWN | | More Fragments flag | STATIC-KNOWN |
| Fragment Offset | STATIC-KNOWN | | Fragment Offset | STATIC-KNOWN |
| Time To Live | RACH | | Time To Live | RACH |
| Protocol | STATIC-DEF | | Protocol | STATIC-DEF |
| Header Checksum | INFERRED | | Header Checksum | INFERRED |
| Source Address | STATIC-DEF | | Source Address | STATIC-DEF |
| Destination Address | STATIC-DEF | | Destination Address | STATIC-DEF |
+------------------------+----------------+ +------------------------+----------------+
Version Version
The version field states which IP version is used, and is set to
The version field states which IP version is used and is set to
the value four. the value four.
Header Length Header Length
As long no options are present in the IP header, the header length
is constant with the value five. If there are options, the field As long as no options are present in the IP header, the header
could be RACH or STATIC-DEF, but only option-less headers are length is constant with the value five. If there are options, the
compressed by ROHCv2 profiles. The field is therefore classified field could be RACH or STATIC-DEF, but only option-less headers
as STATIC-KNOWN. are compressed by ROHCv2 profiles. The field is therefore
classified as STATIC-KNOWN.
Type Of Service Type Of Service
The Type Of Service field is expected to be constant during the
lifetime of a flow or to change relatively seldom. For the type of flows compressed by the ROHCv2 profiles, the DSCP
(Differentiated Services Code Point) and ECN (Explicit Congestion
Notification) fields are expected to change relatively seldom.
Packet Length Packet Length
Information about packet length is expected to be provided by the Information about packet length is expected to be provided by the
link layer. The field is therefore classified as INFERRED. link layer. The field is therefore classified as INFERRED.
IPv4 Identification IPv4 Identification
The Identification field (IP ID) is used to identify what
The Identification field (IP-ID) is used to identify what
fragments constitute a datagram when reassembling fragmented fragments constitute a datagram when reassembling fragmented
datagrams. The IPv4 specification does not specify exactly how datagrams. The IPv4 specification does not specify exactly how
this field is to be assigned values, only that each packet should this field is to be assigned values, only that each packet should
get an IP ID that is unique for the source-destination pair and get an IP-ID that is unique for the source-destination pair and
protocol for the time the datagram (or any of its fragments) could protocol for the time the datagram (or any of its fragments) could
be alive in the network. This means that assignment of IP ID be alive in the network. This means that assignment of IP-ID
values can be done in various ways, but the expected behaviors values can be done in various ways, but the expected behaviors
have been separated into four classes. have been separated into four classes.
Sequential Sequential
In this behavior, the IP-ID is expected to increment by one for In this behavior, the IP-ID is expected to increment by one for
most packets, but may increment by a value larger than one, most packets, but may increment by a value larger than one,
depending on the behavior of the transmitting IPv4 stack. depending on the behavior of the transmitting IPv4 stack.
Sequential Swapped Sequential Swapped
When using this behavior, the IP-ID behaves as in the When using this behavior, the IP-ID behaves as in the
Sequential behavior, but the two bytes of IP-ID are byte Sequential behavior, but the two bytes of IP-ID are byte-
swapped. Therefore, the IP-ID can be swapped before swapped. Therefore, the IP-ID can be swapped before
compression to make it behave exactly as the Sequential compression to make it behave exactly as the Sequential
behavior. behavior.
Random Random
Some IP stacks assign IP ID values using a pseudo-random number
Some IP stacks assign IP-ID values using a pseudo-random number
generator. There is thus no correlation between the ID values generator. There is thus no correlation between the ID values
of subsequent datagrams, and therefore there is no way to of subsequent datagrams, and therefore there is no way to
predict the IP ID value for the next datagram. For header predict the IP-ID value for the next datagram. For header
compression purposes, this means that the IP ID field needs to compression purposes, this means that the IP-ID field needs to
be sent uncompressed with each datagram, resulting in two extra be sent uncompressed with each datagram, resulting in two extra
octets of header. octets of header.
Zero Zero
This behavior, although not a legal implementation of IPv4 is
This behavior, although not a legal implementation of IPv4, is
sometimes seen in existing IPv4 stacks. When this behavior is sometimes seen in existing IPv4 stacks. When this behavior is
used, all IP packets have the IP-ID value set to zero. used, all IP packets have the IP-ID value set to zero.
Flags Flags
The Reserved flag must be set to zero and is therefore classified The Reserved flag must be set to zero and is therefore classified
as STATIC-KNOWN. The Don't Fragment (DF) flag will changes rarely as STATIC-KNOWN. The Don't Fragment (DF) flag changes rarely and
and is therefore classified as RACH. Finally, the More Fragments is therefore classified as RACH. Finally, the More Fragments (MF)
(MF) flag is expected to be zero because IP fragments will not be flag is expected to be zero because IP fragments will not be
compressed by ROHC and is therefore classified as STATIC-KNOWN. compressed by ROHC and is therefore classified as STATIC-KNOWN.
Fragment Offset Fragment Offset
Under the assumption that no fragmentation occurs, the fragment Under the assumption that no fragmentation occurs, the fragment
offset is always zero and is therefore classified as STATIC-KNOWN. offset is always zero and is therefore classified as STATIC-KNOWN.
Time To Live Time To Live
Time To Live field is expected to be constant during the lifetime
of a flow or to alternate between a limited number of values due The Time To Live field is expected to be constant during the
to route changes. lifetime of a flow or to alternate between a limited number of
values due to route changes.
Protocol Protocol
This field will have the same value in all packets of a flow and This field will have the same value in all packets of a flow and
is therefore classified as STATIC-DEF. is therefore classified as STATIC-DEF.
Header Checksum Header Checksum
The header checksum protects individual hops from processing a The header checksum protects individual hops from processing a
corrupted header. When almost all IP header information is corrupted header. When almost all IP header information is
compressed away, there is no point in having this additional compressed away, there is no point in having this additional
checksum; instead it can be regenerated at the decompressor side. checksum; instead, it can be regenerated at the decompressor side.
The field is therefore classified as INFERRED. The field is therefore classified as INFERRED.
Source and Destination addresses Source and Destination addresses
These fields are part of the definition of a flow and must thus be These fields are part of the definition of a flow and must thus be
constant for all packets in the flow. constant for all packets in the flow.
Appendix A.2. IPv6 Header Fields A.2. IPv6 Header Fields
+----------------------+----------------+ +----------------------+----------------+
| Field | Class | | Field | Class |
+----------------------+----------------+ +----------------------+----------------+
| Version | STATIC-KNOWN | | Version | STATIC-KNOWN |
| Traffic Class | RACH | | Traffic Class | RACH |
| Flow Label | STATIC-DEF | | Flow Label | STATIC-DEF |
| Payload Length | INFERRED | | Payload Length | INFERRED |
| Next Header | STATIC-DEF | | Next Header | STATIC-DEF |
| Hop Limit | RACH | | Hop Limit | RACH |
| Source Address | STATIC-DEF | | Source Address | STATIC-DEF |
| Destination Address | STATIC-DEF | | Destination Address | STATIC-DEF |
+----------------------+----------------+ +----------------------+----------------+
Version Version
The version field states which IP version is used, and is set to
The version field states which IP version is used and is set to
the value six. the value six.
Traffic Class Traffic Class
The Traffic Class field is expected to be constant during the
lifetime of a flow or to change relatively seldom. For the type of flows compressed by the ROHCv2 profiles, the DSCP
and ECN fields are expected to change relatively seldom.
Flow Label Flow Label
This field may be used to identify packets belonging to a specific This field may be used to identify packets belonging to a specific
flow. If not used, the value should be set to zero. Otherwise, flow. If it is not used, the value should be set to zero.
all packets belonging to the same flow must have the same value in Otherwise, all packets belonging to the same flow must have the
this field. The field is therefore classified as STATIC-DEF. same value in this field. The field is therefore classified as
STATIC-DEF.
Payload Length Payload Length
Information about packet length (and, consequently, payload Information about packet length (and, consequently, payload
length) is expected to be provided by the link layer. The field length) is expected to be provided by the link layer. The field
is therefore classified as INFERRED. is therefore classified as INFERRED.
Next Header Next Header
This field will have the same value in all packets of a flow and This field will have the same value in all packets of a flow and
is therefore classified as STATIC-DEF. is therefore classified as STATIC-DEF.
Hop Limit Hop Limit
The Hop Limit field is expected to be constant during the lifetime The Hop Limit field is expected to be constant during the lifetime
of a flow or to alternate between a limited number of values due of a flow or to alternate between a limited number of values due
to route changes. to route changes.
Source and Destination addresses Source and Destination addresses
These fields are part of the definition of a flow and must thus be These fields are part of the definition of a flow and must thus be
constant for all packets in the flow. The fields are therefore constant for all packets in the flow. The fields are therefore
classified as STATIC-DEF. classified as STATIC-DEF.
Appendix A.3. UDP Header Fields A.3. UDP Header Fields
+------------------+-------------+ +------------------+-------------+
| Field | Class | | Field | Class |
+------------------+-------------+ +------------------+-------------+
| Source Port | STATIC-DEF | | Source Port | STATIC-DEF |
| Destination Port | STATIC-DEF | | Destination Port | STATIC-DEF |
| Length | INFERRED | | Length | INFERRED |
| Checksum | | | Checksum | |
| Disabled | STATIC | | Disabled | STATIC |
| Enabled | IRREGULAR | | Enabled | IRREGULAR |
skipping to change at page 112, line 19 skipping to change at page 113, line 31
+------------------+-------------+ +------------------+-------------+
| Source Port | STATIC-DEF | | Source Port | STATIC-DEF |
| Destination Port | STATIC-DEF | | Destination Port | STATIC-DEF |
| Length | INFERRED | | Length | INFERRED |
| Checksum | | | Checksum | |
| Disabled | STATIC | | Disabled | STATIC |
| Enabled | IRREGULAR | | Enabled | IRREGULAR |
+------------------+-------------+ +------------------+-------------+
Source and Destination ports Source and Destination ports
These fields are part of the definition of a flow and must thus be These fields are part of the definition of a flow and must thus be
constant for all packets in the flow. constant for all packets in the flow.
Length Length
Information about packet length is expected to be provided by the Information about packet length is expected to be provided by the
link layer. The field is therefore classified as INFERRED. link layer. The field is therefore classified as INFERRED.
Checksum Checksum
The checksum can be optional. If disabled, its value is The checksum can be optional. If disabled, its value is
constantly zero and can be compressed away. If enabled, its value constantly zero and can be compressed away. If enabled, its value
depends on the payload, which for compression purposes is depends on the payload, which for compression purposes is
equivalent to it changing randomly with every packet. equivalent to it changing randomly with every packet.
Appendix A.4. UDP-Lite Header Fields A.4. UDP-Lite Header Fields
+--------------------+-------------+ +--------------------+-------------+
| Field | Class | | Field | Class |
+--------------------+-------------+ +--------------------+-------------+
| Source Port | STATIC-DEF | | Source Port | STATIC-DEF |
| Destination Port | STATIC-DEF | | Destination Port | STATIC-DEF |
| Checksum Coverage | | | Checksum Coverage | |
| Zero | STATIC-DEF | | Zero | STATIC-DEF |
| Constant | INFERRED | | Constant | INFERRED |
| Variable | IRREGULAR | | Variable | IRREGULAR |
skipping to change at page 112, line 47 skipping to change at page 114, line 20
| Source Port | STATIC-DEF | | Source Port | STATIC-DEF |
| Destination Port | STATIC-DEF | | Destination Port | STATIC-DEF |
| Checksum Coverage | | | Checksum Coverage | |
| Zero | STATIC-DEF | | Zero | STATIC-DEF |
| Constant | INFERRED | | Constant | INFERRED |
| Variable | IRREGULAR | | Variable | IRREGULAR |
| Checksum | IRREGULAR | | Checksum | IRREGULAR |
+--------------------+-------------+ +--------------------+-------------+
Source and Destination Port Source and Destination Port
These fields are part of the definition of a flow and must thus be These fields are part of the definition of a flow and must thus be
constant for all packets in the flow. constant for all packets in the flow.
Checksum Coverage Checksum Coverage
The Checksum Coverage field may behave in different ways: it may The Checksum Coverage field may behave in different ways: it may
have a value of zero, it may be equal to the datagram length, or have a value of zero, it may be equal to the datagram length, or
it may have any value between eight octets and the length of the it may have any value between eight octets and the length of the
datagram. From a compression perspective, this field is expected datagram. From a compression perspective, this field is expected
to either be entirely predictable (for the cases where it follows to either be entirely predictable (for the cases where it follows
the same behavior as the UDP Length field or where it takes on a the same behavior as the UDP Length field or where it takes on a
constant value) or either to change randomly for each packet constant value) or to change randomly for each packet (making the
(making the value unpredictable from a header-compression value unpredictable from a header-compression perspective). For
perspective). For all cases, the behavior itself is not expected all cases, the behavior itself is not expected to change for this
to change for this field during the lifetime of a packet flow, or field during the lifetime of a packet flow, or to change
to change relatively seldom. relatively seldom.
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 includes the UDP-Lite header. The checksum is a changing field
that must always be sent as-is. that must always be sent as-is.
Appendix A.5. RTP Header Fields A.5. RTP Header Fields
+----------------+----------------+ +----------------+----------------+
| Field | Class | | Field | Class |
+----------------+----------------+ +----------------+----------------+
| Version | STATIC-KNOWN | | Version | STATIC-KNOWN |
| Padding | RACH | | Padding | RACH |
| Extension | RACH | | Extension | RACH |
| CSRC Counter | RACH | | CSRC Counter | RACH |
| Marker | SEMISTATIC | | Marker | SEMISTATIC |
| Payload Type | RACH | | Payload Type | RACH |
skipping to change at page 113, line 40 skipping to change at page 115, line 23
| CSRC Counter | RACH | | CSRC Counter | RACH |
| Marker | SEMISTATIC | | Marker | SEMISTATIC |
| Payload Type | RACH | | Payload Type | RACH |
| Sequence Number| PATTERN | | Sequence Number| PATTERN |
| Timestamp | PATTERN | | Timestamp | PATTERN |
| SSRC | STATIC-DEF | | SSRC | STATIC-DEF |
| CSRC | RACH | | CSRC | RACH |
+----------------+----------------+ +----------------+----------------+
Version Version
This field is expected to have the value two and the field is This field is expected to have the value two and the field is
therefore classified as STATIC-KNOWN. therefore classified as STATIC-KNOWN.
Padding Padding
The use of this field is application-dependent, but when payload The use of this field is application-dependent, but when payload
padding is used it is likely to be present in most or all packets. padding is used, it is likely to be present in most or all
The field is classified as RACH to allow for the case where the packets. The field is classified as RACH to allow for the case
value of this field changes. where the value of this field changes.
Extension Extension
If RTP extensions are used by the application, these extensions If RTP extensions are used by the application, these extensions
are often present in all packets, although the use of extensions are often present in all packets, although the use of extensions
is infrequent. To allow efficient compression of a flow using is infrequent. To allow efficient compression of a flow using
extensions in only a few packets, this field is classified as extensions in only a few packets, this field is classified as
RACH. RACH.
CSRC Count CSRC Count
This field indicates the number of CSRC items present in the CSRC This field indicates the number of CSRC items present in the CSRC
list. This number is expected to be mostly constant on a packet- list. This number is expected to be mostly constant on a packet-
to-packet basis and when it changes, change by small amounts. As to-packet basis and when it changes, change by small amounts. As
long as no RTP mixer is used, the value of this field will be long as no RTP mixer is used, the value of this field will be
zero. zero.
Marker Marker
For audio, the marker bit should be set only in the first packet For audio, the marker bit should be set only in the first packet
of a talkspurt, while for video it should be set in the last of a talkspurt, while for video, it should be set in the last
packet of every picture. This means that in both cases the RTP packet of every picture. This means that in both cases the RTP
marker is classified as SEMISTATIC. marker is classified as SEMISTATIC.
Payload Type Payload Type
Applications could adapt to congestion by changing payload type Applications could adapt to congestion by changing payload type
and/or frame sizes, but that is not expected to happen frequently, and/or frame sizes, but that is not expected to happen frequently,
so this field is classified as RACH. so this field is classified as RACH.
RTP Sequence Number RTP Sequence Number
The RTP Sequence Number will be incremented by one for each packet The RTP Sequence Number will be incremented by one for each packet
sent. sent.
Timestamp Timestamp
In the audio case: In the audio case:
As long as there are no pauses in the audio stream, the RTP As long as there are no pauses in the audio stream, the RTP
Timestamp will be incremented by a constant value, Timestamp will be incremented by a constant value, which
corresponding to the number of samples in the speech frame. It corresponds to the number of samples in the speech frame. It
will thus mostly follow the RTP Sequence Number. When there will thus mostly follow the RTP Sequence Number. When there
has been a silent period and a new talkspurt begins, the has been a silent period and a new talkspurt begins, the
timestamp will jump in proportion to the length of the silent timestamp will jump in proportion to the length of the silent
period. However, the increment will probably be within a period. However, the increment will probably be within a
relatively limited range. relatively limited range.
In the video case: In the video case:
Between two consecutive packets, the timestamp will either be Between two consecutive packets, the timestamp will either be
unchanged or increase by a multiple of a fixed value unchanged or increase by a multiple of a fixed value
corresponding to the picture clock frequency. The timestamp corresponding to the picture clock frequency. The timestamp
can also decrease by a multiple of the fixed value for certain can also decrease by a multiple of the fixed value for certain
coding schemes. The change in timestamp value, expressed as a coding schemes. The change in timestamp value, expressed as a
multiple of the picture clock frequency, is in most cases multiple of the picture clock frequency, is in most cases
within a limited range. within a limited range.
SSRC SSRC
This field is part of the definition of a flow and must thus be This field is part of the definition of a flow and must thus be
constant for all packets in the flow. The field is therefore constant for all packets in the flow. The field is therefore
classified as STATIC-DEF. classified as STATIC-DEF.
Contributing Sources (CSRC) Contributing Sources (CSRC)
The participants in a session, who are identified by the CSRC The participants in a session, who are identified by the CSRC
fields, are usually expected to be unchanged on a packet-to-packet fields, are usually expected to be unchanged on a packet-to-packet
basis, but will infrequently change by a few additions and/or basis, but will infrequently change by a few additions and/or
removals. removals.
Appendix A.6. ESP Header Fields A.6. ESP Header Fields
+------------------+-------------+ +------------------+-------------+
| Field | Class | | Field | Class |
+------------------+-------------+ +------------------+-------------+
| SPI | STATIC-DEF | | SPI | STATIC-DEF |
| Sequence Number | PATTERN | | Sequence Number | PATTERN |
+------------------+-------------+ +------------------+-------------+
SPI SPI
This field is used to identify a specific flow and only changes
when the sequence number wraps around, and is therefore classified This field is used to identify a distinct flow between two IPsec
as STATIC-DEF. peers and it changes rarely; therefore, it is classified as
STATIC-DEF.
ESP Sequence Number ESP Sequence Number
The ESP Sequence Number will be incremented by one for each packet The ESP Sequence Number will be incremented by one for each packet
sent. sent.
Appendix A.7. IPv6 Extension Header Fields A.7. IPv6 Extension Header Fields
+-----------------------+---------------+ +-----------------------+---------------+
| Field | Class | | Field | Class |
+-----------------------+---------------+ +-----------------------+---------------+
| Next Header | STATIC-DEF | | Next Header | STATIC-DEF |
| Ext Hdr Len | | | Ext Hdr Len | |
| Routing | STATIC-DEF | | Routing | STATIC-DEF |
| Hop-by-hop | STATIC | | Hop-by-hop | STATIC |
| Destination | STATIC | | Destination | STATIC |
| Options | | | Options | |
skipping to change at page 116, line 4 skipping to change at page 117, line 49
| Routing | STATIC-DEF | | Routing | STATIC-DEF |
| Hop-by-hop | STATIC | | Hop-by-hop | STATIC |
| Destination | STATIC | | Destination | STATIC |
| Options | | | Options | |
| Routing | STATIC-DEF | | Routing | STATIC-DEF |
| Hop-by-hop | RACH | | Hop-by-hop | RACH |
| Destination | RACH | | Destination | RACH |
+-----------------------+---------------+ +-----------------------+---------------+
Next Header Next Header
This field will have the same value in all packets of a flow and This field will have the same value in all packets of a flow and
is therefore classified as STATIC-DEF. is therefore classified as STATIC-DEF.
Ext Hdr Len Ext Hdr Len
For the Routing header, it is expected that the length remains
constant for the duration of the flow, and a change in the length For the Routing header, it is expected that the length will remain
should be classified as a new flow by the ROHC compressor. For constant for the duration of the flow, and that a change in the
Hop-by-hop and Destination options headers, the length is expected length should be classified as a new flow by the ROHC compressor.
to remain static, but can be updated by an IR packet. For Hop-by-hop and Destination options headers, the length is
expected to remain static, but can be updated by an IR packet.
Options Options
For the Routing header, it is expected that the option content For the Routing header, it is expected that the option content
remains constant for the duration of the flow, and a change in the will remain constant for the duration of the flow, and that a
routing information should be classified as a new flow by the ROHC change in the routing information should be classified as a new
compressor. For Hop-by-hop and Destination options headers, the flow by the ROHC compressor. For Hop-by-hop and Destination
options are expected to remain static, but can be updated by an IR options headers, the options are expected to remain static, but
packet. can be updated by an IR packet.
Appendix A.8. GRE Header Fields A.8. GRE Header Fields
+--------------------+---------------+ +--------------------+---------------+
| Field | Class | | Field | Class |
+--------------------+---------------+ +--------------------+---------------+
| C flag | STATIC | | C flag | STATIC |
| K flag | STATIC | | K flag | STATIC |
| S flag | STATIC | | S flag | STATIC |
| R flag | STATIC-KNOWN | | R flag | STATIC-KNOWN |
| Reserved0, Version | STATIC-KNOWN | | Reserved0, Version | STATIC-KNOWN |
| Protocol | STATIC-DEF | | Protocol | STATIC-DEF |
skipping to change at page 116, line 40 skipping to change at page 118, line 40
| R flag | STATIC-KNOWN | | R flag | STATIC-KNOWN |
| Reserved0, Version | STATIC-KNOWN | | Reserved0, Version | STATIC-KNOWN |
| Protocol | STATIC-DEF | | Protocol | STATIC-DEF |
| Checksum | IRREGULAR | | Checksum | IRREGULAR |
| Reserved | STATIC-KNOWN | | Reserved | STATIC-KNOWN |
| Sequence Number | PATTERN | | Sequence Number | PATTERN |
| Key | STATIC-DEF | | Key | STATIC-DEF |
+--------------------+---------------+ +--------------------+---------------+
Flags Flags
The four flag bits are not expected to change for the duration of The four flag bits are not expected to change for the duration of
the flow, and the R flag is expected to always be set to zero. the flow, and the R flag is expected to always be set to zero.
Reserved0, Version Reserved0, Version
Both these fields are expected to be set to zero for the duration
of any flow. Both of these fields are expected to be set to zero for the
duration of any flow.
Protocol Protocol
This field will have the same value in all packets of a flow and This field will have the same value in all packets of a flow and
is therefore classified as STATIC-DEF. is therefore classified as STATIC-DEF.
Checksum Checksum
When the checksum field is present, it is expected to behave When the checksum field is present, it is expected to behave
unpredictably. unpredictably.
Reserved Reserved
When present, this field is expected to be set to zero. When present, this field is expected to be set to zero.
Sequence Number Sequence Number
When present, the Sequence Number increases by one for each When present, the Sequence Number increases by one for each
packet. packet.
Key Key
When present, the Key field is used to define the flow and does When present, the Key field is used to define the flow and does
not change. not change.
Appendix A.9. MINE Header Fields A.9. MINE Header Fields
+---------------------+----------------+ +---------------------+----------------+
| Field | Class | | Field | Class |
+---------------------+----------------+ +---------------------+----------------+
| Protocol | STATIC-DEF | | Protocol | STATIC-DEF |
| S bit | STATIC-DEF | | S bit | STATIC-DEF |
| Reserved | STATIC-KNOWN | | Reserved | STATIC-KNOWN |
| Checksum | INFERRED | | Checksum | INFERRED |
| Source Address | STATIC-DEF | | Source Address | STATIC-DEF |
| Destination Address | STATIC-DEF | | Destination Address | STATIC-DEF |
skipping to change at page 117, line 36 skipping to change at page 119, line 38
+---------------------+----------------+ +---------------------+----------------+
| Protocol | STATIC-DEF | | Protocol | STATIC-DEF |
| S bit | STATIC-DEF | | S bit | STATIC-DEF |
| Reserved | STATIC-KNOWN | | Reserved | STATIC-KNOWN |
| Checksum | INFERRED | | Checksum | INFERRED |
| Source Address | STATIC-DEF | | Source Address | STATIC-DEF |
| Destination Address | STATIC-DEF | | Destination Address | STATIC-DEF |
+---------------------+----------------+ +---------------------+----------------+
Protocol Protocol
This field will have the same value in all packets of a flow and This field will have the same value in all packets of a flow and
is therefore classified as STATIC-DEF. is therefore classified as STATIC-DEF.
S bit S bit
The S bit is not expected to change during a flow. The S bit is not expected to change during a flow.
Reserved Reserved
The reserved field is expected to be set to zero. The reserved field is expected to be set to zero.
Checksum Checksum
The header checksum protects individual routing hops from The header checksum protects individual routing hops from
processing a corrupted header. Since all fields of this header processing a corrupted header. Since all fields of this header
are compressed away, there is no need to include this checksum in are compressed away, there is no need to include this checksum in
compressed packets and it can be regenerated at the decompressor compressed packets and it can be regenerated at the decompressor
side. side.
Source and Destination Addresses Source and Destination Addresses
These fields can be used to define the flow and are not expected These fields can be used to define the flow and are not expected
to change. to change.
Appendix A.10. AH Header Fields A.10. AH Header Fields
+---------------------+----------------+ +---------------------+----------------+
| Field | Class | | Field | Class |
+---------------------+----------------+ +---------------------+----------------+
| Next Header | STATIC-DEF | | Next Header | STATIC-DEF |
| Payload Length | STATIC | | Payload Length | STATIC |
| Reserved | STATIC-KNOWN | | Reserved | STATIC-KNOWN |
| SPI | STATIC-DEF | | SPI | STATIC-DEF |
| Sequence Number | PATTERN | | Sequence Number | PATTERN |
| ICV | IRREGULAR | | ICV | IRREGULAR |
skipping to change at page 119, line 6 skipping to change at page 121, line 23
classified as IRREGULAR. classified as IRREGULAR.
Appendix B. Compressor Implementation Guidelines Appendix B. Compressor Implementation Guidelines
This section describes some guiding principles for implementing a This section describes some guiding principles for implementing a
ROHCv2 compressor with focus on how to efficiently select appropriate ROHCv2 compressor with focus on how to efficiently select appropriate
packet formats. The text in this appendix should be considered packet formats. The text in this appendix should be considered
guidelines; it does not define any normative requirement on how guidelines; it does not define any normative requirement on how
ROHCv2 profiles are implemented. ROHCv2 profiles are implemented.
Appendix B.1. Reference Management B.1. Reference Management
The compressor usually maintains a sliding window of reference The compressor usually maintains a sliding window of reference
headers which contains as many references as needed for the headers, which contains as many references as needed for the
optimistic approach. Each reference contains a description of which optimistic approach. Each reference contains a description of which
changes occurred in the flow between two consecutive headers in the changes occurred in the flow between two consecutive headers in the
flow, and a new reference is inserted into the window each time a flow, and a new reference is inserted into the window each time a
packet is compressed by this context. A reference may for example be packet is compressed by this context. A reference may for example be
implemented as a stored copy of the uncompressed header being implemented as a stored copy of the uncompressed header being
represented. When the compressor is confident that a specific represented. When the compressor is confident that a specific
reference is no longer used by the decompressor (for example by using reference is no longer used by the decompressor (for example by using
the optimistic approach or feedback received), the reference is the optimistic approach or feedback received), the reference is
removed from the sliding window. removed from the sliding window.
Appendix B.2. Window-based LSB Encoding (W-LSB) B.2. Window-based LSB Encoding (W-LSB)
Section 5.1.1 describes how the optimistic approach impacts the Section 5.1.1 describes how the optimistic approach impacts the
packet format selection for the compressor. Exactly how the packet format selection for the compressor. Exactly how the
compressor selects a packet format is up to the implementation to compressor selects a packet format is up to the implementation to
decide, but the following is an example of how this process can be decide, but the following is an example of how this process can be
performed for lsb-encoded fields, through the use of Window-based LSB performed for lsb-encoded fields through the use of Window-based LSB
encoding (W-LSB). encoding (W-LSB).
With W-LSB encoding, the compressor uses a number of references (a With W-LSB encoding, the compressor uses a number of references (a
window) from its context. What references to use is determined by window) from its context. What references to use is determined by
its optimistic approach. The compressor extracts the value of the its optimistic approach. The compressor extracts the value of the
field to be W-LSB encoded from each reference in the window, and field to be W-LSB encoded from each reference in the window, and
finds the maximum and minimum values. Once it determines these finds the maximum and minimum values. Once it determines these
values, the compressor uses the assumption that the decompressor has values, the compressor uses the assumption that the decompressor has
a value for this field within the range given by these boundaries a value for this field within the range given by these boundaries
(inclusively) as its reference. The compressor can then select a (inclusively) as its reference. The compressor can then select a
number of LSBs from the value to be compressed, so that the LSBs can number of LSBs from the value to be compressed, so that the LSBs can
be decompressed no matter if the decompressor uses the minimum value, be decompressed regardless of whether the decompressor uses the
the maximum value or any other value in the range of possible minimum value, the maximum value or any other value in the range of
references. possible references.
Appendix B.3. W-LSB Encoding and Timer-based Compression B.3. W-LSB Encoding and Timer-based Compression
Section 6.6.9 defines decompressor behavior for timer-based RTP Section 6.6.9 defines decompressor behavior for timer-based RTP
timestamp compression. This section gives guidelines on how the timestamp compression. This section gives guidelines on how the
compressor should determine the number of LSB bits it should send for compressor should determine the number of LSB bits it should send for
the timestamp field. When using timer-based compression, this number the timestamp field. When using timer-based compression, this number
depends on the sum of the jitter before the compressor and the jitter depends on the sum of the jitter before the compressor and the jitter
between compressor and decompressor. between the compressor and decompressor.
The jitter before the compressor can be estimated using the following The jitter before the compressor can be estimated using the following
computation: computation:
Max_Jitter_BC = Max_Jitter_BC =
max {|(T_n - T_j) - ((a_n - a_j) / time_stride)|, max {|(T_n - T_j) - ((a_n - a_j) / time_stride)|,
for all headers j in the sliding window} for all headers j in the sliding window}
Where (T_n - T_j) is the difference in timestamp between the where (T_n - T_j) is the difference in the timestamp between the
currently compressed header and a reference header and (a_n - a_j) is currently compressed header and a reference header and (a_n - a_j) is
the difference in arrival time between those same two headers. the difference in arrival time between those same two headers.
In addition to this, the compressor needs to estimate an upper bound In addition to this, the compressor needs to estimate an upper bound
for the jitter between compressor and decompressor (Max_Jitter_CD). for the jitter between the compressor and decompressor
This information may for example come from lower layers. (Max_Jitter_CD). This information may for example come from lower
layers.
A compressor implementation can determine whether the difference in A compressor implementation can determine whether the difference in
clock resolution between compressor and decompressor induces an error clock resolution between the compressor and decompressor induces an
when performing integer arithmetics; it can then treat this error as error when performing integer arithmetics; it can then treat this
additional jitter. error as additional jitter.
After obtaining estimates for the jitters, the number of bits needed After obtaining estimates for the jitters, the number of bits needed
to transmit is obtained using the following calculation: to transmit is obtained using the following calculation:
ceiling(log2(2 * (Max_Jitter_BC + Max_Jitter_CD + 2) + 1)) ceiling(log2(2 * (Max_Jitter_BC + Max_Jitter_CD + 2) + 1))
This number is then used to select a packet format which contains at This number is then used to select a packet format that contains at
least this many scaled timestamp bits. least this many scaled timestamp bits.
Authors' Addresses Authors' Addresses
Ghyslain Pelletier Ghyslain Pelletier
Ericsson Ericsson
Box 920 Box 920
Lulea SE-971 28 Lulea SE-971 28
Sweden Sweden
Phone: +46 (0) 8 404 29 43 Phone: +46 (0) 8 404 29 43
Email: ghyslain.pelletier@ericsson.com EMail: ghyslain.pelletier@ericsson.com
Kristofer Sandlund Kristofer Sandlund
Ericsson Ericsson
Box 920 Box 920
Lulea SE-971 28 Lulea SE-971 28
Sweden Sweden
Phone: +46 (0) 8 404 41 58 Phone: +46 (0) 8 404 41 58
Email: kristofer.sandlund@ericsson.com EMail: kristofer.sandlund@ericsson.com
Full Copyright Statement Full Copyright Statement
Copyright (C) The IETF Trust (2008). Copyright (C) The IETF Trust (2008).
This document is subject to the rights, licenses and restrictions This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors contained in BCP 78, and except as set forth therein, the authors
retain all their rights. retain all their rights.
This document and the information contained herein are provided on an This document and the information contained herein are provided on an
skipping to change at page 122, line 44 skipping to change at line 5730
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 this standard. Please address the information to the IETF at
ietf-ipr@ietf.org. ietf-ipr@ietf.org.
Acknowledgment
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
 End of changes. 268 change blocks. 
453 lines changed or deleted 521 lines changed or added

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