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

Versions: 00 01 02 RFC 3408

Network Working Group                                        Zhigang Liu
INTERNET-DRAFT                                                  Khiem Le
Expires: June 14 2002                                              Nokia
                                                       December 14, 2001


     0-byte Support for R-mode in Link-Layer Assisted ROHC Profile
                <draft-ietf-rohc-rtp-lla-r-mode-00.txt>



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-
   Drafts.

   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
   http://www.ietf.org/ietf/1id-abstracts.txt

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

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


Abstract

   This document defines a 0-byte solution for R-mode in the link-layer
   assisted ROHC profile [LLA-ROHC].











Liu, Le                                                         [Page 1]

INTERNET-DRAFT          0-byte Support for R-mode      December 14, 2001


1.  Introduction

   [LLA-ROHC] defines a U/O-mode only 0-byte solution for compression of
   IP/UDP/RTP packets. This document extends [LLA-ROHC] to provide
   0-byte support for R-mode, which allows a header-free packet format
   to be used in all modes.

   For simplification, this profile is defined as a minimal delta to
   [LLA-ROHC].  All terminologies used in this document are the same as
   in [LLA-ROHC].

   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.


2.  Extensions to the assisting layer interface

   This section describes additions (some are optional) to the assisting
   layer interface as defined in [LLA-ROHC].


2.1.  Additional parameters to the compressor to AL interface

   (Editing note: refer to section 4.2.1, [LLA-ROHC])

   -  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.  New interface, assisting layer to compressor

   (Editing note: could be section 4.2.3, [LLA-ROHC])

   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. 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.




Liu, Le                                                         [Page 2]

INTERNET-DRAFT          0-byte Support for R-mode      December 14, 2001


3.  R-mode operation

   (Editing note: could go after section 4.3, [LLA-ROHC])

   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-CRC packets cannot
   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.

   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 to send NHPs
   (caused by other conditions than the disallowance from the
   compressor), the AL records the corresponding RTP SN as SN_break.
   Then it waits until the SN_ACKed > SN_break before it resuming
   sending NHPs. 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
   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 condition is 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 needs to be replaced.  In addition, NHP packets 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



Liu, Le                                                         [Page 3]

INTERNET-DRAFT          0-byte Support for R-mode      December 14, 2001


   is no loss of robustness in this profile compared to ROHC RTP.


4.  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.

5.  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
   Nguyenphu.


6.  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-
               lla-03.txt>

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


7.  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


Appendix A. Clarifications of this profile compared to LLA

   The main body of this document defines the major delta (i.e. section
   2 and 3) between the new profile and the LLA. For completeness, this
   appendix lists other minor clarifications about the new profile.
   Again, [LLA-ROHC] is used as reference and only the differences (some



Liu, Le                                                         [Page 4]

INTERNET-DRAFT          0-byte Support for R-mode      December 14, 2001


   of which are editorial) are listed here.

   1) [LLA-ROHC], section 1, page 4, second paragraph:

   LLA: "can replace a majority of the 1-octet header ROHC RTP packets
   during normal U/O-mode operation"

   This profile: "can replace a majority of the 1-octet header ROHC RTP
   packets during normal operation"

   2) [LLA-ROHC], section 3, page 6:

   LLA: "Basically, what this profile does is to replace the smallest
   and most frequent ROHC U/O-mode headers with a no-header format"

   This profile: "Basically, what this profile does is to replace the
   smallest and most frequent ROHC headers with a no-header format"

   3) [LLA-ROHC], section 3, page 6:

   LLA: "The fields present in the ROHC RTP headers for U/O-mode PT0 are
   the packet type identifier, the sequence number and the CRC."

   This profile: "The fields present in 1-octet ROHC RTP headers are the
   packet type identifier, the sequence number and the CRC (not present
   in PT R-0)."

   4) [LLA-ROHC], section 3.3:

   This profile: add following note: "This section does not apply to R-
   mode as R-0 packets do not contain CRC field".

   5) [LLA-ROHC], section 4.1.1:

   This profile: remove the following statement from the first
   paragraph: "An LLA compressor is not allowed to deliver NHP packets
   when operating in R-mode."

   6) [LLA-ROHC] section 4.2.1:

   LLA: "Recall that delivery of an NHP packet occurs when the ROHC RTP
   compressor would have used a ROHC UO-0."

   This profile: "Recall that delivery of an NHP packet occurs when the
   ROHC RTP compressor would have used a ROHC UO-0 or R-0".

   7) [LLA-ROHC], section 4.2.2, last paragraph:




Liu, Le                                                         [Page 5]

INTERNET-DRAFT          0-byte Support for R-mode      December 14, 2001


   LLA: "Note that the context is updated from a packet loss
   indication."

   This profile: "Note that in U/O-mode the context is updated from a
   packet loss indication."

   8) [LLA-ROHC], section 4.6:

   This profile: add following note at the end of section:

   "Note that this section does not apply to R-mode since there is no
   CRC replacement. Furthermore, the sending of R-0-CRC when 6-bit SN
   wraps around already provides periodic context verification for R-
   mode".





































Liu, Le                                                         [Page 6]


Html markup produced by rfcmarkup 1.108, available from http://tools.ietf.org/tools/rfcmarkup/