RFC 4019
RObust Header Compression (ROHC): Profiles for User Datagram Protocol (UDP) Lite
RFC 4019: RObust Header Compression (ROHC) Profiles for UDP-Lite 🦋
Network Working Group · G. Pelletier · Ericsson AB · Category: Standards Track · April 2005 💖
Okay bestie, the title block is giving: this is a Standards Track doc from Ericsson AB, written by G. Pelletier, dated April 2005. Its header doesn't list any RFCs it obsoletes or updates, so it doesn't replace or patch anything 🧚. (Part 1 of 4, so there's more to come ✨)
Status of This Memo ✨
This document specifies an Internet standards track protocol for the Internet community, and it's asking for discussion and suggestions for improvements 💅. For the 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 Notice 🎀
Copyright (C) The Internet Society (2005).
Abstract 🌈
This doc defines Robust Header Compression (ROHC) profiles for compressing Real-Time Transport Protocol, User Datagram Protocol-Lite, and Internet Protocol (RTP/UDP-Lite/IP) packets, plus UDP-Lite/IP packets 🦋. The profiles are described by how they differ from the UDP profiles in RFC 3095, so you'll want that one close by 💜.
Table of Contents 📖
1. Introduction.................................................. 2
2. Terminology................................................... 3
3. Background.................................................... 3
3.1. Overview of the UDP-Lite Protocol....................... 3
3.2. Expected Behaviours of UDP-Lite Flows................... 5
3.2.1. Per-Packet Behavior............................. 5
3.2.2. Inter-Packet Behavior........................... 5
3.2.3. Per-Flow Behavior............................... 5
3.3. Header Field Classification............................. 5
4. Rationale behind the Design of ROHC Profiles for UDP-Lite..... 6
4.1. Design Motivations...................................... 6
4.2. ROHC Considerations..................................... 6
5. ROHC Profiles for UDP-Lite.................................... 6
5.1. Context Parameters...................................... 7
5.2. Initialization.......................................... 8
5.2.1. Initialization of the UDP-Lite Header [1]....... 8
5.2.2. Compressor and Decompressor Logic............... 9
5.3. Packet Formats.......................................... 9
5.3.1. General Packet Format........................... 9
5.3.2. Packet Type CCE: CCE(), CCE(ON), and CCE(OFF)... 10
5.3.2.1. Properties of CCE():.................. 11
5.3.2.2. Properties of CCE(ON):................ 11
5.3.2.3. Properties of CCE(OFF):............... 12
5.4. Compressor Logic........................................ 12
5.5. Decompressor Logic...................................... 12
5.6. Additional Mode Transition Logic........................ 13
5.7. The CONTEXT_MEMORY Feedback Option...................... 13
5.8. Constant IP-ID.......................................... 13
6. Security Considerations....................................... 14
7. IANA Considerations........................................... 14
8. Acknowledgments............................................... 15
9. References.................................................... 15
9.1. Normative References.................................... 15
9.2. Informative References.................................. 15
Appendix A. Detailed Classification of Header Fields............. 17
Appendix B. Detailed Format of the CCE Packet Type............... 20
Author's Address.................................................. 22
Full Copyright Statement.......................................... 231. Introduction 🍓
Okay so the ROHC WG built a header compression framework that different profiles can sit on top of, for different protocol sets or compression strategies 🧚. The cellular industry really needed a good way to send voice over IP over wireless, so ROHC [2] mostly focused on compressing IP/UDP/RTP headers. Those headers are honestly chunky, especially next to the payloads they're carrying 😭.
ROHC RTP is seriously efficient, robust, and capable 👑. It can squish the headers down to a total size of just one octet 💅. Transparency is also guaranteed to an extremely high extent, even when residual bit errors show up in compressed headers that get delivered to the decompressor 🫶.
UDP-Lite [4] is a transport protocol that's a lot like the UDP protocol [7] 🦋. It's useful for apps built to handle errors in the payload, because getting slightly damaged data is way better than losing whole packets 💜. This is especially good when packets go over link technologies where data can get partly damaged, like wireless links 📡.
These two transport protocols are super similar, but ROHC profiles still have to be defined separately for robust compression of UDP-Lite headers 🙈. That's because UDP-Lite doesn't share the same protocol identifier as UDP ✨. Also, the UDP-Lite Checksum Coverage field doesn't have the same semantics as the UDP Length field, so it can't always be inferred anymore 😭.
This document defines two ROHC profiles for efficient compression of UDP-Lite headers 🎀. The goal is to make simple changes to the matching ROHC profiles for UDP from RFC 3095 [2] 🌸. The UDP-Lite profiles also support some of the mechanisms from the profile for compressing IP headers [3] (ROHC IP-Only) 💖. On top of that, this spec supports compressing multiple IP headers and compressing IP-ID fields with constant behavior 🔥. It also adds improved mode transition logic and a feedback option for decompressors with limited memory resources 👑.
2. Terminology 💅
In this document, the key words are to be interpreted as described in RFC 2119 [1]. Those key words are:
- "MUST"
- "MUST NOT"
- "REQUIRED"
- "SHALL"
- "SHALL NOT"
- "SHOULD"
- "SHOULD NOT"
- "RECOMMENDED"
- "MAY"
- "OPTIONAL"
Here's the vocab you need 🧚:
ROHC RTP: RTP/UDP/IP profile 0x0001 defined in RFC 3095 [2].ROHC UDP: UDP/IP profile 0x0002 defined in RFC 3095 [2].ROHC UDP-Lite: UDP-Lite/IP profile defined in this document.ROHC RTP/UDP-Lite: RTP/UDP-Lite/IP profile defined in this document.
3. Background 🦋
3.1. Overview of the UDP-Lite Protocol 💜
UDP-Lite is its own transport protocol, kind of an independent variant of UDP 🌈. It's very similar to UDP, but it lets apps that can handle payload errors use a checksum with optional partial coverage ✨. This is especially handy with IPv6 [6], where the transport-layer checksum is mandatory 🫶.
UDP-Lite swaps the Length field in the UDP header for a Checksum Coverage field 🍓. That field says how many octets the 16-bit checksum covers, and it's applied per packet 💅. The coverage always includes the UDP-Lite header 🎀. It can also cover the entire packet, and when it does, UDP-Lite is semantically identical to UDP 👑. And again, UDP-Lite and UDP don't share a protocol identifier 🙈.
Here's the UDP-Lite header format:
0 15 16 31
+--------+--------+--------+--------+
| Source | Destination |
| Port | Port |
+--------+--------+--------+--------+
| Checksum | |
| Coverage | Checksum |
+--------+--------+--------+--------+
| |
: Payload :
| |
+-----------------------------------+Like the UDP checksum, the UDP-Lite checksum is an end-to-end mechanism against erroneous delivery of error-sensitive data 🔥. With IPv6 [5], this checksum is mandatory for both protocols 💖. But unlike its UDP counterpart, the UDP-Lite checksum may not be transmitted as all zeroes, and it can't be disabled for IPv4 [5] 😭. For UDP, if the checksum is disabled (IPv4 only), the Checksum field keeps a constant value and isn't normally sent by the header compression scheme 🌸. If the UDP checksum is enabled (mandatory for IPv6), that unpredictable field can't be compressed, so it gets sent uncompressed 🧚. The UDP Length field is always redundant, though, and the IP module can provide it 💅. Header compression schemes don't normally send any bits for this field, since its value can be inferred from the link layer 🦋.
For UDP-Lite, the checksum also has unpredictable values, so this field must always be included as-is in the compressed header for both IPv4 and IPv6 🎀. And since UDP-Lite redefines the UDP Length field as the Checksum Coverage field, that field has different properties from a header-compression point of view 💜.
Here's the quick rundown of how UDP and UDP-Lite relate 🌈:
- UDP-Lite and UDP have different protocol identifiers.
- The UDP-Lite checksum cannot be disabled for IPv4.
- UDP-Lite redefines the UDP Length field as the Checksum Coverage field, with different semantics.
- UDP-Lite is semantically equivalent to UDP when the Checksum Coverage field indicates the total length of the packet.
The next section goes deeper into how the Checksum Coverage field of UDP-Lite behaves with header compression ✨.
3.2. Expected Behaviours of UDP-Lite Flows 🍓
3.2.1. Per-Packet Behavior 💅
As we mentioned in the last section, the checksum coverage value gets applied independently of other packets in the same flow 🎀. So the checksum coverage value might say that a UDP-Lite packet is either entirely covered by the checksum, or covered up to some boundary that's less than the packet size but still includes the UDP-Lite header 👑.
3.2.2. Inter-Packet Behavior 🙈
Looking at UDP-Lite packets next to each other, they can follow one of three change patterns. Within a sequence of packets, the value of the Checksum Coverage field is:
- changing, while covering the entire packet;
- unchanging, covering up to a fixed boundary within the packet; or
- changing, but it does not follow any specific pattern.
The first pattern matches UDP's semantics when the UDP checksum is enabled 💖. In this case the checksum coverage field changes with the packet length, and it can be inferred from the IP header, the same way the UDP Length field value is 🦋.
The second pattern is when the coverage stays the same from one packet to the next within a particular sequence 🌸. Here the Checksum Coverage field can be a static value defined in the context, so it doesn't have to be sent in the compressed header 🧚. For the third case, there's no useful change pattern you can spot from packet to packet in the checksum coverage value, so it must be included in the compressed header 😭.
3.2.3. Per-Flow behavior 🌈
Any one of the change patterns above can be the predominant one at any point during the lifetime of a UDP-Lite flow 🫶. A flow that mostly follows the first two patterns can give you chances to compress the Checksum Coverage field for most of its packets 🔥.
3.3. Header Field Classification
Okay so RFC 3095 [2] has this whole header field classification thing 👑, and the first two patterns cover the situation where the Checksum Coverage field behaves in a fixed way ✨. It can be INFERRED (pattern 1) or STATIC (pattern 2) 🎀. Pattern 3 is the chaotic one 💀: the value changes unpredictably, the field is CHANGING, and the value has to be sent along with every single packet 😭.
Appendix A goes deeper into how the UDP-Lite fields behave if you want the full tea 🍵.
4. Rationale behind the Design of ROHC Profiles for UDP-Lite ✨
4.1. Design Motivations
Simplicity is the main vibe here 🫶. The UDP-Lite profiles should only need a few simple tweaks to the matching UDP profiles from RFC 3095 [2] 💅. It's also lowkey desirable to pull in some of the upgrades from the ROHC IP-Only profile [3] 🌈. And finally, whenever UDP-Lite is used in a way that's semantically identical to UDP, the compression efficiency should land close to what UDP gets 🦋.
4.2. ROHC Considerations
The simplest route to defining ROHC profiles for UDP-Lite is to treat the Checksum Coverage field as an irregular value and just send it uncompressed in every packet 🙈. You can get there by simply adding the field to the general packet format definition [2]. The catch? Compression efficiency would then always be worse than UDP 😭.
Some care is needed to get UDP-Lite compression close to UDP when the Checksum Coverage field acts like the UDP Length field 💖. That means being able to infer the Checksum Coverage field when it equals the length of the packet. If we skip this, UDP-Lite gets the short end of the stick on links that use header compression, especially once its behaviour starts looking like UDP semantics 🥺.
We also need a way to detect whether the Checksum Coverage field is present in compressed headers 🔍. The fix is to define a brand new packet type that uses the identifiers RFC 3095 [2] left unused 🧚.
5. ROHC Profiles for UDP-Lite 👑
5.1. Context Parameters
This section defines two ROHC profiles 🌸:
- RTP/UDP-Lite/IP compression (profile 0x0007)
- UDP-Lite/IP compression (profile 0x0008)
These profiles build on RFC 3095 [2] with as few changes as possible 💜. Unless it's explicitly said otherwise, the profiles here follow the ROHC UDP and ROHC RTP specs, respectively ✨.
Also, this document reuses the notation found in [2] 🎀.
As [2] describes, info about previous packets is kept in a context 📦. That includes details about the packet stream and the compression parameters. UDP and UDP-Lite have plenty in common, but the semantic differences we covered earlier make the following parameter irrelevant 🙅♀️:
The parameter context(UDP Checksum)
The UDP-Lite checksum can't be turned off, unlike UDP 🚫. So the context(UDP Checksum) parameter defined in [2] (section 5.7) is not used for compressing UDP-Lite 💅.
The UDP-Lite checksum is always sent as-is in every compressed packet 🫶. The Checksum Coverage field, though, doesn't always show up in every compressed packet. The following context parameter tells us whether it's sent 👀:
The parameter context(UDP-Lite Coverage Field Present)
Whether the UDP-Lite Checksum Coverage field is in the general packet format (see section 5.3.1) depends on the Coverage Field Present (CFP) flag in the context 🎀.
If context(CFP) is nonzero, the Checksum Coverage field isn't compressed and it shows up inside compressed packets ✨. If context(CFP) is zero, the Checksum Coverage field gets compressed and isn't sent at all 🦋. This happens when the value of the Checksum Coverage field follows a stable inter-packet pattern: it's either a constant, or it equals the packet length for most packets in a sequence (see section 3.2) 💅.
Last but not least, this context parameter says whether the field should be inferred or pulled from a value saved earlier in the context 🧠:
The parameter context(UDP-Lite Coverage Field Inferred)
When the UDP-Lite Checksum Coverage field isn't in the compressed header (CFP=0), the Coverage Field Inferred (CFI) flag in the context decides whether it gets inferred 🔮.
If context(CFI) is nonzero, the Checksum Coverage field is inferred from the packet length, the same way the UDP Length field works in ROHC RTP 🌈. If context(CFI) is zero, the Checksum Coverage field gets decompressed using context(UDP-Lite Checksum Coverage) 🍓. So if context(CFI) ever gets updated to a nonzero value, the Checksum Coverage field value stored in the context has to be updated too 💀.
5.2. Initialization
Unless stated otherwise, the mechanisms of ROHC RTP and ROHC UDP from [2] also apply to the ROHC RTP/UDP-Lite and ROHC UDP-Lite profiles, respectively 🌸.
In particular, the ROHC UDP considerations about the UDP SN taking over the role of the RTP Sequence Number also apply to ROHC UDP-Lite 💖. And the static context for ROHC UDP-Lite can be initialized by reusing an existing context from a stream compressed with ROHC RTP/UDP-Lite (profile 0x0007), just like with ROHC UDP 🫶.
5.2.1. Initialization of the UDP-Lite Header [1] 🎀
The IR and IR-DYN packet structure and the initialization procedures are the same as the ROHC profiles for UDP [2], except for the dynamic part, which is specified for UDP 💅. We add a 2-octet field holding the checksum coverage right before the Checksum field ✨. This changes the format of the dynamic chains in both IR and IR-DYN packets 🦋.
Dynamic part:
+---+---+---+---+---+---+---+---+
/ Checksum Coverage / 2 octets
+---+---+---+---+---+---+---+---+
/ Checksum / 2 octets
+---+---+---+---+---+---+---+---+CRC-DYNAMIC: Checksum Coverage field, Checksum field (octets 5 - 8).
CRC-STATIC: All other fields (octets 1 - 4).
5.2.2. Compressor and Decompressor Logic 🧠
Both the compressor and the decompressor have to use the following logic to assign values to context(CFP) and context(CFI) during initialization 🔧:
Context(CFP)
During context initialization, context(CFP) MUST be set to a nonzero value if the Checksum Coverage field differs from the length of the UDP-Lite packet, for any one IR or IR-DYN packet sent (compressor) or received (decompressor). Otherwise, it MUST be set to zero 🙌.
Context(CFI)
During context initialization, context(CFI) MUST be set to a nonzero value if the Checksum Coverage field is equal to the length of the UDP-Lite packet within an IR or an IR-DYN packet sent (compressor) or received (decompressor). Otherwise, it MUST be set to zero 💜.
5.3. Packet Formats 📦
The general packet format from RFC 3095 [2] gets modified to include an extra field for the UDP-Lite checksum coverage 🎀. There's also a new packet type made specifically for the semantics and quirks of this field ✨.
5.3.1. General Packet Format 🌈
The general packet format of a compressed ROHC UDP-Lite header looks a lot like the compressed ROHC RTP header ([2], section 5.7) 💅. The differences are the Checksum field, plus extra fields for handling multiple IP headers and the UDP-Lite checksum coverage 🫶:
--- --- --- --- --- --- --- ---
: List of : variable, given by static chain
/ dynamic chains / (does not include SN)
: for additional IP headers : see also [3], section 3.2.
--- --- --- --- --- --- --- ---
: : 2 octets,
+ UDP-Lite Checksum Coverage + if context(CFP) = 1 or
: : if packet type = CCE (see 5.3.2)
--- --- --- --- --- --- --- ---
: :
+ UDP-Lite Checksum + 2 octets
: :
--- --- --- --- --- --- --- ---The list of dynamic header chains carries the dynamic header part for each IP header beyond the first two, if there are any (which the presence of matching header parts in the static chain tells us) 🔍. Heads up: there's no sequence number at the end of the chain, because SN is already in the compressed base headers 🙈.
The fields that follow the optional extension of the general ROHC packet format keep the same order they have in the uncompressed header ✨.
When the CRC gets calculated, the Checksum Coverage field is CRC-DYNAMIC 🧮.
5.3.2. Packet Type CCE: CCE(), CCE(ON), and CCE(OFF) 🦋
The ROHC profiles for UDP-Lite define a packet type to cover the different ways the checksum coverage can change 💖. This packet type can manipulate the context values that control whether the Checksum Coverage field shows up in the general packet format (i.e., context(CFP)), and how the field gets decompressed (i.e., context(CFI)) 🎀. The 2-octet Checksum Coverage field is always present in this packet's format (see section 5.3.1) ✨.
This packet type is called Checksum Coverage Extension, or CCE 🫶. Its updating properties depend on the last two bits of the packet type octet (see the format below) 👀. We use the naming scheme CCE(<some_property>) to uniquely identify the properties of a particular CCE packet 🏷️.
Even though this packet type has its own format, it can be thought of as an extension mechanism for packets of type 2, 1, or 0 [2] 🧩. It works by swapping the packet type identifier in the first octet of the base header (the "outer" identifier) for one of the unused packet types from RFC 3095 [2]. The swapped-out identifier then moves into the first octet of the rest of the base header (the "inner" identifier) 🔄.
The format of the ROHC UDP-Lite CCE packet type looks like this 🖼️:
0 1 2 3 4 5 6 7
+---+---+---+---+---+---+---+---+
| 1 1 1 1 1 0 F | K | Outer packet type identifier
+===+===+===+===+===+===+===+===+
: : (with inner type identifier)
/ Inner Base header / variable number of bits, given by
: : the inner packet type identifier
+---+---+---+---+---+---+---+---+F,K: F,K = 00 is reserved at framework level (IR-DYN); F,K = 01 indicates CCE(); F,K = 10 indicates CCE(ON); F,K = 11 indicates CCE(OFF).
Updating properties: The updating properties of the inner packet type carried within any of the CCE packets are always maintained. CCE(ON) and CCE(OFF) MUST NOT be used to extend R-0 and R-1* headers. Also, CCE(ON) always updates context(CFP), and CCE(OFF) always updates context(CFP), context(CFI), and context(UDP-Lite Checksum Coverage) 🔥.
Appendix B gives an expanded view of the resulting CCE packet type format 🌟.
5.3.2.1. Properties of CCE() 💅
Okay so, aside from the updating properties of whatever inner packet type rides inside CCE(), this packet does not update any other context values 🫶 That makes CCE() mode-agnostic! It can extend any of packet types 2, 1, and 0, no matter what mode you're currently in [2] ✨
CCE() is for when the checksum coverage doesn't follow the change pattern the compressor was expecting, so the field couldn't have been compressed before 🙈 It's most useful when those deviations are rare, bestie 🌸
5.3.2.2. Properties of CCE(ON) 🦋
Along with the updating properties of the inner packet type, CCE(ON) sets context(CFP) to a nonzero value. Translation: it switches the Checksum Coverage field on in the general packet format 🔥 This is handy when the usual change pattern of the checksum coverage makes compressing it impossible 💀
CCE(ON) can extend any of the context-updating packets of type 2, 1, and 0, meaning packets whose compressed header has a CRC [2]. Specifically, R-0 and R-1* headers MUST NOT be extended by using CCE(ON) 🚫 Not for them, babe.
5.3.2.3. Properties of CCE(OFF) 🌈
Also along with the inner packet's updates, CCE(OFF) sets context(CFP) to zero, which switches the Checksum Coverage field off in the general packet format ✨ This is the move when the checksum coverage almost never strays from what the compressor assumed 💜
CCE(OFF) also sets context(CFI) to a nonzero value if field(UDP-Lite Checksum Coverage) equals the packet length. Otherwise, it must be set to zero. Quick heads up: when CCE(OFF) updates context(CFI), a match of field(Checksum Coverage) with the packet length always wins over a match with context(Checksum Coverage) 👑 Last but not least, CCE(OFF) also updates context(UDP-Lite Checksum Coverage) 🎀
Just like CCE(ON), CCE(OFF) can extend any of the context-updating packets of type 2, 1, and 0 [2] 🧚
5.4. Compressor Logic 🍓
Here's the compressor's tea ☕. If hdr(UDP-Lite Checksum Coverage) is different from context(UDP-Lite Checksum Coverage) AND different from the packet length while context(CFP) is zero, the Checksum Coverage field cannot be compressed. And if hdr(UDP-Lite Checksum Coverage) is different from the packet length while context(CFP) is zero AND context(CFI) is nonzero, the field can't be compressed by either method. In both cases, the field must be sent uncompressed using a CCE packet, OR the context must be reinitialized by using an IR packet 😭
5.5. Decompressor Logic 🔍
For packet types other than IR, IR-DYN, and CCE that show up while context(CFP) is zero, the Checksum Coverage field must be decompressed using the value stored in the context if context(CFI) is zero. Otherwise, the field gets inferred from the length of the UDP-Lite packet derived from the IP module 🧠✨
5.6. Additional Mode Transition Logic 🦋
The profiles in this document let the compressor decline a mode transition the decompressor asked for. The trick is redefining the Mode parameter for mode = 0 (in packet types UOR-2, IR, and IR-DYN) like this (see also [3], section 3.4) 💅
Mode: Compression mode. 0 = (C)ancel Mode TransitionWhen the decompressor gets a Mode parameter set to 0, it MUST stay in its current mode of operation. It SHOULD also refrain from sending further mode transition requests for the declined mode 🙅♀️💖
5.7. The CONTEXT_MEMORY Feedback Option 🧚
This feedback option tells the compressor that the decompressor doesn't have enough memory to handle the context of the packet stream the current compressed structure needs 😭
0 1 2 3 4 5 6 7
+---+---+---+---+---+---+---+---+
| Opt Type = 9 | Opt Len = 0 |
+---+---+---+---+---+---+---+---+When a CONTEXT_MEMORY option comes in, the compressor SHOULD take actions to compress the packet stream in a way that requires less decompressor memory resources, or stop compressing the packet stream altogether 🫶
5.8. Constant IP-ID 🌸
The profiles for UDP-Lite can compress the IP-ID field when it behaves constantly. To make that work, there's a Static IP Identifier (SID) flag inside the dynamic part of the chain that initializes the IPv4 header. Here's how it looks (see also [3], section 3.3) 👑
Dynamic part:
+---+---+---+---+---+---+---+---+
| Type of Service |
+---+---+---+---+---+---+---+---+
| Time to Live |
+---+---+---+---+---+---+---+---+
/ Identification / 2 octets
+---+---+---+---+---+---+---+---+
| DF|RND|NBO|SID| 0 |
+---+---+---+---+---+---+---+---+
/ Generic extension header list / variable length
+---+---+---+---+---+---+---+---+SID: Static IP Identifier.
For IR and IR-DYN packets:
The logic is the same as the respective ROHC profiles for UDP, with one addition: field (SID) must be kept in the context 🧠
For compressed headers other than IR and IR-DYN:
If value(RND) = 0 and context(SID) = 0, hdr(IP-ID) gets compressed using Offset IP-ID encoding (see [2], section 4.5.5) with p = 0 and default-slope(IP-ID offset) = 0 ✨
If value(RND) = 0 and context(SID) = 1, hdr(IP-ID) is constant and compressed away. hdr(IP-ID) is the value of context(IP-ID) 🦋
If value(RND) = 1, IP-ID is the uncompressed hdr(IP-ID). It then gets passed as additional octets at the end of the compressed header, after any extensions 🌈
Note: Only IR and IR-DYN packets can update context(SID). Don't forget this one, bestie 💀
Note: All other fields are the same as for the respective ROHC profiles for UDP [2] 🫶
6. Security Considerations 🚨
The security considerations of RFC 3095 [2] apply integrally to this document, without modification. This is SERIOUS business, so read RFC 3095 before you ship anything 😭🔥
7. IANA Considerations 📋
ROHC profile identifiers 0x0007 (ROHC RTP/UDP-Lite) and 0x0008 (ROHC UDP-Lite) have been reserved by the IANA for the profiles defined in this document (RFC 4019) 🎀
Two ROHC profile identifiers must be reserved by the IANA for the profiles defined in this document. Since profile number 0x0006 is being saved for the TCP/IP (ROHC-TCP) profile, profile numbers 0x0007 and 0x0008 are the most suitable unused identifiers available, so they should thus be used. Just like previous ROHC profiles, profile numbers 0xnn07 and 0xnn08 must also be reserved for future variants of these profiles. The registration suggested for the "RObust Header Compression (ROHC) Profile Identifiers" name space looks like this 🧚
OLD: 0x0006-0xnn7F To be Assigned by IANA
NEW: 0xnn06 To be Assigned by IANA
0x0007 ROHC RTP/UDP-Lite [RFC4019]
0xnn07 Reserved
0x0008 ROHC UDP-Lite [RFC4019]
0xnn08 Reserved
0x0009-0xnn7F To be Assigned by IANA8. Acknowledgments 🫶
The author would like to thank Lars-Erik Jonsson, Kristofer Sandlund, Mark West, Richard Price, Gorry Fairhurst, Fredrik Linstroem and Mats Nordberg for useful reviews and discussions around this document 💖
9. References 📚
9.1. Normative References
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[2] 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.
[3] Jonsson, L-E. and G. Pelletier, "RObust Header Compression (ROHC): A Compression Profile for IP", RFC 3843, June 2004.
[4] Larzon, L-A., Degermark, M., Pink, S., Jonsson, L-E., and G. Fairhurst, "The Lightweight User Datagram Protocol (UDP-Lite)", RFC 3828, July 2004.
9.2. Informative References
[5] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981.
[6] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998.
[7] Postel, J., "User Datagram Protocol", STD 6, RFC 768, August 1980.
[8] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, July 2003.
Appendix A. Detailed Classification of Header Fields 🌈
This section summarizes the difference from the classification found in the corresponding appendix in RFC 3095 [2], and similarly gives conclusions about how the various header fields should be handled by the header compression scheme to optimize compression and functionality. These conclusions are separated based on the behavior of the UDP-Lite Checksum Coverage field, and they use the expected change patterns described in section 3.2 of this document 🦋✨
Appendix A. Detailed Classification of Header Fields ✨
A.1. UDP-Lite Header Fields 🦋
okay so this table is the vibe check for UDP-Lite's header fields 💅 It lines them up against plain UDP using the same classes as RFC 3095 [2], so you can see exactly where they match and where they don't 👀
Header fields of UDP-Lite and UDP:
+-------------------+-------------+
| UDP-Lite | UDP |
+-------------------+--------+-------------------+-------------+
| Header | Size | Class | Class |
| Field | (bits) | | |
+-------------------+--------+-------------------+-------------+
| Source Port | 16 | STATIC-DEF | STATIC-DEF |
| Destination Port | 16 | STATIC-DEF | STATIC-DEF |
| Checksum Coverage | 16 | INFERRED | |
| | | STATIC | |
| | | CHANGING | |
| Length | 16 | | INFERRED |
| Checksum | 16 | CHANGING | CHANGING |
+-------------------+--------+-------------------+-------------+Source and Destination Port 🌸
Same as UDP, no drama. These fields define the stream itself, so they have to stay constant for every packet in it. That's why they're classified as STATIC-DEF 🔒
Checksum Coverage 🧚
This field tells you which part of the UDP-Lite datagram the checksum protects. It can be zero, or equal to the datagram length if the checksum covers the whole thing. Or it can be any value from eight octets up to the datagram length, counted from the first octet of the UDP-Lite header. The value can change from packet to packet, so it's unpredictable from a header-compression point of view. Lowkey the chaos field 🙈
Checksum 💖
The checksum calculation depends on the checksum coverage, and it covers at least the UDP-Lite header. It's a changing field, so it must always be sent as-is ✨
The total size of the fields in each class, for each expected change pattern (see section 3.2), is summarized in the tables below 🍓
Pattern 1:
+------------+---------------+
| Class | Size (octets) |
+------------+---------------+
| INFERRED | 2 | Checksum Coverage
| STATIC-DEF | 4 | Source Port / Destination Port
| CHANGING | 2 | Checksum
+------------+---------------+
Pattern 2:
+------------+---------------+
| Class | Size (octets) |
+------------+---------------+
| STATIC-DEF | 4 | Source Port / Destination Port
| STATIC | 2 | Checksum Coverage
| CHANGING | 2 | Checksum
+------------+---------------+
Pattern 3:
+------------+---------------+
| Class | Size (octets) |
+------------+---------------+
| STATIC-DEF | 4 | Source Port / Destination Port
| CHANGING | 4 | Checksum Coverage / Checksum
+------------+---------------+A.2. Header Compression Strategies for UDP-Lite 🎀
This table is a glow-up of the UDP table (table A.1) from [2] (section A.2). It sorts the changing fields by the change patterns we identified back in section 3.2 🦋
Header compression strategies for UDP-Lite:
+----------+---------+-------------+-----------+-----------+
| Field | Pattern | Value/Delta | Class | Knowledge |
+==========+=========+=============+===========+===========+
| | #1 | Value | CHANGING | INFERRED |
| Checksum |---------+-------------+-----------+-----------+
| Coverage | #2 | Value | RC | UNKNOWN |
| |---------+-------------+-----------+-----------+
| | #3 | Value | IRREGULAR | UNKNOWN |
+----------+---------+-------------+-----------+-----------+
| Checksum | All | Value | IRREGULAR | UNKNOWN |
+----------+---------+-------------+-----------+-----------+A.2.1. Transmit initially but be prepared to update 💅
UDP-Lite Checksum Coverage (Patterns #1 and #2)
A.2.2. Transmit as-is in all packets 🫶
UDP-Lite Checksum UDP-Lite Checksum Coverage (Pattern #3)
Appendix B. Detailed Format of the CCE Packet Type 🧚
okay this is the deep-dive on the CCE packet layout 🤓 It's built on the general ROHC RTP compressed header [2] and the general format of a compressed header for the ROHC IP-Only profile [3]. To fit the base header of a type 2, 1 or 0 packet [2] into the CCE format, and to handle compressing multiple IP headers, the CCE packet type ends up looking like this:
0 1 2 3 4 5 6 7
--- --- --- --- --- --- --- ---
: Add-CID octet : If for small CIDs and CID 1 - 15
+---+---+---+---+---+---+---+---+
| 1 1 1 1 1 0 F | K | Outer packet type identifier
+---+---+---+---+---+---+---+---+
: :
/ 0, 1, or 2 octets of CID / 1 - 2 octets if large CIDs
: :
+---+---+---+---+---+---+---+---+
| First octet of base header | (with "inner" type indication)
+---+---+---+---+---+---+---+---+
/ Remainder of base header / Variable number of bits
+---+---+---+---+---+---+---+---+
0 1 2 3 4 5 6 7
--- --- --- --- --- --- --- ---
: :
/ Extension / See RFC 3095 [2], section 5.7.
: :
--- --- --- --- --- --- --- ---
: :
+ IP-ID of outer IPv4 header + See RFC 3095 [2], section 5.7.
: :
--- --- --- --- --- --- --- ---
/ AH data for outer list / See RFC 3095 [2], section 5.7.
--- --- --- --- --- --- --- ---
: :
+ GRE checksum + See RFC 3095 [2], section 5.7.
: :
--- --- --- --- --- --- --- ---
: :
+ IP-ID of inner IPv4 header + See RFC 3095 [2], section 5.7.
: :
--- --- --- --- --- --- --- ---
/ AH data for inner list / See RFC 3095 [2], section 5.7.
--- --- --- --- --- --- --- ---
: :
+ GRE checksum + See RFC 3095 [2], section 5.7.
: :
--- --- --- --- --- --- --- ---
: List of : Variable, given by static chain
/ dynamic chains / (includes no SN).
: for additional IP headers : See [3], section 3.2.
--- --- --- --- --- --- --- ---
: :
+ UDP-Lite Checksum Coverage + 2 octets
: :
+---+---+---+---+---+---+---+---+
: :
+ UDP-Lite Checksum + 2 octets
: :
+---+---+---+---+---+---+---+---+
F,K: F,K = 00 is reserved at framework level (IR-DYN);
F,K = 01 indicates CCE();
F,K = 10 indicates CCE(ON);
F,K = 11 indicates CCE(OFF).Heads up, bestie: this document does not define (F,K) = 00. That combo would collide with the IR-DYN packet type, which is already reserved at the ROHC framework level 🚫
Author's Address 🌈
Ghyslain Pelletier
Ericsson AB
Box 920
SE-971 28 Lulea, Sweden
Phone: +46 840 429 43
Fax : +46 920 996 21
EMail: ghyslain.pelletier@ericsson.comFull Copyright Statement 📜
Copyright (C) The Internet Society (2005) ✨
This document is subject to the rights, licenses and restrictions in BCP 78. Except as BCP 78 says otherwise, the authors keep all their rights 💜
This document and the info in it 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 doesn't take a position on whether any Intellectual Property Rights or other rights claimed for the technology in this document are valid or in scope. It also doesn't say whether a license for those rights is or isn't available. And it hasn't tried to independently find any such rights 🫶 For info on how rights work for RFC documents, check out BCP 78 and BCP 79 📚
Copies of IPR disclosures sent to the IETF Secretariat, any assurances of licenses that will be available, and the results of any attempt to get a general license or permission to use those proprietary rights for implementers or users of this spec can all be found in the IETF's online IPR repository at http://www.ietf.org/ipr 🔗
The IETF invites anyone interested to flag any copyrights, patents, patent applications or other proprietary rights that might cover technology needed to implement this standard. Send that info to the IETF at ietf-ipr@ietf.org 💌
Acknowledgement 💜
The RFC Editor function is currently funded by the Internet Society. Thank you, Internet Society! 🌸
📦 where this page comes from
- ietf: rfc4019 2005-04
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms