summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc5225.txt
diff options
context:
space:
mode:
authorThomas Voss <mail@thomasvoss.com> 2024-11-27 20:54:24 +0100
committerThomas Voss <mail@thomasvoss.com> 2024-11-27 20:54:24 +0100
commit4bfd864f10b68b71482b35c818559068ef8d5797 (patch)
treee3989f47a7994642eb325063d46e8f08ffa681dc /doc/rfc/rfc5225.txt
parentea76e11061bda059ae9f9ad130a9895cc85607db (diff)
doc: Add RFC documents
Diffstat (limited to 'doc/rfc/rfc5225.txt')
-rw-r--r--doc/rfc/rfc5225.txt6947
1 files changed, 6947 insertions, 0 deletions
diff --git a/doc/rfc/rfc5225.txt b/doc/rfc/rfc5225.txt
new file mode 100644
index 0000000..b8e3b33
--- /dev/null
+++ b/doc/rfc/rfc5225.txt
@@ -0,0 +1,6947 @@
+
+
+
+
+
+
+Network Working Group G. Pelletier
+Request for Comments: 5225 K. Sandlund
+Category: Standards Track Ericsson
+ April 2008
+
+
+ RObust Header Compression Version 2 (ROHCv2):
+ Profiles for RTP, UDP, IP, ESP and UDP-Lite
+
+Status of This Memo
+
+ This document specifies an Internet standards track protocol for the
+ Internet community, and requests discussion and suggestions for
+ improvements. Please refer to the current edition of the "Internet
+ Official Protocol Standards" (STD 1) for the standardization state
+ and status of this protocol. Distribution of this memo is unlimited.
+
+Abstract
+
+ 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
+ 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 their own
+ specific set of header formats, using the ROHC formal notation.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Pelletier & Sandlund Standards Track [Page 1]
+
+RFC 5225 ROHCv2 Profiles April 2008
+
+
+Table of Contents
+
+ 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
+ 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
+ 3. Acronyms . . . . . . . . . . . . . . . . . . . . . . . . . . 7
+ 4. Background (Informative) . . . . . . . . . . . . . . . . . . 7
+ 4.1. Classification of Header Fields . . . . . . . . . . . . . 7
+ 4.2. Improvements of ROHCv2 over RFC 3095 Profiles . . . . . . 8
+ 4.3. Operational Characteristics of ROHCv2 Profiles . . . . . 10
+ 5. Overview of the ROHCv2 Profiles (Informative) . . . . . . . . 10
+ 5.1. Compressor Concepts . . . . . . . . . . . . . . . . . . . 11
+ 5.1.1. Optimistic Approach . . . . . . . . . . . . . . . . . 11
+ 5.1.2. Tradeoff between Robustness to Losses and to
+ Reordering . . . . . . . . . . . . . . . . . . . . . 11
+ 5.1.3. Interactions with the Decompressor Context . . . . . 13
+ 5.2. Decompressor Concepts . . . . . . . . . . . . . . . . . . 14
+ 5.2.1. Decompressor State Machine . . . . . . . . . . . . . 14
+ 5.2.2. Decompressor Context Management . . . . . . . . . . . 17
+ 5.2.3. Feedback Logic . . . . . . . . . . . . . . . . . . . 19
+ 6. ROHCv2 Profiles (Normative) . . . . . . . . . . . . . . . . . 19
+ 6.1. Channel Parameters, Segmentation, and Reordering . . . . 19
+ 6.2. Profile Operation, Per-context . . . . . . . . . . . . . 20
+ 6.3. Control Fields . . . . . . . . . . . . . . . . . . . . . 21
+ 6.3.1. Master Sequence Number (MSN) . . . . . . . . . . . . 21
+ 6.3.2. Reordering Ratio . . . . . . . . . . . . . . . . . . 21
+ 6.3.3. IP-ID Behavior . . . . . . . . . . . . . . . . . . . 22
+ 6.3.4. UDP-Lite Coverage Behavior . . . . . . . . . . . . . 22
+ 6.3.5. Timestamp Stride . . . . . . . . . . . . . . . . . . 22
+ 6.3.6. Time Stride . . . . . . . . . . . . . . . . . . . . . 22
+ 6.3.7. CRC-3 for Control Fields . . . . . . . . . . . . . . 23
+ 6.4. Reconstruction and Verification . . . . . . . . . . . . . 23
+ 6.5. Compressed Header Chains . . . . . . . . . . . . . . . . 24
+ 6.6. Header Formats and Encoding Methods . . . . . . . . . . . 25
+ 6.6.1. baseheader_extension_headers . . . . . . . . . . . . 26
+ 6.6.2. baseheader_outer_headers . . . . . . . . . . . . . . 26
+ 6.6.3. inferred_udp_length . . . . . . . . . . . . . . . . . 26
+ 6.6.4. inferred_ip_v4_header_checksum . . . . . . . . . . . 26
+ 6.6.5. inferred_mine_header_checksum . . . . . . . . . . . . 27
+ 6.6.6. inferred_ip_v4_length . . . . . . . . . . . . . . . . 28
+ 6.6.7. inferred_ip_v6_length . . . . . . . . . . . . . . . . 28
+ 6.6.8. Scaled RTP Timestamp Compression . . . . . . . . . . 29
+ 6.6.9. timer_based_lsb . . . . . . . . . . . . . . . . . . . 30
+ 6.6.10. inferred_scaled_field . . . . . . . . . . . . . . . . 31
+ 6.6.11. control_crc3_encoding . . . . . . . . . . . . . . . . 32
+ 6.6.12. inferred_sequential_ip_id . . . . . . . . . . . . . . 33
+ 6.6.13. list_csrc(cc_value) . . . . . . . . . . . . . . . . . 34
+ 6.7. Encoding Methods with External Parameters as Arguments . 38
+ 6.8. Header Formats . . . . . . . . . . . . . . . . . . . . . 40
+
+
+
+Pelletier & Sandlund Standards Track [Page 2]
+
+RFC 5225 ROHCv2 Profiles April 2008
+
+
+ 6.8.1. Initialization and Refresh Header Format (IR) . . . . 40
+ 6.8.2. Compressed Header Formats (CO) . . . . . . . . . . . 41
+ 6.9. Feedback Formats and Options . . . . . . . . . . . . . . 100
+ 6.9.1. Feedback Formats . . . . . . . . . . . . . . . . . . 100
+ 6.9.2. Feedback Options . . . . . . . . . . . . . . . . . . 102
+ 7. Security Considerations . . . . . . . . . . . . . . . . . . . 104
+ 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 105
+ 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 105
+ 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 106
+ 10.1. Normative References . . . . . . . . . . . . . . . . . . 106
+ 10.2. Informative References . . . . . . . . . . . . . . . . . 107
+ Appendix A. Detailed Classification of Header Fields . . . . . 108
+ A.1. IPv4 Header Fields . . . . . . . . . . . . . . . . . . . 109
+ A.2. IPv6 Header Fields . . . . . . . . . . . . . . . . . . . 112
+ A.3. UDP Header Fields . . . . . . . . . . . . . . . . . . . 113
+ A.4. UDP-Lite Header Fields . . . . . . . . . . . . . . . . . 114
+ A.5. RTP Header Fields . . . . . . . . . . . . . . . . . . . . 115
+ A.6. ESP Header Fields . . . . . . . . . . . . . . . . . . . . 117
+ A.7. IPv6 Extension Header Fields . . . . . . . . . . . . . . 117
+ A.8. GRE Header Fields . . . . . . . . . . . . . . . . . . . . 118
+ A.9. MINE Header Fields . . . . . . . . . . . . . . . . . . . 119
+ A.10. AH Header Fields . . . . . . . . . . . . . . . . . . . . 120
+ Appendix B. Compressor Implementation Guidelines . . . . . . . 121
+ B.1. Reference Management . . . . . . . . . . . . . . . . . . 121
+ B.2. Window-based LSB Encoding (W-LSB) . . . . . . . . . . . 121
+ B.3. W-LSB Encoding and Timer-based Compression . . . . . . . 122
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Pelletier & Sandlund Standards Track [Page 3]
+
+RFC 5225 ROHCv2 Profiles April 2008
+
+
+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 the definitions depend on the ROHC framework
+ as found in [RFC4995]. The framework is required reading to
+ understand the profile definitions, rules, and their role.
+
+ Specifically, this document defines header compression schemes for:
+
+ 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
+
+ Each of the profiles above can compress the following type of
+ extension headers:
+
+ o AH [RFC4302]
+
+ o GRE [RFC2784][RFC2890]
+
+ o MINE [RFC2004]
+
+ 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].
+
+
+
+
+
+Pelletier & Sandlund Standards Track [Page 4]
+
+RFC 5225 ROHCv2 Profiles April 2008
+
+
+ This document is consistent with the terminology found in the ROHC
+ framework [RFC4995] and in the formal notation for ROHC [RFC4997].
+ In addition, this document uses or defines the following terms:
+
+ Acknowledgment Number
+
+ The Acknowledgment Number identifies what packet is being
+ acknowledged in the RoHCv2 feedback element (See Section 6.9).
+ The value of this field normally corresponds to the Master
+ Sequence Number (MSN) of the header that was last successfully
+ decompressed, for the compression context (CID) for which the
+ feedback information applies.
+
+ Chaining of Items
+
+ A chain of items groups fields based on similar characteristics.
+ ROHCv2 defines chain items for static, dynamic and irregular
+ fields. Chaining is achieved by appending an item to the chain
+ for each header in its 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.
+
+ CRC-3 Control Fields Validation
+
+ The CRC-3 control fields validation refers to the validation of
+ the control fields. This validation is performed by the
+ decompressor when it receives a Compressed (CO) header that
+ contains a 3-bit Cyclic Redundancy Check (CRC) calculated over
+ control fields. This 3-bit CRC covers controls fields carried in
+ the CO header as well as specific control fields in the context.
+ In the formal definition of the header formats, this 3-bit CRC is
+ labeled "control_crc3" and uses the control_crc3_encoding (See
+ also Section 6.6.11).
+
+ Delta
+
+ The delta refers to the difference in the absolute value of a
+ field between two consecutive packets being processed by the same
+ compression endpoint.
+
+ Reordering Depth
+
+ The number of packets by which a packet is received late within
+ its sequence due to reordering between the compressor and the
+ decompressor, i.e., reordering between packets associated with the
+ same context (CID). See the definition of sequentially late
+ packet below.
+
+
+
+Pelletier & Sandlund Standards Track [Page 5]
+
+RFC 5225 ROHCv2 Profiles April 2008
+
+
+ ROHCv2 Header Types
+
+ ROHCv2 profiles use two different header types: the Initialization
+ and Refresh (IR) header type, and the Compressed (CO) header type.
+
+ Sequentially Early Packet
+
+ A packet that reaches the decompressor before one or several
+ packets that were delayed over the channel, where 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). How the
+ decompressor detects a sequentially late packet is outside the
+ scope of this specification, but it can for example use the MSN
+ for this purpose.
+
+ Timestamp Stride (ts_stride)
+
+ The timestamp stride (ts_stride) is the expected increase in the
+ timestamp value between two RTP packets with consecutive sequence
+ numbers. For example, for a media encoding with a sample rate of
+ 8 kHz producing one frame every 20 ms, the RTP timestamp will
+ typically increase by n * 160 (= 8000 * 0.02), for some integer n.
+
+ Time Stride (time_stride)
+
+ The time stride (time_stride) is the time interval equivalent to
+ one ts_stride, e.g., 20 ms in the example for the RTP timestamp
+ increment above.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Pelletier & Sandlund Standards Track [Page 6]
+
+RFC 5225 ROHCv2 Profiles April 2008
+
+
+3. Acronyms
+
+ This section lists most acronyms used for reference, in addition to
+ those defined in [RFC4995].
+
+ AH Authentication Header.
+ ESP Encapsulating Security Payload.
+ GRE Generic Routing Encapsulation.
+ 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.
+ RC Repair Context state (decompressor).
+ ROHC Header compression framework (RFC 4995).
+ 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. The RTP header contains an optional
+ list of contributing sources.
+ TC Traffic Class. Field in the IPv6 header. See also TOS.
+ TOS Type Of Service. Field in the IPv4 header. See also TC.
+ TS RTP Timestamp.
+ TTL Time to Live. Field in the IPv4 header.
+ 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 sections
+ 3 and 4 of [RFC4995], respectively. The fundamentals of the formal
+ notation for ROHC are defined in [RFC4997]. [RFC4224] describes the
+ impacts of out-of-order delivery on profiles based on [RFC3095].
+
+4.1. Classification of Header Fields
+
+ Section 3.1 of [RFC4995] explains that header compression is possible
+ due to the fact that there is much redundancy between field values
+ within the headers of a packet, 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
+
+
+
+Pelletier & Sandlund Standards Track [Page 7]
+
+RFC 5225 ROHCv2 Profiles April 2008
+
+
+ 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 that of the RTP TS to the RTP SN
+ is often observed between the Identifier field (IP-ID) and the master
+ sequence number (MSN) used for compression (e.g., the RTP SN when
+ compressing RTP headers).
+
+4.2. Improvements of ROHCv2 over RFC 3095 Profiles
+
+ The ROHCv2 profiles can achieve compression efficiency and robustness
+ that are both at least equivalent to RFC 3095 profiles [RFC3095],
+ when used under the same operating conditions. In particular, the
+ size and bit layout of the smallest compressed header (i.e., PT-0
+ format U/O-0 in RFC 3095, and pt_0_crc3 in ROHCv2) are identical.
+
+ There are a number of differences and improvements between profiles
+ defined in this document and their earlier version defined in RFC
+ 3095. This section provides an overview of some of the most
+ significant improvements:
+
+
+
+Pelletier & Sandlund Standards Track [Page 8]
+
+RFC 5225 ROHCv2 Profiles April 2008
+
+
+ Tolerance to reordering
+
+ Profiles defined in RFC 3095 require that the channel between
+ compressor and decompressor provide in-order delivery between
+ compression endpoints. ROHCv2 profiles, however, can handle
+ robustly and efficiently a limited amount of reordering after the
+ compression point as part of the compression algorithm itself. In
+ addition, this improved support for reordering makes it possible
+ for ROHCv2 profiles to handle prelink reordering more efficiently.
+
+ Operational logic
+
+ Profiles in RFC 3095 define multiple operational modes, each with
+ different updating logic and compressed header formats. ROHCv2
+ profiles operate in unidirectional operation until feedback is
+ first received for a context (CID), at which point bidirectional
+ operation is used; the formats are independent of what operational
+ logic is used.
+
+ IP extension header
+
+ Profiles in RFC 3095 compress IP Extension headers using list
+ compression. ROHCv2 profiles instead treat extension headers in
+ the same manner as other protocol headers, i.e., using the
+ chaining mechanism; it thus assumes that extension headers are not
+ added or removed during the lifetime of a context (CID), otherwise
+ compression has to be restarted for this flow.
+
+ IP encapsulation
+
+ Profiles in RFC 3095 can compress at most two levels of IP
+ headers. ROHCv2 profiles can compress an arbitrary number of IP
+ headers.
+
+ List compression
+
+ ROHCv2 profiles do not support reference-based list compression.
+
+ Robustness and repairs
+
+ ROHCv2 profiles do not define a format for the IR-DYN packet;
+ instead, each profile defines a compressed header that can be used
+ to perform a more robust context repair using a 7-bit CRC
+ verification. This also implies that only the IR header can
+ change the association between a CID and the profile it uses.
+
+
+
+
+
+
+Pelletier & Sandlund Standards Track [Page 9]
+
+RFC 5225 ROHCv2 Profiles April 2008
+
+
+ Feedback
+
+ ROHCv2 profiles mandate a CRC in the format of the FEEDBACK-2,
+ while this is optional in RFC 3095. A different set of feedback
+ options is also used in ROHCv2 compared to RFC 3095.
+
+4.3. Operational Characteristics of ROHCv2 Profiles
+
+ Robust header compression can be used over different link
+ technologies. Section 4.4 of [RFC4995] 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.
+
+ 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
+ has sent them and still have a fair probability of being
+ 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 concepts that are important and
+ useful to the 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 relate to the
+ compression efficiency of the protocol without impacting the
+ interoperability characteristics of an implementation.
+
+
+
+
+
+Pelletier & Sandlund Standards Track [Page 10]
+
+RFC 5225 ROHCv2 Profiles April 2008
+
+
+5.1. Compressor Concepts
+
+ Header compression can be conceptually characterized as the
+ interaction of a compressor with a decompressor state machine, one
+ per context. The responsibility 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.1.1), and optionally
+ from feedback messages (See Section 6.9), received from the
+ decompressor.
+
+5.1.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, the
+ 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 header 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 of repetitions 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. It is outside the scope of this
+ specification and is left to implementors to decide.
+
+5.1.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
+ interval offset of the sliding window used for lsb encoded fields
+ [RFC4997], and the optimistic approach (See Section 5.1.1) for seldom
+ changing fields.
+
+
+
+
+
+
+
+Pelletier & Sandlund Standards Track [Page 11]
+
+RFC 5225 ROHCv2 Profiles April 2008
+
+
+ lsb encoded fields:
+
+ The interpretation interval offset specifies an upper limit for
+ the maximum reordering depth, by which is it possible for the
+ decompressor to recover the original value of a dynamically
+ changing (i.e., sequentially incrementing) field that is encoded
+ using a window-based lsb encoding. Its value is typically bound
+ to the number of lsb compressed bits in the compressed header
+ format, and thus 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 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 (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 [RFC4997].
+
+ 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.
+
+ Seldom changing fields
+
+ The optimistic approach (Section 5.1.1) provides the upper limit
+ for the maximum reordering depth for seldom changing fields.
+
+ There is thus 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
+
+
+
+
+Pelletier & Sandlund Standards Track [Page 12]
+
+RFC 5225 ROHCv2 Profiles April 2008
+
+
+ MSN bits in the compressed header format. Otherwise, the tradeoff
+ relates to the implementation of the optimistic approach.
+
+ In particular, compressor implementations should adjust their
+ optimistic approach strategy to match both packet loss and reordering
+ characteristics of the link over which header compression is applied.
+ For example, the number of repetitions for each update of a non-lsb
+ encoded field can be increased. The compressor can ensure that each
+ update is repeated until it is reasonably confident that at least one
+ packet containing the change has reached the decompressor before the
+ first packet sent after this sequence.
+
+5.1.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 (i.e., what
+ header format it selects) based on its confidence that the
+ decompressor has the necessary information to successfully process
+ the compressed headers that it selects.
+
+ In other words, the responsibilities of the compressor are to ensure
+ that the decompressor operates with state information that is
+ sufficient to successfully decompress the type of compressed
+ header(s) it receives, and to allow the decompressor to successfully
+ recover that state information as soon as possible otherwise. The
+ compressor therefore selects the type of compressed header based 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
+ bidirectional operation, feedback received from the decompressor
+ (ACKs, NACKs, STATIC-NACK, and options).
+
+
+
+
+Pelletier & Sandlund Standards Track [Page 13]
+
+RFC 5225 ROHCv2 Profiles April 2008
+
+
+ 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 to its assumptions regarding the validity of
+ its context (Section 5.2.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 compressed (CO) header format, 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
+ 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 the decompression of what field(s) is
+ responsible for the failure. The compressor is thus always
+ responsible for determining 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.2. Decompressor Concepts
+
+ The decompressor normally uses the last received and successfully
+ validated (IR packets) or verified (CO packets) header as the
+ reference for future decompression.
+
+ The decompressor is responsible for verifying the outcome of every
+ decompression attempt, to update its context when successful, and
+ finally to request context repairs by making coherent usage of
+ feedback once it has started using feedback.
+
+ 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.2.1. Decompressor State Machine
+
+ The decompressor operation may be represented as a state machine
+ defining three states: No Context (NC), Repair Context (RC), and Full
+ Context (FC).
+
+ The decompressor starts without a valid context, the NC state. Upon
+ receiving an IR packet, the decompressor validates the integrity of
+
+
+
+Pelletier & Sandlund Standards Track [Page 14]
+
+RFC 5225 ROHCv2 Profiles April 2008
+
+
+ its header using the CRC-8 validation. If the IR header is
+ successfully validated, the decompressor updates the context and uses
+ this header as the reference header, and moves to the FC state. Once
+ the decompressor state machine has entered the FC state, it does not
+ normally leave; only repeated decompression failures will force the
+ decompressor to transit downwards to a lower state. When context
+ damage is detected, the decompressor moves to the repair context (RC)
+ state, where it stays until it successfully verifies a decompression
+ attempt for a compressed header with a 7-bit CRC or until it
+ successfully validates an IR header. When static context damage is
+ detected, the decompressor moves back to the NC 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.
+
+ CRC-8(IR) Validation
+ +----->----->----->----->----->----->----->----->----->----->----+
+ | CRC-8(IR) |
+ | !CRC-8(IR) or CRC-7(CO) or or CRC-7(CO) |
+ | PT not allowed CRC-8(IR) or CRC-3(CO) |
+ | +--->---+ +--->----->----->----->---+ +--->---->---+ |
+ | | | | | | | |
+ | | v | v | v v
+ +-----------------+ +----------------------+ +--------------------+
+ | No Context (NC) | | Repair Context (RC) | | Full Context (FC) |
+ +-----------------+ +----------------------+ +--------------------+
+ ^ ^ Static Context | ^ !CRC-7(CO) or | ^ Context Damage | |
+ | | Damage Detected | | PT not allowed | | Detected | |
+ | +--<-----<-----<--+ +----<------<----+ +--<-----<-----<--+ |
+ | |
+ | Static Context Damage Detected |
+ +--<-----<-----<-----<-----<-----<-----<-----<-----<---------+
+
+ where:
+
+ CRC-8(IR) : Successful CRC-8 validation for the IR header.
+ !CRC-8(IR) : Unsuccessful CRC-8 validation for the IR header.
+ CRC-7(CO) and/or
+ CRC-3(CO) : Successful CRC verification for the decompression
+ of a CO header, based on the number of CRC bits
+ carried in the CO header.
+ !CRC-7(CO) : 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 decompressor's current context does
+ not provide enough valid state information to
+ decompress the packet.
+
+
+
+Pelletier & Sandlund Standards Track [Page 15]
+
+RFC 5225 ROHCv2 Profiles April 2008
+
+
+ Static Context Damage Detected: See definition in Section 5.2.2.
+
+ Context Damage Detected: See definition in Section 5.2.2.
+
+5.2.1.1. No Context (NC) State
+
+ Initially, while working in the No Context (NC) state, the
+ decompressor has not yet successfully validated an IR header.
+
+ Attempting decompression:
+
+ In the NC state, only packets carrying sufficient information on
+ the static fields (i.e., IR packets) can be decompressed.
+
+ Upward transition:
+
+ The decompressor can move to the Full Context (FC) state when the
+ CRC validation of an 8-bit CRC in an IR header is successful.
+
+ Feedback logic:
+
+ In the NC state, the decompressor should send a STATIC-NACK if a
+ packet of a type other than IR is received, or if an IR header has
+ failed the CRC-8 validation, subject to the feedback rate
+ limitation as described in Section 5.2.3.
+
+5.2.1.2. Repair Context (RC) State
+
+ In the Repair Context (RC) state, the decompressor has successfully
+ decompressed packets for this context, but does not have confidence
+ that the entire context is valid.
+
+ Attempting decompression:
+
+ In the RC state, only headers covered by an 8-bit CRC (i.e., IR)
+ or CO headers carrying a 7-bit CRC can be decompressed.
+
+ 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 or
+ when validation of an 8-bit CRC in an IR header succeeds.
+
+ Downward transition:
+
+ The decompressor moves back to the NC state if it assumes static
+ context damage.
+
+
+
+
+Pelletier & Sandlund Standards Track [Page 16]
+
+RFC 5225 ROHCv2 Profiles April 2008
+
+
+ Feedback logic:
+
+ In the RC state, the decompressor should send a STATIC-NACK when
+ CRC-8 validation of an IR header fails, or when a CO header
+ carrying a 7-bit CRC fails and static context damage is assumed,
+ subject to the feedback rate limitation as described in
+ Section 5.2.3. If any other packet type is received, the
+ decompressor should treat it as a CRC verification failure to
+ determine if NACK is to be sent.
+
+5.2.1.3. Full Context (FC) State
+
+ In the Full Context (FC) state, the decompressor assumes that its
+ entire context is valid.
+
+ Attempting decompression:
+
+ In the FC state, decompression can be attempted regardless of the
+ type of packet received.
+
+ Downward transition:
+
+ The decompressor moves back to the RC state if it assumes context
+ damage. If the decompressor assumes static context damage, it
+ moves directly to the NC state.
+
+ Feedback logic:
+
+ In the FC state, the decompressor should send a NACK when CRC-8
+ validation or CRC verification of any header type fails and if
+ context damage is assumed, or it should send a STATIC-NACK if
+ static context damage is assumed; this is subject to the feedback
+ rate limitation described in Section 5.2.3.
+
+5.2.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 inferred from
+ other fields).
+
+ The decompressor may assume that some or the entire context is
+ invalid, when it fails to validate or to verify one or more headers
+ using the CRC. Because the decompressor cannot know the exact
+
+
+
+
+
+
+Pelletier & Sandlund Standards Track [Page 17]
+
+RFC 5225 ROHCv2 Profiles April 2008
+
+
+ reason(s) for a CRC failure or what field caused it, the validity of
+ the context hence does not refer to what specific part(s) of the
+ context is deemed valid or not.
+
+ Validity of the context rather relates to the detection of a problem
+ with the context. The decompressor first assumes 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 decompression failures and
+ unsuccessful repairs, the decompressor then assumes that the entire
+ context, including the static part, needs to be repaired, i.e.,
+ static context damage. Failure to validate the 3-bit CRC that
+ protects control fields should be treated as a decompression failure
+ when the decompressor asserts the validity of its context.
+
+ Context Damage Detection
+
+ The assumption of context damage means that the decompressor will
+ not attempt decompression of a CO header that carries only a 3-bit
+ CRC, and will only attempt decompression of IR headers or CO
+ headers protected by a CRC-7.
+
+ Static Context Damage Detection
+
+ The assumption of static context damage means that the
+ decompressor refrains from attempting decompression of any type of
+ header other than the IR header.
+
+ 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 which it will 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 from updating 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.
+
+
+
+
+
+
+Pelletier & Sandlund Standards Track [Page 18]
+
+RFC 5225 ROHCv2 Profiles April 2008
+
+
+5.2.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 is defined in
+ Section 5.2.4.1. of [RFC4995]. What feedback to send is coupled with
+ the context management of the decompressor, i.e., with the
+ implementation of the context damage detection algorithms as
+ described in Section 5.2.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.
+
+ When ROHCv2 profiles are used over a channel that cannot guarantee
+ in-order delivery, the decompressor may refrain from sending ACK
+ feedback for a sequentially late packet that is successfully
+ decompressed.
+
+ 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 with the same event.
+
+6. ROHCv2 Profiles (Normative)
+
+6.1. Channel Parameters, Segmentation, and Reordering
+
+ The compressor MUST NOT use ROHC segmentation (see Section 5.2.5 of
+ [RFC4995]), i.e., the Maximum Reconstructed Reception Unit (MRRU)
+ MUST be set to 0, if the configuration of the ROHC channel contains
+ at least one ROHCv2 profile in the list of supported profiles (i.e.,
+ the PROFILES parameter) and if the channel cannot guarantee in-order
+ delivery of packets between compression endpoints.
+
+
+
+
+
+
+
+
+
+Pelletier & Sandlund Standards Track [Page 19]
+
+RFC 5225 ROHCv2 Profiles April 2008
+
+
+6.2. Profile Operation, Per-context
+
+ ROHCv2 profiles operate 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 starts with the assumption that the
+ decompressor will not send feedback when it initializes a new context
+ (see also the definition of a new context in Section 5.1.1. of
+ [RFC4995], i.e., there is no established feedback channel for the new
+ context. At this point, despite the use of the optimistic approach,
+ decompression failure is still possible because the decompressor may
+ not have received sufficient information to correctly decompress the
+ packets; 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 or STATIC-NACKs) from the decompressor establishes the
+ feedback channel 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 to
+ increase 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
+ positive feedback (ACKs) or negative feedback (NACKs or STATIC-NACKs)
+ establishes this channel. Once it has established a feedback channel
+ for a CID, the decompressor is REQUIRED to continue sending feedback
+ for the lifetime of the context (i.e., until it receives an IR packet
+ that associates the CID to a different profile), to send error
+ recovery requests and (optionally) acknowledgments of significant
+ context updates.
+
+ Compression without an established feedback channel will be less
+ efficient, because of the periodic refreshes and the lack of feedback
+ to trigger error recovery; there will also be a slightly higher
+ probability of loss propagation compared to the case where the
+ decompressor uses feedback.
+
+
+
+Pelletier & Sandlund Standards Track [Page 20]
+
+RFC 5225 ROHCv2 Profiles April 2008
+
+
+6.3. Control Fields
+
+ ROHCv2 defines a number of control fields that are used by the
+ decompressor in its interpretation of the header formats received
+ from the compressor. The control fields listed in the following
+ subsections are defined using the formal notation [RFC4997] in
+ Section 6.8.2.4 of this document.
+
+6.3.1. Master Sequence Number (MSN)
+
+ The Master Sequence Number (MSN) field is either taken from a field
+ that already exists in one of the headers of the protocol that the
+ profile compresses (e.g., RTP SN), or alternatively it is created at
+ the compressor. There is one MSN space per context.
+
+ The MSN field has the following two functions:
+
+ o Differentiating between reference headers when receiving feedback
+ data;
+
+ o Inferring the value of incrementing fields (e.g., IPv4
+ Identifier).
+
+ There is one MSN field in every ROHCv2 header, i.e., the MSN is
+ always present in each header type sent by the compressor. The MSN
+ is sent in full in IR headers, while it can be lsb encoded within CO
+ header formats. The decompressor always includes LSBs of the MSN in
+ the Acknowledgment Number field in feedback (see Section 6.9). The
+ compressor can later use this field to infer what packet the
+ decompressor is acknowledging.
+
+ For profiles for which the MSN is created by the compressor (i.e.,
+ 0x0102, 0x0104, and 0x0108), the following applies:
+
+ o The compressor only initializes the MSN for a context when that
+ context is first created or when the profile associated with a
+ context changes;
+
+ o When the MSN is initialized, it is initialized to a random value;
+
+ o The value of the MSN SHOULD be incremented by one for each packet
+ that the compressor sends for a specific CID.
+
+6.3.2. Reordering Ratio
+
+ The control field reorder_ratio specifies how much reordering is
+ handled by the lsb encoding of the MSN. This is useful when header
+ compression is performed over links with varying reordering
+
+
+
+Pelletier & Sandlund Standards Track [Page 21]
+
+RFC 5225 ROHCv2 Profiles April 2008
+
+
+ characteristics. The reorder_ratio control field provides the means
+ for the compressor to adjust the robustness characteristics of the
+ lsb encoding method with respect to reordering and consecutive
+ losses, as described in Section 5.1.2.
+
+6.3.3. 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], has been observed in practice). There is one IP-ID
+ behavior control field per IP header. The control field for the
+ IP-ID behavior of the innermost IP header determines which set of
+ header formats is used. The IP-ID behavior control field is also
+ used to determine the contents of the irregular chain item, for each
+ IP header.
+
+ ROHCv2 profiles MUST NOT assign a sequential behavior (network byte
+ order or byte-swapped) to any IP-ID but the one in the innermost IP
+ header when compressing more than one level of IP headers. This is
+ because only the IP-ID of the innermost IP header is likely to have a
+ 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.4. UDP-Lite Coverage Behavior
+
+ The control field coverage_behavior specifies how the checksum
+ coverage field of the UDP-Lite header is compressed with RoHCv2. It
+ can indicate one of the following encoding methods: irregular,
+ static, or inferred encoding.
+
+6.3.5. Timestamp Stride
+
+ The ts_stride control field is used in scaled RTP timestamp encoding
+ (see Section 6.6.8). It defines the expected increase in the RTP
+ timestamp between consecutive RTP sequence numbers.
+
+6.3.6. Time Stride
+
+ The time_stride control field is used in timer-based compression
+ encoding (see Section 6.6.9). When timer-based compression is used,
+ time_stride should be set to the expected difference in arrival time
+ between consecutive RTP packets.
+
+
+
+
+
+
+Pelletier & Sandlund Standards Track [Page 22]
+
+RFC 5225 ROHCv2 Profiles April 2008
+
+
+6.3.7. CRC-3 for Control Fields
+
+ ROHCv2 profiles define a CRC-3 calculated over a number of control
+ fields. This 3-bit CRC protecting the control fields is present in
+ the header format for the co_common and co_repair header types.
+
+ The decompressor MUST always validate the integrity of the control
+ fields covered by this 3-bit CRC when processing a co_common or a
+ co_repair compressed header.
+
+ Failure to validate the control fields using this CRC should be
+ considered as a decompression failure by the decompressor in the
+ algorithm that assesses the validity of the context. However, if the
+ decompression attempt can be verified using either the CRC-3 or the
+ CRC-7 calculated over the uncompressed header, the decompressor MAY
+ still forward the decompressed header to upper layers. This is
+ because the protected control fields are not always used to
+ decompress the header (i.e., co_common or co_repair) that updates
+ their respective value.
+
+ The CRC polynomial and coverage of this CRC-3 is defined in
+ Section 6.6.11.
+
+6.4. Reconstruction and Verification
+
+ Validation of the IR header (8-bit CRC)
+
+ The decompressor MUST always validate the integrity of the IR
+ header using the 8-bit CRC carried within the IR header. When the
+ header is validated, the decompressor updates the context with the
+ information in the IR header. Otherwise, if the IR cannot be
+ validated, the context MUST NOT be updated and the IR header MUST
+ NOT be delivered to upper layers.
+
+ Verification of CO headers (3-bit CRC or 7-bit CRC)
+
+ The decompressor MUST always verify the decompression of a CO
+ header using the CRC carried within the compressed header. When
+ the decompression is verified and successful, the decompressor
+ updates the context with the information received in the CO
+ 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.
+
+
+
+
+
+
+Pelletier & Sandlund Standards Track [Page 23]
+
+RFC 5225 ROHCv2 Profiles April 2008
+
+
+ Decompressor implementations may attempt corrective or repair
+ measures on CO headers prior to performing the above actions, and
+ the result of any decompression attempt MUST be verified using the
+ CRC.
+
+6.5. Compressed Header Chains
+
+ Some header 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.
+
+ In the text below, the term <protocol_name> is used to identify
+ formal notation names corresponding to different protocol headers.
+ The mapping between these is defined in the following table:
+
+ +----------------------------------+---------------+
+ | Protocol | protocol_name |
+ +----------------------------------+---------------+
+ | IPv4 RFC 0791 | ipv4 |
+ | IPv6 RFC 2460 | ipv6 |
+ | UDP RFC 0768 | udp |
+ | RTP RFC 3550 | rtp |
+ | ESP RFC 4303 | esp |
+ | UDP-Lite RFC 3828 | udp_lite |
+ | AH RFC 4302 | ah |
+ | GRE RFC 2784, RFC 2890 | gre |
+ | MINE RFC 2004 | mine |
+ | IPv6 Destination Option RFC 2460 | dest_opt |
+ | IPv6 Hop-by-hop Options RFC 2460 | hop_opt |
+ | IPv6 Routing Header RFC 2460 | rout_opt |
+ +----------------------------------+---------------+
+
+ Static chain:
+
+ The static chain consists of one item for each header of the chain
+ of protocol headers that is compressed, starting from the
+ outermost IP header. In the formal description of the header
+ formats, this static chain item for each header type is labeled
+ <protocol_name>_static. The static chain is only used in the IR
+ header format.
+
+
+
+
+
+
+Pelletier & Sandlund Standards Track [Page 24]
+
+RFC 5225 ROHCv2 Profiles April 2008
+
+
+ Dynamic chain:
+
+ The dynamic chain consists of one item for each header of the
+ chain of protocol headers that is compressed, starting from the
+ outermost IP header. In the formal description of the header
+ formats, the dynamic chain item for each header type is labeled
+ <protocol_name>_dynamic. The dynamic chain is only used in the IR
+ and co_repair header formats.
+
+ Irregular chain:
+
+ The structure of the irregular chain is analogous to the structure
+ of the static chain. For each compressed header that uses the
+ general format of Section 6.8, the irregular chain is appended at
+ a specific location in the general format of the compressed
+ headers. In the formal description of the header formats, the
+ irregular chain item for each header type is a format whose name
+ is suffixed by "_irregular". The irregular chain is used in all
+ CO headers, except for the co_repair format.
+
+ The format of the irregular chain for the innermost IP header
+ differs from the format used for the outer IP headers, because the
+ innermost IP header is part of the compressed base header. In the
+ definition of the header formats using the formal notation, the
+ argument "is_innermost", which is passed to the corresponding
+ encoding method (ipv4 or ipv6), determines what irregular chain
+ items to use. The format of the irregular chain item for the
+ outer IP headers is also determined using one flag for TTL/Hop
+ Limit and TOS/TC. This flag is defined in the format of some of
+ the compressed base headers.
+
+ ROHCv2 profiles compress extension headers as other headers, and thus
+ extension headers have a static chain, a dynamic chain, and an
+ irregular chain.
+
+ ROHCv2 profiles define chains for all headers that can be compressed,
+ i.e., RTP [RFC3550], UDP [RFC0768], ESP [RFC4303], UDP-Lite
+ [RFC3828], IPv4 [RFC0791], IPv6 [RFC2460], AH [RFC4302], GRE
+ [RFC2784][RFC2890], MINE [RFC2004], IPv6 Destination Options header
+ [RFC2460], IPv6 Hop-by-hop Options header [RFC2460], and IPv6 Routing
+ header [RFC2460].
+
+6.6. Header Formats and Encoding Methods
+
+ The header formats are defined using the ROHC formal notation. Some
+ of the encoding methods used in the header formats are defined in
+ [RFC4997], while other methods are defined in this section.
+
+
+
+
+Pelletier & Sandlund Standards Track [Page 25]
+
+RFC 5225 ROHCv2 Profiles April 2008
+
+
+6.6.1. baseheader_extension_headers
+
+ The baseheader_extension_headers encoding method skips over all
+ fields of the extension headers of the innermost IP header, without
+ encoding any of them. Fields in these extension headers are instead
+ encoded in the irregular chain.
+
+ This encoding is used in CO headers (see Section 6.8.2). The
+ innermost IP header is combined with other header(s) (i.e., UDP, UDP-
+ Lite, RTP) to create the compressed base header. In this case, there
+ may be a number of extension headers between the IP headers and the
+ other headers.
+
+ The base header defines a representation of the extension headers, to
+ comply with the syntax of the formal notation; this encoding method
+ provides this representation.
+
+6.6.2. baseheader_outer_headers
+
+ 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. Changing fields in outer
+ headers are instead handled by the irregular chain.
+
+ This encoding method, similarly to the baseheader_extension_headers
+ encoding method above, is necessary to keep the definition of the
+ header formats syntactically correct. It describes 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.2).
+
+6.6.3. inferred_udp_length
+
+ The decompressor infers the value of the UDP length field as being
+ the sum of the UDP header length and the UDP payload length. The
+ compressor must therefore ensure that the UDP length field is
+ consistent with the length field(s) of preceding subheaders, i.e.,
+ there must not be any padding after the UDP payload that is covered
+ by the IP Length.
+
+ This encoding method is also used for the UDP-Lite Checksum Coverage
+ field when it behaves in the same manner as the UDP length field
+ (i.e., when the checksum always covers the entire UDP-Lite payload).
+
+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:
+
+
+
+Pelletier & Sandlund Standards Track [Page 26]
+
+RFC 5225 ROHCv2 Profiles April 2008
+
+
+ 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. As the data that this checksum
+ protects is mostly compressed away and is instead taken from state
+ stored in the context, this checksum becomes cumulative to the ROHC
+ CRC. When using this encoding method, the checksum is recomputed by
+ the decompressor.
+
+ The inferred_ip_v4_header_checksum encoding method thus compresses
+ the header checksum field of the IPv4 header down to a size of zero
+ bits, i.e., no bits are transmitted in compressed headers for this
+ field. Using this 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 processing
+ 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 bits,
+ 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.
+
+
+
+Pelletier & Sandlund Standards Track [Page 27]
+
+RFC 5225 ROHCv2 Profiles April 2008
+
+
+ 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 processing 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 bits, 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.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 bits, 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.
+
+ IPv6 headers using the jumbo payload option of RFC 2675 [RFC2675]
+ will not be compressible with this encoding method since the value of
+ the payload length field does not match the length of the packet.
+
+
+
+Pelletier & Sandlund Standards Track [Page 28]
+
+RFC 5225 ROHCv2 Profiles April 2008
+
+
+6.6.8. Scaled RTP Timestamp Compression
+
+ This section provides additional details on encodings used to scale
+ the RTP timestamp, as defined in the formal notation in
+ Section 6.8.2.4.
+
+ The RTP timestamp (TS) usually increases by a multiple of the RTP
+ Sequence Number's (SN's) increase and is therefore a suitable
+ candidate for scaled encoding. This scaling factor is labeled
+ ts_stride in the definition of the profile in the formal notation.
+ The compressor sets the scaling factor based on the change in TS with
+ respect to the change in the RTP SN.
+
+ The default value of the scaling factor ts_stride is 160, as defined
+ in Section 6.8.2.4. To use a different value for ts_stride, the
+ compressor explicitly updates the value of ts_stride to the
+ decompressor using one of the header formats that can carry this
+ information.
+
+ When the compressor uses a scaling factor that is different than the
+ default value of ts_stride, it can only use the new scaling factor
+ once it has enough confidence that the decompressor has successfully
+ calculated the residue (ts_offset) of the scaling function for the
+ timestamp. The compressor achieves this by sending unscaled
+ timestamp values, to allow the decompressor to establish the residue
+ based on the current ts_stride. The compressor MAY send the unscaled
+ timestamp in the same compressed header(s) used to establish the
+ value of ts_stride.
+
+ 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.
+
+ When the compressor detects that the residue (ts_offset) value has
+ changed, it MUST NOT select a compressed header format that uses the
+ scaled timestamp encoding before it has re-established the residue as
+ described above.
+
+ 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.
+
+ If the decompressor receives a compressed header containing scaled
+ timestamp bits while the ts_stride equals zero, it MUST NOT deliver
+ the packet to upper layers and it SHOULD treat this as a CRC
+ verification failure.
+
+
+
+Pelletier & Sandlund Standards Track [Page 29]
+
+RFC 5225 ROHCv2 Profiles April 2008
+
+
+ Whether or not the scaling is applied to the RTP TS field is up to
+ the compressor implementation (i.e., the use of scaling is OPTIONAL),
+ and is indicated by the tsc_indicator control field. In case scaling
+ is applied to the RTP TS field, the value of ts_stride used by the
+ compressor is up to the implementation. A value of ts_stride that is
+ set to the expected increase in the RTP timestamp between consecutive
+ unit increases of the RTP SN will provide the most gain for the
+ scaled encoding. Other values may provide the same gain in some
+ situations, but may reduce the gain in others.
+
+ When scaled timestamp encoding is used for header formats that do not
+ transmit any lsb-encoded timestamp bits at all, the
+ inferred_scaled_field encoding of Section 6.6.10 is used for encoding
+ the timestamp.
+
+6.6.9. timer_based_lsb
+
+ The timer-based compression encoding method, timer_based_lsb,
+ compresses a field whose change pattern approximates a linear
+ function of the time of day.
+
+ This encoding uses the local clock to obtain an approximation of the
+ value that it encodes. The approximated value is then used as a
+ reference value together with the num_lsbs_param least-significant
+ bits received as the encoded value, where num_lsbs_param represents a
+ number of bits that is sufficient to uniquely represent the encoded
+ value in the presence of jitter between compression endpoints.
+
+ ts_scaled =:= timer_based_lsb(<time_stride_param>,
+ <num_lsbs_param>, <offset_param>)
+
+ The parameters "num_lsbs_param" and "offset_param" are the parameters
+ to use for the lsb encoding, i.e., the number of least significant
+ bits and the interpretation interval offset, respectively. The
+ parameter "time_stride_param" represents the context value of the
+ control field time_stride.
+
+ This encoding method always uses a scaled version of the field it
+ compresses.
+
+ The value of the field is decoded by calculating an approximation of
+ the scaled value, using:
+
+ tsc_ref_advanced = tsc_ref + (a_n - a_ref) / time_stride.
+
+
+
+
+
+
+
+Pelletier & Sandlund Standards Track [Page 30]
+
+RFC 5225 ROHCv2 Profiles April 2008
+
+
+ where:
+
+ - tsc_ref is a reference value of the scaled representation
+ of the field.
+ - a_n is the arrival time associated with the value to decode.
+ - a_ref is the arrival time associated with the reference header.
+ - tsc_ref_advanced is an approximation of the scaled value
+ of the field.
+
+ The lsb encoding is then applied using the num_lsbs_param bits
+ received in the compressed header and the tsc_ref_advanced as
+ "ref_value" (as per Section 4.11.5 of [RFC4997]).
+
+ Appendix B.3 provides an example of how the compressor can calculate
+ jitter.
+
+ The control field time_stride controls whether or not the
+ timer_based_lsb method is used in the CO header. The decompressor
+ SHOULD send the CLOCK_RESOLUTION option with a zero value, if:
+
+ o it receives a non-zero time_stride value, and
+
+ o it has not previously sent a CLOCK_RESOLUTION feedback with a non-
+ zero value.
+
+ This is to allow compression to recover from the case where a
+ compressor erroneously activates timer-based compression.
+
+ The support and usage of timer-based compression is OPTIONAL for both
+ the compressor and the decompressor; the compressor is not required
+ to set the time_stride control field to a non-zero value when it has
+ received a non-zero value for the CLOCK_RESOLUTION option.
+
+6.6.10. inferred_scaled_field
+
+ The inferred_scaled_field encoding method encodes a field that is
+ defined as changing in relation to the MSN, and for which the
+ increase with respect to the MSN can be scaled by some scaling
+ factor. This encoding method is used in compressed header formats
+ that do not contain any bits for the scaled field. In this case, the
+ decompressor infers the unscaled value of the scaled field from the
+ MSN field. The unscaled value is calculated according to the
+ following formula:
+
+ unscaled_value = delta_msn * stride + reference_unscaled_value
+
+ where "delta_msn" is the difference in MSN between the reference
+ value of the MSN in the context and the value of the MSN decompressed
+
+
+
+Pelletier & Sandlund Standards Track [Page 31]
+
+RFC 5225 ROHCv2 Profiles April 2008
+
+
+ from this packet, "reference_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 + reference_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 [RFC4997], with the difference being that the data 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(ctrl_data_value, ctrl_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 with 6 MSB of zeroes
+
+ o ts_stride, 32 bits (only for profiles 0x0101 and 0x0107)
+
+ o time_stride, 32 bits (only for profiles 0x0101 and 0x0107)
+
+ o msn, 16 bits (not applicable for profiles 0x0101, 0x0103, and
+ 0x0107)
+
+ o coverage_behavior, 2 bits padded with 6 MSB of zeroes (only for
+ profiles 0x0107 and 0x0108)
+
+
+
+
+
+
+Pelletier & Sandlund Standards Track [Page 32]
+
+RFC 5225 ROHCv2 Profiles April 2008
+
+
+ o ip_id_behavior, one octet for each IP header in the compressible
+ header chain starting from the outermost header. Each octet
+ consists of 2 bits padded with 6 MSBs of zeroes.
+
+ The "ctrl_data_length" binds to the sum of the length of the control
+ field(s) that are applicable to the specific profile.
+
+ The decompressor uses the resulting 3-bit CRC to validate the control
+ fields that are updated by the co_common and co_repair header
+ formats; this CRC cannot be used to verify the outcome of a
+ decompression attempt.
+
+ This CRC protects the update of control fields, as the updated values
+ are not always used to decompress the header that carries them and
+ thus are not protected by the CRC-7 verification. This prevents
+ impairments that could occur if the decompression of a co_common or
+ of a co_repair succeeds and the decompressor sends positive feedback,
+ while for some reason the control fields are incorrectly updated.
+
+6.6.12. inferred_sequential_ip_id
+
+ This encoding method is used with a sequential IP-ID behavior
+ (sequential or sequential byte-swapped) and when there are no coded
+ IP-ID bits in the compressed header. In this case, the IP-ID offset
+ from the MSN is constant, and the IP-ID increases by the same amount
+ as the MSN (similar to the inferred_scaled_field encoding method).
+
+ The decompressor calculates the value for the IP-ID according to the
+ following formula:
+
+ IP-ID = delta_msn + reference_IP_ID_value
+
+ where "delta_msn" is the difference between the reference value of
+ the MSN in the context and the uncompressed value of the MSN
+ associated to the compressed header, and where
+ "reference_IP_ID_value" is the value of the IP-ID in the context.
+ For swapped IP-ID behavior (i.e., when ip_id_behavior_innermost is
+ set to IP_ID_BEHAVIOR_SEQUENTIAL_SWAPPED), "reference_IP_ID_value"
+ and "IP-ID" are byte-swapped with regard to the corresponding fields
+ in the context.
+
+ If the IP-ID behavior is random or zero, this encoding method does
+ not update any fields.
+
+
+
+
+
+
+
+
+Pelletier & Sandlund Standards Track [Page 33]
+
+RFC 5225 ROHCv2 Profiles April 2008
+
+
+6.6.13. list_csrc(cc_value)
+
+ This encoding method compresses the list of RTP CSRC identifiers
+ using list compression. This encoding establishes a content for the
+ different CSRC identifiers (items) and a list describing the order in
+ which they appear.
+
+ The compressor passes an argument (cc_value) to this encoding method:
+ this is the value of the CC field taken from the RTP header. 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
+ correctly reconstruct the CC field.
+
+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:
+
+ When initializing the context:
+
+ 1) The complete representation of the list of CSRC identifiers is
+ transmitted.
+
+ Then, once the context has been initialized:
+
+ 2) When the list is unchanged, a compressed header that does not
+ contain information about the list can be used.
+
+ 3) When the list changes, a compressed list is sent in the compressed
+ header, including a representation of its structure and order.
+ Previously unknown items are sent uncompressed in the list, while
+ previously known items are only represented by an index pointing
+ to the item stored in the context.
+
+
+
+
+
+
+
+
+Pelletier & Sandlund Standards Track [Page 34]
+
+RFC 5225 ROHCv2 Profiles April 2008
+
+
+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.
+
+ The compressor MAY reset its item table upon receiving a negative
+ acknowledgement.
+
+ 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 successful (CRC verification, or CRC-8
+ validation). The decompressor retrieves the item from the table
+ whenever an Index is received without an accompanying Item.
+
+ If an index is received without an accompanying Item and the
+ decompressor does not have any context for this index, the
+ decompressor MUST NOT deliver the packet 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 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).
+
+
+
+
+
+Pelletier & Sandlund Standards Track [Page 35]
+
+RFC 5225 ROHCv2 Profiles April 2008
+
+
+ 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; otherwise, the decompressor MUST
+ discard the packet.
+
+ 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 of the list_csrc encoding (see
+ Section 6.6.13).
+
+ XI_1, ..., XI_m: m XI items. Each XI represents one item in the
+ list of items of the uncompressed header, in the same order as
+ they appear in the uncompressed header.
+
+ The format of an XI item is as follows:
+
+ 0 1 2 3
+ +---+---+---+---+
+ PS = 0: | X | Index |
+ +---+---+---+---+
+
+ 0 1 2 3 4 5 6 7
+ +---+---+---+---+---+---+---+---+
+ PS = 1: | X | Reserved | Index |
+ +---+---+---+---+---+---+---+---+
+
+ X: Indicates whether the item is present in the list:
+
+
+
+Pelletier & Sandlund Standards Track [Page 36]
+
+RFC 5225 ROHCv2 Profiles April 2008
+
+
+ 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: MUST be set to zero; otherwise, the decompressor MUST
+ discard the packet.
+
+ Index: An index into the item table. See Section 6.6.13.4
+
+ When 4-bit XI items are used, the XI items are placed in octets
+ in the following manner:
+
+ 0 1 2 3 4 5 6 7
+ +---+---+---+---+---+---+---+---+
+ | XI_k | XI_k + 1 |
+ +---+---+---+---+---+---+---+---+
+
+ Padding: A 4-bit Padding field is present when PS = 0 and the
+ number of XIs is odd. The Padding field MUST be set to zero;
+ otherwise, the decompressor MUST discard the packet.
+
+ 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 in the item
+ table will only cause a slight overhead to the compressor when items
+ are swapped 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 must have all of
+ 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.
+
+
+
+
+
+
+
+
+
+Pelletier & Sandlund Standards Track [Page 37]
+
+RFC 5225 ROHCv2 Profiles April 2008
+
+
+6.7. Encoding Methods with External Parameters as Arguments
+
+ A number of encoding methods in Section 6.8.2.4 have one or more
+ arguments for which the derivation of the parameter's value is
+ outside the scope of the ROHC-FN [RFC4997] specification of the
+ header formats.
+
+ The following is a list of encoding methods with external parameters
+ as arguments, from Section 6.8.2.4:
+
+ o udp(profile_value, reorder_ratio_value)
+
+ o udp_lite(profile_value, reorder_ratio_value,
+ coverage_behavior_value)
+
+ o esp(profile_value, reorder_ratio_value)
+
+ o rtp(profile_value, ts_stride_value, time_stride_value,
+ reorder_ratio_value)
+
+ o ipv4(profile_value, is_innermost, outer_ip_flag,
+ ip_id_behavior_value, reorder_ratio_value))
+
+ o ipv6(profile_value, is_innermost, outer_ip_flag,
+ reorder_ratio_value))
+
+ o iponly_baseheader(profile_value, outer_ip_flag,
+ ip_id_behavior_value, reorder_ratio_value)
+
+ o udp_baseheader(profile_value, outer_ip_flag, ip_id_behavior_value,
+ reorder_ratio_value)
+
+ o udplite_baseheader(profile_value, outer_ip_flag,
+ ip_id_behavior_value, reorder_ratio_value)
+
+ o esp_baseheader(profile_value, outer_ip_flag, ip_id_behavior_value,
+ reorder_ratio_value)
+
+ o rtp_baseheader(profile_value, ts_stride_value, time_stride_value,
+ outer_ip_flag, ip_id_behavior_value, reorder_ratio_value)
+
+ o udplite_rtp_baseheader(profile_value, ts_stride_value,
+ time_stride_value, outer_ip_flag, ip_id_behavior_value,
+ reorder_ratio_value, coverage_behavior_value)
+
+ The following applies for all parameters listed below: At the
+ compressor, the value of the parameter is set according to the
+ recommendations for each parameter. At the decompressor, the value
+
+
+
+Pelletier & Sandlund Standards Track [Page 38]
+
+RFC 5225 ROHCv2 Profiles April 2008
+
+
+ of the parameter is set to undefined and will get bound by encoding
+ methods, except where otherwise noted.
+
+ The following is a list of external arguments with their respective
+ definition:
+
+ o profile_value:
+
+ Set to the 16-bit number that identifies the profile used to
+ compress this packet. When processing the static chain at the
+ decompressor, this parameter is set to the value of the profile
+ field in the IR header (see Section 6.8.1).
+
+ o reorder_ratio_value:
+
+ Set to a 2-bit integer value, using one of the constants whose
+ name begins with the prefix REORDERING_ and as defined in
+ Section 6.8.2.4.
+
+ o ip_id_behavior_value:
+
+ Set to a 2-bit integer value, using one of the constants whose
+ name begins with the prefix IP_ID_BEHAVIOR_ and as defined in
+ Section 6.8.2.4.
+
+ o coverage_behavior_value:
+
+ Set to a 2-bit integer value, using one of the constants whose
+ name begins with the prefix UDP_LITE_COVERAGE_ and as defined
+ in Section 6.8.2.4.
+
+ o outer_ip_flag:
+
+ This parameter is set to 1 if at least one of the TOS/TC or
+ TTL/Hop Limit fields in outer IP headers has changed compared
+ to their reference values in the context; otherwise, it is set
+ to 0. This flag may only be set to 1 for the "co_common"
+ header format in the different profiles.
+
+ o is_innermost:
+
+ This boolean flag is set to 1 when processing the innermost of
+ the compressible IP headers; otherwise, it is set to 0.
+
+
+
+
+
+
+
+
+Pelletier & Sandlund Standards Track [Page 39]
+
+RFC 5225 ROHCv2 Profiles April 2008
+
+
+ o ts_stride_value
+
+ The value of this parameter should be set to the expected
+ increase in the RTP Timestamp between consecutive RTP sequence
+ numbers. The value selected is implementation-specific. See
+ also Section 6.6.8.
+
+ o time_stride_value
+
+ The value of this parameter should be set to the expected
+ inter-arrival time between consecutive packets for the flow.
+ The value selected is implementation-specific. This parameter
+ MUST be set to zero, unless the compressor has received a
+ feedback message with the CLOCK_RESOLUTION option set to a non-
+ zero value. See also Section 6.6.9.
+
+6.8. Header Formats
+
+ ROHCv2 profiles use two different header types: the Initialization
+ and Refresh (IR) header type, and the Compressed header type (CO).
+
+ The CO header type defines a number of header formats: there are two
+ sets of base header formats, with a few additional formats that are
+ common to both sets.
+
+6.8.1. Initialization and Refresh Header Format (IR)
+
+ The IR header format uses the structure of the ROHC IR header as
+ defined in Section 5.2.2.1 of [RFC4995].
+
+ Header type: IR
+
+ This header format communicates the static part and the dynamic
+ part of the context.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Pelletier & Sandlund Standards Track [Page 40]
+
+RFC 5225 ROHCv2 Profiles April 2008
+
+
+ The ROHCv2 IR header 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
+ | |
+ - - - - - - - - - - - - - - - -
+
+ CRC: 8-bit CRC over the entire IR-header, including any CID fields
+ and up until the end of the dynamic chain, using the polynomial
+ defined in [RFC4995]. For purposes of computing the CRC, the CRC
+ field is zero.
+
+ Static chain: See Section 6.5.
+
+ Dynamic chain: See Section 6.5.
+
+6.8.2. Compressed Header Formats (CO)
+
+6.8.2.1. Design Rationale for Compressed Base Headers
+
+ The compressed header formats are defined as two separate sets for
+ each profile: one set for the headers where the innermost IP header
+ contains a sequential IP-ID (either network byte order or byte-
+ swapped), and one set for the headers without sequential IP-ID
+ (either random, zero, or no IP-ID). There are also a number of
+ common header formats shared between both sets. In the description
+ below, the naming convention used for header formats that belong to
+ the sequential set is to include "seq" in the name of the format,
+ while similarly "rnd" is used for those that belong to the non-
+ sequential set.
+
+
+
+Pelletier & Sandlund Standards Track [Page 41]
+
+RFC 5225 ROHCv2 Profiles April 2008
+
+
+ The design of the header formats is derived from the field behavior
+ analysis found in Appendix A.
+
+ All of the compressed base headers transmit lsb-encoded MSN bits and
+ a CRC.
+
+ The following header formats exist for all profiles defined in this
+ document, and are common to both the sequential and the random header
+ format sets:
+
+ o co_common: This format can be used to update the context when the
+ established change pattern of a dynamic field changes, for any of
+ the dynamic fields. However, not all dynamic fields are updated
+ by conveying their uncompressed value; some fields can only be
+ transmitted using a compressed representation. This format is
+ especially useful when a rarely changing field needs to be
+ updated. This format contains a set of flags to indicate what
+ fields are present in the header, and its size can vary
+ accordingly. This format is protected by a 7-bit CRC. It can
+ update control fields, and it thus also carries a 3-bit CRC to
+ protect those fields. This format is similar in purpose to the
+ UOR-2-extension 3 format of [RFC3095].
+
+ o co_repair: This format can be used to update the context of all
+ the dynamic fields by conveying their uncompressed value. This is
+ especially useful when context damage is assumed (e.g., from the
+ reception of a NACK) and a context repair is performed. This
+ format is protected by a 7-bit CRC. It also carries a 3-bit CRC
+ over the control fields that it can update. This format is
+ similar in purpose to the IR-DYN format of [RFC3095] when
+ performing context repairs.
+
+ o pt_0_crc3: This format conveys only the MSN; it can therefore only
+ update the MSN and fields that are derived from the MSN, such as
+ IP-ID and the RTP Timestamp (for applicable profiles). It is
+ protected by a 3-bit CRC. This format is equivalent to the UO-0
+ header format in [RFC3095].
+
+ o pt_0_crc7: This format has the same properties as pt_0_crc3, but
+ is instead protected by a 7-bit CRC and contains a larger amount
+ of lsb-encoded MSN bits. This format is useful in environments
+ where a high amount of reordering or a high-residual error rate
+ can occur.
+
+
+
+
+
+
+
+
+Pelletier & Sandlund Standards Track [Page 42]
+
+RFC 5225 ROHCv2 Profiles April 2008
+
+
+ The following header format descriptions apply to profiles 0x0101 and
+ 0x0107.
+
+ o pt_1_rnd: This format can convey changes to the MSN and to the RTP
+ Marker bit, and it can update the RTP timestamp using scaled
+ timestamp encoding. It is protected by a 3-bit CRC. It is
+ similar in purpose to the UO-1 format in [RFC3095].
+
+ o pt_1_seq_id: This format can convey changes to the MSN and to the
+ IP-ID. It is protected by a 3-bit CRC. It is similar in purpose
+ to the UO-1-ID format in [RFC3095].
+
+ o pt_1_seq_ts: This format can convey changes to the MSN and to the
+ RTP Marker bit, and it can update the RTP Timestamp using scaled
+ timestamp encoding. It is protected by a 3-bit CRC. It is
+ similar in purpose to the UO-1-TS format in [RFC3095].
+
+ o pt_2_rnd: This format can convey changes to the MSN, to the RTP
+ Marker bit, and to the RTP Timestamp. It is protected by a 7-bit
+ CRC. It is similar in purpose to the UOR-2 format in [RFC3095].
+
+ o pt_2_seq_id: This format can convey changes to the MSN and to the
+ IP-ID. It is protected by a 7-bit CRC. It is similar in purpose
+ to the UO-2-ID format in [RFC3095].
+
+ o pt_2_seq_ts: This format can convey changes to the MSN, to the RTP
+ Marker bit and it can update the RTP Timestamp using scaled
+ timestamp encoding. It is protected by a 7-bit CRC. It is
+ similar in purpose to the UO-2-TS format in [RFC3095].
+
+ o pt_2_seq_both: This format can convey changes to both the RTP
+ Timestamp and the IP-ID, in addition to the MSN and to the Marker
+ bit. It is protected by a 7-bit CRC. It is similar in purpose to
+ the UOR-2-ID extension 1 format in [RFC3095].
+
+ The following header format descriptions apply to profiles 0x0102,
+ 0x0103, 0x0104, and 0x0108.
+
+ o pt_1_seq_id: This format can convey changes to the MSN and to the
+ IP-ID. It is protected by a 7-bit CRC. It is similar in purpose
+ to the UO-1-ID format in [RFC3095].
+
+ o pt_2_seq_id: This format can convey changes to the MSN and to the
+ IP-ID. It is protected by a 7-bit CRC. It is similar in purpose
+ to the UO-2-ID format in [RFC3095].
+
+
+
+
+
+
+Pelletier & Sandlund Standards Track [Page 43]
+
+RFC 5225 ROHCv2 Profiles April 2008
+
+
+6.8.2.2. co_repair Header Format
+
+ The ROHCv2 co_repair header has the following format:
+
+ 0 1 2 3 4 5 6 7
+ --- --- --- --- --- --- --- ---
+ : Add-CID octet : if for small CIDs and CID 1-15
+ +---+---+---+---+---+---+---+---+
+ | 1 1 1 1 1 0 1 1 | discriminator
+ +---+---+---+---+---+---+---+---+
+ : :
+ / 0, 1, or 2 octets of CID / 1-2 octets if large CIDs
+ : :
+ +---+---+---+---+---+---+---+---+
+ |r1 | CRC-7 |
+ +---+---+---+---+---+---+---+---+
+ | r2 | CRC-3 |
+ +---+---+---+---+---+---+---+---+
+ | |
+ / Dynamic chain / variable length
+ | |
+ - - - - - - - - - - - - - - - -
+
+ r1: MUST be set to zero; otherwise, the decompressor MUST discard
+ the packet.
+
+ CRC-7: A 7-bit CRC over the entire uncompressed header, computed
+ using the crc7 (data_value, data_length) encoding method defined
+ in Section 6.8.2.4, where data_value corresponds to the entire
+ uncompressed header chain and where data_length corresponds to the
+ length of this header chain.
+
+ r2: MUST be set to zero; otherwise, the decompressor MUST discard
+ the packet.
+
+ CRC-3: Encoded using the control_crc3_encoding method defined in
+ Section 6.6.11.
+
+ Dynamic chain: See Section 6.5.
+
+6.8.2.3. General CO Header Format
+
+ The CO header format communicates irregularities in the packet
+ header. All CO formats carry a CRC and can update the context. All
+ CO header formats use the general format defined in this section,
+ with the exception of the co_repair format, which is defined in
+ Section 6.8.2.2.
+
+
+
+
+Pelletier & Sandlund Standards Track [Page 44]
+
+RFC 5225 ROHCv2 Profiles April 2008
+
+
+ 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 length
+ +---+---+---+---+---+---+---+---+
+ : :
+ / Irregular Chain / variable length
+ : :
+ --- --- --- --- --- --- --- ---
+
+ 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. The base header formats are defined in
+ Section 6.8.2.4. In the formal description of the header formats,
+ the base header for each profile is labeled
+ <profile_name>_baseheader, where <profile_name> is defined in the
+ following table:
+
+ +------------------+----------------+
+ | Profile number | profile_name |
+ +------------------+----------------+
+ | 0x0101 | rtp |
+ | 0x0102 | udp |
+ | 0x0103 | esp |
+ | 0x0104 | ip |
+ | 0x0107 | udplite_rtp |
+ | 0x0108 | udplite |
+ +------------------+----------------+
+
+6.8.2.4. Header Formats in ROHC-FN
+
+ This section defines the complete set of base header formats for
+ ROHCv2 profiles. The base header formats are defined using the ROHC
+ Formal Notation [RFC4997].
+
+
+
+
+
+
+
+
+Pelletier & Sandlund Standards Track [Page 45]
+
+RFC 5225 ROHCv2 Profiles April 2008
+
+
+// NOTE: The irregular, static, and dynamic chains (see Section 6.5)
+// are defined across multiple encoding methods and are embodied
+// in the correspondingly named formats within those encoding
+// methods. In particular, note that the static and dynamic
+// chains ordinarily go together. The uncompressed fields are
+// defined across these two formats combined, rather than in one
+// or the other of them. The irregular chain items are likewise
+// combined with a baseheader format.
+
+////////////////////////////////////////////
+// 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
+UDP_LITE_COVERAGE_INFERRED = 0;
+UDP_LITE_COVERAGE_STATIC = 1;
+UDP_LITE_COVERAGE_IRREGULAR = 2;
+// The value 3 is reserved and cannot be used for coverage behavior
+
+// 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
+
+// Default values for RTP timestamp encoding
+TS_STRIDE_DEFAULT = 160;
+TIME_STRIDE_DEFAULT = 0;
+
+////////////////////////////////////////////
+// Global control fields
+////////////////////////////////////////////
+
+CONTROL {
+
+
+
+Pelletier & Sandlund Standards Track [Page 46]
+
+RFC 5225 ROHCv2 Profiles April 2008
+
+
+ profile [ 16 ];
+ msn [ 16 ];
+ reorder_ratio [ 2 ];
+ // ip_id fields are for innermost IP header only
+ ip_id_offset [ 16 ];
+ ip_id_behavior_innermost [ 2 ];
+ // The following are only used in RTP-based profiles
+ ts_stride [ 32 ];
+ time_stride [ 32 ];
+ ts_scaled [ 32 ];
+ ts_offset [ 32 ];
+ // UDP-lite-based profiles only
+ coverage_behavior [ 2 ];
+}
+
+///////////////////////////////////////////////
+// Encoding methods not specified in FN syntax:
+///////////////////////////////////////////////
+
+baseheader_extension_headers "defined in Section 6.6.1";
+baseheader_outer_headers "defined in Section 6.6.2";
+control_crc3_encoding "defined in Section 6.6.11";
+inferred_ip_v4_header_checksum "defined in Section 6.6.4";
+inferred_ip_v4_length "defined in Section 6.6.6";
+inferred_ip_v6_length "defined in Section 6.6.7";
+inferred_mine_header_checksum "defined in Section 6.6.5";
+inferred_scaled_field "defined in Section 6.6.10";
+inferred_sequential_ip_id "defined in Section 6.6.12";
+inferred_udp_length "defined in Section 6.6.3";
+list_csrc(cc_value) "defined in Section 6.6.13";
+timer_based_lsb(time_stride, k, p) "defined in Section 6.6.9";
+
+////////////////////////////////////////////
+// General encoding methods
+////////////////////////////////////////////
+
+static_or_irreg(flag, width)
+{
+ UNCOMPRESSED {
+ field [ width ];
+ }
+
+ COMPRESSED irreg_enc {
+ ENFORCE(flag == 1);
+ field =:= irregular(width) [ width ];
+ }
+
+ COMPRESSED static_enc {
+
+
+
+Pelletier & Sandlund Standards Track [Page 47]
+
+RFC 5225 ROHCv2 Profiles April 2008
+
+
+ ENFORCE(flag == 0);
+ field =:= static [ 0 ];
+ }
+}
+
+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 ];
+ }
+}
+
+// Send the entire value, or keep previous value
+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);
+
+
+
+Pelletier & Sandlund Standards Track [Page 48]
+
+RFC 5225 ROHCv2 Profiles April 2008
+
+
+ ENFORCE(field.CVALUE == field.UVALUE);
+ discriminator =:= '110' [ 3 ];
+ field [ 21 ];
+ }
+
+ COMPRESSED present_28bit {
+ 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;
+ }
+}
+
+// Send the entire value, or revert to default value
+sdvl_or_default(flag, default_value)
+{
+ 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 ];
+ }
+
+
+
+Pelletier & Sandlund Standards Track [Page 49]
+
+RFC 5225 ROHCv2 Profiles April 2008
+
+
+ COMPRESSED present_21bit {
+ ENFORCE(flag == 1);
+ ENFORCE(field.UVALUE < 2^21);
+ ENFORCE(field.CVALUE == field.UVALUE);
+ discriminator =:= '110' [ 3 ];
+ field [ 21 ];
+ }
+
+ COMPRESSED present_28bit {
+ 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 =:= uncompressed_value(32, default_value);
+ }
+}
+
+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)
+{
+
+
+
+Pelletier & Sandlund Standards Track [Page 50]
+
+RFC 5225 ROHCv2 Profiles April 2008
+
+
+ UNCOMPRESSED {
+ }
+ COMPRESSED {
+ crc_value =:= crc(3, 0x06, 0x07, data_value, data_length) [ 3 ];
+ }
+}
+
+crc7(data_value, data_length)
+{
+ 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.
+// Does not have an uncompressed side.
+field_scaling(stride_value, scaled_value, unscaled_value, residue_value)
+{
+ UNCOMPRESSED {
+ // Nothing
+ }
+
+ COMPRESSED no_scaling {
+ ENFORCE(stride_value == 0);
+ ENFORCE(residue_value == unscaled_value);
+ ENFORCE(scaled_value == 0);
+ }
+
+ COMPRESSED scaling_used {
+ ENFORCE(stride_value != 0);
+ ENFORCE(residue_value == (unscaled_value % stride_value));
+ ENFORCE(unscaled_value ==
+ scaled_value * stride_value + residue_value);
+ }
+}
+
+////////////////////////////////////////////
+// IPv6 Destination options header
+////////////////////////////////////////////
+
+ip_dest_opt
+{
+ UNCOMPRESSED {
+
+
+
+Pelletier & Sandlund Standards Track [Page 51]
+
+RFC 5225 ROHCv2 Profiles April 2008
+
+
+ next_header [ 8 ];
+ length [ 8 ];
+ value [ length.UVALUE * 64 + 48 ];
+ }
+
+ DEFAULT {
+ length =:= static;
+ next_header =:= static;
+ value =:= static;
+ }
+
+ 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 {
+ }
+
+}
+
+////////////////////////////////////////////
+// IPv6 Hop-by-Hop options header
+////////////////////////////////////////////
+
+ip_hop_opt
+{
+ 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 ];
+ }
+
+
+
+Pelletier & Sandlund Standards Track [Page 52]
+
+RFC 5225 ROHCv2 Profiles April 2008
+
+
+ COMPRESSED hop_opt_dynamic {
+ value =:=
+ irregular(length.UVALUE*64+48) [ length.UVALUE * 64 + 48 ];
+ }
+
+ COMPRESSED hop_opt_irregular {
+ }
+
+}
+
+////////////////////////////////////////////
+// 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
+////////////////////////////////////////////
+
+optional_lsb_7_or_31(flag)
+{
+
+
+
+Pelletier & Sandlund Standards Track [Page 53]
+
+RFC 5225 ROHCv2 Profiles April 2008
+
+
+ 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 =:= '0' [ 1 ];
+ protocol =:= uncompressed_value(16, 0x0800) [ 0 ];
+ }
+
+ COMPRESSED ether_v6 {
+ discriminator =:= '1' [ 1 ];
+
+
+
+Pelletier & Sandlund Standards Track [Page 54]
+
+RFC 5225 ROHCv2 Profiles April 2008
+
+
+ protocol =:= uncompressed_value(16, 0x86DD) [ 0 ];
+ }
+}
+
+gre
+{
+ 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 {
+ ENFORCE((c_flag.UVALUE == 1 && checksum_and_res.ULENGTH == 32)
+ || checksum_and_res.ULENGTH == 0);
+ ENFORCE((s_flag.UVALUE == 1 && sequence_number.ULENGTH == 32)
+ || sequence_number.ULENGTH == 0);
+ 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 Standards Track [Page 55]
+
+RFC 5225 ROHCv2 Profiles April 2008
+
+
+ checksum_and_res =:= optional_checksum(c_flag.UVALUE) [ 0, 16 ];
+ sequence_number =:=
+ optional_lsb_7_or_31(s_flag.UVALUE) [ 0, 8, 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 {
+ }
+
+ COMPRESSED mine_irregular {
+ }
+}
+
+/////////////////////////////////////////////
+
+
+
+Pelletier & Sandlund Standards Track [Page 56]
+
+RFC 5225 ROHCv2 Profiles April 2008
+
+
+// Authentication Header (AH)
+/////////////////////////////////////////////
+
+ah
+{
+ UNCOMPRESSED {
+ next_header [ 8 ];
+ length [ 8 ];
+ res_bits =:= uncompressed_value(16, 0) [ 16 ];
+ spi [ 32 ];
+ sequence_number [ 32 ];
+ icv [ length.UVALUE*32-32 ];
+ }
+
+ DEFAULT {
+ next_header =:= static;
+ length =:= 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 ];
+ icv =:=
+ irregular(length.UVALUE*32-32) [ length.UVALUE*32-32 ];
+ }
+
+ COMPRESSED ah_irregular {
+ sequence_number =:= lsb_7_or_31 [ 8, 32 ];
+ icv =:=
+ irregular(length.UVALUE*32-32) [ length.UVALUE*32-32 ];
+ }
+
+}
+
+/////////////////////////////////////////////
+// IPv6 Header
+/////////////////////////////////////////////
+
+fl_enc
+{
+ UNCOMPRESSED {
+
+
+
+Pelletier & Sandlund Standards Track [Page 57]
+
+RFC 5225 ROHCv2 Profiles April 2008
+
+
+ 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_value, is_innermost, outer_ip_flag, reorder_ratio_value)
+{
+ 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 ];
+ }
+
+ CONTROL {
+ ENFORCE(profile == profile_value);
+ ENFORCE(reorder_ratio.UVALUE == reorder_ratio_value);
+ ENFORCE(innermost_ip.UVALUE == is_innermost);
+ innermost_ip [ 1 ];
+ }
+
+ 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 {
+ version_flag =:= '1' [ 1 ];
+ innermost_ip =:= irregular(1) [ 1 ];
+
+
+
+Pelletier & Sandlund Standards Track [Page 58]
+
+RFC 5225 ROHCv2 Profiles April 2008
+
+
+ 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_value == PROFILE_IP_0104));
+ tos_tc =:= irregular(8) [ 8 ];
+ ttl_hopl =:= irregular(8) [ 8 ];
+ reserved =:= compressed_value(6, 0) [ 6 ];
+ reorder_ratio =:= irregular(2) [ 2 ];
+ msn =:= irregular(16) [ 16 ];
+ }
+
+ COMPRESSED ipv6_regular_dynamic {
+ ENFORCE((is_innermost == 0) ||
+ (profile_value != PROFILE_IP_0104));
+ tos_tc =:= irregular(8) [ 8 ];
+ ttl_hopl =:= irregular(8) [ 8 ];
+ }
+
+ COMPRESSED ipv6_outer_irregular {
+ ENFORCE(is_innermost == 0);
+ tos_tc =:=
+ static_or_irreg(outer_ip_flag, 8) [ 0, 8 ];
+ ttl_hopl =:=
+ static_or_irreg(outer_ip_flag, 8) [ 0, 8 ];
+ }
+
+ COMPRESSED ipv6_innermost_irregular {
+ ENFORCE(is_innermost == 1);
+ }
+
+}
+
+/////////////////////////////////////////////
+// IPv4 Header
+/////////////////////////////////////////////
+
+ip_id_enc_dyn(behavior)
+{
+ UNCOMPRESSED {
+ ip_id [ 16 ];
+ }
+
+
+
+
+Pelletier & Sandlund Standards Track [Page 59]
+
+RFC 5225 ROHCv2 Profiles April 2008
+
+
+ COMPRESSED ip_id_seq {
+ ENFORCE((behavior == IP_ID_BEHAVIOR_SEQUENTIAL) ||
+ (behavior == IP_ID_BEHAVIOR_SEQUENTIAL_SWAPPED));
+ ENFORCE(ip_id_offset.UVALUE == ip_id.UVALUE - msn.UVALUE);
+ ip_id =:= irregular(16) [ 16 ];
+ }
+
+ COMPRESSED ip_id_random {
+ 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_enc_irreg(behavior)
+{
+ UNCOMPRESSED {
+ ip_id [ 16 ];
+ }
+
+ COMPRESSED ip_id_seq {
+ ENFORCE(behavior == IP_ID_BEHAVIOR_SEQUENTIAL);
+ }
+
+ 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 ];
+ }
+}
+
+ipv4(profile_value, is_innermost, outer_ip_flag, ip_id_behavior_value,
+ reorder_ratio_value)
+{
+ UNCOMPRESSED {
+ version =:= uncompressed_value(4, 4) [ 4 ];
+
+
+
+Pelletier & Sandlund Standards Track [Page 60]
+
+RFC 5225 ROHCv2 Profiles April 2008
+
+
+ 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 {
+ ENFORCE(profile == profile_value);
+ ENFORCE(reorder_ratio.UVALUE == reorder_ratio_value);
+ ENFORCE(innermost_ip.UVALUE == is_innermost);
+ ip_id_behavior_outer [ 2 ];
+ innermost_ip [ 1 ];
+ }
+
+ DEFAULT {
+ tos_tc =:= static;
+ df =:= static;
+ ttl_hopl =:= static;
+ protocol =:= static;
+ src_addr =:= static;
+ dst_addr =:= static;
+ ip_id_behavior_outer =:= static;
+ }
+
+ COMPRESSED ipv4_static {
+ version_flag =:= '0' [ 1 ];
+ innermost_ip =:= irregular(1) [ 1 ];
+ reserved =:= '000000' [ 6 ];
+ protocol =:= irregular(8) [ 8 ];
+ src_addr =:= irregular(32) [ 32 ];
+ dst_addr =:= irregular(32) [ 32 ];
+ }
+
+ COMPRESSED ipv4_endpoint_innermost_dynamic {
+ ENFORCE((is_innermost == 1) && (profile_value == PROFILE_IP_0104));
+ ENFORCE(ip_id_behavior_innermost.UVALUE == ip_id_behavior_value);
+ reserved =:= '000' [ 3 ];
+ reorder_ratio =:= irregular(2) [ 2 ];
+ df =:= irregular(1) [ 1 ];
+
+
+
+Pelletier & Sandlund Standards Track [Page 61]
+
+RFC 5225 ROHCv2 Profiles April 2008
+
+
+ ip_id_behavior_innermost =:= irregular(2) [ 2 ];
+ tos_tc =:= irregular(8) [ 8 ];
+ ttl_hopl =:= irregular(8) [ 8 ];
+ ip_id =:= ip_id_enc_dyn(ip_id_behavior_innermost.UVALUE) [ 0, 16 ];
+ msn =:= irregular(16) [ 16 ];
+ }
+
+ COMPRESSED ipv4_regular_innermost_dynamic {
+ ENFORCE((is_innermost == 1) && (profile_value != PROFILE_IP_0104));
+ ENFORCE(ip_id_behavior_innermost.UVALUE == ip_id_behavior_value);
+ reserved =:= '00000' [ 5 ];
+ df =:= irregular(1) [ 1 ];
+ ip_id_behavior_innermost =:= irregular(2) [ 2 ];
+ tos_tc =:= irregular(8) [ 8 ];
+ ttl_hopl =:= irregular(8) [ 8 ];
+ ip_id =:= ip_id_enc_dyn(ip_id_behavior_innermost.UVALUE) [ 0, 16 ];
+ }
+
+ COMPRESSED ipv4_outer_dynamic {
+ ENFORCE(is_innermost == 0);
+ ENFORCE(ip_id_behavior_outer.UVALUE == ip_id_behavior_value);
+ reserved =:= '00000' [ 5 ];
+ df =:= irregular(1) [ 1 ];
+ ip_id_behavior_outer =:= irregular(2) [ 2 ];
+ tos_tc =:= irregular(8) [ 8 ];
+ ttl_hopl =:= irregular(8) [ 8 ];
+ ip_id =:= ip_id_enc_dyn(ip_id_behavior_outer.UVALUE) [ 0, 16 ];
+ }
+
+ COMPRESSED ipv4_outer_irregular {
+ ENFORCE(is_innermost == 0);
+ ip_id =:=
+ ip_id_enc_irreg(ip_id_behavior_outer.UVALUE) [ 0, 16 ];
+ tos_tc =:= static_or_irreg(outer_ip_flag, 8) [ 0, 8 ];
+ ttl_hopl =:= static_or_irreg(outer_ip_flag, 8) [ 0, 8 ];
+ }
+
+ COMPRESSED ipv4_innermost_irregular {
+ ENFORCE(is_innermost == 1);
+ ip_id =:=
+ ip_id_enc_irreg(ip_id_behavior_innermost.UVALUE) [ 0, 16 ];
+ }
+
+}
+
+/////////////////////////////////////////////
+// UDP Header
+/////////////////////////////////////////////
+
+
+
+Pelletier & Sandlund Standards Track [Page 62]
+
+RFC 5225 ROHCv2 Profiles April 2008
+
+
+udp(profile_value, reorder_ratio_value)
+{
+ UNCOMPRESSED {
+ ENFORCE((profile_value == PROFILE_RTP_0101) ||
+ (profile_value == PROFILE_UDP_0102));
+ src_port [ 16 ];
+ dst_port [ 16 ];
+ udp_length =:= inferred_udp_length [ 16 ];
+ checksum [ 16 ];
+ }
+
+ CONTROL {
+ ENFORCE(profile == profile_value);
+ ENFORCE(reorder_ratio.UVALUE == reorder_ratio_value);
+ checksum_used [ 1 ];
+ }
+
+ DEFAULT {
+ src_port =:= static;
+ dst_port =:= static;
+ checksum_used =:= static;
+ }
+
+ COMPRESSED udp_static {
+ src_port =:= irregular(16) [ 16 ];
+ dst_port =:= irregular(16) [ 16 ];
+ }
+
+ COMPRESSED udp_endpoint_dynamic {
+ ENFORCE(profile_value == PROFILE_UDP_0102);
+ ENFORCE(profile == PROFILE_UDP_0102);
+ ENFORCE(checksum_used.UVALUE == (checksum.UVALUE != 0));
+ checksum =:= irregular(16) [ 16 ];
+ msn =:= irregular(16) [ 16 ];
+ reserved =:= compressed_value(6, 0) [ 6 ];
+ reorder_ratio =:= irregular(2) [ 2 ];
+ }
+
+ COMPRESSED udp_regular_dynamic {
+ ENFORCE(profile_value == PROFILE_RTP_0101);
+ ENFORCE(checksum_used.UVALUE == (checksum.UVALUE != 0));
+ checksum =:= irregular(16) [ 16 ];
+ }
+
+ COMPRESSED udp_zero_checksum_irregular {
+ ENFORCE(checksum_used.UVALUE == 0);
+ checksum =:= uncompressed_value(16, 0) [ 0 ];
+ }
+
+
+
+Pelletier & Sandlund Standards Track [Page 63]
+
+RFC 5225 ROHCv2 Profiles April 2008
+
+
+ COMPRESSED udp_with_checksum_irregular {
+ ENFORCE(checksum_used.UVALUE == 1);
+ checksum =:= irregular(16) [ 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 ];
+ }
+}
+
+rtp(profile_value, ts_stride_value, time_stride_value,
+ reorder_ratio_value)
+{
+ UNCOMPRESSED {
+ ENFORCE((profile_value == PROFILE_RTP_0101) ||
+ (profile_value == 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 {
+
+
+
+Pelletier & Sandlund Standards Track [Page 64]
+
+RFC 5225 ROHCv2 Profiles April 2008
+
+
+ ENFORCE(profile == profile_value);
+ ENFORCE(reorder_ratio.UVALUE == reorder_ratio_value);
+ ENFORCE(time_stride_value == time_stride.UVALUE);
+ ENFORCE(ts_stride_value == ts_stride.UVALUE);
+ dummy_field =:= field_scaling(ts_stride.UVALUE,
+ ts_scaled.UVALUE, timestamp.UVALUE, ts_offset.UVALUE) [ 0 ];
+ }
+
+ INITIAL {
+ ts_stride =:= uncompressed_value(32, TS_STRIDE_DEFAULT);
+ time_stride =:= uncompressed_value(32, TIME_STRIDE_DEFAULT);
+ }
+
+ 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;
+ ts_stride =:= static;
+ time_stride =:= static;
+ ts_scaled =:= static;
+ ts_offset =:= static;
+ }
+
+ COMPRESSED rtp_static {
+ ssrc =:= irregular(32) [ 32 ];
+ }
+
+ COMPRESSED rtp_dynamic {
+ reserved =:= compressed_value(1, 0) [ 1 ];
+ reorder_ratio =:= irregular(2) [ 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_default(tss_indicator.CVALUE,
+ TS_STRIDE_DEFAULT) [ VARIABLE ];
+
+
+
+Pelletier & Sandlund Standards Track [Page 65]
+
+RFC 5225 ROHCv2 Profiles April 2008
+
+
+ time_stride =:= sdvl_or_default(tis_indicator.CVALUE,
+ TIME_STRIDE_DEFAULT) [ VARIABLE ];
+ csrc_list =:= csrc_list_dynchain(list_present.CVALUE,
+ 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);
+ 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 {
+
+
+
+Pelletier & Sandlund Standards Track [Page 66]
+
+RFC 5225 ROHCv2 Profiles April 2008
+
+
+ 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_value, reorder_ratio_value, coverage_behavior_value)
+{
+ UNCOMPRESSED {
+ ENFORCE((profile_value == PROFILE_RTP_0107) ||
+ (profile_value == PROFILE_UDPLITE_0108));
+ src_port [ 16 ];
+ dst_port [ 16 ];
+ checksum_coverage [ 16 ];
+ checksum [ 16 ];
+ }
+
+ CONTROL {
+ ENFORCE(profile == profile_value);
+ ENFORCE(coverage_behavior.UVALUE == coverage_behavior_value);
+ ENFORCE(reorder_ratio.UVALUE == reorder_ratio_value);
+ }
+
+ DEFAULT {
+ src_port =:= static;
+ dst_port =:= static;
+ coverage_behavior =:= static;
+ }
+
+ COMPRESSED udp_lite_static {
+ src_port =:= irregular(16) [ 16 ];
+ dst_port =:= irregular(16) [ 16 ];
+ }
+
+ COMPRESSED udp_lite_endpoint_dynamic {
+ ENFORCE(profile_value == PROFILE_UDPLITE_0108);
+ reserved =:= compressed_value(4, 0) [ 4 ];
+ coverage_behavior =:= irregular(2) [ 2 ];
+ reorder_ratio =:= irregular(2) [ 2 ];
+ checksum_coverage =:=
+ checksum_coverage_dynchain(coverage_behavior.UVALUE) [ 16 ];
+ checksum =:= irregular(16) [ 16 ];
+ msn =:= irregular(16) [ 16 ];
+ }
+
+
+
+Pelletier & Sandlund Standards Track [Page 67]
+
+RFC 5225 ROHCv2 Profiles April 2008
+
+
+ COMPRESSED udp_lite_regular_dynamic {
+ ENFORCE(profile_value == PROFILE_RTP_0107);
+ coverage_behavior =:= irregular(2) [ 2 ];
+ reserved =:= compressed_value(6, 0) [ 6 ];
+ checksum_coverage =:=
+ checksum_coverage_dynchain(coverage_behavior.UVALUE) [ 16 ];
+ checksum =:= irregular(16) [ 16 ];
+ }
+
+ COMPRESSED udp_lite_irregular {
+ checksum_coverage =:=
+ checksum_coverage_irregular(coverage_behavior.UVALUE) [ 0, 16 ];
+ checksum =:= irregular(16) [ 16 ];
+ }
+}
+
+/////////////////////////////////////////////
+// ESP Header
+/////////////////////////////////////////////
+
+esp(profile_value, reorder_ratio_value)
+{
+ UNCOMPRESSED {
+ ENFORCE(profile_value == PROFILE_ESP_0103);
+ ENFORCE(msn.UVALUE == sequence_number.UVALUE % 65536);
+ spi [ 32 ];
+ sequence_number [ 32 ];
+ }
+
+ CONTROL {
+ ENFORCE(profile == profile_value);
+ ENFORCE(reorder_ratio.UVALUE == reorder_ratio_value);
+ }
+
+ DEFAULT {
+ spi =:= static;
+ sequence_number =:= static;
+ }
+
+ COMPRESSED esp_static {
+ spi =:= irregular(32) [ 32 ];
+ }
+
+ COMPRESSED esp_dynamic {
+ sequence_number =:= irregular(32) [ 32 ];
+ reserved =:= compressed_value(6, 0) [ 6 ];
+ reorder_ratio =:= irregular(2) [ 2 ];
+ }
+
+
+
+Pelletier & Sandlund Standards Track [Page 68]
+
+RFC 5225 ROHCv2 Profiles April 2008
+
+
+ COMPRESSED esp_irregular {
+ }
+}
+
+///////////////////////////////////////////////////
+// Encoding methods used in the profiles' CO headers
+///////////////////////////////////////////////////
+
+// Variable reordering offset used for MSN
+msn_lsb(k)
+{
+ UNCOMPRESSED {
+ master [ VARIABLE ];
+ }
+
+ 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);
+ }
+}
+
+ip_id_lsb(behavior, k)
+{
+ UNCOMPRESSED {
+ ip_id [ 16 ];
+ }
+
+ CONTROL {
+ ip_id_nbo [ 16 ];
+ }
+
+ COMPRESSED nbo {
+ ENFORCE(behavior == IP_ID_BEHAVIOR_SEQUENTIAL);
+
+
+
+Pelletier & Sandlund Standards Track [Page 69]
+
+RFC 5225 ROHCv2 Profiles April 2008
+
+
+ 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 ];
+ }
+}
+
+ip_id_sequential_variable(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);
+ ENFORCE(ip_id_offset.UVALUE == ip_id.UVALUE - msn.UVALUE);
+ ip_id =:= irregular(16) [ 16 ];
+ }
+
+ COMPRESSED not_present {
+ ENFORCE((behavior == IP_ID_BEHAVIOR_RANDOM) ||
+ (behavior == IP_ID_BEHAVIOR_ZERO));
+ }
+}
+
+dont_fragment(version)
+{
+ UNCOMPRESSED {
+ df [ 0, 1 ];
+ }
+
+ COMPRESSED v4 {
+
+
+
+Pelletier & Sandlund Standards Track [Page 70]
+
+RFC 5225 ROHCv2 Profiles April 2008
+
+
+ ENFORCE(version == 4);
+ df =:= irregular(1) [ 1 ];
+ }
+
+ COMPRESSED v6 {
+ ENFORCE(version == 6);
+ unused =:= compressed_value(1, 0) [ 1 ];
+ }
+}
+
+pt_irr_or_static(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;
+ }
+
+ 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 {
+
+
+
+Pelletier & Sandlund Standards Track [Page 71]
+
+RFC 5225 ROHCv2 Profiles April 2008
+
+
+ timestamp [ 32 ];
+ }
+
+ COMPRESSED timerbased {
+ ENFORCE(time_stride_value != 0);
+ timestamp =:= timer_based_lsb(time_stride_value, k,
+ ((2^k) / 2) - 1);
+ }
+
+ COMPRESSED regular {
+ ENFORCE(time_stride_value == 0);
+ timestamp =:= lsb(k, ((2^k) / 4) - 1);
+ }
+}
+
+// Self-describing variable length encoding with reordering offset
+sdvl_sn_lsb(field_width)
+{
+ UNCOMPRESSED {
+ field [ field_width ];
+ }
+
+ COMPRESSED lsb7 {
+ discriminator =:= '0' [ 1 ];
+ field =:= msn_lsb(7) [ 7 ];
+ }
+
+ COMPRESSED lsb14 {
+ discriminator =:= '10' [ 2 ];
+ field =:= msn_lsb(14) [ 14 ];
+ }
+
+ COMPRESSED lsb21 {
+ discriminator =:= '110' [ 3 ];
+ field =:= msn_lsb(21) [ 21 ];
+ }
+
+ COMPRESSED lsb28 {
+ discriminator =:= '1110' [ 4 ];
+ field =:= msn_lsb(28) [ 28 ];
+ }
+
+ COMPRESSED lsb32 {
+ discriminator =:= '11111111' [ 8 ];
+ field =:= irregular(field_width) [ field_width ];
+ }
+}
+
+
+
+
+Pelletier & Sandlund Standards Track [Page 72]
+
+RFC 5225 ROHCv2 Profiles April 2008
+
+
+// Self-describing variable length encoding
+sdvl_lsb(field_width)
+{
+ 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 ];
+ }
+}
+
+sdvl_scaled_ts_lsb(time_stride)
+{
+ UNCOMPRESSED {
+ field [ 32 ];
+ }
+
+ COMPRESSED lsb7 {
+ discriminator =:= '0' [ 1 ];
+ field =:= scaled_ts_lsb(time_stride, 7) [ 7 ];
+ }
+
+ COMPRESSED lsb14 {
+ discriminator =:= '10' [ 2 ];
+ field =:= scaled_ts_lsb(time_stride, 14) [ 14 ];
+ }
+
+
+
+Pelletier & Sandlund Standards Track [Page 73]
+
+RFC 5225 ROHCv2 Profiles April 2008
+
+
+ COMPRESSED lsb21 {
+ discriminator =:= '110' [ 3 ];
+ field =:= scaled_ts_lsb(time_stride, 21) [ 21 ];
+ }
+
+ COMPRESSED lsb28 {
+ discriminator =:= '1110' [ 4 ];
+ field =:= scaled_ts_lsb(time_stride, 28) [ 28 ];
+ }
+
+ COMPRESSED lsb32 {
+ discriminator =:= '11111111' [ 8 ];
+ field =:= irregular(32) [ 32 ];
+ }
+}
+
+variable_scaled_timestamp(tss_flag, tsc_flag, ts_stride, time_stride)
+{
+ UNCOMPRESSED {
+ scaled_value [ 32 ];
+ }
+
+ COMPRESSED present {
+ ENFORCE((tss_flag == 0) && (tsc_flag == 1));
+ ENFORCE(ts_stride != 0);
+ scaled_value =:= sdvl_scaled_ts_lsb(time_stride) [ VARIABLE ];
+ }
+
+ COMPRESSED not_present {
+ ENFORCE(((tss_flag == 1) && (tsc_flag == 0)) ||
+ ((tss_flag == 0) && (tsc_flag == 0)));
+ }
+}
+
+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));
+
+
+
+Pelletier & Sandlund Standards Track [Page 74]
+
+RFC 5225 ROHCv2 Profiles April 2008
+
+
+ }
+}
+
+profile_1_7_flags1_enc(flag, ip_version)
+{
+ UNCOMPRESSED {
+ ip_outer_indicator [ 1 ];
+ ttl_hopl_indicator [ 1 ];
+ tos_tc_indicator [ 1 ];
+ df [ 0, 1 ];
+ ip_id_behavior [ 2 ];
+ reorder_ratio [ 2 ];
+ }
+
+ COMPRESSED not_present {
+ ENFORCE(flag == 0);
+ ENFORCE(ip_outer_indicator.CVALUE == 0);
+ ENFORCE(ttl_hopl_indicator.CVALUE == 0);
+ ENFORCE(tos_tc_indicator.CVALUE == 0);
+ df =:= static;
+ ip_id_behavior =:= static;
+ reorder_ratio =:= static;
+ }
+
+ COMPRESSED present {
+ ENFORCE(flag == 1);
+ ip_outer_indicator =:= irregular(1) [ 1 ];
+ ttl_hopl_indicator =:= irregular(1) [ 1 ];
+ tos_tc_indicator =:= irregular(1) [ 1 ];
+ df =:= dont_fragment(ip_version) [ 1 ];
+ ip_id_behavior =:= irregular(2) [ 2 ];
+ reorder_ratio =:= irregular(2) [ 2 ];
+ }
+}
+
+profile_1_flags2_enc(flag)
+{
+ UNCOMPRESSED {
+ list_indicator [ 1 ];
+ pt_indicator [ 1 ];
+ time_stride_indicator [ 1 ];
+ pad_bit [ 1 ];
+ extension [ 1 ];
+ }
+
+ COMPRESSED not_present{
+ ENFORCE(flag == 0);
+ ENFORCE(list_indicator.UVALUE == 0);
+
+
+
+Pelletier & Sandlund Standards Track [Page 75]
+
+RFC 5225 ROHCv2 Profiles April 2008
+
+
+ ENFORCE(pt_indicator.UVALUE == 0);
+ ENFORCE(time_stride_indicator.UVALUE == 0);
+ pad_bit =:= static;
+ extension =:= 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 ];
+ reserved =:= compressed_value(3, 0) [ 3 ];
+ }
+}
+
+profile_2_3_4_flags_enc(flag, ip_version)
+{
+ UNCOMPRESSED {
+ ip_outer_indicator [ 1 ];
+ df [ 0, 1 ];
+ ip_id_behavior [ 2 ];
+ }
+
+ COMPRESSED not_present {
+ ENFORCE(flag == 0);
+ ENFORCE(ip_outer_indicator.CVALUE == 0);
+ df =:= static;
+ ip_id_behavior =:= static;
+ }
+
+ COMPRESSED present {
+ ENFORCE(flag == 1);
+ ip_outer_indicator =:= irregular(1) [ 1 ];
+ df =:= dont_fragment(ip_version) [ 1 ];
+ ip_id_behavior =:= irregular(2) [ 2 ];
+ reserved =:= compressed_value(4, 0) [ 4 ];
+ }
+}
+
+profile_8_flags_enc(flag, ip_version)
+{
+ UNCOMPRESSED {
+ ip_outer_indicator [ 1 ];
+ df [ 0, 1 ];
+ ip_id_behavior [ 2 ];
+ coverage_behavior [ 2 ];
+
+
+
+Pelletier & Sandlund Standards Track [Page 76]
+
+RFC 5225 ROHCv2 Profiles April 2008
+
+
+ }
+
+ COMPRESSED not_present {
+ ENFORCE(flag == 0);
+ ENFORCE(ip_outer_indicator.CVALUE == 0);
+ df =:= static;
+ ip_id_behavior =:= static;
+ coverage_behavior =:= static;
+ }
+
+ COMPRESSED present {
+ ENFORCE(flag == 1);
+ reserved =:= compressed_value(2, 0) [ 2 ];
+ ip_outer_indicator =:= irregular(1) [ 1 ];
+ df =:= dont_fragment(ip_version) [ 1 ];
+ ip_id_behavior =:= irregular(2) [ 2 ];
+ coverage_behavior =:= irregular(2) [ 2 ];
+ }
+}
+
+profile_7_flags2_enc(flag)
+{
+ UNCOMPRESSED {
+ list_indicator [ 1 ];
+ pt_indicator [ 1 ];
+ time_stride_indicator [ 1 ];
+ pad_bit [ 1 ];
+ extension [ 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;
+ coverage_behavior =:= static;
+ }
+
+ COMPRESSED present {
+ ENFORCE(flag == 1);
+ reserved =:= compressed_value(1, 0) [ 1 ];
+ list_indicator =:= irregular(1) [ 1 ];
+ pt_indicator =:= irregular(1) [ 1 ];
+ time_stride_indicator =:= irregular(1) [ 1 ];
+ pad_bit =:= irregular(1) [ 1 ];
+
+
+
+Pelletier & Sandlund Standards Track [Page 77]
+
+RFC 5225 ROHCv2 Profiles April 2008
+
+
+ extension =:= irregular(1) [ 1 ];
+ coverage_behavior =:= irregular(2) [ 2 ];
+ }
+}
+
+////////////////////////////////////////////
+// RTP profile
+////////////////////////////////////////////
+
+rtp_baseheader(profile_value, ts_stride_value, time_stride_value,
+ outer_ip_flag, ip_id_behavior_value,
+ reorder_ratio_value)
+{
+ 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 ];
+ 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 {
+
+
+
+Pelletier & Sandlund Standards Track [Page 78]
+
+RFC 5225 ROHCv2 Profiles April 2008
+
+
+ ENFORCE(ip_id_behavior_innermost.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 ];
+ csrc_list [ VARIABLE ];
+ df =:= uncompressed_value(0,0) [ 0 ];
+ ip_id =:= uncompressed_value(0,0) [ 0 ];
+ }
+
+ CONTROL {
+ ENFORCE(profile_value == PROFILE_RTP_0101);
+ ENFORCE(profile == profile_value);
+ ENFORCE(time_stride.UVALUE == time_stride_value);
+ ENFORCE(ts_stride.UVALUE == ts_stride_value);
+ ENFORCE(reorder_ratio.UVALUE == reorder_ratio_value);
+ ENFORCE(ip_id_behavior_innermost.UVALUE == ip_id_behavior_value);
+ dummy_field =:= field_scaling(ts_stride.UVALUE,
+ ts_scaled.UVALUE, timestamp.UVALUE, ts_offset.UVALUE) [ 0 ];
+ }
+
+ INITIAL {
+ ts_stride =:= uncompressed_value(32, TS_STRIDE_DEFAULT);
+ time_stride =:= uncompressed_value(32, TIME_STRIDE_DEFAULT);
+ }
+
+ DEFAULT {
+ ENFORCE(outer_ip_flag == 0);
+
+
+
+Pelletier & Sandlund Standards Track [Page 79]
+
+RFC 5225 ROHCv2 Profiles April 2008
+
+
+ tos_tc =:= static;
+ dest_addr =:= static;
+ ttl_hopl =:= static;
+ src_addr =:= static;
+ df =:= static;
+ flow_label =:= static;
+ next_header =:= static;
+ src_port =:= static;
+ dst_port =:= static;
+ 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;
+ ts_stride =:= static;
+ time_stride =:= static;
+ ts_scaled =:= static;
+ ts_offset =:= static;
+ reorder_ratio =:= static;
+ ip_id_behavior_innermost =:= static;
+ }
+
+ // Replacement for UOR-2-ext3
+ COMPRESSED co_common {
+ ENFORCE(outer_ip_flag == outer_ip_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 : ttl_hopl_indicator :
+ tos_tc_indicator : df : ip_id_behavior_innermost : reorder_ratio
+ =:= profile_1_7_flags1_enc(flags1_indicator.CVALUE,
+ ip_version.UVALUE) [ 0, 8 ];
+ list_indicator : pt_indicator : tis_indicator : pad_bit :
+ extension =:= profile_1_flags2_enc(
+ flags2_indicator.CVALUE) [ 0, 8 ];
+ tos_tc =:= static_or_irreg(tos_tc_indicator.CVALUE, 8) [ 0, 8 ];
+
+
+
+Pelletier & Sandlund Standards Track [Page 80]
+
+RFC 5225 ROHCv2 Profiles April 2008
+
+
+ ttl_hopl =:= static_or_irreg(ttl_hopl_indicator.CVALUE,
+ ttl_hopl.ULENGTH) [ 0, 8 ];
+ payload_type =:= pt_irr_or_static(pt_indicator) [ 0, 8 ];
+ sequence_number =:=
+ sdvl_sn_lsb(sequence_number.ULENGTH) [ VARIABLE ];
+ ip_id =:= ip_id_sequential_variable(
+ ip_id_behavior_innermost.UVALUE,
+ ip_id_indicator.CVALUE) [ 0, 8, 16 ];
+ ts_scaled =:= variable_scaled_timestamp(tss_indicator.CVALUE,
+ tsc_indicator.CVALUE, ts_stride.UVALUE,
+ time_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 ];
+ }
+
+ // 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 =:= '1000' [ 4 ];
+ msn =:= msn_lsb(5) [ 5 ];
+ 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_innermost.UVALUE ==
+ IP_ID_BEHAVIOR_RANDOM) ||
+ (ip_id_behavior_innermost.UVALUE == IP_ID_BEHAVIOR_ZERO));
+ discriminator =:= '101' [ 3 ];
+ marker =:= irregular(1) [ 1 ];
+ msn =:= msn_lsb(4) [ 4 ];
+ ts_scaled =:= scaled_ts_lsb(time_stride.UVALUE, 5) [ 5 ];
+ header_crc =:= crc3(THIS.UVALUE, THIS.ULENGTH) [ 3 ];
+
+
+
+Pelletier & Sandlund Standards Track [Page 81]
+
+RFC 5225 ROHCv2 Profiles April 2008
+
+
+ }
+
+ // UO-1-ID replacement
+ COMPRESSED pt_1_seq_id {
+ ENFORCE((ip_id_behavior_innermost.UVALUE ==
+ IP_ID_BEHAVIOR_SEQUENTIAL) ||
+ (ip_id_behavior_innermost.UVALUE ==
+ IP_ID_BEHAVIOR_SEQUENTIAL_SWAPPED));
+ discriminator =:= '1001' [ 4 ];
+ ip_id =:= ip_id_lsb(ip_id_behavior_innermost.UVALUE, 4) [ 4 ];
+ msn =:= msn_lsb(5) [ 5 ];
+ header_crc =:= crc3(THIS.UVALUE, THIS.ULENGTH) [ 3 ];
+ timestamp =:= inferred_scaled_field [ 0 ];
+ }
+
+ // UO-1-TS replacement
+ COMPRESSED pt_1_seq_ts {
+ ENFORCE(ts_stride.UVALUE != 0);
+ ENFORCE((ip_id_behavior_innermost.UVALUE ==
+ IP_ID_BEHAVIOR_SEQUENTIAL) ||
+ (ip_id_behavior_innermost.UVALUE ==
+ IP_ID_BEHAVIOR_SEQUENTIAL_SWAPPED));
+ discriminator =:= '101' [ 3 ];
+ marker =:= irregular(1) [ 1 ];
+ msn =:= msn_lsb(4) [ 4 ];
+ ts_scaled =:= scaled_ts_lsb(time_stride.UVALUE, 5) [ 5 ];
+ header_crc =:= crc3(THIS.UVALUE, THIS.ULENGTH) [ 3 ];
+ ip_id =:= inferred_sequential_ip_id [ 0 ];
+ }
+
+ // UOR-2 replacement
+ COMPRESSED pt_2_rnd {
+ ENFORCE(ts_stride.UVALUE != 0);
+ ENFORCE((ip_id_behavior_innermost.UVALUE ==
+ IP_ID_BEHAVIOR_RANDOM) ||
+ (ip_id_behavior_innermost.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_innermost.UVALUE ==
+ IP_ID_BEHAVIOR_SEQUENTIAL) ||
+ (ip_id_behavior_innermost.UVALUE ==
+
+
+
+Pelletier & Sandlund Standards Track [Page 82]
+
+RFC 5225 ROHCv2 Profiles April 2008
+
+
+ IP_ID_BEHAVIOR_SEQUENTIAL_SWAPPED));
+ discriminator =:= '11000' [ 5 ];
+ msn =:= msn_lsb(7) [ 7 ];
+ ip_id =:= ip_id_lsb(ip_id_behavior_innermost.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_innermost.UVALUE ==
+ IP_ID_BEHAVIOR_SEQUENTIAL) ||
+ (ip_id_behavior_innermost.UVALUE ==
+ IP_ID_BEHAVIOR_SEQUENTIAL_SWAPPED));
+ discriminator =:= '11001' [ 5 ];
+ msn =:= msn_lsb(7) [ 7 ];
+ ip_id =:= ip_id_lsb(ip_id_behavior_innermost.UVALUE, 5) [ 5 ];
+ header_crc =:= crc7(THIS.UVALUE, THIS.ULENGTH) [ 7 ];
+ ts_scaled =:= scaled_ts_lsb(time_stride.UVALUE, 7) [ 7 ];
+ marker =:= irregular(1) [ 1 ];
+ }
+
+ // UOR-2-TS replacement
+ COMPRESSED pt_2_seq_ts {
+ ENFORCE(ts_stride.UVALUE != 0);
+ ENFORCE((ip_id_behavior_innermost.UVALUE ==
+ IP_ID_BEHAVIOR_SEQUENTIAL) ||
+ (ip_id_behavior_innermost.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 ];
+ ip_id =:= inferred_sequential_ip_id [ 0 ];
+ }
+}
+
+////////////////////////////////////////////
+// UDP profile
+////////////////////////////////////////////
+
+udp_baseheader(profile_value, outer_ip_flag, ip_id_behavior_value,
+ reorder_ratio_value)
+{
+ UNCOMPRESSED v4 {
+ outer_headers =:= baseheader_outer_headers [ VARIABLE ];
+
+
+
+Pelletier & Sandlund Standards Track [Page 83]
+
+RFC 5225 ROHCv2 Profiles April 2008
+
+
+ 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 ];
+ 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 ];
+ df =:= uncompressed_value(0,0) [ 0 ];
+ ip_id =:= uncompressed_value(0,0) [ 0 ];
+ }
+
+ CONTROL {
+ ENFORCE(profile_value == PROFILE_UDP_0102);
+ ENFORCE(profile == profile_value);
+ ENFORCE(reorder_ratio.UVALUE == reorder_ratio_value);
+ ENFORCE(ip_id_behavior_innermost.UVALUE == ip_id_behavior_value);
+ }
+
+
+
+
+Pelletier & Sandlund Standards Track [Page 84]
+
+RFC 5225 ROHCv2 Profiles April 2008
+
+
+ DEFAULT {
+ ENFORCE(outer_ip_flag == 0);
+ tos_tc =:= static;
+ dest_addr =:= static;
+ ip_version =:= static;
+ ttl_hopl =:= static;
+ src_addr =:= static;
+ df =:= static;
+ flow_label =:= static;
+ next_header =:= static;
+ src_port =:= static;
+ dst_port =:= static;
+ reorder_ratio =:= static;
+ ip_id_behavior_innermost =:= static;
+ }
+
+ // Replacement for UOR-2-ext3
+ COMPRESSED co_common {
+ ENFORCE(outer_ip_flag == outer_ip_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 =:= irregular(2) [ 2 ];
+ control_crc3 =:= control_crc3_encoding [ 3 ];
+ outer_ip_indicator : df : ip_id_behavior_innermost =:=
+ profile_2_3_4_flags_enc(
+ flags_indicator.CVALUE, ip_version.UVALUE) [ 0, 8 ];
+ 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 ];
+ ip_id =:= ip_id_sequential_variable(ip_id_behavior_innermost.UVALUE,
+ ip_id_indicator.CVALUE) [ 0, 8, 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 {
+
+
+
+Pelletier & Sandlund Standards Track [Page 85]
+
+RFC 5225 ROHCv2 Profiles April 2008
+
+
+ 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_innermost.UVALUE ==
+ IP_ID_BEHAVIOR_SEQUENTIAL) ||
+ (ip_id_behavior_innermost.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_innermost.UVALUE, 4) [ 4 ];
+ }
+
+ // UOR-2-ID replacement
+ COMPRESSED pt_2_seq_id {
+ ENFORCE((ip_id_behavior_innermost.UVALUE ==
+ IP_ID_BEHAVIOR_SEQUENTIAL) ||
+ (ip_id_behavior_innermost.UVALUE ==
+ IP_ID_BEHAVIOR_SEQUENTIAL_SWAPPED));
+ discriminator =:= '110' [ 3 ];
+ ip_id =:= ip_id_lsb(ip_id_behavior_innermost.UVALUE, 6) [ 6 ];
+ header_crc =:= crc7(THIS.UVALUE, THIS.ULENGTH) [ 7 ];
+ msn =:= msn_lsb(8) [ 8 ];
+ }
+}
+
+////////////////////////////////////////////
+// ESP profile
+////////////////////////////////////////////
+
+esp_baseheader(profile_value, outer_ip_flag, ip_id_behavior_value,
+ reorder_ratio_value)
+{
+ 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 ];
+
+
+
+Pelletier & Sandlund Standards Track [Page 86]
+
+RFC 5225 ROHCv2 Profiles April 2008
+
+
+ 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_innermost.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 ];
+ spi [ 32 ];
+ sequence_number [ 32 ];
+ df =:= uncompressed_value(0,0) [ 0 ];
+ ip_id =:= uncompressed_value(0,0) [ 0 ];
+ }
+
+ CONTROL {
+ ENFORCE(profile_value == PROFILE_ESP_0103);
+ ENFORCE(profile == profile_value);
+ ENFORCE(ip_id_behavior_innermost.UVALUE == ip_id_behavior_value);
+ ENFORCE(reorder_ratio.UVALUE == reorder_ratio_value);
+ }
+
+ DEFAULT {
+ ENFORCE(outer_ip_flag == 0);
+ tos_tc =:= static;
+ dest_addr =:= static;
+ ttl_hopl =:= static;
+ src_addr =:= static;
+ df =:= static;
+ flow_label =:= static;
+ next_header =:= static;
+ spi =:= static;
+
+
+
+Pelletier & Sandlund Standards Track [Page 87]
+
+RFC 5225 ROHCv2 Profiles April 2008
+
+
+ sequence_number =:= static;
+ reorder_ratio =:= static;
+ ip_id_behavior_innermost =:= static;
+ }
+
+ // Replacement for UOR-2-ext3
+ COMPRESSED co_common {
+ ENFORCE(outer_ip_flag == outer_ip_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 =:= irregular(2) [ 2 ];
+ control_crc3 =:= control_crc3_encoding [ 3 ];
+
+ outer_ip_indicator : df : ip_id_behavior_innermost =:=
+ profile_2_3_4_flags_enc(
+ flags_indicator.CVALUE, ip_version.UVALUE) [ 0, 8 ];
+ 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_sn_lsb(sequence_number.ULENGTH) [ VARIABLE ];
+ ip_id =:= ip_id_sequential_variable(ip_id_behavior_innermost.UVALUE,
+ ip_id_indicator.CVALUE) [ 0, 8, 16 ];
+ }
+
+ // Sequence number sent instead of MSN due to field length
+ // UO-0
+ COMPRESSED pt_0_crc3 {
+ discriminator =:= '0' [ 1 ];
+ sequence_number =:= 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 ];
+ sequence_number =:= 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 {
+
+
+
+Pelletier & Sandlund Standards Track [Page 88]
+
+RFC 5225 ROHCv2 Profiles April 2008
+
+
+ ENFORCE((ip_id_behavior_innermost.UVALUE ==
+ IP_ID_BEHAVIOR_SEQUENTIAL) ||
+ (ip_id_behavior_innermost.UVALUE ==
+ IP_ID_BEHAVIOR_SEQUENTIAL_SWAPPED));
+ discriminator =:= '101' [ 3 ];
+ header_crc =:= crc3(THIS.UVALUE, THIS.ULENGTH) [ 3 ];
+ sequence_number =:= msn_lsb(6) [ 6 ];
+ ip_id =:= ip_id_lsb(ip_id_behavior_innermost.UVALUE, 4) [ 4 ];
+ }
+
+ // UOR-2-ID replacement
+ COMPRESSED pt_2_seq_id {
+ ENFORCE((ip_id_behavior_innermost.UVALUE ==
+ IP_ID_BEHAVIOR_SEQUENTIAL) ||
+ (ip_id_behavior_innermost.UVALUE ==
+ IP_ID_BEHAVIOR_SEQUENTIAL_SWAPPED));
+ discriminator =:= '110' [ 3 ];
+ ip_id =:= ip_id_lsb(ip_id_behavior_innermost.UVALUE, 6) [ 6 ];
+ header_crc =:= crc7(THIS.UVALUE, THIS.ULENGTH) [ 7 ];
+ sequence_number =:= msn_lsb(8) [ 8 ];
+ }
+}
+
+////////////////////////////////////////////
+// IP-only profile
+////////////////////////////////////////////
+
+iponly_baseheader(profile_value, outer_ip_flag, ip_id_behavior_value,
+ reorder_ratio_value)
+{
+ 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 ];
+ dest_addr [ 32 ];
+ extension_headers =:= baseheader_extension_headers [ VARIABLE ];
+ }
+
+
+
+Pelletier & Sandlund Standards Track [Page 89]
+
+RFC 5225 ROHCv2 Profiles April 2008
+
+
+ UNCOMPRESSED v6 {
+ ENFORCE(ip_id_behavior_innermost.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 ];
+ df =:= uncompressed_value(0,0) [ 0 ];
+ ip_id =:= uncompressed_value(0,0) [ 0 ];
+ }
+
+ CONTROL {
+ ENFORCE(profile_value == PROFILE_IP_0104);
+ ENFORCE(profile == profile_value);
+ ENFORCE(reorder_ratio.UVALUE == reorder_ratio_value);
+ ENFORCE(ip_id_behavior_innermost.UVALUE == ip_id_behavior_value);
+ }
+
+ DEFAULT {
+ ENFORCE(outer_ip_flag == 0);
+ tos_tc =:= static;
+ dest_addr =:= static;
+ ttl_hopl =:= static;
+ src_addr =:= static;
+ df =:= static;
+ flow_label =:= static;
+ next_header =:= static;
+ reorder_ratio =:= static;
+ ip_id_behavior_innermost =:= static;
+ }
+
+ // Replacement for UOR-2-ext3
+ COMPRESSED co_common {
+ ENFORCE(outer_ip_flag == outer_ip_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 =:= irregular(2) [ 2 ];
+ control_crc3 =:= control_crc3_encoding [ 3 ];
+ outer_ip_indicator : df : ip_id_behavior_innermost =:=
+
+
+
+Pelletier & Sandlund Standards Track [Page 90]
+
+RFC 5225 ROHCv2 Profiles April 2008
+
+
+ profile_2_3_4_flags_enc(
+ flags_indicator.CVALUE, ip_version.UVALUE) [ 0, 8 ];
+ 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 ];
+ ip_id =:= ip_id_sequential_variable(ip_id_behavior_innermost.UVALUE,
+ ip_id_indicator.CVALUE) [ 0, 8, 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_innermost.UVALUE ==
+ IP_ID_BEHAVIOR_SEQUENTIAL) ||
+ (ip_id_behavior_innermost.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_innermost.UVALUE, 4) [ 4 ];
+ }
+
+ // UOR-2-ID replacement
+ COMPRESSED pt_2_seq_id {
+ ENFORCE((ip_id_behavior_innermost.UVALUE ==
+ IP_ID_BEHAVIOR_SEQUENTIAL) ||
+ (ip_id_behavior_innermost.UVALUE ==
+ IP_ID_BEHAVIOR_SEQUENTIAL_SWAPPED));
+ discriminator =:= '110' [ 3 ];
+ ip_id =:= ip_id_lsb(ip_id_behavior_innermost.UVALUE, 6) [ 6 ];
+ header_crc =:= crc7(THIS.UVALUE, THIS.ULENGTH) [ 7 ];
+ msn =:= msn_lsb(8) [ 8 ];
+
+
+
+Pelletier & Sandlund Standards Track [Page 91]
+
+RFC 5225 ROHCv2 Profiles April 2008
+
+
+ }
+}
+
+////////////////////////////////////////////
+// UDP-lite/RTP profile
+////////////////////////////////////////////
+
+udplite_rtp_baseheader(profile_value, ts_stride_value,
+ time_stride_value, outer_ip_flag,
+ ip_id_behavior_value, reorder_ratio_value,
+ coverage_behavior_value)
+{
+ 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 ];
+ 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_innermost.UVALUE == IP_ID_BEHAVIOR_RANDOM);
+
+
+
+Pelletier & Sandlund Standards Track [Page 92]
+
+RFC 5225 ROHCv2 Profiles April 2008
+
+
+ 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 ];
+ marker [ 1 ];
+ payload_type [ 7 ];
+ sequence_number [ 16 ];
+ timestamp [ 32 ];
+ ssrc [ 32 ];
+ csrc_list [ VARIABLE ];
+ df =:= uncompressed_value(0,0) [ 0 ];
+ ip_id =:= uncompressed_value(0,0) [ 0 ];
+ }
+
+ CONTROL {
+ ENFORCE(profile_value == PROFILE_RTP_0107);
+ ENFORCE(profile == profile_value);
+ ENFORCE(time_stride.UVALUE == time_stride_value);
+ ENFORCE(ts_stride.UVALUE == ts_stride_value);
+ ENFORCE(coverage_behavior.UVALUE == coverage_behavior_value);
+ ENFORCE(reorder_ratio.UVALUE == reorder_ratio_value);
+ ENFORCE(ip_id_behavior_innermost.UVALUE == ip_id_behavior_value);
+ dummy_field =:= field_scaling(ts_stride.UVALUE,
+ ts_scaled.UVALUE, timestamp.UVALUE, ts_offset.UVALUE) [ 0 ];
+ }
+
+ INITIAL {
+ ts_stride =:= uncompressed_value(32, TS_STRIDE_DEFAULT);
+ time_stride =:= uncompressed_value(32, TIME_STRIDE_DEFAULT);
+ }
+
+ DEFAULT {
+ ENFORCE(outer_ip_flag == 0);
+ tos_tc =:= static;
+
+
+
+Pelletier & Sandlund Standards Track [Page 93]
+
+RFC 5225 ROHCv2 Profiles April 2008
+
+
+ dest_addr =:= static;
+ ttl_hopl =:= static;
+ src_addr =:= static;
+ df =:= static;
+ flow_label =:= static;
+ next_header =:= static;
+ src_port =:= static;
+ dst_port =:= static;
+ 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;
+ ts_stride =:= static;
+ time_stride =:= static;
+ ts_scaled =:= static;
+ ts_offset =:= static;
+ reorder_ratio =:= static;
+ ip_id_behavior_innermost =:= static;
+ }
+
+ // Replacement for UOR-2-ext3
+ COMPRESSED co_common {
+ ENFORCE(outer_ip_flag == outer_ip_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 : ttl_hopl_indicator :
+ tos_tc_indicator : df : ip_id_behavior_innermost : reorder_ratio
+ =:= profile_1_7_flags1_enc(flags1_indicator.CVALUE,
+ ip_version.UVALUE) [ 0, 8 ];
+ list_indicator : pt_indicator : tis_indicator : pad_bit :
+ extension : coverage_behavior =:=
+ profile_7_flags2_enc(flags2_indicator.CVALUE) [ 0, 8 ];
+ tos_tc =:= static_or_irreg(tos_tc_indicator.CVALUE, 8) [ 0, 8 ];
+ ttl_hopl =:=
+
+
+
+Pelletier & Sandlund Standards Track [Page 94]
+
+RFC 5225 ROHCv2 Profiles April 2008
+
+
+ static_or_irreg(ttl_hopl_indicator.CVALUE, 8) [ 0, 8 ];
+ payload_type =:= pt_irr_or_static(pt_indicator.CVALUE) [ 0, 8 ];
+ sequence_number =:=
+ sdvl_sn_lsb(sequence_number.ULENGTH) [ VARIABLE ];
+ ip_id =:= ip_id_sequential_variable(ip_id_behavior_innermost.UVALUE,
+ ip_id_indicator.CVALUE) [ 0, 8, 16 ];
+ ts_scaled =:= variable_scaled_timestamp(tss_indicator.CVALUE,
+ tsc_indicator.CVALUE, ts_stride.UVALUE,
+ time_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 ];
+ }
+
+ // 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 =:= '1000' [ 4 ];
+ msn =:= msn_lsb(5) [ 5 ];
+ 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_innermost.UVALUE ==
+ IP_ID_BEHAVIOR_RANDOM) ||
+ (ip_id_behavior_innermost.UVALUE == IP_ID_BEHAVIOR_ZERO));
+ discriminator =:= '101' [ 3 ];
+ marker =:= irregular(1) [ 1 ];
+ msn =:= msn_lsb(4) [ 4 ];
+ ts_scaled =:= scaled_ts_lsb(time_stride.UVALUE, 5) [ 5 ];
+ header_crc =:= crc3(THIS.UVALUE, THIS.ULENGTH) [ 3 ];
+ }
+
+
+
+Pelletier & Sandlund Standards Track [Page 95]
+
+RFC 5225 ROHCv2 Profiles April 2008
+
+
+ // UO-1-ID replacement
+ COMPRESSED pt_1_seq_id {
+ ENFORCE((ip_id_behavior_innermost.UVALUE ==
+ IP_ID_BEHAVIOR_SEQUENTIAL) ||
+ (ip_id_behavior_innermost.UVALUE ==
+ IP_ID_BEHAVIOR_SEQUENTIAL_SWAPPED));
+ discriminator =:= '1001' [ 4 ];
+ ip_id =:= ip_id_lsb(ip_id_behavior_innermost.UVALUE, 4) [ 4 ];
+ msn =:= msn_lsb(5) [ 5 ];
+ header_crc =:= crc3(THIS.UVALUE, THIS.ULENGTH) [ 3 ];
+ timestamp =:= inferred_scaled_field [ 0 ];
+ }
+
+ // UO-1-TS replacement
+ COMPRESSED pt_1_seq_ts {
+ ENFORCE(ts_stride.UVALUE != 0);
+ ENFORCE((ip_id_behavior_innermost.UVALUE ==
+ IP_ID_BEHAVIOR_SEQUENTIAL) ||
+ (ip_id_behavior_innermost.UVALUE ==
+ IP_ID_BEHAVIOR_SEQUENTIAL_SWAPPED));
+ discriminator =:= '101' [ 3 ];
+ marker =:= irregular(1) [ 1 ];
+ msn =:= msn_lsb(4) [ 4 ];
+ ts_scaled =:= scaled_ts_lsb(time_stride.UVALUE, 5) [ 5 ];
+ header_crc =:= crc3(THIS.UVALUE, THIS.ULENGTH) [ 3 ];
+ ip_id =:= inferred_sequential_ip_id [ 0 ];
+ }
+
+ // UOR-2 replacement
+ COMPRESSED pt_2_rnd {
+ ENFORCE(ts_stride.UVALUE != 0);
+ ENFORCE((ip_id_behavior_innermost.UVALUE ==
+ IP_ID_BEHAVIOR_RANDOM) ||
+ (ip_id_behavior_innermost.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_innermost.UVALUE ==
+ IP_ID_BEHAVIOR_SEQUENTIAL) ||
+ (ip_id_behavior_innermost.UVALUE ==
+ IP_ID_BEHAVIOR_SEQUENTIAL_SWAPPED));
+ discriminator =:= '11000' [ 5 ];
+
+
+
+Pelletier & Sandlund Standards Track [Page 96]
+
+RFC 5225 ROHCv2 Profiles April 2008
+
+
+ msn =:= msn_lsb(7) [ 7 ];
+ ip_id =:= ip_id_lsb(ip_id_behavior_innermost.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_innermost.UVALUE ==
+ IP_ID_BEHAVIOR_SEQUENTIAL) ||
+ (ip_id_behavior_innermost.UVALUE ==
+ IP_ID_BEHAVIOR_SEQUENTIAL_SWAPPED));
+ discriminator =:= '11001' [ 5 ];
+ msn =:= msn_lsb(7) [ 7 ];
+ ip_id =:= ip_id_lsb(ip_id_behavior_innermost.UVALUE, 5) [ 5 ];
+ header_crc =:= crc7(THIS.UVALUE, THIS.ULENGTH) [ 7 ];
+ ts_scaled =:= scaled_ts_lsb(time_stride.UVALUE, 7) [ 7 ];
+ marker =:= irregular(1) [ 1 ];
+ }
+
+ // UOR-2-TS replacement
+ COMPRESSED pt_2_seq_ts {
+ ENFORCE(ts_stride.UVALUE != 0);
+ ENFORCE((ip_id_behavior_innermost.UVALUE ==
+ IP_ID_BEHAVIOR_SEQUENTIAL) ||
+ (ip_id_behavior_innermost.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 ];
+ ip_id =:= inferred_sequential_ip_id [ 0 ];
+ }
+}
+
+////////////////////////////////////////////
+// UDP-lite profile
+////////////////////////////////////////////
+
+udplite_baseheader(profile_value, outer_ip_flag, ip_id_behavior_value,
+ reorder_ratio_value, coverage_behavior_value)
+{
+ UNCOMPRESSED v4 {
+ outer_headers =:= baseheader_outer_headers [ VARIABLE ];
+ ip_version =:= uncompressed_value(4, 4) [ 4 ];
+ header_length =:= uncompressed_value(4, 5) [ 4 ];
+
+
+
+Pelletier & Sandlund Standards Track [Page 97]
+
+RFC 5225 ROHCv2 Profiles April 2008
+
+
+ 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_innermost.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 ];
+ df =:= uncompressed_value(0,0) [ 0 ];
+ ip_id =:= uncompressed_value(0,0) [ 0 ];
+ }
+
+ CONTROL {
+ ENFORCE(profile_value == PROFILE_UDPLITE_0108);
+ ENFORCE(profile == profile_value);
+ ENFORCE(coverage_behavior.UVALUE == coverage_behavior_value);
+ ENFORCE(reorder_ratio.UVALUE == reorder_ratio_value);
+ ENFORCE(ip_id_behavior_innermost.UVALUE == ip_id_behavior_value);
+ }
+
+ DEFAULT {
+
+
+
+Pelletier & Sandlund Standards Track [Page 98]
+
+RFC 5225 ROHCv2 Profiles April 2008
+
+
+ ENFORCE(outer_ip_flag == 0);
+ tos_tc =:= static;
+ dest_addr =:= static;
+ ttl_hopl =:= static;
+ src_addr =:= static;
+ df =:= static;
+ flow_label =:= static;
+ next_header =:= static;
+ src_port =:= static;
+ dst_port =:= static;
+ reorder_ratio =:= static;
+ ip_id_behavior_innermost =:= static;
+ }
+
+ // Replacement for UOR-2-ext3
+ COMPRESSED co_common {
+ ENFORCE(outer_ip_flag == outer_ip_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 =:= irregular(2) [ 2 ];
+ control_crc3 =:= control_crc3_encoding [ 3 ];
+ outer_ip_indicator : df : ip_id_behavior_innermost :
+ coverage_behavior =:=
+ profile_8_flags_enc(flags_indicator.CVALUE,
+ ip_version.UVALUE) [ 0, 8 ];
+ 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 ];
+ ip_id =:= ip_id_sequential_variable(ip_id_behavior_innermost.UVALUE,
+ ip_id_indicator.CVALUE) [ 0, 8, 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 ];
+
+
+
+Pelletier & Sandlund Standards Track [Page 99]
+
+RFC 5225 ROHCv2 Profiles April 2008
+
+
+ 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_innermost.UVALUE ==
+ IP_ID_BEHAVIOR_SEQUENTIAL) ||
+ (ip_id_behavior_innermost.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_innermost.UVALUE, 4) [ 4 ];
+ }
+
+ // UOR-2-ID replacement
+ COMPRESSED pt_2_seq_id {
+ ENFORCE((ip_id_behavior_innermost.UVALUE ==
+ IP_ID_BEHAVIOR_SEQUENTIAL) ||
+ (ip_id_behavior_innermost.UVALUE ==
+ IP_ID_BEHAVIOR_SEQUENTIAL_SWAPPED));
+ discriminator =:= '110' [ 3 ];
+ ip_id =:= ip_id_lsb(ip_id_behavior_innermost.UVALUE, 6) [ 6 ];
+ 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 [RFC4995].
+
+ The Acknowledgment Number field of the feedback formats contains the
+ least significant bits of the MSN (see Section 6.3.1) that
+ corresponds to the reference header that is being acknowledged. A
+ reference header is a header that has been successfully CRC-8
+ validated or CRC verified. If there is no reference header
+ available, the feedback MUST carry an ACKNUMBER-NOT-VALID option.
+ FEEDBACK-1
+
+
+
+
+
+
+
+Pelletier & Sandlund Standards Track [Page 100]
+
+RFC 5225 ROHCv2 Profiles April 2008
+
+
+ 0 1 2 3 4 5 6 7
+ +---+---+---+---+---+---+---+---+
+ | Acknowledgment Number |
+ +---+---+---+---+---+---+---+---+
+
+ Acknowledgment Number: The eight least significant bits of the
+ MSN.
+
+ 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| Acknowledgment Number |
+ +---+---+---+---+---+---+---+---+
+ | Acknowledgment Number |
+ +---+---+---+---+---+---+---+---+
+ | CRC |
+ +---+---+---+---+---+---+---+---+
+ / Feedback options /
+ +---+---+---+---+---+---+---+---+
+
+ Acktype:
+
+ 0 = ACK
+
+ 1 = NACK
+
+ 2 = STATIC-NACK
+
+ 3 is reserved (MUST NOT be used for parsability)
+
+ Acknowledgment Number: The least significant bits of the MSN.
+
+ CRC: 8-bit CRC computed over the entire feedback payload including
+ any CID fields but excluding the feedback type, the 'Size' field,
+ and the 'Code' octet, using the polynomial defined in Section
+ 5.3.1.1 of [RFC4995]. 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.
+
+
+
+
+
+Pelletier & Sandlund Standards Track [Page 101]
+
+RFC 5225 ROHCv2 Profiles April 2008
+
+
+ A FEEDBACK-2 of type NACK or STATIC-NACK is always implicitly an
+ acknowledgment for a successfully decompressed packet, which
+ corresponds to a packet whose LSBs match the Acknowledgment Number of
+ the feedback element, unless the ACKNUMBER-NOT-VALID option (see
+ Section 6.9.2.2) appears in the feedback element.
+
+ The FEEDBACK-2 format always carries 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 Len (octets)
+ +---+---+---+---+---+---+---+---+
+
+ Opt Type: Unsigned integer that represents the type of the
+ feedback option. Section 6.9.2.1 through Section 6.9.2.4
+ describes the ROHCv2 feedback options.
+
+ Opt Len: Unsigned integer that represents the length of the Option
+ Data field, in octets.
+
+ Option Data: Feedback type specific data. Present if the value of
+ the Opt Len field is set to a non-zero value.
+
+6.9.2.1. The REJECT Option
+
+ The REJECT option informs the compressor that the decompressor does
+ not have sufficient resources to handle the flow.
+
+ 0 1 2 3 4 5 6 7
+ +---+---+---+---+---+---+---+---+
+ | 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. The REJECT option
+
+
+
+
+Pelletier & Sandlund Standards Track [Page 102]
+
+RFC 5225 ROHCv2 Profiles April 2008
+
+
+ MUST NOT appear more than once in the FEEDBACK-2 format; otherwise,
+ the compressor MUST discard the entire feedback element.
+
+6.9.2.2. The ACKNUMBER-NOT-VALID Option
+
+ The ACKNUMBER-NOT-VALID option indicates that the Acknowledgment
+ Number field of the feedback is not valid.
+
+ 0 1 2 3 4 5 6 7
+ +---+---+---+---+---+---+---+---+
+ | Opt Type = 3 | Opt Len = 0 |
+ +---+---+---+---+---+---+---+---+
+
+ A compressor MUST NOT use the Acknowledgment Number of the feedback
+ to find the corresponding sent header when this option is present.
+ When this option is used, the Acknowledgment Number field of the
+ FEEDBACK-2 format is set to zero. Consequently, a NACK or a STATIC-
+ NACK feedback type sent with the ACKNUMBER-NOT-VALID option is
+ equivalent to a STATIC-NACK with respect to the type of context
+ repair requested by the decompressor.
+
+ The ACKNUMBER-NOT-VALID option MUST NOT appear more than once in the
+ FEEDBACK-2 format; otherwise, the compressor MUST discard the entire
+ feedback element.
+
+6.9.2.3. The CONTEXT_MEMORY 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 compressor MUST discard the entire
+ feedback element.
+
+6.9.2.4. The CLOCK_RESOLUTION Option
+
+ The CLOCK_RESOLUTION option informs the compressor of the clock
+ resolution of the decompressor. It also informs whether or not the
+ decompressor supports timer-based compression of the RTP TS timestamp
+
+
+
+Pelletier & Sandlund Standards Track [Page 103]
+
+RFC 5225 ROHCv2 Profiles April 2008
+
+
+ (see Section 6.6.9). The CLOCK_RESOLUTION option is applicable per
+ channel, i.e., it applies to any context associated with a profile
+ for which the option is relevant between a compressor and
+ decompressor pair.
+
+ 0 1 2 3 4 5 6 7
+ +---+---+---+---+---+---+---+---+
+ | Opt Type = 10 | Opt Len = 1 |
+ +---+---+---+---+---+---+---+---+
+ | Clock resolution (ms) |
+ +---+---+---+---+---+---+---+---+
+
+ Clock resolution: Unsigned integer that represents the clock
+ resolution of the decompressor expressed in milliseconds.
+
+ The smallest clock resolution that can be indicated is 1 millisecond.
+ The value zero has a special meaning: it indicates that the
+ decompressor cannot do timer-based compression of the RTP Timestamp.
+ The CLOCK_RESOLUTION option MUST NOT appear more than once in the
+ FEEDBACK-2 format; otherwise, the compressor MUST discard the entire
+ feedback element.
+
+6.9.2.5. Unknown Option Types
+
+ If an option type other than those defined in this document is
+ encountered, the compressor MUST discard the entire feedback element.
+
+7. Security Considerations
+
+ Impairments such as bit errors on the received compressed headers,
+ missing packets, and reordering between packets could cause the
+ header decompressor to reconstitute erroneous packets, i.e., packets
+ that do not match the original packet, but still have a valid IP, UDP
+ (or UDP-Lite), and RTP headers, and possibly also valid UDP (or UDP-
+ Lite) checksums.
+
+ The header compression profiles defined herein use an internal
+ checksum for verification of reconstructed headers. This reduces the
+ probability that a header decompressor delivers erroneous packets to
+ upper layers without the error being noticed. In particular, the
+ probability that consecutive erroneous packets are not detected by
+ the internal checksum is close to zero.
+
+ This small but non-zero probability remains unchanged when integrity
+ protection is applied after compression and verified before
+ decompression, in the case where an attacker could discard or reorder
+ packets between the compression endpoints.
+
+
+
+
+Pelletier & Sandlund Standards Track [Page 104]
+
+RFC 5225 ROHCv2 Profiles April 2008
+
+
+ The impairments mentioned above could be caused by a malfunctioning
+ or malicious header compressor. Such corruption may be detected with
+ end-to-end integrity mechanisms that will not be affected by the
+ compression. Moreover, the internal checksum can also be useful in
+ the case of malfunctioning compressors.
+
+ Denial-of-service attacks are possible if an intruder can introduce
+ (for example) bogus IR 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 assigned by the IANA
+ for the profiles defined in this document:
+
+ Identifier Profile
+ ---------- -------
+ 0x0101 ROHCv2 RTP
+ 0x0102 ROHCv2 UDP
+ 0x0103 ROHCv2 ESP
+ 0x0104 ROHCv2 IP
+ 0x0107 ROHCv2 RTP/UDP-Lite
+ 0x0108 ROHCv2 UDP-Lite
+
+9. Acknowledgements
+
+ The authors would like to thank Mark West, Robert Finking, Haipeng
+ Jin, and Rohit Kapoor for serving as committed document reviewers,
+ and also for constructive discussions during the development of this
+ document. Thanks to Carl Knutsson for his extensive contribution to
+ this specification, as well as to Jani Juvan and Anders Edqvist for
+ useful comments and feedback. Thanks also to Elwyn Davies for his
+ review as the General Area Review Team (Gen-ART) reviewer, and to
+ Stephen Kent for his review on behalf of the IETF security
+ directorate, during IETF last-call. Finally, thanks to the many
+ people who have contributed to previous ROHC specifications and
+ supported this effort.
+
+
+
+
+
+
+
+
+
+
+
+Pelletier & Sandlund Standards Track [Page 105]
+
+RFC 5225 ROHCv2 Profiles April 2008
+
+
+10. References
+
+10.1. Normative References
+
+ [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
+ 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.
+
+ [RFC4995] Jonsson, L-E., Pelletier, G., and K. Sandlund, "The RObust
+ Header Compression (ROHC) Framework", RFC 4995, July 2007.
+
+
+
+
+
+Pelletier & Sandlund Standards Track [Page 106]
+
+RFC 5225 ROHCv2 Profiles April 2008
+
+
+ [RFC4997] Finking, R. and G. Pelletier, "Formal Notation for RObust
+ Header Compression (ROHC-FN)", RFC 4997, July 2007.
+
+10.2. Informative References
+
+ [RFC2675] Borman, D., Deering, S., and R. Hinden, "IPv6 Jumbograms",
+ RFC 2675, August 1999.
+
+ [RFC3095] Bormann, C., Burmeister, C., Degermark, M., Fukushima, H.,
+ 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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Pelletier & Sandlund Standards Track [Page 107]
+
+RFC 5225 ROHCv2 Profiles April 2008
+
+
+Appendix A. Detailed Classification of Header Fields
+
+ Header compression is possible due 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 fields in the headers compressible by these
+ profiles are classified and analyzed. The analysis is based on
+ behavior for the types of traffic that are expected to be the most
+ frequently compressed (e.g., RTP field behavior is based on voice
+ and/or video traffic behavior).
+
+ 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 included in compressed packets.
+
+ STATIC - These fields are expected to be constant throughout the
+ lifetime of the flow; in general, it is sufficient to design a
+ compressed format so that these fields are only updated by IR
+ packets.
+
+ STATIC-DEF - These fields are expected to be constant throughout the
+ lifetime of the flow and their values can be used to define a flow.
+ They are only sent in IR packets.
+
+ STATIC-KNOWN - These fields are expected to have well-known values
+ and therefore do not need to be communicated at all.
+
+ SEMISTATIC - These fields are unchanged most of the time. However,
+ occasionally the value changes but will revert to its original value.
+ For ROHCv2, the values of such fields do not need to be possible to
+ change with the smallest compressed packet formats, but should be
+ possible to change via slightly larger compressed packets.
+
+ RARELY CHANGING (RACH) - These are fields that change their values
+ occasionally and then keep their new values. For ROHCv2, the values
+ of such fields do not need to be possible to change with the smallest
+ compressed packet formats, but should be possible to change via
+ slightly larger compressed packets.
+
+ IRREGULAR - These are the fields for which no useful change pattern
+ can be identified and should be transmitted uncompressed in all
+ compressed packets.
+
+
+
+Pelletier & Sandlund Standards Track [Page 108]
+
+RFC 5225 ROHCv2 Profiles April 2008
+
+
+ PATTERN - These are fields that change between each packet, but
+ change in a predictable pattern.
+
+A.1. IPv4 Header Fields
+
+ +------------------------+----------------+
+ | Field | Class |
+ +------------------------+----------------+
+ | Version | STATIC-KNOWN |
+ | Header Length | STATIC-KNOWN |
+ | Type Of Service | RACH |
+ | Packet Length | INFERRED |
+ | Identification | |
+ | Sequential | PATTERN |
+ | Seq. swap | PATTERN |
+ | Random | IRREGULAR |
+ | Zero | STATIC |
+ | Reserved flag | STATIC-KNOWN |
+ | Don't Fragment flag | RACH |
+ | More Fragments flag | STATIC-KNOWN |
+ | Fragment Offset | STATIC-KNOWN |
+ | Time To Live | RACH |
+ | Protocol | STATIC-DEF |
+ | Header Checksum | INFERRED |
+ | Source Address | STATIC-DEF |
+ | Destination Address | STATIC-DEF |
+ +------------------------+----------------+
+
+ Version
+
+ The version field states which IP version is used and is set to
+ the value four.
+
+ Header Length
+
+ As long as no options are present in the IP header, the header
+ length is constant with the value five. If there are options, the
+ field could be RACH or STATIC-DEF, but only option-less headers
+ are compressed by ROHCv2 profiles. The field is therefore
+ classified as STATIC-KNOWN.
+
+ Type Of Service
+
+ For the type of flows compressed by the ROHCv2 profiles, the DSCP
+ (Differentiated Services Code Point) and ECN (Explicit Congestion
+ Notification) fields are expected to change relatively seldom.
+
+
+
+
+
+Pelletier & Sandlund Standards Track [Page 109]
+
+RFC 5225 ROHCv2 Profiles April 2008
+
+
+ Packet Length
+
+ Information about packet length is expected to be provided by the
+ link layer. The field is therefore classified as INFERRED.
+
+ IPv4 Identification
+
+ The Identification field (IP-ID) is used to identify what
+ 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 behavior, 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 Standards Track [Page 110]
+
+RFC 5225 ROHCv2 Profiles April 2008
+
+
+ Flags
+
+ The Reserved flag must be set to zero and is therefore classified
+ as STATIC-KNOWN. The Don't Fragment (DF) flag changes rarely and
+ is therefore classified as RACH. Finally, the More Fragments (MF)
+ flag is expected to be zero because IP fragments will not be
+ compressed by ROHC and is therefore classified as STATIC-KNOWN.
+
+ Fragment Offset
+
+ Under the assumption that no fragmentation occurs, the fragment
+ offset is always zero and is therefore classified as STATIC-KNOWN.
+
+ Time To Live
+
+ The Time To Live field is expected to be constant during the
+ lifetime of a flow or to alternate between a limited number of
+ values due to route changes.
+
+ Protocol
+
+ This field will have the same value in all packets of a flow 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
+
+ These fields are part of the definition of a flow and must thus be
+ constant for all packets in the flow.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Pelletier & Sandlund Standards Track [Page 111]
+
+RFC 5225 ROHCv2 Profiles April 2008
+
+
+A.2. IPv6 Header Fields
+
+ +----------------------+----------------+
+ | Field | Class |
+ +----------------------+----------------+
+ | Version | STATIC-KNOWN |
+ | Traffic Class | RACH |
+ | Flow Label | STATIC-DEF |
+ | Payload Length | INFERRED |
+ | Next Header | STATIC-DEF |
+ | Hop Limit | RACH |
+ | Source Address | STATIC-DEF |
+ | Destination Address | STATIC-DEF |
+ +----------------------+----------------+
+
+ Version
+
+ The version field states which IP version is used and is set to
+ the value six.
+
+ Traffic Class
+
+ For the type of flows compressed by the ROHCv2 profiles, the DSCP
+ and ECN fields are expected to change relatively seldom.
+
+ Flow Label
+
+ This field may be used to identify packets belonging to a specific
+ flow. If it is not used, the value should be set to zero.
+ Otherwise, all packets belonging to the same flow 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 flow and
+ is therefore classified as STATIC-DEF.
+
+
+
+
+
+
+
+
+Pelletier & Sandlund Standards Track [Page 112]
+
+RFC 5225 ROHCv2 Profiles April 2008
+
+
+ Hop Limit
+
+ The Hop Limit field is expected to be constant during the lifetime
+ of a flow or to alternate between a limited number of values due
+ to route changes.
+
+ Source and Destination addresses
+
+ These fields are part of the definition of a flow and must thus be
+ constant for all packets in the flow. The fields are therefore
+ classified as STATIC-DEF.
+
+A.3. UDP Header Fields
+
+ +------------------+-------------+
+ | Field | Class |
+ +------------------+-------------+
+ | Source Port | STATIC-DEF |
+ | Destination Port | STATIC-DEF |
+ | Length | INFERRED |
+ | Checksum | |
+ | Disabled | STATIC |
+ | Enabled | IRREGULAR |
+ +------------------+-------------+
+
+ Source and Destination ports
+
+ These fields are part of the definition of a flow and must thus be
+ constant for all packets in the flow.
+
+ Length
+
+ Information about packet length is expected to be provided by the
+ link layer. The field is therefore classified as INFERRED.
+
+ Checksum
+
+ The checksum can be optional. If disabled, its value is
+ constantly zero and can be compressed away. If enabled, its value
+ depends on the payload, which for compression purposes is
+ equivalent to it changing randomly with every packet.
+
+
+
+
+
+
+
+
+
+
+Pelletier & Sandlund Standards Track [Page 113]
+
+RFC 5225 ROHCv2 Profiles April 2008
+
+
+A.4. UDP-Lite Header Fields
+
+ +--------------------+-------------+
+ | Field | Class |
+ +--------------------+-------------+
+ | Source Port | STATIC-DEF |
+ | Destination Port | STATIC-DEF |
+ | Checksum Coverage | |
+ | Zero | STATIC-DEF |
+ | Constant | INFERRED |
+ | Variable | IRREGULAR |
+ | Checksum | IRREGULAR |
+ +--------------------+-------------+
+
+ Source and Destination Port
+
+ These fields are part of the definition of a flow and must thus be
+ constant for all packets in the flow.
+
+ 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 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.
+
+ 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.
+
+
+
+
+
+
+
+
+
+
+
+
+Pelletier & Sandlund Standards Track [Page 114]
+
+RFC 5225 ROHCv2 Profiles April 2008
+
+
+A.5. RTP Header Fields
+
+ +----------------+----------------+
+ | Field | Class |
+ +----------------+----------------+
+ | Version | STATIC-KNOWN |
+ | Padding | RACH |
+ | Extension | RACH |
+ | CSRC Counter | RACH |
+ | Marker | SEMISTATIC |
+ | Payload Type | RACH |
+ | Sequence Number| PATTERN |
+ | Timestamp | PATTERN |
+ | SSRC | STATIC-DEF |
+ | CSRC | RACH |
+ +----------------+----------------+
+
+ Version
+
+ This field is expected to have the value two and the field is
+ therefore classified as STATIC-KNOWN.
+
+ Padding
+
+ 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 RACH to allow for the case
+ where the value of this field changes.
+
+ Extension
+
+ If RTP extensions are used by the application, these extensions
+ are often present in all packets, although the use of extensions
+ is infrequent. To allow efficient compression of a flow using
+ extensions in only a few packets, this field is classified as
+ RACH.
+
+ CSRC Count
+
+ This field indicates the number of CSRC items present in the CSRC
+ list. This number is expected to be mostly constant on a packet-
+ to-packet basis and when it changes, change by small amounts. As
+ long as no RTP mixer is used, the value of this field will be
+ zero.
+
+
+
+
+
+
+
+Pelletier & Sandlund Standards Track [Page 115]
+
+RFC 5225 ROHCv2 Profiles April 2008
+
+
+ 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.
+
+ Payload Type
+
+ Applications could adapt to congestion by changing payload type
+ and/or frame sizes, but that is not expected to happen frequently,
+ so this field is classified as RACH.
+
+ RTP Sequence Number
+
+ The RTP Sequence Number will be incremented by one for each packet
+ sent.
+
+ 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 value, which
+ corresponds 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:
+
+ 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 change in timestamp value, expressed as a
+ multiple of the picture clock frequency, is in most cases
+ within a limited range.
+
+ SSRC
+
+ This field is part of the definition of a flow and must thus be
+ constant for all packets in the flow. The field is therefore
+ classified as STATIC-DEF.
+
+
+
+
+
+Pelletier & Sandlund Standards Track [Page 116]
+
+RFC 5225 ROHCv2 Profiles April 2008
+
+
+ Contributing Sources (CSRC)
+
+ The participants in a session, who are identified by the CSRC
+ fields, are usually expected to be unchanged on a packet-to-packet
+ basis, but will infrequently change by a few additions and/or
+ removals.
+
+A.6. ESP Header Fields
+
+ +------------------+-------------+
+ | Field | Class |
+ +------------------+-------------+
+ | SPI | STATIC-DEF |
+ | Sequence Number | PATTERN |
+ +------------------+-------------+
+
+ SPI
+
+ This field is used to identify a distinct flow between two IPsec
+ peers and it changes rarely; therefore, it is classified as
+ STATIC-DEF.
+
+ ESP Sequence Number
+
+ The ESP Sequence Number will be incremented by one for each packet
+ sent.
+
+A.7. IPv6 Extension Header Fields
+
+ +-----------------------+---------------+
+ | Field | Class |
+ +-----------------------+---------------+
+ | Next Header | STATIC-DEF |
+ | Ext Hdr Len | |
+ | Routing | STATIC-DEF |
+ | Hop-by-hop | STATIC |
+ | Destination | STATIC |
+ | Options | |
+ | Routing | STATIC-DEF |
+ | Hop-by-hop | RACH |
+ | Destination | RACH |
+ +-----------------------+---------------+
+
+ Next Header
+
+ This field will have the same value in all packets of a flow and
+ is therefore classified as STATIC-DEF.
+
+
+
+
+Pelletier & Sandlund Standards Track [Page 117]
+
+RFC 5225 ROHCv2 Profiles April 2008
+
+
+ Ext Hdr Len
+
+ For the Routing header, it is expected that the length will remain
+ constant for the duration of the flow, and that a change in the
+ length should be classified as a new flow by the ROHC compressor.
+ For Hop-by-hop and Destination options headers, the length is
+ expected to remain static, but can be updated by an IR packet.
+
+ Options
+
+ For the Routing header, it is expected that the option content
+ will remain constant for the duration of the flow, and that a
+ change in the routing information should be classified as a new
+ flow by the ROHC compressor. For Hop-by-hop and Destination
+ options headers, the options are expected to remain static, but
+ can be updated by an IR packet.
+
+A.8. GRE Header Fields
+
+ +--------------------+---------------+
+ | Field | Class |
+ +--------------------+---------------+
+ | C flag | STATIC |
+ | K flag | STATIC |
+ | S flag | STATIC |
+ | R flag | STATIC-KNOWN |
+ | Reserved0, Version | STATIC-KNOWN |
+ | Protocol | STATIC-DEF |
+ | Checksum | IRREGULAR |
+ | Reserved | STATIC-KNOWN |
+ | Sequence Number | PATTERN |
+ | Key | STATIC-DEF |
+ +--------------------+---------------+
+
+ Flags
+
+ The four flag bits are not expected to change for the duration of
+ the flow, and the R flag is expected to always be set to zero.
+
+ Reserved0, Version
+
+ Both of these fields are expected to be set to zero for the
+ duration of any flow.
+
+ Protocol
+
+ This field will have the same value in all packets of a flow and
+ is therefore classified as STATIC-DEF.
+
+
+
+Pelletier & Sandlund Standards Track [Page 118]
+
+RFC 5225 ROHCv2 Profiles April 2008
+
+
+ Checksum
+
+ When the checksum field is present, it is expected to behave
+ unpredictably.
+
+ Reserved
+
+ When present, this field is expected to be set to zero.
+
+ Sequence Number
+
+ When present, the Sequence Number increases by one for each
+ packet.
+
+ Key
+
+ When present, the Key field is used to define the flow and does
+ not change.
+
+A.9. MINE Header Fields
+
+ +---------------------+----------------+
+ | Field | Class |
+ +---------------------+----------------+
+ | Protocol | STATIC-DEF |
+ | S bit | STATIC-DEF |
+ | Reserved | STATIC-KNOWN |
+ | Checksum | INFERRED |
+ | Source Address | STATIC-DEF |
+ | Destination Address | STATIC-DEF |
+ +---------------------+----------------+
+
+ Protocol
+
+ This field will have the same value in all packets of a flow and
+ is therefore classified as STATIC-DEF.
+
+ S bit
+
+ The S bit is not expected to change during a flow.
+
+ Reserved
+
+ The reserved field is expected to be set to zero.
+
+
+
+
+
+
+
+Pelletier & Sandlund Standards Track [Page 119]
+
+RFC 5225 ROHCv2 Profiles April 2008
+
+
+ Checksum
+
+ The header checksum protects individual routing hops from
+ processing a corrupted header. Since all fields of this header
+ are compressed away, there is no need to include this checksum in
+ compressed packets and it can be regenerated at the decompressor
+ side.
+
+ Source and Destination Addresses
+
+ These fields can be used to define the flow and are not expected
+ to change.
+
+A.10. AH Header Fields
+
+ +---------------------+----------------+
+ | Field | Class |
+ +---------------------+----------------+
+ | Next Header | STATIC-DEF |
+ | Payload Length | STATIC |
+ | Reserved | STATIC-KNOWN |
+ | SPI | STATIC-DEF |
+ | Sequence Number | PATTERN |
+ | ICV | IRREGULAR |
+ +---------------------+----------------+
+
+ Next Header
+
+ This field will have the same value in all packets of a flow and
+ is therefore classified as STATIC-DEF.
+
+ Payload Length
+
+ It is expected that the length of the header is constant for the
+ duration of the flow.
+
+ Reserved
+
+ The value of this field will be set to zero.
+
+ 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.
+
+
+
+
+
+
+Pelletier & Sandlund Standards Track [Page 120]
+
+RFC 5225 ROHCv2 Profiles April 2008
+
+
+ Sequence Number
+
+ The Sequence Number will be incremented by one for each packet
+ sent.
+
+ ICV
+
+ The ICV is expected to behave unpredictably and is therefore
+ classified as IRREGULAR.
+
+Appendix B. Compressor Implementation Guidelines
+
+ This section describes some guiding principles for implementing a
+ ROHCv2 compressor with focus on how to efficiently select appropriate
+ packet formats. The text in this appendix should be considered
+ guidelines; it does not define any normative requirement on how
+ ROHCv2 profiles are implemented.
+
+B.1. Reference Management
+
+ The compressor usually maintains a sliding window of reference
+ headers, which contains as many references as needed for the
+ optimistic approach. Each reference contains a description of which
+ changes occurred in the flow between two consecutive headers in the
+ flow, and a new reference is inserted into the window each time a
+ packet is compressed by this context. A reference may for example be
+ implemented as a stored copy of the uncompressed header being
+ represented. When the compressor is confident that a specific
+ reference is no longer used by the decompressor (for example by using
+ the optimistic approach or feedback received), the reference is
+ removed from the sliding window.
+
+B.2. Window-based LSB Encoding (W-LSB)
+
+ Section 5.1.1 describes how the optimistic approach impacts the
+ packet format selection for the compressor. Exactly how the
+ compressor selects a packet format is up to the implementation to
+ decide, but the following is an example of how this process can be
+ performed for lsb-encoded fields through the use of Window-based LSB
+ encoding (W-LSB).
+
+ With W-LSB encoding, the compressor uses a number of references (a
+ window) from its context. What references to use is determined by
+ its optimistic approach. The compressor extracts the value of the
+ field to be W-LSB encoded from each reference in the window, and
+ finds the maximum and minimum values. Once it determines these
+ values, the compressor uses the assumption that the decompressor has
+ a value for this field within the range given by these boundaries
+
+
+
+Pelletier & Sandlund Standards Track [Page 121]
+
+RFC 5225 ROHCv2 Profiles April 2008
+
+
+ (inclusively) as its reference. The compressor can then select a
+ number of LSBs from the value to be compressed, so that the LSBs can
+ be decompressed regardless of whether the decompressor uses the
+ minimum value, the maximum value or any other value in the range of
+ possible references.
+
+B.3. W-LSB Encoding and Timer-based Compression
+
+ Section 6.6.9 defines decompressor behavior for timer-based RTP
+ timestamp compression. This section gives guidelines on how the
+ compressor should determine the number of LSB bits it should send for
+ the timestamp field. When using timer-based compression, this number
+ depends on the sum of the jitter before the compressor and the jitter
+ between the compressor and decompressor.
+
+ The jitter before the compressor can be estimated using the following
+ computation:
+
+ Max_Jitter_BC =
+ max {|(T_n - T_j) - ((a_n - a_j) / time_stride)|,
+ for all headers j in the sliding window}
+
+ where (T_n - T_j) is the difference in the timestamp between the
+ currently compressed header and a reference header and (a_n - a_j) is
+ the difference in arrival time between those same two headers.
+
+ In addition to this, the compressor needs to estimate an upper bound
+ for the jitter between the compressor and decompressor
+ (Max_Jitter_CD). This information may for example come from lower
+ layers.
+
+ A compressor implementation can determine whether the difference in
+ clock resolution between the compressor and decompressor induces an
+ error when performing integer arithmetics; it can then treat this
+ error as additional jitter.
+
+ After obtaining estimates for the jitters, the number of bits needed
+ to transmit is obtained using the following calculation:
+
+ ceiling(log2(2 * (Max_Jitter_BC + Max_Jitter_CD + 2) + 1))
+
+ This number is then used to select a packet format that contains at
+ least this many scaled timestamp bits.
+
+
+
+
+
+
+
+
+Pelletier & Sandlund Standards Track [Page 122]
+
+RFC 5225 ROHCv2 Profiles April 2008
+
+
+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 Standards Track [Page 123]
+
+RFC 5225 ROHCv2 Profiles April 2008
+
+
+Full Copyright Statement
+
+ Copyright (C) The IETF Trust (2008).
+
+ 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.
+
+
+
+
+
+
+
+
+
+
+
+
+Pelletier & Sandlund Standards Track [Page 124]
+