RFC 3759
RObust Header Compression (ROHC): Terminology and Channel Mapping Examples
RFC 3759: RObust Header Compression (ROHC): Terminology and Channel Mapping Examples 🎀
Okay bestie, this one is from the Network Working Group, written by L-E. Jonsson at Ericsson, dated April 2004. It's RFC 3759 and it's Informational, so it's giving "here's some helpful info" rather than a standard 💅 It updates RFC 3095, and the title block doesn't list anything it obsoletes. Lowkey iconic that it exists just to make 3095 easier to read ✨
Status of This Memo 🌈
This memo gives information to the Internet community. It is not an Internet standard of any kind, and it can be shared without any limits 🦋
Copyright Notice 💜
Copyright (C) The Internet Society (2004). All Rights Reserved.
Abstract 🌸
Okay so this doc is here to clear up the terms and concepts from RFC 3095, which is a Proposed Standard framework with profiles for RObust Header Compression (ROHC) 🧚 3095 introduces a bunch of ideas that are honestly kind of confusing, especially when you try to connect them to the networks where header compression actually gets used. This doc breaks down those parts of ROHC and talks about terms like ROHC instances, ROHC channels, ROHC feedback, and ROHC contexts. It also explains how those terms line up with other stuff like network elements and IP interfaces, which people use all the time when they're dealing with MIB issues 🔥
Table of Contents 💅
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology. . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. ROHC External Terminology. . . . . . . . . . . . . . . . . . . 6
3.1. Network Elements and IP Interfaces . . . . . . . . . . . 6
3.2. Channels . . . . . . . . . . . . . . . . . . . . . . . . 7
3.3. A Unidirectional Point-to-Point Link Example . . . . . . 8
3.4. A Bi-directional Point-to-Point Link Example . . . . . . 8
3.5. A Bi-directional Multipoint Link Example . . . . . . . . 9
3.6. A Multi-Channel Point-to-Point Link Example. . . . . . . 9
4. ROHC Instances . . . . . . . . . . . . . . . . . . . . . . . . 10
4.1. ROHC Compressors . . . . . . . . . . . . . . . . . . . . 11
4.2. ROHC Decompressors . . . . . . . . . . . . . . . . . . . 12
5. ROHC Channels. . . . . . . . . . . . . . . . . . . . . . . . . 13
6. ROHC Feedback Channels . . . . . . . . . . . . . . . . . . . . 14
6.1. Single-Channel Dedicated ROHC FB Channel Example . . . . 14
6.2. Piggybacked/Interspersed ROHC FB Channel Example . . . . 15
6.3. Dual-Channel Dedicated ROHC FB Channel Example . . . . . 16
7. ROHC Contexts. . . . . . . . . . . . . . . . . . . . . . . . . 17
8. Summary. . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
9. Implementation Implications. . . . . . . . . . . . . . . . . . 18
10. Security Considerations. . . . . . . . . . . . . . . . . . . . 19
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 19
12. Informative References . . . . . . . . . . . . . . . . . . . . 19
13. Author's Address . . . . . . . . . . . . . . . . . . . . . . . 19
14. Full Copyright Statement . . . . . . . . . . . . . . . . . . . 201. Introduction 🦋
Okay so RFC 3095 is where the ROHC standard framework lives, and it comes with 4 compression profiles [RFC-3095]. There are a lot of concepts in there that aren't super well defined or explained, and that can make the whole thing feel like a maze 😭 It gets even more confusing when you think about how ROHC fits into the surrounding environments where header compression might get used.
So the point of this doc is to clear all that up with examples and extra terminology, talking about ROHC instances, ROHC channels, ROHC feedback, and ROHC contexts. It especially wants to show how those terms connect to things like network elements and IP interfaces, which people bring up a lot when they're working on MIB issues. One big goal here is to support and simplify the ROHC MIB development work, bestie 🫶
Sections 3 to 8 are the main part of the doc, and they're all about the conceptual stuff, how the entities relate to each other, and the terminology of ROHC [RFC-3095]. Section 9 then goes through some implementation implications that come out of those concepts 🌟
2. Terminology 💖
ROHC instance
A ROHC instance is a logical entity that does header compression or decompression according to one or several ROHC profiles. It's either a ROHC compressor instance or a ROHC decompressor instance. See section 4.
ROHC compressor instance
A ROHC compressor instance is a logical entity that does header compression according to one or several ROHC profiles. It has a one-to-one relationship with a ROHC channel, and the ROHC compressor sits at the input end of that channel. See section 4.1.
ROHC decompressor instance
A ROHC decompressor instance is a logical entity that does header decompression according to one or several ROHC profiles. It also has a one-to-one relationship with a ROHC channel, and the ROHC decompressor sits at the output end of that channel. See section 4.2.
Corresponding decompressor
When we talk about a compressor's corresponding decompressor, we mean the peer decompressor at the other end of the ROHC channel where the compressor sends its compressed header packets. In other words, it's the decompressor that decompresses the headers the compressor compressed 🎀
Corresponding compressor
When we talk about a decompressor's corresponding compressor, we mean the peer compressor at the other end of the ROHC channel where the decompressor gets its compressed header packets. So it's the compressor that compresses the headers the decompressor decompresses ✨
ROHC peers
A ROHC compressor and its corresponding ROHC decompressor are called ROHC peers. Best friends forever 👯♀️
Link
A communication path between two network entities is generally called a link in this document 🔗
Bi-directional compression
If there's a way to send feedback information from a decompressor back to its corresponding compressor, the compression performance can get better. This way of operating, which uses that feedback to improve compression performance, is called bi-directional compression 🔥
Unidirectional compression
If there's no way to send feedback information from a decompressor to its corresponding compressor, the compression performance might not be as good as it could be if feedback was available. This way of operating, which doesn't use feedback to improve compression performance, is called unidirectional compression 🙈
ROHC channel
When a ROHC compressor has turned the original packets into ROHC packets with compressed headers, those ROHC packets get sent to the corresponding decompressor through a logical point-to-point connection that's dedicated to that traffic. A logical channel like that only has to carry data in one direction, from compressor to decompressor, and it's called a ROHC channel. See section 5.
ROHC feedback channel
To allow bi-directional compression, a logical point-to-point connection has to be set up for feedback data going from the decompressor to its corresponding compressor. A logical channel like that only has to carry data in one direction, from decompressor to compressor, and it's called a ROHC feedback channel. See section 6.
Co-located compressor/decompressor
A minimal ROHC instance is only a compressor or only a decompressor. It talks to its corresponding decompressor or compressor peer at the other end of a ROHC channel, so it only handles packet streams going in one direction over the link. But in lots of cases the link carries packet streams both ways, and it would be nice to do header compression in both directions too. That needs both a ROHC compressor and a ROHC decompressor at each end of the link, and each pair is called a co-located compressor/decompressor pair 💜
Associated compressor/decompressor
If there's a co-located ROHC compressor/decompressor pair at each end of a link, feedback messages can go from a ROHC decompressor back to its corresponding compressor by creating a virtual ROHC feedback channel inside the compressed header packets. Those packets go from the co-located ROHC compressor to the decompressor that sits with the compressor at the other end. When a co-located pair is connected like this, they're said to be associated with each other 👑
Interspersed feedback
Feedback going from a ROHC decompressor to a ROHC compressor can either be sent on a separate ROHC feedback channel that's dedicated to feedback packets, or it can be sent among the compressed header packets going the other way, from a co-located (associated) compressor to a similarly co-located decompressor at the other end of the link. If the feedback packets are sent in that second way as stand-alone packets, it's called interspersed feedback. See section 6.2 for an example 🧚
Piggybacked feedback
Feedback going from a ROHC decompressor to a ROHC compressor can either be sent on a separate ROHC feedback channel that's dedicated to feedback packets, or it can be sent among the compressed header packets going the other way, from a co-located (associated) compressor to a similarly co-located decompressor at the other end of the link. If the feedback packets are sent in that second way and get encapsulated inside the compressed header packets going the other direction, it's called piggybacked feedback. See section 6.2 for an example 🍓
Dedicated feedback channel
A dedicated feedback channel is a logical layer two channel that goes from a ROHC decompressor to a ROHC compressor, and it's only used to carry feedback packets. See sections 6.1 and 6.3 for examples 💅
3. ROHC External Terminology 🌸
Okay so when we think about the parts of ROHC that touch the networking environment where header compression might be applied, things get confusing really fast. That's mostly because there isn't a common, well understood, well defined set of terms for it 😭 One of the main goals of this doc is to set the preferred terminology for talking about how header compression fits into network integration issues ✨
3.1. Network Elements and IP Interfaces ✨
okay so header compression happens over certain links, between two communicating entities in a network 🌸 people call these entities "nodes", "network devices", or "network elements", and they all basically mean the same thing 💅 but network management folks prefer "network element", so that's the term we're sticking with for the rest of the doc 🫶
a network element talks through one or several network interfaces, and those are often managed, as defined by MIB specifications 🦋 in all IP internetworking, every one of those interfaces has its own IP identity 🔥 this gives us a common network interface abstraction that doesn't care what link technology is hiding underneath 🧚 from here on, we'll call these interfaces "IP interfaces" 💖
so to picture it, the top level of a network element looks like this, with one or several IP interfaces:
+-----------------------------------------------------+
| Network Element |
+---------------+--+---------------+------------------+
| IP | | IP |
| Interface | | Interface |
+---------------+ +---------------+ ...next section builds on this hierarchy by looking at what's below an IP interface 👑
3.2. Channels 🦋
as we just mentioned, an IP interface can sit on top of almost any link technology 🌈 different link technologies have different characteristics and communicate in different ways, but they ALL share one superpower: they can send and/or receive data to and from the IP interface 💜 the easiest way to picture this shared ability is as one or several logical communication channels provided by the link, where each channel is either bi-directional or unidirectional 🎀 these logical point-to-point connections are what we're calling "channels" from here on, either bi-directional or unidirectional ✨ heads up that this definition of "channels" is less restrictive than "ROHC channels", which show up in section 5 💅
so if we extend the network element hierarchy with channels, it becomes this:
+-----------------------------------------------------+
| Network Element |
+---------------+--+---------------+------------------+
| IP | | IP |
| Interface | | Interface |
++ +-+ +-+ +----+ ++ +-+ +-+ +----+ ...
|C| |C| |C| |C| |C| |C|
|h| |h| |h| |h| |h| |h|
|a| |a| |a| |a| |a| |a|
|n| |n| |n| ... |n| |n| |n| ...
|n| |n| |n| |n| |n| |n|
|e| |e| |e| |e| |e| |e|
|l| |l| |l| |l| |l| |l|
: : : : : : : : : : : :whether there's more than one channel, and whether those channels are bi-directional or unidirectional (or a mix!) depends on the link technology 🌸 so does how the channels get logically created 🙈
the next subsections, 3.3-3.6, go through a bunch of different link examples and connect them back to these general descriptions 💖 each one also talks about how header compression might be applied in that case 🧚 the core questions for header compression are:
- Are channels bi- or unidirectional?
- Is the link point-to-point? If not, a lower layer addressing scheme is needed to create logical point-to-point channels.
quick heads up: these subsections talk about header compression in general, while later sections go deeper into ROHC 🔥 and in those later sections, the general channel definition gets a little upgrade for header compression, with the ROHC channel (section 5) and the ROHC feedback channel (section 6) 👑 here, though, we're just using the basic channel concept we defined above 💅
3.3. A Unidirectional Point-to-Point Link Example 🌈
the simplest link example you can come up with from the overview above is one single unidirectional channel between two communicating network elements 🦋
+-----------------+ +-----------------+
| Network Element | | Network Element |
+-----------------+ +-----------------+
| IP | | IP |
| Interface | | Interface |
+------+ +------+ +------+ +------+
| | | |
| +--------------------------------+ |
| -> Unidirectional channel -> |
+----------------------------------------+a typical example of a point-to-point link with one unidirectional channel like this is a satellite link 🛰️✨ and since there's no return path, only unidirectional header compression can be applied here 🙅♀️
3.4. A Bi-directional Point-to-Point Link Example 💜
taking the last example one step further, the natural extension is one single bi-directional channel between two communicating network elements 💖 there are still only two endpoints and one channel, but this time the channel is enhanced to allow communication in both directions 🎀
+-----------------+ +-----------------+
| Network Element | | Network Element |
+-----------------+ +-----------------+
| IP | | IP |
| Interface | | Interface |
+------+ +------+ +------+ +------+
| | | |
| +--------------------------------+ |
| <-> Bi-directional channel <-> |
+----------------------------------------+a typical example of a point-to-point link with a bi-directional channel like this is a PPP modem connection over a regular telephone line 📞 header compression can easily be applied here too, as it's usually done over e.g., PPP 🫶 and the compression scheme can make use of the return path to improve compression performance 🚀
3.5. A Bi-directional Multipoint Link Example 🌸
okay now we're leaving the simple point-to-point examples behind 🦋 this section covers a bi-directional link connecting more than two communicating network elements 💅 to keep things simple, we're looking at the case with three endpoints 🧚
+-----------------+ +-----------------+ +-----------------+
| Network Element | | Network Element | | Network Element |
+-----------------+ +-----------------+ +-----------------+
| IP | | IP | | IP |
| Interface | | Interface | | Interface |
+------+ +------+ +------+ +------+ +------+ +------+
| | | | | |
| | | | | |
| +-----------------+ +-----------------+ |
| <-> Bi-directional "shared channel" <-> |
+-----------------------------------------------+a typical example of a multipoint link with a bi-directional "shared channel" is Ethernet 🌐 since the channel is shared, applying header compression would require a lower layer addressing scheme to provide logical point-to-point channels, according to the definition of "channels" 💖
aside, but it matters: a case of unidirectional multipoint links is basically the same as a bunch of unidirectional point-to-point links 🙈 in that case, each receiver only sees one single sender, and the sender's behavior is independent of the number of receivers and is unaffected by their behavior 🫶
3.6. A Multi-Channel Point-to-Point Link Example 👑
this last example is a scenario that's expected to be typical in lots of environments where ROHC will be applied 🔥 the key point is the multi-channel property, which is common in cellular environments, for example 📶 data through the same IP interface might be transmitted on different channels depending on its characteristics 🎀 in the example below there are three channels: one bi-directional, and one unidirectional in each direction 💜 but the channel configuration could of course be arbitrary ✨
+-----------------+ +-----------------+
| Network Element | | Network Element |
+-----------------+ +-----------------+
| IP | | IP |
| Interface | | Interface |
+-+ +---+ +---+ +-+ +-+ +---+ +---+ +-+
| | | | | | | | | | | |
| | | | | +--------------------------+ | | | | |
| | | | | <- Unidirectional channel <- | | | | |
| | | | +------------------------------+ | | | |
| | | | | | | |
| | | | | | | |
| | | +--------------------------------------+ | | |
| | | <-> Bi-directional channel <-> | | |
| | +------------------------------------------+ | |
| | | |
| | | |
| +--------------------------------------------------+ |
| -> Unidirectional channel -> |
+------------------------------------------------------+as mentioned above, a typical example of a multi-channel link is a cellular wireless link 📱 in this example, header compression would be applicable on a per-channel basis, for each channel operating either bi-directionally or unidirectionally, depending on the channel properties 🌈
4. ROHC Instances 🧚
okay so for stuff like network management on an IP interface that implements ROHC, you need to be able to identify all the various ROHC entities that might be present on that interface 🔍 the smallest possible ROHC entity is what we're calling a "ROHC instance" 💖 a ROHC instance can be one of two types: a "ROHC compressor" or a "ROHC decompressor" instance 🦋 and an IP interface can have N ROHC compressors and M ROHC decompressors, where N and M are arbitrary numbers 🌸 it's worth noting that although a compressor is often co-located with a decompressor, a ROHC instance can NEVER include both a compressor and a decompressor 🙅♀️ where both are present, they'll be referred to as two ROHC instances 👑
the following two subsections describe the two kinds of ROHC instances and their external interfaces 💅 sections 5 and 6 then cover how communication over those interfaces actually happens, through "ROHC channels" and "ROHC feedback channels" 🎀 and section 7 builds on top of the instance, channel and feedback channel concepts and explains how ROHC contexts map onto all of that 🫶
one more thing: all figures in sections 4-6 have been rotated 90 degrees to make them easier to draw, which means they do NOT show a "stack view" 🌈
4.1. ROHC Compressors
okay so a ROHC compressor instance can do header compression using one or several ROHC profiles 💅 Apart from any configuration or control interfaces (those are a whole other vibe 🙈), a compressor instance sends and receives data through 3 inputs and 1 output. Here's the picture:
+--------------+
-> UI -> | | -> CO ->
| ROHC |
| Compressor |
-> PI -> | | <- FI <-
+--------------+- Uncompressed Input (UI): uncompressed packets get delivered from higher layers to the compressor through the UI 📦
- Compressed Output (CO): compressed packets leave the compressor through the CO, which is always connected to the input end of a ROHC channel (see section 5) 🚀
- Feedback Input (FI) [optional]: feedback from the corresponding decompressor comes into the compressor through the FI. If it's present, it's connected to the output end of a ROHC feedback channel of some kind (see section 6). When there's no way to transmit feedback from decompressor to compressor, FI is not used, and bi-directional compression will not be possible 😭
- Piggyback Input (PI) [optional]: if the compressor is associated with a co-located decompressor, and that decompressor sends feedback to the other end of the link, the feedback data for piggybacking gets delivered to the compressor through the PI. If this input is used, it's connected to the FO of the co-located decompressor (see section 4.2) 🫶
4.2. ROHC Decompressors
A ROHC decompressor instance supports header decompression according to one or several ROHC profiles ✨ Apart from any configuration or control interfaces, a decompressor instance receives and sends data through 1 input and 3 outputs. Check out the figure:
+--------------+
-> CI -> | | -> DO ->
| ROHC |
| Decompressor |
<- FO <- | | -> PO ->
+--------------+- Compressed Input (CI): compressed packets are received by the decompressor through the CI, which is always connected to the output end of a ROHC channel (see section 5) 📥
- Decompressed Output (DO): decompressed packets are delivered from the decompressor to higher layers through the DO 🎁
- Feedback Output (FO) [optional]: feedback to the corresponding compressor is sent from the compressor through the FO. If it's present, it's connected to the input end of a ROHC feedback channel of some kind (see section 6). When there's no means to transmit feedback from decompressor to compressor, FO is not used, and bi-directional compression will not be possible 💀
- Piggyback Output (PO) [optional]: if the decompressor is associated with a co-located compressor, and it delivers feedback to that compressor that it received piggybacked from the other end of the link, the received feedback data is delivered from the decompressor through the PO. If this output is used, it's connected to the FI of the co-located compressor (see section 4.1) 🌸
5. ROHC Channels
Remember how section 3 introduced the general concept of channels? 🦋 By that definition, a channel is basically a logical point-to-point connection between the IP interfaces of two communicating network elements. So a channel represents the kind of logical connection needed to make header compression generally applicable, and then the channel properties control whether compression can operate in a unidirectional or bi-directional manner.
The channel concept is great for general header compression discussions, but since it groups unidirectional and bi-directional connections together, it doesn't describe the details of how ROHC logically works. So for ROHC, the channel concept gets enhanced, and we get a more restricted concept of "ROHC channels" 💅
A ROHC channel has the same properties as a channel, with one difference: a ROHC channel is always unidirectional. It has one single input endpoint, connected to the CO of one single ROHC compressor instance, and one single output endpoint, connected to the CI of one single ROHC decompressor instance. A ROHC channel must be logically dedicated to one ROHC compressor and one ROHC decompressor, which are called ROHC peers. That makes a one-to-one mapping between a ROHC channel and two ROHC compressor/decompressor peers 🎀
+--------------+ --->-->-->-->--- +--------------+
| | -> CO -> ROHC Channel -> CI -> | |
| ROHC | --->-->-->-->--- | ROHC |
| Compressor | | Decompressor |
| | | |
+--------------+ +--------------+In many cases the lower layer channel is bi-directional by nature 🌈 But for ROHC communication over that channel, a ROHC channel only represents one communication direction. So for a bi-directional channel, the common move is to logically allocate one ROHC channel in each direction, so ROHC compression can happen both ways. The reason ROHC channels are defined as unidirectional is basically to separate and generalize the concept of feedback, which section 6 explains and shows with examples 🧚
6. ROHC Feedback Channels
ROHC can be implemented over all sorts of links: unidirectional or bi-directional one-channel links, and multi-channel links too 🍓 To keep things flexible, the logical transmission of feedback from decompressor to compressor has been separated out from the transport of actual ROHC packets. ROHC channels are always unidirectional, from compressor to decompressor. So we need an additional channel concept just for feedback, and that's what we'll call "ROHC feedback channels" 🔥
A ROHC feedback channel is to the decompressor what a ROHC channel is to the compressor. It's a logically dedicated unidirectional channel from a ROHC decompressor to its corresponding ROHC peer compressor. A ROHC feedback channel has one single input endpoint, connected to the FO of one single ROHC decompressor instance, and one single output endpoint, connected to the FI of one single ROHC compressor instance.
+--------------+ +--------------+
| | | |
| ROHC | | ROHC |
| Compressor | --<--<--<--<--<-- | Decompressor |
| | <- FI <- ROHC FB Channel <- FO <- | |
+--------------+ --<--<--<--<--<-- +--------------+Why do this? It's about generality for handling feedback 👑 ROHC was designed with the assumption of logical separation, which gives flexibility in how feedback transport gets realized, as discussed in [RFC-3095, section 5.2.1]. There are no restrictions on how to implement a ROHC feedback channel, other than that it must be made available and logically dedicated to the ROHC peers if bi-directional compression operation is to be allowed.
The following subsections give some examples of how a ROHC feedback channel might be realized. They're not at all exhaustive, so don't treat them as the full list 💖
6.1. Single-Channel Dedicated ROHC Feedback Channel Example
This section illustrates a one-way compression example where one bi-directional channel has been configured to represent a ROHC channel in one direction and a dedicated ROHC feedback channel in the other direction 🦋
Bi-directional channel
..................
+--------------+ : -->-->-->-->-- : +--------------+
--> |UI CO| --> : ROHC Channel : --> |CI DO| -->
| ROHC | : -->-->-->-->-- : | ROHC |
| Compressor | : : | Decompressor |
| | : --<--<--<--<-- : | |
o |PI FI| <-- : FB Channel : <-- |FO PO| o
+--------------+ : --<--<--<--<-- : +--------------+
:................:In this example, feedback is sent on its own dedicated channel, as discussed in e.g., feedback realization example 1-3 of ROHC [RFC-3095, page 44]. So the piggybacking/interspersing mechanism of ROHC is not used, and the PI/PO connections are left open (marked with a "o") 🙈 To get ROHC compression working in a two-way manner using this approach, an identical configuration must be provided for the other direction, which means making use of four logical unidirectional channels 🌈
6.2. Piggybacked/Interspersed ROHC Feedback Channel Example 🦋
Okay so this one shows a bi-directional channel set up as one ROHC channel in each direction, but feedback still gets to hitch a ride through piggybacking and interspersing 🫶
Bi-directional channel
..................
+--------------+ : -->-->-->-->-- : +--------------+
--> |UI CO| --> : ROHC Channel A : --> |CI DO| -->
| ROHC | : -->-->-->-->-- : | ROHC |
| Compressor | : : | Decompressor |
| A | : : | A |
+-> |PI FI| <-+ : : +-- |PO FO| --+
| +--------------+ | : : | +--------------+ |
| | : : | |
| | : : | |
| +--------------+ | : : | +--------------+ |
+-- |FO PO| --+ : : +-> |FI PI| <-+
| ROHC | : : | ROHC |
| Decompressor | : : | Compressor |
| B | : --<--<--<--<-- : | B |
<-- |DO CI| <-- : ROHC Channel B : <-- |CO UI| <--
+--------------+ : --<--<--<--<-- : +--------------+
:................:So in this example, feedback rides along inside the compressed header packets on the ROHC channels, which is covered in feedback realization example 4-6 of ROHC [RFC-3095, page 44] ✨ Feedback from decompressor A going back to compressor A takes the route FO(A)->PI(B), gets piggybacked on a compressed packet over ROHC channel B, and then lands at compressor A through PO(B)->FI(A). The result is a logical ROHC feedback channel from the PI input at compressor B to the PO output at decompressor B 💅 Also, the PO and FO at the decompressors got swapped in this picture just to make it easier to draw, so don't freak out if they look flipped 🙈
6.3. Dual-Channel Dedicated ROHC Feedback Channel Example 🌈
In this one, two bi-directional channels are set up to carry two ROHC channels and two dedicated ROHC feedback channels, one pair for each direction 💜
Bi-directional channel
..................
+--------------+ : -->-->-->-->-- : +--------------+
->|UI CO| --> : ROHC Channel A : --> |CI DO|->
| ROHC | : -->-->-->-->-- : | ROHC |
| Compressor | : : | Decompressor |
| A | : : | A |
| | : : | |
+-> |FI PI| o : : o |PO FO| --+
| +--------------+ : --<--<--<--<-- : +--------------+ |
| +- : ROHC Channel B :<-+ |
| | : --<--<--<--<-- : | |
| +--------------+ | :................: | +--------------+ |
| <-|DO CI|<-+ +- |CO UI|<- |
| | ROHC | | ROHC | |
| | Decompressor | Bi-directional channel | Compressor | |
| | B | .................. | B | |
| | | : -->-->-->-->-- : | | |
| o|PO FO| --> : FB Channel B : --> |FI PI|o |
| +--------------+ : -->-->-->-->-- : +--------------+ |
| : : |
| : --<--<--<--<-- : |
+----------------------- : FB Channel A : <----------------------+
: --<--<--<--<-- :
:................:Here, feedback gets its very own dedicated channel in both directions, as covered in feedback realization example 1-3 of ROHC [RFC-3095, page 44] 🧚 Because of that, the piggybacking/interspersing mechanism of ROHC isn't used at all, so the PI/PO connections are left open, marked with an "o". Quick heads up: the FI/PI and PO/FO at the A-instances were swapped for drawing purposes, and the B-instances were horizontally mirrored, so just keep that in mind when you're reading the picture 🎀
7. ROHC Contexts ✨
Okay bestie, so earlier on it was established that one network element can have multiple IP interfaces, and one IP interface can have multiple ROHC instances running (not necessarily both compressors and decompressors). For every ROHC instance, there is exactly one ROHC channel and optionally one ROHC feedback channel 🫶 How those ROHC channels and feedback channels actually get realized depends on the layer two technology in use, so it's going to look different from case to case 👑
Each compressor or decompressor can also compress or decompress an arbitrary (but limited) number of concurrent packet streams that go over the ROHC channel attached to it. Every one of those streams is tied to a particular context in the compressor or decompressor 💅 When a compressed packet goes out over the ROHC channel, it gets labeled with a context identifier (CID) that says which context it belongs to. So the number of contexts a compressor or decompressor can hold maps one-to-one onto the CID space used in compressed packets on that ROHC channel. Here's the picture:
+------------------------------------------------------------------+
| IP Interface |
+---------------+----+---------------+----+---------------+--------+
| ROHC | | ROHC | | ROHC |
| Compressor | | Compressor | | Decompressor |
| Context 0...N | | Context 0...M | | Context 0...K | ...
+--+---------+--+ +--+---------+--+ +--+---------+--+
^ | ^ | : ^
: CID | : CID | : CID |
: 0...N | : 0...M | : 0...K |
: v : v v |
ROHC ROHC ROHC ROHC ROHC ROHC
Feedback Channel Feedback Channel Feedback Channel
Channel Channel ChannelHeads up: each ROHC instance at an IP interface gets its own context and CID space, so it must be ensured that the CID size of the corresponding decompressor at the other end of the ROHC channel is not smaller than the CID space of the compressor. Don't skip this one, it's a big deal 🙈
8. Summary 🌸
Okay, recap time! This document has introduced and defined a bunch of concepts and terms for ROHC network integration, and it explained how all the pieces fit together 💖 Here are the most important relationship takeaways, repeated in one handy list:
- A network element may have one or several IP interfaces.
- Each IP interface is connected to one or several logical layer two channels.
- Each IP interface may have one or several ROHC instances, either compressors, decompressors, or an arbitrary mix of both.
- For each ROHC instance, there is exactly one ROHC channel, and optionally exactly one ROHC feedback channel.
- How ROHC channels and ROHC feedback channels are realized through the available logical layer two channels will vary, so there is no general relation between ROHC instances and logical layer two channels. ROHC instances map only to ROHC channels and ROHC feedback channels.
- Each compressor owns its own context identifier (CID) space, which is the multiplexing mechanism it uses when sending compressed header packets to its corresponding decompressor. That CID space defines how many compressed packet streams can be concurrently sent over the ROHC channel allocated to the compressor/decompressor peers.
9. Implementation Implications 🔥
Here we're talking about how all the conceptual stuff above actually affects implementers of ROHC 👀
ROHC is defined as a general header compression framework, and compression profiles get defined on top of it for each specific set of headers you want to compress. The framework has a bunch of important mechanisms, but the split between framework and profiles is mainly a standardization thing. It tells you what has to be common to all profiles, what every profile has to define, and what's specific to each profile. So building the framework as a separate module isn't an obvious choice, especially if you want to mix profile implementations from different vendors 🧠 That said, optimized implementations will probably pull the common parts out into a ROHC framework module and then bolt profile modules onto it ✨
A ROHC instance might therefore be made up of various implementation modules, profiles, and possibly a common ROHC module, potentially coming from different vendors 🌈 If vendor and implementation version info is made available for network management purposes, it should be provided on a per-profile basis, and potentially for the instance as a whole too 💅
10. Security Considerations 💀
Okay, this part is serious, bestie. Having a clear picture of ROHC channels and how they relate to IP interfaces and the physical medium plays a critical role in using ROHC securely 🚨 That's why this document is a valuable companion to the Security Considerations in RFC 3095 and the other ROHC specifications. Still, since it only reviews information and definitions, it doesn't add any new security issues to the ROHC protocol specifications 🫶
11. Acknowledgements 💜
Huge thank-yous to Juergen Quittek, Hans Hannu, Carsten Bormann, and Ghyslain Pelletier for the fruitful discussions, improvement suggestions, and review 🦋 Thanks also to Peter Eriksson for doing a language review 🎀
12. Informative References 📚
[RFC-3095] 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.13. Author's Address 🌷
Lars-Erik Jonsson
Ericsson AB
Box 920
SE-971 28 Lulea
Sweden
Phone: +46 920 20 21 07
Fax: +46 920 20 20 99
EMail: lars-erik.jonsson@ericsson.com14. Full Copyright Statement ⭐
The copyright here belongs to The Internet Society (2004). This document is covered by the rights, licenses and restrictions in BCP 78, and except as set out there, the authors keep all of 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 ✨
okay so, the IETF is not picking a side on whether any IP rights (patents, copyrights, that whole legal drama 💅) apply to the tech in this doc, or whether you can get a license for them. it also hasn't gone hunting for those rights itself, so don't assume it did 🙈 if you want the rules on rights for RFCs, check out BCP 78 and BCP 79 📚
copies of IPR disclosures sent to the IETF Secretariat are a thing, and so are any licensing assurances, or the results of anyone trying to get a general license or permission to use those proprietary rights for implementers or users. all of that lives in the IETF online IPR repository at http://www.ietf.org/ipr 🦋
and this is the fun part: the IETF invites anyone to speak up if they know about copyrights, patents, patent applications, or other proprietary rights that might cover tech needed to implement this standard. just send it to ietf-ipr@ietf.org 💌 the whole community wants to hear about it, no cap 🫶
Acknowledgement
funding for the RFC Editor function is currently provided by the Internet Society 💜 shoutout to them for keeping the lights on ✨
📦 where this page comes from
- ietf: rfc3759 2004-04
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms