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

 
Document
Type RFC - Proposed Standard (December 2002; No errata)
Last updated 2013-03-02
Stream IETF
Formats plain text pdf html
Stream
WG state (None)
Consensus Unknown
Document shepherd No shepherd assigned
IESG
IESG state RFC 3408 (Proposed Standard)
Telechat date
Responsible AD Allison Mankin
Send notices to <cabo@tzi.org>, <lars-erik.jonsson@ericsson.com>

Email authors IPR References Referenced by Nits Search lists

Network Working Group                                             Z. Liu
Request for Comments: 3408                                         K. Le
Category: Standards Track                                          Nokia
                                                           December 2002

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

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 Notice

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

Abstract

   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.

1.  Introduction

   [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)
   packet [RFC3095].

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
   [RFC2119].

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