draft-ietf-rohc-rfc3095bis-rohcv2-profiles-05.txt   draft-ietf-rohc-rfc3095bis-rohcv2-profiles-06.txt 
Robust Header Compression G. Pelletier Robust Header Compression G. Pelletier
Internet-Draft K. Sandlund Internet-Draft K. Sandlund
Intended status: Standards Track Ericsson Intended status: Standards Track Ericsson
Expires: August 1, 2008 January 29, 2008 Expires: September 20, 2008 March 19, 2008
RObust Header Compression Version 2 (ROHCv2): Profiles for RTP, UDP, IP, RObust Header Compression Version 2 (ROHCv2): Profiles for RTP, UDP, IP,
ESP and UDP Lite ESP and UDP Lite
draft-ietf-rohc-rfc3095bis-rohcv2-profiles-05 draft-ietf-rohc-rfc3095bis-rohcv2-profiles-06
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware 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 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. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 35 skipping to change at page 1, line 35
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on August 1, 2008. This Internet-Draft will expire on September 20, 2008.
Copyright Notice Copyright Notice
Copyright (C) The IETF Trust (2008). Copyright (C) The IETF Trust (2008).
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
skipping to change at page 2, line 21 skipping to change at page 2, line 21
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 its 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 . . . . . . . . . . . . . . . . . . . . . . . . . . 6
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 . . . . . . . . . . . . . 19
6.3. Control Fields . . . . . . . . . . . . . . . . . . . . . 20 6.3. Control Fields . . . . . . . . . . . . . . . . . . . . . 20
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 . . . . . . . . . . . . . . 22
6.4. Reconstruction and Verification . . . . . . . . . . . . . 23 6.4. Reconstruction and Verification . . . . . . . . . . . . . 23
6.5. Compressed Header Chains . . . . . . . . . . . . . . . . 23 6.5. Compressed Header Chains . . . . . . . . . . . . . . . . 23
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 . . . . . . . . . . . . 25
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
skipping to change at page 3, line 22 skipping to change at page 3, line 22
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) . . . . . . . . . . . . . . . . . 33
6.7. Encoding Methods With External Parameters as Arguments . 37 6.7. Encoding Methods With External Parameters as Arguments . 37
6.8. Header Formats . . . . . . . . . . . . . . . . . . . . . 39 6.8. Header Formats . . . . . . . . . . . . . . . . . . . . . 39
6.8.1. Initialization and Refresh Header Format (IR) . . . . 39 6.8.1. Initialization and Refresh Header Format (IR) . . . . 39
6.8.2. Compressed Header Formats (CO) . . . . . . . . . . . 40 6.8.2. Compressed Header Formats (CO) . . . . . . . . . . . 40
6.9. Feedback Formats and Options . . . . . . . . . . . . . . 99 6.9. Feedback Formats and Options . . . . . . . . . . . . . . 99
6.9.1. Feedback Formats . . . . . . . . . . . . . . . . . . 99 6.9.1. Feedback Formats . . . . . . . . . . . . . . . . . . 99
6.9.2. Feedback Options . . . . . . . . . . . . . . . . . . 101 6.9.2. Feedback Options . . . . . . . . . . . . . . . . . . 101
7. Security Considerations . . . . . . . . . . . . . . . . . . . 103 7. Security Considerations . . . . . . . . . . . . . . . . . . . 103
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 103 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 104
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 104 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 105
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 105 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 106
10.1. Normative References . . . . . . . . . . . . . . . . . . 105 10.1. Normative References . . . . . . . . . . . . . . . . . . 106
10.2. Informative References . . . . . . . . . . . . . . . . . 106 10.2. Informative References . . . . . . . . . . . . . . . . . 107
Appendix A. Detailed classification of header fields . . . . . 106 Appendix A. Detailed Classification of Header Fields . . . . . 107
Appendix A.1. IPv4 Header Fields . . . . . . . . . . . . . . . . 107 Appendix A.1. IPv4 Header Fields . . . . . . . . . . . . . . . . 108
Appendix A.2. IPv6 Header Fields . . . . . . . . . . . . . . . . 109 Appendix A.2. IPv6 Header Fields . . . . . . . . . . . . . . . . 110
Appendix A.3. UDP Header Fields . . . . . . . . . . . . . . . . 111 Appendix A.3. UDP Header Fields . . . . . . . . . . . . . . . . 112
Appendix A.4. UDP-Lite Header Fields . . . . . . . . . . . . . . 111 Appendix A.4. UDP-Lite Header Fields . . . . . . . . . . . . . . 112
Appendix A.5. RTP Header Fields . . . . . . . . . . . . . . . . 112 Appendix A.5. RTP Header Fields . . . . . . . . . . . . . . . . 113
Appendix A.6. ESP Header Fields . . . . . . . . . . . . . . . . 114 Appendix A.6. ESP Header Fields . . . . . . . . . . . . . . . . 115
Appendix A.7. IPv6 Extension Header Fields . . . . . . . . . . . 114 Appendix A.7. IPv6 Extension Header Fields . . . . . . . . . . . 115
Appendix A.8. GRE Header Fields . . . . . . . . . . . . . . . . 115 Appendix A.8. GRE Header Fields . . . . . . . . . . . . . . . . 116
Appendix A.9. MINE Header Fields . . . . . . . . . . . . . . . . 116 Appendix A.9. MINE Header Fields . . . . . . . . . . . . . . . . 117
Appendix A.10. AH Header Fields . . . . . . . . . . . . . . . . . 117 Appendix A.10. AH Header Fields . . . . . . . . . . . . . . . . . 118
Appendix B. Compressor Implementation Guidelines . . . . . . . 117 Appendix B. Compressor Implementation Guidelines . . . . . . . 118
Appendix B.1. Reference Management . . . . . . . . . . . . . . . 118 Appendix B.1. Reference Management . . . . . . . . . . . . . . . 119
Appendix B.2. Window-based LSB Encoding (W-LSB) . . . . . . . . 118 Appendix B.2. Window-based LSB Encoding (W-LSB) . . . . . . . . 119
Appendix B.3. W-LSB Encoding and Timer-based Compression . . . . 118 Appendix B.3. W-LSB Encoding and Timer-based Compression . . . . 119
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 119 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 120
Intellectual Property and Copyright Statements . . . . . . . . . 121 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]
skipping to change at page 5, line 16 skipping to change at page 5, line 16
The value of this field normally corresponds to the Master The value of this field normally corresponds to the Master
Sequence Number (MSN) of the header that was last successfully Sequence Number (MSN) of the header that was last successfully
decompressed, for the compression context (CID) for which the decompressed, for the compression context (CID) for which the
feedback information applies. feedback information applies.
Chaining of Items Chaining of Items
A chain of items groups fields based on similar characteristics. A chain of items groups fields based on similar characteristics.
ROHCv2 defines chain items for static, dynamic and irregular ROHCv2 defines chain items for static, dynamic and irregular
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 their 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 CO header that contains a 3-bit
CRC calculated over control fields. This 3-bit CRC covers CRC calculated over control fields. This 3-bit CRC covers
controls fields carried in the CO header as well as specific controls fields carried in the CO header as well as specific
control fields in the context. In the formal definition of the control fields in the context. In the formal definition of the
header formats, this 3-bit CRC is labelled "control_crc3" and uses header formats, this 3-bit CRC is labeled "control_crc3" and uses
the "control_crc3_encoding" (See also Section 6.6.11). 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
its sequence due to reordering between the compressor and the its sequence due to reordering between the compressor and the
decompressor, i.e. reordering between packets associated with the decompressor, i.e., reordering between packets associated with the
same context (CID). See definition of sequentially late packet same context (CID). See the definition of sequentially late
below. packet below.
ROHCv2 Header Types ROHCv2 Header Types
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 (CO) header type. and Refresh (IR) header type, and the Compressed (CO) header type.
Sequentially Early Packet Sequentially Early Packet
A packet that reaches the decompressor before one or several A packet that reaches the decompressor before one or several
packets that were delayed over the channel, whereas all of the packets that were delayed over the channel, where all of the said
said packets belong to the same header-compressed flow and are packets belong to the same header-compressed flow and are
associated to the same compression context (CID). At the time of associated to the same compression context (CID). At the time of
the arrival of a sequentially early packet, the packet(s) delayed the arrival of a sequentially early packet, the packet(s) delayed
on the link cannot be differentiated from lost packet(s). on the link cannot be differentiated from lost packet(s).
Sequentially Late Packet Sequentially Late Packet
A packet is late within its sequence if it reaches the A packet is late within its sequence if it reaches the
decompressor after one or several other packets belonging to the decompressor after one or several other packets belonging to the
same CID have been received, although the sequentially late packet same CID have been received, although the sequentially late packet
was sent from the compressor before the other packet(s). How the was sent from the compressor before the other packet(s). How the
decompressor detects a sequentially late packet is outside the decompressor detects a sequentially late packet is outside the
scope of this specification, but it can for example use the MSN to scope of this specification, but it can for example use the MSN
this purpose. for this purpose.
Timestamp Stride (ts_stride) Timestamp Stride (ts_stride)
The timestamp stride (ts_stride) is the expected increase in the The timestamp stride (ts_stride) is the expected increase in the
timestamp value between two RTP packets with consecutive sequence timestamp value between two RTP packets with consecutive sequence
numbers. For example, for a media encoding with a sample rate of numbers. For example, for a media encoding with a sample rate of
8 kHz producing one frame every 20ms, the RTP timestamp will 8 kHz producing one frame every 20ms, the RTP timestamp will
typically increase by n * 160 (= 8000 * 0.02), for some integer n. typically increase by n * 160 (= 8000 * 0.02), for some integer n.
Time Stride (time_stride) Time Stride (time_stride)
skipping to change at page 7, line 39 skipping to change at page 7, line 39
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 section
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, but especially between the headers of within the headers of a packet, especially between the headers of
consecutive packets. consecutive packets.
Appendix A lists and classifies in detail all the header fields Appendix A lists and classifies in detail all the header fields
relevant to this document. The appendix concludes with relevant to this document. The appendix concludes with
recommendations on how the various fields should be handled by header recommendations on how the various fields should be handled by header
compression algorithms. compression algorithms.
The main conclusion is that most of the header fields can easily be The main conclusion is that most of the header fields can easily be
compressed away since they never or seldom change. A small number of compressed away since they never or seldom change. A small number of
fields however need more sophisticated mechanisms. fields however need more sophisticated mechanisms.
skipping to change at page 8, line 33 skipping to change at page 8, line 33
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 the one of the RTP TS to the RTP
SN is often observed between the Identifier field (IP-ID) and the SN is often observed between the Identifier field (IP-ID) and the
master sequence number used for compression (e.g. the RTP SN when master sequence number 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.
There are a number of differences and improvements between profiles There are a number of differences and improvements between profiles
defined in this document and their earlier version defined in RFC defined in this document and their earlier version defined in RFC
3095. This section provides an overview of some of the most 3095. This section provides an overview of some of the most
significant improvements: significant improvements:
Tolerance to reordering Tolerance to reordering
Profiles defined in RFC 3095 require that the channel between Profiles defined in RFC 3095 require that the channel between
compressor and decompressor provide in-order delivery between compressor and decompressor provide in-order delivery between
skipping to change at page 9, line 25 skipping to change at page 9, line 25
different updating logic and compressed header formats. ROHCv2 different updating logic and compressed header formats. ROHCv2
profiles operate in unidirectional operation until feedback is profiles operate in unidirectional operation until feedback is
first received for a context (CID), at which point bidirectional first received for a context (CID), at which point bidirectional
operation is used; the formats are independent of what operational operation is used; the formats are independent of what operational
logic is used. logic is used.
IP extension header IP extension header
Profiles in RFC 3095 compress IP Extension headers using list Profiles in RFC 3095 compress IP Extension headers using list
compression. ROHCv2 profiles instead treat extension headers in compression. ROHCv2 profiles instead treat extension headers in
the same manner as other protocol headers, i.e. using the chaining the same manner as other protocol headers, i.e., using the
mechanism; it thus assumes that extension header are not added or chaining mechanism; it thus assumes that extension headers are not
removed during the lifetime of a context (CID), otherwise added or removed during the lifetime of a context (CID), otherwise
compression has to be restarted for this flow. compression has to be restarted for this flow.
IP encapsulation IP encapsulation
Profiles in RFC 3095 can compress at most two levels of IP Profiles in RFC 3095 can compress at most two levels of IP
headers. ROHCv2 profiles can compress an arbitrary number of IP headers. ROHCv2 profiles can compress an arbitrary number of IP
headers. headers.
List compression List compression
skipping to change at page 10, line 25 skipping to change at page 10, line 25
Packet length Packet length
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 to be successfully
decompressed. 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.
5. Overview of the ROHCv2 Profiles (Informative) 5. Overview of the ROHCv2 Profiles (Informative)
This section provides an overview of concepts that are important and This section provides an overview of concepts that are important and
useful to the ROHCv2 profiles. These concepts may be used as useful to the ROHCv2 profiles. These concepts may be used as
guidelines for implementations but they are not part of the normative guidelines for implementations but they are not part of the normative
definition of the profiles, as these concepts relates to the definition of the profiles, as these concepts relate to the
compression efficiency of the protocol without impacting the compression efficiency of the protocol without impacting the
interoperability characteristics of an implementation. interoperability characteristics of an implementation.
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.
skipping to change at page 11, line 42 skipping to change at page 11, line 42
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 and is left open to
implementations. implementations.
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:
The interpretation interval offset specifies an upper limit for The interpretation interval offset specifies an upper limit for
the maximum reordering depth, by which is it possible for the the maximum reordering depth, by which is it possible for the
decompressor to recover the original value of a dynamically decompressor to recover the original value of a dynamically
changing (i.e. sequentially incrementing) field that is encoded changing (i.e., sequentially incrementing) field that is encoded
using a window-based lsb encoding. Its value is typically bound using a window-based lsb encoding. Its value is typically bound
to the number of lsb compressed bits in the compressed header to the number of lsb compressed bits in the compressed header
format, and thus grows with the number of bits transmitted. format, and thus grows with the number of bits transmitted.
However, the offset and the lsb encoding only provide robustness However, the offset and the lsb encoding only provide robustness
for the field that it compresses, and (implicitly) for other for the field that it compresses, and (implicitly) for other
sequentially changing fields that are derived from that field. sequentially changing fields that are derived from that field.
This is shown in the figure below: This is shown in the figure below:
<--- interpretation interval (size is 2^k) ----> <--- interpretation interval (size is 2^k) ---->
skipping to change at page 13, line 28 skipping to change at page 13, line 28
the new flow, and sends Initialization and Refresh (IR) packets. the new flow, and sends Initialization and Refresh (IR) packets.
Initially, when sending the first IR packet for a compressed flow, Initially, when sending the first IR packet for a compressed flow,
the compressor does not expect to receive feedback for that flow, the compressor does not expect to receive feedback for that flow,
until such feedback is first received. At this point, the compressor until such feedback is first received. At this point, the compressor
may then assume that the decompressor will continue to send feedback may then assume that the decompressor will continue to send feedback
in order to repair its context when necessary. The former is in order to repair its context when necessary. The former is
referred to as unidirectional operation, while the latter is called referred to as unidirectional operation, while the latter is called
bidirectional operation. bidirectional operation.
The compressor can then adjust the compression level (i.e. what The compressor can then adjust the compression level (i.e., what
header format it selects) based on its confidence that the header format it selects) based on its confidence that the
decompressor has the necessary information to successfully process decompressor has the necessary information to successfully process
the compressed headers that it selects. the compressed headers that it selects.
In other words, the responsibilities of the compressor are to ensure In other words, the responsibilities of the compressor are to ensure
that the decompressor operates with state information that is that the decompressor operates with state information that is
sufficient to successfully decompress the type of compressed sufficient to successfully decompress the type of compressed
header(s) it receives, and to allow the decompressor to successfully header(s) it receives, and to allow the decompressor to successfully
recover that state information as soon as possible otherwise. The recover that state information as soon as possible otherwise. The
compressor therefore selects the type of compressed header based on compressor therefore selects the type of compressed header based on
skipping to change at page 14, line 16 skipping to change at page 14, line 16
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 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 to determine what is the most suitable response to a responsible for determining what is the most suitable response to a
negative acknowledgement, using the confidence it has in the state of negative acknowledgement, using the confidence it has in the state of
the decompressor context, when selecting the type of compressed the decompressor context, when selecting the type of compressed
header it will use when compressing a header. header it 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 to always verify the outcome of the 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.
skipping to change at page 16, line 16 skipping to change at page 16, line 16
Context Damage Detected: See definition in Section 5.2.2. Context Damage Detected: See definition in Section 5.2.2.
5.2.1.1. No Context (NC) State 5.2.1.1. No Context (NC) State
Initially, while working in the No Context (NC) state, the Initially, while working in the No Context (NC) state, the
decompressor has not yet successfully validated an IR header. decompressor has not yet successfully validated an IR header.
Attempting decompression: Attempting decompression:
In the NC state, only packets carrying sufficient information on In the NC state, only packets carrying sufficient information on
the static fields (i.e. IR packets) can be decompressed. the static fields (i.e., IR packets) 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 validation of an 8-bit CRC in an IR header is successful. CRC validation of an 8-bit CRC in an IR header is successful.
Feedback logic: Feedback logic:
In the NC state, the decompressor should send a STATIC-NACK if a In the NC state, the decompressor should send a STATIC-NACK if a
packet of a type other than IR is received, or if an IR header has packet of a type other than IR is received, or if an IR header has
skipping to change at page 18, line 11 skipping to change at page 18, line 11
The decompressor may assume that some or the entire context is The decompressor may assume that some or the entire context is
invalid, when it fails to validate or to verify one or more headers invalid, when it fails to validate or to verify one or more headers
using the CRC. Because the decompressor cannot know the exact using the CRC. Because the decompressor cannot know the exact
reason(s) for a CRC failure or what field caused it, the validity of reason(s) for a CRC failure or what field caused it, the validity of
the context hence does not refer to what specific part(s) of the the context hence does not refer to what specific part(s) of the
context is deemed valid or not. context is deemed valid or not.
Validity of the context rather relates to the detection of a problem Validity of the context rather relates to the detection of a problem
with the context. The decompressor first assumes that the type of with the context. The decompressor first assumes that the type of
information that most likely caused the failure(s) is the state that information that most likely caused the failure(s) is the state that
normally changes for each packet, i.e. context damage of the dynamic normally changes for each packet, i.e., context damage of the dynamic
part of the context. Upon repeated decompression failures and part of the context. Upon repeated decompression failures and
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. static context, including the static part, needs to be repaired, i.e.,
context damage. Failure to validate the 3-bit CRC that protects static context damage. Failure to validate the 3-bit CRC that
control fields should be treated as a decompression failure when the protects control fields should be treated as a decompression failure
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 if 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 to
the context management of the decompressor, i.e. to the the context management of the decompressor, i.e. to 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
skipping to change at page 19, line 42 skipping to change at page 19, line 42
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 to 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 [RFC4995] section
5.2.5), i.e. MRRU MUST be set to 0, if the configuration of the ROHC 5.2.5), i.e., MRRU MUST be set to 0, if the configuration of the ROHC
channel contains at least one ROHCv2 profile in the list of supported channel contains at least one ROHCv2 profile in the list of supported
profiles (i.e. the PROFILES parameter) and if the channel cannot profiles (i.e., the PROFILES parameter) and if the channel cannot
guarantee in-order delivery of packets between compression endpoints. 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 new [RFC4995]), i.e., there is no established feedback channel for the
context. At this point, despite the use of the optimistic approach, new context. At this point, despite the use of the optimistic
decompression failure is still possible because the decompressor may approach, decompression failure is still possible because the
not have received sufficient information to correctly decompress the decompressor may not have received sufficient information to
packets; therefore, until the decompressor has established a feedback correctly decompress the packets; therefore, until the decompressor
channel, the compressor SHOULD periodically send IR packets. The has established a feedback channel, the compressor SHOULD
periodicity can be based on timeouts, on the number of compressed periodically send IR packets. The periodicity can be based on
packets sent for the flow, or any other strategy the implementer timeouts, on the number of compressed packets sent for the flow, or
chooses. any other strategy the implementer 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 estimate the current state of the decompressor. This helps to
increasing 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) establishes
this channel. Once it has established a feedback channel for a CID, this channel. Once it has established a feedback channel for a CID,
the decompressor is REQUIRED to continue sending feedback for the the decompressor is REQUIRED to continue sending feedback for the
lifetime of the context (i.e. until it receives an IR packet that lifetime of the context (i.e., until it receives an IR packet that
associates the CID to a different profile), to send error recovery associates the CID to a different profile), to send error recovery
requests and (optionally) acknowledgments of significant context requests and (optionally) acknowledgments of significant context
updates. 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 from the lack of
feedback to trigger error recovery; there will also be a slightly feedback to trigger error recovery; there will also be a slightly
higher probability of loss propagation compared to the case where the higher probability of loss propagation compared to the case where the
decompressor uses feedback. decompressor uses feedback.
skipping to change at page 21, line 12 skipping to change at page 21, line 12
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.
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 (CID).
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 always There is one MSN field in every ROHCv2 header, i.e., the MSN is
present in each header type sent by the compressor. The MSN is sent always present in each header type sent by the compressor. The MSN
in full in IR headers, while it can be lsb encoded within CO header is sent in full in IR headers, while it can be lsb encoded within CO
formats. The decompressor always includes LSBs of the MSN in the header formats. The decompressor always includes LSBs of the MSN in
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;
skipping to change at page 22, line 5 skipping to change at page 22, line 5
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
lsb encoding method with respect to reordering and consecutive lsb encoding method with respect to reordering and consecutive
losses, as described in Section 5.1.2. losses, as described in Section 5.1.2.
6.3.3. IP-ID behavior 6.3.3. IP-ID Behavior
The IP-ID field of the IPv4 header can have different change The IP-ID field of the IPv4 header can have different change
patterns: sequential in network byte order, sequential byte-swapped, patterns: sequential in network byte order, sequential byte-swapped,
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.
skipping to change at page 23, line 14 skipping to change at page 23, line 14
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.
6.4. Reconstruction and Verification 6.4. Reconstruction and Verification
Validation of the IR header (8-bit CRC) Validation of the IR header (8-bit CRC)
The decompressor MUST always validate the integrity of the IR The decompressor MUST always validate the integrity of the IR
skipping to change at page 24, line 35 skipping to change at page 24, line 35
| IPv6 Destination Option RFC 2460 | dest_opt | | IPv6 Destination Option RFC 2460 | dest_opt |
| IPv6 Hop-by-hop Options RFC 2460 | hop_opt | | IPv6 Hop-by-hop Options RFC 2460 | hop_opt |
| IPv6 Routing Header RFC 2460 | rout_opt | | IPv6 Routing Header RFC 2460 | rout_opt |
+----------------------------------+---------------+ +----------------------------------+---------------+
Static chain: Static chain:
The static chain consists of one item for each header of the chain The static chain consists of one item for each header of the chain
of protocol headers that is compressed, starting from the of protocol headers that is compressed, starting from the
outermost IP header. In the formal description of the header outermost IP header. In the formal description of the header
formats, this static chain item for each header type is labelled formats, this static chain item for each header type is labeled
<protocol_name>_static. The static chain is only used in the IR <protocol_name>_static. The static chain is only used in the IR
header format. header format.
Dynamic chain: Dynamic chain:
The dynamic chain consists of one item for each header of the The dynamic chain consists of one item for each header of the
chain of protocol headers that is compressed, starting from the chain of protocol headers that is compressed, starting from the
outermost IP header. In the formal description of the header outermost IP header. In the formal description of the header
formats, the dynamic chain item for each header type is labelled formats, the dynamic chain item for each header type is labeled
<protocol_name>_dynamic. The dynamic chain is only used in the IR <protocol_name>_dynamic. The dynamic chain is only used in the IR
and co_repair header formats. and co_repair header formats.
Irregular chain: Irregular chain:
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
skipping to change at page 25, line 30 skipping to change at page 25, line 30
use. The format of the irregular chain item for the outer IP use. The format of the irregular chain item for the outer IP
headers is also determined using one flag for TTL/Hop Limit and headers is also determined using one flag for TTL/Hop Limit and
TOS/TC. This flag is defined in the format of some of the TOS/TC. This flag is defined in the format of some of the
compressed base headers. 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
The baseheader_outer_headers encoding method skips over all the The baseheader_outer_headers encoding method skips over all the
fields of the extension header(s) that do not belong to the innermost fields of the extension header(s) that do not belong to the innermost
IP header, without encoding any of them. Changing fields in outer IP header, without encoding any of them. Changing fields in outer
headers are instead handled by the irregular chain. headers are instead handled by the irregular chain.
This encoding method, similarly to the baseheader_extension_headers This encoding method, similarly to the baseheader_extension_headers
encoding method above, is necessary to keep the definition of the encoding method above, is necessary to keep the definition of the
header formats syntactically correct. It describes tunneling IP header formats syntactically correct. It describes tunneling IP
headers and their respective extension headers (i.e. all headers headers and their respective extension headers (i.e., all headers
located before the innermost IP header) for CO headers (see located before the innermost IP header) for CO headers (see
Section 6.8.2). Section 6.8.2).
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
(e.g., time to live), this is recomputed and verified at each (e.g., time to live), this is recomputed and verified at each
skipping to change at page 27, line 21 skipping to change at page 27, line 21
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. There is no reason to transmit this
checksum when almost all IP header information is compressed away, checksum when almost all IP header information is compressed away,
and when decompression is verified by a CRC computed over the and when decompression is verified by a CRC computed over the
original header for every compressed packet; instead, the checksum original header for every compressed packet; instead, the checksum
can be recomputed by the decompressor. can be recomputed by 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
This encoding method compresses the minimal encapsulation header This encoding method compresses the minimal encapsulation header
skipping to change at page 27, line 44 skipping to change at page 27, line 44
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
avoid processing a corrupted header. avoid processing a corrupted header.
skipping to change at page 28, line 19 skipping to change at page 28, line 19
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 checksum down to a size of zero bits, i.e. no bits are header checksum down to a size of zero bits, i.e., no bits are
transmitted in compressed headers for this field. Using this transmitted in compressed headers for this field. Using this
encoding method, the decompressor infers the value of this field by encoding method, the decompressor infers the value of this field by
counting in octets the length of the entire packet after counting in octets 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
following this IPv6 header, in octets. (Note that any following this IPv6 header, in octets. (Note that any
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.
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.
skipping to change at page 29, line 47 skipping to change at page 29, line 47
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 RTP timestamp between consecutive
unit increase of the RTP SN will provide the most gain for the scaled unit increase of the RTP SN will provide the most gain for the scaled
encoding. Other values may provide the same gain in some situations, encoding. Other values may provide the same gain in some situations,
but may reduce the gain in others. 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
skipping to change at page 30, line 30 skipping to change at page 30, line 30
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.
ts_scaled =:= timer_based_lsb(<time_stride_param>, ts_scaled =:= timer_based_lsb(<time_stride_param>,
<num_lsbs_param>, <offset_param>) <num_lsbs_param>, <offset_param>)
The parameters "num_lsbs_param" and "offset_param" are the parameters The parameters "num_lsbs_param" and "offset_param" are the parameters
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.
skipping to change at page 31, line 23 skipping to change at page 31, line 23
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.
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
skipping to change at page 33, line 29 skipping to change at page 33, line 29
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
following formula: following formula:
IP-ID = delta_msn + reference_IP_ID_value IP-ID = delta_msn + reference_IP_ID_value
where "delta_msn" is the difference between the reference value of where "delta_msn" is the difference between the reference value of
the MSN in the context and the uncompressed value of the MSN the MSN in the context and the uncompressed value of the MSN
associated to the compressed header, and where associated to the compressed header, and where
"reference_IP_ID_value" is the value of the IP-ID in the context. "reference_IP_ID_value" is the value of the IP-ID in the context.
For swapped IP-ID behavior (i.e. when ip_id_behavior_innermost is set For swapped IP-ID behavior (i.e., when ip_id_behavior_innermost is
to IP_ID_BEHAVIOR_SEQUENTIAL_SWAPPED), "reference_IP_ID_value" and set to IP_ID_BEHAVIOR_SEQUENTIAL_SWAPPED), "reference_IP_ID_value"
"IP-ID" are byte-swapped with regard to the corresponding fields in and "IP-ID" are byte-swapped with regard to the corresponding fields
the context. in the context.
If the IP-ID behavior is random or zero, this encoding method does If the IP-ID behavior is random or zero, this encoding method does
not update any fields. not update any fields.
6.6.13. list_csrc(cc_value) 6.6.13. list_csrc(cc_value)
This encoding method compresses the list of RTP CSRC identifiers This encoding method compresses the list of RTP CSRC identifiers
using list compression. This encoding establishes a content for the using list compression. This encoding establishes a content for the
different CSRC identifiers (items) and a list describing the order in different CSRC identifiers (items) and a list describing the order in
which they appear. which they appear.
skipping to change at page 36, line 20 skipping to change at page 36, line 20
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 of
the cc_value argument of the list_csrc encoding (Section 6.6.13). the cc_value argument of the list_csrc encoding (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 item of the uncompressed header, in the same order as they
appear in the uncompressed header. 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
+---+---+---+---+ +---+---+---+---+
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:
skipping to change at page 37, line 23 skipping to change at page 37, line 23
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 its
list items present, i.e. all X-bits in the XI list MUST be set. All list items present, i.e., all X-bits in the XI list MUST be set. All
items previously established in the item table that are not present items previously established in the item table that are not present
in the list decompressed from this packet MUST also be retained in in the list decompressed from this packet MUST also be retained in
the decompressor context. 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 specification of the header formats.
skipping to change at page 40, line 42 skipping to change at page 40, line 42
CRC: 8-bit CRC over the entire IR-header, including any CID fields CRC: 8-bit CRC over the entire IR-header, including any CID fields
and up until the end of the dynamic chain, using the polynomial and up until the end of the dynamic chain, using the polynomial
defined in [RFC4995]. For purposes of computing the CRC, the CRC defined in [RFC4995]. For purposes of computing the CRC, the CRC
field is zero. field is zero.
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-
skipping to change at page 44, line 28 skipping to change at page 44, line 36
+---+---+---+---+---+---+---+---+ +---+---+---+---+---+---+---+---+
: : : :
/ Irregular Chain / variable length / Irregular Chain / variable length
: : : :
--- --- --- --- --- --- --- --- --- --- --- --- --- --- --- ---
The base header in the figure above is the compressed representation The base header in the figure above is the compressed representation
of the innermost IP header and other header(s), if any, in the of the innermost IP header and other header(s), if any, in the
uncompressed packet. The base header formats are defined in uncompressed packet. The base header formats are defined in
Section 6.8.2.4. In the formal description of the header formats, Section 6.8.2.4. In the formal description of the header formats,
the base header for each profile is labelled the base header for each profile is labeled
<profile_name>_baseheader, where <profile_name> is defined in the <profile_name>_baseheader, where <profile_name> is defined in the
following table: following table:
+------------------+----------------+ +------------------+----------------+
| Profile number | profile_name | | Profile number | profile_name |
+------------------+----------------+ +------------------+----------------+
| 0x0101 | rtp | | 0x0101 | rtp |
| 0x0102 | udp | | 0x0102 | udp |
| 0x0103 | esp | | 0x0103 | esp |
| 0x0104 | ip | | 0x0104 | ip |
skipping to change at page 101, line 23 skipping to change at page 101, line 29
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)
+---+---+---+---+---+---+---+---+ +---+---+---+---+---+---+---+---+
6.9.2.1. The REJECT option Opt Type: Unsigned integer that represents the type of the
feedback option. Sections Section 6.9.2.1 to Section 6.9.2.4
describe the ROHCv2 feedback options.
Opt Len: The lenght of the Option Data field, in octets.
Option Data: Feedback type specific data. Present if the value of
the Opt Len field is set to a non-zero value.
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
+---+---+---+---+---+---+---+---+ +---+---+---+---+---+---+---+---+
| 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
+---+---+---+---+---+---+---+---+ +---+---+---+---+---+---+---+---+
| Opt Type = 3 | Opt Len = 0 | | Opt Type = 3 | Opt Len = 0 |
+---+---+---+---+---+---+---+---+ +---+---+---+---+---+---+---+---+
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.
skipping to change at page 102, line 15 skipping to change at page 102, line 32
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 Feedback 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 Feedback 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 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) or not. The CLOCK_RESOLUTION option is
applicable per channel, i.e. it applies to any context associated applicable per channel, i.e., it applies to any context associated
with a profile for which the option is relevant between one with a profile for which the option is relevant between one
compressor and decompressor pair. compressor and decompressor pair.
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
resolution of the decompressor expressed in milliseconds.
The smallest clock resolution which can be indicated is 1 The smallest clock resolution which can be indicated is 1
millisecond. The value zero has a special meaning: it indicates that millisecond. The value zero has a special meaning: it indicates that
the decompressor cannot do timer-based compression of the RTP the decompressor cannot do timer-based compression of the RTP
Timestamp. The CLOCK_RESOLUTION option MUST NOT appear more than Timestamp. The CLOCK_RESOLUTION option MUST NOT appear more than
once in the FEEDBACK-2 format, otherwise the compressor MUST discard once in the FEEDBACK-2 format, otherwise the compressor MUST discard
the entire feedback element. the entire 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 A malfunctioning or malicious header compressor could cause the
header decompressor to reconstitute packets that do not match the header decompressor to reconstitute packets that do not match the
original packets but still have valid IP, UDP and RTP headers and original packets but still have valid IP, UDP and RTP headers and
possibly also valid UDP checksums. Such corruption may be detected possibly also valid UDP checksums. Such corruption may be detected
with end-to-end authentication and integrity mechanisms which will with integrity mechanisms which will not be affected by the
not be affected by the compression. Moreover, this header compression. Moreover, this header compression scheme uses an
compression scheme uses an internal checksum for verification of internal checksum for verification of reconstructed headers. This
reconstructed headers. This reduces the probability of producing reduces the probability of producing decompressed headers not
decompressed headers not matching the original ones without this matching the original ones without this being noticed, which can be
being noticed. 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
skipping to change at page 104, line 40 skipping to change at page 105, line 39
0x0008 ROHC UDP-Lite RFC 4019 0x0008 ROHC UDP-Lite RFC 4019
0x0108 ROHCv2 UDP-Lite [RFCXXXX (this)] 0x0108 ROHCv2 UDP-Lite [RFCXXXX (this)]
0xnn08 Reserved 0xnn08 Reserved
0x0009-0xnn7F To be Assigned by IANA 0x0009-0xnn7F To be Assigned by IANA
0xnn80-0xnnFE To be Assigned by IANA 0xnn80-0xnnFE To be Assigned by IANA
0xnnFF Reserved 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, and
also for constructive discussions during the development of this also for constructive discussions during the development of this
document. Thanks also to Carl Knutsson, Jani Juvan and Anders document. Thanks to Carl Knutsson for his extensive contribution to
Edqvist for useful comments and feedback. Finally, thanks to the this specification, as well as to Jani Juvan and Anders Edqvist for
many people who have contributed to previous ROHC specifications. useful comments and feedback. Thanks also to Elwyn Davies for his
review as the General Area Review Team (Gen-ART) reviewer, and to
Stephen Kent for his review on behalf of the IETF security
directorate, during IETF last-call. Finally, thanks to the many
people who have contributed to previous ROHC specifications and
supported this effort.
10. References 10. References
10.1. Normative References 10.1. Normative References
[RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768,
August 1980. August 1980.
[RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791,
September 1981. September 1981.
skipping to change at page 106, line 22 skipping to change at page 107, line 22
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.
[RFC4224] Pelletier, G., Jonsson, L-E., and K. Sandlund, "RObust [RFC4224] Pelletier, G., Jonsson, L-E., and K. Sandlund, "RObust
Header Compression (ROHC): ROHC over Channels That Can Header Compression (ROHC): ROHC over Channels That Can
Reorder Packets", RFC 4224, January 2006. Reorder Packets", RFC 4224, January 2006.
Appendix A. Detailed classification of header fields Appendix A. Detailed Classification of Header Fields
Header compression is possible due to the fact that most header Header compression is possible due to the fact that most header
fields do not vary randomly from packet to packet. Many of the fields do not vary randomly from packet to packet. Many of the
fields exhibit static behavior or change in a more or less fields exhibit static behavior or change in a more or less
predictable way. When designing a header compression scheme, it is predictable way. When designing a header compression scheme, it is
of fundamental importance to understand the behavior of the fields in of fundamental importance to understand the behavior of the fields in
detail. detail.
In this appendix, all fields in the headers compressible by these In this appendix, all fields in the headers compressible by these
profiles are classified and analyzed. The analysis is based on profiles are classified and analyzed. The analysis is based on
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 and any change to them only has to be possible
 End of changes. 81 change blocks. 
131 lines changed or deleted 150 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/