Current Meeting Report

2.8.15 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: -- Additional ROHC Page
NOTE: This charter is a snapshot of the 54th IETF Meeting in Yokohama, Japan. It may now be out-of-date.

Last Modifield: 05/06/2002

Carsten Bormann <>
Lars-Erik Jonsson <>
Transport Area Director(s):
Scott Bradner <>
A. Mankin <>
Transport Area Advisor:
A. Mankin <>
Technical Advisor(s):
Erik Nordmark <>
Mailing Lists:
General Discussion:
To Subscribe:
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  Requirements for IP/TCP 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  IP/TCP compression scheme submitted to IESG for publication
JAN 01  Possible recharter of WG to develop additional compression schemes.
JAN 02  Initial draft on general signaling compression security analysis.
JAN 02  Requirements and assumptions for signaling compression
JAN 02  Signaling compression scheme submitted to IESG for publication as Proposed Standard, including security approach for SIP compression usage.
JAN 02  Layer-2 design guidelines submitted to IESG for publication as Informational.
APR 02  LLA mapping examples submitted to IESG for publication as Informational.
APR 02  I-Ds of ROHC IP/UDP/RTP bis, framework and profiles separated.
MAY 02  General signaling compression security analysis submitted to IESG for publication as Informational.
MAY 02  ROHC MIB submitted to IESG for publication as Proposed Standard.
AUG 02  ROHC UDP Lite schemes submitted to IESG for publication as Proposed Standard.
SEP 02  ROHC framework submitted to IESG for publication as Draft Standard.
SEP 02  ROHC IP/UDP/RTP schemes submitted to IESG for publication as Draft Standard.
SEP 02  Requirements for IP/TCP header compression submitted to IESG for publication as Informational.
SEP 02  IP/TCP compression scheme submitted to IESG for publication as Proposed Standard.
DEC 02  Requirements for IP/SCTP header compression submitted to IESG for publication as Informational.
DEC 02  IP/SCTP compression scheme submitted to IESG for publication as Proposed Standard.
Done  Possible recharter of WG to develop additional compression schemes.
  • - draft-ietf-rohc-rtp-lower-layer-guidelines-03.txt
  • - draft-ietf-rohc-tcp-requirements-04.txt
  • - draft-ietf-rohc-signaling-req-assump-06.txt
  • - draft-ietf-rohc-sigcomp-07.txt
  • - draft-ietf-rohc-epic-lite-01.txt
  • - draft-ietf-rohc-mib-rtp-02.txt
  • - draft-ietf-rohc-rtp-lla-r-mode-03.txt
  • - draft-ietf-rohc-sigcomp-extended-04.txt
  • - draft-ietf-rohc-sigcomp-udvm-00.txt
  • - draft-ietf-rohc-tcp-02.txt
  • - draft-ietf-rohc-rtp-impl-guide-01.txt
  • - draft-ietf-rohc-sctp-requirements-00.txt
  • - draft-ietf-rohc-tcp-field-behavior-00.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

    Current Meeting Report

    Minutes of the ROHC WG session at IETF 54

    Pacifico Yokohama, Yokohama, Japan
    Wednesday morning, 2002-07-17

    Reported by: Lars-Erik Jonsson
    Note takers: Pete McCann, Adam Roach,
    Christian Schmidt & Mark West

    Slides are available at

    Morning session, 0900-1130

    * WG admonishments (Carsten Bormann)

    Carsten reviewed the IETF working group principles, the IETF standardization process and the IPR rules defined by RFC 2026. People are encouraged to read RFC 2026 and RFC 2418, which define our processes. We are here to make the internet work, and we use rough consensus and running code instead of voting. The ROHC WG is chaired by Lars-Erik Jonsson and Carsten Bormann, with support from our area directors, Allison Mankin and Scott Bradner. Note that the real work is done on the mailing list, although face-to-face meetings can sometimes help the progress.

    Finally, Carsten stressed the RFC 2026 IPR policy, which says that any contribution must identify whether the contributor(s) is(are) aware of any IPR issues related to the contribution.

    * Agenda bashing (Carsten Bormann)

    Carsten presented the proposed agenda, which was accepted without modifications.

    * WG and document status (Lars-Erik Jonsson)

    Lars-Erik reviewed WG goals, milestones and document status. The LLA mapping, RTP draft standard and TCP profiles are late, but the work is ongoing. SCTP profile development has still not started, and there seems to be a lack of interest. Since the March meeting, a number of documents have been approved and/or published. In addition to RFC 3095 and RFC 3096, three more documents have now been published as RFCs, "ROHC over PPP" (RFC 3241), "0-byte requirements" (RFC 3243), and "LLA RTP profile" (RFC 3242). Also the SigComp documents have all been approved for publication and are currently in the RFC editor's queue. Two documents, "RTP lower layer guidelines", and "LLA RTP R-mode", have been tentatively approved by the IESG with some updates being requested, and are still awaiting the final IESG approval.

    Drafts: draft-ietf-rohc-sigcomp-07.txt

    * Signaling compression

    - User guide (Richard Price)

    Richard gave an overview of the SigComp user guide document and its purpose. SigComp itself defines a decompressor, while the intention with the user guide is to provide a companion document with hints for how to implement SigComp compressors, including various compression algorithms, optional enhancements (SigComp extended operations), and corresponding decompressor bytecode for the algorithms listed. The document further includes test message sequences, worked examples to clarify SigComp, and sample code. The user guide also defines a mnemonic language to simplify UDVM bytecode development, and here there are a few open issues for further consideration. One question regarding this document that was raised by Stephen Casner was about the IPR aspects of the various algorithms described. The conclusion was that all algorithms might be affected by various IPR claims, and each implementer will have to consider that. We can still document them and an IPR section will highlight that we know the algorithms described might be subject to IPR claims. Finally, Carsten brought up the question of how to proceed with the user guide, and people seemed to agree that it would be useful to keep this document as an Internet Draft for some time while we test interoperability, and publish it later.

    Draft: draft-price-rohc-sigcomp-user-guide-00.txt

    - Static dictionary for SIP/SDP (Carsten Bormann)

    A small design team with members from the SigComp, SIP and SIPPING communities was formed to create a static dictionary for SIP/SDP to be used by SigComp. The dictionary contains the strings most likely to appear in SIP/SDP exchanges and is supposed to be useful for LZ77- and LZ78-based compressors, which is a majority of the compressors out there). A 3855 byte string has been created by arranging all original strings and using any overlap. A problem is the dictionary size, which might not be feasible for all SigComp implementations. All substrings have therefore been given a priority between 1 and 5; a compressor can instruct the decompressor to load only a subset defined along these priorities. The dictionary is still changing due to SIP changes, and there are still some open issues related to handling of P-headers. Consequently, the State ID will also continue to change until the dictionary is frozen for publication.

    Draft: draft-ietf-sipping-sigcomp-sip-dictionary-03.txt

    - Next steps (Carsten Bormann)

    SigComp itself is done, but we need to do some more work on integration into e.g. SIP. However, this is as issue that will be discussed within the SIP/SIPPING groups. Another thing is to get interoperability testing going. There has been some initial testing during the UDVM development, but we need a more complete test set with less likely cases, and we need to test e.g. SIP integration, not just the UDVM. Carsten proposed to arrange virtual interops over the Internet to avoid travels, but a virtual interop host would still be needed to provide test engines and procedures.

    * ROHC RTP, Draft Standard preparations (Lars-Erik Jonsson)

    RFC 3095 was published in July 2001, it is thus time to start with the preparations for Draft Standard. This includes a number of steps to be taken. The most important is to show interoperability for all pieces we want to keep, and so far we have not identified anything we think should be removed. For Draft Standard, we must also finalize the MIB. Further, there is a significant editorial work needed since the intention is to separate the framework and profiles part of RFC 3095.

    - ROHC architecture document (Lars-Erik Jonsson)

    A ROHC architecture document has been written to simplify ROHC understanding, MIB development and implementation. ROHC entities and relationships are identified and some additional terminology is established. One important purpose is also to clarify how ROHC feedback works and can be implemented, which might be tricky to figure out from RFC 3095. It is not yet clear whether this should be published as a separate document, or go into the Draft Standard framework document. In any case, the MIB will refer to it. People are encouraged to read and comment, the document will be updated and resubmitted as a WG draft.

    Draft: draft-jonsson-rohc-architecture-00.txt

    - MIB (Juergen Quittek)

    The most important change in the MIB is the new structure with 2 MIB modules, one generic ROHC MIB and one RTP-specific MIB. Some inconsistencies with the architecture document will be resolved in the next version, and the cutting line between the generic and RTP-specific parts will be slightly revised. There was a question from the MIB author whether ROHC profile identifiers are unique, and Lars-Erik clarified that this is indeed the case. Juergen further asked for more input on useful statistics, and once more asked whether anyone is planning to implement the MIB. No positive responses this time either. Carsten remarked that maybe the question needs to be asked in a different venue as the ROHC implementers may not be around.

    Draft: draft-ietf-rohc-mib-rtp-02.txt

    - A ROHC profile for IP only (Lars-Erik Jonsson)

    RFC 3095 defines profiles for uncompressed, IP/UDP, IP/UDP/RTP and IP/ESP. People have asked for a profile for compression of IP only, which sounds like a reasonable request for simplified ROHC implementations and for use with new transports not supported by ROHC. The profile is similar to ROHC IP/UDP. There are some issues for further discussion. One applies also to the IP/UDP profile and concerns the CRC coverage, but this has already been discussed and does not seem to be any problem. Lars-Erik asked whether we should add this to the charter, and there was support from the audience to do so.

    Draft: draft-jonsson-rohc-ip-only-00.txt

    - Implementer's guide (Lars-Erik Jonsson)

    There have been some minor changes to the implementer's guide in the new version, based on mail list discussions. The scope of the document has been discussed and is rather clear at this point: it should supply additional clarifications to RFC 3095 for those implementing the standard. The enhanced mode transitions proposal is in some way an exception, but it does not change the standard and is mainly there to point out that it is ok to do simplified and enhanced transitions.

    Most, or maybe all, content of this document will go into RFC3095bis, so it will continue to live as an I-D until the Draft Standard work is completed.

    Draft: draft-ietf-rohc-rtp-impl-guide-01.txt

    - Implementation status (Lars-Erik Jonsson)

    Three ROHC interop events have been held so far. At the last interop, "Arctic ROHC" in Luleň, there were five implementations present from Effnet, Ericsson, Nokia, RokeManor/Siemens and Panasonic. Tests were carried out between almost all parties, initial IPv6 tests were successfully performed and even ROHC-over-PPP was tested. The Arctic ROHC participants suggested to have another interop in November, but there is no host for that event yet (Note: A host appeared the day after the meeting). As a result of discussions at Arctic ROHC, a new mail list has been set up for those who have participated in an interop. The intention with that list is to encourage interop participation and pre-interop discussions.

    One thing that obviously has been missing at previous interops is an RFC 3095 test document, clearly defining what to test. Such a document must be created, and should also be used to further keep track of the interoperability status for each test item.

    - Way forward (Lars-Erik Jonsson)

    The work for taking RFC 3095 further has started, but there are lots of things to do to make this happen. The IP profile should be finalized and brought to Proposed Standard. The architecture document must be completed as a reference for the MIB, which must be finalized and brought to Proposed Standard. An initial version of an RFC 3095 test list document must be written, which should be used as the basis for the next interop, yet to be scheduled. Finally, we need to start working on an "RFC 3095 surgery plan, i.e. outline how to split the document in Framework and Profiles.

    Lars-Erik also made a general comment of the way things work in the ROHC WG. We always seem to be behind schedule according to the milestones. However, since one can count the number of really active WG participants on two hands, we cannot handle that many things at once. We have been focused on SigComp for a while, which is now done, and now we start to allocate significant resources for TCP. More active participation in the WG would be appreciated in any case.

    * Generic (Formal) HC notation (Mark West)

    Mark gave a first presentation of what we have started to refer to as generic or formal header compression notation. The idea is to produce generic methods to describe a header compression process, where the original header is split up in fields, relationships between fields are identified, and encoding methods are chosen from an available set of methods. The notation will thus be a tool that can be used for future profile developments. After using the formal notation to describe the compression methods to use, a profile definition would then have to define how the compressed fields are turned into bits on the wire, but that encoding issue is not part of the notation.

    Based on the current drafts and latest mail list discussions, there are some issues we will have to discuss further. One is the question about separate versus combined notation, where the WG notation draft takes the latter approach and a counter proposal is based on the former. The other issue is about how much details should be captured by the notation. Discussions so far suggests that the notation should be independent of which bit-encoding is used, although it should give generally useful "hints" to that encoding process. A rule of thumb could be: "If a parameter can be ignored by any set of encoding rules, then it is ok, while if it is too suggestive or restrictive to a particular way of doing things, then it should not be used. The more general, the better."

    Mark also reported that some tests of the EPIC approach have been conducted between RokeManor and University of Split, with implementations based on the EPIC-lite draft. These tests seem to indicate that this approach is a workable basis for generating interoperable implementations. Carsten somewhat mellowed that conclusion by pointing out that there has been extensive communication between the two implementation groups, going beyond just exchanging specifications, and Mark confirmed that point.

    Lars-Erik noted that the goal is to simplify further work with new profiles. One of the difficult things with the ROHC RTP development was the generation of compressed header formats, which were done by hand without a structured work method. We want to have a notation so we can use automated encoding of the compressed fields into compressed headers, or as a structured basis for manual creation of formats. However, the notation today does much more than that, and it does not produce an output representation including only what is needed for compressed header encoding. Mark commented that this is the question about using a combined notation or not. Carsten said that there are both advantages and disadvantages of having a combined approach, but in this case the advantages are probably dominating. Qian said that the key question is that we need to efficiently label each field, which would motivate a separate uncompressed notation. Mark answered that it is not really necessary to know what the field is, might just show up as syntax or a comment. However, as soon as we go for separate notations, we need to label it to be able to come back to it. There are some few cases that might benefit from having an uncompressed notation, but most other cases would just get messy. There was no clear conclusion, but the next draft version will probably stick to the combined approach, more discussions will have to follow on that.

    Richard raised a question related to encoding. In EPIC or EPIC-lite, encoding is a two-stage process. The first stage is the field notation and compression of each field, and the second specifies how to convert these fields into a single compressed header. Different methods could be used for the second stage, but the notation must define methods for the first stage. This seemed to be the common understanding, notation covers encoding of fields, but not how to further create complete compressed header formats out of that.

    Finally, Carsten had some questions as a WG chair. First he wondered why we have two notation documents. Mark and Lars-Erik explained that Mark's document should had been a WG draft, but did not ask for a WG document name in time for submission. At the same time, an alternative submission was sent in. What will happen now is that Mark will incorporate some material from the second draft and resubmit it as a WG document. Carsten proposed that a small design team should be set up to finalize this, and asked whether two months is a reasonable timeframe. Mark answered that a couple of months sounds plausible ("but don't quote me"). The last discussion point was about what to do with this document. After some discussions, there seemed to be agreement on making this a standards track document, as previously done with other notations, such as the ABNF in RFC 2234.

    Drafts: draft-west-rohc-formal-notation-00.txt

    * ROHC TCP profile (Qian Zhang)

    Qian gave a quick update on the TCP profile work. The TCP compression requirements have been frozen, while the TCP behavior document needs some more work. Currently, it provides an analysis of the behavior of each field and some reflections regarding short-lived transfers, implicit acks, the potential use of a master sequence number, and shared data aspects. What should be added is an analysis of what fields can potentially be replicated, and how.

    For the actual profile development, there have been extensive discussions on the mailing list and the core issues have been resolved. There is now agreement to only allow context replication based on acknowledged contexts. Further, we have also agreed to use a master sequence number to reference packet, although there is no useful field for that purpose in the uncompressed TCP header itself. The cost of having an MSN is expected to be low, especially since it would not be required in all compressed packets. The third core issue that has been discussed and resolved on the mail list is about mode transitions for TCP. In the TCP profile, there is no need for a four-way handshake, as in the RTP case, since the packet formats are the same for the modes. Lars-Erik pointed out that this means we will not allow transition back to unidirectional operation, but that should not be a problem. A single feedback message indicates to the compressor that a feedback channel is available, and the compressor can then expect to get nacks in case of failure. For TCP, the concept of modes is thus not the same as in ROHC RTP, so we should maybe just talk about Unidirectional and Bidirectional operation.

    There are no significant open issues left to resolve at this stage, but we will have to wait for the notation work to progress before the TCP profile can be finalized. Mark said it is important to keep these two pieces separated, while Richard noted that we still look at real life protocols like TCP when developing the notation. Lars-Erik pointed out that the people working on the TCP profile are the same as those working on the notation, so it should be easy to keep these parts synchronized.

    Drafts: draft-ietf-rohc-tcp-requirements-04.txt