One document matched: draft-ietf-rohc-rfc3095bis-rohcv2-profiles-01.txt
Differences from draft-ietf-rohc-rfc3095bis-rohcv2-profiles-00.txt
Robust Header Compression G. Pelletier
Internet-Draft K. Sandlund
Expires: November 26, 2007 Ericsson
May 25, 2007
RObust Header Compression Version 2 (RoHCv2): Profiles for RTP, UDP, IP,
ESP and UDP Lite
draft-ietf-rohc-rfc3095bis-rohcv2-profiles-01
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on November 26, 2007.
Copyright Notice
Copyright (C) The IETF Trust (2007).
Abstract
This document specifies ROHC (Robust Header Compression) profiles
that efficiently compress RTP/UDP/IP (Real-Time Transport Protocol,
User Datagram Protocol, Internet Protocol), RTP/UDP-Lite/IP (User
Datagram Protocol Lite), UDP/IP, UDP-Lite/IP, IP and ESP/IP
(Encapsulating Security Payload) headers.
This specification defines a second version of the profiles found in
Pelletier & Sandlund Expires November 26, 2007 [Page 1]
Internet-Draft RoHCv2 Profiles May 2007
RFC 3095, RFC 3843 and RFC 4019; it supersedes their definition, but
does not obsolete them.
The RoHCv2 profiles introduce a number of simplifications to the
rules and algorithms that govern the behavior of the compression
endpoints. It also defines robustness mechanisms that may be used by
a compressor implementation to increase the probability of
decompression success when packets can be lost and/or reordered on
the ROHC channel. Finally, the RoHCv2 profiles define its own
specific set of packet formats, using the ROHC formal notation.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 5
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Acronyms . . . . . . . . . . . . . . . . . . . . . . . . . . 7
4. Background (Informative) . . . . . . . . . . . . . . . . . . 7
4.1. Classification of header fields . . . . . . . . . . . . . 7
4.2. Operational Characteristics of RoHCv2 Profiles . . . . . 8
5. Overview of the RoHCv2 Profiles (Informative) . . . . . . . . 9
5.1. General Concepts . . . . . . . . . . . . . . . . . . . . 9
5.1.1. Control Fields and Context Updates . . . . . . . . . 9
5.2. Compressor Concepts . . . . . . . . . . . . . . . . . . . 10
5.2.1. Optimistic Approach . . . . . . . . . . . . . . . . . 10
5.2.2. Tradeoff between robustness to losses and to
reordering . . . . . . . . . . . . . . . . . . . . . 10
5.2.3. Interactions with the Decompressor Context . . . . . 12
5.3. Decompressor Concepts . . . . . . . . . . . . . . . . . . 13
5.3.1. Decompressor State Machine . . . . . . . . . . . . . 13
5.3.2. Decompressor Context Management . . . . . . . . . . . 16
5.3.3. Feedback logic . . . . . . . . . . . . . . . . . . . 17
6. RoHCv2 Profiles (Normative) . . . . . . . . . . . . . . . . . 18
6.1. Profile Operation, per-context . . . . . . . . . . . . . 18
6.2. Control Fields . . . . . . . . . . . . . . . . . . . . . 19
6.2.1. Master Sequence Number (MSN) . . . . . . . . . . . . 19
6.2.2. IP-ID behavior . . . . . . . . . . . . . . . . . . . 20
6.3. Reconstruction and Verification . . . . . . . . . . . . . 20
6.4. Reordering and Segmentation . . . . . . . . . . . . . . . 20
6.4.1. Optimistic Approach . . . . . . . . . . . . . . . . . 21
6.5. Compressed Header Chains . . . . . . . . . . . . . . . . 21
6.6. Packet Formats and Encoding Methods . . . . . . . . . . . 22
6.6.1. baseheader_extension_headers . . . . . . . . . . . . 22
6.6.2. baseheader_outer_headers . . . . . . . . . . . . . . 23
6.6.3. inferred_udp_length . . . . . . . . . . . . . . . . . 23
6.6.4. inferred_ip_v4_header_checksum . . . . . . . . . . . 23
6.6.5. inferred_mine_header_checksum . . . . . . . . . . . . 24
6.6.6. inferred_ip_v4_length . . . . . . . . . . . . . . . . 24
Pelletier & Sandlund Expires November 26, 2007 [Page 2]
Internet-Draft RoHCv2 Profiles May 2007
6.6.7. inferred_ip_v6_length . . . . . . . . . . . . . . . . 25
6.6.8. Scaled RTP Timestamp Encoding . . . . . . . . . . . . 25
6.6.9. Timer-Based RTP Timestamp Encoding . . . . . . . . . 26
6.6.10. inferred_scaled_field . . . . . . . . . . . . . . . . 26
6.6.11. control_crc3_encoding . . . . . . . . . . . . . . . . 27
6.6.12. inferred_sequential_ip_id . . . . . . . . . . . . . . 28
6.6.13. list_csrc(cc_value) . . . . . . . . . . . . . . . . . 28
6.7. Encoding Methods With External Parameters . . . . . . . . 32
6.8. Packet Formats . . . . . . . . . . . . . . . . . . . . . 36
6.8.1. Initialization and Refresh Packet (IR) . . . . . . . 36
6.8.2. IR Packet Payload Discard (IR-PD) . . . . . . . . . 37
6.8.3. Compressed Packet Formats (CO) . . . . . . . . . . . 38
6.9. Feedback Formats and Options . . . . . . . . . . . . . . 100
6.9.1. Feedback Formats . . . . . . . . . . . . . . . . . . 100
6.9.2. Feedback Options . . . . . . . . . . . . . . . . . . 101
7. Security Considerations . . . . . . . . . . . . . . . . . . . 104
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 104
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 106
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 106
10.1. Normative References . . . . . . . . . . . . . . . . . . 106
10.2. Informative References . . . . . . . . . . . . . . . . . 107
Appendix A. Detailed classification of header fields . . . . 107
Appendix A.1. General classification . . . . . . . . . . . . . 108
Appendix A.1.1. IPv4 header fields . . . . . . . . . . . . . . . 108
Appendix A.1.2. IPv6 header fields . . . . . . . . . . . . . . . 110
Appendix A.1.3. UDP header fields . . . . . . . . . . . . . . . 111
Appendix A.1.4. UDP-Lite header fields . . . . . . . . . . . . . 111
Appendix A.1.5. RTP header fields . . . . . . . . . . . . . . . 112
Appendix A.1.6. ESP header fields . . . . . . . . . . . . . . . 113
Appendix A.2. Analysis of change patterns of header fields . . 113
Appendix A.2.1. IPv4 Identification . . . . . . . . . . . . . . 116
Appendix A.2.2. IP Traffic Class / Type-Of-Service . . . . . . . 117
Appendix A.2.3. IP Hop-limit / Time-To-Live . . . . . . . . . . 117
Appendix A.2.4. IPv4 Don't Fragment . . . . . . . . . . . . . . 117
Appendix A.2.5. UDP Checksum . . . . . . . . . . . . . . . . . . 117
Appendix A.2.6. UDP-Lite Checksum Coverage . . . . . . . . . . . 117
Appendix A.2.7. UDP-Lite Checksum . . . . . . . . . . . . . . . 117
Appendix A.2.8. RTP CSRC Counter . . . . . . . . . . . . . . . . 117
Appendix A.2.9. RTP Marker . . . . . . . . . . . . . . . . . . . 118
Appendix A.2.10. RTP Padding . . . . . . . . . . . . . . . . . . 118
Appendix A.2.11. RTP Extension . . . . . . . . . . . . . . . . . 118
Appendix A.2.12. RTP Payload Type . . . . . . . . . . . . . . . . 118
Appendix A.2.13. RTP Sequence Number . . . . . . . . . . . . . . 118
Appendix A.2.14. RTP Timestamp . . . . . . . . . . . . . . . . . 118
Appendix A.2.15. RTP Contributing Sources (CSRC) . . . . . . . . 119
Appendix A.2.16. ESP Sequence Number . . . . . . . . . . . . . . 119
Appendix B. Differences between RoHCv2 and RFC3095
profiles . . . . . . . . . . . . . . . . . . . . 119
Pelletier & Sandlund Expires November 26, 2007 [Page 3]
Internet-Draft RoHCv2 Profiles May 2007
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 120
Intellectual Property and Copyright Statements . . . . . . . . . 121
Pelletier & Sandlund Expires November 26, 2007 [Page 4]
Internet-Draft RoHCv2 Profiles May 2007
1. Introduction
The ROHC WG has developed a header compression framework on top of
which various profiles can be defined for different protocol sets or
compression requirements. The ROHC framework was first documented in
[RFC3095], together with profiles for compression of RTP/UDP/IP
(Real-Time Transport Protocol, User Datagram Protocol, Internet
Protocol), UDP/IP, IP and ESP/IP (Encapsulating Security Payload)
headers. Additional profiles for compression of IP headers [RFC3843]
and UDP-Lite (User Datagram Protocol Lite) headers [RFC4019] were
later specified to complete the initial set of ROHC profiles.
This document defines an updated version for each of the above
mentioned profiles, and its definition is based on the specification
of the RoHC framework as found in
[I-D.ietf-rohc-rfc3095bis-framework].
Specifically, this document defines header compression schemes for:
o RTP/UDP/IP : profile 0x0101
o UDP/IP : profile 0x0102
o ESP/IP : profile 0x0103
o IP : profile 0x0104
o RTP/UDP-Lite/IP : profile 0x0107
o UDP-Lite/IP : profile 0x0108
ROHCv2 compresses the following type of extension headers:
o AH [RFC4302]
o GRE [RFC2784][RFC2890]
o MINE [RFC2004]
o NULL-encrupted ESP [RFC4303]
o IPv6 Destination Options header[RFC2460]
o IPv6 Hop-by-hop Options header[RFC2460]
o IPv6 Routing header [RFC2460].
2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119].
This document is consistent with the terminology found in the ROHC
framework [I-D.ietf-rohc-rfc3095bis-framework] and in the formal
notation for ROHC [I-D.ietf-rohc-formal-notation]. In addition, this
document uses or defines the following terms:
Pelletier & Sandlund Expires November 26, 2007 [Page 5]
Internet-Draft RoHCv2 Profiles May 2007
Chaining of Items
A chain groups fields based on similar characteristics. ROHCv2
defines chain items for static, dynamic and irregular fields.
Chaining is done by appending an item for e.g. each header to the
chain in their order of appearance in the uncompressed packet.
Chaining is useful to construct compressed headers from an
arbitrary number of any of the protocol headers for which a ROHCv2
profile defines a compressed format.
Delta
The delta refers to the difference in terms of the absolute value
of a field between two consecutive packets and processed by the
same compression endpoint.
Reordering Depth
The number of packets by which a packet made late in its sequence.
See definition of sequentially late packet below.
ROHCv2 packet types
ROHCv2 profiles use two different packet types: the Initialization
and Refresh (IR) packet type, and the Compressed packet type (CO).
Sequentially early packet
A packet that reaches the decompressor before one or several
packets that were delayed over the channel, whereas all of the
said packets belong to the same header-compressed flow and are
associated to the same compression context (CID). At the time of
the arrival of a sequentially early packet, the packet(s) delayed
on the link cannot be differentiated from lost packet(s).
Sequentially late packet
A packet is late within its sequence if it reaches the
decompressor after one or several other packets belonging to the
same CID have been received, although the sequentially late packet
was sent from the compressor before the other packet(s).
Timestamp stride (ts_stride)
Pelletier & Sandlund Expires November 26, 2007 [Page 6]
Internet-Draft RoHCv2 Profiles May 2007
The timestamp stride (TS_STRIDE) is the expected increase in the
timestamp value between two RTP packets with consecutive sequence
numbers.
3. Acronyms
This section lists most acronyms used for reference, in addition to
those defined in [I-D.ietf-rohc-rfc3095bis-framework].
AH Authentication Header.
ESP Encapsulating Security Payload.
GRE Generic Routing Encapsulation. RFC 2784, RFC 2890.
IC Initial Context state (decompressor)
FC Full Context state (decompressor)
IP Internet Protocol.
LSB Least Significant Bits.
MINE Minimal Encapsulation in IP
MSB Most Significant Bits.
MSN Master Sequence Number.
NC No Context state (decompressor).
OA Optimistic Approach.
ROHCv2 Set of header compression profiles defined in this document
RTP Real-time Transport Protocol.
SSRC Synchronization source. Field in RTP header.
CSRC Contributing source. Optional list of CSRCs in RTP header.
TC Traffic Class. Octet in IPv6 header. See also TOS.
TOS Type Of Service. Octet in IPv4 header. See also TC.
TS RTP Timestamp.
UDP User Datagram Protocol.
UDP-Lite User Datagram Protocol Lite.
4. Background (Informative)
This section provides background information on the compression
profiles defined in this document. The fundamentals of general
header compression and of the ROHC framework may be found in section
3 and 4 of [I-D.ietf-rohc-rfc3095bis-framework], respectively. The
fundamentals of the formal notation for ROHC are defined in
[I-D.ietf-rohc-formal-notation]. [RFC4224] describes the impacts of
out-of-order delivery on profiles based on [RFC3095].
4.1. Classification of header fields
Section 3.1 of [I-D.ietf-rohc-rfc3095bis-framework] explains that
header compression is possible due to the fact that there is much
redundancy between field values within the headers of a packet, but
Pelletier & Sandlund Expires November 26, 2007 [Page 7]
Internet-Draft RoHCv2 Profiles May 2007
especially between the headers of consecutive packets.
Appendix A lists and classifies in detail all the header fields
relevant to this document. The appendix concludes with
recommendations on how the various fields should be handled by header
compression algorithms.
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
fields however need more sophisticated mechanisms.
These fields are:
- IPv4 Identification (16 bits) - IP-ID
- ESP Sequence Number (32 bits) - ESP SN
- UDP Checksum (16 bits) - Checksum
- UDP-Lite Checksum (16 bits) - Checksum
- UDP-Lite Checksum Coverage (16 bits) - CCov
- RTP Marker ( 1 bit ) - M-bit
- RTP Sequence Number (16 bits) - RTP SN
- RTP Timestamp (32 bits) - TS
In particular, for RTP, the analysis in Appendix A reveals that the
values of the RTP Timestamp (TS) field usually have a strong
correlation to the RTP Sequence Number (SN), which increments by one
for each packet emitted by an RTP source. The RTP M-bit is expected
to have the same value most of the time, but it needs to be
communicated explicitly on occasion.
For UDP, the Checksum field cannot be inferred or recalculated at the
receiving end without violating its end-to-end properties, and is
thus sent as-is when enabled (mandatory with IPv6). The same applies
to the UDP-Lite Checksum (mandatory with both IPv4 and IPv6), while
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
SN is often observed between the Identifier field (IP-ID) and the
master sequence number used for compression (e.g. the RTP SN when
compressing RTP headers).
4.2. Operational Characteristics of RoHCv2 Profiles
Robust header compression can be used over many type of link
technologies. Section 4.4 of [I-D.ietf-rohc-rfc3095bis-framework]
lists the operational characteristics of the ROHC channel. The
RoHCv2 profiles address a wide range of applications, and this
section summarizes some of the operational characteristics that are
specific to these profiles.
Pelletier & Sandlund Expires November 26, 2007 [Page 8]
Internet-Draft RoHCv2 Profiles May 2007
Packet length
ROHCv2 profiles assume that the lower layer indicates the length
of a compressed packet. ROHCv2 compressed headers do not contain
length information for the payload.
Out-of-order delivery between compression endpoints
The definition of the RoHCv2 profiles places no strict requirement
on the delivery sequence between the compression endpoints, i.e.
packets may be received in a different order than the compressor
sent them and still have a fair probability to be successfully
decompressed.
However, frequent out-of-order delivery and/or significant
reordering depth will negatively impact the compression
efficiency. More specifically, if the compressor can operate
using a proper estimate of the reordering characteristics of the
path between the compression endpoints, larger headers can be sent
more often to increase the robustness against decompression
failures due to out-of-order delivery. Otherwise, the compression
efficiency will be impaired from an increase in the frequency of
decompression failures and recovery attempts.
5. Overview of the RoHCv2 Profiles (Informative)
This section provides an overview of important and useful concepts of
ROHCv2 profiles. These concepts may be used as guidelines for
implementations but they are not part of the normative definition of
the profiles, as these concepts relates to the compression efficiency
of the protocol without impacting the interoperability
characteristics of an implementation.
5.1. General Concepts
5.1.1. Control Fields and Context Updates
Control fields have the same attributes and properties as
uncompressed fields [I-D.ietf-rohc-formal-notation]. These fields
are used for compression and decompression of some of the
uncompressed header fields. Updating the value of one or more
control field(s) is thus no less important than updating context
values for header fields. Control fields are defined in
[I-D.ietf-rohc-formal-notation].
Packet types that initialize or update the value of one or more
control field(s) thus include an additional 3-bit CRC, as defined by
Pelletier & Sandlund Expires November 26, 2007 [Page 9]
Internet-Draft RoHCv2 Profiles May 2007
the packet formats in Section 6.8. The CRC is calculated using the
UVALUE of the control field(s) that it covers.
This CRC validates all the control fields that are updated. Failure
to verify this CRC should be interpreted by the decompressor as a
decompression failure, in the algorithm it implements to assess the
validity of its context.
5.2. Compressor Concepts
Header compression can be conceptually characterized as the
interaction of a compressor with a decompressor state machine, one
per context. The responsability of the compressor is to convey the
information needed to successfully decompress a packet, based on a
certain confidence regarding the state of the decompressor context.
This confidence is obtained from the frequency and the type of
information the compressor sends when updating the decompressor
context, from the optimistic approach (Section 5.2.1) and optionally
from feedback messages received from the decompressor.
5.2.1. Optimistic Approach
A compressor always uses the optimistic approach when it performs
context updates. The compressor normally repeats the same type of
update until it is fairly confident that the decompressor has
successfully received the information. If the decompressor
successfully receives any of the headers containing this update,
state will be available for the decompressor to process smaller
compressed headers.
If field X in the uncompressed header changes value, the compressor
uses a packet type that contains an encoding of field X until it has
gained confidence that the decompressor has received at least one
packet containing the new value for X. The compressor normally
selects a compressed format with the smallest header that can convey
the changes needed to achieve confidence.
The number N of repetitions for the optimistic approach that is
needed to obtain this confidence is normally related to the packet
loss and out-of-order delivery characteristics of the link where
header compression is used; it is thus not defined in this document
and is left open to implementations.
5.2.2. Tradeoff between robustness to losses and to reordering
The ability of a header compression algorithm to handle sequentially
late packets is mainly limited by two factors: the interpretation
Pelletier & Sandlund Expires November 26, 2007 [Page 10]
Internet-Draft RoHCv2 Profiles May 2007
interval offset of the sliding window used for LSB encoded fields
[I-D.ietf-rohc-formal-notation], and the optimistic approach
Section 5.2.1 for seldom changing fields.
The interpretation interval offset specifies an upper limit for the
maximum reordering depth, by which is it possible for decompressor to
recover the original value of a dynamically changing field that is
encoded using W-LSB. Its value is bound to the number of LSB
compressed bits in the compressed header format, and grows with the
number of bits transmitted. However, the offset and the LSB encoding
only provide robustness for the field that it compresses, and
(implicitly) for other sequentially changing fields that are derived
from that field.
This is shown in the figure below:
<--- interpretation interval (size is 2^k) ---->
|------------------+---------------------------|
v_ref-p v_ref v_ref + (2^k-1) - p
Lower Upper
Bound Bound
<--- reordering --> <--------- losses --------->
where delta(SN) = p is the maximum negative delta, corresponding
to the maximum reordering depth for which the lsb encoding can
recover the original value of the field;
where delta(SN) = (2^k-1) - p is the maximum positive delta,
corresponding to the maximum number of consecutive losses for
which the lsb encoding can recover the original value of the
field;
where v_ref is the reference value, as defined in the lsb encoding
method in [I-D.ietf-rohc-formal-notation].
The optimistic approach (Section 5.2.1) provides the upper limit for
the maximum reordering depth for seldom changing fields.
There is thus a tradeoff between the robustness against reordering
and the robustness against packet losses, with respect to the number
of MSN bits needed and the distribution of the interpretation
interval between negative and positive deltas in the MSN.
There is also a tradeoff between compression efficiency and
robustness. When only information on the MSN needs to be conveyed to
the decompressor, the tradeoff relates to the number of compressed
MSN bits in the compressed header format. Otherwise, the tradeoff
relates to the implementation of the optimistic approach.
Pelletier & Sandlund Expires November 26, 2007 [Page 11]
Internet-Draft RoHCv2 Profiles May 2007
5.2.3. Interactions with the Decompressor Context
The compressor normally starts compression with the initial
assumption that the decompressor has no useful information to process
the new flow, and sends Initialization and Refresh (IR) packets.
Initially, when sending the first IR packet for a compressed flow,
the compressor does not expect to receive feedback for that flow,
until such feedback is first received. At this point, the compressor
may then assume that the decompressor will continue to send feedback
in order to repair its context when necessary. The former is
referred to as unidirectional operation, while the latter is called
bidirectional operation.
The compressor can then adjust the compression level based on its
confidence that the decompressor has the necessary information to
successfully process the compressed headers that it selects. In
other words, the responsibility of the compressor is to ensure that
the decompressor operates with state information that is sufficient
to allow decompression of the most efficient compressed header(s),
and to allow the decompressor to successfully recover that state
information as soon as possible otherwise.
The compressor thus has the entire responsability to ensure that the
decompressor has the proper information to decompress the type of
compressed header that it sends. In other words, the choice of
compressed header depends on the following factors:
o the outcome of the encoding method applied to each field;
o the optimistic approach, with respect to the characteristics of
the channel;
o the type of operation (unidirectional or bidirectional), and if in
birectional operation, feedback received from the decompressor
(ACKs, NACKs, Static-NACK, and options).
Encoding methods normally use previous value(s) from a history of
packets whose headers it has previously compressed. The optimistic
approach is meant to ensure that at least one compressed header
containing the information to update the state for a field is
received. Finally, feedback indicates what actions the decompressor
has taken with respect its assumptions regarding the validity of its
context (Section 5.3.2); it indicates what type of compressed header
the decompressor can or cannot decompress.
The decompressor has the means to detect decompression failures for
any type of compressed (CO) header, using the CRC verification.
Depending on the frequency and/or on the type of the failure, it
might send a negative acknowledgement (NACK) or an explicit request
Pelletier & Sandlund Expires November 26, 2007 [Page 12]
Internet-Draft RoHCv2 Profiles May 2007
for a complete context update (Static-NACK). However, the
decompressor does not have the means to identify the cause of the
failure, and in particular decompression of what field(s) is
responsible for the failure. The compressor is thus always
reponsible to figure out what is the most suitable response to a
negative acknowledgement, using the confidence it has in the state of
the decompressor context, when selecting the type of compressed
header it will use when compressing a header.
5.3. Decompressor Concepts
The decompressor normally always uses the last received and
successfully validated (IR packets) or verified (CO packets) header
as the reference for future decompression. If the received packet is
older than the current reference packet based on the MSN in the
compressed header, the decompressor may refrain from using this
packet as the new reference packet, even if the correctness of its
header was successfully verified.
The decompressor's responsibility is thus to minimally and
consistently verify the outcome of the decompression attempt, update
its context when successful and finally to request context repairs by
making coherent usage of feedback, once it starts using it.
Specifically, the outcome of every decompression attempt is verified
using the CRC present in the compressed header; the decompressor
updates the context information when this outcome is successfully
verified; finally if the decompressor uses feedback once for a
compressed flow then it will continue to do so for as long as the
corresponding context is associated with the same profile.
5.3.1. Decompressor State Machine
The decompressor operation may be represented as a state machine
defining three states: No Context (NC), Initial Context (IC) and Full
Context (FC).
The decompressor starts with no valid context, the NC state.
Successful CRC-8 validation of an IR packet moves the decompressor to
the IC state, where it stays until it successfully verifies a
decompression attempt for a compressed header with a 7-bit CRC. The
decompressor state machine normally does not leave the FC state once
it has entered this state; only repeated decompression failures will
force the decompressor to transit downwards to a lower state.
Below is the state machine for the decompressor. Details of the
transitions between states and decompression logic are given in the
sub-sections following the figure.
Pelletier & Sandlund Expires November 26, 2007 [Page 13]
Internet-Draft RoHCv2 Profiles May 2007
CRC-8(IR) or
CRC-8(IR)
Validation
CRC-7(CO) or
CRC-8(IR) CRC-8(IR) CRC-8(IR) CRC-7(CO) CRC-3(CO)
Failure Validation Validation Verification Verification
+--->---+ +-->---->--+ +-->----->--+ +-->---->--+ +-->---->--+
| | | | | | | | | |
| v | v | v | v | v
+-----------------+ +----------------------+ +-------------------+
| No Context (NC) | | Initial Context (IC) | | Full Context (FC) |
+-----------------+ +----------------------+ +-------------------+
^ | ^ CRC-7(CO) | ^ |
| Static Context | | Failure or | | Context Damage |
| Damage Detected | | PT not allowed | | Detected |
+--<-----<-----<--+ +----<------<----+ +--<-----<-----<--+
where:
CRC-8(IR) validation: successful CRC-8 validation for the IR
header.
CRC-7(CO) and/or CRC-3(CO) verification: successful CRC
verification for the CO header, based on the number of CRC bits
carried in the CO header.
CRC-7(CO) failure: failure to CRC verify the decompression of a CO
header carrying a 7-bit CRC.
PT not allowed: the decompressor has received a packet type (PT)
for which the decopressor's current context does not provide
enough valid state information for that packet to be decompressed.
Static Context Damaged Detected: see definition in Section 5.3.2.
Context Damage Detected: see definition in Section 5.3.2.
5.3.1.1. No Context (NC) State
Initially, while working in the No Context (NC) state, the
decompressor has not yet successfully validated an IR packet.
Attempting decompression:
In the NC state, only packets carrying sufficient information on
the static fields (i.e. IR packets) can be decompressed.
Upward transition:
Upon receiving an IR packet, the decompressor validates the
integrity of its header using the CRC-8 validation. If the IR
packet is successfully validated, the decompressor updates the
context and use this packet as the reference packet. Once an IR
packet has initialized the context, the decompressor can transit
to the IC state.
Pelletier & Sandlund Expires November 26, 2007 [Page 14]
Internet-Draft RoHCv2 Profiles May 2007
Feedback logic:
In the No Context state, the decompressor should send a STATIC-
NACK if a packet of a type other than IR is received, or if an IR
packet has failed the CRC-8 validation, subject to the feedback
rate limitation as described in Section 5.3.3.
5.3.1.2. Initial Context (IC) State
In the IC state, the decompressor has successfully validated an IR
packet.
Attempting decompression:
In the Initial Context state, only packets carrying sufficient
information on the dynamic fields covered by an 8-bit CRC (i.e.
IR) or CO packets carrying a 7-bit CRC can be decompressed.
Upward transition:
The decompressor can move to the Full Context (FC) state when the
CRC verification succeeds for a CO header carrying a 7-bit CRC.
Downward transition:
The decompressor moves back to the NC state if it assumes static
context damage.
Feedback logic:
In the IC state, the decompressor should send a STATIC-NACK when
CRC-8 validation of an IR fails, or when a CO header carrying a
7-bit CRC fails and if static context damage is assumed, subject
to the feedback rate limitation as described in Section 5.3.3. If
any other packet type is received, the decompressor should treat
it as a CRC verification failure when deciding if a NACK is to be
sent.
5.3.1.3. Full Context (FC) State
In the FC state, the decompressor has successfully verified a CO
header with a 7-bit CRC.
Attempting decompression:
Pelletier & Sandlund Expires November 26, 2007 [Page 15]
Internet-Draft RoHCv2 Profiles May 2007
In the Full Context state, decompression can be attempted
regardless of the type of packet received.
Downward transition:
The decompressor moves back to the IC state if it assumes context
damage, and back to the NC state if it assumes static context
damage.
Feedback logic:
In the Full Context state, the decompressor should send a NACK
when CRC-8 validation or CRC verification of any packet type fails
and if context damage is assumed, subject to the feedback rate
limitation as described in Section 5.3.3.
5.3.2. Decompressor Context Management
All header formats carry a CRC and are context updating. A packet
for which the CRC succeeds updates the reference values of all header
fields, either explicitly (from the information about a field carried
within the compressed header) or implicitly (fields that are inferred
from other fields).
The decompressor may assume that some or the entire context is
invalid, following one or more failures to validate or verify a
header using the CRC. Because the decompressor cannot know the exact
reason(s) for a CRC failure or what field caused it, the validity of
the context hence does not refer to what exact context entry is
deemed valid or not.
Validity of the context rather relates to the detection of a problem
with the context. The decompressor first assume that the type of
information that most likely caused the failure(s) is the state that
normally changes for each packet, i.e. context damage of the dynamic
part of the context. Upon repeated failures and unsuccessful
repairs, the decompressor then assume that the entire context,
including the static part, needs to be repaired, i.e. static context
damage.
Context Damage Detection
The assumption of context damage means that the decompressor will
not attemp decompression of a CO headers that carries a 3-bit CRC,
and only attempt decompression of IR headers, or CO headers
protected by a CRC-7.
Static Context Damage Detection
Pelletier & Sandlund Expires November 26, 2007 [Page 16]
Internet-Draft RoHCv2 Profiles May 2007
The assumption of static context damage means that the
decompressor refrains from attempting decompression of any type of
header other than the IR header, as it cannot know what part of
its context can be relied upon after first assuming context damage
and failed to repair its context, and as a result of too many
failures.
How these assumptions are made, i.e. how context damage is detected,
is open to implementations. It can be based on the residual error
rate, where a low error rate makes the decompressor assume damage
more often than on a high rate link.
The decompressor implements these assumptions by selecting the type
of compressed header for it may attempt decompression. In other
words, validity of the context refers to the ability of a
decompressor to attempt or not decompression of specific packet
types.
When RoHCv2 profiles are used over a channel that cannot guarantee
in-order delivery, the decompressor may refrain to update its context
with the content of a sequentially late packet that is successfully
decompressed. This is to avoid updating the context with information
that is older than what the decompressor already has in its context.
How the decompressor detects a sequentially late packet is outside
the scope of this specification, but it can for example use the MSN
to this purpose.
5.3.3. Feedback logic
RoHCv2 profiles may be used in environments with or without feedback
capabilities from decompressor to compressor. RoHCv2 however assumes
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
channel will be used during the entire compression operation for that
context (i.e. bidirectional operation).
The RoHC framework defines 3 types of feedback messages: ACKs, NACKs
and STATIC-NACKs. The semantics of each message if defined in
section 5.2.3.1. of [I-D.ietf-rohc-rfc3095bis-framework] What
feedback to send is coupled to the context management of the
decompressor, i.e. to the implementation of the context damage
detection algorithms as described in Section 5.3.2.
The decompressor should send a NACK when it assumes context damage,
and it should send a STATIC-NACK when it assumes static context
damage. The decompressor is not strictly expected to send ACK
feedback upon successful decompression, other than for the purpose of
improving compression efficiency.
Pelletier & Sandlund Expires November 26, 2007 [Page 17]
Internet-Draft RoHCv2 Profiles May 2007
When RoHCv2 profiles are used over a channel that cannot guarantee
in-order delivery, the decompressor may refrain to send ACK feedback
for a sequentially late packet that is successfully decompressed.
How the decompressor detects a sequentially late packet is outside
the scope of this specification, but it can for example use the MSN
to this purpose.
The decompressor should limit the rate at which it sends feedback,
for both ACKs and STATIC-NACK/NACKs, and should avoid sending
unnecessary duplicates of the same type of feedback message that may
be associated to the same event.
6. RoHCv2 Profiles (Normative)
6.1. Profile Operation, per-context
RoHCv2 profiles operates differently, per context, depending on how
the decompressor makes use of the feedback channel, if any. Once the
decompressor uses the feedback channel for a context, it establishes
the feedback channel for that CID.
The compressor always start assuming that the decompressor will not
send feedback when it initializes a new context (see also , section
5.1.1. of [I-D.ietf-rohc-rfc3095bis-framework]), i.e. there is no
established feedback channel for the new context. There will always
be a possibility of decompression failure with the optimistic
approach, because the decompressor may not have received sufficient
information for correct decompression. Therefore, until the
decompressor has established a feedback channel, the compressor
SHOULD periodically send IR packets. The periodicity can be based on
timeouts, on the number of compressed packets sent for the flow, or
any other strategy the implementer chooses.
The reception of either positive feedback (ACKs) or negative feedback
(NACKs) establishes the feedback channel from the decompressor for
the context (CID) for which the feedback was received. Once there is
an established feedback channel for a specific context, the
compressor can make use of this feedback to estimate the current
state of the decompressor. This helps increasing the compression
efficiency by providing the information needed for the compressor to
achieve the necessary confidence level. When the feedback channel is
established, it becomes superfluous for the compressor to send
periodic refreshes, and instead it can rely entirely on the
optimistic approach and feedback from the decompressor.
The decompressor MAY send positive feedback (ACKs) to initially
establish the feedback channel for a particular flow. Either
Pelletier & Sandlund Expires November 26, 2007 [Page 18]
Internet-Draft RoHCv2 Profiles May 2007
positive feedback (ACKs) or negative feedback (NACKs) establishes
this channel. The decompressor is REQUIRED to continue sending
feedback once it has established a feedback channel for a CID, for
the lifetime of the context, i.e. until the CID is associated with a
different profile from the reception of an IR packet, to send error
recovery requests and (optionally) acknowledgments of significant
context updates.
Due to the periodic refreshes and the lack of feedback for initiation
of error recovery, compression without an established feedback
channel will be less efficient and have a slightly higher probability
of loss propagation compared to the decompressor making use of
feedback.
6.2. Control Fields
RoHCv2 defines a number of control fields that are used by the
decompressor in its interpretation of the packet formats received
from the compressor.
A control field is a field that is transmitted from the compressor to
the decompressor, but is not part of the uncompressed header. Values
for control fields can be set up in the context of both the
compressor and the decompressor. Once established at the
decompressor, the values of these fields MUST be kept until updated
by another packet.
6.2.1. Master Sequence Number (MSN)
The Master Sequence Number (MSN) field is either taken from a field
that already exists in each of the headers of the protocol that the
profile compresses (e.g. RTP SN), or alternatively it is created at
the compressor.
The MSN field has the following two functions:
o Differentiating between packets when sending feedback data.
o Inferring the value of incrementing fields (e.g. IPv4
Identifier).
The MSN field is present in every packet sent by the compressor. The
MSN is sent in full in IR packets, while it is sent LSB encoded
within CO header formats. The decompressor always sends the MSN as
part of the feedback information. The compressor can later use the
MSN to infer which packet the decompressor is acknowledging.
For profiles for which the MSN is created by the compressor, the
following rules applies:
Pelletier & Sandlund Expires November 26, 2007 [Page 19]
Internet-Draft RoHCv2 Profiles May 2007
o The compressor should only initialize a new MSN for the initial IR
sent for a CID that corresponds to a context that is not already
associated with this profile;
o When the MSN is initialized, it is initialized to a random value;
o The value of the MSN is incremented by one for each packet that
the compressor sends.
6.2.2. IP-ID behavior
The IP-ID field of the IPv4 header can have different change
patterns: sequential in network byte order, sequential byte-swapped,
random or constant (a constant value of zero, although not conformant
with [RFC0791], as been observed in practice). The control field for
the IP-ID behavior determines which set of packet formats will be
used. Note that these control fields are also used to determine the
contents of the irregular chain item for each IP header.
If more than one level of IP headers is present, RoHCv2 profiles can
assign a sequential behavior (network byte order or byte-swapped)
only to the IP-ID of innermost IP header. This is because only this
IP-ID can possibly have a sufficiently close correlation with the MSN
to compress it as a sequentially changing field. Therefore, a
compressor MUST assign either the constant zero IP-ID or the random
IP-ID behavior to tunneling headers.
6.3. Reconstruction and Verification
The CRC carried within compressed headers MUST be used to verify
decompression. When the decompression is verified and successful,
the decompressor updates the context with the information received in
the current header; otherwise if the reconstructed header fails the
CRC verification, these updates MUST NOT be performed.
A packet for which the decompression attempt cannot be verified using
the CRC MUST NOT be delivered to upper layers.
Note: Decompressor implementations may attempt corrective or repair
measures prior to performing the above actions, and the result of any
decompression attempt MUST be verified using the CRC.
6.4. Reordering and Segmentation
When ROHCv2 profiles are used on a channel that may reorder packets,
the compressor should take into account some extra considerations
compared to when used on a channel that guarantees in-order
delivery.ROHC Segmentation (see [I-D.ietf-rohc-rfc3095bis-framework]
section 5.2.5) must not be used, i.e. MRRU MUST be set to 0).
Pelletier & Sandlund Expires November 26, 2007 [Page 20]
Internet-Draft RoHCv2 Profiles May 2007
6.4.1. Optimistic Approach
The optimistic approach is affected by the reordering characteristics
of the channel when operating over a reordering channel. Compressor
implementations should therefore adjust their optimistic approach
strategy to match both packet loss and reordering characteristics.
For example, the number of repetitions for each update of a non-LSB
encoded field can be increased. The compressor should ensure that
each such update is repeated until it is reasonably confident that at
least one packet containing this change has reached the decompressor
before the first packet sent after this sequence.
6.5. Compressed Header Chains
Some packet types use one or more chains containing sub-header
information. The function of a chain is to group fields based on
similar characteristics, such as static, dynamic or irregular fields.
Chaining is done by appending an item for each header to the chain in
their order of appearance in the uncompressed packet, starting from
the fields in the outermost header.
Static chain:
The static chain consists of one item for each header of the chain
of protocol headers to be compressed, starting from the outermost
IP header. In the formal description of the packet formats, this
static chain item for each header type is labelled
<protocol_name>_static. The static chain is only used in IR
packets.
Dynamic chain:
The dynamic chain consists of one item for each header of the
chain of protocol headers to be compressed, starting from the
outermost IP header. In the formal description of the packet
formats, the dynamic chain item for each header type is labelled
<protocol_name>_dynamic. The dynamic chain is used in IR packet
format
Irregular chain:
Pelletier & Sandlund Expires November 26, 2007 [Page 21]
Internet-Draft RoHCv2 Profiles May 2007
The structure of the irregular chain is analogous to the structure
of the static chain. For each compressed packet, the irregular
chain is appended at the specified location in the general format
of the compressed packets as defined in Section 6.8. The
irregular chain is used for all CO packets.
The format of the irregular chain for the innermost IP header
differs from the format of the one for the outer IP headers, since
this header is part of the compressed base header. What irregular
chain items to use is determined by the argument "is_innermost",
which is passed as an argument to the corresponding encoding
method (ipv4 or ipv6). The format of the irregular chain item for
the outer IP headers is also determined using one flag for TTL/Hop
Limit and one for TOS/TC. These flags are defined in the format
of some of the compressed base headers.
RoHCv2 profiles compresses extension headers as other headers, and
thus extension headers have a static chain, a dynamic chain and an
irregular chain.
Chains are defined for all headers compressed by RoHCv2 profiles,
i.e. RTP [RFC3550], UDP [RFC0768], UDP Lite [RFC3828], IPv4
[RFC0791], IPv6 [RFC2460], AH [RFC4302], GRE [RFC2784][RFC2890], MINE
[RFC2004], NULL-encrupted ESP [RFC4303], IPv6 Destination Options
header[RFC2460], IPv6 Hop-by-hop Options header[RFC2460] and IPv6
Routing header [RFC2460].
6.6. Packet Formats and Encoding Methods
The packet formats used for are defined using the ROHC formal
notation. Some of the encoding methods used in the packet formats
are defined in [I-D.ietf-rohc-formal-notation], while other methods
are defined in this section.
6.6.1. baseheader_extension_headers
In CO packets (see Section 6.8.3), the innermost IP header can be
combined with other header(s) (i.e. UDP, UDP Lite, RTP) to create
the compressed base header. In such case, the IP header may have a
number of extension headers between itself and the other headers.
The base header defines some representation of these extension
headers, to comply with the syntax of the formal notation; this
encoding method provides this representation. The
baseheader_extension_headers encoding method skips over all fields of
the extension headers of the innermost IP header, without encoding
any of the them. Fields in these extension headers are instead
encoded in the irregular chain.
Pelletier & Sandlund Expires November 26, 2007 [Page 22]
Internet-Draft RoHCv2 Profiles May 2007
6.6.2. baseheader_outer_headers
This encoding method, similarly to the baseheader_extension_headers
encoding method above, is needed to keep the definition of the packet
formats syntactically correct. It describe tunneling IP headers and
their respective extension headers (i.e. all headers located before
the innermost IP header) for CO headers (see Section 6.8.3). The
baseheader_outer_headers encoding method skips over all the fields of
the extension header(s) that do not belong to the innermost IP
header, without encoding any of them. Changed fields in outer
headers are instead handled by the irregular chain.
6.6.3. inferred_udp_length
The UDP length field is inferred by the decompressor to be the size
of the UDP payload. This also means that the compressor MUST make
sure that the UDP length field is consistent with the length field(s)
of preceeding subheaders, i.e., there must not be any padding after
the UDP payload that is covered by the IP Length.
6.6.4. inferred_ip_v4_header_checksum
This encoding method compresses the header checksum field of the IPv4
header. This checksum is defined in RFC 791 [RFC0791] as follows:
Header Checksum: 16 bits
A checksum on the header only. Since some header fields change
(e.g., time to live), this is recomputed and verified at each
point that the internet header is processed.
The checksum algorithm is:
The checksum field is the 16 bit one's complement of the one's
complement sum of all 16 bit words in the header. For purposes
of computing the checksum, the value of the checksum field is
zero.
As described above, the header checksum protects individual hops from
processing a corrupted header. When almost all IP header information
is compressed away, and when decompression is verified by a CRC
computed over the original header for every compressed packet, there
is no point in having this additional checksum; instead it can be
recomputed at the decompressor side.
The "inferred_ip_v4_header_checksum" encoding method thus compresses
the IPv4 header checksum down to a size of zero bit, i.e. no bits are
transmitted in compressed headers for this field. Using this
Pelletier & Sandlund Expires November 26, 2007 [Page 23]
Internet-Draft RoHCv2 Profiles May 2007
encoding method, the decompressor infers the value of this field
using the computation above.
The compressor MAY use the header checksum to validate the
correctness of the header before compressing it, to avoid compressing
a corrupted header.
6.6.5. inferred_mine_header_checksum
This encoding method compresses the minimal encapsulation header
checksum. This checksum is defined in RFC 2004 [RFC2004] as follows:
Header Checksum
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
computing the checksum, the value of the checksum field is 0.
The IP header and IP payload (after the minimal forwarding
header) are not included in this checksum computation.
The "inferred_mine_header_checksum" encoding method compresses the
minimal encapsulation header checksum down to a size of zero bit,
i.e. no bits are transmitted in compressed headers for this field.
Using this encoding method, the decompressor infers the value of this
field using the above computation.
The motivations for inferring this checksum are similar to the ones
explained above in Section 6.6.4.
The compressor MAY use the minimal encapsulation header checksum to
validate the correctness of the header before compressing it, to
avoid compressing a corrupted header.
6.6.6. inferred_ip_v4_length
This encoding method compresses the total length field of the IPv4
header. The total length field of the IPv4 header is defined in RFC
791 [RFC0791] as follows:
Total Length: 16 bits
Total Length is the length of the datagram, measured in octets,
including internet header and data. This field allows the
length of a datagram to be up to 65,535 octets.
The "inferred_ip_v4_length" encoding method compresses the IPv4
header checksum down to a size of zero bit, i.e. no bits are
transmitted in compressed headers for this field. Using this
Pelletier & Sandlund Expires November 26, 2007 [Page 24]
Internet-Draft RoHCv2 Profiles May 2007
encoding method, the decompressor infers the value of this field by
counting in octets the length of the entire packet after
decompression.
6.6.7. inferred_ip_v6_length
This encoding method compresses the payload length field in the IPv6
header. This length field is defined in RFC 2460 [RFC2460] as
follows:
Payload Length: 16-bit unsigned integer
Length of the IPv6 payload, i.e., the rest of the packet
following this IPv6 header, in octets. (Note that any
extension headers present are considered part of the payload,
i.e., included in the length count.)
The "inferred_ip_v6_length" encoding method compresses the payload
length field of the IPv6 header down to a size of zero bit, i.e. no
bits are transmitted in compressed headers for this field. Using
this encoding method, the decompressor infers the value of this field
by counting in octets the length of the entire packet after
decompression.
6.6.8. Scaled RTP Timestamp Encoding
The RTP timestamp (TS) usually increases by a multiple of the RTP
Sequence Number's (SN) increase and is therefore a suitable candidate
for scaled encoding. This scaling factor is labeled ts_stride in the
definition of the profile in ROHC-FN Section 6.8. The compressor
sets the scaling factor based on the change in TS with respect to the
change in the RTP SN.
The initial value of the scaling factor ts_stride is always set to 1
[NOTE: define what is initial? New context with this profile?].
When ts_stride is set to 1, scaling is not applied on the field for
any format.
Initially, the scaling factor is set to 1, meaning that no actual
scaling is performed even in the scaled packet formats. For the
compressor to use a different scaling value, it must first explicitly
transmit the new value of ts_stride to the decompressor, using one of
the packet types that can carry this information. Once the new value
of the scaling factor is established, before using the new scaling
factor, the compressor must have enough confidence that the
decompressor has successfully calculated the residue (ts_offset) of
the scaling function for the timestamp. This is done by sending
unscaled timestamp values to allow the decompressor to establish the
Pelletier & Sandlund Expires November 26, 2007 [Page 25]
Internet-Draft RoHCv2 Profiles May 2007
residue based on the current ts_stride. The compressor MAY send the
unscaled timestamp in the same packets as the ones establishing the
new ts_stride value.
Once the compressor has gained enough confidence that both the value
of the scaling factor and the value of the residue have been
established in the decompressor, the compressor can start compressing
packets using the new scaling factor.
If the compressor notices that the residue (ts_offset) value changes,
the compressor cannot use scaled timestamp packet formats until it
has re-established the residue as described above.
If the decompressor receives a packet containing scaled timestamp
bits while the ts_stride equals zero, it MUST NOT deliver the packet
to upper layers.
When the value of the timestamp field wraps around, the value of the
residue of the scaling function is likely to change. When this
occurs, the compressor re-establishes the new residue value as
described above.
The compressor MAY use the scaled timestamp encoding; what value it
will use as the scaling factor is up to the compressor
implementation, but to achive any gains from the scaling, the
ts_stride should be set to the value of the expected incease in
timestamp between consecutive sequence numbers.
When scaled timestamp encoding is used for packet formats that do not
transmit any LSB-encoded timestamp bits at all, the Section 6.6.10 is
used for encoding the timestamp.
6.6.9. Timer-Based RTP Timestamp Encoding
Text to be added. Same encoding method as in RFC 3095, section
4.5.4.
6.6.10. inferred_scaled_field
The "inferred_scaled_field" encoding method is used to encode a field
that is defined as changing in relation to the MSN but for each
increase is scaled by an established scaling factor. This encoding
method is to be used in the case when a packet format contains MSN
bits, but does not contain any bits for the scaled field. In this
case, the new value for the field being scaled is calculated
according to the following formula:
Pelletier & Sandlund Expires November 26, 2007 [Page 26]
Internet-Draft RoHCv2 Profiles May 2007
unscaled_value = delta_msn * stride + previous_unscaled_value
Where "delta_msn" is the difference is MSN between the previous value
of MSN in the context and the value of the MSN decompressed from this
packet, "previous_unscaled_value" is the value of the field being
scaled in the context, and "stride" is the scaling value for this
field.
For example, when this encoding method is applied to the RTP
timestamp in the RTP profile, the calculation above becomes:
timestamp = delta_msn * ts_stride + previous_timestamp
6.6.11. control_crc3_encoding
The "control_crc3_encoding" method provides a CRC calculated over a
number of control fields. The definition of this encoding method is
the same as for the "crc" encoding method specified in section 4.11.6
of [I-D.ietf-rohc-formal-notation], with the difference that the data
that is covered by the CRC is given by a concatenated list of control
fields.
In other words, the definition of the control_crc3_encoding method is
equivalent to the following definition:
control_crc_encoding(data_value, data_length)
{
UNCOMPRESSED {
}
COMPRESSED {
control_crc3 =:=
crc(3, 0x06, 0x07, ctrl_data_value, ctrl_data_length) [ 3 ];
}
}
where the parameter "ctrl_data_value" binds to the concatenated
values of the following control fields, in the order listed below:
o reorder_ratio, 2 bits padded by 6 MSB of zeroes
o ts_stride, 16 bits (applicable only for profiles 0x0101 and
0x0107)
o msn,16 bits (not applicable for profiles 0x0101 and 0x0107)
The "ctrl_data_length" binds to the sum of the length of the control
field(s) that are applicable.
A 3-bit CRC is used to validate the control fields that are updated
by the co_common and co_repair packet types; it cannot verify the
outcome of a decompression attempt. The definition of this CRC comes
Pelletier & Sandlund Expires November 26, 2007 [Page 27]
Internet-Draft RoHCv2 Profiles May 2007
from the fact that the decompression of a header that carries and
updates control fields does not necessarily make use of these control
fields, and the update to the control fields is thus not protected by
the CRC-7 validation.
For example, without a verification of the updates to the control
fields, there would be a possibility that a decompression attempt
succeeds for a co_common or for a co_repair packet for which the
decompressor would send a positive feedback, even in the case where
one of the control fields had been corrupted on the link between the
compression endpoints.
6.6.12. inferred_sequential_ip_id
This encoding method is used when a sequential IP-ID behavior is used
(sequential or sequential byte-swapped) and no coded IP-ID bits are
present in the compressed header. When these packet types are used,
the IP-ID offset from the MSN will be constant, and therefore, the
IP-ID will increase by the same amount as the MSN increases by
(similar to the inferred_scaled_field encoding method).
Therefore, the new value for the IP-ID is calculated according to the
following formula:
IP-ID = delta_msn + previous_IP_ID_value
Where "delta_msn" is the difference is MSN between the previous value
of MSN in the context and the value of the MSN decompressed from this
packet, "previous_IP_ID_value" is the value of the IP-ID in the
context.
If the IP-ID behavior is random or zero, this encoding method does
not update any fields.
6.6.13. list_csrc(cc_value)
This encoding method describes how the list of CSRC identifiers can
be compressed using list compression. This list compression operates
by establishing content for the different CSRC identifiers (items)
and list describing the order that they appear.
The argument to this encoding method (cc_value) is the CC field from
the RTP header which the compressor passes to this encoding method.
The decompressor is required to bind the value of this argument to
the number of items in the list, which will allow the decompressor to
corectly reconstruct the CC field.
Pelletier & Sandlund Expires November 26, 2007 [Page 28]
Internet-Draft RoHCv2 Profiles May 2007
6.6.13.1. List Compression
The CSRC identifiers in the uncompressed packet can be represented as
an ordered list, whose order and presence are usually constant
between packets. The generic structure of such a list is as follows:
+--------+--------+--...--+--------+
list: | item 1 | item 2 | | item n |
+--------+--------+--...--+--------+
When performing list compression on a CSRC list, each item is the
uncompressed value of one CSRC identifier.
The basic principles of list-based compression are the following:
1) When a context is being initialized, a complete representation
of the compressed list of options is transmitted. All items that
have any content are present in the compressed list of items sent
by the compressor.
Then, once the context has been initialized:
2) When the structure of the list is unchanged no information
about the list is sent in compressed headers.
3) When the structure of the list changes, a compressed list is
sent in the compressed header, including a representation of its
structure and order. Previously unknown items are sent
uncompressed in the list, while previously known items are only
represented by an index pointing to the context.
6.6.13.2. Table-based Item Compression
The Table-based item compression compresses individual items sent in
compressed lists. The compressor assigns a unique identifier,
"Index", to each item "Item" of a list.
Compressor Logic
The compressor conceptually maintains an Item Table containing all
items, indexed using "Index". The (Index, Item) pair is sent
together in compressed lists until the compressor gains enough
confidence that the decompressor has observed the mapping between
items and their respective index. Confidence is obtained from the
reception of an acknowledgment from the decompressor, or by
sending (Index, Item) pairs using the optimistic approach. Once
confidence is obtained, the index alone is sent in compressed
lists to indicate the presence of the item corresponding to this
index.
Pelletier & Sandlund Expires November 26, 2007 [Page 29]
Internet-Draft RoHCv2 Profiles May 2007
The compressor may reassign an existing index to a new item, by
re-establishing the mapping using the procedure described above.
Decompressor Logic
The decompressor conceptually maintains an Item Table that
contains all (Index, Item) pairs received. The Item Table is
updated whenever an (Index, Item) pair is received and
decompression is successfully verified using the CRC. The
decompressor retrieves the item from the table whenever an Index
without an accompanying Item is received.
If an index without an accompanying item is received and the
decompressor does not have any context for this index, the packet
MUST NOT be delivered to upper layers.
6.6.13.3. Encoding of Compressed Lists
Each item present in a compressed list is represented by:
o an index into the table of items, and
o a presence bit indicating if a compressed representation of the
item is present in the list.
o an item (if the presence bit is set)
If the presence bit is not set, the item must already be known by the
decompressor.
A compressed list of items uses the following encoding:
0 1 2 3 4 5 6 7
+---+---+---+---+---+---+---+---+
| Reserved |PS | m |
+---+---+---+---+---+---+---+---+
| XI_1, ..., XI_m | m octets, or m * 4 bits
/ --- --- --- ---/
| : Padding : if PS = 0 and m is odd
+---+---+---+---+---+---+---+---+
| |
/ item_1, ..., item_n / variable
| |
+---+---+---+---+---+---+---+---+
Reserved: Must be set to zero.
Pelletier & Sandlund Expires November 26, 2007 [Page 30]
Internet-Draft RoHCv2 Profiles May 2007
PS: Indicates size of XI fields:
PS = 0 indicates 4-bit XI fields;
PS = 1 indicates 8-bit XI fields.
m: Number of XI item(s) in the compressed list. Also the value of
the cc_value argument.
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
appear in the uncompressed header.
The format of an XI item is as follows:
+---+---+---+---+
PS = 0: | X | Index |
+---+---+---+---+
0 1 2 3 4 5 6 7
+---+---+---+---+---+---+---+---+
PS = 1: | X | Reserved | Index |
+---+---+---+---+---+---+---+---+
X: Indicates whether the item present in the list:
X = 1 indicates that the item corresponding to the Index is
sent in the item_1, ..., item_n list;
X = 0 indicates that the item corresponding to the Index is
not sent.
Reserved: Set to zero when sending, ignored when received.
Index: An index into the item table. See Section 6.6.13.4
When 4-bit XI items are used and, the XI items are placed in
octets in the following manner:
0 1 2 3 4 5 6 7
+---+---+---+---+---+---+---+---+
| XI_k | XI_k + 1 |
+---+---+---+---+---+---+---+---+
Pelletier & Sandlund Expires November 26, 2007 [Page 31]
Internet-Draft RoHCv2 Profiles May 2007
Padding: A 4-bit padding field is present when PS = 0 and the
number of XIs is odd. The Padding field is set to zero when
sending and ignored when receiving.
Item 1, ..., item n: Each item corresponds to an XI with X = 1 in
XI 1, ..., XI m. Each entry in the item list is the uncompressed
representation of one CSRC identifier.
6.6.13.4. Item Table Mappings
The item table for list compression is limited to 16 different items,
since the RTP header can only carry at most 15 simultaneous CSRC
identifiers. The effect of having more than 16 items will only cause
a slight overhead to the compressor when items are swappen in/out of
the item table.
6.6.13.5. Compressed Lists in Dynamic Chain
A compressed list that is part of the dynamic chain (e.g. in IR
packets) must have all its 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 in the list decompressed from this packet
MUST also be retained in the decompressor context.
6.7. Encoding Methods With External Parameters
A number of encoding methods in Section 6.8.3.2 have one or more
arguments for which the derivation of the parameter's value is
outside the scope of the ROHC-FN specification of the header formats.
This section lists the encoding methods together with a definition of
each of their parameters.
o ip_dest_opt(repair_flag):
repair_flag: This parameter must be set to the value that was
used for the corresponding "repair_flag" parameter of the
"[profilename]_baseheader" encoding method when extracting the
irregular chain for a compressed header; otherwise it is set to
zero and ignored for other types of chains.
o ip_hop_opt(repair_flag):
See definition of arguments for "ip_dest_opt" above.
o gre(repair_flag):
Pelletier & Sandlund Expires November 26, 2007 [Page 32]
Internet-Draft RoHCv2 Profiles May 2007
See definition of arguments for "ip_dest_opt" above.
o ah(repair_flag):
See definition of arguments for "ip_dest_opt" above.
o esp_null(next_header_value, repair_flag):
next_header_value: Set to the value of the Next Header field
located in the ESP trailer, usually 12 octets from the end of
the packet. Compression of null-encrypted ESP headers should
only be performed when the compressor has prior knowledge of
the exact location of the next header field.
repair_flag: This parameter must be set to the value that was
used for the corresponding "repair_flag" parameter of the
"[profilename]_baseheader" encoding method when extracting the
irregular chain for a compressed header; otherwise it is set to
zero and ignored for other types of chains.
o ipv6(profile, is_innermost, ip_outer_flag, repair_flag)):
profile: Set to the profile number of the profile used to
compress this packet.
is_innermost: This boolean flag is set to 1 when processing the
innermost IP header; otherwise it is set to 0.
repair_flag: This parameter must be set to the value that was
used for the corresponding "repair_flag" parameter of the
"[profilename]_baseheader" encoding method when extracting the
irregular chain for a compressed header; otherwise it is set to
zero and ignored for other types of chains.
o ipv4(profile, is_innermost, ip_outer_flag, repair_flag)
See definition of arguments for "ipv6" above.
o udp(profile)
profile: Set to the profile number of the profile used to
compress this packet.
o rtp(profile, ts_stride_value, time_stride_value)
Pelletier & Sandlund Expires November 26, 2007 [Page 33]
Internet-Draft RoHCv2 Profiles May 2007
profile: Set to the profile number of the profile used to
compress this packet.
ts_stride_value: This parameter is set to a user-selected value
that is the expected increase in the RTP Timestamp between
consecutive sequence numbers. See also Section 6.6.8.
time_stride_value: This parameter is set to a user-selected
value that is the expected inter-arrival time between
consecutive packets for this flow. See also Section 6.6.9.
o esp(profile)
profile: Set to the profile number of the profile used to
compress this packet.
o udp_lite(profile)
profile: Set to the profile number of the profile used to
compress this packet.
o rtp_baseheader(profile, ts_stride_value, time_stride_value,
outer_ip_flag, repair_flag):
profile: Set to the profile number of the profile used to
compress this packet.
ts_stride_value: This parameter is set to a user-selected value
that is the expected increase in the RTP Timestamp between
consecutive sequence numbers. See also Section 6.6.8.
time_stride_value: This parameter is set to a user-selected
value that is the expected inter-arrival time between
consecutive packets for this flow. See also Section 6.6.9.
outer_ip_flag: This parameter is set to 1 of one or more of a a
number of semi-static fields in outer IP headers have changed
compared to their reference values in the context, otherwise it
is set to 0. The value used for this parameter is also used
for the "outer_ip_flag" argument for a number of encoding
methods defined above, when these are processing the irregular
chain. This flag may only be set to 1 either for the
"co_common" or the "co_repair" packet formats in the different
profiles.
Pelletier & Sandlund Expires November 26, 2007 [Page 34]
Internet-Draft RoHCv2 Profiles May 2007
repair_flag: This parameter is set to 1 if the certain fields
in extension headers or outer IP headers have changed compared
to their reference values in the context, otherwise it is set
to 0. The value used for this parameter is also used for the
"repair_flag" argument for a number of encoding methods defined
above, when these are processing the irregular chain. This may
only be set to 1 for the "co_repair" packet formats in the
different profiles.
o udp_baseheader(profile, outer_ip_flag, repair_flag):
profile: Set to the profile number of the profile used to
compress this packet.
outer_ip_flag: This parameter is set to 1 of one or more of a a
number of semi-static fields in outer IP headers have changed
compared to their reference values in the context, otherwise it
is set to 0. The value used for this parameter is also used
for the "outer_ip_flag" argument for a number of encoding
methods defined above, when these are processing the irregular
chain. This flag may only be set to 1 either for the
"co_common" or the "co_repair" packet formats in the different
profiles.
repair_flag: This parameter is set to 1 if the certain fields
in extension headers or outer IP headers have changed compared
to their reference values in the context, otherwise it is set
to 0. The value used for this parameter is also used for the
"repair_flag" argument for a number of encoding methods defined
above, when these are processing the irregular chain. This may
only be set to 1 for the "co_repair" packet formats in the
different profiles.
o esp_baseheader(profile, outer_ip_flag, repair_flag):
See definition of arguments for "udp_baseheader" above.
o iponly_baseheader(profile, outer_ip_flag, repair_flag):
See definition of arguments for "udp_baseheader" above.
o udplite_rtp_baseheader(profile, ts_stride_value,
time_stride_value, outer_ip_flag, repair_flag):
Pelletier & Sandlund Expires November 26, 2007 [Page 35]
Internet-Draft RoHCv2 Profiles May 2007
See definition of arguments for "rtp_baseheader" above.
o udplite_baseheader(profile, outer_ip_flag, repair_flag):
See definition of arguments for "udp_baseheader" above.
6.8. Packet Formats
ROHCv2 profiles use two different packet types: the Initialization
and Refresh (IR) packet type, and the Compressed packet type (CO).
Each packet type defines a number of packet formats: two packet
formats are defined for the IR type, and two sets base header formats
are defined for the CO type with one additional format that is common
to both sets.
When the number of bits available in compressed header fields exceeds
the number of bits in the value, the most significant field is padded
with zeroes in its most significant bits.
Updating Properties: all packet types carry a CRC and are context
updating. Packets update the entire context besides the fields for
which they explicitly convey information for, since the context can
be expressed as the collection of the reference value of each field
together with the function established with respect to the MSN.
6.8.1. Initialization and Refresh Packet (IR)
The IR packet format uses the structure of the ROHC IR packet as
defined in [I-D.ietf-rohc-rfc3095bis-framework], section 5.2.2.1.
Packet type: IR
This packet type communicates the static part and the dynamic part
of the context.
Pelletier & Sandlund Expires November 26, 2007 [Page 36]
Internet-Draft RoHCv2 Profiles May 2007
The ROHCv2 IR packet has the following format:
0 1 2 3 4 5 6 7
--- --- --- --- --- --- --- ---
: Add-CID octet : if for small CIDs and (CID != 0)
+---+---+---+---+---+---+---+---+
| 1 1 1 1 1 1 0 1 | IR type octet
+---+---+---+---+---+---+---+---+
: :
/ 0-2 octets of CID / 1-2 octets if for large CIDs
: :
+---+---+---+---+---+---+---+---+
| Profile | 1 octet
+---+---+---+---+---+---+---+---+
| CRC | 1 octet
+---+---+---+---+---+---+---+---+
| |
/ Static chain / variable length
| |
- - - - - - - - - - - - - - - -
| |
/ Dynamic chain / variable length
| |
- - - - - - - - - - - - - - - -
| |
/ Payload / variable length
| |
- - - - - - - - - - - - - - - -
Static chain: See Section 6.5.
Dynamic chain: See Section 6.5.
Payload: The payload of the corresponding original packet, if any.
The presence of a payload is inferred from the packet length.
6.8.2. IR Packet Payload Discard (IR-PD)
The IR-PD packet format uses the structure of the ROHC IR packet as
defined in [I-D.ietf-rohc-rfc3095bis-framework], section 5.2.2.1.
Packet type: IR-PD
Pelletier & Sandlund Expires November 26, 2007 [Page 37]
Internet-Draft RoHCv2 Profiles May 2007
This packet type communicates the static part and the dynamic part
of the context, but without the payload of the original packet for
which it carries the header information.
The ROHCv2 IR packet has the following format:
0 1 2 3 4 5 6 7
--- --- --- --- --- --- --- ---
: Add-CID octet : if for small CIDs and (CID != 0)
+---+---+---+---+---+---+---+---+
| 1 1 1 1 1 1 0 0 | IR type octet
+---+---+---+---+---+---+---+---+
: :
/ 0-2 octets of CID / 1-2 octets if for large CIDs
: :
+---+---+---+---+---+---+---+---+
| Profile | 1 octet
+---+---+---+---+---+---+---+---+
| CRC | 1 octet
+---+---+---+---+---+---+---+---+
| |
/ Static chain / variable length
| |
- - - - - - - - - - - - - - - -
| |
/ Dynamic chain / variable length
| |
- - - - - - - - - - - - - - - -
Static chain: See Section 6.5.
Dynamic chain: See Section 6.5.
6.8.3. Compressed Packet Formats (CO)
6.8.3.1. Design rationale for compressed base headers
The compressed packet formats are defined as two separate sets for
each profile: one set for the packets where the innermost IP header
contains a sequential IP-ID (either network byte order or byte
swapped), and one set for the packets without sequential IP-ID
(either random, zero, or no IP-ID).
The design of the packet formats is derived from the field behavior
analysis found in Appendix A.
All of the compressed base headers transmit LSB-encoded MSN bits and
Pelletier & Sandlund Expires November 26, 2007 [Page 38]
Internet-Draft RoHCv2 Profiles May 2007
a CRC.
The following packet formats exist for all profiles defined in this
document, both for the sequential and random packet format sets:
o co_common: The common packet format is designed so that it can be
used for chagnes to all the dynamic fields in the context, but can
not always transmit all these fields uncompressed can be used. It
is therefore useful for when some of the more rarely changing
fields in the headers change. Since this packet format may modify
the value of the control fields that determine how the
decompressor interprets different compressed header format, it
carries a 7-bit CRC to reduce the probability of context
corruption. This packet format uses a large set of flags to
provide information about which fields are present in the packet
format and can therefore be of very varied size.
o co_repair: This format is very similar to the co_common format
described above. The difference is that this packet is intended
to be used when context damage has been assumed, and therefore
changing fields are transmit uncompressed when present in this
format. This format also contains some options to transmit semi-
static fields from extension headers which cannot be transmit with
the co_common format. This packet format should be considered a
replacement for the IR-DYN packet format which is not defined for
the profiles defined in this document.
o pt_0_crc3: This packet format only transmit the MSN, and can
therefore only be used to update the MSN and fields that are
derived from the MSN, such as IP-ID and the RTP Timestamp (where
applicable). This packet format is equivalent to the UO-0 packet
format in [RFC3095]
o pt_0_crc7: This packet has the same properties as pt_0_crc3, but
is instead protected by a 7-bit CRC and contains a larger amount
of LSB-encoded MSN bits. This format is intended to be used for
the compressor to transmit from IC state to FC state (see
Section 5.3.1 or it can be used on ROHC channels that expect a
high amount of reordering.
The following packet formats exist exclusively for profiles 0x101 and
0x107.
o pt_1_rnd: This format is a replacement for the UO-1 packet format
in [RFC3095] and can be used to transmit changes in the MSN, RTP
Marker bit and it can update the RTP timestamp using scaled
timestamp encoding.
Pelletier & Sandlund Expires November 26, 2007 [Page 39]
Internet-Draft RoHCv2 Profiles May 2007
o pt_1_seq_id: This format is a replacement for the UO-1-ID packet
format in [RFC3095] and can be used to transmit changes in the MSN
and IP-ID.
o pt_1_seq_ts: This format is a replacement for the UO-1-TS packet
format in [RFC3095] and can be used to transmit changes in the
MSN, RTP Marker bit and can update the RTP Timestamp using scaled
timestamp encoding.
o pt_2_rnd: This format is a replacement for the UOR-2 packet format
in [RFC3095] and can be used to transmit changes in the MSN, RTP
Marker bit and the RTP Timestamp, and is protected by a 7-bit CRC.
o pt_2_seq_id: This format is a replacement for the UO-2-ID packet
format in [RFC3095] and can be used to transmit changes in the MSN
and IP-ID. This format is also protected by a 7-bit CRC.
o pt_2_seq_ts: This format is a replacement for the UO-2-TS packet
format in [RFC3095] and can be used to transmit changes in the
MSN, RTP Marker bit and can update the RTP Timestamp using scaled
timestamp encoding. This format is also protected by a 7-bit CRC.
o pt_2_seq_both: This format is replaces the UOR-2-ID extension 1
format in [RFC3095] and can carry changes in both the RTP
Timestamp and IP-ID in addition to the MSN and Marker bit.
The following packet formats exist exclusively for profiles 0x102,
0x103, 0x104 and 0x108.
o pt_1_seq_id: This format is a replacement for the UO-1-ID packet
format in [RFC3095] and can be used to transmit changes in the MSN
and IP-ID.
o pt_2_rnd: This format is a replacement for the UOR-2 packet format
in [RFC3095] and can be used to transmit changes in the MSN and is
protected by a 7-bit CRC.
o pt_2_seq_id: This format is a replacement for the UO-2-ID packet
format in [RFC3095] and can be used to transmit changes in the MSN
and IP-ID. This format is also protected by a 7-bit CRC.
6.8.3.2. General CO Header Format
The CO packets communicate irregularities in the packet header. All
CO packets carry a CRC and can update the context.
Pelletier & Sandlund Expires November 26, 2007 [Page 40]
Internet-Draft RoHCv2 Profiles May 2007
The general format for a compressed header is as follows:
0 1 2 3 4 5 6 7
--- --- --- --- --- --- --- ---
: Add-CID octet : if for small CIDs and CID 1-15
+---+---+---+---+---+---+---+---+
| first octet of base header | (with type indication)
+---+---+---+---+---+---+---+---+
: :
/ 0, 1, or 2 octets of CID / 1-2 octets if large CIDs
: :
+---+---+---+---+---+---+---+---+
/ remainder of base header / variable number of octets
+---+---+---+---+---+---+---+---+
: :
/ Irregular Chain / variable
: :
--- --- --- --- --- --- --- ---
The base header in the figure above is the compressed representation
of the innermost IP header and other header(s), if any, in the
uncompressed packet.
Upon receiving other types of packet, the decompressor will
decompress it. The decompressor MUST verify the correctness of the
decompressed packet by CRC check. If this verification succeeds, the
decompressor passes the decompressed packet to the system's network
layer. The decompressor will then use this packet as the reference
packet.
The entire set of base headers are defined using the ROHC Formal
notation [I-D.ietf-rohc-formal-notation] in the remainder of this
section.
// TODO:
// - PT_0/PT_1 packets? Use "tbc-optimized" or "msn-optimized"
////////////////////////////////////////////
// Constants
////////////////////////////////////////////
// IP-ID behavior constants
IP_ID_BEHAVIOR_SEQUENTIAL = 0;
IP_ID_BEHAVIOR_SEQUENTIAL_SWAPPED = 1;
IP_ID_BEHAVIOR_RANDOM = 2;
IP_ID_BEHAVIOR_ZERO = 3;
// UDP-lite checksum coverage behavior constants
Pelletier & Sandlund Expires November 26, 2007 [Page 41]
Internet-Draft RoHCv2 Profiles May 2007
UDP_LITE_COVERAGE_INFERRED = 0;
UDP_LITE_COVERAGE_STATIC = 1;
UDP_LITE_COVERAGE_IRREGULAR = 2;
UDP_LITE_COVERAGE_RESERVED = 3;
// Variable reordering offset
REORDERING_NONE = 0;
REORDERING_QUARTER = 1;
REORDERING_HALF = 2;
REORDERING_THREEQUARTERS = 3;
// Profile names and versions
PROFILE_RTP_0101 = 0x0101;
PROFILE_UDP_0102 = 0x0102;
PROFILE_ESP_0103 = 0x0103;
PROFILE_IP_0104 = 0x0104;
PROFILE_RTP_0107 = 0x0107; // With UDP-LITE
PROFILE_UDPLITE_0108 = 0x0108; // Without RTP
////////////////////////////////////////////
// Global control fields
////////////////////////////////////////////
CONTROL {
msn [ 16 ];
reorder_ratio [ 2 ];
}
///////////////////////////////////////////////
// Encoding methods not specified in FN syntax:
///////////////////////////////////////////////
baseheader_extension_headers "defined in Section X.Y.Z";
baseheader_outer_headers "defined in Section X.Y.Z";
inferred_udp_length "defined in Section X.Y.Z";
inferred_ip_v4_header_checksum "defined in Section X.Y.Z";
inferred_mine_header_checksum "defined in Section X.Y.Z";
inferred_ip_v4_length "defined in Section X.Y.Z";
inferred_ip_v6_length "defined in Section X.Y.Z";
list_csrc(cc_value) "defined in Section X.Y.Z";
inferred_scaled_field "defined in Section X.Y.Z";
inferred_sequential_ip_id "defined in Section X.Y.Z";
control_crc3_encoding "defined in Section X.Y.Z";
timer_based_lsb(time_stride, k, p) "defined in Section X.Y.Z";
////////////////////////////////////////////
// General encoding methods
////////////////////////////////////////////
Pelletier & Sandlund Expires November 26, 2007 [Page 42]
Internet-Draft RoHCv2 Profiles May 2007
reorder_choice
{
UNCOMPRESSED {
ratio [ 2 ];
}
DEFAULT {
ratio =:= irregular(2);
}
COMPRESSED none {
ENFORCE(ratio.UVALUE == REORDERING_NONE);
ratio [ 2 ];
}
COMPRESSED quarter {
ENFORCE(ratio.UVALUE == REORDERING_QUARTER);
ratio [ 2 ];
}
COMPRESSED half {
ENFORCE(ratio.UVALUE == REORDERING_HALF);
ratio [ 2 ];
}
COMPRESSED three_quarters {
ENFORCE(ratio.UVALUE == REORDERING_THREEQUARTERS);
ratio [ 2 ];
}
}
static_or_irreg(flag, width)
{
UNCOMPRESSED {
field [ width ];
}
COMPRESSED irreg_enc {
ENFORCE(flag == 1);
field =:= irregular(width) [ width ];
}
COMPRESSED static_enc {
ENFORCE(flag == 0);
field =:= static [ 0 ];
}
}
Pelletier & Sandlund Expires November 26, 2007 [Page 43]
Internet-Draft RoHCv2 Profiles May 2007
optional_32(flag)
{
UNCOMPRESSED {
item [ 0, 32 ];
}
COMPRESSED present {
ENFORCE(flag == 1);
item =:= irregular(32) [ 32 ];
}
COMPRESSED not_present {
ENFORCE(flag == 0);
item =:= compressed_value(0, 0) [ 0 ];
}
}
sdvl_or_static(flag)
{
UNCOMPRESSED {
field [ 32 ];
}
COMPRESSED present_7bit {
ENFORCE(flag == 1);
ENFORCE(field.UVALUE < 2^7);
ENFORCE(field.CVALUE == field.UVALUE);
discriminator =:= '0' [ 1 ];
field [ 7 ];
}
COMPRESSED present_14bit {
ENFORCE(flag == 1);
ENFORCE(field.UVALUE < 2^14);
ENFORCE(field.CVALUE == field.UVALUE);
discriminator =:= '10' [ 2 ];
field [ 14 ];
}
COMPRESSED present_21bit {
ENFORCE(flag == 1);
ENFORCE(field.UVALUE < 2^21);
ENFORCE(field.CVALUE == field.UVALUE);
discriminator =:= '110' [ 3 ];
field [ 21 ];
}
COMPRESSED present_28bit {
Pelletier & Sandlund Expires November 26, 2007 [Page 44]
Internet-Draft RoHCv2 Profiles May 2007
ENFORCE(flag == 1);
ENFORCE(field.UVALUE < 2^28);
ENFORCE(field.CVALUE == field.UVALUE);
discriminator =:= '1110' [ 4 ];
field [ 28 ];
}
COMPRESSED present_32bit {
ENFORCE(flag == 1);
ENFORCE(field.CVALUE == field.UVALUE);
discriminator =:= '11111111' [ 8 ];
field [ 32 ];
}
COMPRESSED not_present {
ENFORCE(flag == 0);
field =:= static;
}
}
lsb_7_or_31
{
UNCOMPRESSED {
item [ 32 ];
}
COMPRESSED lsb_7 {
discriminator =:= '0' [ 1 ];
item =:= lsb(7, ((2^7) / 4) - 1) [ 7 ];
}
COMPRESSED lsb_31 {
discriminator =:= '1' [ 1 ];
item =:= lsb(31, ((2^31) / 4) - 1) [ 31 ];
}
}
crc3(data_value, data_length)
{
UNCOMPRESSED {
}
COMPRESSED {
crc_value =:= crc(3, 0x06, 0x07, data_value, data_length) [ 3 ];
}
}
crc7(data_value, data_length)
Pelletier & Sandlund Expires November 26, 2007 [Page 45]
Internet-Draft RoHCv2 Profiles May 2007
{
UNCOMPRESSED {
}
COMPRESSED {
crc_value =:= crc(7, 0x79, 0x7f, data_value, data_length) [ 7 ];
}
}
// Encoding method for updating a scaled field and its associated
// control fields. Should be used both when the value is scaled
// or unscaled in a compressed format.
field_scaling(stride_value, scaled_value, unscaled_value)
{
UNCOMPRESSED {
residue_field [ 32 ];
}
COMPRESSED no_scaling {
ENFORCE(stride_value == 0);
ENFORCE(residue_field.UVALUE == unscaled_value);
ENFORCE(scaled_value == 0);
}
COMPRESSED scaling_used {
ENFORCE(stride_value != 0);
ENFORCE(residue_field.UVALUE == (unscaled_value % stride_value));
ENFORCE(unscaled_value ==
scaled_value * stride_value + residue_field.UVALUE);
}
}
////////////////////////////////////////////
// IPv6 Destination options header
////////////////////////////////////////////
ip_dest_opt(repair_flag)
{
UNCOMPRESSED {
next_header [ 8 ];
length [ 8 ];
value [ length.UVALUE * 64 + 48 ];
}
DEFAULT {
length =:= static;
next_header =:= static;
value =:= static;
Pelletier & Sandlund Expires November 26, 2007 [Page 46]
Internet-Draft RoHCv2 Profiles May 2007
}
COMPRESSED dest_opt_static {
next_header =:= irregular(8) [ 8 ];
length =:= irregular(8) [ 8 ];
}
COMPRESSED dest_opt_dynamic {
value =:=
irregular(length.UVALUE * 64 + 48) [ length.UVALUE * 64 + 48 ];
}
COMPRESSED dest_opt_irregular {
ENFORCE(repair_flag == 0);
}
COMPRESSED dest_opt_repair_irregular {
ENFORCE(repair_flag == 1);
value =:=
irregular(length.UVALUE * 64 + 48) [ length.UVALUE * 64 + 48 ];
}
}
////////////////////////////////////////////
// IPv6 Hop-by-Hop options header
////////////////////////////////////////////
ip_hop_opt(repair_flag)
{
UNCOMPRESSED {
next_header [ 8 ];
length [ 8 ];
value [ length.UVALUE * 64 + 48 ];
}
DEFAULT {
length =:= static;
next_header =:= static;
value =:= static;
}
COMPRESSED hop_opt_static {
next_header =:= irregular(8) [ 8 ];
length =:= irregular(8) [ 8 ];
}
COMPRESSED hop_opt_dynamic {
value =:=
Pelletier & Sandlund Expires November 26, 2007 [Page 47]
Internet-Draft RoHCv2 Profiles May 2007
irregular(length.UVALUE*64+48) [ length.UVALUE * 64 + 48 ];
}
COMPRESSED hop_opt_irregular {
ENFORCE(repair_flag == 0);
}
COMPRESSED hop_opt_repair_irregular {
ENFORCE(repair_flag == 1);
value =:=
irregular(length.UVALUE * 64 + 48) [ length.UVALUE * 64 + 48 ];
}
}
////////////////////////////////////////////
// IPv6 Routing header
////////////////////////////////////////////
ip_rout_opt
{
UNCOMPRESSED {
next_header [ 8 ];
length [ 8 ];
value [ length.UVALUE * 64 + 48 ];
}
DEFAULT {
length =:= static;
next_header =:= static;
value =:= static;
}
COMPRESSED rout_opt_static {
next_header =:= irregular(8) [ 8 ];
length =:= irregular(8) [ 8 ];
value =:=
irregular(length.UVALUE*64+48) [ length.UVALUE * 64 + 48 ];
}
COMPRESSED rout_opt_dynamic {
}
COMPRESSED rout_opt_irregular {
}
}
////////////////////////////////////////////
// GRE Header
Pelletier & Sandlund Expires November 26, 2007 [Page 48]
Internet-Draft RoHCv2 Profiles May 2007
////////////////////////////////////////////
optional_lsb_7_or_31(flag)
{
UNCOMPRESSED {
item [ 0, 32 ];
}
COMPRESSED present {
ENFORCE(flag == 1);
item =:= lsb_7_or_31 [ 8, 32 ];
}
COMPRESSED not_present {
ENFORCE(flag == 0);
item =:= compressed_value(0, 0) [ 0 ];
}
}
optional_checksum(flag_value)
{
UNCOMPRESSED {
value [ 0, 16 ];
reserved1 [ 0, 16 ];
}
COMPRESSED cs_present {
ENFORCE(flag_value == 1);
value =:= irregular(16) [ 16 ];
reserved1 =:= uncompressed_value(16, 0) [ 0 ];
}
COMPRESSED not_present {
ENFORCE(flag_value == 0);
value =:= compressed_value(0, 0) [ 0 ];
reserved1 =:= compressed_value(0, 0) [ 0 ];
}
}
gre_proto
{
UNCOMPRESSED {
protocol [ 16 ];
}
COMPRESSED ether_v4 {
discriminator =:= compressed_value(1, 0) [ 1 ];
protocol =:= uncompressed_value(16, 0x0800) [ 0 ];
Pelletier & Sandlund Expires November 26, 2007 [Page 49]
Internet-Draft RoHCv2 Profiles May 2007
}
COMPRESSED ether_v6 {
discriminator =:= compressed_value(1, 1) [ 1 ];
protocol =:= uncompressed_value(16, 0x86DD) [ 0 ];
}
}
gre(repair_flag)
{
UNCOMPRESSED {
c_flag [ 1 ];
r_flag =:= uncompressed_value(1, 0) [ 1 ];
k_flag [ 1 ];
s_flag [ 1 ];
reserved0 =:= uncompressed_value(9, 0) [ 9 ];
version =:= uncompressed_value(3, 0) [ 3 ];
protocol [ 16 ];
checksum_and_res [ 0, 32 ];
key [ 0, 32 ];
sequence_number [ 0, 32 ];
}
DEFAULT {
c_flag =:= static;
k_flag =:= static;
s_flag =:= static;
protocol =:= static;
key =:= static;
sequence_number =:= static;
}
COMPRESSED gre_static {
protocol =:= gre_proto [ 1 ];
c_flag =:= irregular(1) [ 1 ];
k_flag =:= irregular(1) [ 1 ];
s_flag =:= irregular(1) [ 1 ];
padding =:= compressed_value(4, 0) [ 4 ];
key =:= optional_32(k_flag.UVALUE) [ 0, 32 ];
}
COMPRESSED gre_dynamic {
checksum_and_res =:=
optional_checksum(c_flag.UVALUE) [ 0, 16 ];
sequence_number =:= optional_32(s_flag.UVALUE) [ 0, 32 ];
}
COMPRESSED gre_irregular {
Pelletier & Sandlund Expires November 26, 2007 [Page 50]
Internet-Draft RoHCv2 Profiles May 2007
ENFORCE(repair_flag == 0);
checksum_and_res =:= optional_checksum(c_flag.UVALUE) [ 0, 16 ];
sequence_number =:=
optional_lsb_7_or_31(s_flag.UVALUE) [ 0, 8, 32 ];
}
COMPRESSED gre_repair_irregular {
ENFORCE(repair_flag == 1);
checksum_and_res =:= optional_checksum(c_flag.UVALUE) [ 0, 16 ];
sequence_number =:= optional_32(s_flag.UVALUE) [ 0, 32 ];
}
}
/////////////////////////////////////////////
// MINE header
/////////////////////////////////////////////
mine
{
UNCOMPRESSED {
next_header [ 8 ];
s_bit [ 1 ];
res_bits [ 7 ];
checksum [ 16 ];
orig_dest [ 32 ];
orig_src [ 0, 32 ];
}
DEFAULT {
next_header =:= static;
s_bit =:= static;
res_bits =:= static;
checksum =:= inferred_mine_header_checksum;
orig_dest =:= static;
orig_src =:= static;
}
COMPRESSED mine_static {
next_header =:= irregular(8) [ 8 ];
s_bit =:= irregular(1) [ 1 ];
// Reserved bits are included to achieve byte-alignment
res_bits =:= irregular(7) [ 7 ];
orig_dest =:= irregular(32) [ 32 ];
orig_src =:= optional_32(s_bit.UVALUE) [ 0, 32 ];
}
COMPRESSED mine_dynamic {
}
Pelletier & Sandlund Expires November 26, 2007 [Page 51]
Internet-Draft RoHCv2 Profiles May 2007
COMPRESSED mine_irregular {
}
}
/////////////////////////////////////////////
// Authentication Header (AH)
/////////////////////////////////////////////
ah(repair_flag)
{
UNCOMPRESSED {
next_header [ 8 ];
length [ 8 ];
res_bits [ 16 ];
spi [ 32 ];
sequence_number [ 32 ];
auth_data [ length.UVALUE*32-32 ];
}
DEFAULT {
next_header =:= static;
length =:= static;
res_bits =:= static;
spi =:= static;
sequence_number =:= static;
}
COMPRESSED ah_static {
next_header =:= irregular(8) [ 8 ];
length =:= irregular(8) [ 8 ];
spi =:= irregular(32) [ 32 ];
}
COMPRESSED ah_dynamic {
sequence_number =:= irregular(32) [ 32 ];
auth_data =:=
irregular(length.UVALUE*32-32) [ length.UVALUE*32-32 ];
}
COMPRESSED ah_irregular {
ENFORCE(repair_flag == 0);
sequence_number =:= lsb_7_or_31 [ 8, 32 ];
auth_data =:=
irregular(length.UVALUE*32-32) [ length.UVALUE*32-32 ];
}
COMPRESSED ah_repair_irregular {
ENFORCE(repair_flag == 1);
Pelletier & Sandlund Expires November 26, 2007 [Page 52]
Internet-Draft RoHCv2 Profiles May 2007
res_bits =:= irregular(16) [ 16 ];
sequence_number =:= irregular(32) [ 32 ];
auth_data =:=
irregular(length.UVALUE*32-32) [ length.UVALUE*32-32 ];
}
}
/////////////////////////////////////////////
// ESP header (NULL encrypted)
/////////////////////////////////////////////
// The value of the next header field from the trailer
// part of the packet is passed as a parameter.
esp_null(next_header_value, repair_flag)
{
UNCOMPRESSED {
spi [ 32 ];
sequence_number [ 32 ];
}
CONTROL {
nh_field [ 8 ];
}
DEFAULT {
spi =:= static;
sequence_number =:= static;
nh_field =:= static;
}
COMPRESSED esp_static {
nh_field =:= compressed_value(8, next_header_value) [ 8 ];
spi =:= irregular(32) [ 32 ];
}
COMPRESSED esp_dynamic {
sequence_number =:= irregular(32) [ 32 ];
}
COMPRESSED esp_irregular {
ENFORCE(repair_flag == 0);
sequence_number =:= lsb_7_or_31 [ 8, 32 ];
}
COMPRESSED esp_repair_irregular {
ENFORCE(repair_flag == 1);
sequence_number =:= irregular(32) [ 32 ];
}
Pelletier & Sandlund Expires November 26, 2007 [Page 53]
Internet-Draft RoHCv2 Profiles May 2007
}
/////////////////////////////////////////////
// IPv6 Header
/////////////////////////////////////////////
fl_enc
{
UNCOMPRESSED {
flow_label [ 20 ];
}
COMPRESSED fl_zero {
discriminator =:= '0' [ 1 ];
flow_label =:= uncompressed_value(20, 0) [ 0 ];
reserved =:= '0000' [ 4 ];
}
COMPRESSED fl_non_zero {
discriminator =:= '1' [ 1 ];
flow_label =:= irregular(20) [ 20 ];
}
}
ipv6(profile, is_innermost, ip_outer_flag, repair_flag)
{
UNCOMPRESSED {
version =:= uncompressed_value(4, 6) [ 4 ];
tos_tc [ 8 ];
flow_label [ 20 ];
payload_length [ 16 ];
next_header [ 8 ];
ttl_hopl [ 8 ];
src_addr [ 128 ];
dst_addr [ 128 ];
}
DEFAULT {
tos_tc =:= static;
flow_label =:= static;
payload_length =:= inferred_ip_v6_length;
next_header =:= static;
ttl_hopl =:= static;
src_addr =:= static;
dst_addr =:= static;
}
COMPRESSED ipv6_static {
Pelletier & Sandlund Expires November 26, 2007 [Page 54]
Internet-Draft RoHCv2 Profiles May 2007
version_flag =:= '1' [ 1 ];
reserved =:= '00' [ 2 ];
flow_label =:= fl_enc [ 5, 21 ];
next_header =:= irregular(8) [ 8 ];
src_addr =:= irregular(128) [ 128 ];
dst_addr =:= irregular(128) [ 128 ];
}
COMPRESSED ipv6_endpoint_static {
ENFORCE((is_innermost == 1) &&
(profile == PROFILE_IP_0104));
version_flag =:= '1' [ 1 ];
innermost_indicator =:= compressed_value(1, 1) [ 1 ];
reserved =:= '0' [ 1 ];
flow_label =:= fl_enc [ 5, 21 ];
next_header =:= irregular(8) [ 8 ];
src_addr =:= irregular(128) [ 128 ];
dst_addr =:= irregular(128) [ 128 ];
}
COMPRESSED ipv6_endpoint_dynamic {
ENFORCE((is_innermost == 1) &&
(profile == PROFILE_IP_0104));
tos_tc =:= irregular(8) [ 8 ];
ttl_hopl =:= irregular(8) [ 8 ];
reserved =:= compressed_value(6, 0) [ 6 ];
reorder_ratio =:= reorder_choice [ 2 ];
msn =:= irregular(16) [ 16 ];
}
COMPRESSED ipv6_regular_dynamic {
ENFORCE((is_innermost == 0) ||
(profile != PROFILE_IP_0104));
tos_tc =:= irregular(8) [ 8 ];
ttl_hopl =:= irregular(8) [ 8 ];
}
COMPRESSED ipv6_outer_irregular {
ENFORCE(repair_flag == 0);
ENFORCE(is_innermost == 0);
tos_tc =:=
static_or_irreg(ip_outer_flag, 8) [ 0, 8 ];
ttl_hopl =:=
static_or_irreg(ip_outer_flag, 8) [ 0, 8 ];
}
COMPRESSED ipv6_innermost_irregular {
ENFORCE(repair_flag == 0);
Pelletier & Sandlund Expires November 26, 2007 [Page 55]
Internet-Draft RoHCv2 Profiles May 2007
ENFORCE(is_innermost == 1);
}
COMPRESSED ipv6_outer_repair_irregular {
ENFORCE(repair_flag == 1);
ENFORCE(is_innermost == 0);
tos_tc =:= static_or_irreg(ip_outer_flag, 8) [ 0, 8 ];
ttl_hopl =:= static_or_irreg(ip_outer_flag, 8) [ 0, 8 ];
}
COMPRESSED ipv6_innermost_repair_irregular {
ENFORCE(repair_flag == 1);
ENFORCE(is_innermost == 1);
}
}
/////////////////////////////////////////////
// IPv4 Header
/////////////////////////////////////////////
ip_id_enc_dyn(behavior)
{
UNCOMPRESSED {
ip_id [ 16 ];
}
COMPRESSED ip_id_seq {
ENFORCE((behavior == IP_ID_BEHAVIOR_SEQUENTIAL) ||
(behavior == IP_ID_BEHAVIOR_SEQUENTIAL_SWAPPED) ||
(behavior == IP_ID_BEHAVIOR_RANDOM));
ip_id =:= irregular(16) [ 16 ];
}
COMPRESSED ip_id_zero {
ENFORCE(behavior == IP_ID_BEHAVIOR_ZERO);
ip_id =:= uncompressed_value(16, 0) [ 0 ];
}
}
ip_id_enc_irreg(behavior)
{
UNCOMPRESSED {
ip_id [ 16 ];
}
COMPRESSED ip_id_seq {
ENFORCE(behavior == IP_ID_BEHAVIOR_SEQUENTIAL);
}
Pelletier & Sandlund Expires November 26, 2007 [Page 56]
Internet-Draft RoHCv2 Profiles May 2007
COMPRESSED ip_id_seq_swapped {
ENFORCE(behavior == IP_ID_BEHAVIOR_SEQUENTIAL_SWAPPED);
}
COMPRESSED ip_id_rand {
ENFORCE(behavior == IP_ID_BEHAVIOR_RANDOM);
ip_id =:= irregular(16) [ 16 ];
}
COMPRESSED ip_id_zero {
ENFORCE(behavior == IP_ID_BEHAVIOR_ZERO);
ip_id =:= uncompressed_value(16, 0) [ 0 ];
}
}
ip_id_behavior_choice(is_inner)
{
UNCOMPRESSED {
behavior [ 2 ];
}
DEFAULT {
behavior =:= irregular(2);
}
COMPRESSED sequential {
ENFORCE(is_inner == 1);
ENFORCE(behavior.UVALUE == IP_ID_BEHAVIOR_SEQUENTIAL);
behavior [ 2 ];
}
COMPRESSED sequential_swapped {
ENFORCE(is_inner == 1);
ENFORCE(behavior.UVALUE ==
IP_ID_BEHAVIOR_SEQUENTIAL_SWAPPED);
behavior [ 2 ];
}
COMPRESSED random {
ENFORCE(behavior.UVALUE == IP_ID_BEHAVIOR_RANDOM);
behavior [ 2 ];
}
COMPRESSED zero {
ENFORCE(behavior.UVALUE == IP_ID_BEHAVIOR_ZERO);
behavior [ 2 ];
}
}
Pelletier & Sandlund Expires November 26, 2007 [Page 57]
Internet-Draft RoHCv2 Profiles May 2007
variable_ipv4_fields(flag)
{
UNCOMPRESSED {
df [ 1 ];
ip_id_behavior [ 2 ];
}
COMPRESSED not_present {
ENFORCE(flag == 0);
df =:= static;
ip_id_behavior =:= static;
}
COMPRESSED present {
ENFORCE(flag == 1);
reserved =:= '00000' [ 5 ];
df =:= irregular(1) [ 1 ];
ip_id_behavior =:= ip_id_behavior_choice(0) [ 2 ];
}
}
ipv4(profile, is_innermost, ip_outer_flag, repair_flag)
{
UNCOMPRESSED {
version =:= uncompressed_value(4, 4) [ 4 ];
hdr_length =:= uncompressed_value(4, 5) [ 4 ];
tos_tc [ 8 ];
length =:= inferred_ip_v4_length [ 16 ];
ip_id [ 16 ];
rf =:= uncompressed_value(1, 0) [ 1 ];
df [ 1 ];
mf =:= uncompressed_value(1, 0) [ 1 ];
frag_offset =:= uncompressed_value(13, 0) [ 13 ];
ttl_hopl [ 8 ];
protocol [ 8 ];
checksum =:= inferred_ip_v4_header_checksum [ 16 ];
src_addr [ 32 ];
dst_addr [ 32 ];
}
CONTROL {
ip_id_behavior [ 2 ];
}
DEFAULT {
tos_tc =:= static;
df =:= static;
ttl_hopl =:= static;
Pelletier & Sandlund Expires November 26, 2007 [Page 58]
Internet-Draft RoHCv2 Profiles May 2007
protocol =:= static;
src_addr =:= static;
dst_addr =:= static;
ip_id_behavior =:= static;
}
COMPRESSED ipv4_static {
version_flag =:= '0' [ 1 ];
reserved =:= '0000000' [ 7 ];
protocol =:= irregular(8) [ 8 ];
src_addr =:= irregular(32) [ 32 ];
dst_addr =:= irregular(32) [ 32 ];
}
COMPRESSED ipv4_endpoint_static {
ENFORCE((is_innermost == 1) &&
(profile == PROFILE_IP_0104));
version_flag =:= '0' [ 1 ];
innermost_indicator =:= compressed_value(1, 1) [ 1 ];
reserved =:= '000000' [ 6 ];
protocol =:= irregular(8) [ 8 ];
src_addr =:= irregular(32) [ 32 ];
dst_addr =:= irregular(32) [ 32 ];
}
COMPRESSED ipv4_endpoint_dynamic {
ENFORCE((is_innermost == 1) &&
(profile == PROFILE_IP_0104));
reserved =:= '000' [ 3 ];
reorder_ratio =:= reorder_choice [ 2 ];
df =:= irregular(1) [ 1 ];
ip_id_behavior =:= ip_id_behavior_choice(is_innermost) [ 2 ];
tos_tc =:= irregular(8) [ 8 ];
ttl_hopl =:= irregular(8) [ 8 ];
ip_id =:= ip_id_enc_dyn(ip_id_behavior.UVALUE) [ 0, 16 ];
msn =:= irregular(16) [ 16 ];
}
COMPRESSED ipv4_regular_dynamic {
ENFORCE((is_innermost == 0) ||
(profile != PROFILE_IP_0104));
reserved =:= '00000' [ 5 ];
df =:= irregular(1) [ 1 ];
ip_id_behavior =:= ip_id_behavior_choice(is_innermost) [ 2 ];
tos_tc =:= irregular(8) [ 8 ];
ttl_hopl =:= irregular(8) [ 8 ];
ip_id =:= ip_id_enc_dyn(ip_id_behavior.UVALUE) [ 0, 16 ];
}
Pelletier & Sandlund Expires November 26, 2007 [Page 59]
Internet-Draft RoHCv2 Profiles May 2007
COMPRESSED ipv4_outer_irregular {
ENFORCE(repair_flag == 0);
ENFORCE(is_innermost == 0);
ip_id =:= ip_id_enc_irreg(ip_id_behavior.UVALUE) [ 0, 16 ];
tos_tc =:= static_or_irreg(ip_outer_flag, 8) [ 0, 8 ];
ttl_hopl =:= static_or_irreg(ip_outer_flag, 8) [ 0, 8 ];
}
COMPRESSED ipv4_innermost_irregular {
// Same format for repair and non-repair
ip_id =:= ip_id_enc_irreg(ip_id_behavior.UVALUE) [ 0, 16 ];
ENFORCE(is_innermost == 1);
}
COMPRESSED ipv4_outer_repair_irregular {
ENFORCE(repair_flag == 1);
ENFORCE(is_innermost == 0);
df : ip_id_behavior =:=
variable_ipv4_fields(outer_flag) [ 0, 8 ];
ip_id =:= ip_id_enc_irreg(ip_id_behavior.UVALUE) [ 0, 16 ];
tos_tc =:= static_or_irreg(ip_outer_flag, 8) [ 0, 8 ];
ttl_hopl =:= static_or_irreg(ip_outer_flag, 8) [ 0, 8 ];
}
}
/////////////////////////////////////////////
// UDP Header
/////////////////////////////////////////////
udp(profile)
{
UNCOMPRESSED {
ENFORCE((profile == PROFILE_RTP_0101) ||
(profile == PROFILE_UDP_0102));
src_port [ 16 ];
dst_port [ 16 ];
udp_length =:= inferred_udp_length [ 16 ];
checksum [ 16 ];
}
DEFAULT {
src_port =:= static;
dst_port =:= static;
checksum =:= irregular(16);
}
COMPRESSED udp_static {
Pelletier & Sandlund Expires November 26, 2007 [Page 60]
Internet-Draft RoHCv2 Profiles May 2007
src_port =:= irregular(16) [ 16 ];
dst_port =:= irregular(16) [ 16 ];
}
COMPRESSED udp_endpoint_dynamic {
ENFORCE(profile == PROFILE_UDP_0102);
checksum [ 16 ];
msn =:= irregular(16) [ 16 ];
reserved =:= compressed_value(6, 0) [ 6 ];
reorder_ratio =:= reorder_choice [ 2 ];
}
COMPRESSED udp_regular_dynamic {
ENFORCE(profile == PROFILE_RTP_0101);
checksum [ 16 ];
}
COMPRESSED udp_zero_checksum_irregular {
ENFORCE(checksum.UVALUE == 0);
checksum =:= uncompressed_value(16, 0) [ 0 ];
}
COMPRESSED udp_with_checksum_irregular {
ENFORCE(checksum.UVALUE != 0);
checksum [ 16 ];
}
}
/////////////////////////////////////////////
// RTP Header
/////////////////////////////////////////////
csrc_list_dynchain(presence, cc_value)
{
UNCOMPRESSED {
csrc_list;
}
COMPRESSED no_list {
ENFORCE(cc_value == 0);
ENFORCE(presence == 0);
csrc_list =:= uncompressed_value(0, 0) [ 0 ];
}
COMPRESSED list_present {
ENFORCE(presence == 1);
csrc_list =:= list_csrc(cc_value) [ VARIABLE ];
Pelletier & Sandlund Expires November 26, 2007 [Page 61]
Internet-Draft RoHCv2 Profiles May 2007
}
}
rtp(profile, ts_stride_value, time_stride_value)
{
UNCOMPRESSED {
ENFORCE((profile == PROFILE_RTP_0101) ||
(profile == PROFILE_RTP_0107));
rtp_version =:= uncompressed_value(2, 0) [ 2 ];
pad_bit [ 1 ];
extension [ 1 ];
cc [ 4 ];
marker [ 1 ];
payload_type [ 7 ];
sequence_number [ 16 ];
timestamp [ 32 ];
ssrc [ 32 ];
csrc_list [ cc.UVALUE * 32 ];
}
CONTROL {
ENFORCE(time_stride_value == time_stride.UVALUE);
ENFORCE(ts_stride_value == ts_stride.UVALUE);
ts_stride [ 32 ];
time_stride [ 32 ];
ts_scaled [ 32 ];
ts_offset =:=
field_scaling(ts_stride.UVALUE, ts_scaled.UVALUE,
timestamp.UVALUE) [ 32 ];
}
INITIAL {
ts_stride =:= uncompressed_value(32, 0);
time_stride =:= uncompressed_value(32, 0);
}
DEFAULT {
ENFORCE(msn.UVALUE == sequence_number.UVALUE);
pad_bit =:= static;
extension =:= static;
cc =:= static;
marker =:= static;
payload_type =:= static;
sequence_number =:= static;
timestamp =:= static;
ssrc =:= static;
csrc_list =:= static;
}
Pelletier & Sandlund Expires November 26, 2007 [Page 62]
Internet-Draft RoHCv2 Profiles May 2007
COMPRESSED rtp_static {
ssrc =:= irregular(32) [ 32 ];
}
COMPRESSED rtp_dynamic {
reserved =:= compressed_value(1, 0) [ 1 ];
reorder_ratio =:= reorder_choice [ 2 ];
list_present =:= irregular(1) [ 1 ];
tss_indicator =:= irregular(1) [ 1 ];
tis_indicator =:= irregular(1) [ 1 ];
pad_bit =:= irregular(1) [ 1 ];
extension =:= irregular(1) [ 1 ];
marker =:= irregular(1) [ 1 ];
payload_type =:= irregular(7) [ 7 ];
sequence_number =:= irregular(16) [ 16 ];
timestamp =:= irregular(32) [ 32 ];
ts_stride =:= sdvl_or_static(tss_indicator) [ VARIABLE ];
time_stride =:= sdvl_or_static(tis_indicator) [ VARIABLE ];
csrc_list =:=
csrc_list_dynchain(list_present, cc.UVALUE) [ VARIABLE ];
}
COMPRESSED rtp_irregular {
}
}
/////////////////////////////////////////////
// UDP-Lite Header
/////////////////////////////////////////////
checksum_coverage_dynchain(behavior)
{
UNCOMPRESSED {
checksum_coverage [ 16 ];
}
COMPRESSED inferred_coverage {
ENFORCE(behavior == UDP_LITE_COVERAGE_INFERRED);
checksum_coverage =:= inferred_udp_length [ 0 ];
}
COMPRESSED static_coverage {
ENFORCE(behavior == UDP_LITE_COVERAGE_STATIC);
checksum_coverage =:= irregular(16) [ 16 ];
}
COMPRESSED irregular_coverage {
ENFORCE(behavior == UDP_LITE_COVERAGE_IRREGULAR);
Pelletier & Sandlund Expires November 26, 2007 [Page 63]
Internet-Draft RoHCv2 Profiles May 2007
checksum_coverage =:= irregular(16) [ 16 ];
}
}
checksum_coverage_irregular(behavior)
{
UNCOMPRESSED {
checksum_coverage [ 16 ];
}
COMPRESSED inferred_coverage {
ENFORCE(behavior == UDP_LITE_COVERAGE_INFERRED);
checksum_coverage =:= inferred_udp_length [ 0 ];
}
COMPRESSED static_coverage {
ENFORCE(behavior == UDP_LITE_COVERAGE_STATIC);
checksum_coverage =:= static [ 0 ];
}
COMPRESSED irregular_coverage {
ENFORCE(behavior == UDP_LITE_COVERAGE_IRREGULAR);
checksum_coverage =:= irregular(16) [ 16 ];
}
}
udp_lite(profile)
{
UNCOMPRESSED {
ENFORCE((profile == PROFILE_RTP_0107) ||
(profile == PROFILE_UDPLITE_0108));
src_port [ 16 ];
dst_port [ 16 ];
checksum_coverage [ 16 ];
checksum [ 16 ];
}
CONTROL {
coverage_behavior [ 2 ];
}
DEFAULT {
src_port =:= static;
dst_port =:= static;
checksum_coverage =:= irregular(16);
checksum =:= irregular(16);
}
Pelletier & Sandlund Expires November 26, 2007 [Page 64]
Internet-Draft RoHCv2 Profiles May 2007
COMPRESSED udp_lite_static {
src_port =:= irregular(16) [ 16 ];
dst_port =:= irregular(16) [ 16 ];
}
COMPRESSED udp_lite_endpoint_dynamic {
ENFORCE(profile == PROFILE_UDPLITE_0108);
reserved =:= compressed_value(4, 0) [ 4 ];
coverage_behavior =:= irregular(2) [ 2 ];
reorder_ratio =:= reorder_choice [ 2 ];
checksum_coverage =:=
checksum_coverage_dynchain(coverage_behavior.UVALUE) [ 16 ];
checksum [ 16 ];
msn =:= irregular(16) [ 16 ];
}
COMPRESSED udp_lite_regular_dynamic {
coverage_behavior =:= irregular(2) [ 2 ];
reserved =:= compressed_value(6, 0) [ 6 ];
checksum_coverage =:=
checksum_coverage_dynchain(coverage_behavior.UVALUE) [ 16 ];
checksum [ 16 ];
}
COMPRESSED udp_lite_irregular {
checksum_coverage =:=
checksum_coverage_dynchain(coverage_behavior.UVALUE) [ 0, 16 ];
checksum [ 16 ];
}
}
/////////////////////////////////////////////
// ESP Header (Non-NULL encrypted
// i.e. only used for the ESP profile)
/////////////////////////////////////////////
esp(profile)
{
UNCOMPRESSED {
ENFORCE(profile == PROFILE_ESP_0103);
spi [ 32 ];
sequence_number [ 32 ];
}
DEFAULT {
ENFORCE(msn.UVALUE == sequence_number.UVALUE % 65536);
spi =:= static;
sequence_number =:= static;
Pelletier & Sandlund Expires November 26, 2007 [Page 65]
Internet-Draft RoHCv2 Profiles May 2007
}
COMPRESSED esp_static {
// Needs to be discriminated from ESP NULL headers,
// and therefore we have a dummy protocol field here.
discriminator =:= uncompressed_value(8, 255) [ 8 ];
spi =:= irregular(32) [ 32 ];
}
COMPRESSED esp_dynamic {
sequence_number =:= irregular(32) [ 32 ];
reserved =:= compressed_value(6, 0) [ 6 ];
reorder_ratio =:= reorder_choice [ 2 ];
}
COMPRESSED esp_irregular {
}
}
///////////////////////////////////////////////////
// Encoding methods used in the profiles' CO packets
///////////////////////////////////////////////////
// Variable reordering offset used for MSN
msn_lsb(k)
{
UNCOMPRESSED {
master [ 16 ];
}
COMPRESSED none {
ENFORCE(reorder_ratio.UVALUE == REORDERING_NONE);
master =:= lsb(k, 1);
}
COMPRESSED quarter {
ENFORCE(reorder_ratio.UVALUE == REORDERING_QUARTER);
master =:= lsb(k, ((2^k) / 4) - 1);
}
COMPRESSED half {
ENFORCE(reorder_ratio.UVALUE == REORDERING_HALF);
master =:= lsb(k, ((2^k) / 2) - 1);
}
COMPRESSED threequarters {
ENFORCE(reorder_ratio.UVALUE == REORDERING_THREEQUARTERS);
master =:= lsb(k, (((2^k) * 3) / 4) - 1);
Pelletier & Sandlund Expires November 26, 2007 [Page 66]
Internet-Draft RoHCv2 Profiles May 2007
}
}
ip_id_lsb(behavior, k)
{
UNCOMPRESSED {
ip_id [ 16 ];
}
CONTROL {
ip_id_offset [ 16 ];
ip_id_nbo [ 16 ];
}
COMPRESSED nbo {
ENFORCE(behavior == IP_ID_BEHAVIOR_SEQUENTIAL);
ENFORCE(ip_id_offset.UVALUE == ip_id.UVALUE - msn.UVALUE);
ip_id_offset =:= lsb(k, ((2^k) / 4) - 1) [ k ];
}
COMPRESSED non_nbo {
ENFORCE(behavior == IP_ID_BEHAVIOR_SEQUENTIAL_SWAPPED);
ENFORCE(ip_id_nbo.UVALUE ==
(ip_id.UVALUE / 256) + (ip_id.UVALUE % 256) * 256);
ENFORCE(ip_id_nbo.ULENGTH == 16);
ENFORCE(ip_id_offset.UVALUE == ip_id_nbo.UVALUE - msn.UVALUE);
ip_id_offset =:= lsb(k, ((2^k) / 4) - 1) [ k ];
}
}
optional_ip_id_lsb(behavior, indicator)
{
UNCOMPRESSED {
ip_id [ 16 ];
}
COMPRESSED short {
ENFORCE((behavior == IP_ID_BEHAVIOR_SEQUENTIAL) ||
(behavior == IP_ID_BEHAVIOR_SEQUENTIAL_SWAPPED));
ENFORCE(indicator == 0);
ip_id =:= ip_id_lsb(behavior, 8) [ 8 ];
}
COMPRESSED long {
ENFORCE((behavior == IP_ID_BEHAVIOR_SEQUENTIAL) ||
(behavior == IP_ID_BEHAVIOR_SEQUENTIAL_SWAPPED));
ENFORCE(indicator == 1);
ip_id =:= irregular(16) [ 16 ];
Pelletier & Sandlund Expires November 26, 2007 [Page 67]
Internet-Draft RoHCv2 Profiles May 2007
}
COMPRESSED not_present {
ENFORCE((behavior == IP_ID_BEHAVIOR_RANDOM) ||
(behavior == IP_ID_BEHAVIOR_ZERO));
}
}
dont_fragment(version)
{
UNCOMPRESSED {
df [ 1 ];
}
COMPRESSED v4 {
ENFORCE(version == 4);
df =:= irregular(1) [ 1 ];
}
COMPRESSED v6 {
ENFORCE(version == 6);
df =:= compressed_value(1, 0) [ 1 ];
}
}
optional_pt(flag)
{
UNCOMPRESSED {
payload_type [ 7 ];
}
COMPRESSED not_present {
ENFORCE(flag == 0);
payload_type =:= static [ 0 ];
}
COMPRESSED present {
ENFORCE(flag == 1);
reserved =:= compressed_value(1, 0) [ 1 ];
payload_type =:= irregular(7) [ 7 ];
}
}
csrc_list_presence(presence, cc_value)
{
UNCOMPRESSED {
csrc_list;
}
Pelletier & Sandlund Expires November 26, 2007 [Page 68]
Internet-Draft RoHCv2 Profiles May 2007
COMPRESSED no_list {
ENFORCE(presence == 0);
csrc_list =:= static [ 0 ];
}
COMPRESSED list_present {
ENFORCE(presence == 1);
csrc_list =:= list_csrc(cc_value) [ VARIABLE ];
}
}
scaled_ts_lsb(time_stride_value, k)
{
UNCOMPRESSED {
timestamp [ 32 ];
}
COMPRESSED timerbased {
ENFORCE(time_stride_value != 0);
timestamp =:= timer_based_lsb(time_stride_value, k,
((2^k) / 4) - 1);
}
COMPRESSED regular {
ENFORCE(time_stride_value == 0);
timestamp =:= lsb(k, ((2^k) / 4) - 1);
}
}
irregular_or_nothing(flag)
{
UNCOMPRESSED {
field [ 32 ];
}
COMPRESSED not_present {
ENFORCE(flag == 0);
}
COMPRESSED present {
ENFORCE(flag == 1);
field =:= irregular(32);
}
}
// Self-describing variable length encoding
sdvl_lsb(field_width)
{
Pelletier & Sandlund Expires November 26, 2007 [Page 69]
Internet-Draft RoHCv2 Profiles May 2007
UNCOMPRESSED {
field [ field_width ];
}
COMPRESSED lsb7 {
discriminator =:= '0' [ 1 ];
field =:= lsb(7, ((2^7) / 4) - 1) [ 7 ];
}
COMPRESSED lsb14 {
discriminator =:= '10' [ 2 ];
field =:= lsb(14, ((2^14) / 4) - 1) [ 14 ];
}
COMPRESSED lsb21 {
discriminator =:= '110' [ 3 ];
field =:= lsb(21, ((2^21) / 4) - 1) [ 21 ];
}
COMPRESSED lsb28 {
discriminator =:= '1110' [ 4 ];
field =:= lsb(28, ((2^28) / 4) - 1) [ 28 ];
}
COMPRESSED lsb32 {
discriminator =:= '11111111' [ 8 ];
field =:= irregular(field_width) [ field_width ];
}
}
variable_scaled_timestamp(tss_flag, tsc_flag, ts_stride)
{
UNCOMPRESSED {
timestamp [ 32 ];
}
COMPRESSED present {
ENFORCE((tss_flag == 0) && (tsc_flag == 1));
ENFORCE(ts_stride != 0);
timestamp =:= sdvl_lsb(32) [ VARIABLE ];
}
COMPRESSED not_present {
ENFORCE(((tss_flag == 1) && (tsc_flag == 0)) ||
((tss_flag == 0) && (tsc_flag == 0)));
}
}
Pelletier & Sandlund Expires November 26, 2007 [Page 70]
Internet-Draft RoHCv2 Profiles May 2007
variable_unscaled_timestamp(tss_flag, tsc_flag)
{
UNCOMPRESSED {
timestamp [ 32 ];
}
COMPRESSED present {
ENFORCE(((tss_flag == 1) && (tsc_flag == 0)) ||
((tss_flag == 0) && (tsc_flag == 0)));
timestamp =:= sdvl_lsb(32);
}
COMPRESSED not_present {
ENFORCE((tss_flag == 0) && (tsc_flag == 1));
}
}
profile_1_7_flags1_enc(flag)
{
UNCOMPRESSED {
ip_outer_indicator [ 1 ];
repair_indicator [ 1 ];
ttl_hopl_indicator [ 1 ];
tos_tc_indicator [ 1 ];
ip_id_behavior [ 2 ];
reorder_ratio [ 2 ];
}
COMPRESSED not_present {
ENFORCE(flag == 0);
ENFORCE(ip_outer_indicator.CVALUE == 0);
ENFORCE(repair_indicator.CVALUE == 0);
ENFORCE(ttl_hopl_indicator.CVALUE == 0);
ENFORCE(tos_tc_indicator.CVALUE == 0);
ip_id_behavior =:= static;
reorder_ratio =:= static;
}
COMPRESSED present {
ENFORCE(flag == 1);
ip_outer_indicator =:= irregular(1) [ 1 ];
repair_indicator =:= irregular(1) [ 1 ];
ttl_hopl_indicator =:= irregular(1) [ 1 ];
tos_tc_indicator =:= irregular(1) [ 1 ];
ip_id_behavior =:= ip_id_behavior_choice(1) [ 2 ];
reorder_ratio =:= reorder_choice [ 2 ];
}
}
Pelletier & Sandlund Expires November 26, 2007 [Page 71]
Internet-Draft RoHCv2 Profiles May 2007
profile_1_flags2_enc(flag, ip_version)
{
UNCOMPRESSED {
list_indicator [ 1 ];
pt_indicator [ 1 ];
pad_bit [ 1 ];
extension [ 1 ];
df [ 1 ];
time_stride_indicator [ 1 ];
}
COMPRESSED not_present{
ENFORCE(flag == 0);
ENFORCE(list_indicator.UVALUE == 0);
ENFORCE(pt_indicator.UVALUE == 0);
ENFORCE(time_stride_indicator.UVALUE == 0);
pad_bit =:= static;
extension =:= static;
df =:= static;
}
COMPRESSED present {
ENFORCE(flag == 1);
list_indicator =:= irregular(1) [ 1 ];
pt_indicator =:= irregular(1) [ 1 ];
time_stride_indicator =:= irregular(1) [ 1 ];
pad_bit =:= irregular(1) [ 1 ];
extension =:= irregular(1) [ 1 ];
df =:= dont_fragment(ip_version) [ 1 ];
reserved =:= compressed_value(2, 0) [ 2 ];
}
}
profile_2_3_4_flags_enc(flag, ip_version)
{
UNCOMPRESSED {
ip_outer_indicator [ 1 ];
repair_indicator [ 1 ];
df [ 1 ];
ip_id_behavior [ 2 ];
}
COMPRESSED not_present {
ENFORCE(flag == 0);
ENFORCE(ip_outer_indicator.CVALUE == 0);
ENFORCE(repair_indicator.CVALUE == 0);
df =:= static;
ip_id_behavior =:= static;
Pelletier & Sandlund Expires November 26, 2007 [Page 72]
Internet-Draft RoHCv2 Profiles May 2007
}
COMPRESSED present {
ENFORCE(flag == 1);
ip_outer_indicator =:= irregular(1) [ 1 ];
repair_indicator =:= irregular(1) [ 1 ];
df =:= dont_fragment(ip_version) [ 1 ];
ip_id_behavior =:= ip_id_behavior_choice(1) [ 2 ];
reserved =:= compressed_value(3, 0) [ 3 ];
}
}
profile_8_flags_enc(flag)
{
UNCOMPRESSED {
ip_outer_indicator [ 1 ];
repair_indicator [ 1 ];
df [ 1 ];
ip_id_behavior [ 2 ];
coverage_behavior [ 2 ];
}
COMPRESSED not_present {
ENFORCE(flag == 0);
ENFORCE(ip_outer_indicator.CVALUE == 0);
ENFORCE(repair_indicator.CVALUE == 0);
df =:= static;
ip_id_behavior =:= static;
coverage_behavior =:= static;
}
COMPRESSED present {
ENFORCE(flag == 1);
reserved =:= compressed_value(1, 0) [ 1 ];
ip_outer_indicator =:= irregular(1) [ 1 ];
repair_indicator =:= irregular(1) [ 1 ];
df =:= dont_fragment(ip_version) [ 1 ];
ip_id_behavior =:= ip_id_behavior_choice(1) [ 2 ];
coverage_behavior =:= irregular(2) [ 2 ];
}
}
profile_7_flags2_enc(flag, ip_version)
{
UNCOMPRESSED {
list_indicator [ 1 ];
pt_indicator [ 1 ];
time_stride_indicator [ 1 ];
Pelletier & Sandlund Expires November 26, 2007 [Page 73]
Internet-Draft RoHCv2 Profiles May 2007
pad_bit [ 1 ];
extension [ 1 ];
df [ 1 ];
coverage_behavior [ 2 ];
}
COMPRESSED not_present{
ENFORCE(flag == 0);
ENFORCE(list_indicator.CVALUE == 0);
ENFORCE(pt_indicator.CVALUE == 0);
ENFORCE(time_stride_indicator.CVALUE == 0);
pad_bit =:= static;
extension =:= static;
df =:= static;
coverage_behavior =:= static;
}
COMPRESSED present {
ENFORCE(flag == 1);
list_indicator =:= irregular(1) [ 1 ];
pt_indicator =:= irregular(1) [ 1 ];
time_stride_indicator =:= irregular(1) [ 1 ];
pad_bit =:= irregular(1) [ 1 ];
extension =:= irregular(1) [ 1 ];
df =:= dont_fragment(ip_version) [ 1 ];
coverage_behavior =:= irregular(2) [ 2 ];
}
}
////////////////////////////////////////////
// RTP profile
////////////////////////////////////////////
rtp_baseheader(profile, ts_stride_value, time_stride_value,
outer_ip_flag, repair_flag)
{
UNCOMPRESSED v4 {
ENFORCE(msn.UVALUE == sequence_number.UVALUE);
outer_headers =:= baseheader_outer_headers [ VARIABLE ];
ip_version =:= uncompressed_value(4, 4) [ 4 ];
header_length =:= uncompressed_value(4, 5) [ 4 ];
tos_tc [ 8 ];
length =:= inferred_ip_v4_length [ 16 ];
ip_id [ 16 ];
rf =:= uncompressed_value(1, 0) [ 1 ];
df [ 1 ];
mf =:= uncompressed_value(1, 0) [ 1 ];
frag_offset =:= uncompressed_value(13, 0) [ 13 ];
Pelletier & Sandlund Expires November 26, 2007 [Page 74]
Internet-Draft RoHCv2 Profiles May 2007
ttl_hopl [ 8 ];
next_header [ 8 ];
ip_checksum =:= inferred_ip_v4_header_checksum [ 16 ];
src_addr [ 32 ];
dest_addr [ 32 ];
extension_headers =:= baseheader_extension_headers [ VARIABLE ];
src_port [ 16 ];
dst_port [ 16 ];
udp_length =:= inferred_udp_length [ 16 ];
udp_checksum [ 16 ];
rtp_version =:= uncompressed_value(2, 2) [ 2 ];
pad_bit [ 1 ];
extension [ 1 ];
cc [ 4 ];
marker [ 1 ];
payload_type [ 7 ];
sequence_number [ 16 ];
timestamp [ 32 ];
ssrc [ 32 ];
csrc_list [ VARIABLE ];
}
UNCOMPRESSED v6 {
ENFORCE(ip_id_behavior.UVALUE == IP_ID_BEHAVIOR_RANDOM);
ENFORCE(msn.UVALUE == sequence_number.UVALUE);
outer_headers =:= baseheader_outer_headers [ VARIABLE ];
ip_version =:= uncompressed_value(4, 6) [ 4 ];
tos_tc [ 8 ];
flow_label [ 20 ];
payload_length =:= inferred_ip_v6_length [ 16 ];
next_header [ 8 ];
ttl_hopl [ 8 ];
src_addr [ 128 ];
dest_addr [ 128 ];
extension_headers =:= baseheader_extension_headers [ VARIABLE ];
src_port [ 16 ];
dst_port [ 16 ];
udp_length =:= inferred_udp_length [ 16 ];
udp_checksum [ 16 ];
rtp_version =:= uncompressed_value(2, 2) [ 2 ];
pad_bit [ 1 ];
extension [ 1 ];
cc [ 4 ];
marker [ 1 ];
payload_type [ 7 ];
sequence_number [ 16 ];
timestamp [ 32 ];
ssrc [ 32 ];
Pelletier & Sandlund Expires November 26, 2007 [Page 75]
Internet-Draft RoHCv2 Profiles May 2007
csrc_list [ VARIABLE ];
}
CONTROL {
ENFORCE(time_stride_value == time_stride.UVALUE);
ENFORCE(ts_stride.UVALUE == ts_stride_value);
ENFORCE(profile == PROFILE_RTP_0101);
ts_stride [ 32 ];
time_stride [ 32 ];
ts_scaled [ 32 ];
ts_offset =:= field_scaling(ts_stride.UVALUE, ts_scaled.UVALUE,
timestamp.UVALUE) [ 32 ];
ip_id_behavior [ 2 ];
}
INITIAL {
ts_stride =:= uncompressed_value(32, 0);
time_stride =:= uncompressed_value(32, 0);
}
DEFAULT {
ENFORCE(outer_ip_flag == 0);
ENFORCE(repair_flag == 0);
tos_tc =:= static;
dest_addr =:= static;
ttl_hopl =:= static;
src_addr =:= static;
df =:= static;
ip_id_behavior =:= static;
flow_label =:= static;
next_header =:= static;
src_port =:= static;
dst_port =:= static;
udp_checksum =:= irregular(16);
pad_bit =:= static;
extension =:= static;
cc =:= static;
// When marker not present in packets, it is assumed 0
marker =:= uncompressed_value(1, 0);
payload_type =:= static;
sequence_number =:= static;
timestamp =:= static;
ssrc =:= static;
csrc_list =:= static;
}
// Replacement for UOR-2-ext3
COMPRESSED co_common {
Pelletier & Sandlund Expires November 26, 2007 [Page 76]
Internet-Draft RoHCv2 Profiles May 2007
ENFORCE(repair_flag == 0);
ENFORCE(outer_ip_flag == outer_ip_indicator.CVALUE);
ENFORCE(repair_flag == repair_indicator.CVALUE);
discriminator =:= '11111010' [ 8 ];
marker =:= irregular(1) [ 1 ];
header_crc =:= crc7(THIS.UVALUE, THIS.ULENGTH) [ 7 ];
flags1_indicator =:= irregular(1) [ 1 ];
flags2_indicator =:= irregular(1) [ 1 ];
tsc_indicator =:= irregular(1) [ 1 ];
tss_indicator =:= irregular(1) [ 1 ];
ip_id_indicator =:= irregular(1) [ 1 ];
control_crc3 =:= control_crc3_encoding [ 3 ];
outer_ip_indicator : repair_indicator : ttl_hopl_indicator :
tos_tc_indicator : ip_id_behavior : reorder_ratio =:=
profile_1_7_flags1_enc(flags1_indicator.CVALUE) [ 0, 8 ];
list_indicator : pt_indicator : tis_indicator :pad_bit :
extension : df =:= profile_1_flags2_enc(flags2_indicator.CVALUE,
ip_version.UVALUE) [ 0, 8 ];
ip_id =:= optional_ip_id_lsb(ip_id_behavior.UVALUE,
ip_id_indicator.CVALUE) [ 0, 8, 16 ];
tos_tc =:= static_or_irreg(tos_tc_indicator.CVALUE, 8) [ 0, 8 ];
ttl_hopl =:= static_or_irreg(ttl_hopl_indicator.CVALUE,
ttl_hopl.ULENGTH) [ 0, 8 ];
payload_type =:= optional_pt(pt_indicator) [ 0, 8 ];
sequence_number =:= sdvl_lsb(sequence_number.ULENGTH) [ VARIABLE ];
ts_scaled =:= variable_scaled_timestamp(tss_indicator.CVALUE,
tsc_indicator, ts_stride.UVALUE) [ VARIABLE ];
timestamp =:= variable_unscaled_timestamp(tss_indicator.CVALUE,
tsc_indicator) [ VARIABLE ];
ts_stride =:= sdvl_or_static(tss_indicator.CVALUE) [ VARIABLE ];
time_stride =:= sdvl_or_static(tis_indicator.CVALUE) [ VARIABLE ];
csrc_list =:= csrc_list_presence(list_indicator.CVALUE,
cc.UVALUE) [ VARIABLE ];
}
// Context repair (IR-DYN replacement).
COMPRESSED co_repair {
ENFORCE(outer_ip_flag == outer_ip_indicator.CVALUE);
ENFORCE(repair_flag == repair_indicator.CVALUE);
discriminator =:= '11111011' [ 8 ];
marker =:= irregular(1) [ 1 ];
header_crc =:= crc7(THIS.UVALUE, THIS.ULENGTH) [ 7 ];
flags1_indicator =:= irregular(1) [ 1 ];
flags2_indicator =:= irregular(1) [ 1 ];
timestamp_indicator =:= irregular(1) [ 1 ];
tss_indicator =:= irregular(1) [ 1 ];
ip_id_indicator =:= irregular(1) [ 1 ];
Pelletier & Sandlund Expires November 26, 2007 [Page 77]
Internet-Draft RoHCv2 Profiles May 2007
control_crc3 =:= control_crc3_encoding [ 3 ];
outer_ip_indicator : repair_indicator : ttl_hopl_indicator :
tos_tc_indicator : ip_id_behavior : reorder_ratio =:=
profile_1_7_flags1_enc(flags1_indicator.CVALUE) [ 0, 8 ];
list_indicator : pt_indicator : pad_bit : extension : df :
tis_indicator =:= profile_1_flags2_enc(flags2_indicator.CVALUE,
ip_version.UVALUE) [ 0, 8 ];
ip_id =:= optional_ip_id_lsb(ip_id_behavior.UVALUE,
ip_id_indicator.CVALUE) [ 0, 8, 16 ];
tos_tc =:=
static_or_irreg(tos_tc_indicator.CVALUE, 8) [ 0, 8 ];
ttl_hopl =:= static_or_irreg(ttl_hopl_indicator.CVALUE,
ttl_hopl.ULENGTH) [ 0, 8 ];
payload_type =:= optional_pt(pt_indicator) [ 0, 8 ];
sequence_number =:= irregular(16) [ 16 ];
timestamp =:=
irregular_or_nothing(timestamp_indicator) [ 0, 32 ];
ts_stride =:=
sdvl_or_static(tss_indicator) [ VARIABLE ];
time_stride =:=
sdvl_or_static(tis_indicator) [ VARIABLE ];
csrc_list =:=
csrc_list_presence(list_indicator.CVALUE, cc.UVALUE) [ VARIABLE ];
}
// UO-0
COMPRESSED pt_0_crc3 {
discriminator =:= '0' [ 1 ];
msn =:= msn_lsb(4) [ 4 ];
header_crc =:= crc3(THIS.UVALUE, THIS.ULENGTH) [ 3 ];
timestamp =:= inferred_scaled_field [ 0 ];
ip_id =:= inferred_sequential_ip_id [ 0 ];
}
// New format, Type 0 with strong CRC and more SN bits
COMPRESSED pt_0_crc7 {
discriminator =:= '100' [ 3 ];
msn =:= msn_lsb(6) [ 6 ];
header_crc =:= crc7(THIS.UVALUE, THIS.ULENGTH) [ 7 ];
timestamp =:= inferred_scaled_field [ 0 ];
ip_id =:= inferred_sequential_ip_id [ 0 ];
}
// UO-1 replacement
COMPRESSED pt_1_rnd {
ENFORCE(ts_stride.UVALUE != 0);
ENFORCE((ip_id_behavior.UVALUE == IP_ID_BEHAVIOR_RANDOM) ||
Pelletier & Sandlund Expires November 26, 2007 [Page 78]
Internet-Draft RoHCv2 Profiles May 2007
(ip_id_behavior.UVALUE == IP_ID_BEHAVIOR_ZERO));
discriminator =:= '101' [ 3 ];
msn =:= msn_lsb(5) [ 5 ];
marker =:= irregular(1) [ 1 ];
ts_scaled =:= scaled_ts_lsb(time_stride.UVALUE, 4) [ 4 ];
header_crc =:= crc3(THIS.UVALUE, THIS.ULENGTH) [ 3 ];
}
// UO-1-ID replacement
COMPRESSED pt_1_seq_id {
ENFORCE((ip_id_behavior.UVALUE == IP_ID_BEHAVIOR_SEQUENTIAL) ||
(ip_id_behavior.UVALUE ==
IP_ID_BEHAVIOR_SEQUENTIAL_SWAPPED));
discriminator =:= '1010' [ 4 ];
header_crc =:= crc3(THIS.UVALUE, THIS.ULENGTH) [ 3 ];
msn =:= msn_lsb(5) [ 5 ];
ip_id =:= ip_id_lsb(ip_id_behavior.UVALUE, 4) [ 4 ];
timestamp =:= inferred_scaled_field [ 0 ];
}
// UO-1-TS replacement
COMPRESSED pt_1_seq_ts {
ENFORCE(ts_stride.UVALUE != 0);
ENFORCE((ip_id_behavior.UVALUE == IP_ID_BEHAVIOR_SEQUENTIAL) ||
(ip_id_behavior.UVALUE ==
IP_ID_BEHAVIOR_SEQUENTIAL_SWAPPED));
discriminator =:= '1011' [ 4 ];
marker =:= irregular(1) [ 1 ];
header_crc =:= crc3(THIS.UVALUE, THIS.ULENGTH) [ 3 ];
msn =:= msn_lsb(4) [ 4 ];
ts_scaled =:= scaled_ts_lsb(time_stride.UVALUE, 4) [ 4 ];
}
// UOR-2 replacement
COMPRESSED pt_2_rnd {
ENFORCE(ts_stride.UVALUE != 0);
ENFORCE((ip_id_behavior.UVALUE == IP_ID_BEHAVIOR_RANDOM) ||
(ip_id_behavior.UVALUE == IP_ID_BEHAVIOR_ZERO));
discriminator =:= '110' [ 3 ];
msn =:= msn_lsb(7) [ 7 ];
ts_scaled =:= scaled_ts_lsb(time_stride.UVALUE, 6) [ 6 ];
marker =:= irregular(1) [ 1 ];
header_crc =:= crc7(THIS.UVALUE, THIS.ULENGTH) [ 7 ];
}
// UOR-2-ID replacement
COMPRESSED pt_2_seq_id {
ENFORCE((ip_id_behavior.UVALUE == IP_ID_BEHAVIOR_SEQUENTIAL) ||
Pelletier & Sandlund Expires November 26, 2007 [Page 79]
Internet-Draft RoHCv2 Profiles May 2007
(ip_id_behavior.UVALUE ==
IP_ID_BEHAVIOR_SEQUENTIAL_SWAPPED));
discriminator =:= '11000' [ 5 ];
msn =:= msn_lsb(7) [ 7 ];
ip_id =:= ip_id_lsb(ip_id_behavior.UVALUE, 5) [ 5 ];
header_crc =:= crc7(THIS.UVALUE, THIS.ULENGTH) [ 7 ];
timestamp =:= inferred_scaled_field [ 0 ];
}
// UOR-2-ID-ext1 replacement (both TS and IP-ID)
COMPRESSED pt_2_seq_both {
ENFORCE(ts_stride.UVALUE != 0);
ENFORCE((ip_id_behavior.UVALUE == IP_ID_BEHAVIOR_SEQUENTIAL) ||
(ip_id_behavior.UVALUE ==
IP_ID_BEHAVIOR_SEQUENTIAL_SWAPPED));
discriminator =:= '11001' [ 5 ];
msn =:= msn_lsb(7) [ 7 ];
ip_id =:= ip_id_lsb(ip_id_behavior.UVALUE, 5) [ 5 ];
header_crc =:= crc7(THIS.UVALUE, THIS.ULENGTH) [ 7 ];
ts_scaled =:= scaled_ts_lsb(time_stride.UVALUE, 8) [ 8 ];
}
// UOR-2-TS replacement
COMPRESSED pt_2_seq_ts {
ENFORCE(ts_stride.UVALUE != 0);
ENFORCE((ip_id_behavior.UVALUE == IP_ID_BEHAVIOR_SEQUENTIAL) ||
(ip_id_behavior.UVALUE ==
IP_ID_BEHAVIOR_SEQUENTIAL_SWAPPED));
discriminator =:= '1101' [ 4 ];
msn =:= msn_lsb(7) [ 7 ];
ts_scaled =:= scaled_ts_lsb(time_stride.UVALUE, 5) [ 5 ];
marker =:= irregular(1) [ 1 ];
header_crc =:= crc7(THIS.UVALUE, THIS.ULENGTH) [ 7 ];
}
}
////////////////////////////////////////////
// UDP profile
////////////////////////////////////////////
udp_baseheader(profile, outer_ip_flag, repair_flag)
{
UNCOMPRESSED v4 {
outer_headers =:= baseheader_outer_headers [ VARIABLE ];
ip_version =:= uncompressed_value(4, 4) [ 4 ];
header_length =:= uncompressed_value(4, 5) [ 4 ];
tos_tc [ 8 ];
length =:= inferred_ip_v4_length [ 16 ];
Pelletier & Sandlund Expires November 26, 2007 [Page 80]
Internet-Draft RoHCv2 Profiles May 2007
ip_id [ 16 ];
rf =:= uncompressed_value(1, 0) [ 1 ];
df [ 1 ];
mf =:= uncompressed_value(1, 0) [ 1 ];
frag_offset =:= uncompressed_value(13, 0) [ 13 ];
ttl_hopl [ 8 ];
next_header [ 8 ];
ip_checksum =:= inferred_ip_v4_header_checksum [ 16 ];
src_addr [ 32 ];
dest_addr [ 32 ];
extension_headers =:= baseheader_extension_headers [ VARIABLE ];
src_port [ 16 ];
dst_port [ 16 ];
udp_length =:= inferred_udp_length [ 16 ];
udp_checksum [ 16 ];
}
UNCOMPRESSED v6 {
ENFORCE(ip_id_behavior.UVALUE == IP_ID_BEHAVIOR_RANDOM);
outer_headers =:= baseheader_outer_headers [ VARIABLE ];
ip_version =:= uncompressed_value(4, 6) [ 4 ];
tos_tc [ 8 ];
flow_label [ 20 ];
payload_length =:= inferred_ip_v6_length [ 16 ];
next_header [ 8 ];
ttl_hopl [ 8 ];
src_addr [ 128 ];
dest_addr [ 128 ];
extension_headers =:= baseheader_extension_headers [ VARIABLE ];
src_port [ 16 ];
dst_port [ 16 ];
udp_length =:= inferred_udp_length [ 16 ];
udp_checksum [ 16 ];
}
CONTROL {
ENFORCE(profile == PROFILE_UDP_0102);
ip_id_behavior [ 2 ];
}
DEFAULT {
ENFORCE(outer_ip_flag == 0);
ENFORCE(repair_flag == 0);
tos_tc =:= static;
dest_addr =:= static;
ip_version =:= static;
ttl_hopl =:= static;
src_addr =:= static;
Pelletier & Sandlund Expires November 26, 2007 [Page 81]
Internet-Draft RoHCv2 Profiles May 2007
df =:= static;
ip_id_behavior =:= static;
flow_label =:= static;
next_header =:= static;
src_port =:= static;
dst_port =:= static;
udp_checksum =:= irregular(16);
}
// Replacement for UOR-2-ext3
COMPRESSED co_common {
ENFORCE(repair_flag == 0);
ENFORCE(outer_ip_flag == outer_ip_indicator.CVALUE);
ENFORCE(repair_flag == repair_indicator.CVALUE);
discriminator =:= '11111010' [ 8 ];
ip_id_indicator =:= irregular(1) [ 1 ];
header_crc =:= crc7(THIS.UVALUE, THIS.ULENGTH) [ 7 ];
flags_indicator =:= irregular(1) [ 1 ];
ttl_hopl_indicator =:= irregular(1) [ 1 ];
tos_tc_indicator =:= irregular(1) [ 1 ];
reorder_ratio =:= reorder_choice [ 2 ];
control_crc3 =:= control_crc3_encoding [ 3 ];
outer_ip_indicator : repair_indicator : df :
ip_id_behavior =:= profile_2_3_4_flags_enc(
flags_indicator.CVALUE, ip_version.UVALUE) [ 0, 8 ];
ip_id =:= optional_ip_id_lsb(ip_id_behavior.UVALUE,
ip_id_indicator.CVALUE) [ 0, 8, 16 ];
tos_tc =:= static_or_irreg(tos_tc_indicator.CVALUE, 8) [ 0, 8 ];
ttl_hopl =:= static_or_irreg(ttl_hopl_indicator.CVALUE,
ttl_hopl.ULENGTH) [ 0, 8 ];
msn =:= msn_lsb(8) [ 8 ];
}
// Context repair (IR-DYN replacement).
COMPRESSED co_repair {
ENFORCE(outer_ip_flag == outer_ip_indicator.CVALUE);
ENFORCE(repair_flag == repair_indicator.CVALUE);
discriminator =:= '11111011' [ 8 ];
ip_id_indicator =:= irregular(1) [ 1 ];
header_crc =:= crc7(THIS.UVALUE, THIS.ULENGTH) [ 7 ];
flags_indicator =:= irregular(1) [ 1 ];
ttl_hopl_indicator =:= irregular(1) [ 1 ];
tos_tc_indicator =:= irregular(1) [ 1 ];
reorder_ratio =:= reorder_choice [ 2 ];
control_crc3 =:= control_crc3_encoding [ 3 ];
outer_ip_indicator : repair_indicator : df :
ip_id_behavior =:= profile_2_3_4_flags_enc(
flags_indicator.CVALUE, ip_version.UVALUE) [ 0, 8 ];
Pelletier & Sandlund Expires November 26, 2007 [Page 82]
Internet-Draft RoHCv2 Profiles May 2007
ip_id =:= optional_ip_id_lsb(ip_id_behavior.UVALUE,
ip_id_indicator.CVALUE) [ 0, 8, 16 ];
tos_tc =:= static_or_irreg(tos_tc_indicator.CVALUE, 8) [ 0, 8 ];
ttl_hopl =:= static_or_irreg(ttl_hopl_indicator.CVALUE,
ttl_hopl.ULENGTH) [ 0, 8 ];
msn =:= irregular(16) [ 16 ];
}
// UO-0
COMPRESSED pt_0_crc3 {
discriminator =:= '0' [ 1 ];
msn =:= msn_lsb(4) [ 4 ];
header_crc =:= crc3(THIS.UVALUE, THIS.ULENGTH) [ 3 ];
ip_id =:= inferred_sequential_ip_id [ 0 ];
}
// New format, Type 0 with strong CRC and more SN bits
COMPRESSED pt_0_crc7 {
discriminator =:= '100' [ 3 ];
msn =:= msn_lsb(6) [ 6 ];
header_crc =:= crc7(THIS.UVALUE, THIS.ULENGTH) [ 7 ];
ip_id =:= inferred_sequential_ip_id [ 0 ];
}
// UO-1-ID replacement (PT-1 only used for sequential)
COMPRESSED pt_1_seq_id {
ENFORCE((ip_id_behavior.UVALUE == IP_ID_BEHAVIOR_SEQUENTIAL) ||
(ip_id_behavior.UVALUE ==
IP_ID_BEHAVIOR_SEQUENTIAL_SWAPPED));
discriminator =:= '101' [ 3 ];
header_crc =:= crc3(THIS.UVALUE, THIS.ULENGTH) [ 3 ];
msn =:= msn_lsb(6) [ 6 ];
ip_id =:= ip_id_lsb(ip_id_behavior.UVALUE, 4) [ 4 ];
}
// UOR-2 replacement
COMPRESSED pt_2_rnd {
ENFORCE((ip_id_behavior.UVALUE == IP_ID_BEHAVIOR_RANDOM) ||
(ip_id_behavior.UVALUE == IP_ID_BEHAVIOR_ZERO));
discriminator =:= '110' [ 3 ];
msn =:= msn_lsb(6) [ 6 ];
header_crc =:= crc7(THIS.UVALUE, THIS.ULENGTH) [ 7 ];
}
// UOR-2-ID replacement
COMPRESSED pt_2_seq_id {
ENFORCE((ip_id_behavior.UVALUE == IP_ID_BEHAVIOR_SEQUENTIAL) ||
(ip_id_behavior.UVALUE ==
Pelletier & Sandlund Expires November 26, 2007 [Page 83]
Internet-Draft RoHCv2 Profiles May 2007
IP_ID_BEHAVIOR_SEQUENTIAL_SWAPPED));
discriminator =:= '1100' [ 4 ];
ip_id =:= ip_id_lsb(ip_id_behavior.UVALUE, 5) [ 5 ];
header_crc =:= crc7(THIS.UVALUE, THIS.ULENGTH) [ 7 ];
msn =:= msn_lsb(8) [ 8 ];
}
}
////////////////////////////////////////////
// ESP profile
////////////////////////////////////////////
esp_baseheader(profile, outer_ip_flag, repair_flag)
{
UNCOMPRESSED v4 {
ENFORCE(msn.UVALUE == sequence_number.UVALUE % 65536);
outer_headers =:= baseheader_outer_headers [ VARIABLE ];
ip_version =:= uncompressed_value(4, 4) [ 4 ];
header_length =:= uncompressed_value(4, 5) [ 4 ];
tos_tc [ 8 ];
length =:= inferred_ip_v4_length [ 16 ];
ip_id [ 16 ];
rf =:= uncompressed_value(1, 0) [ 1 ];
df [ 1 ];
mf =:= uncompressed_value(1, 0) [ 1 ];
frag_offset =:= uncompressed_value(13, 0) [ 13 ];
ttl_hopl [ 8 ];
next_header [ 8 ];
ip_checksum =:= inferred_ip_v4_header_checksum [ 16 ];
src_addr [ 32 ];
dest_addr [ 32 ];
extension_headers =:= baseheader_extension_headers [ VARIABLE ];
spi [ 32 ];
sequence_number [ 32 ];
}
UNCOMPRESSED v6 {
ENFORCE(msn.UVALUE == (sequence_number.UVALUE % 65536));
ENFORCE(ip_id_behavior.UVALUE == IP_ID_BEHAVIOR_RANDOM);
outer_headers =:= baseheader_outer_headers [ VARIABLE ];
ip_version =:= uncompressed_value(4, 6) [ 4 ];
tos_tc [ 8 ];
flow_label [ 20 ];
payload_length =:= inferred_ip_v6_length [ 16 ];
next_header [ 8 ];
ttl_hopl [ 8 ];
src_addr [ 128 ];
dest_addr [ 128 ];
Pelletier & Sandlund Expires November 26, 2007 [Page 84]
Internet-Draft RoHCv2 Profiles May 2007
extension_headers =:= baseheader_extension_headers [ VARIABLE ];
spi [ 32 ];
sequence_number [ 32 ];
}
CONTROL {
ENFORCE(profile == PROFILE_ESP_0103);
ip_id_behavior [ 2 ];
}
DEFAULT {
ENFORCE(outer_ip_indicator == 0);
ENFORCE(repair_flag == 0);
tos_tc =:= static;
dest_addr =:= static;
ttl_hopl =:= static;
src_addr =:= static;
df =:= static;
ip_id_behavior =:= static;
flow_label =:= static;
next_header =:= static;
spi =:= static;
sequence_number =:= static;
}
// Replacement for UOR-2-ext3
COMPRESSED co_common {
ENFORCE(repair_flag == 0);
ENFORCE(outer_ip_flag == outer_ip_indicator.CVALUE);
ENFORCE(repair_flag == repair_indicator.CVALUE);
discriminator =:= '11111010' [ 8 ];
ip_id_indicator =:= irregular(1) [ 1 ];
header_crc =:= crc7(THIS.UVALUE, THIS.ULENGTH) [ 7 ];
flags_indicator =:= irregular(1) [ 1 ];
ttl_hopl_indicator =:= irregular(1) [ 1 ];
tos_tc_indicator =:= irregular(1) [ 1 ];
reorder_ratio =:= reorder_choice [ 2 ];
control_crc3 =:= control_crc3_encoding [ 3 ];
outer_ip_indicator : repair_indicator : df :
ip_id_behavior =:= profile_2_3_4_flags_enc(
flags_indicator.CVALUE, ip_version.UVALUE) [ 0, 8 ];
ip_id =:= optional_ip_id_lsb(ip_id_behavior.UVALUE,
ip_id_indicator.CVALUE) [ 0, 8, 16 ];
tos_tc =:= static_or_irreg(tos_tc_indicator.CVALUE, 8) [ 0, 8 ];
ttl_hopl =:= static_or_irreg(ttl_hopl_indicator.CVALUE,
ttl_hopl.ULENGTH) [ 0, 8 ];
sequence_number =:= sdvl_lsb(sequence_number.ULENGTH) [ VARIABLE ];
Pelletier & Sandlund Expires November 26, 2007 [Page 85]
Internet-Draft RoHCv2 Profiles May 2007
}
// Context repair (IR-DYN replacement).
COMPRESSED co_repair {
ENFORCE(outer_ip_flag == outer_ip_indicator.CVALUE);
ENFORCE(repair_flag == repair_indicator.CVALUE);
discriminator =:= '11111011' [ 8 ];
discriminator =:= '11111010' [ 8 ];
ip_id_indicator =:= irregular(1) [ 1 ];
header_crc =:= crc7(THIS.UVALUE, THIS.ULENGTH) [ 7 ];
flags_indicator =:= irregular(1) [ 1 ];
ttl_hopl_indicator =:= irregular(1) [ 1 ];
tos_tc_indicator =:= irregular(1) [ 1 ];
reorder_ratio =:= reorder_choice [ 2 ];
control_crc3 =:= control_crc3_encoding [ 3 ];
outer_ip_indicator : repair_indicator : df :
ip_id_behavior =:= profile_2_3_4_flags_enc(
flags_indicator.CVALUE, ip_version.UVALUE) [ 0, 8 ];
ip_id =:= optional_ip_id_lsb(ip_id_behavior.UVALUE,
ip_id_indicator.CVALUE) [ 0, 8, 16 ];
tos_tc =:= static_or_irreg(tos_tc_indicator.CVALUE, 8) [ 0, 8 ];
ttl_hopl =:= static_or_irreg(ttl_hopl_indicator.CVALUE,
ttl_hopl.ULENGTH) [ 0, 8 ];
sequence_number =:= irregular(32) [ 32 ];
}
// UO-0
COMPRESSED pt_0_crc3 {
discriminator =:= '0' [ 1 ];
msn =:= msn_lsb(4) [ 4 ];
header_crc =:= crc3(THIS.UVALUE, THIS.ULENGTH) [ 3 ];
ip_id =:= inferred_sequential_ip_id [ 0 ];
}
// New format, Type 0 with strong CRC and more SN bits
COMPRESSED pt_0_crc7 {
discriminator =:= '100' [ 3 ];
msn =:= msn_lsb(6) [ 6 ];
header_crc =:= crc7(THIS.UVALUE, THIS.ULENGTH) [ 7 ];
ip_id =:= inferred_sequential_ip_id [ 0 ];
}
// UO-1-ID replacement (PT-1 only used for sequential)
COMPRESSED pt_1_seq_id {
ENFORCE((ip_id_behavior.UVALUE == IP_ID_BEHAVIOR_SEQUENTIAL) ||
(ip_id_behavior.UVALUE ==
IP_ID_BEHAVIOR_SEQUENTIAL_SWAPPED));
Pelletier & Sandlund Expires November 26, 2007 [Page 86]
Internet-Draft RoHCv2 Profiles May 2007
discriminator =:= '101' [ 3 ];
header_crc =:= crc3(THIS.UVALUE, THIS.ULENGTH) [ 3 ];
msn =:= msn_lsb(6) [ 6 ];
ip_id =:= ip_id_lsb(ip_id_behavior.UVALUE, 4) [ 4 ];
}
// UOR-2 replacement
COMPRESSED pt_2_rnd {
ENFORCE((ip_id_behavior.UVALUE == IP_ID_BEHAVIOR_RANDOM) ||
(ip_id_behavior.UVALUE == IP_ID_BEHAVIOR_ZERO));
discriminator =:= '110' [ 3 ];
msn =:= msn_lsb(6) [ 6 ];
header_crc =:= crc7(THIS.UVALUE, THIS.ULENGTH) [ 7 ];
}
// UOR-2-ID replacement
COMPRESSED pt_2_seq_id {
ENFORCE((ip_id_behavior.UVALUE == IP_ID_BEHAVIOR_SEQUENTIAL) ||
(ip_id_behavior.UVALUE ==
IP_ID_BEHAVIOR_SEQUENTIAL_SWAPPED));
discriminator =:= '1100' [ 4 ];
ip_id =:= ip_id_lsb(ip_id_behavior.UVALUE, 5) [ 5 ];
header_crc =:= crc7(THIS.UVALUE, THIS.ULENGTH) [ 7 ];
msn =:= msn_lsb(8) [ 8 ];
}
}
////////////////////////////////////////////
// IP-only profile
////////////////////////////////////////////
iponly_baseheader(profile, outer_ip_flag, repair_flag)
{
UNCOMPRESSED v4 {
outer_headers =:= baseheader_outer_headers [ VARIABLE ];
ip_version =:= uncompressed_value(4, 4) [ 4 ];
header_length =:= uncompressed_value(4, 5) [ 4 ];
tos_tc [ 8 ];
length =:= inferred_ip_v4_length [ 16 ];
ip_id [ 16 ];
rf =:= uncompressed_value(1, 0) [ 1 ];
df [ 1 ];
mf =:= uncompressed_value(1, 0) [ 1 ];
frag_offset =:= uncompressed_value(13, 0) [ 13 ];
ttl_hopl [ 8 ];
next_header [ 8 ];
ip_checksum =:= inferred_ip_v4_header_checksum [ 16 ];
src_addr [ 32 ];
Pelletier & Sandlund Expires November 26, 2007 [Page 87]
Internet-Draft RoHCv2 Profiles May 2007
dest_addr [ 32 ];
extension_headers =:= baseheader_extension_headers [ VARIABLE ];
}
UNCOMPRESSED v6 {
ENFORCE(ip_id_behavior.UVALUE == IP_ID_BEHAVIOR_RANDOM);
outer_headers =:= baseheader_outer_headers [ VARIABLE ];
ip_version =:= uncompressed_value(4, 6) [ 4 ];
tos_tc [ 8 ];
flow_label [ 20 ];
payload_length =:= inferred_ip_v6_length [ 16 ];
next_header [ 8 ];
ttl_hopl [ 8 ];
src_addr [ 128 ];
dest_addr [ 128 ];
extension_headers =:= baseheader_extension_headers [ VARIABLE ];
}
CONTROL {
ENFORCE(profile == PROFILE_IP_0104);
ip_id_behavior [ 2 ];
}
DEFAULT {
ENFORCE(outer_ip_indicator == 0);
ENFORCE(repair_flag == 0);
tos_tc =:= static;
dest_addr =:= static;
ttl_hopl =:= static;
src_addr =:= static;
df =:= static;
ip_id_behavior =:= static;
flow_label =:= static;
next_header =:= static;
}
// Replacement for UOR-2-ext3
COMPRESSED co_common {
ENFORCE(repair_flag == 0);
ENFORCE(outer_ip_flag == outer_ip_indicator.CVALUE);
ENFORCE(repair_flag == repair_indicator.CVALUE);
discriminator =:= '11111010' [ 8 ];
ip_id_indicator =:= irregular(1) [ 1 ];
header_crc =:= crc7(THIS.UVALUE, THIS.ULENGTH) [ 7 ];
flags_indicator =:= irregular(1) [ 1 ];
ttl_hopl_indicator =:= irregular(1) [ 1 ];
tos_tc_indicator =:= irregular(1) [ 1 ];
reorder_ratio =:= reorder_choice [ 2 ];
Pelletier & Sandlund Expires November 26, 2007 [Page 88]
Internet-Draft RoHCv2 Profiles May 2007
control_crc3 =:= control_crc3_encoding [ 3 ];
outer_ip_indicator : repair_indicator : df :
ip_id_behavior =:= profile_2_3_4_flags_enc(
flags_indicator.CVALUE, ip_version.UVALUE) [ 0, 8 ];
ip_id =:= optional_ip_id_lsb(ip_id_behavior.UVALUE,
ip_id_indicator.CVALUE) [ 0, 8, 16 ];
tos_tc =:= static_or_irreg(tos_tc_indicator.CVALUE, 8) [ 0, 8 ];
ttl_hopl =:= static_or_irreg(ttl_hopl_indicator.CVALUE,
ttl_hopl.ULENGTH) [ 0, 8 ];
msn =:= msn_lsb(8) [ 8 ];
}
// Context repair (IR-DYN replacement).
COMPRESSED co_repair {
ENFORCE(outer_ip_flag == outer_ip_indicator.CVALUE);
ENFORCE(repair_flag == repair_indicator.CVALUE);
discriminator =:= '11111011' [ 8 ];
ip_id_indicator =:= irregular(1) [ 1 ];
header_crc =:= crc7(THIS.UVALUE, THIS.ULENGTH) [ 7 ];
flags_indicator =:= irregular(1) [ 1 ];
ttl_hopl_indicator =:= irregular(1) [ 1 ];
tos_tc_indicator =:= irregular(1) [ 1 ];
reorder_ratio =:= reorder_choice [ 2 ];
control_crc3 =:= control_crc3_encoding [ 3 ];
outer_ip_indicator : repair_indicator : df :
ip_id_behavior =:= profile_2_3_4_flags_enc(
flags_indicator.CVALUE, ip_version.UVALUE) [ 0, 8 ];
ip_id =:= optional_ip_id_lsb(ip_id_behavior.UVALUE,
ip_id_indicator.CVALUE) [ 0, 8, 16 ];
tos_tc =:= static_or_irreg(tos_tc_indicator.CVALUE, 8) [ 0, 8 ];
ttl_hopl =:= static_or_irreg(ttl_hopl_indicator.CVALUE,
ttl_hopl.ULENGTH) [ 0, 8 ];
msn =:= irregular(16) [ 16 ];
}
// UO-0
COMPRESSED pt_0_crc3 {
discriminator =:= '0' [ 1 ];
msn =:= msn_lsb(4) [ 4 ];
header_crc =:= crc3(THIS.UVALUE, THIS.ULENGTH) [ 3 ];
ip_id =:= inferred_sequential_ip_id [ 0 ];
}
// New format, Type 0 with strong CRC and more SN bits
COMPRESSED pt_0_crc7 {
discriminator =:= '100' [ 3 ];
msn =:= msn_lsb(6) [ 6 ];
header_crc =:= crc7(THIS.UVALUE, THIS.ULENGTH) [ 7 ];
Pelletier & Sandlund Expires November 26, 2007 [Page 89]
Internet-Draft RoHCv2 Profiles May 2007
ip_id =:= inferred_sequential_ip_id [ 0 ];
}
// UO-1-ID replacement (PT-1 only used for sequential)
COMPRESSED pt_1_seq_id {
ENFORCE((ip_id_behavior.UVALUE == IP_ID_BEHAVIOR_SEQUENTIAL) ||
(ip_id_behavior.UVALUE ==
IP_ID_BEHAVIOR_SEQUENTIAL_SWAPPED));
discriminator =:= '101' [ 3 ];
header_crc =:= crc3(THIS.UVALUE, THIS.ULENGTH) [ 3 ];
msn =:= msn_lsb(6) [ 6 ];
ip_id =:= ip_id_lsb(ip_id_behavior.UVALUE, 4) [ 4 ];
}
// UOR-2 replacement
COMPRESSED pt_2_rnd {
ENFORCE((ip_id_behavior.UVALUE == IP_ID_BEHAVIOR_RANDOM) ||
(ip_id_behavior.UVALUE == IP_ID_BEHAVIOR_ZERO));
discriminator =:= '110' [ 3 ];
msn =:= msn_lsb(6) [ 6 ];
header_crc =:= crc7(THIS.UVALUE, THIS.ULENGTH) [ 7 ];
}
// UOR-2-ID replacement
COMPRESSED pt_2_seq_id {
ENFORCE((ip_id_behavior.UVALUE == IP_ID_BEHAVIOR_SEQUENTIAL) ||
(ip_id_behavior.UVALUE ==
IP_ID_BEHAVIOR_SEQUENTIAL_SWAPPED));
discriminator =:= '1100' [ 4 ];
ip_id =:= ip_id_lsb(ip_id_behavior.UVALUE, 5) [ 5 ];
header_crc =:= crc7(THIS.UVALUE, THIS.ULENGTH) [ 7 ];
msn =:= msn_lsb(8) [ 8 ];
}
}
////////////////////////////////////////////
// UDP-lite/RTP profile
////////////////////////////////////////////
udplite_rtp_baseheader(profile, ts_stride_value, time_stride_value,
outer_ip_flag, repair_flag)
{
UNCOMPRESSED v4 {
ENFORCE(msn.UVALUE == sequence_number.UVALUE);
outer_headers =:= baseheader_outer_headers [ VARIABLE ];
ip_version =:= uncompressed_value(4, 4) [ 4 ];
header_length =:= uncompressed_value(4, 5) [ 4 ];
tos_tc [ 8 ];
Pelletier & Sandlund Expires November 26, 2007 [Page 90]
Internet-Draft RoHCv2 Profiles May 2007
length =:= inferred_ip_v4_length [ 16 ];
ip_id [ 16 ];
rf =:= uncompressed_value(1, 0) [ 1 ];
df [ 1 ];
mf =:= uncompressed_value(1, 0) [ 1 ];
frag_offset =:= uncompressed_value(13, 0) [ 13 ];
ttl_hopl [ 8 ];
next_header [ 8 ];
ip_checksum =:= inferred_ip_v4_header_checksum [ 16 ];
src_addr [ 32 ];
dest_addr [ 32 ];
extension_headers =:= baseheader_extension_headers [ VARIABLE ];
src_port [ 16 ];
dst_port [ 16 ];
checksum_coverage [ 16 ];
udp_checksum [ 16 ];
rtp_version =:= uncompressed_value(2, 2) [ 2 ];
pad_bit [ 1 ];
extension [ 1 ];
cc [ 4 ];
marker [ 1 ];
payload_type [ 7 ];
sequence_number [ 16 ];
timestamp [ 32 ];
ssrc [ 32 ];
csrc_list [ VARIABLE ];
}
UNCOMPRESSED v6 {
ENFORCE(ip_id_behavior.UVALUE == IP_ID_BEHAVIOR_RANDOM);
outer_headers =:= baseheader_outer_headers [ VARIABLE ];
ip_version =:= uncompressed_value(4, 6) [ 4 ];
tos_tc [ 8 ];
flow_label [ 20 ];
payload_length =:= inferred_ip_v6_length [ 16 ];
next_header [ 8 ];
ttl_hopl [ 8 ];
src_addr [ 128 ];
dest_addr [ 128 ];
extension_headers =:= baseheader_extension_headers [ VARIABLE ];
src_port [ 16 ];
dst_port [ 16 ];
checksum_coverage [ 16 ];
udp_checksum [ 16 ];
rtp_version =:= uncompressed_value(2, 2) [ 2 ];
pad_bit [ 1 ];
extension [ 1 ];
cc [ 4 ];
Pelletier & Sandlund Expires November 26, 2007 [Page 91]
Internet-Draft RoHCv2 Profiles May 2007
marker [ 1 ];
payload_type [ 7 ];
sequence_number [ 16 ];
timestamp [ 32 ];
ssrc [ 32 ];
csrc_list [ VARIABLE ];
}
CONTROL {
ENFORCE(time_stride_value == time_stride.UVALUE);
ENFORCE(ts_stride.UVALUE == ts_stride_value);
ENFORCE(profile == PROFILE_RTP_0107);
ip_id_behavior [ 2 ];
coverage_behavior [ 2 ];
ts_stride [ 32 ];
time_stride [ 32 ];
ts_scaled [ 32 ];
ts_offset =:= field_scaling(ts_stride.UVALUE, ts_scaled.UVALUE,
timestamp.UVALUE) [ 32 ];
}
DEFAULT {
ENFORCE(outer_ip_indicator == 0);
ENFORCE(repair_flag == 0);
tos_tc =:= static;
dest_addr =:= static;
ttl_hopl =:= static;
src_addr =:= static;
df =:= static;
ip_id_behavior =:= static;
flow_label =:= static;
next_header =:= static;
src_port =:= static;
dst_port =:= static;
checksum_coverage =:= irregular(16);
udp_checksum =:= irregular(16);
pad_bit =:= static;
extension =:= static;
cc =:= static;
// When marker not present in packets, it is assumed 0
marker =:= uncompressed_value(1, 0);
payload_type =:= static;
sequence_number =:= static;
timestamp =:= static;
ssrc =:= static;
csrc_list =:= static;
}
Pelletier & Sandlund Expires November 26, 2007 [Page 92]
Internet-Draft RoHCv2 Profiles May 2007
// Replacement for UOR-2-ext3
COMPRESSED co_common {
ENFORCE(repair_flag == 0);
ENFORCE(outer_ip_flag == outer_ip_indicator.CVALUE);
ENFORCE(repair_flag == repair_indicator.CVALUE);
discriminator =:= '11111010' [ 8 ];
marker =:= irregular(1) [ 1 ];
header_crc =:= crc7(THIS.UVALUE, THIS.ULENGTH) [ 7 ];
flags1_indicator =:= irregular(1) [ 1 ];
flags2_indicator =:= irregular(1) [ 1 ];
tsc_indicator =:= irregular(1) [ 1 ];
tss_indicator =:= irregular(1) [ 1 ];
ip_id_indicator =:= irregular(1) [ 1 ];
control_crc3 =:= control_crc3_encoding [ 3 ];
outer_ip_indicator : repair_indicator : ttl_hopl_indicator :
tos_tc_indicator : ip_id_behavior : reorder_ratio =:=
profile_1_7_flags1_enc(flags1_indicator.CVALUE) [ 0, 8 ];
list_indicator : tis_indicator : pt_indicator : pad_bit :
extension : df : coverage_behavior =:=
profile_7_flags2_enc(flags2_indicator.CVALUE,
ip_version.UVALUE) [ 0, 8 ];
ip_id =:= optional_ip_id_lsb(ip_id_behavior.UVALUE,
ip_id_indicator.CVALUE) [ 0, 8, 16 ];
tos_tc =:= static_or_irreg(tos_tc_indicator.CVALUE, 8) [ 0, 8 ];
ttl_hopl =:= static_or_irreg(ttl_hopl_indicator.CVALUE,
ttl_hopl.ULENGTH) [ 0, 8 ];
payload_type =:= optional_pt(pt_indicator.CVALUE) [ 0, 8 ];
sequence_number =:= sdvl_lsb(sequence_number.ULENGTH) [ 8, 16, 24 ];
ts_scaled =:= variable_scaled_timestamp(tss_indicator.CVALUE,
tsc_indicator.CVALUE, ts_stride.UVALUE) [ VARIABLE ];
timestamp =:= variable_unscaled_timestamp(tss_indicator.CVALUE,
tsc_indicator.CVALUE) [ VARIABLE ];
ts_stride =:= sdvl_or_static(tss_indicator.CVALUE) [ VARIABLE ];
time_stride =:= sdvl_or_static(tis_indicator.CVALUE) [ VARIABLE ];
csrc_list =:=
csrc_list_presence(list_indicator.CVALUE,
cc.UVALUE) [ VARIABLE ];
}
// Context repair (IR-DYN replacement).
COMPRESSED co_repair {
ENFORCE(outer_ip_flag == outer_ip_indicator.CVALUE);
ENFORCE(repair_flag == repair_indicator.CVALUE);
discriminator =:= '11111011' [ 8 ];
marker =:= irregular(1) [ 1 ];
header_crc =:= crc7(THIS.UVALUE, THIS.ULENGTH) [ 7 ];
flags1_indicator =:= irregular(1) [ 1 ];
Pelletier & Sandlund Expires November 26, 2007 [Page 93]
Internet-Draft RoHCv2 Profiles May 2007
flags2_indicator =:= irregular(1) [ 1 ];
timestamp_indicator =:= irregular(1) [ 1 ];
tss_indicator =:= irregular(1) [ 1 ];
ip_id_indicator =:= irregular(1) [ 1 ];
control_crc3 =:= control_crc3_encoding [ 3 ];
outer_ip_indicator : repair_indicator : ttl_hopl_indicator :
tos_tc_indicator : ip_id_behavior : reorder_ratio =:=
profile_1_7_flags1_enc(flags1_indicator.CVALUE) [ 0, 8 ];
list_indicator : tis_indicator : pt_indicator : pad_bit :
extension : df : coverage_behavior =:=
profile_7_flags2_enc(flags2_indicator.CVALUE,
ip_version.UVALUE) [ 0, 8 ];
ip_id =:= optional_ip_id_lsb(ip_id_behavior.UVALUE,
ip_id_indicator.CVALUE) [ 0, 8, 16 ];
tos_tc =:= static_or_irreg(tos_tc_indicator.CVALUE, 8) [ 0, 8 ];
ttl_hopl =:= static_or_irreg(ttl_hopl_indicator.CVALUE,
ttl_hopl.ULENGTH) [ 0, 8 ];
payload_type =:= optional_pt(pt_indicator.CVALUE) [ 0, 8 ];
sequence_number =:= irregular(16) [ 16 ];
timestamp =:=
irregular_or_nothing(timestamp_indicator.CVALUE) [ 0, 32 ];
ts_stride =:= sdvl_or_static(tss_indicator.CVALUE) [ VARIABLE ];
time_stride =:= sdvl_or_static(tis_indicator.CVALUE) [ VARIABLE ];
csrc_list =:= csrc_list_presence(list_indicator.CVALUE,
cc.UVALUE) [ VARIABLE ];
}
// UO-0
COMPRESSED pt_0_crc3 {
discriminator =:= '0' [ 1 ];
msn =:= msn_lsb(4) [ 4 ];
header_crc =:= crc3(THIS.UVALUE, THIS.ULENGTH) [ 3 ];
timestamp =:= inferred_scaled_field [ 0 ];
ip_id =:= inferred_sequential_ip_id [ 0 ];
}
// New format, Type 0 with strong CRC and more SN bits
COMPRESSED pt_0_crc7 {
discriminator =:= '100' [ 3 ];
msn =:= msn_lsb(6) [ 6 ];
header_crc =:= crc7(THIS.UVALUE, THIS.ULENGTH) [ 7 ];
timestamp =:= inferred_scaled_field [ 0 ];
ip_id =:= inferred_sequential_ip_id [ 0 ];
}
// UO-1 replacement
Pelletier & Sandlund Expires November 26, 2007 [Page 94]
Internet-Draft RoHCv2 Profiles May 2007
COMPRESSED pt_1_rnd {
ENFORCE((ip_id_behavior.UVALUE == IP_ID_BEHAVIOR_RANDOM) ||
(ip_id_behavior.UVALUE == IP_ID_BEHAVIOR_ZERO));
discriminator =:= '101' [ 3 ];
msn =:= msn_lsb(5) [ 5 ];
marker =:= irregular(1) [ 1 ];
ts_scaled =:= scaled_ts_lsb(time_stride.UVALUE, 4) [ 4 ];
header_crc =:= crc3(THIS.UVALUE, THIS.ULENGTH) [ 3 ];
}
// UO-1-ID replacement
COMPRESSED pt_1_seq_id {
ENFORCE((ip_id_behavior.UVALUE == IP_ID_BEHAVIOR_SEQUENTIAL) ||
(ip_id_behavior.UVALUE ==
IP_ID_BEHAVIOR_SEQUENTIAL_SWAPPED));
discriminator =:= '1010' [ 4 ];
header_crc =:= crc3(THIS.UVALUE, THIS.ULENGTH) [ 3 ];
msn =:= msn_lsb(5) [ 5 ];
ip_id =:= ip_id_lsb(ip_id_behavior.UVALUE, 4) [ 4 ];
timestamp =:= inferred_scaled_field [ 0 ];
}
// UO-1-TS replacement
COMPRESSED pt_1_seq_ts {
ENFORCE(ts_stride.UVALUE != 0);
ENFORCE((ip_id_behavior.UVALUE == IP_ID_BEHAVIOR_SEQUENTIAL) ||
(ip_id_behavior.UVALUE ==
IP_ID_BEHAVIOR_SEQUENTIAL_SWAPPED));
discriminator =:= '1011' [ 4 ];
marker =:= irregular(1) [ 1 ];
header_crc =:= crc3(THIS.UVALUE, THIS.ULENGTH) [ 3 ];
msn =:= msn_lsb(4) [ 4 ];
ts_scaled =:= scaled_ts_lsb(time_stride.UVALUE, 4) [ 4 ];
}
// UOR-2 replacement
COMPRESSED pt_2_rnd {
ENFORCE(ts_stride.UVALUE != 0);
ENFORCE((ip_id_behavior.UVALUE == IP_ID_BEHAVIOR_RANDOM) ||
(ip_id_behavior.UVALUE == IP_ID_BEHAVIOR_ZERO));
discriminator =:= '110' [ 3 ];
msn =:= msn_lsb(7) [ 7 ];
ts_scaled =:= scaled_ts_lsb(time_stride.UVALUE, 6) [ 6 ];
marker =:= irregular(1) [ 1 ];
header_crc =:= crc7(THIS.UVALUE, THIS.ULENGTH) [ 7 ];
}
// UOR-2-ID replacement
Pelletier & Sandlund Expires November 26, 2007 [Page 95]
Internet-Draft RoHCv2 Profiles May 2007
COMPRESSED pt_2_seq_id {
ENFORCE((ip_id_behavior.UVALUE == IP_ID_BEHAVIOR_SEQUENTIAL) ||
(ip_id_behavior.UVALUE ==
IP_ID_BEHAVIOR_SEQUENTIAL_SWAPPED));
discriminator =:= '11000' [ 5 ];
msn =:= msn_lsb(7) [ 7 ];
ip_id =:= ip_id_lsb(ip_id_behavior.UVALUE, 5) [ 5 ];
header_crc =:= crc7(THIS.UVALUE, THIS.ULENGTH) [ 7 ];
timestamp =:= inferred_scaled_field [ 0 ];
}
// UOR-2-ID-ext1 replacement (both TS and IP-ID)
COMPRESSED pt_2_seq_both {
ENFORCE(ts_stride.UVALUE != 0);
ENFORCE((ip_id_behavior.UVALUE == IP_ID_BEHAVIOR_SEQUENTIAL) ||
(ip_id_behavior.UVALUE ==
IP_ID_BEHAVIOR_SEQUENTIAL_SWAPPED));
discriminator =:= '11001' [ 5 ];
msn =:= msn_lsb(7) [ 7 ];
ip_id =:= ip_id_lsb(ip_id_behavior.UVALUE, 5) [ 5 ];
header_crc =:= crc7(THIS.UVALUE, THIS.ULENGTH) [ 7 ];
ts_scaled =:= scaled_ts_lsb(time_stride.UVALUE, 8) [ 8 ];
}
// UOR-2-TS replacement
COMPRESSED pt_2_seq_ts {
ENFORCE(ts_stride.UVALUE != 0);
ENFORCE((ip_id_behavior.UVALUE == IP_ID_BEHAVIOR_SEQUENTIAL) ||
(ip_id_behavior.UVALUE ==
IP_ID_BEHAVIOR_SEQUENTIAL_SWAPPED));
discriminator =:= '1101' [ 4 ];
msn =:= msn_lsb(7) [ 7 ];
ts_scaled =:= scaled_ts_lsb(time_stride.UVALUE, 5) [ 5 ];
marker =:= irregular(1) [ 1 ];
header_crc =:= crc7(THIS.UVALUE, THIS.ULENGTH) [ 7 ];
}
}
////////////////////////////////////////////
// UDP-lite profile
////////////////////////////////////////////
udplite_baseheader(profile, outer_ip_flag, repair_flag)
{
UNCOMPRESSED v4 {
outer_headers =:= baseheader_outer_headers [ VARIABLE ];
ip_version =:= uncompressed_value(4, 4) [ 4 ];
header_length =:= uncompressed_value(4, 5) [ 4 ];
Pelletier & Sandlund Expires November 26, 2007 [Page 96]
Internet-Draft RoHCv2 Profiles May 2007
tos_tc [ 8 ];
length =:= inferred_ip_v4_length [ 16 ];
ip_id [ 16 ];
rf =:= uncompressed_value(1, 0) [ 1 ];
df [ 1 ];
mf =:= uncompressed_value(1, 0) [ 1 ];
frag_offset =:= uncompressed_value(13, 0) [ 13 ];
ttl_hopl [ 8 ];
next_header [ 8 ];
ip_checksum =:= inferred_ip_v4_header_checksum [ 16 ];
src_addr [ 32 ];
dest_addr [ 32 ];
extension_headers =:= baseheader_extension_headers [ VARIABLE ];
src_port [ 16 ];
dst_port [ 16 ];
checksum_coverage [ 16 ];
udp_checksum [ 16 ];
}
UNCOMPRESSED v6 {
ENFORCE(ip_id_behavior.UVALUE == IP_ID_BEHAVIOR_RANDOM);
outer_headers =:= baseheader_outer_headers [ VARIABLE ];
ip_version =:= uncompressed_value(4, 6) [ 4 ];
tos_tc [ 8 ];
flow_label [ 20 ];
payload_length =:= inferred_ip_v6_length [ 16 ];
next_header [ 8 ];
ttl_hopl [ 8 ];
src_addr [ 128 ];
dest_addr [ 128 ];
extension_headers =:= baseheader_extension_headers [ VARIABLE ];
src_port [ 16 ];
dst_port [ 16 ];
checksum_coverage [ 16 ];
udp_checksum [ 16 ];
}
CONTROL {
ENFORCE(profile == PROFILE_UDPLITE_0108);
ip_id_behavior [ 2 ];
coverage_behavior [ 2 ];
}
DEFAULT {
ENFORCE(outer_ip_indicator == 0);
ENFORCE(repair_flag == 0);
tos_tc =:= static;
dest_addr =:= static;
Pelletier & Sandlund Expires November 26, 2007 [Page 97]
Internet-Draft RoHCv2 Profiles May 2007
ttl_hopl =:= static;
src_addr =:= static;
df =:= static;
ip_id_behavior =:= static;
flow_label =:= static;
next_header =:= static;
src_port =:= static;
dst_port =:= static;
checksum_coverage =:= irregular(16);
udp_checksum =:= irregular(16);
}
// Replacement for UOR-2-ext3
COMPRESSED co_common {
ENFORCE(repair_flag == 0);
ENFORCE(outer_ip_flag == outer_ip_indicator.CVALUE);
ENFORCE(repair_flag == repair_indicator.CVALUE);
discriminator =:= '11111010' [ 8 ];
reorder_ratio =:= reorder_choice [ 2 ];
ip_id_indicator =:= irregular(1) [ 1 ];
header_crc =:= crc7(THIS.UVALUE, THIS.ULENGTH) [ 7 ];
flags_indicator =:= irregular(1) [ 1 ];
ttl_hopl_indicator =:= irregular(1) [ 1 ];
tos_tc_indicator =:= irregular(1) [ 1 ];
control_crc3 =:= control_crc3_encoding [ 3 ];
outer_ip_indicator : repair_indicator : df :
ip_id_behavior : coverage_behavior =:=
profile_8_flags_enc(flags_indicator.CVALUE) [ 0, 8 ];
ip_id =:= optional_ip_id_lsb(ip_id_behavior.UVALUE,
ip_id_indicator.CVALUE) [ 0, 8, 16 ];
tos_tc =:= static_or_irreg(tos_tc_indicator.CVALUE, 8) [ 0, 8 ];
ttl_hopl =:= static_or_irreg(ttl_hopl_indicator.CVALUE,
ttl_hopl.ULENGTH) [ 0, 8 ];
msn =:= msn_lsb(8) [ 8 ];
}
// Context repair (IR-DYN replacement).
COMPRESSED co_repair {
ENFORCE(outer_ip_flag == outer_ip_indicator.CVALUE);
ENFORCE(repair_flag == repair_indicator.CVALUE);
discriminator =:= '11111011' [ 8 ];
reorder_ratio =:= reorder_choice [ 2 ];
ip_id_indicator =:= irregular(1) [ 1 ];
header_crc =:= crc7(THIS.UVALUE, THIS.ULENGTH) [ 7 ];
flags_indicator =:= irregular(1) [ 1 ];
ttl_hopl_indicator =:= irregular(1) [ 1 ];
tos_tc_indicator =:= irregular(1) [ 1 ];
control_crc3 =:= control_crc3_encoding [ 3 ];
Pelletier & Sandlund Expires November 26, 2007 [Page 98]
Internet-Draft RoHCv2 Profiles May 2007
outer_ip_indicator : repair_indicator : df :
ip_id_behavior : coverage_behavior =:=
profile_8_flags_enc(flags_indicator.CVALUE) [ 0, 8 ];
msn =:= msn_lsb(16) [ 8 ];
ip_id =:= optional_ip_id_lsb(ip_id_behavior.UVALUE,
ip_id_indicator.CVALUE) [ 0, 8, 16 ];
tos_tc =:= static_or_irreg(tos_tc_indicator.CVALUE, 8) [ 0, 8 ];
ttl_hopl =:= static_or_irreg(ttl_hopl_indicator.CVALUE,
ttl_hopl.ULENGTH) [ 0, 8 ];
}
// UO-0
COMPRESSED pt_0_crc3 {
discriminator =:= '0' [ 1 ];
msn =:= msn_lsb(4) [ 4 ];
header_crc =:= crc3(THIS.UVALUE, THIS.ULENGTH) [ 3 ];
ip_id =:= inferred_sequential_ip_id [ 0 ];
}
// New format, Type 0 with strong CRC and more SN bits
COMPRESSED pt_0_crc7 {
discriminator =:= '100' [ 3 ];
msn =:= msn_lsb(6) [ 6 ];
header_crc =:= crc7(THIS.UVALUE, THIS.ULENGTH) [ 7 ];
ip_id =:= inferred_sequential_ip_id [ 0 ];
}
// UO-1-ID replacement (PT-1 only used for sequential)
COMPRESSED pt_1_seq_id {
ENFORCE((ip_id_behavior.UVALUE == IP_ID_BEHAVIOR_SEQUENTIAL) ||
(ip_id_behavior.UVALUE ==
IP_ID_BEHAVIOR_SEQUENTIAL_SWAPPED));
discriminator =:= '101' [ 3 ];
header_crc =:= crc3(THIS.UVALUE, THIS.ULENGTH) [ 3 ];
msn =:= msn_lsb(6) [ 6 ];
ip_id =:= ip_id_lsb(ip_id_behavior.UVALUE, 4) [ 4 ];
}
// UOR-2 replacement
COMPRESSED pt_2_rnd {
ENFORCE((ip_id_behavior.UVALUE == IP_ID_BEHAVIOR_RANDOM) ||
(ip_id_behavior.UVALUE == IP_ID_BEHAVIOR_ZERO));
discriminator =:= '110' [ 3 ];
msn =:= msn_lsb(6) [ 6 ];
header_crc =:= crc7(THIS.UVALUE, THIS.ULENGTH) [ 7 ];
}
// UOR-2-ID replacement
Pelletier & Sandlund Expires November 26, 2007 [Page 99]
Internet-Draft RoHCv2 Profiles May 2007
COMPRESSED pt_2_seq_id {
ENFORCE((ip_id_behavior.UVALUE == IP_ID_BEHAVIOR_SEQUENTIAL) ||
(ip_id_behavior.UVALUE ==
IP_ID_BEHAVIOR_SEQUENTIAL_SWAPPED));
discriminator =:= '1100' [ 4 ];
ip_id =:= ip_id_lsb(ip_id_behavior.UVALUE, 5) [ 5 ];
header_crc =:= crc7(THIS.UVALUE, THIS.ULENGTH) [ 7 ];
msn =:= msn_lsb(8) [ 8 ];
}
}
6.9. Feedback Formats and Options
6.9.1. Feedback Formats
This section describes the feedback format for ROHCv2 profiles, using
the formats described in section 5.2.3 of
[I-D.ietf-rohc-rfc3095bis-framework].
All feedback formats carry a field labelled MSN, which contain LSBs
of the MSN described in Section 6.2.1. The sequence number to use is
the MSN corresponding to the last header that was successfully CRC-8
validated or CRC verified.
FEEDBACK-1
0 1 2 3 4 5 6 7
+---+---+---+---+---+---+---+---+
| MSN |
+---+---+---+---+---+---+---+---+
MSN: The lsb-encoded master sequence number.
A FEEDBACK-1 is an ACK. In order to send a NACK or a STATIC-NACK,
FEEDBACK-2 must be used.
FEEDBACK-2
0 1 2 3 4 5 6 7
+---+---+---+---+---+---+---+---+
|Acktype| MSN |
+---+---+---+---+---+---+---+---+
| MSN |
+---+---+---+---+---+---+---+---+
| CRC |
+---+---+---+---+---+---+---+---+
/ Feedback options /
+---+---+---+---+---+---+---+---+
Pelletier & Sandlund Expires November 26, 2007 [Page 100]
Internet-Draft RoHCv2 Profiles May 2007
Acktype:
0 = ACK
1 = NACK
2 = STATIC-NACK
3 is reserved (MUST NOT be used for parsability)
MSN: The lsb-encoded master sequence number.
CRC: 8-bit CRC computed over the entire feedback payload including
any CID fields but excluding the packet type, the 'Size' field and
the 'Code' octet, using the polynomial defined in
[I-D.ietf-rohc-rfc3095bis-framework]. If the CID is given with an
Add-CID octet, the Add-CID octet immediately precedes the
FEEDBACK-1 or FEEDBACK-2 format. For purposes of computing the
CRC, the CRC field is zero.
Feedback options: A variable number of feedback options, see
Section 6.9.2. Options may appear in any order.
A FEEDBACK-2 of type NACK or STATIC-NACK is always implicitely an
acknowlegement for a successfully decompressed packet, which packet
corresponds to the MSN of the feedback element, unless the MSN-NOT-
VALID option Section 6.9.2.2 appears in the feedback element.
The FEEDBACK-2 format always carry a CRC and is thus more robust than
the FEEDBACK-1 format. When receiving FEEDBACK-2, the compressor
MUST verify the information by computing the CRC and comparing the
result with the CRC carried in the feedback format. If the two are
not identical, the feedback element MUST be discarded.
6.9.2. Feedback Options
A feedback option has variable length and the following general
format:
0 1 2 3 4 5 6 7
+---+---+---+---+---+---+---+---+
| Opt Type | Opt Len |
+---+---+---+---+---+---+---+---+
/ option data / Opt Length (octets)
+---+---+---+---+---+---+---+---+
The CRC option contains an 8-bit CRC computed over the entire
feedback payload including any CID fields but excluding the packet
type, the 'Size' field and the 'Code' octet, using the polynomial of
[I-D.ietf-rohc-rfc3095bis-framework], section 5.3.1.1.
Pelletier & Sandlund Expires November 26, 2007 [Page 101]
Internet-Draft RoHCv2 Profiles May 2007
6.9.2.1. The REJECT option
The REJECT option informs the compressor that the decompressor does
not have sufficient resources to handle the flow.
+---+---+---+---+---+---+---+---+
| Opt Type = 2 | Opt Len = 0 |
+---+---+---+---+---+---+---+---+
When receiving a REJECT option, the compressor MUST stop compressing
the packet flow, and SHOULD refrain from attempting to increase the
number of compressed packet flows for some time. Any FEEDBACK packet
carrying a REJECT option MUST also carry a CRC option. The REJECT
option MUST NOT appear more than once in the FEEDBACK-2 format,
otherwise the decompressor MUST discard the entire feedback element.
6.9.2.2. The MSN-NOT-VALID option
The MSN-NOT-VALID option indicates that the MSN of the feedback is
not valid.
+---+---+---+---+---+---+---+---+
| Opt Type = 3 | Opt Len = 0 |
+---+---+---+---+---+---+---+---+
A compressor MUST NOT use the MSN of the feedback to find the
corresponding sent header when this option is present. Consequently,
a NACK or a STATIC-NACK feedback type sent with the MSN-NOT-VALID
option is equivalent to a STATIC-NACK with respect to the type of
context repair requested by the decompressor.
The MSN-NOT-VALID option MUST NOT appear more than once in the
FEEDBACK-2 format and MUST NOT appear in the same feedback element as
the MSN option, otherwise the decompressor MUST discard the entire
feedback element.
6.9.2.3. The MSN option
The MSN option provides 8 additional bits of MSN.
+---+---+---+---+---+---+---+---+
| Opt Type = 4 | Opt Len = 1 |
+---+---+---+---+---+---+---+---+
| MSN |
+---+---+---+---+---+---+---+---+
the bits in the MSN option are concatenated with the MSN bits in the
FEEDBACK-2 format, with the bits in the FEEDBACK-2 format being the
Pelletier & Sandlund Expires November 26, 2007 [Page 102]
Internet-Draft RoHCv2 Profiles May 2007
most significant bits. The MSN option MAY appear more than once in
the FEEDBACK-2 format, in which case the MSN is given by
concatenating the MSN fields of each occurance of the MSN option.
The MSN option MUST NOT appear in the same feedback element as the
MSN-NOT-VALID option, otherwise the decompressor MUST discard the
entire feedback element.
6.9.2.4. The CONTEXT_MEMORY Feedback Option
The CONTEXT_MEMORY option informs the compressor that the
decompressor does not have sufficient memory resources to handle the
context of the packet flow, as the flow is currently compressed.
0 1 2 3 4 5 6 7
+---+---+---+---+---+---+---+---+
| Opt Type = 9 | Opt Len = 0 |
+---+---+---+---+---+---+---+---+
When receiving a CONTEXT_MEMORY option, the compressor SHOULD take
actions to compress the packet flow in a way that requires less
decompressor memory resources, or stop compressing the packet flow.
The CONTEXT_MEMORY option MUST NOT appear more than once in the
FEEDBACK-2 format, otherwise the decompressor MUST discard the entire
feedback element.
6.9.2.5. The CONTROL_FIELDS_UPDATE Feedback Option
The CONTROL_FIELDS_UPDATE option informs the compressor that the
decompressor considers its set of control fields to be invalid, or
that those have not been established.
0 1 2 3 4 5 6 7
+---+---+---+---+---+---+---+---+
| Opt Type = 10 | Opt Len = 0 |
+---+---+---+---+---+---+---+---+
When receiving the CONTROL_FIELDS_UPDATE option in a feedback
element, the compressor SHOULD select a packet format that can update
the control fields covered by the control_crc3 encoding method
Section 6.6.11.
The CONTROL_FIELDS_UPDATE option MUST NOT appear more than once in
the FEEDBACK-2 format, otherwise the decompressor MUST discard the
entire feedback element.
Pelletier & Sandlund Expires November 26, 2007 [Page 103]
Internet-Draft RoHCv2 Profiles May 2007
6.9.2.6. Unknown option types
If an option type unknown to the compressor is encountered, it must
continue parsing the rest of the FEEDBACK packet, which is possible
since the length of the option is explicit, but MUST otherwise ignore
the unknown option.
7. Security Considerations
Because encryption eliminates the redundancy that header compression
schemes try to exploit, there is some inducement to forego encryption
of headers in order to enable operation over low-bandwidth links.
However, for those cases where encryption of data (and not headers)
is sufficient, RTP does specify an alternative encryption method in
which only the RTP payload is encrypted and the headers are left in
the clear. That would still allow header compression to be applied.
ROHC compression is transparent with regard to the RTP Sequence
Number and RTP Timestamp fields, so the values of those fields can be
used as the basis of payload encryption schemes (e.g., for
computation of an initialization vector).
A malfunctioning or malicious header compressor could cause the
header decompressor to reconstitute packets that do not match the
original packets but still have valid IP, UDP and RTP headers and
possibly also valid UDP checksums. Such corruption may be detected
with end-to-end authentication and integrity mechanisms which will
not be affected by the compression. Moreover, this header
compression scheme uses an internal checksum for verification of
reconstructed headers. This reduces the probability of producing
decompressed headers not matching the original ones without this
being noticed.
Denial-of-service attacks are possible if an intruder can introduce
(for example) bogus IR, IR-PD or FEEDBACK packets onto the link and
thereby cause compression efficiency to be reduced. However, an
intruder having the ability to inject arbitrary packets at the link
layer in this manner raises additional security issues that dwarf
those related to the use of header compression.
8. IANA Considerations
The following ROHC profile identifiers have been reserved by the IANA
for the profiles defined in this document:
Pelletier & Sandlund Expires November 26, 2007 [Page 104]
Internet-Draft RoHCv2 Profiles May 2007
Identifier Profile
---------- -------
0x0101 ROHCv2 RTP
0x0102 ROHCv2 UDP
0x0103 ROHCv2 ESP
0x0104 ROHCv2 IP
0x0107 ROHCv2 RTP/UDP-Lite
0x0108 ROHCv2 UDP-Lite
<# Editor's Note: To be removed before publication #>
ROHC profile identifiers must be reserved by the IANA for the updated
profiles defined in this document. A suggested registration in the
"RObust Header Compression (ROHC) Profile Identifiers" name space
would then be:
Profile Identifier Usage Reference
------------------ ---------------------- ---------
0x0000 ROHC uncompressed RFC 3095
0xnn00 Reserved
0x0001 ROHC RTP RFC 3095
0x0101 ROHCv2 RTP [RFCXXXX (this)]
0xnn01 Reserved
0x0002 ROHC UDP RFC 3095
0x0102 ROHCv2 UDP [RFCXXXX (this)]
0xnn02 Reserved
0x0003 ROHC ESP RFC 3095
0x0103 ROHCv2 ESP [RFCXXXX (this)]
0xnn03 Reserved
0x0004 ROHC IP RFC 3843
0x0104 ROHCv2 IP [RFCXXXX (this)]
0xnn04 Reserved
0x0005 ROHC LLA RFC 4362
0x0105 ROHC LLA with R-mode RFC 3408
0xnn05 Reserved
0xnn06 To be Assigned by IANA
0x0007 ROHC RTP/UDP-Lite RFC 4019
0x0107 ROHCv2 RTP/UDP-Lite [RFCXXXX (this)]
0xnn07 Reserved
0x0008 ROHC UDP-Lite RFC 4019
0x0108 ROHCv2 UDP-Lite [RFCXXXX (this)]
0xnn08 Reserved
0x0009-0xnn7F To be Assigned by IANA
0xnn80-0xnnFE To be Assigned by IANA
0xnnFF Reserved
Pelletier & Sandlund Expires November 26, 2007 [Page 105]
Internet-Draft RoHCv2 Profiles May 2007
9. Acknowledgements
The authors would like to thank the many people who have contributed
to the ROHC specifications.
10. References
10.1. Normative References
[I-D.ietf-rohc-formal-notation]
Pelletier, G. and R. Finking, "Formal Notation for Robust
Header Compression (ROHC-FN)",
draft-ietf-rohc-formal-notation-13 (work in progress),
December 2006.
[I-D.ietf-rohc-rfc3095bis-framework]
Jonsson, L., "The RObust Header Compression (ROHC)
Framework", draft-ietf-rohc-rfc3095bis-framework-04 (work
in progress), November 2006.
[RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768,
August 1980.
[RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791,
September 1981.
[RFC2004] Perkins, C., "Minimal Encapsulation within IP", RFC 2004,
October 1996.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", RFC 2460, December 1998.
[RFC2784] Farinacci, D., Li, T., Hanks, S., Meyer, D., and P.
Traina, "Generic Routing Encapsulation (GRE)", RFC 2784,
March 2000.
[RFC2890] Dommety, G., "Key and Sequence Number Extensions to GRE",
RFC 2890, September 2000.
[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V.
Jacobson, "RTP: A Transport Protocol for Real-Time
Applications", STD 64, RFC 3550, July 2003.
[RFC3828] Larzon, L-A., Degermark, M., Pink, S., Jonsson, L-E., and
Pelletier & Sandlund Expires November 26, 2007 [Page 106]
Internet-Draft RoHCv2 Profiles May 2007
G. Fairhurst, "The Lightweight User Datagram Protocol
(UDP-Lite)", RFC 3828, July 2004.
[RFC4019] Pelletier, G., "RObust Header Compression (ROHC): Profiles
for User Datagram Protocol (UDP) Lite", RFC 4019,
April 2005.
[RFC4302] Kent, S., "IP Authentication Header", RFC 4302,
December 2005.
[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)",
RFC 4303, December 2005.
10.2. Informative References
[RFC3095] Bormann, C., Burmeister, C., Degermark, M., Fukushima, H.,
Hannu, H., Jonsson, L-E., Hakenberg, R., Koren, T., Le,
K., Liu, Z., Martensson, A., Miyazaki, A., Svanbro, K.,
Wiebke, T., Yoshimura, T., and H. Zheng, "RObust Header
Compression (ROHC): Framework and four profiles: RTP, UDP,
ESP, and uncompressed", RFC 3095, July 2001.
[RFC3843] Jonsson, L-E. and G. Pelletier, "RObust Header Compression
(ROHC): A Compression Profile for IP", RFC 3843,
June 2004.
[RFC4224] Pelletier, G., Jonsson, L-E., and K. Sandlund, "RObust
Header Compression (ROHC): ROHC over Channels That Can
Reorder Packets", RFC 4224, January 2006.
Appendix A. Detailed classification of header fields
Header compression is possible thanks to the fact that most header
fields do not vary randomly from packet to packet. Many of the
fields exhibit static behavior or change in a more or less
predictable way. When designing a header compression scheme, it is
of fundamental importance to understand the behavior of the fields in
detail.
In this appendix, all IP, UDP, UDP-Lite, RTP and ESP header fields
are classified and analyzed in two steps. First, we have a general
classification in Appendix A.1 where the fields are classified on the
basis of stable knowledge and assumptions. A more detailed analysis
of the change characteristics of the changing fields is then done in
Appendix A.2.
Pelletier & Sandlund Expires November 26, 2007 [Page 107]
Internet-Draft RoHCv2 Profiles May 2007
Appendix A.1. General classification
Fields are classified as belonging to one of the following classes:
INFERRED - These fields contain values that can be inferred from
other values, for example the size of the frame carrying the packet,
and thus do not have to be handled at all by the compression scheme.
STATIC-DEF - These fields are expected to be constant throughout the
lifetime of the packet stream and whose values can be used to define
a packet stream. They are in general communicated only at the
initialization of the context.
STATIC-KNOWN - These fields are expected to have well-known values
and therefore do not need to be communicated at all.
CHANGING - These fields are expected to vary in some way: randomly,
within a limited value set or range, or in some other manner.
In this section, the fields of the various protocol headers are
assigned to one of these classes. For all fields except those
classified as CHANGING, the motives for the classification are also
stated. In Appendix A.2, CHANGING fields are further examined and
classified on the basis of their expected change behavior.
Appendix A.1.1. IPv4 header fields
+---------------------+-------------+----------------+
| Field | Size (bits) | Class |
+---------------------+-------------+----------------+
| Version | 4 | STATIC-KNOWN |
| Header Length | 4 | STATIC-KNOWN |
| Type Of Service | 8 | CHANGING |
| Packet Length | 16 | INFERRED |
| Identification | 16 | CHANGING |
| Reserved flag | 1 | STATIC-KNOWN |
| Don't Fragment flag | 1 | CHANGING |
| More Fragments flag | 1 | STATIC-KNOWN |
| Fragment Offset | 13 | STATIC-KNOWN |
| Time To Live | 8 | CHANGING |
| Protocol | 8 | STATIC-DEF |
| Header Checksum | 16 | INFERRED |
| Source Address | 32 | STATIC-DEF |
| Destination Address | 32 | STATIC-DEF |
+---------------------+-------------+----------------+
Version
Pelletier & Sandlund Expires November 26, 2007 [Page 108]
Internet-Draft RoHCv2 Profiles May 2007
The version field states which IP version is used. Packets with
different values in this field must be handled by different IP
stacks. All packets of a packet stream must therefore be of the
same IP version. Accordingly, the field is classified as STATIC-
KNOWN.
Header Length
As long no options are present in the IP header, the header length
is constant and well known. If there are options, the fields
could be CHANGING or STATIC-DEF, but it is assumed here that there
are no options. The field is therefore classified as STATIC-
KNOWN.
Packet Length
Information about packet length is expected to be provided by the
link layer. The field is therefore classified as INFERRED.
Flags
The Reserved flag must be set to zero and is therefore classified
as STATIC-KNOWN. The Don't Fragment (DF) flag will changes rarely
and is therefore classified as CHANGING. Finally, the More
Fragments (MF) flag is expected to be zero because IP fragments
will not be compressed by ROHC. The More Fragments flag is
therefore classified as STATIC-KNOWN.
Fragment Offset
Under the assumption that no fragmentation occurs, the fragment
offset is always zero. The field is therefore classified as
STATIC-KNOWN.
Protocol
This field will have the same value in all packets of a packet
stream and is therefore classified as STATIC-DEF.
Header Checksum
The header checksum protects individual hops from processing a
corrupted header. When almost all IP header information is
compressed away, there is no point in having this additional
checksum; instead it can be regenerated at the decompressor side.
The field is therefore classified as INFERRED.
Source and Destination addresses
Pelletier & Sandlund Expires November 26, 2007 [Page 109]
Internet-Draft RoHCv2 Profiles May 2007
These fields are part of the definition of a stream and must thus
be constant for all packets in the stream. The fields are
therefore classified as STATIC-DEF.
Appendix A.1.2. IPv6 header fields
+---------------------+-------------+----------------+
| Field | Size (bits) | Class |
+---------------------+-------------+----------------+
| Version | 4 | STATIC-KNOWN |
| Traffic Class | 8 | CHANGING |
| Flow Label | 20 | STATIC-DEF |
| Payload Length | 16 | INFERRED |
| Next Header | 8 | STATIC-DEF |
| Hop Limit | 8 | CHANGING |
| Source Address | 128 | STATIC-DEF |
| Destination Address | 128 | STATIC-DEF |
+---------------------+-------------+----------------+
Version
The version field states which IP version is used. Packets with
different values in this field must be handled by different IP
stacks. All packets of a packet stream must therefore be of the
same IP version. Accordingly, the field is classified as STATIC-
KNOWN.
Flow Label
This field may be used to identify packets belonging to a specific
packet stream. If not used, the value should be set to zero.
Otherwise, all packets belonging to the same stream must have the
same value in this field. The field is therefore classified as
STATIC-DEF.
Payload Length
Information about packet length (and, consequently, payload
length) is expected to be provided by the link layer. The field
is therefore classified as INFERRED.
Next Header
This field will have the same value in all packets of a packet
stream and is therefore classified as STATIC-DEF.
Source and Destination addresses
Pelletier & Sandlund Expires November 26, 2007 [Page 110]
Internet-Draft RoHCv2 Profiles May 2007
These fields are part of the definition of a stream and must thus
be constant for all packets in the stream. The fields are
therefore classified as STATIC-DEF.
Appendix A.1.3. UDP header fields
+------------------+-------------+-------------+
| Field | Size (bits) | Class |
+------------------+-------------+-------------+
| Source Port | 16 | STATIC-DEF |
| Destination Port | 16 | STATIC-DEF |
| Length | 16 | INFERRED |
| Checksum | 16 | CHANGING |
+------------------+-------------+-------------+
Source and Destination ports
These fields are part of the definition of a stream and must thus
be constant for all packets in the stream. The fields are
therefore classified as STATIC-DEF.
Length
This field is redundant and is therefore classified as INFERRED.
Appendix A.1.4. UDP-Lite header fields
+-------------------+-------------+-------------+
| Field | Size (bits) | Class |
+-------------------+-------------+-------------+
| Source Port | 16 | STATIC-DEF |
| Destination Port | 16 | STATIC-DEF |
| Checksum Coverage | 16 | INFERRED |
| | | STATIC-DEF |
| | | CHANGING |
| Checksum | 16 | CHANGING |
+-------------------+-------------+-------------+
Source and Destination Port
Same as for UDP Appendix A.1.3.
Source and Destination ports
Pelletier & Sandlund Expires November 26, 2007 [Page 111]
Internet-Draft RoHCv2 Profiles May 2007
Same as for UDP Appendix A.1.3.
Checksum Coverage
This field specifies which part of the UDP-Lite datagram is
covered by the checksum. It may have a value of zero or be equal
to the datagram length if the checksum covers the entire datagram,
or it may have any value between eight octets and the length of
the datagram to specify the number of octets protected by the
checksum, calculated from the first octet of the UDP-Lite header.
The value of this field may vary for each packet, and this makes
the value unpredictable from a header-compression perspective.
Checksum
The information used for the calculation of the UDP-Lite checksum
is governed by the value of the checksum coverage and minimally
includes the UDP-Lite header. The checksum is a changing field
that must always be sent as-is.
Appendix A.1.5. RTP header fields
+-----------------+-------------+----------------+
| Field | Size (bits) | Class |
+-----------------+-------------+----------------+
| Version | 2 | STATIC-KNOWN |
| Padding | 1 | CHANGING |
| Extension | 1 | CHANGING |
| CSRC Counter | 4 | CHANGING |
| Marker | 1 | CHANGING |
| Payload Type | 7 | CHANGING |
| Sequence Number | 16 | CHANGING |
| Timestamp | 32 | CHANGING |
| SSRC | 32 | STATIC-DEF |
| CSRC | 0(-480) | CHANGING |
+-----------------+-------------+----------------+
Version
Only one working RTP version exists, namely version 2. The field
is therefore classified as STATIC-KNOWN.
Padding
Pelletier & Sandlund Expires November 26, 2007 [Page 112]
Internet-Draft RoHCv2 Profiles May 2007
The use of this field is application-dependent, but when payload
padding is used it is likely to be present in most or all packets.
The field is classified as CHANGING to allow for the rare case
where this field is updated.
Extension
If RTP extensions are used by the application, these extensions
are likely to be present in all packets (but the use of extensions
is very uncommon). However, for safety's sake this field is
classified as CHANGING to allow for the rare case where this field
is changed during the flow.
SSRC
This field is part of the definition of a stream and must thus be
constant for all packets in the stream. The field is therefore
classified as STATIC-DEF.
Appendix A.1.6. ESP header fields
+------------------+-------------+-------------+
| Field | Size (bits) | Class |
+------------------+-------------+-------------+
| SPI | 32 | STATIC-DEF |
| Sequence Number | 32 | CHANGING |
+------------------+-------------+-------------+
SPI
This field is used to identify a specific flow and only changes
when the sequence number wraps around, and is therefore classified
as STATIC-DEF.
Appendix A.2. Analysis of change patterns of header fields
To design suitable mechanisms for efficient compression of all header
fields, their change patterns must be analyzed. For this reason, an
extended classification is done based on the general classification
in Appendix A.1, considering the fields which were labeled CHANGING
in that classification. Different applications will use the fields
in different ways, which may affect their behavior. For the fields
whose behavior is variable, typical behavior for conversational audio
and video will be discussed.
The CHANGING fields are separated into five different subclasses:
Pelletier & Sandlund Expires November 26, 2007 [Page 113]
Internet-Draft RoHCv2 Profiles May 2007
NONCHANGING These are fields that were classified as CHANGING on a
general basis, but may under some conditions be static throughout
the flow and therefore be completely compressed away.
SEMISTATIC These fields are unchanged most of the time. However,
occasionally the value changes but will revert to its original
value.
RARELY-CHANGING (RC) These are fields that change their values
occasionally and then keep their new values.
IRREGULAR These, finally, are the fields for which no useful
change pattern can be identified.
PATTERN These field that change between each packet, but change in
a predictable pattern.
Table A.1 classifies all the CHANGING fields on the basis of their
expected change patterns.
Pelletier & Sandlund Expires November 26, 2007 [Page 114]
Internet-Draft RoHCv2 Profiles May 2007
+------------------------+-------------+
| Field | Class |
+========================+=============+
| Sequential | PATTERN |
| -----------+-------------+
| IPv4 Id: Seq. swap | PATTERN |
| -----------+-------------+
| Random | IRREGULAR |
| -----------+-------------+
| Zero | NONCHANGING |
+------------------------+-------------+
| IP TOS / Tr. Class | RC |
+------------------------+-------------+
| IP TTL / Hop Limit | RC |
+------------------------+-------------+
| IP Don't Fragment | RC |
+------------------------+-------------+
| Disabled | NONCHANGING |
| UDP Checksum: ---------+-------------+
| Enabled | IRREGULAR |
+------------------------+-------------+
| UDP-Lite Checksum | IRREGULAR |
+------------------------+-------------+
| Case #1 | CHANGING |
| UDP-Lite ----------+-------------+
| Checksum: Case #2 | RC |
| Coverage ----------+-------------+
| Case #3 | IRREGULAR |
+------------------------+-------------+
| RTP CSRC Count | RC |
+------------------------+-------------+
| RTP Marker | SEMISTATIC |
+------------------------+-------------+
| RTP Payload Type | RC |
+------------------------+-------------+
| RTP Extension | RC |
+------------------------+-------------+
| RTP Padding | RC |
+------------------------+-------------+
| RTP Sequence Number | PATTERN |
+------------------------+-------------+
| RTP Timestamp | PATTERN |
+------------------------+-------------+
| RTP CSRC List: | RC |
+------------------------+-------------+
| ESP Sequence Number | PATTERN |
+------------------------+-------------+
Table A.1 : Classification of CHANGING header fields
Pelletier & Sandlund Expires November 26, 2007 [Page 115]
Internet-Draft RoHCv2 Profiles May 2007
The following subsections discuss the various header fields in
detail. Note that table A.1 and the discussions below do not
consider changes caused by loss or reordering before the compression
point.
Appendix A.2.1. IPv4 Identification
The Identification field (IP ID) of the IPv4 header is there to
identify which fragments constitute a datagram when reassembling
fragmented datagrams. The IPv4 specification does not specify
exactly how this field is to be assigned values, only that each
packet should get an IP ID that is unique for the source-destination
pair and protocol for the time the datagram (or any of its fragments)
could be alive in the network. This means that assignment of IP ID
values can be done in various ways, but the expected behaviors have
been separated into four classes.
Sequential
In this behavior, the IP-ID is expected to increment by one for
most packets, but may increment by a value larger than one,
depending on the behavior of the transmitting IPv4 stack.
Sequential Swapped
When using this behavior, the IP-ID behaves as in the Sequential
bahvior, but the two bytes of IP-ID are byte swapped. Therefore,
the IP-ID can be swapped before compression to make it behave
exactly as the Sequential behavior.
Random
Some IP stacks assign IP ID values using a pseudo-random number
generator. There is thus no correlation between the ID values of
subsequent datagrams, and therefore there is no way to predict the
IP ID value for the next datagram. For header compression
purposes, this means that the IP ID field needs to be sent
uncompressed with each datagram, resulting in two extra octets of
header.
Zero
This behavior, although not a legal implementation of IPv4 is
sometimes seen in existing IPv4 stacks. When this behavior is
used, all IP packets have the IP-ID value set to zero.
Pelletier & Sandlund Expires November 26, 2007 [Page 116]
Internet-Draft RoHCv2 Profiles May 2007
Appendix A.2.2. IP Traffic Class / Type-Of-Service
The Traffic-Class (IPv6) or Type-Of-Service (IPv4) field is expected
to be constant during the lifetime of a packet stream or to change
relatively seldom.
Appendix A.2.3. IP Hop-limit / Time-To-Live
The Hop-Limit (IPv6) or Time-To-Live (IPv4) field is expected to be
constant during the lifetime of a packet stream or to alternate
between a limited number of values due to route changes.
Appendix A.2.4. IPv4 Don't Fragment
The Don't Fragment flag in IPv4 will seldom change, and is therefore
classified as RC.
Appendix A.2.5. UDP Checksum
The UDP checksum is optional. If disabled, its value is constantly
zero and could be compressed away. If enabled, its value depends on
the payload, which for compression purposes is equivalent to it
changing randomly with every packet.
Appendix A.2.6. UDP-Lite Checksum Coverage
The Checksum Coverage field may behave in different ways: it may have
a value of zero, it may be equal to the datagram length, or it may
have any value between eight octets and the length of the datagram.
From a compression perspective, this field is expected to either be
entirely predictable (for the cases where it follows the same
behavior as the UDP Length field or where it takes on a constant
value) or either to change randomly for each packet (making the value
unpredictable from a header-compression perspective). For all cases,
the behavior itself is not expected to change for this field during
the lifetime of a packet flow, or to change relatively seldom.
Appendix A.2.7. UDP-Lite Checksum
As opposed to the UDP checksum, the UDP-Lite checksum is not optional
and it cannot be disabled. Its value depends on the payload and on
the checksum coverage field, which for compression purposes is
equivalent to it changing randomly with every packet.
Appendix A.2.8. RTP CSRC Counter
This is a counter indicating the number of CSRC items present in the
CSRC list. This number is expected to be almost constant on a
Pelletier & Sandlund Expires November 26, 2007 [Page 117]
Internet-Draft RoHCv2 Profiles May 2007
packet-to-packet basis and change by small amounts. As long as no
RTP mixer is used, the value of this field will be zero.
Appendix A.2.9. RTP Marker
For audio the marker bit should be set only in the first packet of a
talkspurt, while for video it should be set in the last packet of
every picture. This means that in both cases the RTP marker is
classified as SEMISTATIC..
Appendix A.2.10. RTP Padding
If padding is used, it is expected to be present in most packets, but
is classified as RC to allow efficient compression even when this
field changes.
Appendix A.2.11. RTP Extension
If extensions are used, it is expected to be used in most packets,
but is classified as RC to allow efficient compression even when this
field changes.
Appendix A.2.12. RTP Payload Type
Changes of the RTP payload type within a packet stream are expected
to be rare. Applications could adapt to congestion by changing
payload type and/or frame sizes, but that is not expected to happen
frequently.
Appendix A.2.13. RTP Sequence Number
The RTP Sequence Number will be incremented by one for each packet
sent.
Appendix A.2.14. RTP Timestamp
In the audio case:
As long as there are no pauses in the audio stream, the RTP
Timestamp will be incremented by a constant delta, corresponding
to the number of samples in the speech frame. It will thus mostly
follow the RTP Sequence Number. When there has been a silent
period and a new talkspurt begins, the timestamp will jump in
proportion to the length of the silent period. However, the
increment will probably be within a relatively limited range.
In the video case:
Pelletier & Sandlund Expires November 26, 2007 [Page 118]
Internet-Draft RoHCv2 Profiles May 2007
Between two consecutive packets, the timestamp will either be
unchanged or increase by a multiple of a fixed value corresponding
to the picture clock frequency. The timestamp can also decrease
by a multiple of the fixed value for certain coding schemes. The
delta interval, expressed as a multiple of the picture clock
frequency, is in most cases very limited.
Appendix A.2.15. RTP Contributing Sources (CSRC)
The participants in a session, which are identified by the CSRC
fields, are expected to be almost the same on a packet-to-packet
basis with relatively few additions and removals. As long as RTP
mixers are not used, no CSRC fields are present at all.
Appendix A.2.16. ESP Sequence Number
The ESP Sequence Number will be incremented by one for each packet
sent.
Appendix B. Differences between RoHCv2 and RFC3095 profiles
To be Written
Profiles defined in RFC3095 were designed with the assumption that
the channel between compressor and decompressor maintains packet
ordering, i.e., that the decompressor always receive packets in the
same order as the compressor sent them. RoHCv2 profiles does not
make this assumption, i.e. reordering before and after the
compression point is handled as part of the compression algorithm
itself.
Some of the other technical differences between these specifications
are:
o ROHCv2 profiles do not contain multiple modes with different
updating logic and different packet format sets. Insted, ROHCv2
profiles assume bidirectional opeartion from the time that the
first feedback is received.
o Simplified handling of extension headers.
o Simplified list compression for CSRC lists.
o The IR-DYN packet is not used, and instead, each profile contains
a co_repair packet which is protected by a 7-bit CRC. This also
means that profile downgrading via IR-DYN was removed.
o Different decompressor state transitions in order to improve
robustness when initiating the context.
o The format of FEEDBACK-2 now includes a CRC, and there have been
changes in which of feedback options that are used.
Pelletier & Sandlund Expires November 26, 2007 [Page 119]
Internet-Draft RoHCv2 Profiles May 2007
Authors' Addresses
Ghyslain Pelletier
Ericsson
Box 920
Lulea SE-971 28
Sweden
Phone: +46 (0) 8 404 29 43
Email: ghyslain.pelletier@ericsson.com
Kristofer Sandlund
Ericsson
Box 920
Lulea SE-971 28
Sweden
Phone: +46 (0) 8 404 41 58
Email: kristofer.sandlund@ericsson.com
Pelletier & Sandlund Expires November 26, 2007 [Page 120]
Internet-Draft RoHCv2 Profiles May 2007
Full Copyright Statement
Copyright (C) The IETF Trust (2007).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Acknowledgment
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
Pelletier & Sandlund Expires November 26, 2007 [Page 121]
| PAFTECH AB 2003-2026 | 2026-04-24 07:42:33 |