2.8.16 Robust Header Compression (rohc)

In addition to this official charter maintained by the IETF Secretariat, there is additional information about this working group on the Web at:

       http://www.dmn.tzi.org/ietf/rohc/ -- Additional ROHC Page
NOTE: This charter is a snapshot of the 56th IETF Meeting in San Francisco, California USA. It may now be out-of-date.

Last Modified: 2003-01-27

Carsten Bormann <cabo@tzi.org>
Lars-Erik Jonsson <lars-erik.jonsson@ericsson.com>
Transport Area Director(s):
Scott Bradner <sob@harvard.edu>
Allison Mankin <mankin@psg.com>
Transport Area Advisor:
Allison Mankin <mankin@psg.com>
Technical Advisor(s):
Erik Nordmark <erik.nordmark@sun.com>
Mailing Lists:
General Discussion: rohc@ietf.org
To Subscribe: rohc-request@ietf.org
Archive: http://www1.ietf.org/mail-archive/working-groups/rohc/
Description of Working Group:
Due to limited bandwidth, IP/UDP/RTP/TCP packets sent over cellular links benefit considerably from header compression. Existing header compression schemes (RFC 1144, RFC 2508) do not perform well over cellular links due to high error rates and long link roundtrip times, particularly as topologies and traffic patterns become more complex. In addition, existing schemes do not compress TCP options such as SACK or Timestamps.

Another consequence of low bandwidth links is long session setup delays when text-based signaling protocols, such as SIP and SDP, are used. These delays can be significantly reduced by compressing not only the headers, but also the signaling information.

The goal of ROHC is to develop generic header compression schemes that perform well over links with high error rates and long roundtrip times, as well as related signaling compression schemes. The schemes must perform well for cellular links built 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. Ideally, it should be possible to compress over unidirectional links.

Good performance includes both minimal loss propagation and minimal added delay. In addition to generic TCP and UDP/RTP compression, applications of particular interest are voice and low-bandwidth video.

ROHC may develop multiple compression schemes, for example, some that are particularly suited to specific link layer technologies. Schemes in addition to those listed in the milestones below may be added in consultation with the area directors.

A robust compression scheme must:

* assure that the result after decompression is semantically identical to the uncompressed original;

* perform well when the end-to-end path involves more than one cellular link;

* support IPv4 and IPv6.

* provide benefit in the presence of IPSEC.

Creating more thorough requirements documents will be the first task of the WG for each of its specific areas of work, which are:

* 0-byte improvements to RTP header compression

* TCP header compression

* Signaling compression

* SCTP header compression

In addition, the WG will work on MIBs for its compression schemes, as well as the sheperding of RFC3095 to draft standard.

The working group shall maintain connections with other standardization organizations developing cellular technology for IP, such as 3GPP and 3GPP-2, to ensure that its output fulfills their requirements and will be put to good use.

In addition, the WG should develop a solid understanding of the impact that specific error patterns have on the compression schemes, and document guidelines to Layer 2 designers regarding what Layer 2 features work best to assist Layer 3 and Layer 4 header compression. This work is in coordination with the PILC WG.

Some of the schemes developed in ROHC will be used in wider contexts than just the specific link technologies discussed. The working group will ensure the applicability in particular of the TCP and signaling compression schemes to the general Internet. This includes considering the applicability of the technologies under consideration to open-source implementations.

Finally, working group documents will address interactions with IPSEC and other security implications.

Goals and Milestones:
Done  Submit I-D on Requirements for IP/UDP/RTP header compression.
Done  Submit I-D of layer-2 design guidelines.
Done  Submit I-D(s) proposing IP/UDP/RTP header compression schemes.
Done  Submit I-D of Requirements for IP/TCP header compression.
Done  Requirements for IP/UDP/RTP header compression submitted to IESG for publication as Informational.
Done  Resolve possibly multiple IP/UDP/RTP compression schemes into a single scheme.
Done  Submit I-D on IP/TCP header compression scheme.
Done  IP/UDP/RTP header compression scheme submitted to IESG for publication as Proposed Standard.
Done  Layer-2 design guidelines submitted to IESG for publication as Informational.
Done  Initial draft on general signaling compression security analysis.
Done  Requirements and assumptions for signaling compression
Done  Signaling compression scheme submitted to IESG for publication as Proposed Standard, including security approach for SIP compression usage.
Done  General signaling compression security analysis submitted to IESG for publication as Informational.
NOV 02  ROHC MIB submitted to IESG for publication as Proposed Standard.
NOV 02  I-Ds of ROHC IP/UDP/RTP bis, framework and profiles separated.
JAN 03  LLA mapping examples submitted to IESG for publication as Informational.
FEB 03  Requirements for IP/TCP header compression submitted to IESG for publication as Informational.
FEB 03  IP/TCP compression scheme submitted to IESG for publication as Proposed Standard
MAR 03  ROHC framework submitted to IESG for publication as Draft Standard.
MAR 03  ROHC IP/UDP/RTP schemes submitted to IESG for publication as Draft Standard.
APR 03  ROHC UDP Lite schemes submitted to IESG for publication as Proposed Standard.
JUN 03  IP/SCTP compression scheme submitted to IESG for publication as Proposed Standard.
AUG 03  Possible recharter of WG to develop additional compression schemes
  • - draft-ietf-rohc-tcp-requirements-05.txt
  • - draft-ietf-rohc-mib-rtp-06.txt
  • - draft-ietf-rohc-tcp-03.txt
  • - draft-ietf-rohc-rtp-impl-guide-03.txt
  • - draft-ietf-rohc-sctp-requirements-02.txt
  • - draft-ietf-rohc-tcp-field-behavior-02.txt
  • - draft-ietf-rohc-terminology-and-examples-02.txt
  • - draft-ietf-rohc-rtp-rfc3095-interoperability-01.txt
  • - draft-ietf-rohc-ip-only-01.txt
  • - draft-ietf-rohc-tcp-enhancement-00.txt
  • - draft-ietf-rohc-formal-notation-01.txt
  • Request For Comments:
    RFC3095 PS RObust Header Compression (ROHC)
    RFC3096 I Requirements for robust IP/UDP/RTP header compression
    RFC3242 PS A Link-Layer Assisted ROHC Profile for IP/UDP/RTP
    RFC3243 I Requirements and assumptions for ROHC 0-byte IP/UDP/RTP compression
    RFC3241 PS ROHC over PPP
    RFC3408 PS Zero-byte Support for Reliable Bidirectional Mode (R-mode) in Extended Link-Layer Assisted RObust Header Compression (ROHC) Profile
    RFC3409 I Lower Layer Guidelines for Robust RTP/UDP/IP Header Compression
    RFC3320 PS Signaling Compression
    RFC3321 I SigComp - Extended Operations
    RFC3322 I Signaling Compression Requirements & Assumptions

    Current Meeting Report

    Minutes of the ROHC WG session at IETF 56
    Hilton San Francisco, San Francisco, USA
    Monday evening, 2003-03-17
    Chairs: Carsten Bormann & Lars-Erik Jonsson
    Reported by: Lars-Erik Jonsson
    Note takers: Stephen Casner, Christian Schmidt & Mark West 
    Slides are available at 
    Evening session, 19:30-22:00
    * WG admonishments (Jonsson)
    Lars-Erik reviewed the IETF working group principles, the IETF 
    standardization process and the IPR rules defined by RFC 2026.  Meeting 
    time should be used to advance difficult issues, not for 
    presentation of material that can be read from drafts. We assume that 
    people have read the drafts, and what we decide in meetings must be 
    confirmed on the mailing list.
    * Agenda bashing (Jonsson)
    Lars-Erik presented the proposed agenda, which was accepted without 
     - Chair admonishments and agenda bashing   
     - WG and document status update
     - Signaling compression issues
     - ROHC RTP DS preparations update
     - Formal header compression notation
    * WG and document status (Jonsson)
    Lars-Erik reviewed WG goals, milestones and document status. Five new ROHC 
    RFC's have been published since November, three SigComp documents, the LLA 
    R-mode extension, and the RTP lower layer guidelines. Currently, we have no 
    documents in the RFC editor's queue, but we have two that were just 
    submitted to the IESG, the ROHC MIB and its companion document with 
    terminology and channel mapping examples.
    The working group is progressing, but slowly. A milestone update was 
    planned after Atlanta, but has not yet happen for various reasons. 
    However, we should be able to do this rather soon. 
    A new document review concept is to be implemented, where each document is 
    required to have "committed reviewers". These reviewers are 
    designated as such by the chairs, preferably on an early stage, and must 
    have agreed to follow the document evolution, to carefully review the 
    whole document, and to respond openly to working group last-call. 
    Committed reviewers should be non-authors, and will be separately 
    acknowledged in documents.
    The work items not covered by the agenda of this meeting were:
    - ROHC TCP, which has not progressed as planned due to editor illness, but an 
    update is expected within a few weeks.
    - Modified RTP/UDP profiles for UDP-Lite compression, where the current 
    individual draft will be resubmitted as a WG draft.
    - SCTP compression, which is still on hold. The chairs have asked for 
    interest, motivation, industry support, and commitments for doing the 
    actual work, but answers have not really provided that.  Carsten noted that 
    we might not understand future usage of SCTP at this point, so 
    attempting a solution now might produce a result that is not really 
    * Signaling compression issues
     - SigComp Feedback (Roach)
    Adam Roach gave a quick summary of the changes in the updated draft.  Nack 
    information is now at the end of the messages, and can therefore be 
    distinguished from standalone feedback. The TCP behavior has been 
    changed, and a NACK detection mechanisms has been added. There was a 
    question raised whether we should create an IANA registry for the first 32 
    bytes of UDVM memory space, but the question was never answered or 
    discussed. More people have to look at this, so far the input has been 
    limited. The meeting suggested that the document should be adopted as a WG 
    document, if we get a few committed draft reviewers, and Mark West and 
    Carsten Bormann volunteered for this.
    Draft: draft-roach-sigcomp-nack-01.txt
     - SigComp interoperability report (West)
    Mark West gave a report from the first SigComp interoperability 
    testing, conducted at SIPit. The point was primarily to test SigComp, with or 
    without SIP, trying to verify that all decompressor/UDVM endpoints behave 
    consistently. Six implementations were present, which was more than 
    expected, and the overall result was good, things mainly worked. 
    The main problem had to do with consumption of decompressor memory 
    because bytecode consumes memory in two places, making 
    bootstrapping very difficult. Zhigang Liu noted that this is not a new 
    issue, as it was discussed among SigComp authors during last year, but then 
    it was seen as a non-problem. Adam Roach pointed out that this 
    currently makes SigComp unusable for SIP in 3GPP, and described three 
    potential solutions. It was agreed that the desirable approach would be to 
    increase the UDVM memory size, but there were various opinions on how to 
    achieve that, from a standards point of view. Richard noted that this is an 
    application specific issue, and a larger UDVM memory size should be 
    mandated for SIP. Carsten agreed, but RFC 3486 does not say so, and there 
    are other things missing as well. Carsten suggested that SigComp should not 
    be changed, but that this should be left to each signaling protocol to 
    specify. We should then not consider RFC 3486 as binding SIP to 
    SigComp, but only defining how an application finds out if SigComp is 
    being used. This means that we need a new document to specify other SIP 
    specifics for SigComp.  Zhigang volunteered to serve as editor for such a 
    There were a few more issues identified at SIPit, but these were minor, 
    although we should provide some clarifications. To do that, it was agreed to 
    create a SigComp implementer's guide, and Mark agreed to write up an 
    initial version with the current findings.
    - The SigComp binary multiplexing issues (Price)
    Richard Price initiated a follow-up to the SigComp multiplexing 
    discussion from the Sipping list. Although SigComp offers an 
    alternative transport service to applications, using SigComp requires more 
    than just an on/off switch. Applications using SigComp must provide 
    mechanisms for SigComp discovery, methods for recognizing SigComp 
    messages, define compartment handling, clarifying whether 
    "continuous mode" can be used, and potentially increase the minimal 
    memory size and/or the maximal number of UDVM cycles.
    The mixing problem raised was triggered by the requirement that SIP 
    messages may contain binary data. In UDP, framing comes from the packet, but 
    for TCP there are both application and SigComp delimiters. Problems would 
    then arise if uncompressed application messages are multiplexed with 
    SigComp messages. Carsten noted that for TCP, the first byte would 
    indicate whether SigComp is used or not, and there seems to be 
    something wrong with the layering here.  If there is a problem, it is 
    probably because of misuse of SigComp.  Richard agreed, what should be made 
    clear is that SigComp should not be switched on/off within a 
    connection. If someone wants to send some messages uncompressed, that can be 
    handled within SigComp.  Zhigang argued that we should still define how to do 
    multiplexing of raw application messages and SigComp messages, and this 
    discussion will probably continue on the mailing list.
    Whether to allow "continuous mode" at all must further be specified per 
    application, so we need the SIP-SigComp binding document also for that. 
    * ROHC RTP, Draft Standard preparations status (Jonsson)
    The MIB draft has been submitted to the IESG, and so has the channel 
    mapping examples document. The feature test document has been updated with 
    additional tests, as well as some initial status figures. Reports are 
    currently being collected, and the next update will be available within a 
    month. An update of the IP profile has also been available for some time, 
    but more feedback would be appreciated before we issue WG last-call. 
    Finally, some minor clarifications have been added to the 
    implementer's guide. Stephen Casner asked whether ROHC RTP Draft 
    Standard advancement is dependent on DS for RTP itself. Although this will 
    probably not be an issue since RTP will soon be published as Draft 
    Standard, Carsten noted that ROHC RTP is not dependent on RTP itself 
    because compression is speculative. 
    * Formal header compression notation (Bormann, Ozegovic, Price)
    Carsten introduced the formal header compression notation, initially 
    answering the question why this work is needed. The lesson we have 
    learned from RFC 3095 is that compressed packet formats easily gets 
    non-trivial, overstressing the RFC box notation. It is not always clear 
    what goes where, since labeling a field in box notation does not 
    necessary mean you know how to interpret it. With a formal notation, the 
    uncompressed data is described, as well as which compression 
    mechanisms that is applied to each field. ROHC formal notation 
    (ROHC-FN) is inspired by BNF, ROHC packet classifications, Huffman 
    probabilities, etc. ROHC-FN is something that needs to get done and out of 
    the way to return to working on profiles, which is what we are really 
    chartered to do.
    Julije Ozegovic gave a quick presentation of an initial attempt to define a 
    profile for DCCP using a formal notation approach. The purpose of this work 
    was to investigate the usefulness of a formal notation, as well as 
    studying DCCP for compression purposes. DCCP has a fixed header and 
    various options, so the compression must handle the variability.
    Carsten noted that to use the notation, we will have to nail it down 
    formally in a standardized way. It is easy to do something 
    "wishy-washy", but it is hard to do it clearly. We need to get a common 
    understanding in the WG as to how the notation works. This is not easy, and 
    semantics have to be very clear. Further, we have to find a proper 
    trade-off between top-down and bottom-up design. If we focus too much on 
    specific applications of the notation in a top-down design we will get a 
    smaller set of tools, which would be a good thing, but the solution will 
    probably be inflexible for new uses. With a bottom-up design, we could on 
    the other hand get something too flexible and far from actual 
    application requirements. We need to find a proper middle-way.
    An idea is to define the notation using a high level programming 
    language, and two examples were given by Carsten (Prolog) and Richard 
    (Haskell). Prolog is a well-known logical programming language, while 
    Haskell is a functional language. As shown by the examples, both provide 
    means to get a rather human-readable notation result, and the 
    difference is minimal, at least on the surface. 
    Carsten finally raised some issues on the way forward. We will have to 
    balance specification/implementation, as it is a danger that we write the 
    whole implementation into the specification. There will have to be 
    "oracle" functions, which are left for implementers to define. Another 
    issue is the actual bits-on-the wire encoding, when there are 
    alternatives in the encoding. To handle alternatives, some 
    discriminators are needed, but it is not obvious how to create these.  
    There have been discussions on the mailing list, but we have not totally 
    converged towards an agreement. This was discussed also at the meeting, but 
    the conclusion was that an agreement should not be difficult to reach, we 
    just have to get a clearer and common picture of what people really mean. 
    One thing is to agree on some terminology for discriminator 
    functions, i.e. Huffman and Hierarchical Huffman.  Julije noted that we 
    have two phases, encoding and how to arrange the bits on the wire, i.e. 
    field encoding and discriminators. Carsten clarified that there are 
    really not two phases, just two primitives in the notation, Fields and 
    Another high level question is how complete we want to make the 
    notation. With an academic approach, one would let this take three or four 
    years to get a complete solution, but that is really not the IETF way. 
    Since new stuff can easily be added, if needed for another 
    compression profile, we do not really have to create a complete 
    solution, although we should have a good feeling about future 
    enhancements. There was a strong agreement in the room to go for the 
    proposed approach.
    One major open issue is about interaction between the formal notation and 
    contexts, which is something that is not well understood at this point. 
    Since contexts may not be the same at compressor and decompressor, due to 
    loss, this must be covered for. We have feedback for context repair, but 
    that is not covered by the notation. We also need to have means to handle 
    things that are optionally present, e.g. list elements in IPv6. Richard 
    noted that we currently do not support unbounded (recursive) encoding, and we 
    have to carefully consider whether we should do that.
    Julije asked whether we have a problem with contexts and packet 
    classification, i.e. which fields to check to see how to handle the 
    packet and find the right context for it. Carsten commented that this 
    would be a typical oracle function, i.e. an implementation issue, and 
    Lars-Erik agreed that there should not be any difference to RFC 3095 in 
    this respect. 
    Zhigang pointed out that one must be confident that the 
    decompressor has the correct context present. Carsten responded that in 
    3095 this is handled by the sequence number, which gives the context (or 
    candidate contexts) to be used for decompression. That is an issue for 
    profile specification, nothing to be captured by the notation.
    Carsten then outlined a direction for moving forward. We should write down 
    both requirements and non-requirements for the notation, and work from 
    those. To get some more bandwidth and get this work going, we may need to 
    consider having an interim meeting, as we had when we created RFC 3095. But 
    first we should continue with the current discussions on the mailing list, 
    which so far have been really helpful for bringing people forward 
    towards a common understanding of concepts and principles.
    * Summing up (Bormann / Jonsson)
    Let's continue the discussions that we are now having on the mailing list. 
    People who have not been involved are encouraged to read the notation 
    draft, as well as the mail discussions from the last 2 weeks.
    See you in Vienna, at the