RFC 5795
The RObust Header Compression (ROHC) Framework
RFC 5795: The RObust Header Compression (ROHC) Framework 💖
Title: The RObust Header Compression (ROHC) Framework Number: RFC 5795 🎀 Authors: K. Sandlund, G. Pelletier, and L-E. Jonsson, all from Ericsson 👑 Category: Standards Track ✨ Date: March 2010 🌸 ISSN: 2070-1721 Obsoletes: RFC 4995 🦋 Updates: no Updates field listed in the header
Abstract 🌈
okay so ROHC (Robust Header Compression) is giving efficient, flexible, and future-proof header compression vibes 🫶 It's built to work well and stay robust over lots of different link technologies, each with its own quirks.
The ROHC framework and a set of compression profiles were first defined in RFC 3095. To make the ROHC specs cleaner and simpler, this document defines the framework and the uncompressed profile separately 🧚 Defining the framework here doesn't modify or update the framework from RFC 3095 at all.
This spec obsoletes RFC 4995. It fixes one interoperability issue that got accidentally introduced in RFC 4995, plus a few minor clarifications 💅
Status of This Memo 🍓
This is an Internet Standards Track document.
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It went through public review and got approved for publication by the Internet Engineering Steering Group (IESG). More info on Internet Standards is in Section 2 of RFC 5741.
For the current status, any errata, and how to send feedback on this document, check http://www.rfc-editor.org/info/rfc5795 🔍
Copyright Notice 💜
Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) as they stand on the publication date of this document. Please read these carefully, because they describe your rights and restrictions for this document. Code Components pulled out of this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions, and they come without warranty, as described in the Simplified BSD License.
This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The people who control the copyright in some of that material may not have granted the IETF Trust the right to allow modifications outside the IETF Standards Process. Unless you get an adequate license from those copyright holders, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process. The exceptions are formatting it for publication as an RFC or translating it into languages other than English 🙈
Table of Contents 📖
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.1. Acronyms . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.2. ROHC Terminology . . . . . . . . . . . . . . . . . . . . . 5
3. Background (Informative) . . . . . . . . . . . . . . . . . . . 8
3.1. Header Compression Fundamentals . . . . . . . . . . . . . 8
3.2. A Short History of Header Compression . . . . . . . . . . 9
4. Overview of ROHC (Informative) . . . . . . . . . . . . . . . . 10
4.1. General Principles . . . . . . . . . . . . . . . . . . . . 10
4.2. Compression Efficiency, Robustness, and Transparency . . . 11
4.3. Developing the ROHC Protocol . . . . . . . . . . . . . . . 12
4.4. Operational Characteristics of the ROHC Channel . . . . . 13
4.5. Compression and Master Sequence Number (MSN) . . . . . . . 14
4.6. Static and Dynamic Parts of a Context . . . . . . . . . . 15
5. The ROHC Framework (Normative) . . . . . . . . . . . . . . . . 15
5.1. The ROHC Channel . . . . . . . . . . . . . . . . . . . . . 15
5.1.1. Contexts and Context Identifiers . . . . . . . . . . . 15
5.1.2. Per-Channel Parameters . . . . . . . . . . . . . . . . 16
5.1.3. Persistence of Decompressor Contexts . . . . . . . . . 17
5.2. ROHC Packets and Packet Types . . . . . . . . . . . . . . 17
5.2.1. General Format of ROHC Packets . . . . . . . . . . . . 18
5.2.1.1. Format of the Padding Octet . . . . . . . . . . . 19
5.2.1.2. Format of the Add-CID Octet . . . . . . . . . . . 19
5.2.1.3. General Format of Header . . . . . . . . . . . . . 19
5.2.2. Initialization and Refresh (IR) Packet Types . . . . . 20
5.2.2.1. ROHC IR Header Format . . . . . . . . . . . . . . 20
5.2.2.2. ROHC IR-DYN Header Format . . . . . . . . . . . . 21
5.2.3. ROHC Initial Decompressor Processing . . . . . . . . . 22
5.2.4. ROHC Feedback . . . . . . . . . . . . . . . . . . . . 23
5.2.4.1. ROHC Feedback Format . . . . . . . . . . . . . . . 24
5.2.5. ROHC Segmentation . . . . . . . . . . . . . . . . . . 26
5.2.5.1. Segmentation Usage Considerations . . . . . . . . 26
5.2.5.2. Segmentation Protocol . . . . . . . . . . . . . . 26
5.3. General Encoding Methods . . . . . . . . . . . . . . . . . 28
5.3.1. Header Compression CRCs, Coverage, and Polynomials . . 28
5.3.1.1. 8-bit CRC in IR and IR-DYN Headers . . . . . . . . 28
5.3.1.2. 3-bit CRC in Compressed Headers . . . . . . . . . 28
5.3.1.3. 7-bit CRC in Compressed Headers . . . . . . . . . 29
5.3.1.4. 32-bit Segmentation CRC . . . . . . . . . . . . . 29
5.3.2. Self-Describing Variable-Length Values . . . . . . . . 30
5.4. ROHC UNCOMPRESSED -- No Compression (Profile 0x0000) . . 30
5.4.1. IR Packet . . . . . . . . . . . . . . . . . . . . . . 31
5.4.2. Normal Packet . . . . . . . . . . . . . . . . . . . . 32
5.4.3. Context Initialization . . . . . . . . . . . . . . . . 32
5.4.4. Decompressor Operation . . . . . . . . . . . . . . . . 33
5.4.5. Feedback . . . . . . . . . . . . . . . . . . . . . . . 33
6. Overview of a ROHC Profile (Informative) . . . . . . . . . . . 33
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 35
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 35
9. Security Considerations . . . . . . . . . . . . . . . . . . . 36
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 37
10.1. Normative References . . . . . . . . . . . . . . . . . . . 37
10.2. Informative References . . . . . . . . . . . . . . . . . . 37
Appendix A. CRC Algorithm . . . . . . . . . . . . . . . . . . . . 391. Introduction ✨
For lots of network types, cutting deployment and operating costs means using bandwidth better 💸 Header compression works over a link because some of the info in a packet's header is compressible between packets from the same flow.
When the IP header overhead is a problem, the total header size can get big 😭 Apps sending data over RTP [RFC3550] end up with a link-layer framing plus an IPv4 [RFC0791] header (20 octets), a UDP [RFC0768] header (8 octets), and an RTP header (12 octets), for a total of 40 octets. With IPv6 [RFC2460], the IPv6 header is 40 octets, so the total is 60 octets. Apps that send data over TCP [RFC0793] have 20 octets for the transport header, which makes a total of 40 octets for IPv4 and 60 octets for IPv6.
How much you gain for a given flow (or app) depends on how big the payload is in each packet. For stuff like Voice over IP, where the coded speech payload can be as small as 15-20 octets, the gain is huge 🔥 TCP flows with big payloads (like file transfers) gain less than flows with small payloads (like app signaling, e.g., session initiation).
More and more wireless link technologies are being used to carry IP traffic, so the header compression algorithms have to deal with what makes those technologies special 🦋 Older schemes, like those defined in [RFC2507] and [RFC2508], have been shown to do badly on links where both loss and round-trip times are not negligible. Wireless links and IP tunnels are examples of that.
A header compression scheme also has to handle residual errors, which can be a real pain. That's when the lower layer may pass along a packet with undetected bit errors to the decompressor. It should handle loss and reordering before the compression point, and on the link between the compression and decompression points too [RFC4224].
The Robust Header Compression (ROHC) protocol provides an efficient, flexible, and future-proof header compression concept. It is designed to operate efficiently and robustly over various link technologies with different characteristics 🧚
RFC 3095 [RFC3095] defines the ROHC framework along with an initial set of compression profiles. To make the specification better and simpler, the framework and the profile parts were split into separate documents. This document explicitly defines the ROHC framework, but it does not modify or update the framework from RFC 3095. Both documents can be used independently of each other. That also means implementations based on either definition will be compatible and interoperable with each other. The plan, however, is for this specification to replace RFC 3095 as the base spec for all profiles defined in the future 👑
This document fixes one interoperability issue that was accidentally introduced in RFC 4995. The fix is in Section 5.2.4.1, and it clarifies how to interpret the Size field in ROHC feedback 💖
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 [RFC2119].
2.1. Acronyms 💅
This section lists most of the acronyms used for reference 🌸
ACK Acknowledgment.
CID Context Identifier.
CO Compressed Packet Format.
CRC Cyclic Redundancy Check.
IR Initialization and Refresh.
IR-DYN Initialization and Refresh, Dynamic part.
LSB Least Significant Bit.
MRRU Maximum Reconstructed Reception Unit.
MSB Most Significant Bit.
MSN Master Sequence Number.
NACK Negative Acknowledgment.
ROHC RObust Header Compression.2.2. ROHC Terminology ✨
okay so before we get into the good stuff, we need the vocab, bestie 🎀 these terms show up everywhere in the rest of the doc, so let's make sure we're on the same page 🧚
Context
the compressor's context is the state it uses to compress a header 💅 the decompressor's context is the state it uses to decompress a header. either one, or both together, usually gets called "context" as long as it's obvious which one is meant 🫶 the context holds useful info from earlier headers in the packet flow, like static fields and possible reference values for compression and decompression. it also holds extra info about how the packet flow behaves, like how the IP Identifier changes, or how sequence numbers and timestamps typically go up between packets 📈 it's giving memory, main character energy ✨
Context damage
when the decompressor's context doesn't match the compressor's context, decompression might fail to rebuild the original header 💀 this can happen if the decompressor's context was never initialized properly, or if packets got lost or damaged between the compressor and the decompressor 😭
packets that can't be decompressed because the contexts don't match are said to be lost due to context damage 🙈 packets that do get decompressed but come out with errors because of mismatched contexts are said to be damaged due to context damage 💔
Context repair mechanisms
these are the mechanisms that resync the contexts, which is a big deal, because context damage causes loss propagation 🔥 examples include NACK-based mechanisms, and periodic refreshes of important context info (usually done in unidirectional operation) 🌸 there are also mechanisms that lower the chance of context inconsistency, like repeating the same type of info in multiple packets, and CRCs that protect the context-updating info 🛡️
CRC-8 validation
checking the integrity of a received IR or IR-DYN header against bit error(s), using the 8-bit CRC included in that IR/IR-DYN header 🎀
CRC verification
checking the result of a decompression attempt, using the 3-bit CRC or 7-bit CRC that's included in the header of a compressed packet format 🦋
Damage propagation
incorrect decompressed headers getting delivered because of context damage, like errors in (i.e., loss of or damage to) previous header(s) or feedback 😩
Error detection
detecting errors at lower layers 🔍 if that error detection isn't perfect, residual errors will be left over 👀
Error propagation
damage propagation or loss propagation, take your pick 💅
ROHC profile
a compression protocol that specifies how to compress specific header combinations 👑 a ROHC profile can be tailored to a specific set of link characteristics, e.g., loss characteristics, reordering between compression points, etc. 🌈 ROHC profiles provide the details of the header compression framework defined in this document, and each compression profile is tied to a unique ROHC profile identifier [ROHC-ids] 🫶 when a ROHC channel is set up, both endpoints negotiate which profiles they both support, and when new contexts get initialized, a profile identifier from that negotiated set is used to link each context to one specific profile 🔗
Link
a physical transmission path that makes up a single IP hop 🛤️
Loss propagation
loss of headers, due to errors in (i.e., loss of or damage to) previous header(s) or feedback 😵💫
Packet flow
a sequence of packets where the field values, and the change patterns of those values, are such that the headers can be compressed using the same context ✨
Residual error
an error that got introduced during transmission and wasn't caught by lower-layer error detection schemes 🙃
ROHC channel
a logical unidirectional point-to-point channel that carries ROHC packets from one compressor to one decompressor 🦋 it can optionally carry ROHC feedback info on behalf of another compressor-decompressor pair running on a separate ROHC channel in the opposite direction 🔄 see also [RFC3759] 📚
This document also makes use of the conceptual terminology defined by "ROHC Terminology and Channel Mapping Examples", RFC 3759 [RFC3759]. 📖
3. Background (Informative) 🌷
this section gives you the background on header compression 🧠 it covers the fundamental ideas, plus the history of how header compression schemes evolved 📜 we'll look at what motivated each scheme's development and what drawbacks they had, which sets up the foundations for the ROHC framework and profiles [RFC3095] 💜
3.1. Header Compression Fundamentals 💖
header compression works because there's a ton of redundancy between header field values in packets, especially between consecutive packets in the same flow 🥰 end-to-end, the full header info is needed for every packet in the flow, but over a single link, some of that info is redundant and can be reduced, as long as it gets transparently recovered at the receiving end of the link 🔁 the header can shrink by sending first the field info that's expected to stay static for (at least most of) the lifetime of the packet flow 🧊 fields that carry more dynamically changing info get squeezed even further using compression methods tailored to their assumed change behavior 🎯
to compress and decompress, some necessary info from past packets gets stored in a context 🗂️ the compressor and the decompressor each update their own context on certain events, which don't have to happen at the same time 🕰️ impairment events can cause inconsistencies in the decompressor's context (i.e., context damage), and that can lead to incorrect decompression 😬 so a Robust Header Compression scheme needs mechanisms that minimize the chance of context damage, plus mechanisms for context repair 🛠️
3.2. A Short History of Header Compression 📜
the first header compression scheme, compressed TCP (CTCP) [RFC1144], was introduced by Van Jacobson 👴✨ CTCP, also often called VJ compression, squashes the 40 octets of the TCP/IP header down to 4 octets 🤏 it uses delta encoding for fields that change sequentially 🔢 when transport-level retransmissions happen, the CTCP compressor spots them and sends a header that updates the entire context 🔄 this repair mechanism doesn't need any explicit signaling between the compressor and decompressor 🤫
a more general IP header compression scheme, IP header compression [RFC2507], improved on CTCP somewhat 📈 IP header compression (IPHC) can compress arbitrary IP, TCP, and UDP headers 🎁 when compressing non-TCP headers, IPHC doesn't use delta encoding, and it's robust 💪 IPHC added negative acknowledgments to CTCP's repair mechanism, called CONTEXT_STATE messages, which speed up the repair 🏃♀️ but this context repair mechanism is still limited by the round-trip time of the link ⏳ IPHC doesn't compress RTP headers 🙅♀️
CRTP [RFC2508] is an RTP extension to IPHC 🎀 CRTP compresses the 40 octets of IPv4/UDP/RTP headers down to a minimum of 2 octets when the UDP Checksum isn't enabled 🤌 if the UDP Checksum is enabled, the minimum CRTP header is 4 octets 🧮
on lossy links with long round-trip times, CRTP doesn't perform well [CRTP-eval] 😩 every packet lost over the link makes decompression of several subsequent packets fail, because the context gets invalidated for at least one link round-trip time from the lost packet 💔 and unfortunately, the large headers CRTP sends when updating the context waste extra bandwidth 🗑️
CRTP uses a local repair mechanism called TWICE, which came from IPHC 🔧 TWICE gets its name from the observation that when the flow of compressed packets is regular, the correct guess for when one packet is lost between the compression points is to apply the update in the current packet twice 🤯 TWICE improves CRTP performance a lot, but [CRTP-eval] also found that even with TWICE, CRTP still doubled the number of lost packets 😭
an enhanced variant of CRTP, called eCRTP [RFC3545], aims to improve CRTP's robustness when there's reordering and packet losses, while keeping the protocol almost unchanged from CRTP 🌟 so eCRTP does offer better ways to get some degree of robustness, but it comes at the cost of additional overhead, which means a drop in compression efficiency compared to CRTP 📉 it's a trade-off, bestie 🫠
4. Overview of ROHC (Informative) 🦋✨
4.1. General Principles ✨
okay so header compression works per-link bc there is SO much redundancy between header field values inside packets, esp between consecutive packets in the same flow 💖 to actually use that, there are a few essential steps to think about.
step one is identifying and grouping packets into different "flows" so the packet-to-packet redundancy is maxed out and the compression ratio gets better 🎀 grouping is usually based on source and destination host (IP) addresses, transport protocol type (e.g., UDP or TCP), process (port) numbers, and potentially extra unique app identifiers, like the synchronization source (SSRC) in RTP [RFC3550]. the compressor and decompressor each set up a context for the flow and identify it with a Context Identifier (CID) that shows up in each compressed header 🧚
step two is understanding how the header fields change. on a high level, fields fall into one of these classes:
- INFERRED: these values can be inferred from other fields or external sources. for example, the size of the frame carrying the packet can often be derived from the link-layer protocol, so the compression scheme doesn't have to send it 🙈
- STATIC: these are assumed to stay constant for the whole lifetime of the packet flow, so the value only gets communicated at the start ✨
- STATIC-DEF: these fields are used to define a packet flow, as we talked about above. packets whose values for these fields differ are treated as belonging to different flows. they're generally compressed like STATIC fields 🌸
- STATIC-KNOWN: these are expected to have well-known values, so there's no need to communicate them at all 👑
- CHANGING: these are expected to vary randomly, either within a limited set or range, or in some other manner. CHANGING fields usually get handled in more sophisticated ways based on a more detailed classification of their expected change patterns 🦋
last step: choose the encoding method(s) that will be applied to each field based on its classification. the encoding methods, combined with the field behaviour you already identified, are the input to designing the compressed header formats. then analysing the probability distribution of those change patterns helps optimise the packet formats, where the most frequently occurring change patterns for a field should be encoded within the most efficient format(s) 🔥
however, compression efficiency has to be traded off against two other properties: how robust the encoding is to losses and errors between the compressor and decompressor, and the ability to detect and cope with errors in the decompression process 😭
4.2. Compression Efficiency, Robustness, and Transparency 💅
the performance of a header compression protocol can be described with three parameters: its compression efficiency, its robustness, and its compression transparency. here's the tea:
- Compression efficiency: this is determined by how much the average header size is reduced by applying the compression protocol 🍓
- Robustness: a robust protocol tolerates packet losses, residual bit errors, and out-of-order delivery on the link where header compression happens, without losing additional packets or introducing additional errors in decompressed headers. main character energy 👑
- Compression transparency: this is a measure of how well the scheme maintains the semantics of the original headers. if all decompressed headers are bitwise identical to the corresponding original headers, the scheme is transparent 🫶
4.3. Developing the ROHC Protocol 🌈
the challenge in developing a header compression protocol is conciliating compression efficiency and robustness while keeping transparency, bc increasing robustness will always come at the expense of lower compression efficiency, and vice versa 😭 the scheme also has to be flexible enough that it minimises the impact of the varying round-trip times and loss patterns of the links where header compression will be used 💜
to get there, the scheme must provide facilities for the decompressor to verify decompression and detect potential context damage, plus context recovery mechanisms like feedback. earlier header compression schemes, the ones from before the Robust Header Compression (ROHC) Working Group (WG), weren't designed with those high-level objectives in mind 🙈
the ROHC WG has developed header compression solutions for the needs of present and future link technologies. they paid special attention to the more stringent requirements that come from wireless links, but the results are equally applicable to lots of other link technologies ✨
"RObust Header Compression (ROHC): Framework and four profiles: RTP, UDP, ESP, and uncompressed" [RFC3095] came out in 2001 as the first output of the ROHC WG. ROHC is a general, extendable framework for header compression, and profiles can be defined on top of it for compressing different protocol headers 🧚 RFC 3095 introduced a bunch of new compression techniques and was successful at living up to the requirements placed on it, as described in [RFC3096] 🎀
interoperability testing of RFC 3095 confirms that ROHC can meet its purposes, but feedback from implementers also said the protocol specification is complex and sometimes obscure 🌸 most importantly, a clear distinction between framework and profiles isn't obvious in [RFC3095], which also makes developing additional profiles kinda troublesome. so this document aims to explicitly specify the ROHC framework, while a companion document [RFC5225] specifies revised versions of the compression profiles of RFC 3095 🦋
4.4. Operational Characteristics of the ROHC Channel 🫶
robust header compression can be used over many types of link technologies. the ROHC framework gives profiles the flexibility to address a wide range of applications, and this section lists some of the operational characteristics of the ROHC channel (see also [RFC3759]) 💖
Multiplexing over a single logical channel: the ROHC channel provides a mechanism to identify a context within the general ROHC packet format. the CID makes it possible for a logical channel that supports ROHC to carry multiple header-compressed flows, while still letting a channel be dedicated to one single packet flow without any CID overhead. more specifically, ROHC uses a distinct CID space per logical channel, and the CID can be omitted for one of the flows over the ROHC channel when it's configured to use a small CID space ✨
Establishment of channel parameters: a link layer that defines support for the ROHC channel must provide the means to establish header compression channel parameters (see Section 5.1). this can be achieved through a negotiation mechanism, static provisioning, or some out-of-band signaling 🎀
Packet type identification: the ROHC channel defines a packet type identifier space, and it puts restrictions on the use of a number of identifiers that are common for all ROHC profiles. identifiers with no restrictions, i.e., identifiers not defined by this document, are available to each profile. the identifier is part of each compressed header, and this means the link that supports the ROHC channel can allocate one single link-layer payload type for ROHC 🧚
Out-of-order delivery between compression endpoints: each profile defines its own level of robustness, including tolerance to reordering of packets before, but especially between, compression endpoints, if any 🌈
for profiles specified in [RFC3095], the channel between the compressor and decompressor is required to maintain in-order delivery of the packets. in other words, the definition of these profiles assumes the decompressor always receives packets in the same order the compressor sent them 🙈 the impacts of reordering on the performance of these profiles are described in [RFC4224]. however, reordering before the compression point is handled, so these profiles make no assumption that the compressor will receive packets in order 💅
for the ROHCv2 profiles specified in [RFC5225], their definitions assume the decompressor can receive packets out of order, i.e., not in the same order the compressor sent them. reordering before the compression point is also dealt with 🦋
Duplication of packets: the link supporting the ROHC channel is required to not duplicate packets. (duplication of packets can still occur before they reach the compressor, so there's no assumption that the compressor will receive only one copy of each packet 👑)
Framing: the link layer must provide framing that makes it possible to distinguish frame boundaries and individual frames 🍓
Error detection/protection: ROHC profiles should be designed to cope with residual errors in the headers delivered to the decompressor. CRCs are used to detect decompression failures and to prevent or reduce damage propagation 🔥 however, it is recommended that lower layers deploy error detection for ROHC headers, and that ROHC headers with high residual error rates not be delivered 😭
4.5. Compression and Master Sequence Number (MSN) 🌸
compression of header fields is based on establishing a function to a sequence number, called the master sequence number (MSN). this function describes the change pattern of the field with respect to a change in the MSN 💜
change patterns include, for example, fields that increase monotonically or by a small value, fields that seldom change, and fields that stay unchanged for the entire lifetime of the packet flow. in that last case, the function to the MSN is equivalent to a constant value ✨
the compressor first establishes functions for each of the header fields, and then reliably communicates the MSN. when the change pattern of a field doesn't match the established function (i.e., the existing function gives a result that's different from the field in the header being compressed), additional information can be sent to update the parameters of that function 🎀
the MSN is defined per profile. it can either be derived directly from one of the fields of the protocol being compressed (e.g., the RTP SN [RFC5225]), or it can be created and maintained by the compressor (e.g., the MSN for compression of UDP in profile 0x0102 [RFC5225], or the MSN in ROHC-TCP [RFC4996]) 🧚
4.6. Static and Dynamic Parts of a Context 🧚
okay so a compression context can be split into two parts, bestie 💅 the static context and the dynamic context, and the split depends on the properties of the fields being compressed ✨
The static part holds the info needed to compress and decompress the fields whose change behavior is classified as STATIC, STATIC-KNOWN, or STATIC-DEF (see Section 4.1 above) 🎀
The dynamic part holds the state for all the other fields, the ones classified as CHANGING 🦋
5. The ROHC Framework (Normative) 👑
this section is the normative part, and it defines everything common to all ROHC profiles, aka the framework 💖 the framework lays out the requirements and functionality of the ROHC channel, including how to handle multiple compressed packet flows over the same channel 🔥
it also specifies the encoding methods used in the packet formats that every profile shares 🫶 profiles can reuse these encoding methods to encode fields in their profile-specific parts of a packet format without having to redefine them. no cap, that's so efficient 💅
5.1. The ROHC Channel 🌸
5.1.1. Contexts and Context Identifiers 🧚
every compressed flow has a context. the context is the state that the compressor and the decompressor keep so they can correctly compress or decompress the headers of the packets in that flow 💜 each context is identified using a CID.
a context counts as a new context when a CID gets tied to a profile for the first time since the ROHC channel was created. it also counts as new when a CID gets associated through the reception of an IR with a different profile than the one already in the context (IR-DYN doesn't count for this one, iykyk 🙈).
context info is conceptually kept in a table. the context table is indexed using the CID, which gets sent along with compressed headers and feedback info 📋
the CID space can be either small, meaning CIDs take the values 0 through 15, or large, meaning CIDs take values between 0 and 2^14 - 1 = 16383 ✨ whether the CID space is large or small MUST be established, possibly by negotiation, before any compressed packet may be sent over the ROHC channel. this is not optional, bestie 🙅♀️
the CID space is distinct for each channel. so CID 3 over channel A and CID 3 over channel B do not refer to the same context, even if the endpoints of A and B are the same nodes 🦋 CIDs for any pair of ROHC channels are not related. two associated ROHC channels that serve as feedback channels for one another don't even need CID spaces of the same size 💅
5.1.2. Per-Channel Parameters 🌈
the ROHC channel runs on a bunch of parameters that form part of the established channel state and the per-context state. the state of the ROHC channel MUST be established before the first ROHC packet may be sent. that can happen through negotiation protocols provided by the link layer (see also [RFC3241], which describes an option for negotiating ROHC parameters for PPP) 🧁 this section describes some of this channel state in an abstract way:
LARGE_CIDS: Boolean. if false, the small CID representation (0 octets or 1 prefix octet, covering CID 0 to 15) is used. if true, the large CID representation (1 or 2 embedded CID octets covering CID 0 to 16383) is used. see also Section 5.1.1 and Section 5.2.1.3 🌸MAX_CID: Non-negative integer. the highest CID number the compressor is allowed to use. (note that this parameter isn't coupled to LARGE_CIDS, but it's in effect further constrained by it 👀) this value represents an agreement by the decompressor that it can provide enough memory to host at least MAX_CID+1 contexts. the decompressor MUST maintain established contexts within this space until either the CID gets re-used by the establishment of a new context, or until the channel is taken down 🔥PROFILES: Set of non-negative integers, where each integer indicates a profile supported by both the compressor and the decompressor. a profile is identified by a 16-bit value. the 8 LSB bits indicate the actual profile, and the 8 MSB bits indicate the variant of that profile. the ROHC compressed header format only identifies the profile used with the 8 LSB bits. that means if multiple variants of the same profile are available for a ROHC channel, the PROFILES set after negotiation MUST NOT include more than one variant of the same profile. the compressor MUST NOT compress using a profile that is not in PROFILES 🚫FEEDBACK_FOR: Optional reference to a ROHC channel in the opposite direction between the same compression endpoints. if provided, this parameter says which other ROHC channel any feedback sent on this channel refers to (see [RFC3759]) 💌MRRU: Non-negative integer. Maximum Reconstructed Reception Unit. this is the size, in octets, of the largest reconstructed unit the decompressor is expected to reassemble from segments (see Section 5.2.5). this size includes the segmentation CRC. if MRRU is negotiated to be 0, segmentation MUST NOT be used on the channel, and received segments MUST be discarded by the decompressor 🧩
5.1.3. Persistence of Decompressor Contexts 🧚
as part of the negotiated channel parameters, the compressor and decompressor agree on the highest context identification (CID) number to be used, through the MAX_CID parameter 🫶 by agreeing on MAX_CID, the decompressor also agrees to provide memory to host at least MAX_CID+1 contexts. an established context with a CID inside this negotiated space SHOULD be kept by the decompressor until either the CID gets re-used, or the channel is taken down or re-negotiated 💖
5.2. ROHC Packets and Packet Types 🦋
this section uses the following convention in the diagrams when showing the various ROHC packet types, formats, and fields 📐
- colons ":" indicate that the part is optional
- slashes "/" indicate variable lengththe ROHC packet type indication scheme is designed to give us optional padding, a feedback packet type, an optional Add-CID octet (which carries 4 bits of CID), and a simple segmentation and reassembly mechanism. genius, honestly 👑
the following packet types are reserved at the ROHC framework level:
11100000 : Padding
1110nnnn : Add-CID octet (nnnn=CID with values 0x1 through 0xF)
11110 : Feedback
11111000 : IR-DYN packet
1111110 : IR packet
1111111 : Segmentother packet types can be defined and used by individual profiles:
0 : available (not reserved by ROHC framework)
10 : available (not reserved by ROHC framework)
110 : available (not reserved by ROHC framework)
1111101 : available (not reserved by ROHC framework)
11111001 : available (not reserved by ROHC framework)5.2.1. General Format of ROHC Packets 🎀
a ROHC packet has the following general format:
--- --- --- --- --- --- --- ---
: Padding :
--- --- --- --- --- --- --- ---
: Feedback :
--- --- --- --- --- --- --- ---
: Header :
--- --- --- --- --- --- --- ---
: Payload :
--- --- --- --- --- --- --- ---- Padding: any number (zero or more) of padding octets, where the format of a padding octet is as defined in Section 5.2.1.1 🧸
- Feedback: any number (zero or more) of feedback elements, where the format of a feedback element is as defined in Section 5.2.4.1 💬
- Header: either a profile-specific CO header (see Section 5.2.1.3), an IR or IR-DYN header (see Section 5.2.2), or a ROHC Segment (see Section 5.2.5). there can be at most one Header in a ROHC packet, but it may also be omitted (if the packet contains Feedback only) 🫧
- Payload: corresponds to zero or more octets of payload from the uncompressed packet, starting with the first octet in the uncompressed packet after the last header compressible by the current profile 📦
at least one of Feedback or Header MUST be present. no exceptions, babe 🙅♀️
5.2.1.1. Format of the Padding Octet 🌷
0 1 2 3 4 5 6 7
+---+---+---+---+---+---+---+---+
| 1 1 1 0 0 0 0 0 |
+---+---+---+---+---+---+---+---+Note: the Padding octet MUST NOT be interpreted as an Add-CID octet for CID 0. ⚠️
5.2.1.2. Format of the Add-CID Octet 🍓
0 1 2 3 4 5 6 7
+---+---+---+---+---+---+---+---+
| 1 1 1 0 | CID |
+---+---+---+---+---+---+---+---+CID: 0x1 through 0xF indicates CIDs 1 through 15.
Note: the Padding octet looks like an Add-CID octet for CID 0. wild that they look so similar 🙈
5.2.1.3. General Format of Header 💜
all ROHC packet types have the following general Header format:
0 x-1 x 7
--- --- --- --- --- --- --- ---
: Add-CID octet : if CID 1-15 and small CIDs
+--- --- --- --- ---+--- --- ---+
| type indication | body | 1 octet (8-x bits of body)
+--- --- --- --- ---+--- --- ---+
: :
/ 0, 1, or 2 octets of CID / 1 or 2 octets if large CIDs
: :
+---+---+---+---+---+---+---+---+
/ body / variable length
+---+---+---+---+---+---+---+---+- type indication: the ROHC packet type.
- body: interpreted according to the packet type indication and CID information, as defined by individual profiles.
so the header either starts with a packet type indication, or it has a packet type indication right after an Add-CID octet 💅
when the ROHC channel is configured with a small CID space:
- if an Add-CID immediately precedes the packet type indication, the packet has the CID of the Add-CID. otherwise, it has CID 0 🌼
- a small CID with the value 0 is represented using zero bits. so a flow associated with CID 0 has no CID overhead in the compressed header. in that case, the Header starts with a packet type indication ✨
- a small CID with a value from 1 to 15 is represented using the Add-CID octet described above. the Header starts with the Add-CID octet, followed by a packet type indication 🎀
- there is no large CID in the Header 🫧
when the ROHC channel is configured with a large CID space:
- the large CID is always present. it's represented using the encoding scheme of Section 5.3.2, limited to two octets. in this case, the Header starts with a packet type indication 🌈
5.2.2. Initialization and Refresh (IR) Packet Types 🧚
IR packet types contain a profile identifier, which determines how the rest of the header is interpreted. they also associate a profile with a context. the stored profile parameter further determines the syntax and semantics of the packet type identifiers and packet types used with a specific context 🔑
the IR and IR-DYN packets always update the context for all context-updating fields carried in the header. they never clear the context, except when initializing a new context (see Section 5.1.1), or unless the profile indicated in the Profile field specifies otherwise. so they're basically the glow-up packets of ROHC 🌟✨
5.2.2.1. ROHC IR Header Format
okay so the IR header is the one that ties a CID to a profile 🎀 and usually sets up the context too ✨. It can also refresh all (or parts of) the context 💅. Here's the general layout for IR Header:
0 1 2 3 4 5 6 7
--- --- --- --- --- --- --- ---
: Add-CID octet : if CID 1-15 and small CID
+---+---+---+---+---+---+---+---+
| 1 1 1 1 1 1 0 | x | IR type octet
+---+---+---+---+---+---+---+---+
: :
/ 0-2 octets of CID / 1 or 2 octets if large CIDs
: :
+---+---+---+---+---+---+---+---+
| Profile | 1 octet
+---+---+---+---+---+---+---+---+
| CRC | 1 octet
+---+---+---+---+---+---+---+---+
| |
/ profile-specific information / variable length
| |
+---+---+---+---+---+---+---+---+- x: Profile-specific information. Interpreted according to the profile indicated in the Profile field of the IR header.
- Profile: The profile associated with the CID. In the IR header, the profile identifier is abbreviated to the 8 least significant bits (see Section 5.1.2).
- CRC: 8-bit CRC (see Section 5.3.1.1).
- Profile-specific information: The content of this part of the IR header is defined by the individual profiles. It is interpreted according to the profile indicated in the Profile field.
5.2.2.2. ROHC IR-DYN Header Format
Compared to the IR header, the IR-DYN header can never initialize a non-initialized context 🙅♀️. However, it can redefine what profile is associated with a context, if the profile indicated in the IR-DYN header allows this. So this packet type is also reserved at the framework level 🦋. The IR-DYN header typically also initializes or refreshes parts of a context. For IR-DYN, Header has the following general format:
0 1 2 3 4 5 6 7
--- --- --- --- --- --- --- ---
: Add-CID octet : if CID 1-15 and small CID
+---+---+---+---+---+---+---+---+
| 1 1 1 1 1 0 0 0 | IR-DYN type octet
+---+---+---+---+---+---+---+---+
: :
/ 0-2 octets of CID / 1 or 2 octets if large CIDs
: :
+---+---+---+---+---+---+---+---+
| Profile | 1 octet
+---+---+---+---+---+---+---+---+
| CRC | 1 octet
+---+---+---+---+---+---+---+---+
| |
/ profile-specific information / variable length
| |
+---+---+---+---+---+---+---+---+- Profile: The profile associated with the CID. This is abbreviated in the same way as in IR packets.
- CRC: 8-bit CRC (see Section 5.3.1.1).
- Profile-specific information: The content of this part of the IR-DYN header is defined by the individual profiles. It is interpreted according to the profile indicated in the Profile field.
5.2.3. ROHC Initial Decompressor Processing
Initially, all contexts are in no context state 😴. So all packets referencing a non-initialized context, except packets that have enough information on the static fields, cannot be decompressed by the decompressor. Rip 💀.
When the decompressor receives a packet of type IR, the profile indicated in the IR packet determines how it is to be processed.
- If the 8-bit CRC fails to verify the integrity of the header, the packet MUST NOT be decompressed and delivered to upper layers. If a profile is indicated in the context, the logic of that profile determines what, if any, feedback is to be sent. If no profile is noted in the context, the logic used to determine what, if any, feedback to send is up to the implementation. However, it may be suitable to take no further actions, as any part of the IR header covered by the CRC may have caused the failure.
When the decompressor receives a packet of type IR-DYN, the profile indicated in the IR-DYN packet determines how it is to be processed.
- If the 8-bit CRC fails to verify the integrity of the header, the packet MUST NOT be decompressed and delivered to upper layers. If a profile is indicated in the context, the logic of that profile determines what, if any, feedback is to be sent. If no profile is noted in the context, the logic used to determine what, if any, feedback to send is up to the implementation. However, it may be suitable to take no further actions, as any part of the IR-DYN header covered by the CRC may have caused the failure.
- If the context has not already been initialized, the packet MUST NOT be decompressed and delivered to upper layers. The logic of the profile indicated in the IR-DYN header (if verified by the 8-bit CRC), determines what, if any, feedback is to be sent.
If a parsing error occurs for any packet type, the decompressor MUST discard the packet without further processing. For example, a CID field is present in the compressed header when the large CID space is used for the ROHC channel, and the field is coded using the self-describing variable-length encoding of Section 5.3.2; if the field starts with 110 or 111, this would generate a parsing error for the decompressor because this field must not be encoded with a size larger than 2 octets. Oof, that's a sneaky one 🙈.
It is RECOMMENDED that profiles disallow the decompressor to make a decompression attempt for packets carrying only a 3-bit CRC after it has invalidated some or all of the entire dynamic context, until a packet that contains sufficient information on the dynamic fields is received, decompressed, and successfully verified by a 7- or 8-bit CRC. 🌈✨
5.2.4. ROHC Feedback
Feedback carries information from the decompressor to the compressor 📨. Feedback can be sent over a ROHC channel that operates in the same direction as the feedback.
The general ROHC packet format allows transport of feedback using interspersion or piggybacking (see [RFC3759]), or a combination of both, over a ROHC channel. This is facilitated by the following properties:
- Reserved packet type: A feedback packet type is reserved at the framework level. The packet type can carry variable-length feedback information.
- CID information: The feedback information sent on a particular channel is passed to, and interpreted by, the compressor associated with feedback on that channel. Thus, each feedback element contains CID information from the channel for which the feedback is sent. The ROHC feedback scheme thus requires that a channel carries feedback to at most one compressor. How a compressor is associated with the feedback for a particular channel is outside the scope of this specification. See also [RFC3759].
- Length information: The length of a feedback element can be determined by examining the first few octets of the feedback. This enables piggybacking of feedback, and also the concatenation of more than one feedback element in a packet. The length information thus decouples the decompressor from the associated same-side compressor, as the decompressor can extract the feedback information from the compressed header without parsing its content and hand over the extracted information.
The association between compressor-decompressor pairs operating in opposite directions, for the purpose of exchanging piggyback and/or interspersed feedback, SHOULD be maintained for the lifetime of the ROHC channel. Otherwise, it is RECOMMENDED that the compressor be notified if the feedback channel is no longer available: the compressor SHOULD then restart compression by creating a new context for each packet flow, and SHOULD use a CID value that was not previously associated with the profile used to compress the flow. Think of it as keeping the group chat alive 💬.
5.2.4.1. ROHC Feedback Format
ROHC defines three different categories of feedback messages: acknowledgment (ACK), negative ACK (NACK), and NACK for the entire context (STATIC-NACK). Other types of information may be defined in profile-specific feedback information.
- ACK: Acknowledges successful decompression of a packet. Indicates that the decompressor considers its context to be valid.
- NACK: Indicates that the decompressor considers some or all of the dynamic part of its context invalid.
- STATIC-NACK: Indicates that the decompressor considers its entire static context invalid, or that it has not been established.
Feedback sent on a ROHC channel consists of one or more concatenated feedback elements, where each feedback element has the following format:
0 1 2 3 4 5 6 7
+---+---+---+---+---+---+---+---+
| 1 1 1 1 0 | Code | feedback type
+---+---+---+---+---+---+---+---+
: Size : if Code = 0
+---+---+---+---+---+---+---+---+
: Add-CID octet : if for small CIDs and (CID != 0)
+---+---+---+---+---+---+---+---+
: :
/ large CID / 1-2 octets if for large CIDs
: :
+---+---+---+---+---+---+---+---+
/ FEEDBACK data / variable length
+---+---+---+---+---+---+---+---+- Code:
- 0 indicates that a Size octet is present.
- 1-7 indicates the total size of the FEEDBACK data field and the CID field (if any), in octets.
- Size: Indicates the total size of the FEEDBACK data field and the CID field (if any), in octets.
- FEEDBACK data: FEEDBACK-1 or FEEDBACK-2 (see below).
CID information in a feedback element indicates the context for which feedback is sent. The LARGE_CIDS parameter that controls whether a large CID is present is taken from the channel state of the receiving compressor's channel, not from the state of the channel carrying the feedback.
The large CID field, if present, is encoded according to Section 5.3.2, and it MUST NOT be encoded using more than 2 octets.
The FEEDBACK data field can have either of the following two formats:
FEEDBACK-1:
0 1 2 3 4 5 6 7
+---+---+---+---+---+---+---+---+
| profile-specific information | 1 octet
+---+---+---+---+---+---+---+---+FEEDBACK-2:
0 1 2 3 4 5 6 7
+---+---+---+---+---+---+---+---+
|Acktype| |
+---+---+ profile-specific / at least 2 octets
/ information |
+---+---+---+---+---+---+---+---+Acktype: 0 = ACK
1 = NACK
2 = STATIC-NACK
3 is reserved (MUST NOT be used. Otherwise unparsable.)5.2.5. ROHC Segmentation
ROHC defines a simple segmentation protocol 🧩. The compressor may perform segmentation, e.g., to accommodate packets that are larger than a specific size configured for the channel.
5.2.5.1. Segmentation Usage Considerations ✨
okay so the ROHC segmentation protocol is honestly not super efficient 💀. It was never meant to replace link-layer segmentation, so if link-layer segmentation is available and works well for the job, these SHOULD be used instead 🫶.
the ROHC segmentation protocol was designed assuming packets arrive in order between the compressor and the decompressor, with only a CRC for error detection and no sequence numbers 🔥. if in-order delivery can't be guaranteed, ROHC segmentation MUST NOT be used 🙅♀️.
it also assumes that all the segments of one ROHC packet for one context arrive without any interference from other ROHC packets on the channel, including packets for a different context 👀. because of that, segments don't carry CID info, so they can't be linked to a specific context until every segment has arrived and the whole unit has been rebuilt 🦋.
5.2.5.2. Segmentation Protocol 💖
ROHC segmentation is applied to the combination of the Header and the Payload fields of the ROHC packet, as defined in Section 5.2.1 🌸.
Here's the segment format:
0 1 2 3 4 5 6 7
+---+---+---+---+---+---+---+---+
| 1 1 1 1 1 1 1 | F | segment type
+---+---+---+---+---+---+---+---+
/ Segment / variable length
+---+---+---+---+---+---+---+---+F: Final bit. If it's set, it means this is the last segment of a reconstructed unit 🏁.
Padding and/or Feedback may come before the segment type octet 🧚. There's no per-segment CID, but CID information is of course part of the reconstructed unit 🎀. The reconstructed unit MUST NOT contain padding, segments, or feedback 🚫.
when a final segment comes in, the decompressor reassembles the segment in this packet plus any non-final segments that came right before it into one reconstructed unit, in the order they were received 💅. all the segments for one reconstructed unit have to be received consecutively and in the correct order by the decompressor 📦. if a non-segment ROHC packet directly follows a non-final segment, the reassembly of the current unit is aborted, and the decompressor MUST discard the non-final segments received so far on this channel 💀.
Here's the reconstructed unit:
0 1 2 3 4 5 6 7
+---+---+---+---+---+---+---+---+
/ Header /
+---+---+---+---+---+---+---+---+
: Payload :
+---+---+---+---+---+---+---+---+
/ CRC / 4 octets
+---+---+---+---+---+---+---+---+Header: See Section 5.2.1 ✨
Payload: See Section 5.2.1 ✨
CRC: a 32-bit CRC computed using the polynomial of Section 5.3.1.4 🔢. If the reconstructed unit is 4 octets or less, or the CRC fails, or it's larger than the channel parameter MRRU (see Section 5.1.2), the reconstructed unit MUST be discarded by the decompressor 🗑️. if the CRC succeeds, the unit can be processed further 🌈.
5.3. General Encoding Methods 🌸
5.3.1. Header Compression CRCs, Coverage, and Polynomials 🔢
this section explains how to calculate the CRCs ROHC uses 🧮. for all CRCs, the algorithm is the same as the one in [RFC1662], defined in Appendix A of this document, with the polynomials given in the sections below 💜.
5.3.1.1. 8-bit CRC in IR and IR-DYN Headers 🦋
the coverage for the 8-bit CRC in the IR and IR-DYN headers is profile-dependent, but it MUST cover at least the initial part of the header, ending with the Profile field, including the CID or an Add-CID octet 💖. Feedback and padding aren't part of the Header (Section 5.2.1), so they aren't included in the CRC calculation 🙅♀️. as a rule of thumb for profile specifications, any other information that initializes the decompressor context SHOULD also be covered by a CRC 🎀.
more specifically, the 8-bit CRC does not cover only and entirely the original uncompressed header 😭. so it doesn't give the decompressor a way to verify a decompression attempt, or a way to verify the correctness of the entire decompressor context 🫠. however, when it succeeds, it does provide enough robustness for the decompressor to update its context with the information carried in the IR or the IR-DYN header ✨.
the CRC polynomial for the 8-bit CRC is:
C(x) = 1 + x + x^2 + x^8when computing the CRC, the CRC field in the header is set to zero, and the initial content of the CRC register is set to all 1's 🌈.
5.3.1.2. 3-bit CRC in Compressed Headers 🍓
the 3-bit CRC in compressed headers is calculated over all octets of the entire original header, before compression, in the following manner 🧠.
the initial content of the CRC register is set to all 1's.
the polynomial for the 3-bit CRC is:
C(x) = 1 + x + x^3the purpose of the 3-bit CRC is to give the decompressor a way to verify the outcome of a decompression attempt for small compressed headers, and to detect context damage based on aggregated probability over a number of decompression attempts 👀. however, it's too weak to provide enough success guarantees from decompressing one single header 😬. so compressed headers carrying a 3-bit CRC are normally not suitable for performing context repairs at the decompressor 🚫. hence, profiles should refrain from allowing decompression of such a header when some or all of the decompressor context is assumed invalid 🙈.
5.3.1.3. 7-bit CRC in Compressed Headers 💅
the 7-bit CRC in compressed headers is calculated over all octets of the entire original header, before compression, in the following manner 🔥.
the initial content of the CRC register is set to all 1's.
the polynomial for the 7-bit CRC is:
C(x) = 1 + x + x^2 + x^3 + x^6 + x^7the purpose of the 7-bit CRC is to give the decompressor a way to verify the outcome of a decompression attempt for a larger compressed header, and to provide enough protection to validate a context repair at the decompressor 🛠️. the 7-bit CRC is strong enough to assume a repair is successful from decompressing one single header, so profiles may allow decompression of a header carrying a 7-bit CRC when some of the decompressor context is assumed invalid 👑.
5.3.1.4. 32-bit Segmentation CRC 🧚
the 32-bit CRC is used by the segmentation scheme to verify the reconstructed unit, so it's calculated over the segmented unit, i.e., over the Header and the Payload fields of the ROHC packet 💜.
the initial content of the CRC register is set to all 1's.
the polynomial for the 32-bit CRC is:
C(x) = x^0 + x^1 + x^2 + x^4 + x^5 + x^7 + x^8 + x^10 +
x^11 + x^12 + x^16 + x^22 + x^23 + x^26 + x^32the purpose of the 32-bit CRC is to verify the reconstructed unit 🫶.
5.3.2. Self-Describing Variable-Length Values 🦋
the values of many fields and compression parameters can vary widely 🌈. to keep transfers efficient, a variable number of octets is used to encode them ✨. the first few bits of the first octet determine how many octets are used 💅:
First bit is 0: 1 octet.
7 bits transferred.
Up to 127 decimal.
Encoded octets in hexadecimal: 00 to 7F
First bits are 10: 2 octets.
14 bits transferred.
Up to 16 383 decimal.
Encoded octets in hexadecimal: 80 00 to BF FF
First bits are 110: 3 octets.
21 bits transferred.
Up to 2 097 151 decimal.
Encoded octets in hexadecimal: C0 00 00 to DF FF FF
First bits are 111: 4 octets.
29 bits transferred.
Up to 536 870 911 decimal.
Encoded octets in hexadecimal: E0 00 00 00 to FF FF FF FF5.4. ROHC UNCOMPRESSED -- No Compression (Profile 0x0000) 🎀
this section describes the uncompressed ROHC profile 🫶. its profile identifier is 0x0000 🔢.
Profile 0x0000 gives you a way to send IP packets without compressing them 🦋. this can be used for any packet for which a compression profile isn't available in the set of profiles the ROHC channel supports, or for which compression isn't desirable for some reason 🌸.
after initialization, the only overhead for sending packets with Profile 0x0000 is the size of the CID 💖. when uncompressed packets are frequent, Profile 0x0000 should be associated with a CID the size of zero or one octet 🍓. Profile 0x0000 SHOULD be associated with at most one CID 👑.
5.4.1. IR Packet 💜
the initialization and refresh packet (IR packet) for Profile 0x0000 has the following Header 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 |res|
+---+---+---+---+---+---+---+---+
: :
/ 0-2 octets of CID info / 1-2 octets if for large CIDs
: :
+---+---+---+---+---+---+---+---+
| Profile = 0x00 | 1 octet
+---+---+---+---+---+---+---+---+
| CRC | 1 octet
+---+---+---+---+---+---+---+---+res: MUST be set to zero; otherwise, the decompressor MUST discard the packet 🚫.
Profile: 0x00 🔢
CRC: an 8-bit CRC computed using the polynomial of Section 5.3.1.1 🧮. the CRC covers the first octet of the IR Header through the Profile octet of the IR Header, i.e., it does not cover the CRC itself 💅. it also doesn't cover any preceding Padding or Feedback, nor the Payload 🙈.
for the IR packet, the Payload has the following format:
--- --- --- --- --- --- --- ---
: : (optional)
/ IP packet / variable length
: :
--- --- --- --- --- --- --- ---IP packet: an uncompressed IP packet may be included in the IR packet 🌈. the decompressor figures out whether the IP packet is present by looking at the length of the IR packet 👀.
5.4.2. Normal Packet ✨
a Normal packet is a normal IP packet plus CID information 🎀. for the Normal Packet, the following format corresponds to the Header and Payload (as defined in Section 5.2.1) 🦋:
0 1 2 3 4 5 6 7
--- --- --- --- --- --- --- ---
: Add-CID octet : if for small CIDs and (CID != 0)
+---+---+---+---+---+---+---+---+
| first octet of IP packet |
+---+---+---+---+---+---+---+---+
: :
/ 0-2 octets of CID info / 1-2 octets if for large CIDs
: :
+---+---+---+---+---+---+---+---+
| |
/ rest of IP packet / variable length
| |
+---+---+---+---+---+---+---+---+note this one! 💖 the first octet of the IP packet starts with the bit pattern 0100 (IPv4) or 0110 (IPv6). this doesn't conflict with any reserved packet types 🙌.
when the channel uses small CIDs, and Profile 0x0000 is associated with a CID > 0, an Add-CID octet comes before the IP packet 🧚. when the channel uses large CIDs, the CID is placed so that it starts at the second octet of the combined Header/Payload format above 🍓.
a Normal Packet may carry Padding and/or Feedback like any other ROHC packet, preceding the combined Header/Payload 🫶.
5.4.3. Context Initialization ✨
okay so the compressor sets up the static context for the UNCOMPRESSED profile by sending IR packets (see Section 5.4.1) 🎀 during context initialization, it is RECOMMENDED that it keeps sending IR packets until it's reasonably confident the decompressor has actually received at least one. 💖 that confidence can come from feedback from the decompressor, or from knowing what the link is like 🧚
the compressor SHOULD keep periodically sending IR packets for a context tied to the UNCOMPRESSED profile, at least until it gets feedback from the decompressor for that context 🦋 once that feedback shows up, it MAY stop the periodic IR sending 💅
5.4.4. Decompressor Operation ✨
when an IR packet shows up, the decompressor checks its header first using the 8-bit CRC 🔍
- if the header fails validation, the decompressor MUST NOT deliver the IP packet to upper layers. 💀
- if the header passes validation, the decompressor:
- initializes the context if it doesn't already have a valid context for the given CID associated with the specified profile,
- delivers the IP packet to upper layers if there is one,
- MAY send an ACK. 🫶
when any other packet arrives while the decompressor has no context, it gets discarded with no further action 🙈
when a Normal packet arrives and the decompressor has a valid context, the IP packet is pulled out and delivered to upper layers 🌸
5.4.5. Feedback ✨
the only kind of feedback Profile 0x0000 defines is ACK 💜 it uses the FEEDBACK-1 format from Section 5.2.4.1, and the profile-specific octet in FEEDBACK-1 is 0 (zero) 🎀 which means the FEEDBACK-2 format is not defined for Profile 0x0000, full stop 💅
6. Overview of a ROHC Profile (Informative) ✨
okay this part is giving big-picture vibes 🌈 the ROHC protocol has two parts: a framework and a profile. the framework defines the mechanisms every profile shares, and the profile defines the compression algorithm and its profile-specific packet formats 🧚
Section 5 is where the details of the ROHC framework live ✨ this section is just an informative overview of what makes up a profile spec. the normative spec for individual profiles is outside the scope of this document 🙈
a ROHC profile defines the elements that build the compression protocol. a ROHC profile consists of:
Packet formats:
- Bits-on-the-wire: the profile defines the bit layout for the profile-specific packet types it defines, and for the profile-specific parts of packet types common to all profiles (for example, IR and IR-DYN). 🦋
- Field encodings: bits and groups of bits from the packet format layout, called Compressed fields, represent the result of an encoding method specific to that compressed field within a specific packet format. the profile defines these encoding methods. 🍓
- Updating properties: profile-specific packet formats may update the decompressor's state, and they can do that in different ways. the profile defines how individual profile-specific fields, or whole profile-specific packet types, update the decompressor context. 🔥
- Verification: packets that update the decompressor's state get verified so the context doesn't get wrongly updated. the profile defines the mechanisms used to verify the decompression of a packet. 🫶
Context management:
- Robustness logic: packets can get lost or reordered between the compressor and the decompressor. the profile defines mechanisms to minimize the impact of those events and to stop damage from spreading. 🛡️
- Repair mechanism: even with robustness logic, impairment events can still cause decompression failures, and even context damage at the decompressor. the profile defines context repair mechanisms, including feedback logic if it's used. 👑
7. Acknowledgments ✨
the authors want to shout out everyone who has contributed to earlier ROHC work 💖 extra special thanks go to the authors of RFC 3095 [RFC3095], which is the technical basis for this document 🌸 thanks also to everyone who helped with the RFC 3095 corrections and clarifications document [RFC4815], since technical content from it was brought into this document where it applied 🧚 and thanks to Jani Juvan for spotting an inconsistency between the feedback structure in [RFC4995] and the one in [RFC3095], which made this update to [RFC4995] necessary 👏
the committed WG document reviewers were Carl Knutsson, Biplab Sarkar, and Robert Stangarone, who reviewed the document during the working group last calls 💅 extra thanks to Bert Wijnen and Brian Carpenter for their comments during IETF Last Call 🎀
8. IANA Considerations ✨
there's an IANA registry for "RObust Header Compression (ROHC) Profile Identifiers" [ROHC-ids], which RFC 3095 [RFC3095] created 🗂️ the assignment policy, as RFC 3095 outlines, goes like this:
The ROHC profile identifier is a non-negative integer. In many negotiation protocols, it will be represented as a 16-bit value. Due to the way the profile identifier is abbreviated in ROHC packets, the 8 LSBs of the profile identifier have a special significance: Two profile identifiers with identical 8 LSBs should be assigned only if the higher-numbered one is intended to supersede the lower-numbered one. To highlight this relationship, profile identifiers should be given in hexadecimal (for example, as in 0x1234, which would supersede 0x0A34).
following the policies outlined in [RFC5226], the IANA policy for assigning new values for the profile identifier is Specification Required: values and their meanings must be documented in an RFC or in some other permanent and readily available reference, in sufficient detail that interoperability between independent implementations is possible. in the 8 LSBs, the range 0 to 127 is reserved for IETF standard-track specifications, and the range 128 to 254 is available for other specifications that meet this requirement (such as Informational RFCs). the LSB value 255 is reserved for future extensibility of the present specification. 🌈
the following profile identifiers have been allocated so far 🦋
Profile Identifier Usage Reference
------------------ ---------------------- ---------
0x0000 ROHC uncompressed RFC 5795
0x0001 ROHC RTP RFC 3095
0x0002 ROHC UDP RFC 3095
0x0003 ROHC ESP RFC 3095
0x0004 ROHC IP RFC 3843
0x0005 ROHC LLA RFC 3242
0x0105 ROHC LLA with R-mode RFC 3408
0x0006 ROHC TCP RFC 4996
0x0007 ROHC RTP/UDP-Lite RFC 4019
0x0008 ROHC UDP-Lite RFC 4019
0x0101 ROHCv2 RTP RFC 5225
0x0102 ROHCv2 UDP RFC 5225
0x0103 ROHCv2 ESP RFC 5225
0x0104 ROHCv2 IP RFC 5225
0x0107 ROHCv2 RTP/UDP-Lite RFC 5225
0x0108 ROHCv2 UDP-Lite RFC 5225new profiles will need new identifiers assigned by the IANA, but this document does not require any additional IANA action 🎀
9. Security Considerations ✨
okay this section is serious, bestie 😭 because encryption removes the redundancy that header compression schemes try to exploit, there's some temptation to skip encrypting headers so things can run over low-bandwidth links 🚨
a malfunctioning or malicious header compressor could make the header decompressor rebuild packets that don't match the originals but still have valid headers and possibly valid transport checksums. 💀 that kind of corruption may be caught with end-to-end authentication and integrity mechanisms, which compression won't affect. 🔒 on top of that, the ROHC header compression scheme uses an internal checksum to verify reconstructed headers, which lowers the chance of decompressed headers not matching the originals without anyone noticing. 🛡️
denial-of-service attacks are possible if an intruder can inject, for example, bogus IR, IR-DYN, or feedback packets onto the link and so reduce compression efficiency 😤 however, an intruder who can inject arbitrary packets at the link layer like this brings extra security issues that totally dwarf anything related to header compression 💀💀
10. References ✨
10.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. 📚
that's the whole doc, babe 🌈✨
10.2. Informative References 📚
okay these are the receipts, bestie 🧾✨ none of these are required reading, but they're where the backstory lives 🫶
- [CRTP-eval] Degermark, M., Hannu, H., Jonsson, L., and K. Svanbro, ""Evaluation of CRTP Performance over Cellular Radio Networks", IEEE Personal Communication Magazine, Volume 7, number 4, pp. 20-25, August 2000.", 2000.
- [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, August 1980.
- [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981.
- [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981.
- [RFC1144] Jacobson, V., "Compressing TCP/IP headers for low-speed serial links", RFC 1144, February 1990.
- [RFC1662] Simpson, W., "PPP in HDLC-like Framing", STD 51, RFC 1662, July 1994.
- [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998.
- [RFC2507] Degermark, M., Nordgren, B., and S. Pink, "IP Header Compression", RFC 2507, February 1999.
- [RFC2508] Casner, S. and V. Jacobson, "Compressing IP/UDP/RTP Headers for Low-Speed Serial Links", RFC 2508, February 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.
- [RFC3096] Degermark, M., "Requirements for robust IP/UDP/RTP header compression", RFC 3096, July 2001.
- [RFC3241] Bormann, C., "Robust Header Compression (ROHC) over PPP", RFC 3241, April 2002.
- [RFC3545] Koren, T., Casner, S., Geevarghese, J., Thompson, B., and P. Ruddy, "Enhanced Compressed RTP (CRTP) for Links with High Delay, Packet Loss and Reordering", RFC 3545, July 2003.
- [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, July 2003.
- [RFC3759] Jonsson, L-E., "RObust Header Compression (ROHC): Terminology and Channel Mapping Examples", RFC 3759, April 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.
- [RFC4815] Jonsson, L-E., Sandlund, K., Pelletier, G., and P. Kremer, "RObust Header Compression (ROHC): Corrections and Clarifications to RFC 3095", RFC 4815, February 2007.
- [RFC4995] Jonsson, L-E., Pelletier, G., and K. Sandlund, "The RObust Header Compression (ROHC) Framework", RFC 4995, July 2007.
- [RFC4996] Pelletier, G., Sandlund, K., Jonsson, L-E., and M. West, "RObust Header Compression (ROHC): A Profile for TCP/IP (ROHC-TCP)", RFC 4996, July 2007.
- [RFC5225] Pelletier, G. and K. Sandlund, "RObust Header Compression Version 2 (ROHCv2): Profiles for RTP, UDP, IP, ESP and UDP-Lite", RFC 5225, April 2008.
- [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.
- [ROHC-ids] IANA, "RObust Header Compression (ROHC) Profile Identifiers",
<http://www.iana.org>.
Appendix A. CRC Algorithm 💅
okay the authors wrote this tiny Perl demo to show off the four CRC types used in RFC 3095 🔥 you type your data in hex, hit Control+D, and it spits out the results. it's giving science class and I'm obsessed 🧪🤓
#!/usr/bin/perl -w
use strict;
#=================================
#
# ROHC CRC demo - Carsten Bormann cabo@tzi.org 2001-08-02
#
# This little demo shows the four types of CRC in use in RFC 3095,
# the specification for robust header compression. Type your data in
# hexadecimal form and then press Control+D.
#
#---------------------------------
#
# utility
#
sub dump_bytes($) {
my $x = shift;
my $i;
for ($i = 0; $i < length($x); ) {
printf("%02x ", ord(substr($x, $i, 1)));
printf("\n") if (++$i % 16 == 0);
}
printf("\n") if ($i % 16 != 0);
}
#---------------------------------
#
# The CRC calculation algorithm.
#
sub do_crc($$$) {
my $nbits = shift;
my $poly = shift;
my $string = shift;
my $crc = ($nbits == 32 ? 0xffffffff : (1 << $nbits) - 1);
for (my $i = 0; $i < length($string); ++$i) {
my $byte = ord(substr($string, $i, 1));
for( my $b = 0; $b < 8; $b++ ) {
if (($crc & 1) ^ ($byte & 1)) {
$crc >>= 1;
$crc ^= $poly;
} else {
$crc >>= 1;
}
$byte >>= 1;
}
}
printf "%2d bits, ", $nbits;
printf "CRC: %02x\n", $crc;
}
#---------------------------------
#
# Test harness
#
$/ = undef;
$_ = <>; # read until EOF
my $string = ""; # extract all that looks hex:
s/([0-9a-fA-F][0-9a-fA-F])/$string .= chr(hex($1)), ""/eg;
dump_bytes($string);
#---------------------------------
#
# 32-bit segmentation CRC
# Note that the text implies this is complemented like for PPP
# (this differs from 8, 7, and 3-bit CRC)
#
# C(x) = x^0 + x^1 + x^2 + x^4 + x^5 + x^7 + x^8 + x^10 +
# x^11 + x^12 + x^16 + x^22 + x^23 + x^26 + x^32
#
do_crc(32, 0xedb88320, $string);
#---------------------------------
#
# 8-bit IR/IR-DYN CRC
#
# C(x) = x^0 + x^1 + x^2 + x^8
#
do_crc(8, 0xe0, $string);
#---------------------------------
#
# 7-bit FO/SO CRC
#
# C(x) = x^0 + x^1 + x^2 + x^3 + x^6 + x^7
#
do_crc(7, 0x79, $string);
#---------------------------------
#
# 3-bit FO/SO CRC
#
# C(x) = x^0 + x^1 + x^3
#
do_crc(3, 0x6, $string);Authors' Addresses 🎀
these are the girls who built it, bestie 🫶 go say hi 💖
Kristofer Sandlund
Ericsson
Box 920
Lulea SE-971 28
Sweden
Phone: +46 (0) 8 404 41 58
EMail: kristofer.sandlund@ericsson.com
Ghyslain Pelletier
Ericsson
Box 920
Lulea SE-971 28
Sweden
Phone: +46 (0) 8 404 29 43
EMail: ghyslain.pelletier@ericsson.com
Lars-Erik Jonsson
Optand 737
Ostersund SE-831 92
Sweden
Phone: +46 76 830 03 12
EMail: lars-erik@lejonsson.comthat's the whole RFC, bestie 🌈✨💅
📦 where this page comes from
- ietf: rfc5795 2010-03
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms