[Docs] [txt|pdf] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 RFC 3408

Network Working Group                                        Zhigang Liu
INTERNET-DRAFT                                                  Khiem Le
Expires: July 17 2002                                              Nokia
                                                        January 17, 2002

 0-byte Support for R-mode in Extended Link-Layer Assisted ROHC Profile

Status of This Memo

   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC2026.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is  inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at

   The list of Internet-Draft Shadow Directories can be accessed at

   This document is a submission of the IETF ROHC WG. Comments should be
   directed to its mailing list, rohc@cdt.luth.se.


   This document defines a new profile that extends the link-layer
   assisted ROHC profile ([LLA-ROHC]) to provide 0-byte solution for R-

Liu, Le                                                         [Page 1]

INTERNET-DRAFT          0-byte Support for R-mode       January 17, 2001

1.  Introduction

   [LLA-ROHC] defines a U/O-mode only 0-byte solution for compression of
   IP/UDP/RTP packets. This document defines a new profile that extends
   the profile defined in [LLA-ROHC] to provide 0-byte support for R-
   mode. The new profile allows a header-free packet format to be used
   in all modes to replace the majority of the 1-octet header of ROHC
   RTP packets sent during normal operation. Specifically, the
   compressor operating in R-mode is allowed to deliver an NHP packet
   when it would have used a ROHC R-0 ([ROHC]).

   For simplification, this profile is defined in the form of additions
   and exceptions to [LLA-ROHC] that are required to extend the LLA-ROHC
   profile with 0-byte support for R-mode. All terminologies used in
   this document are the same as in [LLA-ROHC].

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   document are to be interpreted as described in RFC 2119.

2.  Extensions to the assisting layer interface

   This section describes additions (some are optional) to the assisting
   layer interface as defined in [LLA-ROHC] (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

   This interface is RECOMMENDED to improve the compression efficiency
   of this profile in some cases, e.g., when the AL operates in such a
   way that it often becomes unsafe to send NHPs. (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

Liu, Le                                                         [Page 2]

INTERNET-DRAFT          0-byte Support for R-mode       January 17, 2001

   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
   decompressor as = SN_Ref_D + Offset_D, where SN_Ref_D is the RTP SN
   of the last update packet received by the decompressor, and Offset_D
   the sequence number offset between the NHP and the last update
   packet. How to derive Offset_D depends on the implementation of this
   profile over a specific link technology and 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. Alternatively, it can be derived using the link
   timing in the case where the linear mapping between RTP SN and link
   timing is maintained.

   On the transmitting side, the AL follows the same rule defined in
   section 4.1.1 of [LLA-ROHC] to determine whether it can send NHP or
   not. When the AL determines that it has become unsafe (see section
   2.2) to send NHPs, the AL 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. (The latter
   condition is due to the non-context-updating nature of R-0.)  To make
   this happen, the AL can either wait passively for the compressor to
   send a context update packet (e.g. R-0-CRC triggered by 6-bit SN
   wrap-around), or send an update_request via the interface from AL to
   the compressor [section 2.2] to request the compressor to send a
   context updating packet. The update_request carries the last
   SN_break. Upon receiving an update_request, the compressor can send
   R-0-CRC or some other context updating packet. Context updating
   packets are handled as in [ROHC].

   Note: the passive waiting as described above might take a long time
   in the worst case (during which NHPs cannot be sent).  Therefore,
   sending update_request via the optional AL to compressor interface is
   RECOMMENDED to improve the worst case performance.

   Note: the update_request may be lost if the AL and compressor are at
   different locations and the channel between them are unreliable.  But

Liu, Le                                                         [Page 3]

INTERNET-DRAFT          0-byte Support for R-mode       January 17, 2001

   such a loss only delays the AL from resuming sending NHP. Therefore,
   how frequent 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.  How quickly the compressor sends a context updating packet upon
   receiving an update_request is also an implementation issue.

   Note: as no CRC field is present in R-0 packets, only the function
   related to RTP SN and packet type identifier needs to be replaced.
   In addition, NHP packets and packet loss indications in R-mode do not
   update either the compressor or the decompressor context (as opposed
   to U/O-mode).  Consequently, the secure reference principle (section
   5.5, [ROHC]) is not affected in any way and there is no loss of
   robustness in this profile compared to ROHC RTP.

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

   This section clarifies some differences between R-mode and U/O-mode
   in this profile.

   a) CRC replacement
      Unlike U/O-mode, CRC replacement (section 3.3, [LLA-ROHC]) is not
      an issue for R-mode since R-0 packets do not carry CRC field.

   b) Periodic context verification
      For U/O-mode, periodic context verification (section 4.6, [LLA-
      ROHC]) is RECOMMENDED to provide additional protection against
      damage propagation after CRC is replaced. In R-mode, this is not
      needed since there is no CRC replacement (see above). Furthermore,
      the sending of R-0-CRC when 6-bit SN wraps around implicitly
      provides periodic context verification for R-mode.

   c) CV-REQUEST option
      For the same reasons as above, the decompressor operating in R-
      mode SHOULD NOT send CV-REQUEST (section 4.5, [LLA-ROHC]) to
      compressor. This is to avoid unnecessary overhead on the feedback

   d) Context Check Packet (CCP)
      When CCP is used (section 4.1.3, [LLA-ROHC]), compressor operating
      in R-mode SHOULD set C-bit to 0 (zero) and not generate 7-bit CRC
      if computation cost at compressor and decompressor causes concern.
      The use of the CRC field in CCP to perform decompressor context
      verification is not critical in R-mode (see last note of section 3
      and item b) above).

Liu, Le                                                         [Page 4]

INTERNET-DRAFT          0-byte Support for R-mode       January 17, 2001

5.  IANA considerations

   A ROHC profile identifier must be reserved by the IANA for the
   profile defined in this document, preferably 0x01SS, where 0x00SS is
   the value to be assigned by IANA for LLA.

6.  Acknowledgements

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

7.  References

   [LLA-ROHC]  Lars-Erik Jonsson and Ghyslain Pelletier, "A Link-Layer
               Assisted ROHC Profile for IP/UDP/RTP", Internet Draft,
               work in progress, October 2001. <draft-ietf-rohc-rtp-

   [ROHC]      Bormann, C., et. al., "Robust Header Compression (ROHC)",
               RFC 3095, July 2001.

8.  Authors' Addresses

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

   Phone:  +1 972 894-5935               Phone:  +1 972 894-4882
   Fax:    +1 972 894-4589               Fax:    +1 972 894-4589
   E-mail: zhigang.c.liu@nokia.com       E-mail: khiem.le@nokia.com

Liu, Le                                                         [Page 5]

Html markup produced by rfcmarkup 1.113, available from https://tools.ietf.org/tools/rfcmarkup/