GENWiki

Network Working Group L-E. Jonsson Request for Comments: 3243 Ericsson Category: Informational April 2002

                 RObust Header Compression (ROHC):
  Requirements and Assumptions for 0-byte IP/UDP/RTP Compression

Status of this Memo

 This memo provides information for the Internet community.  It does
 not specify an Internet standard of any kind.  Distribution of this
 memo is unlimited.

Copyright Notice

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

Abstract

 This document contains requirements for the 0-byte IP/UDP/RTP
 (Internet Protocol/User Datagram Protocol/Real-Time Transport
 Protocol) header compression scheme to be developed by the Robust
 Header Compression (ROHC) Working Group.  It also includes the basic
 assumptions for the typical link layers over which 0-byte compression
 may be implemented, and assumptions about its usage in general.

1. Introduction

 The goal of the Robust Header Compression (ROHC) Working Group is to
 develop header compression schemes that perform well over links with
 high error rates and long link roundtrip times.  The schemes must
 perform well for cellular links, using technologies such as WCDMA,
 EDGE, and CDMA-2000.  However, the schemes should also be applicable
 to other future link technologies with high loss and long roundtrip
 times.

 ROHC RTP has become a very efficient, robust and capable compression
 scheme, able to compress the IP/UDP/RTP headers down to a total size
 of only one octet.  This makes ROHC RTP an excellent solution for
 future cellular environments with new air interfaces, such as WCDMA,
 making even speech services possible over IP with an insignificantly
 lower spectrum efficiency compared to existing circuit switched
 solutions.

Jonsson Informational [Page 1] RFC 3243 Reqs and Assumptions for 0-byte ROHC RTP April 2002

 However, all-IP cellular networks will also be built with already
 existing air interfaces such as GSM and IS-95, which are less
 flexible using radio bearers optimized for specific frame sizes
 matching the speech codecs used.  This means that not a single octet
 of header can be added without switching to the next higher fixed
 packet size supported by the link, something which is obviously very
 costly.  In the long term, this drawback should of course be
 eliminated with new, more flexible air interfaces, but in the short
 term it would be desirable if an efficiency comparable to the circuit
 switched case could also be achieved for already deployed speech
 codecs when used over the existing air interfaces.  To achieve that,
 it must be possible to completely eliminate the headers for a
 majority of the packets during normal operation, and this is the
 purpose of 0-byte header compression.  All functionality normally
 provided by the 1-octet header must then be provided by some other
 means, typically by utilizing functionality from the lower layer.  It
 is important to remember that the purpose of 0-byte header
 compression is to provide optimal efficiency for applications
 matching the link layer characteristics, not efficiency in general.

 As a starting point for these requirements, the well-established
 requirements base developed in the ROHC WG has been used.  From that,
 the requirements have evolved through input from the 3GPP2 community
 and from discussions within the WG.

2. Assumptions for the Applicability of 0-byte RTP Header Compression

 The purpose of 0-byte header compression is to provide optimal usage
 of certain links when the traffic pattern of a packet stream
 completely matches the characteristics of that link.  There are no
 assumptions that only packet streams complying with that pattern will
 occur, but optimal efficiency cannot of course be provided when this
 is not the case.

 To make 0-byte header compression feasible, it is assumed that lower
 layers can provide the necessary functionality needed to replace the
 1-octet headers and fulfill the requirements defined in section 3.
 An example is the synchronized nature of most cellular links, which
 can provide sequencing and timing information and make packet loss
 detection possible.

3. Requirements on 0-byte RTP Header Compression

 Since 0-byte header compression for ROHC IP/UDP/RTP is a variant of
 regular ROHC RTP compression [ROHC], these requirements are described
 as deltas to those defined in the regular RTP requirements [RTP-REQ].
 For simplicity, this section is also separated into the same three
 subsections as the requirements in [RTP-REQ], where the first deals

Jonsson Informational [Page 2] RFC 3243 Reqs and Assumptions for 0-byte ROHC RTP April 2002

 with the impact of header compression on the rest of the Internet
 infrastructure, the second concerns the headers to be compressed, and
 the third covers efficiency and link technology related issues.

3.1. Impact on Internet Infrastructure

 The meaning of header compression is in no way changed by the
 introduction of 0-byte header compression.  No additional impact on
 the Internet infrastructure is thus allowed.  The "Transparency" and
 "Ubiquity" requirements of [RTP-REQ, section 2.1] therefore also
 apply to 0-byte RTP compression without any modifications.

3.2. Supported Headers and Kinds of RTP Streams

 The 0-byte RTP compression scheme in general imposes the same
 requirements on supported headers and RTP streams as regular ROHC RTP
 [RTP-REQ, section 2.2].  However, there are some aspects regarding
 the "Genericity" and IPSEC requirements that should be noted.

 The "Genericity" requirement of [RTP-REQ] states that compression of
 headers of arbitrary RTP streams must be supported, and this is also
 true for the 0-byte compression scheme to the extent that it is not
 allowed to assume certain RTP behavior.  However, as also stated in
 [RTP-REQ], this does not preclude optimizations for certain media
 types where the traffic pattern is known.  For 0-byte RTP, this means
 that the scheme must be able to handle arbitrary RTP streams in order
 to fulfill the requirements of section 3.1.  However, due to the
 typical characteristics of 0-byte compression, by requiring a traffic
 pattern that suits the link over which it is implemented to be able
 to compress down to 0-byte headers, it becomes optimized for
 applications with link-suited traffic patterns.  For traffic that
 does not comply with the link properties, the scheme must
 automatically and immediately fall back to non-0-byte RTP compression
 and must not have any impact on the packet stream.

 Regarding IPSEC, it should be noted that 0-byte compression cannot be
 achieved if parts of the original headers are encrypted or carry
 randomly changing fields.  IPSEC and 0-byte RTP header compression
 therefore do not go well together.  If IPSEC is used and prevents 0-
 byte compression, the scheme must fall back to a less efficient
 compression that can handle all present header fields.  Of course,
 this applies not only to IPSEC but to all cases where headers cannot
 be compressed down to 0-byte.

Jonsson Informational [Page 3] RFC 3243 Reqs and Assumptions for 0-byte ROHC RTP April 2002

3.3. Performance Issues

 All the performance requirements of [RTP-REQ] also apply to 0-byte
 RTP header compression, with the following additions and exceptions:

Performance/Spectral Efficiency: For packet streams with traffic

patterns that match the characteristics of the link over which 0-

    byte header compression is implemented, the performance should be
    such that 0-byte header packets are generated during normal
    operation, most of the time.  0-byte headers would then replace
    most of the 1-octet headers used by regular ROHC RTP [ROHC].

    Justification: Spectrum efficiency is a primary goal.  Studies
    have shown that for certain applications and link technologies,
    even a single octet of header may result in a significant decrease
    in spectrum efficiency, compared to existing circuit switched
    solutions.

Header Compression Coexistence: The scheme must fit into the ROHC

framework together with other ROHC profiles.

    Justification: Implementation simplicity is an important issue and
    the 0-byte RTP compression scheme should therefore have as much as
    possible in common with the regular IP/UDP/RTP profile.

Unidirectional links: It is of less importance that the 0-byte

header compression scheme be able to also work over unidirectional

    links.

    Justification: 0-byte header compression targets links that
    typically are bi-directional.

4. IANA Considerations

 A protocol which meets these requirements, e.g., [LLA], will require
 the IANA to assign various numbers.  This document by itself,
 however, does not require any IANA involvement.

5. Security Considerations

 A protocol specified to meet these requirements, e.g., [LLA], may
 have a number of security aspects that need to be considered.  This
 document by itself, however, does not add any security risks.

Jonsson Informational [Page 4] RFC 3243 Reqs and Assumptions for 0-byte ROHC RTP April 2002

6. References

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

 [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)", RFC 3095, July 2001.

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

7. Author's Address

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

 Phone: +46 (920) 20 21 07
 Fax: +46 (920) 20 20 99
 EMail: lars-erik.jonsson@ericsson.com

Jonsson Informational [Page 5] RFC 3243 Reqs and Assumptions for 0-byte ROHC RTP April 2002

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

Jonsson Informational [Page 6]