Zero-byte Support for Bidirectional Reliable Mode (R-mode) in Extended Link-Layer Assisted RObust Header Compression (ROHC) Profile
RFC - Proposed Standard
(December 2002; No errata)
No shepherd assigned
RFC 3408 (Proposed Standard)
||Send notices to
Network Working Group Z. Liu
Request for Comments: 3408 K. Le
Category: Standards Track Nokia
Zero-byte Support for Bidirectional Reliable Mode (R-mode)
in Extended Link-Layer Assisted RObust Header Compression
Status of this Memo
This document specifies an Internet standards track protocol for the
Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Official Protocol Standards" (STD 1) for the standardization state
and status of this protocol. Distribution of this memo is unlimited.
Copyright (C) The Internet Society (2002). All Rights Reserved.
This document defines an additional mode of the link-layer assisted
RObust Header Compression (ROHC) profile, also known as the zero-byte
profile, beyond the two defined in RFC 3242. Zero-byte header
compression exists in order to prevent the single-octet ROHC header
from pushing a packet voice stream into the next higher fixed packet
size for the radio. It is usable in certain widely deployed older
air interfaces. This document adds the zero-byte operation for ROHC
Bidirectional Reliable mode (R-mode) to the ones specified for
Unidirectional (U-mode) and Bidirectional Optimistic (O-mode) modes
of header compression in RFC 3242.
[RFC3242] defines a zero-byte solution for compression of IP/UDP/RTP
packets only for Unidirectional (U-) and Bidirectional Optimistic
(O-) modes [RFC3095]. The present specification extends the profile
defined in [RFC3242] to provide zero-byte support for Bidirectional
Reliable (R-) mode. This specification and [RFC3242] allow a
header-free packet format to be used in all modes to replace the
majority of the 1-octet headers of ROHC RTP packets sent during
normal operation. Specifically, the compressor operating in R-mode
is allowed to deliver a No-Header Packet (NHP) when [RFC3242] would
have required it to deliver a ROHC Reliable Packet Type Zero (R-0)
Liu & Le Standards Track [Page 1]
RFC 3408 0-byte Support for R-mode December 2002
For simplification, this profile is defined in the form of the
additions and exceptions to [RFC3242] that are required 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
2. Extensions to the assisting layer (AL) interface
This section describes additions (some are optional) to the assisting
layer interface as defined in [RFC3242, section 4.2].
2.1. Additional parameters to the compressor to AL interface
- Mode, indicating the mode in which the compressor is operating.
The AL has slightly different logic depending on the mode value.
- SN_ACKed, indicating the latest RTP SN that has been acknowledged.
It is used only when Mode value = R-mode.
Note that these two parameters MUST always be attached to every
packet delivered to the AL.
2.2. Additional interface, assisting layer to compressor
To improve the compression efficiency of this profile in some
specific cases, e.g., when the AL operates in such a way that it
often becomes unsafe to send NHPs, it is RECOMMENDED to implement
this additional interface. Here, the word "unsafe" means that the
compressor allows the AL to send NHP but the AL cannot guarantee that
the RTP SN of the NHP will be correctly decompressed at the receiving
side. The interface is used to carry update_request as described in
section 3. Note that this interface is not required in the sense
that the impossibility of implementing such an interface should not
be an obstacle to implement this profile over a specific link.
3. R-mode operation
For the R-mode, this profile extends ROHC RTP by performing a mapping
of the R-0 packet to the NHP packet. Note that R-0 is the only type
of packets in R-mode that can be replaced with NHP.
On the receiving side, the RTP SN of an NHP is determined by the
Show full document text