RFC 4164
RObust Header Compression (ROHC): Context Replication for ROHC Profiles
Title Block ✨
Okay bestie, here's the deal 💖 This RFC is RFC 4164, called RObust Header Compression (ROHC): Context Replication for ROHC Profiles. G. Pelletier from Ericsson wrote it as a Standards Track document, dated August 2005 🎀 The header doesn't list any Obsoletes or Updates entries, so it doesn't replace or change any older RFCs 🫶
Table of Contents
1. Introduction ....................................................3
2. Terminology .....................................................4
3. Context Replication for ROHC Profiles ...........................5
3.1. Robustness Considerations ..................................5
3.2. Replication of Control Fields ..............................5
3.3. Compressor States and Logic ................................6
3.3.1. Context Replication (CR) State ......................6
3.3.2. State Machine with Context Replication ..............7
3.3.3. State Transition Logic ..............................7
3.3.3.1. Selection of Base Context, Upward
Transition .................................8
3.3.3.2. Optimistic Approach, Upward Transition .....9
3.3.3.3. Optional Acknowledgements (ACKs),
Upward Transition ..........................9
3.3.3.4. Negative ACKs (NACKs), Downward
Transition .................................9
3.4. Decompressor Logic ........................................10
3.4.1. Replication and Context Initialization .............10
3.4.2. Reconstruction and Verification ....................10
3.4.3. Actions upon Failure ...............................11
3.4.4. Feedback Logic .....................................11
3.5. Packet Formats ............................................11
3.5.1. CRCs in the IR-CR Packet ...........................12
3.5.1.1. 7-bit CRC .................................13
3.5.1.2. 8-bit CRC .................................13
3.5.2. General Format of the IR-CR Packet .................13
3.5.3. Properties of the Base Context Identifier (BCID) ...15
4. Security Considerations ........................................15
5. Acknowledgements ...............................................15
6. References .....................................................16
6.1. Normative References ......................................16
6.2. Informative References ....................................16
Appendix A: General Format of the IR-CR Packet (Informative).......17
A.1. General Structure (Informative) ..........................17
A.2. Profile-Specific Replication Information (Informative) ...17
Appendix B: Inter-Profile Context Replication (Informative)........18
B.1. Defining Support for Inter-Profile Context Replication ...18
B.2. Compatibility between Different Profiles (Informative) ...19Status of This Memo 🌸
This document is an Internet standards track protocol for the Internet community, and it asks 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 💜
Okay so this doc defines context replication, which is basically a sidekick to the context initialization procedure in Robust Header Compression (ROHC) from RFC 3095 🧚 Profiles that support context replication can use this mechanism to set up a new context based on one that already exists. It's all about cutting down the overhead of context establishment 🔥 It's especially useful for compressing lots of short-lived flows that happen at the same time or close together, like short-lived TCP flows 😭
1. Introduction ✨
Bestie, there's often redundancy between the header fields of different flows going through the same compressor-decompressor pair 💖 So some of the info needed to set up the context for a new flow might already be sitting at the decompressor. Reusing that info and skipping some of the setup overhead, at both the compressor and the decompressor, is kind of the whole point 🎀
Reducing that overhead matters most when lots of short-lived connections (or flows) happen at once, or nearly at once, between the same compressor-decompressor pair 🌸 Each new packet stream needs most of its header info sent during initialization before the smaller compressed headers can even be used. So a bunch of short-lived connections can seriously eat into the overall gain from header compression 😭
Context replication lets some header fields get left out of the special Initiation and Refresh (IR) packet type that's defined just for replication 🦋 Those include the IP source and/or destination addresses, which are 16 octets each for IPv6. It also lets other fields, like the source and/or destination ports, be either left out or sent in compressed form starting from the very first packet of the header-compressed flow 💅
Context replication is defined here as a general ROHC mechanism 🌈 Its benefits aren't tied to any particular protocol, and support for it can be defined for any ROHC profile ✨
TCP compression is a big use case, since lots of TCP transfers are short-lived 🧚 A behavior analysis of TCP/IP header fields across multiple short-lived connections is in [5]. Also, [4] covers the considerations and requirements for the ROHC-TCP profile [3] so it can compress those short-lived TCP transfers efficiently 💜
Here's how it works: for profiles that support this, the compressor does context replication by reusing an existing context, called a base context, or by making a copy of it, and that becomes the replicated context 🫶 The replicated context then gets updated to match the header fields of the new flow. Next, the compressor sends the decompressor a packet that references the chosen base context, along with some data for the fields that need updating when the replicated context gets created. Finally, the decompressor creates the replicated context from the reference to the base context plus the uncompressed and compressed data in that packet 🔥
This document specifies the context replication procedure for ROHC profiles. It defines the general compressor and decompressor logic used during context replication, as well as the general format of the special IR packet that this procedure requires. Profiles that support context replication must further specify the specific format(s) of this packet 🎀
The fundamentals of the ROHC framework are in [2], and this doc assumes you already get them 🙈
2. Terminology 💖
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [1] 🌈
This document reuses some terminology from [2]. It also defines these terms 🧚
Base context 🌸
A base context is a context that has been validated by both the compressor and the decompressor 🦋 The compressor can use a base context as the reference when it builds a new context using replication 💅
Base CID (BCID) ✨
The Base Context Identifier is the CID used to identify the base context. Information needed for context replication can be extracted from it 💜
Context replication 🫶
Context replication is the mechanism that initializes a new context based on another existing context (a base context) 🔥
3. Context Replication for ROHC Profiles 🎀
For profiles that define support for it, context replication can be used as an alternative to the context initialization procedure in [2] 🌸 Note that for those profiles, only the decompressor is mandated to support context replication. Using the IR-CR packet is optional for the compressor 🙈
This section covers the compressor and decompressor logic, plus the general format of the IR packet used with context replication 🦋
3.1. Robustness Considerations 🌈
Context replication is different from the initialization procedure in [2] because it can reach a certain level of compression right from the first packet used to set up the context for a new flow ✨ So it's super important that the context replication procedure is robust 😭 That means a base context suitable for replication has to be used, the integrity of the initialization packet has to be guaranteed, and the result of the replication has to be verified 💅
The main tools for robustness are picking the base context (based on prior feedback from the decompressor) and using checksums 💜 To be specific, the compressor must get enough confidence that the base context it picked for replication is valid and available at the decompressor before it starts the replication procedure 🫶 So the most reliable way to pick a base context is to choose one where at least the static part to be replicated has already been acknowledged by the decompressor 🔥
Also, a CRC covering the info that initializes the context keeps the IR header used for replication intact 🎀 And finally, a second CRC calculated over the original uncompressed header lets the decompressor check the reconstructed header and whether the replication worked 🌸
3.2. Replication of Control Fields 🦋
Control fields are fields that either get sent from a ROHC compressor to a ROHC decompressor, or are inferred from how other fields behave. They aren't part of the uncompressed header itself 💅
They can control compression and decompression behavior, in particular which set of packet formats gets used 💜 Control fields are profile-specific. Examples include the NBO and RND flags in [2], which tell you whether the IP-ID field is in Network Byte Order and what kind of behavior the field has, respectively 🫶 Another example is the parameter that indicates the mode of operation in [2] 🌈
The IR-CR is different from the IR packet in [2]. Its purpose is to fully specify which part of the base context gets replicated, and to carry the extra info needed to create a new context 🧚 Because of that, a profile that supports the IR-CR packet SHOULD define, for each control field, whether the field's value is replicated from the base context to the new context or whether its value is reinitialized 🔥
Also, a compressor MUST NOT initiate context replication while a control field that isn't reinitialized by replication is being updated. For example, that happens during the handshake for a mode transition in [2] 😭🎀
3.3. Compressor States and Logic ✨
okay so ROHC normally kicks off in the IR state 🌸, where IR packets have to be sent to set up a brand new context at the decompressor. IR packets carry all the static and non-static fields of the original header in uncompressed form, plus some extra info 🎀. The compressor hangs out in the IR state until it has confidence that the decompressor actually got everything 🫶.
Context replication is an optional extra on top of that initialization process 💖. It defines a packet type, the IR packet for Context Replication (IR-CR), which can set up a new context. So the Context Replication (CR) state gets added to the compressor state machine to hold all the logic needed for IR-CR 🦋.
For profiles that support context replication, the compressor can go straight from the IR state to the CR state if there's already an existing context it can select as a base context for replication. Basically, that swaps out any IR/IR-DYN packets from context setup for a single IR-CR packet 💅.
3.3.1. Context Replication (CR) State
The CR state exists to set up a new context by reusing one that's already there 🧚. In this state, the compressor sends a mix of uncompressed and compressed info, along with a reference to a base context and some extra info. So header info for the fields being replicated doesn't get sent at all 🙈.
The compressor stays in the CR state until it's confident that the decompressor received the replication info correctly ✨.
3.3.2. State Machine with Context Replication
The compressor always starts in the lower compression state (IR), and moves to the context replication state (CR) as long as it can select a base context that's suitable for the flow being compressed (see also Section 3.3.3.1) 💜.
Moving from the CR state up to a higher compression state (e.g., the CO state for [3]) is based on the optimistic approach principle or on feedback received from the decompressor 🔥.
The figure below shows the additional state for the compressor. The details of the state transitions and compression logic are given in sub-sections following the figure 👑.
BCID selection Optimistic approach / ACK
+----->----->------+ +----->----->----->-----+
| | | |
| v | v
+---------+ +---------+ +-------------+
| IR | | CR | | Higher |
| state | | state | | order state |
+---------+ +---------+ +-------------+
^ |
| NACK / STATIC-NACK |
+---<-----<-----<----+Note that context replication is a complement to the normal initialization procedure for ROHC profiles that support it. Therefore, the compressor's transition to the CR state is an optional addition to the state machine, and it doesn't affect the existing transitions between the IR state and higher order state(s) 🌈.
3.3.3. State Transition Logic
Decisions about transitioning to and from the CR state are made by the compressor based on:
- availability of a base context
- positive feedback from the decompressor (Acknowledgements -- ACKs)
- negative feedback from the decompressor (Negative ACKs -- NACKs)
- confidence level regarding error-free decompression of a packet
Context replication is designed to operate over links where a feedback channel is available 📡. This is necessary to make sure the information used to create a new context is synchronized between the compressor and the decompressor. On top of that, context replication may also use feedback from the decompressor to the compressor for transitioning back to the IR state, and for OPTIONAL improved forward transition towards a state with a higher compression ratio 🍓.
The format that must be used by all profiles for the feedback field within the general ROHC format is specified in Section 5.2.2 of [2]. The feedback information comes in two possible formats: FEEDBACK-1 and FEEDBACK-2. FEEDBACK-2 can carry one of three types of feedback information: ACK, NACK, or STATIC-NACK 💜.
3.3.3.1. Selection of Base Context, Upward Transition
The compressor may start a transition from the IR state to the CR state when a suitable base context can be identified 🦋. To make this transition, the compressor selects a context that the decompressor has previously acknowledged as the base context. The selected context MUST have been acknowledged by the decompressor using the CRC option (see also [2], Section 5.7.6.3) in the feedback message. The static part of the base context to be replicated MUST have been acknowledged by the decompressor, and the base context MUST be valid at replication time 🔥.
This also means a compressor is not allowed to use the context replication mechanism if a feedback channel is not present 🙅. However, note that having a feedback channel can't guarantee that a base context selected for replication hasn't been corrupted after it was acknowledged, or that it's still part of the state managed by the decompressor when the IR-CR arrives 😬.
More specifically, RFC 3095 [2] defines the context identifier (CID) as a reference to the state information (i.e., the context) used for compression and decompression. Multiple packet streams, each with its own context, can share a channel, and the CID space along with its representation within packet formats may be negotiated as part of the channel state. However, because RFC 3095 [2] doesn't explicitly define context state management between compressor and decompressor, particularly for connection-oriented flows (e.g., TCP), you can only get a high degree of confidence when selecting a base context 🧐.
If feedback isn't used by the decompressor, the compressor may have to periodically transition back to the IR state 🔄. In that case, the same logic applies for transitioning back up to the higher order state via the CR state: a base context that was previously acknowledged and is suitable for replication must be re-selected.
The criteria for whether an existing context is a suitable base context for replication for a new flow are left up to implementations 🛠️.
Whenever the sequencing information from the last acknowledgement received is available, the compressor MAY use it to determine which fields can be replicated, so it avoids replicating any fields that have changed significantly from the state corresponding to the acknowledged packet 🎯.
3.3.3.2. Optimistic Approach, Upward Transition
Transitioning to a higher order state can be carried out according to the optimistic approach principle. This means the compressor may make an upward state transition when it's fairly confident the decompressor has received enough information to correctly decompress packets sent according to the higher compression state 🚀.
In general, there are many approaches the compressor can use to get that confidence. The compressor may get its confidence by sending several IR-CR packets with the same information 💅.
3.3.3.3. Optional Acknowledgements (ACKs), Upward Transition
An ACK may be sent by the decompressor to indicate that a context has been successfully initialized during context replication 🎉.
Once it receives an ACK, the compressor may assume that the context replication procedure was successful, and move from its initial state (e.g., the IR state) to a higher compression state 🦋.
3.3.3.4. Negative ACKs (NACKs), Downward Transition
A STATIC-NACK sent by the decompressor may indicate that the decompressor couldn't initialize a valid context during context replication, and that the corresponding context has been invalidated 💀.
Upon reception of a STATIC-NACK, the compressor MUST transit back to its initial no context state. The compressor SHOULD also refrain from sending IR-CR packets using the same base context, at least until an acknowledgement received after the STATIC-NACK makes this context suitable for replication (Section 3.3.3.1). The compressor SHOULD re-initialize the decompressor context using an IR packet 🔁.
A NACK sent by the decompressor may indicate that a valid context was successfully initialized, but the decompression of one or more subsequent packets failed 😭.
Upon reception of a NACK, the compressor MAY assume that the static part of the decompressor context is valid, but that the dynamic part is invalid. The compressor may take actions accordingly 🫧.
3.4. Decompressor Logic 🎀
3.4.1. Replication and Context Initialization
Once an IR-CR packet arrives, the decompressor first works out its content ([2], Section 5.2.6) 🔍. The profile indicated in the IR-CR packet determines how it gets processed. If the CRC (8-bit CRC) fails to verify the packet, the packet MUST be discarded 🚫.
If the profile indicated in the IR-CR packet defines the use of the Base CID, and its corresponding field is present within the packet format, this field is used to identify the base context. Otherwise, the CID is used 💜.
3.4.2. Reconstruction and Verification
The decompressor creates a new context using the information in the IR-CR packet together with the identified base context, and then decompresses the original header 🧩.
The CRC calculated over the original uncompressed header and carried within the profile-specific part of the IR-CR headers (7-bit CRC) MUST be used to verify decompression 🔐.
When decompression is verified and successful, the decompressor initializes or updates the context with the information received in the current header. The decompressor SHOULD send an ACK when it successfully validates the context as a result of decompressing one or more IR-CR packets 🥳.
Otherwise, if the reconstructed header fails the CRC check, changes (either initialization or update) to the context MUST NOT be performed. When the decompressor fails to validate the header, the actions specified in Section 3.4.3 are taken ⚠️.
3.4.3. Actions upon Failure ✨
okay so for profiles that support context replication, the decompressor's feedback logic works a lot like the context initialization logic from [2]. 🧚
here's the vibe: if the decompressor fails to validate the context after decompressing one or more initial IR-CR packets, it MUST invalidate the context and stay in its initial state 🙅♀️. it SHOULD also send a STATIC-NACK 📨. and if the decompressor is a strict memory manager (like, it deletes context state once a connection-oriented flow such as TCP is known to have ended), it SHOULD send STATIC-NACK in this case too 💅. otherwise the compressor might keep that CID around as a candidate for a future replication attempt, even though the decompressor has barely any state left for that CID to act as a Base CID. bestie, that's a whole mess 💀
if the context was successfully validated from one or more initial IR-CR packets, then the decompressor SHOULD send a NACK when it fails to verify the context after decompressing one or more later IR-CR packets 🔥.
3.4.4. Feedback Logic 🎀
the decompressor SHOULD use the CRC option (see [2], Section 5.7.6.3) when it sends feedback for an IR or an IR-CR packet 🫶.
3.5. Packet Formats 🦋
the IR-CR packet was designed with these constraints in mind:
a) it must be possible to either overwrite a CID during context replication, or to use a different CID than the Base CID for the replicated context; b) it must be possible to selectively include or exclude from the packet format some fields that may be replicable; c) it must be possible for some fields that may be replicable to be represented within the packet format using either a compressed or an uncompressed form; d) it must be possible for the decompressor to verify the success of the replication procedure; e) it is anticipated that profiles, other than ROHC-TCP [3], will also define support for context replication. Therefore it is desirable that the packet format be profile independent.
3.5.1. CRCs in the IR-CR Packet 🌸
the IR packet from [2] is used to communicate the static and/or dynamic parts of a context, and it typically initializes the context. for example, the static and dynamic chains of IR packets may contain an uncompressed representation of the original header 📦.
the IR packet format has an 8-bit CRC, calculated over the initial part of the IR packet. this CRC is meant to protect any info that initializes the context. specifically, its coverage always includes any CID information as well as the profile used to interpret the rest of the IR packet 🔐.
the whole point of the 8-bit CRC is to make sure the IR header itself is intact. profiles can extend the coverage of this CRC to the entire IR header, so you can verify the integrity of the whole uncompressed header. BUT since the IR packet format is shared by all ROHC profiles and gets verified during the initial processing of a ROHC decompressor (see [2], Section 5.2.6.), profiles may not redefine this CRC beyond the extent of its coverage 🙅♀️.
RFC 3095 [2] also defines a 3-bit CRC and a 7-bit CRC for compressed headers. these are used to verify proper decompression and validate the context. this type of CRC is calculated over the original uncompressed header, because protecting only the compressed data being exchanged isn't enough to make sure the original header gets rebuilt robustly 🧠.
so there's a clear difference in purpose between the 8-bit CRC in the IR packet and the 3-bit or 7-bit CRC in compressed headers. with context replication, the IR-CR packet can contain both compressed and uncompressed info, and it can leave out replicable fields entirely, so this distinction is no longer present 🤯.
profiles supporting context replication MUST define a CRC over the original uncompressed header as part of the profile-specific information in the IR-CR packet. this is necessary so a decompressor can verify that the replication process has succeeded ✅.
3.5.1.1. 7-bit CRC 💜
the 7-bit CRC in the IR-CR packet is calculated over all octets of the entire original header, before replication, in the same way described in Section 5.9.2 of [2].
the initial content of the CRC register is to be preset to all 1's. the CRC polynomial used for the 7-bit CRC in the IR-CR is:
C(x) = 1 + x + x^2 + x^3 + x^6 + x^73.5.1.2. 8-bit CRC 🍓
the coverage of the 8-bit CRC in the IR-CR packet is not profile dependent, unlike the ROHC IR(-DYN) packet (see [2], Sections 5.2.3 and 5.2.4). it MUST cover the entire packet, excluding the payload. that includes the CID or any add-CID octet, plus the Base CID field if it's present. for profiles that make the Base CID optional in the IR-CR packet format, this CRC MUST also cover the info used to indicate whether this field is present 👀.
the initial content of the CRC register is to be preset to all 1's. the CRC polynomial used for the 8-bit CRC in the IR-CR is:
C(x) = 1 + x + x^2 + x^83.5.2. General Format of the IR-CR Packet 👑
the context replication mechanism needs a dedicated IR packet format that uniquely identifies the IR-CR packet. this packet communicates the static and dynamic parts of the replicated context, and it may also communicate a reference to a base context 🫧.
the IR packet type from [2] is extensible, so replication support can be added through the profile-specific part of the IR packet. there's one bit, (x), left in the IR header for "Profile specific information", and its definition is profile specific. so profiles supporting context replication MAY use this bit as a flag that says whether the packet is an IR packet or an IR-CR packet. profiles may also define an alternative way to identify the IR-CR packet within the profile-specific information, instead of using this bit 🌈.
the IR-CR header associates a CID with a profile and initializes the context using the context replication mechanism. it is not recommended to use this packet to repair a damaged context 🙈.
the IR-CR has the following general format:
0 1 2 3 4 5 6 7
--- --- --- --- --- --- --- ---
: Add-CID octet : if for small CIDs and (CID != 0)
+---+---+---+---+---+---+---+---+
| 1 1 1 1 1 1 0 x | IR type octet
+---+---+---+---+---+---+---+---+
: :
/ 0-2 octets of CID / 1-2 octets if for large CIDs
: :
+---+---+---+---+---+---+---+---+
| Profile | 1 octet
+---+---+---+---+---+---+---+---+
| CRC | 1 octet
+---+---+---+---+---+---+---+---+
| |
/ Profile-specific information / variable length
| |
- - - - - - - - - - - - - - - -
| |
/ Payload / variable length
| |
- - - - - - - - - - - - - - - -- x: Profile-specific information. Interpreted according to the profile indicated in the Profile field.
- Profile: The profile to be associated with the CID. In the IR-CR packet, the profile identifier is abbreviated to the 8 least significant bits (LSBs). It selects the highest-number profile in the channel state parameter PROFILES that matches the 8 LSBs given (see also [2]).
- CRC: 8-bit CRC computed using the polynomial of Section 3.5.1.2.
- Profile-specific information: The contents of this part of the IR-CR packet are defined by the individual profiles. This information is interpreted according to the profile indicated in the Profile field. It MUST include a 7-bit CRC over the original uncompressed header using the polynomial of Section 3.5.1.1. It also includes the static and dynamic subheader information used for replication; thus, which header fields are replicated and their respective encoding methods are outside the scope of this document.
- Payload: The payload of the corresponding original packet, if any.
3.5.3. Properties of the Base Context Identifier (BCID) 🦄
the Base CID within the packet format of the IR-CR may be assigned a different value than the context identifier associated with the new flow (i.e., BCID != CID). otherwise, the base context gets overwritten with the new context by the replication process 💥.
when the channel uses small CIDs, a four-bit field within the packet format of the IR-CR minimally represents the BCID, with a value from 0 to 15. specifically, the four bits of Add-CID used with small CIDs [2] aren't needed for the BCID, since that info is already provided by the CID of the IR-CR packet itself. when large CIDs are used, the BCID is represented in the IR-CR with one or two octets, and it's coded the same way as a large CID [2] 🫶.
4. Security Considerations 🔥
this document adds an alternative mechanism for ROHC profiles to increase compression efficiency when initializing a new context, by reusing info that already exists at the decompressor. it does this by introducing new state transition logic, new feedback logic, and a new packet type. all of it is based on logic and packet formats already defined in RFC 3095 [2] 🧩.
so this document isn't believed to bring any additional weakness to the potential attacks already listed in [2]. however, it does increase the potential impact of these attacks, because it creates dependencies between multiple contexts. specifically, corruption of one context can make compressor attempts to initialize another context at the decompressor fail, or let the corruption spread to another context, if the compressor uses a corrupted context as a base for replication 😭🚨.
5. Acknowledgements 💖
the author would like to thank Richard Price, Kristofer Sandlund, Fredrik Lindstroem, Zhigang Liu, and HongBin Liao for their valuable input, as well as Mark West and Lars-Erik Jonsson, who also served as committed working group document reviewers 🫶🌸.
6. References ✨
6.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.
6.2. Informative References ✨
- [3] Pelletier, G., Jonsson, L-E., Sandlund, K., and M. West, "RObust Header Compression (ROHC): A Profile for TCP/IP (ROHC-TCP)", Work in Progress, July 2005.
- [4] Jonsson, L-E., "RObust Header Compression (ROHC): Requirements on TCP/IP Header Compression", RFC 4163, August 2005.
- [5] West, M. and S. McCann, "TCP/IP Field Behavior", Work in Progress, October 2004.
- [6] Finking, R. and G. Pelletier, "Formal Notation for Robust Header Compression (ROHC-FN)", Work in Progress, June 2005.
Appendix A: General Format of the IR-CR Packet (Informative) 💖
A.1. General Structure (Informative) 🌸
okay so this bit gives you an example of what the profile-specific info looks like inside the general IR-CR format. 🧚
0 1 2 3 4 5 6 7
+---+---+---+---+---+---+---+---+
| |
/ replication base information / variable length
| |
+---+---+---+---+---+---+---+---+
| |
/ replication information / variable length
| |
- - - - - - - - - - - - - - - -Replication base information: the contents of this part are defined by each individual profile. 💅 It gets interpreted according to whatever profile is named in the Profile field. It MUST include a 7-bit CRC over the original uncompressed header, using the polynomial from Section 3.4.1.1. See Appendix A.2. 🔥
Replication information: this part is also defined by the profiles, and it holds the static and dynamic subheader info used for replication. 🎀 How it's structured is profile specific. Profiles can use a chain structure (static and dynamic replication chains), or they can define header formats for replication (like ROHC-TCP [3]). iconic flexibility, honestly. ✨
A.2. Profile-Specific Replication Information (Informative) 🦋
this section gives a more detailed example of what the replication information field from Appendix A.1 could look like. 🫶
+---+---+---+---+---+---+---+---+
| B | CRC7 | 1 octet
+---+---+---+---+---+---+---+---+
| | present if B = 1,
/ Base CID / 1 octet if for small CIDs, or
| | 1-2 octets if for large CIDs
+---+---+---+---+---+---+---+---+B: B = 1 means the Base CID field is present. 🌈
CRC7: the CRC over the original, uncompressed, header. This 7-bit CRC is computed according to Section 3.4.1.1. 💜
Base CID: the CID that identifies the base context used for replication. 🍓
Appendix B: Inter-Profile Context Replication (Informative) 👑
context replication, as defined in this document, does not explicitly support replicating context between profiles. 🙈 It might still be of interest when someone is developing new compression profiles, though, so keep it in mind. ✨
inter-profile replication would need the decompressor to have access to data structures from the base context, which belongs to a profile different from the one doing the replicating. 💖 That info would have to be made available in a format consistent with the data structures and encoding method(s) in use for all header fields being replicated. bestie, that's a lot of consistency. 💀
B.1. Defining Support for Inter-Profile Context Replication 🧚
a ROHC profile describes how to compress a specific protocol stack, and it includes one or more sets of packet formats. 🌸 The packet formats usually compress protocol headers relative to a context of field values from previous headers in a flow. That context can also hold some control data. So the packet formats basically specify a mapping between the uncompressed and compressed versions of a protocol field. 🦋
that mapping happens through one or more encoding methods. These are simply functions that get applied to compress or decompress a field. An encoding method is defined using a name, a set of function parameters, and either a formal expression (using the ROHC-FN [6]) or a textual description (like the one in RFC 3095 [2]) of how it behaves. 💅
different profiles can define their packet formats with different encoding methods, or with a variant of a similar technique. 🌈 A typical example of the latter is list compression, like what's used for IP extension headers. So context entries for a field in a specific protocol stack can look different in content, representation, and structure from one profile to another. the vibes are just different, and that's okay. 🫶
because of all that, a profile that supports context replication can only use a base context from another profile that explicitly supports the concept of a base context. ✨ In other words, existing profiles that don't support this concept must be updated first, so they can export the context data entries they need in a meaningful representation during replication. 🔥
inter-profile context replication would specifically require that decompressor implementations (including existing ones) of other profiles get updated when a profile that uses context replication is added. 😭 So it can't be treated as an implementation-specific issue. main character problem, fr fr. 👑
the compressor has to know whether the decompressor supports inter-profile context replication before starting the procedure. 🎀 It also has to know which contexts (and which profile each belongs to) can be used as a base context. So a compressor can't start context replication using a base context from a different profile, unless that profile explicitly provides the proper mapping for its context entries, or that profile is formally defined using ROHC-FN [6] in a way that makes both profiles compatible. 💜 The set of profiles negotiated for the channel (see also RFC 3095 [2]) can then be used to figure out whether a context for a specific profile can serve as a base context. 🍓
B.2. Compatibility between Different Profiles (Informative) 🦋
compatibility between profiles, when replicating a field for a particular protocol stack, can be expressed like this: a field that's compressed by different profiles is compatible for inter-profile replication if it's defined in the set of packet formats using the same mapping function between its uncompressed and compressed versions. 🌸
for example, the IP Destination Address field. Based on the packet formats and compression strategies defined in RFC 3095 [2], it's implicitly compressed using an encoding method equivalent to the static() method defined in ROHC-FN [6]. 💖
for profiles that define their packet formats with a formal notation like ROHC-FN [6], two different encoding methods may not have the same name. 🙈 So a field from a protocol stack is said to be compatible for replication between two different profiles if it has an equivalent definition within each profile's packet formats. ✨
Author's Address 🎀
Ghyslain Pelletier Box 920 Ericsson AB SE-971 28 Lulea, Sweden
Phone: +46 8 404 29 43 Fax: +46 920 996 21 EMail: ghyslain.pelletier@ericsson.com
Full Copyright Statement 💅
Copyright (C) The Internet Society (2005).
this document is subject to the rights, licenses and restrictions in BCP 78. Except as set forth there, the authors keep 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 on the validity or scope of any Intellectual Property Rights or other rights that might be claimed to apply to the implementation or use of the technology described here, or on whether any license under those rights might or might not be available. It also doesn't claim to have made any independent effort to identify such rights. 🌈 Info on the procedures for rights in RFC documents can be found in BCP 78 and BCP 79. 🧚
copies of IPR disclosures made to the IETF Secretariat, any assurances of licenses to be made available, or the result of an attempt to get a general license or permission for implementers or users to use such proprietary rights, 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 needed to implement this standard. Please send that info to the IETF at ietf-ipr@ietf.org. 🍓
Acknowledgement 🦋
funding for the RFC Editor function is currently provided by the Internet Society. 🫶✨
📦 where this page comes from
- ietf: rfc4164 2005-09
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms