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



Liu & Le                    Standards Track                     [Page 2]

RFC 3408               0-byte Support for R-mode           December 2002


  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 [RFC3242] to determine whether it can send NHP or
  not, with one modification.  That is, 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 essentially the counterpart of
  optimistic approach agreement [RFC3242, section 4.3] of U/O-mode
  which states that when the AL in U/O-mode determines it is unsafe to
  send 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, instead of
  optimistic approach principle as in U/O-mode; and 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 (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 SHOULD use a context updating packet (e.g. R-0-CRC) when
  sending the next packet.  Context updating packets are handled as in
  [RFC3095].

  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 is 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 conditions to send NHP are
  met.





Liu & Le                    Standards Track                     [Page 3]

RFC 3408               0-byte Support for R-mode           December 2002


  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 [RFC3095,
  section 5.5] 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 [RFC3242, section 3.3] 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 [RFC3242, section 4.6]
     is RECOMMENDED to provide additional protection against damage
     propagation after CRC is replaced.  For R-mode, since there is no
     CRC replacement (see above), no change to ROHC RTP is needed in
     this regard.  In particular, R-mode has this feature naturally
     built-in, since 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 [RFC3242, section 4.5] to
     compressor.  This is to avoid unnecessary overhead on the feedback
     channel.

  d) Context Check Packet (CCP)
     When CCP [RFC3242, section 4.1.3] is used, 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).

  e) Handling of Acknowledgements (ACKs)
     Special care in the realization of ACKs should be taken for R-mode
     implementations.  It is RECOMMENDED to avoid the use of
     interspersed feedback packets [RFC3095, section 5.2.1] to carry
     ACK information.  The reason is that interspersed feedback packets
     will interrupt the RTP SN sequencing and thus temporarily disable
     the sending of NHPs.




Liu & Le                    Standards Track                     [Page 4]

RFC 3408               0-byte Support for R-mode           December 2002


5.  IANA Considerations

  A ROHC profile identifier has been reserved by the IANA for the
  profile defined in this document (0x0105), where 0x0005 is the
  profile identifier assigned for LLA [RFC3242].

6.  Security Considerations

  The security considerations of ROHC RTP [RFC3095, section 7] apply
  also to this document with one addition: in the case of a denial-of-
  service attack scenario where an intruder injects bogus CCP packets
  onto the link using random CRC values, the CRC check will fail for
  incorrect reasons at the decompressor side.  This would obviously
  greatly reduce the advantages of ROHC and any extra efficiency
  provided by this profile due to unnecessary context invalidation,
  feedback messages and refresh packets.  However, the same remarks
  related to the presence of such an intruder apply.

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

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.










Liu & Le                    Standards Track                     [Page 5]

RFC 3408               0-byte Support for R-mode           December 2002


9.  Authors' Addresses

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

  Phone: +1 972 894-5935
  Fax:   +1 972 894-4589
  EMail  [email protected]


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

  Phone: +1 972 894-4882
  Fax:   +1 972 894-4589
  EMail: [email protected]





























Liu & Le                    Standards Track                     [Page 6]

RFC 3408               0-byte Support for R-mode           December 2002


10.  Full Copyright Statement

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

  This document and translations of it may be copied and furnished to
  others, and derivative works that comment on or otherwise explain it
  or assist in its implementation may be prepared, copied, published
  and distributed, in whole or in part, without restriction of any
  kind, provided that the above copyright notice and this paragraph are
  included on all such copies and derivative works.  However, this
  document itself may not be modified in any way, such as by removing
  the copyright notice or references to the Internet Society or other
  Internet organizations, except as needed for the purpose of
  developing Internet standards in which case the procedures for
  copyrights defined in the Internet Standards process must be
  followed, or as required to translate it into languages other than
  English.

  The limited permissions granted above are perpetual and will not be
  revoked by the Internet Society or its successors or assigns.

  This document and the information contained herein is provided on an
  "AS IS" basis and 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.



















Liu & Le                    Standards Track                     [Page 7]


You are viewing proxied material from gopher.rbfh.de. The copyright of proxied material belongs to its original authors. Any comments or complaints in relation to proxied material should be directed to the original authors of the content concerned. Please see the disclaimer for more details.