RFC 3408

Zero-byte Support for Bidirectional Reliable Mode (R-mode) in Extended Link-Layer Assisted RObust Header Compression (ROHC) Profile

📅 published December 2002, from ietf

Network Working Group 🦋

Authors: Z. Liu and K. Le, both from Nokia 💅

Category: Standards Track ✨

Date: December 2002 🌸

Obsoletes and updates: the title block doesn't list anything it obsoletes or updates. 🙈

Status of This Memo 📜

okay so this doc is an Internet standards track protocol for the Internet community 🌈 It's also asking for discussion and suggestions for improvements, so bring your ideas. For the current standardization state and status of this protocol, check the "Internet Official Protocol Standards" (STD 1). Distribution of this memo is unlimited 💜

Copyright (C) The Internet Society (2002). All Rights Reserved. 🫶

Abstract 🧚

so this doc adds a new mode to the link-layer assisted RObust Header Compression (ROHC) profile, which people also call the zero-byte profile 💖 The two modes that RFC 3242 already defines are the other ones, and this one is the third 👑

Why does zero-byte exist at all? It's giving "don't let one tiny header bump your voice packet into the next size up." The single-octet ROHC header can push a packet voice stream past the next higher fixed packet size for the radio, and nobody wants that 😭 It's usable in certain widely deployed older air interfaces.

This document adds zero-byte operation for ROHC Bidirectional Reliable mode (R-mode). Right now, zero-byte is only specified for Unidirectional (U-mode) and Bidirectional Optimistic (O-mode) modes of header compression in RFC 3242. Now R-mode gets the glow-up too ✨

1. Introduction 🌷

okay so [RFC3242] defines a zero-byte solution for compressing IP/UDP/RTP packets, but only for Unidirectional (U-) and Bidirectional Optimistic (O-) modes [RFC3095]. This spec extends the profile from [RFC3242] to give zero-byte support to Bidirectional Reliable (R-) mode 🦋 Between this spec and [RFC3242], a header-free packet format can be used in all modes to replace most of the 1-octet headers on ROHC RTP packets sent during normal operation. That's the whole vibe.

Specifically, a compressor in R-mode is allowed to send a No-Header Packet (NHP) when [RFC3242] would have required it to send a ROHC Reliable Packet Type Zero (R-0) packet [RFC3095] 💅

For simplification, this profile is written as the additions and exceptions to [RFC3242] needed to extend the RFC 3242 profile with zero-byte support for R-mode. All terminology used in this document is the same as in [RFC3242] 🎀

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 BCP 14, RFC 2119 [RFC2119]. ✨

2. Extensions to the assisting layer (AL) interface 🧩

This section covers additions to the assisting layer interface defined in [RFC3242, section 4.2]. Some of them are optional, so don't panic 🙈

2.1. Additional parameters to the compressor to AL interface 🍓

Two new parameters go from the compressor to the AL:

  • Mode, which tells you the mode the compressor is operating in. The AL has slightly different logic depending on the mode value.
  • SN_ACKed, which tells you the latest RTP SN that has been acknowledged. It's only used when Mode value = R-mode.

Note that these two parameters MUST always be attached to every packet delivered to the AL. no exceptions, bestie 💀

2.2. Additional interface, assisting layer to compressor 🔁

To improve compression efficiency in some specific cases, like when the AL often ends up in a spot where sending NHPs is unsafe, it is RECOMMENDED to implement this additional interface 🫶 Here, "unsafe" means the compressor lets the AL send an NHP, but the AL can't guarantee that the RTP SN of that NHP will be decompressed correctly on the receiving side 😬

The interface carries update_request, which is described in section 3. This interface is not required in the sense that not being able to implement it should not be an obstacle to implementing this profile over a specific link 🌸

3. R-mode operation 💖

For R-mode, this profile extends ROHC RTP by mapping the R-0 packet to the NHP packet. R-0 is the only type of packet in R-mode that can be replaced with an NHP 🦋

On the receiving side, the decompressor works out the RTP SN of an NHP as SN_Ref_D + Offset_D. SN_Ref_D is the RTP SN of the last update packet the decompressor received. Offset_D is the sequence number offset between the NHP and that last update packet. How to derive Offset_D depends on how this profile is implemented over a specific link technology, and it must be specified in the implementation document(s). For example, it can be calculated by counting the total number of non-context-updating packets (including NHPs) and packet loss indications received since the last successful context update. Or it can be derived from link timing, if a linear mapping between RTP SN and link timing is maintained 🧚

On the transmitting side, the AL follows the same rule as section 4.1.1 of [RFC3242] to decide whether it can send an NHP, with one change ✨ When the AL decides it has become unsafe (see section 2.2) to send NHPs, it records the corresponding RTP SN as SN_break. Then it waits until the rule is satisfied again and SN_ACKed > SN_break before it resumes sending NHPs 🎀

That last condition is basically the R-mode counterpart of the optimistic approach agreement in [RFC3242, section 4.3] for U/O-mode. In U/O-mode, when the AL decides it's unsafe to send an NHP, it must send headers in the subsequent X packets, where X is some agreed number. There are two reasons for the difference 🤓 a) R-mode relies on acknowledgements to synchronize contexts, not the optimistic approach principle used in U/O-mode. b) R-0 packets do not update decompressor context, while UO-0 packets do.

To meet the condition SN_ACKed > SN_break, the AL can either wait passively for the compressor to send a context update packet (for example, an R-0-CRC triggered by a 6-bit SN wrap-around), or it can send an update_request through the interface from the AL to the compressor (section 2.2), asking the compressor to send a context updating packet. The update_request carries the last SN_break. When the compressor gets an update_request, it SHOULD use a context updating packet (e.g. R-0-CRC) when it sends the next packet. Context updating packets are handled as in [RFC3095] 💅

Note: passive waiting, as described above, might take a long time in the worst case, and during that time NHPs cannot be sent. So sending update_request via the optional AL to compressor interface is RECOMMENDED to improve worst case performance. 😭
Note: the update_request may be lost if the AL and compressor are in different locations and the channel between them is unreliable. But that loss only delays the AL from resuming NHP sending. So how often the AL sends update_request is an implementation issue. For example, the AL may send one update_request for each packet it receives from the compressor until the conditions to send NHP are met. 🧠
Note: since there's no CRC field in R-0 packets, only the function related to RTP SN and packet type identifier needs to be replaced. Also, NHP packets and packet loss indications in R-mode do not update either the compressor or the decompressor context (unlike U/O-mode). So the secure reference principle in [RFC3095, section 5.5] is not affected in any way, and there's no loss of robustness in this profile compared to ROHC RTP 🛡️

4. Differences between R-mode and U/O-mode 🔍

This section clears up some differences between R-mode and U/O-mode in this profile 💅

  • a) CRC replacement. Unlike U/O-mode, CRC replacement [RFC3242, section 3.3] is not an issue for R-mode, since R-0 packets don't carry a CRC field 🙌
  • b) Periodic context verification. For U/O-mode, periodic context verification [RFC3242, section 4.6] is RECOMMENDED to add protection against damage propagation after the CRC is replaced. For R-mode, there's no CRC replacement (see above), so no change to ROHC RTP is needed here. R-mode actually has this feature built in, since sending R-0-CRC when the 6-bit SN wraps around implicitly provides periodic context verification for R-mode ✨
  • c) CV-REQUEST option. For the same reasons as above, a decompressor operating in R-mode SHOULD NOT send CV-REQUEST [RFC3242, section 4.5] to the compressor. This avoids unnecessary overhead on the feedback channel 🙅‍♀️
  • d) Context Check Packet (CCP). When CCP [RFC3242, section 4.1.3] is used, a compressor operating in R-mode SHOULD set the C-bit to 0 (zero) and not generate a 7-bit CRC if computation cost at the compressor and decompressor is a concern. Using the CRC field in CCP to verify decompressor context isn't critical in R-mode (see the last note of section 3 and item b) above) 🧮
  • e) Handling of Acknowledgements (ACKs). Special care should be taken in how ACKs are handled for R-mode implementations. It is RECOMMENDED to avoid using interspersed feedback packets [RFC3095, section 5.2.1] to carry ACK information. The reason is that interspersed feedback packets interrupt the RTP SN sequencing, which temporarily disables sending NHPs 🚫

5. IANA Considerations 📚

A ROHC profile identifier has been reserved by IANA for the profile defined in this document: 0x0105. The profile identifier assigned for LLA [RFC3242] is 0x0005 🎀

6. Security Considerations 🚨

The security considerations of ROHC RTP [RFC3095, section 7] also apply to this document, with one addition. Picture this: a denial-of-service attack where an intruder injects bogus CCP packets onto the link using random CRC values. The CRC check will fail for the wrong reasons at the decompressor side 😱 That would obviously cut way down on the advantages of ROHC, and on any extra efficiency this profile provides, because of unnecessary context invalidation, feedback messages, and refresh packets. The same remarks about the presence of such an intruder still apply 💀

Warning: this is a real-life threat model, not a "meh" one. The intruder can drain all the efficiency gains you were counting on, so keep it in mind. 🔥

7. Acknowledgements 🫶

The authors would like to thank Lars-Erik Jonsson and Ghyslain Pelletier for intriguing discussions on LLA, which helped nail down the R-mode operation 👑 The authors also appreciate valuable input from Carsten Bormann, Christopher Clanton, Mark Cheng, and Thinh Nguyenphu 🌈

8. References 📖

[RFC3242] Jonsson, L. and G. Pelletier, "RObust Header Compression (ROHC): A Link-Layer Assisted Profile for IP/UDP/RTP", RFC 3242, April 2002. 🦋

[RFC3095] Bormann, C., Burmeister, C., Degermark, M., Fukushima, H., Hannu, H., Jonsson, L., 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. 🧚

[RFC2119] Bradner, S., "Key words for use in RFCs to indicate requirement levels", BCP 14, RFC 2119, March 1997. 💜

9. Authors' Addresses ✨

okay bestie, here are the two people who wrote this spec 🎀 Both are from Nokia Research Center in Irving, Texas, so you know where to find them 💅

Zhigang Liu
Nokia Research Center
6000 Connection Drive
Irving, TX 75039
USA

Phone: +1 972 894-5935
Fax:   +1 972 894-4589
EMail  zhigang.c.liu@nokia.com


Khiem Le
Nokia Research Center
6000 Connection Drive
Irving, TX 75039
USA

Phone: +1 972 894-4882
Fax:   +1 972 894-4589
EMail: khiem.le@nokia.com

okay so this part is the legal stuff, but it's giving very clear vibes 💖 Copyright is held by The Internet Society (2002), and all rights are reserved 🌸

You're allowed to copy this document and share it with others, and you can make derivative works that comment on or explain it, or help people implement it. You can publish and distribute those too, in whole or in part, with no restrictions of any kind 🎀 The one condition is that the copyright notice and this paragraph stay on every copy and every derivative work ✨

The document itself is a different story 🙈 You may not modify it in any way. That means you can't remove the copyright notice or the references to the Internet Society or other Internet organizations. There are two exceptions. One is for developing Internet standards, and in that case the copyright procedures in the Internet Standards process have to be followed. The other is for translating it into languages other than English 🌈

The limited permissions above are perpetual, and the Internet Society or its successors or assigns will never revoke them 💜

This document and everything in it is provided on an "AS IS" basis. THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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 💀

Acknowledgement 🫶

funding for the RFC Editor function is currently provided by the Internet Society 💅✨

📦 where this page comes from