RFC 4362

RObust Header Compression (ROHC): A Link-Layer Assisted Profile for IP/UDP/RTP

📅 published January 2006, from ietf

Hiii bestie 💖 so this is RFC 4362, and it's a Standards Track doc from the Network Working Group, written by L-E. Jonsson, G. Pelletier and K. Sandlund from Ericsson. It was published in January 2006 🎀. It obsoletes RFC 3242, which means 3242 is officially retired and this one takes its place ✨. Its main job is defining a ROHC profile for IP/UDP/RTP packets 🦋.

Status of This Memo

Okay so this doc is an Internet standards track protocol for the Internet community 💅. It's asking for discussion and suggestions for improvements 🫶. If you want the current standardization state and status of this protocol, check the current edition of the "Internet Official Protocol Standards" (STD 1) 📚. Distribution of this memo is unlimited 🌈.

Copyright (C) The Internet Society (2006). 🎀

Abstract

Okay the big picture: this doc defines a ROHC (Robust Header Compression) profile for compressing IP/UDP/RTP (Internet Protocol/User Datagram Protocol/Real-Time Transport Protocol) packets 🔥. It uses stuff the lower layers already provide so it can fully get rid of the header for most packets when things are running optimally, which is iconic for efficiency 👑. The profile is built as an extension of the ROHC RTP profile ✨. It adds the extra mechanisms ROHC needs, sets out requirements on the assisting layer so transparency is guaranteed 🫶, and describes general compression and decompression logic for using the header-free packet format 💅. This document replaces RFC 3242, which it obsoletes 🦋.

Table of Contents

   1. Introduction ....................................................2
      1.1. Differences from RFC 3242 ..................................5
   2. Terminology .....................................................5
   3. Overview of the Link-Layer Assisted Profile .....................6
      3.1. Providing Packet Type Identification .......................7
      3.2. Replacing the Sequence Number ..............................7
      3.3. CRC Replacement ............................................8
      3.4. Applicability of This Profile ..............................8
   4. Additions and Exceptions Compared to ROHC RTP ...................9
      4.1. Additional Packet Types ....................................9
           4.1.1. No-Header Packet (NHP) ..............................9
           4.1.2. Context Synchronization Packet (CSP) ................9
           4.1.3. Context Check Packet (CCP) .........................11
      4.2. Interfaces Towards the Assisting Layer ....................12
           4.2.1. Interface, Compressor to Assisting Layer ...........13
           4.2.2. Interface, Assisting Layer to Decompressor .........13
      4.3. Optimistic Approach Agreement .............................14
      4.4. Fast Context Initialization, IR Redefinition ..............15
      4.5. Feedback Option, CV-REQUEST ...............................16
      4.6. Periodic Context Verification .............................16
      4.7. Use of Context Identifier .................................16
   5. Implementation Issues ..........................................17
      5.1. Implementation Parameters and Signals .....................17
           5.1.1. Implementation Parameters at the Compressor ........17
           5.1.2. Implementation Parameters at the Decompressor ......19
      5.2. Implementation over Various Link Technologies .............19
   6. IANA Considerations ............................................20
   7. Security Considerations ........................................20
   8. Acknowledgements ...............................................20
   9. References .....................................................20
      9.1. Normative References ......................................20
      9.2. Informative References ....................................21

1. Introduction ✨

Okay so header compression is a technique for squishing the header info of a packet on a per-hop basis 🧚. It's basically a flex that uses the redundancy inside each packet and between packets in the same stream 💜. Over the years, a bunch of protocols [VJHC, IPHC] were built to compress network and transport headers [IPv4, IPv6, UDP, TCP], and they were super successful on wired bottleneck links like modem connections over phone networks 📞. On top of IP, UDP and TCP compression, there's also Compressed RTP [CRTP], which goes even harder for real-time traffic using the Real-Time Transport Protocol [RTP] 🔥.

Here's the tea 🫖: all of those schemes were designed assuming wired links, because that's what link characteristics were traditionally based on 😬. But now there are more and more wireless links in Internet paths, so those assumptions are no longer generally valid 💀. On wireless, especially wide-coverage cellular networks, relatively high error rates are tolerated so radio resources can be used efficiently 📶. Real-time traffic cares more about delay than errors, so those conditions are going to be the norm over things like 3rd generation cellular links, which means header compression has to be able to handle packet loss 🙈. The older schemes, especially CRTP on real-time traffic, have been shown to seriously degrade performance when error rates are high [CRTPC] 😭. That problem is literally why the RObust Header Compression (ROHC) WG was created in the IETF 🎀.

The ROHC WG built a header compression framework that profiles can sit on top of, for different protocol sets or different compression strategies 🌸. CRTP has limited packet-loss robustness, and the cellular industry really wanted an efficient way to carry voice over IP over wireless 🎤. So ROHC's main focus has been compressing IP/UDP/RTP headers, which are pretty chunky compared to the payloads they often carry 🍓.

ROHC RTP is now a super efficient, robust and capable compression scheme 👑. It can squish the headers down to a total size of just one octet 🤏. Transparency is guaranteed to an extremely great extent too, even when residual bit errors are present in compressed headers delivered to the decompressor 🫶. The RTP compression requirements [RTP-REQ], which the WG set before and during development, have been fulfilled ✅.

As I said, 3rd generation cellular systems, where IP will be used end-to-end, were a big driving force behind ROHC RTP 📱. The scheme was also designed to suit new cellular air interfaces like WCDMA, so it can even run speech services with spectrum efficiency that's barely lower than existing one-service circuit switched solutions [VTC2000] 🌈. But other air interfaces (like those based on GSM and IS-95) will also be used in all-IP networks, and that brings new header compression issues 🤔. These older air interfaces are less flexible, with radio bearers optimized for specific payload sizes 📦. That means you can't add even a single octet of header without jumping to the next fixed packet size the link supports, and that's obviously very costly 😩. For the already deployed speech vocoders, spectrum efficiency over these links ends up low compared to existing circuit-switched solutions 📉. To get high spectrum efficiency overall with any application, more flexible air interfaces need to be deployed, and then ROHC RTP will perform excellently, as shown for WCDMA [MOMUC01] 💅. But for deployment reasons, it's also important to have a suitable header compression strategy for existing vocoders and air interfaces, like GERAN and CDMA2000, with minimal effects on spectral efficiency 🫶.

This document describes a link-layer-assisted ROHC RTP profile 🦋. It was originally defined by [LLA] and extends ROHC RTP (profile 0x0001) [ROHC], and it's compliant with the ROHC 0-byte requirements [0B-REQ] 💖. The point of this profile is to provide a header-free packet format that, for certain application behavior, can replace most of the 1-octet header ROHC RTP packets during normal U/O-mode operation 🌸. It's still fully transparent and follows all the requirements of ROHC RTP [RTP-REQ] ✨. For other applications, compression is done just like normal ROHC RTP 🧚.

To completely eliminate the compressed header, everything the 1-octet header normally does has to be handled some other way 🤯. That usually means leaning on functionality from the lower layers and accepting less efficiency for the less frequent, larger compressed headers 🎀. That's not a contradiction, because the reason for eliminating the last octet for most packets isn't overall efficiency in general 🙈. The purpose of this profile is to efficiently match existing applications to existing link technologies, not to be efficient in general 💅. The extra complexity this profile brings, even though it's minimized by a tight integration with existing ROHC functionality, means it should only be used to optimize the performance of specific applications over specific links ⚠️.

When implementing this profile over various link technologies, you have to take care that all the functionality needed is provided by ROHC and the lower layers together 🧩. So additional documents should specify how to put this profile on top of various link technologies 📚.

The profile in this document was originally specified by RFC 3242 [LLA]. To fix one technical flaw and clarify one implementation issue, this document was issued to replace RFC 3242, which is now obsolete 🦋.

1.1. Differences from RFC 3242 💅

This section gives a quick rundown of how this document differs from RFC 3242 🎀. Acronyms and terminology are in Section 2 📖.

The CSP packet format, as defined in [LLA], was found to be non-interoperable when carrying an RHP header with a 3-bit or 7-bit CRC 😬. The issue happens because the compressor drops the payload, and the decompressor is supposed to use the payload length to infer certain fields in the uncompressed header 🙈. Those fields are the IPv4 total length, the IPv6 payload length, the UDP length, and the IPv4 header checksum field (all INFERRED fields in [ROHC]) 🔍. To fix this flaw, the CSP packet has to carry info about the payload length of the RHP packet 🛠️. So the RTP payload length has been added to the CSP packet ✨.

This document also clears up some unclear referencing in RFC 3242 🫶. Section 4.1.3 of [LLA] says that upon CRC failure, the actions of [ROHC], Section 5.3.2.2.3 MUST be taken 🚨. That section says detection of SN wraparound and local repair must be performed, but neither step applies when the failing packet is a CCP 😭. So upon CRC failure, the actions to take are the ones in Section 5.3.2.2.3, but steps a-d only 🎯.

2. Terminology ✨

okay so the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document get read the way [RFC2119] describes. these words are doing a lot of work, bestie 🫶

CCP    Context Check Packet
CRC    Cyclic Redundancy Check
CSP    Context Synchronization Packet
LLA    Link Layer Assisted ROHC RTP profile
NHP    No Header Packet
ROHC   RObust Header Compression
RHP    ROHC Header Packet (a non-NHP packet; i.e., RRP, CSP, or CCP)
RRP    ROHC RTP Packet as defined in [ROHC, profile 0x0001]

Assisting layer 🧚

"Assisting layer" means any entity that implements the interface to ROHC (Section 4.2). it could be, for example, a sub-layer that adapts the ROHC implementation and the physical link layer. this layer is assumed to know about the physical layer synchronization. 💖

Compressing side 🎀

"Compressing side" is the combo of the header compressor (running the LLA profile) and its assisting layer. a team, basically 👯‍♀️

Lower layers 🌸

"Lower layers" refers to everything sitting below ROHC in the protocol stack, including the assisting layer. 🍓

ROHC RTP 💜

"ROHC RTP" is the IP/UDP/RTP profile defined in [ROHC].

okay the ROHC IP/UDP/RTP profile in [LLA], updated by this document, is profile 0x0005 (hex). it was built for channels that are tuned to specific payload sizes, which means they can't handle header info nicely when the payload is sent together with those perfect sizes. it's giving optimization era 🦋

the LLA profile extends the ROCH RTP profile, so it inherits everything from it. it also adds some extra features and an interface from the ROHC component to an assisting lower layer. ✨

                 +---------------------------------------+
                 |                                       |
    The LLA      |    ROHC RTP,                          |
    profile      |    Profile #1       +-----------------+
                 |                     |  LLA Additions  |
                 +---------------------+-----------------+

by putting extra requirements on the lower layers (compared to [ROHC]), it becomes possible to infer the info needed to keep header compression robust and transparent, even though the headers are totally gone for most of the time. the magic is in the inference 🪄

basically, this profile swaps the smallest and most common ROHC U/O-mode header for a no-header format. the header's job has to be handled some other way. 💅

   Smallest header in                 Smallest header in
   ROHC RTP (profile #1)              LLA (profile #5)
 +--+--+--+--+--+--+--+--+              ++
 |        1 octet        |  ----->      ||  No Header
 +--+--+--+--+--+--+--+--+              ++
             |
             |                        Header field functionality
             +------------------->    provided by other means

the fields in ROHC RTP headers for U/O-mode PT0 are the packet type identifier, the sequence number, and the CRC. the next sections go into how each of these gets replaced for NHP. 🔥

3.1. Providing Packet Type Identification

every ROHC header carries a packet type identifier, which tells the decompressor how to read the header. in 0-byte header compression, this is a function that must be provided by some means. ROHC RTP packets with compressed headers can still be recognized thanks to the packet type identifier, but a mechanism is needed to tell apart packets that have a header from packets that don't. so this function MUST be provided by the assisting layer, one way or another. no skipping this one bestie 🙈

3.2. Replacing the Sequence Number

from the sending application, the RTP sequence number goes up by one for each packet sent. the sequence number exists to deal with packet reordering and packet loss. if reordering or loss already happened before the transmission point, the compressing side can easily avoid trouble, if needed, by not allowing a header-free packet to be used. ✨

but at the transmission point, loss or reordering over the link can't be predicted or covered in advance. so for NHP, the assisting layer MUST guarantee in-order delivery over the link (which [ROHC] already assumes), and on the receiving side it MUST provide an indication for each packet loss over the link. this is basically the same principle the VJ header compression [VJHC] relies on. it's a classic, iconic move 💜

also, guaranteeing in-order delivery and packet loss indication over the link doesn't just make it possible to infer the sequence number info. it also replaces the main job of the CRC, which normally handles errors from link losses and bit errors in the compressed sequence number. 🧚

3.3. CRC Replacement

every context-updating RRP packet carries a CRC calculated over the uncompressed header. the decompressor uses the CRC to check that the updated context is correct. in U/O-mode, this verification does three things:

  1. Detection of longer losses than can be covered by the sequence number LSBs.
  2. Protection against failures caused by residual bit errors in compressed headers.
  3. Protection against faulty implementations and other causes of error.

this profile defines an NHP packet without this CRC, so when an NHP stands in for a context-updating packet, these purposes have to be covered some other way. detecting long losses (1) is already handled, because the assisting layer MUST provide an indication of all packet losses. plus, NHP has one big advantage over RHP packets: residual bit errors (2) can't damage a header that isn't even sent. 😭 the absolute main character move

so it's reasonable to assume compression and decompression transparency can be assured with high confidence, even without a CRC on header-free packets. however, to add extra protection against damage spreading because of undetected residual bit errors in context-updating packets (2) or other unexpected errors (3), periodic context verifications SHOULD be performed (see Section 4.6). ✨

3.4. Applicability of This Profile

the LLA profile works with any link technology that can provide the functionality described in the previous sections. so whether you should implement LLA or ROHC RTP depends on the characteristics of the link itself. for most RTP packet streams, LLA works exactly like ROHC RTP, and it gets better compression efficiency for streams with certain characteristics. LLA will never have a lower compression efficiency than ROHC RTP. 💖

also, LLA (like every other ROHC profile) is fully transparent to any packet stream reaching the compressor. it doesn't make any assumptions about the stream, but it performs best on streams with certain characteristics, e.g., synchronized streams timed exactly with the assisting link the LLA profile runs over. 🦋

the LLA profile is obviously not applicable if the UDP checksum (2 bytes) is enabled, which is always the case for IPv6/UDP. for IPv4/UDP, the sender may choose to disable the UDP checksum. 🙅‍♀️

4. Additions and Exceptions Compared to ROHC RTP

4.1. Additional Packet Types

the LLA profile defines three new packet types, used alongside the RRP packet types defined by [ROHC]. the following sections describe these packet types and their purpose in detail. 💅

4.1.1. No-Header Packet (NHP)

a No-Header Packet (NHP) is a packet made up only of the payload of the original packet. the NHP MAY be used when only the sequence information needs to get to the decompressor. in other words, the NHP can be used when all header fields are either unchanged or follow the change pattern that's already established. there are also some considerations for using the NHP (see sections 4.3, 4.5, and 4.6). an LLA compressor is not allowed to deliver NHP packets when operating in R-mode. 🚫

the assisting layer MAY send the NHP for RTP SN = X only if an NHP was delivered by the LLA compressor AND the assisting layer can guarantee that the decompressor will infer the proper sequencing for this NHP. this guarantee rests on the confidence that the decompressor:

  1. has the means to infer proper sequencing for the packet corresponding to SN = X-1, AND
  2. has either received a loss indication or the packet itself for the packet corresponding to SN = X-1.

Updating properties: NHP packets update context (RTP Sequence Number). 🌈

4.1.2. Context Synchronization Packet (CSP) 🧚

okay so when the packet stream is hungrier than the channel bandwidth, stuff gets dropped, and then the decompressor's context can get invalidated 😭 the fix is to send a packet with just the header and ditch the payload. that keeps the decompressor synced AND doesn't waste bandwidth. iconic 💅

This is handled by the Context Synchronization Packet (CSP) 🦋, which looks like this:

     0   1   2   3   4   5   6   7
   +---+---+---+---+---+---+---+---+
   | 1   1   1   1   1   0   1   0 | Packet type identifier
   +===+===+===+===+===+===+===+===+
   /       RTP Payload Length      / 2 octets
   +---+---+---+---+---+---+---+---+
   :  ROHC header without padding  :
   :    see [ROHC, Section 5.7]    :
   +---+---+---+---+---+---+---+---+

RTP Payload Length: this field holds the length of the payload that was inside the RTP header, stored in network byte order 🔢 The compressor sets it to (UDP length - size of the UDP header - size of the RTP header including CSRC identifiers).

Updating properties: CSP keeps the updating properties of the ROHC header it carries ✨

The CSP is defined by one of the unused packet type identifiers from ROHC RTP, and it sits in the one-octet base header. Like any ROHC packet except the NHP, it may start with ROHC padding and/or feedback. It can also carry context identification right after the packet type identifier. You can even have two CID fields, one after the packet type ID and one inside the encapsulated ROHC header 👀 If a decompressor gets a CSP with two non-equal CID values, the packet MUST be discarded 🚫 ROHC segmentation can also be applied to the CSP.

Here's the tea 🍓 the compressor drops the payload, but the decompressor still needs the payload length to infer some fields in the uncompressed header: the IPv4 total length, the IPv6 payload length, the UDP length, and the IPv4 header checksum field 🤓 So the length has to ride along in the CSP. When the decompressor gets a CSP, it uses the RTP payload length field to work out the fields classified as INFERRED in [ROHC], which it needs when checking the 3- or 7-bit CRC in the RHP header enclosed in the CSP.

Note that once the decompressor has received and processed a CSP, the packet (including any data that follows the CSP encapsulated compressed header) MUST be discarded 🙈

4.1.3. Context Check Packet (CCP) 🎀

A Context Check Packet (CCP) is a no-payload packet 💜 It only has an optional CRC value next to the packet type identifier.

Its whole purpose is to be a useful packet that MAY be sent by a synchronized physical link layer when data has to go out at fixed intervals, even when no compressed packet is ready. Whether the CCP actually gets sent over the link and delivered to the decompressor is up to the assisting layer 🫶 The CCP looks like this:

     0   1   2   3   4   5   6   7
   +---+---+---+---+---+---+---+---+
   | 1   1   1   1   1   0   1   1 | Packet type identifier
   +===+===+===+===+===+===+===+===+
   | C |          CRC              |
   +---+---+---+---+---+---+---+---+

C: C = 0 means the CRC field is not used. C = 1 means a valid CRC is present.

Updating properties: CCP packets do not update context 🙅

The CCP is defined by one of the unused packet type identifiers from ROHC RTP, carried in the first octet of the base header. The first bit of the second octet, the C bit, says whether the CRC field is used. If C=1, the CRC field MUST be set to the 7-bit CRC calculated over the original uncompressed header defined in [ROHC, Section 5.9.2]. As for any ROHC packet except NHP, the packet MAY begin with ROHC padding and/or carry context identification.

Using the CRC field to verify decompressor context is optional, so it's a compressor implementation choice 🤷‍♀️ However, a CCP MUST always be made available to the assisting layer.

If the assisting layer gets CCPs with the C bit set (C=1) from the compressor, it MUST use the last CCP received if a CCP is to be sent. That means the CCP that matches the last non-CCP packet sent (NHP, RRP or CSP). An assisting layer MAY use the CCP for other purposes, like signaling a packet loss before the link 👀

The decompressor is REQUIRED to handle a CCP received with the C bit set (C=1), which indicates a valid CRC field, and to perform context verification. The received CRC MUST then be applied to the last decompressed packet, unless a packet loss indication was received before. If the CRC fails, actions MUST be taken as specified in [ROHC, Section 5.3.2.2.3, steps a-d only]. A CCP received with C=0 MUST be ignored by the decompressor. The decompressor is not allowed to make any further interpretation of the CCP 🛑

When you use the 7-bit CRC in the CCP packet to verify context, the decompressor needs the entire uncompressed header of the latest packet it decompressed 🧠 Some [ROHC] implementations might not save the values of INFERRED fields. An implementation of ROHC LLA MUST save these fields in the decompressor context, or it won't be able to verify CCP packets properly 😤

Using CCP in an assisting layer is optional and depends on the actual link's characteristics. So whether it's used MUST be specified in the link-layer implementation specifications for this profile 📋

4.2. Interfaces Towards the Assisting Layer 🌈

This profile relies on the lower layers to provide the functionality needed to send NHP packets. The interaction between LLA and the assisting layer is defined as interfaces between the LLA compressor/decompressor and the LLA applicable link technology 🔌

                |                              |
                +                              +
   +-------------------------+    +-------------------------+
   |       ROHC RTP HC       |    |       ROHC RTP HD       |
   +-------------------------+    +-------------------------+
   |       LLA profile       |    |       LLA profile       |
   +=========================+    +=========================+
   |       Interface         |    |        Interface        |
   | ROHC to assisting layer |    | Assisting layer to ROHC |
   +=========================+    +=========================+
   |       Applicable        |    |       Applicable        |
   |     link technology     |    |     link technology     |
   +=========================+    +=========================+
                |                              |
                +------>---- CHANNEL ---->-----+

The figure above shows the various levels, as defined in [ROHC] and this document, that make up a complete implementation of the LLA profile. It also shows that additional documents are needed to explain how to implement these interfaces for any link technology this profile applies to 📚

This section defines the information the LLA compressor and the assisting layer need to swap for this profile to work properly. It defines the semantics, but it doesn't say how these interfaces should be implemented 🤍

4.2.1. Interface, Compressor to Assisting Layer 🦋

This section covers the interface semantics between the compressor and the assisting layer, including the rules for delivering packets from the compressor 💌

The interface defines these parameters: RRP, RRP segmentation flag, CSP, CSP segmentation flag, NHP, and RTP Sequence Number. Every parameter except the NHP MUST always be delivered to the assisting layer. That gives two possible delivery scenarios:

a. RRP, CSP, CCP, NHP, and RTP Sequence Number are delivered, along with the corresponding segmentation flags, set accordingly. This happens when the compressor allows sending an NHP packet, with or without segmentation applied to the matching RRP/CSP packets.

Quick reminder: an NHP packet gets delivered when the ROHC RTP compressor would have used a ROHC UO-0 ✨

b. RRP, CSP, CCP, and RTP Sequence Number are delivered, along with the corresponding segmentation flags, set accordingly. This happens when the compressor does not allow sending an NHP packet. Segmentation might be applied to the matching RRP and CSP packets 🧩

Segmentation may be applied independently to an RRP or a CSP packet if its size is bigger than the largest value in the PREFERRED PACKET_SIZES list and the LARGE_PACKET_ALLOWED parameter is set to false. The segmentation flags are spelled out in the interface definition to make it clear that the compressor may deliver RRP and CSP as segmented packets 💖

The RTP SN MUST be delivered for each packet by the compressor, so the assisting layer can keep the sequencing information straight 🔢

4.2.2. Interface, Assisting Layer to Decompressor 🌸

This section covers the interface semantics between the assisting layer and the decompressor. The rules here are simple: how received packets get delivered to the decompressor 📬 The decompressor needs a way to tell NHP packets apart from RHP packets. Also, when packets arrive without a header, the decompressor needs a way to infer the sequencing information, so the received payload stays in sync with the sequence information of the decompressed headers 🫠 To make that happen, the decompressor MUST receive the following from the assisting layer:

  • an indication for each packet loss over the link between the compressing and decompressing sides for CID=0.
  • the received packet together with an indication of whether the packet received is an NHP.

Note that the context is updated from a packet loss indication 🔄

4.3. Optimistic Approach Agreement ✨

okay so ROHC has this optimistic approach for context updates, which saves header overhead 🫶 It's fully used in the Optimistic and Unidirectional modes. Every compressed header has a CRC, so the optimistic approach is only a compressor issue. The decompressor always catches a bad context with the CRC check 💅

BUT the NHP packet from the LLA profile has no CRC, which is kind of a big deal 😭 So if an RHP packet that updates the context gets lost, nobody might notice. To fix this, the compressor and decompressor have to agree on the optimistic approach rules, and the transmitting assisting layer has to enforce them too. For example, say three consecutive updates are sent to convey one header field change. The decompressor needs to know that, and it has to invalidate the context if three or more consecutive physical packets are lost. Also, if a new field change needs to be conveyed while the compressing side is already sending packets for non-linear context updates, the mechanism used to enforce the optimistic approach has to be reinitialized 🔥

An LLA decompressor MUST use the optimistic approach knowledge to detect possible context loss events. If it suspects context loss, it MUST invalidate the context and not forward any packets before the context has been synchronized 💀

It is REQUIRED that every document describing how the LLA profile is implemented over a certain link technology defines how the compressing and decompressing sides agree on the optimistic approach. It could be a fixed principle, negotiated at startup, or done some other way, but the method has to be unambiguously defined 🌸

4.4. Fast Context Initialization, IR Redefinition 🧚

so initial IR packets can overrun the channel bandwidth and seriously delay the decompressor setting up its context 😩 It might be smart to throw away the payload at first. That lets state transitions happen with minimal delay and still gets you higher compression efficiency ✨

To make this work, the D-bit from the basic structure of the ROHC RTP IR packet [ROHC, Section 5.7.7.1] gets redefined for the LLA profile. For D=0 (no dynamic chain), the D-bit now also tells you that the payload was discarded when the IR packet was assembled. Every other field keeps the meaning it has in ROHC RTP 🎀

Here's the resulting structure, using small CIDs and CID=0:

     0   1   2   3   4   5   6   7
   +---+---+---+---+---+---+---+---+
   | 1 | 1 | 1 | 1 | 1 | 1 | 0 | D |
   +---+---+---+---+---+---+---+---+
   |            Profile            | 1 octet
   +---+---+---+---+---+---+---+---+
   |              CRC              | 1 octet
   +---+---+---+---+---+---+---+---+
   |            Static             | variable length
   |             chain             |
    - - - - - - - - - - - - - - - -
   |            Dynamic            | not present if D = 0
   |             chain             | present if D = 1, variable length
    - - - - - - - - - - - - - - - -
   |            Payload            | not present if D = 0
   |                               | present if D = 1, variable length
    - - - - - - - - - - - - - - - -

        D:   D = 0 indicates that the dynamic chain is not present
             and that the payload has been discarded.

After an IR packet with D=0 has been processed by the decompressor, the packet MUST be discarded 🫧

4.5. Feedback Option, CV-REQUEST 💜

The CV-REQUEST option MAY be used by the decompressor to ask for an RRP or CSP for context verification 🙈 This option should be used if only NHPs have been received for a long time, since the context hasn't been verified recently.

+---+---+---+---+---+---+---+---+
|  Opt Type = 8 |  Opt Len = 0  |
+---+---+---+---+---+---+---+---+

If the compressor gets a feedback packet with this option, the next packet it compresses SHOULD NOT be delivered to the assisting layer as an NHP 🙅‍♀️

4.6. Periodic Context Verification 🦋

As Section 3.3 explains, transparency is expected to be guaranteed by the functionality of the lower layers. So this ROHC profile would be at least as reliable as the older header compression schemes [VJHC, IPHC, CRTP], which don't use a header compression CRC. BUT ROHC RTP is extremely safe to use from a transparency point of view, so it would be super desirable to get that same safety with LLA too 🥹

To give an extra transparency guarantee and also catch unexpected errors, like errors caused by faulty implementations, it is RECOMMENDED that context updating packets be sent periodically, even when the compressor logic allows NHP packets to be used 🫶

4.7. Use of Context Identifier 🍓

An NHP can't carry a context identifier (CID), so there's a restriction on how this profile can be used for context identification. No matter which CID size was negotiated, NHP packets can only be used for CID=0. If the decompressor receives an NHP packet, it can only belong to CID=0 🎀

If multiple packet streams are handled by a compressor using LLA, the assisting layer MUST be able to tell which CID a physical packet loss happened on, or at least it MUST be able to tell if packets with CID=0 (the packet stream with NHPs) have been lost. Bestie, this one matters 😭

5. Implementation Issues 🧚

This document specifies the mechanisms for the protocol and leaves the details of using them to the implementers. This section is giving guidelines, ideas, and suggestions for implementing LLA 💅

5.1. Implementation Parameters and Signals ✨

As described in [ROHC, Section 6.3], implementations use parameters to set up configuration information and to decide how a ROHC implementation operates. The following parameters are additions to the parameter set defined for ROHC RTP implementations, and they're useful for LLA. Heads up: if the PREFERRED_PACKET_SIZES parameter is used, it obsoletes all PACKET_SIZE and PAYLOAD_SIZE parameters of ROHC RTP 👑

5.1.1. Implementation Parameters at the Compressor 💖

ALWAYS_PAD -- value: boolean

An external entity may set this parameter to tell the compressor that every RHP packet MUST be padded with ROHC padding of one octet, minimum 🌈

The assisting layer MUST provide a packet type identification. If the link layer protocol has no field for this, a leading sequence can be used to tell RHP packets apart from NHP packets. Using a leading sequence isn't super efficient, since it costs RHP packets some efficiency. BUT the loss should be insignificant, because the leading sequence only applies to packets with headers, which keeps packets without headers (the ones we want to favor) nice and efficient 🙌 If a leading sequence is wanted for RHP identification, the lower layer MAY use ROHC padding for it by setting the ALWAYS_PAD parameter. Just note that in that case, possible collisions of the padding with the NHP payload must be avoided ⚠️

By default, this parameter is set to FALSE.

PREFERRED_PACKET_SIZES -- list of:

  • SIZE -- value: integer (octets)
  • RESTRICTED_TYPE -- values: NHP_ONLY, RHP_ONLY, NO_RESTRICTION

This parameter set controls which packet sizes the assisting layer prefers 🎀 If it's used, all RHP packets MUST be padded to fit the smallest possible preferred size. If the unpadded packet is larger than the maximal preferred packet size (or, if ALWAYS_PAD is set, the packet with minimal one-octet padding is), the compressor has two options. It can deliver the larger packet at an arbitrary size, OR it can split the packet into several segments using ROHC segmentation and pad each segment to one of the preferred sizes. Which one it picks depends on the value of the LARGE_PACKETS_ALLOWED parameter below 🧩

NHP packets can only be delivered to the lower layer if their payload size is part of the preferred packet size set. Also, if RESTRICTED_TYPE is set to NHP_ONLY or RHP_ONLY for any of the preferred packet sizes, that size is only allowed for packets of the specified type 🙅‍♀️

By default, no preferred packet sizes are specified. When sizes are specified, the default value for RESTRICTED_TYPE is NO_RESTRICTION.

LARGE_PACKETS_ALLOWED -- value: boolean

An external entity may set this parameter to say how to handle packets that don't fit any of the specified preferred packet sizes 🚀 If it's TRUE, the compressor MUST deliver the larger packet as-is and MUST NOT use segmentation. If it's FALSE, the ROHC segmentation scheme MUST be used to split the packet into two or more segments, and each segment MUST further be padded to fit one of the preferred packet sizes.

By default, this parameter is set to TRUE, which means segmentation is disabled 🌸

VERIFICATION_PERIOD -- value: integer

An external entity may set this parameter to tell the compressor the minimum frequency at which a packet validating the context must be sent 🔍 It tells the compressor that a packet containing a CRC field MUST be sent at least once every N packets, where N=VERIFICATION_PERIOD (see Section 4.6).

By default, this parameter is set to 0, which means periodic verifications are disabled.

5.1.2. Implementation Parameters at the Decompressor 🫧

NHP_PACKET -- value: boolean

This parameter tells the decompressor that the packet being delivered is an NHP packet. The decompressor MUST accept this packet type indicator from the lower layer. An assisting layer MUST set this indicator to true for every NHP packet delivered, and to false for any other packet 💫

PHYSICAL_PACKET_LOSS -- signal

This signal tells the decompressor that a packet got lost on the link between the compressing and decompressing sides, because of a physical link error 📉 It's given once for each lost packet, and a decompressor must increase the sequence number accordingly when it receives this signal.

PRE_LINK_PACKET_LOSS -- signal

This signal tells the decompressor to increase the sequence number because of a gap in the sequencing that isn't related to a physical link error 🕵️ A receiving assisting layer might use it, for example, to tell the decompressor that a packet was lost before the compressor, or that the transmitting assisting layer discarded a packet.

okay so this part is about how the ROHC compressor and decompressor talk to the assisting layer 💅 this doc spells out the semantics and requirements of that interface, which is what makes link-layer-assisted header compression possible 🫶

ngl, this doc doesn't get into link-specific operational details, except for a few implementation suggestions 🙈 the details for each link technology have to live in other docs, where they can take that link's characteristics into account and get the best possible use out of this profile ✨

These specifications MAY use a packet-type bit pattern unused by this profile to implement signaling on the lower layer. The pattern available to lower layer implementations is [11111001] 🌸

6. IANA Considerations 🎀

ROHC profile identifier 0x0005 has been reserved by the IANA for the IP/UDP/RTP profile defined in this document 💖

7. Security Considerations 🔥

okay this section is serious, bestie 😭 all the security considerations of ROHC RTP [ROHC, Section 7] apply here too, with one extra thing to watch out for 👀

picture a denial-of-service attack where an intruder throws bogus CCP packets onto the link, using random CRC values 💀 the CRC check then fails for the wrong reasons at the decompressor side. that would totally wreck the advantages of ROHC and any extra efficiency this profile gives you, because you'd get unnecessary context invalidation, feedback messages, and refresh packets flooding in 🙈 and yes, the same remarks about the presence of such an intruder still apply 🚨

8. Acknowledgements 🫶

The authors want to thank Lila Madour, Ulises Olvera-Hernandez, and Francis Lupien for their input on the typical links where LLA can be applied 🧚 thanks also to Mikael Degermark for the fruitful discussions that led to improvements in this profile, and to Zhigang Liu for many valuable comments 💜

9. References 📚

9.1. Normative References

  • [ROHC] 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.
  • [IPv4] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981.
  • [IPv6] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998.
  • [UDP] Postel, J., "User Datagram Protocol", STD 6, RFC 768, August 1980.
  • [RTP] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, July 2003.
  • [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.

9.2. Informative References

  • [LLA] Jonsson, L-E. and G. Pelletier, "RObust Header Compression (ROHC): A Link-Layer Assisted Profile for IP/UDP/RTP", RFC 3242, April 2002.
  • [TCP] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981.
  • [RTP-REQ] Degermark, M., "Requirements for robust IP/UDP/RTP header compression", RFC 3096, July 2001.
  • [0B-REQ] Jonsson, L-E., "RObust Header Compression (ROHC): Requirements and Assumptions for 0-byte IP/UDP/RTP Compression", RFC 3243, April 2002.
  • [VJHC] Jacobson, V., "Compressing TCP/IP headers for low-speed serial links", RFC 1144, February 1990.
  • [IPHC] Degermark, M., Nordgren, B., and S. Pink, "IP Header Compression", RFC 2507, February 1999.
  • [CRTP] Casner, S. and V. Jacobson, "Compressing IP/UDP/RTP Headers for Low-Speed Serial Links", RFC 2508, February 1999.
  • [CRTPC] Degermark, M., Hannu, H., Jonsson, L-E. and K. Svanbro, "Evaluation of CRTP Performance over Cellular Radio Networks", IEEE Personal Communications Magazine, Volume 7, number 4, pp. 20-25, August 2000.
  • [VTC2000] Svanbro, K., Hannu, H., Jonsson, L-E. and M. Degermark, "Wireless real time IP-services enabled by header compression", proceedings of IEEE VTC2000, May 2000.
  • [MOMUC01] Liu, G., et al., "Experimental field trials results of Voice-over IP over WCDMA links", MoMuC'01 - The International Workshop on Mobile Multimedia Communications, Conference proceedings, February 2001.

Authors' Addresses 📮

Lars-Erik Jonsson
Ericsson AB
Box 920
SE-971 28 Lulea, Sweden

Phone: +46 8 404 29 61
Fax:   +46 920 996 21
EMail: lars-erik.jonsson@ericsson.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.com

Copyright (C) The Internet Society (2006).

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 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 provided by the IETF Administrative Support Activity (IASA).

📦 where this page comes from