RObust Header Compression (ROHC): A Link-Layer Assisted Profile for IP/UDP/RTP
RFC 4362

5.  Implementation Issues

   This document specifies mechanisms for the protocol and leaves
   details on the use of these mechanisms to the implementers.  The
   present section aims to provide guidelines, ideas, and suggestions
   for implementation of LLA.

5.1.  Implementation Parameters and Signals

   As described in [ROHC, Section 6.3], implementations use parameters
   to set up configuration information and to stipulate how a ROHC
   implementation is to operate.  The following parameters are
   additions, useful to LLA, to the parameter set defined for ROHC RTP
   implementations.  Note that if the PREFERRED_PACKET_SIZES parameters
   defined here are used, they obsolete all PACKET_SIZE and PAYLOAD_SIZE
   parameters of ROHC RTP.

5.1.1.  Implementation Parameters at the Compressor

   ALWAYS_PAD -- value: boolean

      This parameter may be set by an external entity to specify to the
      compressor that every RHP packet MUST be padded with ROHC padding
      of one octet, minimum.

      The assisting layer MUST provide a packet type identification.  If
      no field is available for this purpose from the protocol at the
      link layer, then a leading sequence may be used to distinguish RHP
      packets from NHP packets.  Although the use of a leading sequence
      is obviously not efficient, since it sacrifices efficiency for RHP
      packets, the efficiency loss should be insignificant because the
      leading sequence applies only to packets with headers in order to
      favor the use of packets without headers.  If a leading sequence
      is desired for RHP identification, the lower layer MAY use ROHC
      padding for the leading sequence by setting the ALWAYS_PAD
      parameter.  Note that in such cases, possible collisions of the
      padding with the NHP payload must be avoided.

      By default, this parameter is set to FALSE.

   PREFERRED_PACKET_SIZES -- list of:
         SIZE -- value: integer (octets)
         RESTRICTED_TYPE -- values: [NHP_ONLY, RHP_ONLY, NO_RESTRICTION]

      This parameter set governs which packet sizes are preferred by the
      assisting layer.  If this parameter set is used, all RHP packets
      MUST be padded to fit the smallest possible preferred size.  If
      the size of the unpadded packet (or, in the case of ALWAYS_PAD

Jonsson, et al.             Standards Track                    [Page 17]
RFC 4362             A Link-Layer Assisted ROHC RTP         January 2006

      being set, the packet with minimal one-octet padding) is larger
      than the maximal preferred packet size, the compressor has two
      options.  Either it may deliver this larger packet with an
      arbitrary size, or it may split the packet into several segments
      using ROHC segmentation and pad each segment to one of the
      preferred sizes.  Which method to use depends on the value of the
      LARGE_PACKETS_ALLOWED parameter below.

      NHP packets can be delivered to the lower layer only if the
      payload size is part of the preferred packet size set.
      Furthermore, if RESTRICTED_TYPE is set to one of NHP_ONLY or
      RHP_ONLY for any of the preferred packet sizes, that size is
      allowed only for packets of the specified type.

      By default, no preferred packet sizes are specified.  When sizes
      are specified, the default value for RESTRICTED_TYPE is
      NO_RESTRICTION.

   LARGE_PACKETS_ALLOWED -- value: boolean

      This parameter may be set by an external entity to specify how to
      handle packets that do not fit any of the preferred packet sizes
      specified.  If it is set to TRUE, the compressor MUST deliver the
      larger packet as-is and MUST NOT use segmentation.  If it is set
      to FALSE, the ROHC segmentation scheme MUST be used to split the
      packet into two or more segments, and each segment MUST further be
      padded to fit one of the preferred packet sizes.

      By default, this parameter is set to TRUE, which means that
      segmentation is disabled.

   VERIFICATION_PERIOD -- value: integer

      This parameter may be set by an external entity to specify to the
      compressor the minimum frequency with which a packet validating
      the context must be sent.  This tells the compressor that a packet
      containing a CRC field MUST be sent at least once every N packets,
      where N=VERIFICATION_PERIOD (see Section 4.6).

      By default, this parameter is set to 0, which indicates that
      periodical verifications are disabled.

Jonsson, et al.             Standards Track                    [Page 18]
RFC 4362             A Link-Layer Assisted ROHC RTP         January 2006

5.1.2.  Implementation Parameters at the Decompressor

   NHP_PACKET -- value: boolean

      This parameter informs the decompressor that the packet being
      delivered is an NHP packet.  The decompressor MUST accept this
      packet type indicator from the lower layer.  An assisting layer
      MUST set this indicator to true for every NHP packet delivered,
      and to false for any other packet.

   PHYSICAL_PACKET_LOSS -- signal

      This signal indicates to the decompressor that a packet has been
      lost on the link between the compressing and the decompressing
      sides, due to a physical link error.  The signal is given once for
      each packet that was lost, and a decompressor must increase the
      sequence number accordingly when this signal is received.

   PRE_LINK_PACKET_LOSS -- signal

      This signal tells the decompressor to increase the sequence number
      due to a gap in the sequencing not related to a physical link
      error.  A receiving assisting layer may, for example, use this
      signal to indicate to the decompressor that a packet was lost
      before the compressor, or that a packet was discarded by the
      transmitting assisting layer.

5.2.  Implementation over Various Link Technologies

   This document provides the semantics and requirements of the
   interface needed from the ROHC compressor and decompressor towards
   the assisting layer to perform link-layer-assisted header
   compression.

   However, this document does not provide any link-layer-specific
   operational information, except for some implementation suggestions.
   Further details about how this profile is to be implemented over
   various link technologies must be described in other documents, where
   specific characteristics of each link layer can be taken into account
   to provide optimal usage of this profile.

   These specifications MAY use a packet-type bit pattern unused by this
   profile to implement signaling on the lower layer.  The pattern
   available to lower layer implementations is [11111001].

Jonsson, et al.             Standards Track                    [Page 19]
RFC 4362             A Link-Layer Assisted ROHC RTP         January 2006

6.  IANA Considerations

   ROHC profile identifier 0x0005 has been reserved by the IANA for the
   IP/UDP/RTP profile defined in this document.

7.  Security Considerations

   The security considerations of ROHC RTP [ROHC, 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
   using random CRC values onto the link, 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.

8.  Acknowledgements

   The authors would like to thank Lila Madour, Ulises Olvera-Hernandez,
   and Francis Lupien for input regarding the typical links in which LLA
   can be applied.  Thanks also to Mikael Degermark for fruitful
   discussions that led to improvements of this profile, and to Zhigang
   Liu for many valuable comments.

9.  References

9.1.  Normative References

   [ROHC]    Bormann, C., Burmeister, C., Degermark, M., Fukushima, H.,
             Hannu, H., Jonsson, L-E., 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.

   [IPv4]    Postel, J., "Internet Protocol", STD 5, RFC 791, September
             1981.

   [IPv6]    Deering, S. and R. Hinden, "Internet Protocol, Version 6
             (IPv6) Specification", RFC 2460, December 1998.

   [UDP]     Postel, J., "User Datagram Protocol", STD 6, RFC 768,
             August 1980.

   [RTP]     Schulzrinne, H.,  Casner, S., Frederick, R., and V.
             Jacobson, "RTP: A Transport Protocol for Real-Time
             Applications", STD 64, RFC 3550, July 2003.

Jonsson, et al.             Standards Track                    [Page 20]
RFC 4362             A Link-Layer Assisted ROHC RTP         January 2006

   [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
             Requirement Levels", BCP 14, RFC 2119, March 1997.

9.2.  Informative References

   [LLA]     Jonsson, L-E. and G. Pelletier, "RObust Header Compression
             (ROHC): A Link-Layer Assisted Profile for IP/UDP/RTP", RFC
             3242, April 2002.

   [TCP]     Postel, J., "Transmission Control Protocol", STD 7, RFC
             793, September 1981.

   [RTP-REQ] Degermark, M., "Requirements for robust IP/UDP/RTP header
             compression", RFC 3096, July 2001.

   [0B-REQ]  Jonsson, L-E., "RObust Header Compression (ROHC):
             Requirements and Assumptions for 0-byte IP/UDP/RTP
             Compression", RFC 3243, April 2002.

   [VJHC]    Jacobson, V., "Compressing TCP/IP headers for low-speed
             serial links", RFC 1144, February 1990.

   [IPHC]    Degermark, M., Nordgren, B., and S. Pink, "IP Header
             Compression", RFC 2507, February 1999.

   [CRTP]    Casner, S. and V. Jacobson, "Compressing IP/UDP/RTP Headers
             for Low-Speed Serial Links", RFC 2508, February 1999.

   [CRTPC]   Degermark, M., Hannu, H., Jonsson, L-E. and K. Svanbro,
             "Evaluation of CRTP Performance over Cellular Radio
             Networks", IEEE Personal Communications Magazine, Volume 7,
             number 4, pp. 20-25, August 2000.

   [VTC2000] Svanbro, K., Hannu, H., Jonsson, L-E. and M. Degermark,
             "Wireless real time IP-services enabled by header
             compression", proceedings of IEEE VTC2000, May 2000.

   [MOMUC01] Liu, G., et al., "Experimental field trials results of
             Voice-over IP over WCDMA links", MoMuC'01 - The
             International Workshop on Mobile Multimedia Communications,
             Conference proceedings, February 2001.

Jonsson, et al.             Standards Track                    [Page 21]
RFC 4362             A Link-Layer Assisted ROHC RTP         January 2006

Authors' Addresses

   Lars-Erik Jonsson
   Ericsson AB
   Box 920
   SE-971 28 Lulea, Sweden

   Phone: +46 8 404 29 61
   Fax:   +46 920 996 21
   EMail: lars-erik.jonsson@ericsson.com

   Ghyslain Pelletier
   Ericsson AB
   Box 920
   SE-971 28 Lulea, Sweden

   Phone: +46 8 404 29 43
   Fax:   +46 920 996 21
   EMail: ghyslain.pelletier@ericsson.com

   Kristofer Sandlund
   Ericsson AB
   Box 920
   SE-971 28 Lulea, Sweden

   Phone: +46 8 404 41 58
   Fax:   +46 920 996 21
   EMail: kristofer.sandlund@ericsson.com

Jonsson, et al.             Standards Track                    [Page 22]
RFC 4362             A Link-Layer Assisted ROHC RTP         January 2006

Full Copyright Statement

   Copyright (C) The Internet Society (2006).

   This document is subject to the rights, licenses and restrictions
   contained in BCP 78, and except as set forth therein, the authors
   retain all their rights.

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
   ENGINEERING TASK FORCE DISCLAIM 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.

Intellectual Property

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   ietf-ipr@ietf.org.

Acknowledgement

   Funding for the RFC Editor function is provided by the IETF
   Administrative Support Activity (IASA).

Jonsson, et al.             Standards Track                    [Page 23]