RFC 4995
The RObust Header Compression (ROHC) Framework
RFC 4995: The RObust Header Compression (ROHC) Framework ✨
Okay bestie, this is RFC 4995 🎀, called The RObust Header Compression (ROHC) Framework. It came out of the Network Working Group in July 2007 and was written by L-E. Jonsson, G. Pelletier, and K. Sandlund, all from Ericsson 💜. It's a Standards Track doc. The header doesn't list anything it Obsoletes or Updates, but the Abstract says it doesn't modify or update RFC 3095, so that's the big one to know 👀.
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.
Copyright Notice ©️
Copyright (C) The IETF Trust (2007).
Abstract 🦋
Okay so ROHC is giving efficient, flexible, AND future-proof header compression, no cap 💅. It's built to work well and stay robust over all kinds of link technologies, even the ones with very different vibes from each other 🌈.
The ROHC framework, along with a set of compression profiles, was first defined in RFC 3095. To make the ROHC specs better and simpler, this document defines the ROHC framework and the profile for uncompressed separately 🧚. The framework definition does not modify or update the framework specified by RFC 3095, so it's a clean glow-up with zero drama ✨.
Table of Contents 🗂️
1. Introduction ....................................................3
2. Terminology .....................................................4
2.1. Acronyms ...................................................4
2.2. ROHC Terminology ...........................................4
3. Background (Informative) ........................................7
3.1. Header Compression Fundamentals ............................7
3.2. A Short History of Header Compression ......................7
4. Overview of Robust Header Compression (ROHC) (Informative) ......8
4.1. General Principles .........................................8
4.2. Compression Efficiency, Robustness, and Transparency ......10
4.3. Developing the ROHC Protocol ..............................10
4.4. Operational Characteristics of the ROHC Channel ...........11
4.5. Compression and Master Sequence Number (MSN) ..............13
4.6. Static and Dynamic Parts of a Context .....................13
5. The ROHC Framework (Normative) .................................14
5.1. The ROHC Channel ..........................................14
5.1.1. Contexts and Context Identifiers ...................14
5.1.2. Per-Channel Parameters .............................15
5.1.3. Persistence of Decompressor Contexts ...............16
5.2. ROHC Packets and Packet Types .............................16
5.2.1. General Format of ROHC Packets .....................17
5.2.1.1. Format of the Padding Octet ...............17
5.2.1.2. Format of the Add-CID Octet ...............18
5.2.1.3. General Format of Header ..................18
5.2.2. Initialization and Refresh (IR) Packet Types .......19
5.2.2.1. ROHC IR Packet Type .......................20
5.2.2.2. ROHC IR-DYN Packet Type ...................20
5.2.3. ROHC Initial Decompressor Processing ...............21
5.2.4. ROHC Feedback ......................................22
5.2.4.1. ROHC Feedback Format ......................23
5.2.5. ROHC Segmentation ..................................25
5.2.5.1. Segmentation Usage Considerations .........25
5.2.5.2. Segmentation Protocol .....................26
5.3. General Encoding Methods ..................................27
5.3.1. Header Compression CRCs, Coverage and Polynomials ..27
5.3.1.1. 8-bit CRCs in IR and IR-DYN Headers .......27
5.3.1.2. 3-bit CRC in Compressed Headers ...........27
5.3.1.3. 7-bit CRC in Compressed Headers ...........28
5.3.1.4. 32-bit Segmentation CRC ...................28
5.3.2. Self-Describing Variable-Length Values .............29
5.4. ROHC UNCOMPRESSED -- No Compression (Profile 0x0000) .....29
5.4.1. IR Packet ..........................................30
5.4.2. Normal Packet ......................................31
5.4.3. Decompressor Operation .............................31
5.4.4. Feedback ...........................................32
6. Overview of a ROHC Profile (Informative) .......................32
7. Security Considerations ........................................33
8. IANA Considerations ............................................34
9. Acknowledgments ................................................35
10. References ....................................................35
10.1. Normative References .....................................35
10.2. Informative References ...................................35
Appendix A. CRC Algorithm ........................................371. Introduction 🌸
Okay so for lots of networks, cutting deployment and operating costs by using bandwidth better is super important 💰. Header compression over a link works because some of the info in a packet's header becomes compressible between packets from the same flow 🧠.
For links where the IP header overhead is a problem, the header can be pretty chunky 🙈. Applications carrying data within RTP [13] would have, on top of link-layer framing, an IPv4 [10] header (20 octets), a UDP [12] header (8 octets), and an RTP header (12 octets), which is 40 octets total. With IPv6 [11], the IPv6 header is 40 octets, so that's 60 octets total. Apps moving data with TCP [14] get 20 octets for the transport header, which means 40 octets total on IPv4 and 60 octets on IPv6 😭.
How much you gain depends on how big each packet's payload is 📦. For stuff like Voice-over-IP, where the coded speech payload can be as small as 15-20 octets, the gain is going to be huge 🔥. TCP flows with big payloads (like file transfers) get smaller gains than flows with tiny payloads (like app signaling, e.g., session initiation) 🎀.
More and more wireless link techs are carrying IP traffic, so header compression algorithms need to deal with what makes those techs different 🦋. Legacy schemes, like the ones defined in [16] and [17], have been shown to perform poorly over links where both loss and round-trip times are non-negligible, which happens on things like wireless links and IP tunnels 🥲.
Also, a header compression scheme should handle residual errors, which are super messy, meaning the lower layer may pass a packet with undetected bit errors to the decompressor 🙃. It should also handle loss and reordering before the compression point, and also on the link between the compression and decompression points [7] 💅.
The Robust Header Compression (ROHC) protocol provides an efficient, flexible, and future-proof header compression concept. It's designed to operate efficiently and robustly over various link technologies with different characteristics 👑.
RFC 3095 [3] defines the ROHC framework along with an initial set of compression profiles. To improve and simplify the specification, the framework and the profiles' parts have been split into separate documents 🧚. This document explicitly defines the ROHC framework, but it does not modify or update the definition of the framework specified by 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, though, is for this specification to replace RFC 3095 as the base specification for all profiles defined in the future 🌈.
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 [1]. Those words are the BCP 14 key words, so read them exactly as written 🫡.
2.1. Acronyms 💜
This section lists most 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(s).
MRRU Maximum Reconstructed Reception Unit.
MSB Most Significant Bit(s).
MSN Master Sequence Number.
NACK Negative Acknowledgment.
ROHC RObust Header Compression.2.2. ROHC Terminology ✨
okay so this part is the glossary bit, and it's lowkey where everything clicks 🫶
Context
the context of the compressor is the state it uses to compress a header 💅 and the context of the decompressor is the state it uses to decompress a header. either one, or both together, is usually just called "context" when it's clear which one is meant 🧚 it holds useful info from earlier headers in the packet flow, like static fields and possible reference values. it also describes how the flow behaves, like how the IP Identifier changes or how sequence numbers and timestamps usually go up between packets 📈
Context damage
when the decompressor's context doesn't match the compressor's, decompression can fail to rebuild the original header 💀 this can happen if the decompressor's context was never set up properly, or if packets got lost or damaged between the two ends.
packets that can't be decompressed because the contexts don't match are called lost due to context damage. packets that do come out decompressed but have errors because of mismatched contexts are called damaged due to context damage 🙈
Context repair mechanism
these are the tools for getting the contexts back in sync, 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 when things only go one way. there are also mechanisms that make an inconsistent context less likely, like repeating the same kind of info across several packets, or using CRCs to protect the context-updating info 🔥
CRC-8 validation
this is checking that a received IR or IR-DYN header hasn't been hit by bit errors, using the 8-bit CRC that's included in that IR/IR-DYN header 🎀
CRC verification
this is 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
this is when incorrect decompressed headers get delivered because of context damage. in other words, it's caused by errors in (meaning loss of or damage to) earlier header(s) or feedback 🦋
Error detection
this is error detection done by lower layers 🌸 if it isn't perfect, some residual errors will still get through.
Error propagation
this just means damage propagation or loss propagation, so it's the umbrella term 👑
ROHC profile
a ROHC profile is a compression protocol that says how to compress specific combinations of headers ✨ a profile can be tailored to a particular set of link characteristics, such as loss characteristics or reordering between compression points. ROHC profiles give the details of the header compression framework defined in this document, and each one has its own unique ROHC profile identifier [21] 🌈
when a ROHC channel gets set up, both endpoints negotiate which profiles they both support. then, whenever new contexts get initialized, a profile identifier from that agreed set is used to tie each context to one specific profile 🫶
Link
a physical transmission path that makes up a single IP hop 🧚
Loss propagation
this is when headers get lost because of errors in (meaning loss of or damage to) earlier header(s) or feedback 😩
Packet flow
a sequence of packets where the field values, and the way those values change, mean the headers can all be compressed using the same context 💜
Residual error
errors that happen during transmission and aren't caught by the 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 also optionally carry ROHC feedback information on behalf of another compressor-decompressor pair that's running on a separate ROHC channel going the opposite way. see also [5] ⭐
this document also uses the conceptual terminology from "ROHC Terminology and Channel Mapping Examples", RFC 3759 [5] 📚
3. Background (Informative) 🌸
this section gives the background on header compression, covering the core ideas and the history of how header compression schemes came to be. it also explains what motivated each scheme and what drawbacks were spotted along the way. all of that is what the ROHC framework and profiles [3] were built on, so it's super important context 🧠
3.1. Header Compression Fundamentals 💖
header compression works because there's a ton of redundancy between header fields 🤯 this happens inside the headers of a single packet, but especially between consecutive packets in the same flow. end-to-end, the full header info is needed for every packet in the flow. over a single link, though, some of that info is redundant and can be cut down, as long as it's transparently recovered at the receiving end of the link 🔥
the header can get smaller by sending first the field info that's expected to stay static for (at least most of) the lifetime of the packet flow. then you get extra compression for fields that change more dynamically, by using compression methods that suit how each field is expected to change 🦋
to make compression and decompression work, some necessary info from past packets gets kept in a context 🧚 the compressor and the decompressor each update their own contexts when certain events happen, and those events don't have to line up with each other. impairment events can cause inconsistencies in the decompressor's context (that's context damage), and that can lead to incorrect decompression 😬 so a Robust Header Compression scheme needs mechanisms that keep context damage unlikely, along with mechanisms that repair the context when it happens ✨
3.2. A Short History of Header Compression 🎀
the first header compression scheme was compressed TCP (CTCP) [15], introduced by Van Jacobson 👑 CTCP, which is 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. the CTCP compressor spots transport-level retransmissions and sends a header that updates the entire context whenever one happens. this repair mechanism doesn't need any explicit signaling between the compressor and decompressor 🙌
next came a general IP header compression scheme, IP header compression [16], which improved on CTCP a bit 💅 IP Header Compression (IPHC) can compress arbitrary IP, TCP, and UDP headers. when it compresses non-TCP headers, IPHC doesn't use delta encoding, and it's robust 🛡️ IPHC also took CTCP's repair mechanism and added negative acknowledgments, called CONTEXT_STATE messages, which speed up the repair. but this repair is still limited by the round-trip time of the link ⏳ and IPHC doesn't compress RTP headers 🙈
CRTP [17] is an RTP extension to IPHC 🎧 it squishes 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 💜
CRTP doesn't do well on lossy links with long round-trip times [20] 😭 every packet lost over the link makes decompression fail for several packets after it, because the context gets invalidated for at least one link round-trip time from the lost packet. and the big headers CRTP sends when it's updating the context waste extra bandwidth too 💀
CRTP uses a local repair mechanism called TWICE, which came from IPHC 🧩 the name comes from the observation that when the flow of compressed packets is regular, the right guess when one packet gets lost between the compression points is to apply the update in the current packet twice. TWICE really improves CRTP performance, but [20] also found that even with TWICE, CRTP still doubled the number of lost packets 😩
an enhanced version of CRTP, called eCRTP [19], aims to make CRTP more robust when there's reordering and packet loss, while keeping the protocol almost the same as CRTP 🔧 so eCRTP does offer better ways to get some degree of robustness 💖 the catch is that it comes with extra overhead, which lowers compression efficiency compared to CRTP 🥲
4. Overview of Robust Header Compression (ROHC) (Informative) 🦋
4.1. General Principles ✨
Okay so, remember how header compression works per-link? 🦋 It's possible because there's SO much redundancy between header field values inside packets, especially between consecutive packets in the same flow. To take advantage of that, there are a few essential steps to think about 💅
Step one is identifying and grouping packets into different "flows", so that packet-to-packet redundancy is maximized 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 maybe extra unique application identifiers, like the synchronization source (SSRC) in RTP [13]. The compressor and decompressor each set up a context for the packet flow and tag it with a Context Identifier (CID) that shows up in each compressed header 🎀
Step two is understanding the change patterns of the various header fields. Highkey, header fields fall into one of these classes:
INFERRED: the 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 transmit it. 🧚STATIC: these are assumed to stay constant for the whole lifetime of the packet flow, so the value is only communicated at the start. 💖STATIC-DEF: these are used to define a packet flow. Packets whose values for these fields differ are treated as belonging to different flows. They're generally compressed the same way asSTATICfields. 👑STATIC-KNOWN: these are expected to have well-known values, so the values don't need to be communicated at all. 🌸CHANGING: these are expected to vary randomly, either within a limited value set or range, or in some other manner. They're usually handled with more sophisticated methods based on a more detailed classification of their expected change patterns. 🔥
Finally, the last step is choosing the encoding method(s) to apply to different fields based on their classification. The encoding methods, combined with the identified field behavior, are the input to designing the compressed header formats. Analysing the probability distribution of the identified change patterns then helps optimize 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 against two other properties: the robustness of the encoding to losses and errors between the compressor and the 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. Let's break them down:
- Compression efficiency: how much the average header size gets 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. It doesn't lose additional packets or introduce additional errors into decompressed headers. 💅
- Compression transparency: a measure of how well the scheme keeps 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 maintaining transparency. Increasing robustness will always come at the expense of lower compression efficiency, and vice-versa. 😭 The scheme also needs to be flexible enough to minimize the impacts of the varying round-trip times and loss patterns of links where header compression will be used.
To achieve this, the header compression scheme must provide facilities for the decompressor to verify decompression and detect potential context damage, plus context recovery mechanisms such as feedback. Header compression schemes made before the ones developed by the Robust Header Compression (ROHC) WG weren't designed with those high-level objectives in mind 🙈
The ROHC WG has developed header compression solutions to meet the needs of present and future link technologies. Lots of special attention went toward the more stringent requirements that come from wireless links, but the results are equally applicable to many other link technologies 🌸
RFC 3095 [3], "RObust Header Compression (ROHC): Framework and four profiles: RTP, UDP, ESP, and uncompressed", was published in 2001 as the first output of the ROHC WG. ROHC is a general and extendable framework for header compression, and profiles can be defined on top of it for compressing different protocols' 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 [18] ⭐
Interoperability testing of RFC 3095 confirms that ROHC can meet its purposes. But implementers also said the protocol specification is complex and sometimes obscure. Most importantly, the clear distinction between framework and profiles isn't obvious in [3], which also makes developing additional profiles troublesome 💀 This document therefore aims to explicitly specify the ROHC framework, while a companion document [8] 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 [5]) 💖
- Multiplexing over a single logical channel: The ROHC channel provides a mechanism to identify a context within the general ROHC packet format. The CID lets a logical channel that supports ROHC transport multiple header-compressed flows, while a channel can still be dedicated to one single packet flow without any CID overhead. More specifically, ROHC uses a distinct context identifier space per logical channel, and the context identifier can be omitted for one of the flows over the ROHC channel when configured to use a small CID space. 🎀
- Establishment of channel parameters: A link layer defining 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 puts restrictions on the use of a number of identifiers that are common to all ROHC profiles. Identifiers without restrictions, meaning the ones not defined by this document, are available to each profile. The identifier is part of each compressed header, which makes it possible for the link supporting the ROHC channel to 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 [3], the channel between the compressor and decompressor is required to maintain in-order delivery of the packets. That means 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 [7]. Reordering before the compression point is handled, though: these profiles make no assumption that the compressor will receive packets in order. 🙈
- For the ROHCv2 profiles specified in [8], their definitions assume the decompressor can receive packets out-of-order, i.e., not in the same order that 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 can still happen before packets reach the compressor, so there's no assumption that the compressor gets 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 unchanging 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 be either derived directly from one of the fields of the protocol being compressed (e.g., the RTP SN [8]), or it can be created and maintained by the compressor (e.g., the MSN for compression of UDP in profile 0x0102 [8] or the MSN in ROHC-TCP [9]) 🧚
4.6. Static and Dynamic Parts of a Context 🧚
okay so a compression context can be split into two conceptual parts, the static context and the dynamic context 💖. The split depends on how the fields being compressed behave. ✨
The static part holds everything needed to compress and decompress the fields whose change behavior is 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 bit 💅. It defines the parts that every ROHC profile shares, which is the framework 🎀. The framework lays out the requirements and behavior of the ROHC channel, including how multiple compressed packet flows get handled over that same channel 🫶.
It also specifies the encoding methods used in packet formats that all profiles share 🌈. Profiles are allowed to reuse these encodings for fields in their profile-specific parts of a packet format, so nobody has to redefine them 👑.
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 decompressor both keep so they can compress or decompress the headers of packets in that flow correctly ✨. Each context gets identified by a CID 🎀.
a context counts as new in two situations. The first is when a CID gets associated with a profile for the first time since the ROHC channel was created 🌸. The second is when a CID gets associated with a different profile than the one already in the context, and that association comes from receiving an IR packet (this doesn't apply to IR-DYN) 😭.
conceptually, context information lives in a table 🍓. That table is indexed by the CID, which travels along with compressed headers and feedback information 💅.
the CID space can be 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 through negotiation, before any compressed packet may be sent over the ROHC channel 🔥.
the CID space is separate for each channel 🙈. CID 3 over channel A and CID 3 over channel B do not refer to the same context, even when channels A and B connect the exact same nodes 💀. CIDs for any pair of ROHC channels are unrelated to each other. 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 set of parameters. Some of them form part of the established channel state, and others form part of 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 offered by the link layer (see also [4], which describes an option for negotiating ROHC parameters for PPP) 🌈. Here's an abstract look at some of that channel state 💜:
LARGE_CIDS: a Boolean 🌸. If it's false, the small CID representation gets used, which is 0 octets or 1 prefix octet and covers CID 0 to 15 🍓. If it's true, the large CID representation gets used, which is 1 or 2 embedded CID octets and covers CID 0 to 16383 🦋. See also 5.1.1 and 5.2.1.3.MAX_CID: a non-negative integer, and it's the highest CID number the compressor is allowed to use 👑. Note that this parameter isn't tied toLARGE_CIDS, butLARGE_CIDSeffectively limits it further 💅. This value is the decompressor agreeing that it has enough memory to hold at least MAX_CID+1 contexts 🫶. The decompressor MUST keep established contexts within that space until either the CID gets reused for a new context, or the channel gets taken down ✨.PROFILES: a set of non-negative integers, where each integer names a profile supported by both the compressor and the decompressor 🔥. A profile is identified by a 16-bit value. The 8 LSB bits show the actual profile, and the 8 MSB bits show the variant of that profile 😭. The ROHC compressed header format only identifies the profile using those 8 LSB bits 🙈. So if several variants of the same profile are available on a ROHC channel, thePROFILESset after negotiation MUST NOT include more than one variant of that profile 💀. The compressor MUST NOT compress using a profile that isn't inPROFILES🚫.FEEDBACK_FOR: an optional reference to a ROHC channel going the opposite direction between the same compression endpoints 🌸. When it's provided, it says which other ROHC channel any feedback sent on this channel is about (see [5]) 🧚.MRRU: a non-negative integer that stands for Maximum Reconstructed Reception Unit 🍓. It's the size, in octets, of the largest reconstructed unit the decompressor is expected to reassemble from segments (see Section 5.2.5) 💜. That size includes the segmentation CRC 🎀. IfMRRUis negotiated to be 0, segmentation MUST NOT be used on the channel, and the decompressor MUST discard any received segments 😭.
5.1.3. Persistence of Decompressor Contexts 💾
as part of the negotiated channel parameters, the compressor and decompressor agree through the MAX_CID parameter on the highest context identification (CID) number that will be used 🌈. By agreeing on MAX_CID, the decompressor also agrees to provide memory to hold at least MAX_CID+1 contexts 🫶. An established context with a CID inside that negotiated space SHOULD be kept by the decompressor until the CID gets reused, or until the channel is taken down or renegotiated 💖.
5.2. ROHC Packets and Packet Types 📦
this section uses the following conventions in its diagrams when showing ROHC packet types, formats, and fields 🎀:
- colons
:mean that the part is optional 💅. - slashes
/mean variable length 🦋.
the ROHC packet type indication scheme was designed to provide optional padding, a feedback packet type, an optional Add-CID octet (which carries 4 bits of CID), and a simple segmentation and reassembly mechanism 🔥. These 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 :
--- --- --- --- --- --- --- ---here's the breakdown 💖:
- Padding: any number of padding octets, zero or more 🫶. Each one follows the format in Section 5.2.1.1 ✨.
- Feedback: any number of feedback elements, zero or more 🔥. Each one follows the format 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) 👑. A ROHC packet can have at most one Header, but the Header can also be left out, if the packet only carries Feedback 😭.
- Payload: zero or more octets of payload from the uncompressed packet 🍓. It starts at the first octet after the last header that the current profile can compress 💅.
At least one of Feedback or Header MUST be present 💀.
5.2.1.1. Format of the Padding Octet 🫧
the padding octet looks like this 🌸:
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 🎀
the Add-CID octet looks like this 💜:
0 1 2 3 4 5 6 7
+---+---+---+---+---+---+---+---+
| 1 1 1 0 | CID |
+---+---+---+---+---+---+---+---+CID: 0x1 through 0xF means CIDs 1 through 15 🌈.
Note: The Padding octet looks like an Add-CID octet for CID 0 🧚. Yep, that's why the Note above matters 🙈.
5.2.1.3. General Format of Header 🧩
every ROHC packet type uses this 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: read according to the packet type indication and the CID information, as each profile defines it 🫶.
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 uses a small CID space 🌸:
- If an Add-CID comes right before the packet type indication, the packet has the CID from that Add-CID. Otherwise it has CID 0 🍓.
- A small CID with the value 0 is represented with zero bits, so a flow on 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 with 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 uses a large CID space 👑:
- The large CID is always present and gets encoded with the scheme in 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 carry a profile identifier, and that identifier decides how the rest of the header gets interpreted 🧚. They also link a profile to a context 🌟. The stored profile parameter then decides the syntax and semantics of the packet type identifiers and packet types used with that 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 named in the Profile field says otherwise ✨.
5.2.2.1. ROHC IR Packet Type ✨
okay so the IR header is the one that links a CID to a profile 🎀 and usually sets up the context from scratch. it can also refresh all (or parts of) the context too 💖. here's the general format 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 🧚 It gets interpreted according to the profile named in the Profile field of the IR header.Profile: the profile associated with the CID 💜 In the IR header, the profile identifier gets shortened to the 8 least significant bits (see Section 5.1.2).CRC: an 8-bit CRC (see Section 5.3.1.1) 🔥Profile specific information: the content of this part is defined by each individual profile. It's read according to whatever the Profile field says 💅
5.2.2.2. ROHC IR-DYN Packet Type 🦋
the IR-DYN header is kind of the opposite vibe, bestie 🙈. it can NEVER initialize a context that hasn't been initialized yet. BUT it can redefine which profile goes with a context, as long as the profile in the IR-DYN header allows that. so this packet type is also reserved at the framework level 👑. the IR-DYN header usually also initializes or refreshes parts of a context. here's the general format for IR-DYN Header:
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 🌸 It's abbreviated the same way as in IR packets.CRC: an 8-bit CRC (see Section 5.3.1.1) ✨Profile specific information: defined by the individual profiles, and read according to the profile named in the Profile field 🫶
5.2.3. ROHC Initial Decompressor Processing
okay so at the start, every context is in no context state 🥺. that means any packet pointing at a non-initialized context can't be decompressed by the decompressor, UNLESS the packet has enough info on the static fields to make it work 🧠.
when the decompressor gets an IR packet, the profile named in that packet decides how it gets handled:
- 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, that profile's logic decides what feedback (if any) gets sent. if no profile is noted in the context, the feedback logic is up to the implementation. still, it may be suitable to take no further actions, since any part of the IR header covered by the CRC could've caused the failure 💀
when the decompressor gets an IR-DYN packet, the profile named in that packet decides how it gets handled too:
- if the 8-bit CRC fails to verify the integrity of the header, the packet MUST NOT be decompressed and delivered to upper layers 😭. same deal as above: the profile logic in the context decides any feedback, or the implementation does if no profile is noted. it may be suitable to take no further actions, since 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 (as long as the 8-bit CRC verified it) decides what feedback, if any, gets sent.
if a parsing error happens for any packet type, the decompressor MUST discard the packet without further processing 🗑️. for example, a CID field shows up in the compressed header when the large CID space is used for the ROHC channel, and that field is coded with the self-describing variable-length encoding of Section 5.3.2. if the field starts with 110 or 111, that's a parsing error for the decompressor, because this field must not be encoded with a size larger than 2 octets 🙈.
it is RECOMMENDED that profiles disallow the decompressor from attempting decompression for packets that only carry a 3-bit CRC, after it has invalidated some or all of the entire dynamic context. this holds until a packet with enough info on the dynamic fields is received, decompressed, and successfully verified by a 7- or 8-bit CRC 🚨
5.2.4. ROHC Feedback 💌
feedback carries info from the decompressor back to the compressor 🔁. feedback can be sent over a ROHC channel that goes in the same direction as the feedback.
the general ROHC packet format lets feedback get transported using interspersion or piggybacking (see [5]), or a combo of both, over a ROHC channel. this works thanks to these properties:
- Reserved packet type: a feedback packet type is reserved at the framework level 🎀. it can carry variable-length feedback info.
- CID information: the feedback sent on a particular channel gets passed to, and interpreted by, the compressor that's associated with feedback on that channel. so each feedback element contains CID info from the channel it's being sent for 💖. the ROHC feedback scheme requires that a channel carries feedback to at most one compressor 👑. how a compressor gets associated with a channel's feedback is outside the scope of this specification (see also [5]).
- Length information: you can figure out the length of a feedback element by checking the first few octets of the feedback 📏. this makes piggybacking possible, and also lets you concatenate more than one feedback element in a packet ✨. the length info decouples the decompressor from its same-side compressor, since the decompressor can pull the feedback info out of the compressed header without parsing its content and hand it over 🧚.
the association between compressor-decompressor pairs that operate in opposite directions (for exchanging piggyback and/or interspersed feedback) SHOULD be maintained for the whole lifetime of the ROHC channel 🫶. otherwise, it is RECOMMENDED that the compressor be notified if the feedback channel is no longer available 🚨. then the compressor SHOULD 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 🔄.
5.2.4.1. ROHC Feedback Format 🍓
ROHC defines three categories of feedback messages: acknowledgment (ACK), negative ACK (NACK), and NACK for the entire context (STATIC-NACK) 🌈. other types of info may be defined in profile-specific feedback info.
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 is made of one or more concatenated feedback elements, and each feedback element looks like this:
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 (5.3.2 encoding) / 1-2 octets if for large CIDs
: :
+---+---+---+---+---+---+---+---+
/ FEEDBACK data / variable length
+---+---+---+---+---+---+---+---+Code: 0 means a Size octet is present 🧾. 1-7 means the size of the feedback data field, in octets.Size: the size of the feedback data field, in octets 📐.FEEDBACK data: either FEEDBACK-1 or FEEDBACK-2 (see below) 💜.
CID information in a feedback element tells you which context the feedback is for 🎯. the LARGE_CIDS parameter that decides whether a large CID is present gets 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 these 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 🦋Acktypevalue 3 is reserved (MUST NOT be used. Otherwise unparseable.) 🚫
5.2.5. ROHC Segmentation 🧩
ROHC defines a simple segmentation protocol 🍬. the compressor may perform segmentation, e.g., to fit packets that are larger than a specific size configured for the channel 📦.
5.2.5.1. Segmentation Usage Considerations ✨
Okay bestie, real talk: the ROHC segmentation protocol is not particularly efficient 🐢 It is not meant to replace link layer segmentation functions, so those SHOULD be used whenever they're available and efficient for the task at hand 💅
The ROHC segmentation protocol was designed assuming in-order delivery of packets between the compressor and the decompressor. It only uses a CRC for error detection and has no sequence numbers 🧐 So if in-order delivery can't be guaranteed, ROHC segmentation MUST NOT be used 🚫
It also assumes that all segments of a ROHC packet for one context arrive without interference from other ROHC packets on the channel, including packets for a different context 🫣 Because of that, segments don't carry CID information. That means 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 set, it indicates that this is the last segment of a reconstructed unit.
Padding and/or Feedback may precede 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 is received, the decompressor reassembles it, along with any non-final segments that immediately came before it, into a single reconstructed unit. The segments get put together in the order they were received 🪡 All 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 is aborted, and the decompressor MUST discard the non-final segments received so far on this channel 😭
Here's what the reconstructed unit looks like:
0 1 2 3 4 5 6 7
+---+---+---+---+---+---+---+---+
/ Header / (see Section 5.2.1)
+---+---+---+---+---+---+---+---+
: Payload : (see Section 5.2.1)
+---+---+---+---+---+---+---+---+
/ CRC / 4 octets
+---+---+---+---+---+---+---+---+CRC: 32-bit CRC computed using the polynomial of Section 5.3.1.4.
If the reconstructed unit is 4 octets or less, if the CRC fails, or if it is 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 reconstructed unit can be further processed ✅
5.3. General Encoding Methods 🌈
5.3.1. Header Compression CRCs, Coverage and Polynomials 🧮
This section explains how to calculate the CRCs used by ROHC 🤓 For all CRCs, the algorithm is the same as the one used in [2], defined in Appendix A of this document. The only difference is the polynomials, which are specified in the subsequent sections.
5.3.1.1. 8-bit CRCs in IR and IR-DYN Headers 🦋
The coverage for the 8-bit CRC in the IR and IR-DYN headers depends on the profile 💫 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 are not part of 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 doesn't cover only and entirely the original uncompressed header 🙈 So it doesn't let the decompressor verify a decompression attempt, or verify the correctness of the entire decompressor context. When it succeeds, though, it does give enough robustness for the decompressor to update its context with the information 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, like this 🧾
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 point of the 3-bit CRC is to let the decompressor verify the outcome of a decompression attempt for small compressed headers. It also helps detect context damage based on aggregated probability over a number of decompression attempts 📉 It's too weak to give enough success guarantees from decompressing one single header, though 😬 So compressed headers carrying a 3-bit CRC are normally not suitable for context repairs at the decompressor. 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 7-bit CRC lets the decompressor verify the outcome of a decompression attempt for a larger compressed header. It also gives enough protection to validate a context repair at the decompressor 🛡️ It's strong enough to assume a repair succeeded 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. It's calculated over the segmented unit, which means 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^32.The 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 wildly 🎢 To keep transfers small, a variable number of octets is used to encode them. The first few bits of the first octet determine how many octets get 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 lets you send IP packets without compressing them 📦 It can be used for any packet with no compression profile available in the set of profiles supported by the ROHC channel, or for any packet where 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 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 this 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: 0x00CRC: 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. Neither does it cover any preceding Padding or Feedback, nor the Payload 🔐
For the IR packet, the Payload has this format:
--- --- --- --- --- --- --- ---
: : (optional)
/ IP packet / variable length
: :
--- --- --- --- --- --- --- ---IP packet: An uncompressed IP packet may be included in the IR packet. The decompressor determines if the IP packet is present by considering 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
| |
+---+---+---+---+---+---+---+---+The first octet of the IP packet starts with the bit pattern 0100 (IPv4) or 0110 (IPv6). That 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 precedes 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 as any other ROHC packet does, preceding the combined Header/Payload 🫧
5.4.3. Decompressor Operation
okay so when an IR packet shows up, the decompressor checks its header first using the 8-bit CRC 🔍
- if the header fails the check, the decompressor MUST NOT pass the IP packet up to upper layers. no exceptions, bestie 🙅♀️
- if the header passes, the decompressor does three things:
- it sets up the context, but only if it doesn't already have a valid context for that CID tied to the profile
- it hands the IP packet up to upper layers, if there is one
- it MAY send an ACK 💌
if any other packet arrives while the decompressor has no context, it just gets tossed without further action. bye 👋
when a Normal packet arrives and the decompressor does have a valid context, the IP packet gets pulled out and delivered to upper layers ✨
5.4.4. Feedback
the only 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). so FEEDBACK-2 isn't defined for Profile 0x0000 at all, not even a little 🙈
6. Overview of a ROHC Profile (Informative)
okay, the ROHC protocol has two halves: a framework part and a profile part 🧚 the framework holds the stuff every profile shares, and the profile is where the compression algorithm and its own packet formats live 💜
Section 5 is where the framework details live. this section is just an informative tour of what a profile spec is made of 🦋 the normative spec for individual profiles is out of scope for this document, so don't look for it here 🫶
a ROHC profile defines the pieces that build the compression protocol. a profile has:
Packet formats:
- Bits-on-the-wire: the profile lays out the bits for the profile-specific packet types it defines, plus the profile-specific parts of the packet types every profile shares (like IR and IR-DYN) 🎀
- Field encodings: bits and groups of bits from the packet layout, called Compressed fields, are the output of an encoding method for that field inside a specific packet format. the profile defines those encoding methods 🌸
- Updating properties: profile-specific packet formats can update the decompressor's state, and they can do it in different ways. the profile says how each profile-specific field, or each whole profile-specific packet type, updates the decompressor context 🔥
- Verification: packets that update the decompressor state get verified, so the context doesn't get messed up. the profile defines the checks used to verify a packet's decompression 🧐
Context management:
- Robustness logic: packets can get lost or reordered between compressor and decompressor. the profile defines mechanisms to shrink the impact of that and stop damage from spreading 🛡️
- Repair mechanism: even with robustness logic, impairments 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. Security Considerations
okay this section is serious but still iconic 💀 because encryption gets rid of the redundancy that header compression feeds on, there's some temptation to skip encrypting headers just so things work on low-bandwidth links 😬
a malfunctioning or malicious header compressor could make the header decompressor rebuild packets that don't match the originals, while still having valid headers and maybe valid transport checksums. that kind of corruption can be caught with end-to-end authentication and integrity mechanisms, and compression doesn't touch those 🔐 plus, ROHC uses an internal checksum to verify rebuilt headers, which makes it less likely that a wrong decompressed header goes unnoticed 👀
denial-of-service attacks are possible if an intruder can slip bogus IR, IR-DYN, or FEEDBACK packets onto the link, for example, and make compression efficiency drop 📉 but honestly, an intruder who can inject arbitrary packets at the link layer like that brings security problems that make the header compression ones look tiny 😭
8. IANA Considerations
the IANA registry for "RObust Header Compression (ROHC) Profile Identifiers" [21] was created by RFC 3095 [3] 🗂️ here's the assignment policy, as RFC 3095 lays it out:
the ROHC profile identifier is a non-negative integer. in lots of negotiation protocols it's represented as a 16-bit value. because of how ROHC packets abbreviate the profile identifier, the 8 least significant bits have special meaning. two profile identifiers with the same 8 LSBs should only be assigned if the higher-numbered one is meant to supersede the lower-numbered one. to make that relationship obvious, profile identifiers should be written in hexadecimal, like 0x1234, which would for example supersede 0x0A34 💜
following the policies in [22], the IANA policy for assigning new profile identifier values shall be Specification Required. that means the values and their meanings must be documented in an RFC or in some other permanent, readily available reference, in enough detail that independent implementations can interoperate 📚 within the 8 LSBs, the range 0 to 127 is reserved for IETF standard-track specifications, and the range 128 to 254 is open to other specifications that meet this requirement, like Informational RFCs 🌈 the LSB value 255 is reserved for future extensibility of this specification ✨
these profile identifiers have been allocated so far:
Profile Identifier Usage Reference
------------------ ---------------------- ---------
0x0000 ROHC uncompressed RFC 4995
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 4019new profiles will need new identifiers assigned by IANA, but this document doesn't require any extra IANA action 🫶
9. Acknowledgments
the authors want to thank everyone who worked on earlier ROHC stuff, and especially the authors of RFC 3095 [3], which is the technical basis for this document 🙌 thanks also to the people who contributed to the RFC 3095 corrections and clarifications document [6], since technical content from it was folded in where it applied 💖 committed WG document reviewers Carl Knutsson and Biplab Sarkar reviewed the document during working group last-call, so they get big flowers 🌸
10. References
10.1. Normative References
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
10.2. Informative References
[2] Simpson, W., "PPP in HDLC-like Framing", STD 51, RFC 1662, July 1994.
[3] 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.
[4] Bormann, C., "Robust Header Compression (ROHC) over PPP", RFC 3241, April 2002.
[5] Jonsson, L-E., "RObust Header Compression (ROHC): Terminology and Channel Mapping Examples", RFC 3759, April 2004.
[6] Jonsson, L-E., Sandlund, K., Pelletier, G., and P. Kremer, "RObust Header Compression (ROHC): Corrections and Clarifications to RFC 3095", RFC 4815, February 2007.
[7] Pelletier, G., Jonsson, L-E., and K. Sandlund, "RObust Header Compression (ROHC): ROHC over Channels That Can Reorder Packets", RFC 4224, January 2006.
[8] Pelletier, G. and K. Sandlund, "RObust Header Compression Version 2 (ROHCv2): Profiles for RTP, UDP, IP, ESP, and UDP Lite", Work in Progress, September 2006.
[9] 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.
[10] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981.
[11] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998.
[12] Postel, J., "User Datagram Protocol", STD 6, RFC 768, August 1980.
[13] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, July 2003.
[14] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981.
[15] Jacobson, V., "Compressing TCP/IP headers for low-speed serial links", RFC 1144, February 1990.
[16] Degermark, M., Nordgren, B., and S. Pink, "IP Header Compression", RFC 2507, February 1999.
[17] Casner, S. and V. Jacobson, "Compressing IP/UDP/RTP Headers for Low-Speed Serial Links", RFC 2508, February 1999.
[18] Degermark, M., "Requirements for robust IP/UDP/RTP header compression", RFC 3096, July 2001.
[19] 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.
[20] Degermark, M., Hannu, H., Jonsson, L.E., and K. Svanbro, "Evaluation of CRTP Performance over Cellular Radio Networks", IEEE Personal Communication Magazine, Volume 7, number 4, pp. 20-25, August 2000.
[21] IANA registry, "RObust Header Compression (ROHC) Profile Identifiers", http://www.iana.org/assignments/rohc-pro-ids
[22] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
Appendix A. CRC Algorithm ✨
okay so this appendix is a little Perl demo from Carsten Bormann (2001-08-02) 💻 It shows off the four CRC types used in RFC 3095, the robust header compression spec. You type your data in hex, press Control+D, and it spits out the CRCs 🦋
#!/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 💌
Lars-Erik Jonsson
Optand 737
SE-831 92 Ostersund, Sweden
Phone: +46 70 365 20 58
EMail: lars-erik@lejonsson.com
Ghyslain Pelletier
Ericsson AB
Box 920
SE-971 28 Lulea, Sweden
Phone: +46 8 404 29 43
Fax: +46 920 996 21
EMail: ghyslain.pelletier@ericsson.com
Kristofer Sandlund
Ericsson AB
Box 920
SE-971 28 Lulea, Sweden
Phone: +46 8 404 41 58
Fax: +46 920 996 21
EMail: kristofer.sandlund@ericsson.comFull Copyright Statement 🎀
Copyright (C) The IETF Trust (2007) 🌸
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property 🧚
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
Acknowledgement 💜
Funding for the RFC Editor function is currently provided by the Internet Society. 🫶
📦 where this page comes from
- ietf: rfc4995 2007-07
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms