2.8.17 Robust Header Compression (rohc)

NOTE: This charter is a snapshot of the 61st IETF Meeting in Washington, DC USA. It may now be out-of-date.
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

Last Modified: 2004-10-15


Carsten Bormann <cabo@tzi.org>
Lars-Erik Jonsson <lars-erik.jonsson@ericsson.com>

Transport Area Director(s):

Allison Mankin <mankin@psg.com>
Jon Peterson <jon.peterson@neustar.biz>

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://www.ietf.org/mail-archive/web/rohc/index.html

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

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.
Done  ROHC MIB submitted to IESG for publication as Proposed Standard.
Done  ROHC IP-only profile submitted to IESG for publication as Proposed Standard
Mar 04  I-Ds of ROHC IP/UDP/RTP bis, framework and profiles separated.
Apr 04  ROHC UDP Lite schemes submitted to IESG for publication as Proposed Standard.
May 04  ROHC framework submitted to IESG for publication as Draft Standard.
Jun 04  Requirements for IP/TCP header compression submitted to IESG for publication as Informational.
Jun 04  IP/TCP compression scheme submitted to IESG for publication as Proposed Standard
Aug 04  ROHC IP/UDP/RTP schemes submitted to IESG for publication as Draft Standard.
Aug 04  Possible recharter of WG to develop additional compression schemes


  • draft-ietf-rohc-tcp-requirements-08.txt
  • draft-ietf-rohc-tcp-08.txt
  • draft-ietf-rohc-rtp-impl-guide-08.txt
  • draft-ietf-rohc-tcp-field-behavior-04.txt
  • draft-ietf-rohc-rtp-rfc3095-interoperability-03.txt
  • draft-ietf-rohc-formal-notation-04.txt
  • draft-ietf-rohc-udp-lite-04.txt
  • draft-ietf-rohc-sigcomp-impl-guide-03.txt
  • draft-ietf-rohc-context-replication-06.txt
  • draft-ietf-rohc-sigcomp-nack-02.txt
  • draft-ietf-rohc-rtp-lla-impl-guide-00.txt
  • draft-ietf-rohc-over-reordering-00.txt

    Request For Comments:

    RFC3095 PS RObust Header Compression (ROHC)
    RFC3096 I Requirements for robust IP/UDP/RTP header compression
    RFC3241 PS ROHC over PPP
    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
    RFC3320 PS Signaling Compression
    RFC3321 I SigComp - Extended Operations
    RFC3322 I Signaling Compression Requirements & Assumptions
    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
    RFC3759 I RObust Header Compression (ROHC):Terminology and Channel Mapping Examples
    RFC3816 Standard Definitions of Managed Objects for Robus Header Compression
    RFC3843 Standard RObust Header Compression (ROHC): A Compression Profile for IP

    Current Meeting Report

    Minutes of the ROHC WG session at IETF 61

    Hilton Washington, Washington DC, USA
    Monday Morning, 2004-11-08

    Chairs: Carsten Bormann & Lars-Erik Jonsson

    Reported by: Lars-Erik Jonsson
    Note taker: Christian Schmidt
    Jabber scribe: Gorry Fairhurst

    Morning session, 09:00-11:30

    * WG admonishments (Jonsson)

    Meeting time will 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. Also, all contributors must be aware of the IPR principles, as stated by RFC 3668.

    * 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 towards Draft Standard
    - ROHC TCP and Formal Notation
    - ROHC RTP towards Draft Standard
    + Various ways to go forward
    + ROHC implementer's guide
    + RFC 3095 in Formal Notation
    - LLA ROHC RTP Implementer's guide
    - ROHC over channels that can reorder packets
    - ROHC over 802 networks

    * WG and document status (Jonsson)

    Lars-Erik reviewed WG goals, milestones and document status. The WG has 13 published RFC's, but no new publications have been made since San Diego. The UDP-Lite profiles draft has passed IANA and is expected to be published within a month or two. Four drafts have been submitted to the IESG, the SigComp NACK draft and three drafts related to ROHC-TCP. In San Diego, we said that we were about to update the milestones, but we had hoped to get the TCP profile completed and submitted first, which we have still not managed to do. The milestone update is thus still pending.

    * Signaling compression issues

    - Applying SigComp to SIP (Bormann)

    Carsten gave a summary of the three open issues for SIP over SigComp. SigComp defines a default state memory size of 0, while it has been suggested to mandate more for SIP, as it has been observed that stateless compression for SIP/SDP does not give much gain. The current proposal is thus to have 2K per state compartment, and require NACK support for a compressor that wants to make use of the state memory. There were no SIP implementers in the room that had any comments on this proposal.

    Second issue is about the definition of compartments, as they need to be well-defined to avoid accidental push-outs. The original proposal was to use SIP dialogs, but another idea is to have three different compartments for; registration related messages (R), dialog-related messages (D), and subscription-related messages (S). Question is, can this be clearly defined, and is (nr*R+nd*D+ns*S) in any way worse than (n*D)? No comments were received from the audience.

    Third issue left is the question on "TCP step-up", i.e. whether it should be possible to start SigComp compression in the middle of a SIP TCP connection? In many architectures, this requires a SigComp shim layer to add SIP parser, which is a non-desirable requirement. The solution would thus be to open another TCP connection to start SigComp.

    There is a pressing need to make this document available to 3GPP in an updated form, and Carsten promised to make sure an update will be available by the middle of next week, at latest.

    Draft: draft-ietf-rohc-sigcomp-sip-01.txt

    - SigComp towards Draft Standard (Bormann)

    Interoperability test events for SigComp have been held at SIPit. Now we need to collect interoperability test status and create a matrix document with all "features" we can identify, and endure there are at least two independent interoperable implementations for every feature. After that, we are ready to bring SigComp, RFC 3320, forward to Draft Standard. An ancillary document that might go with this is of course the implementer's guide, but potentially also the User Guide (draft-ietf-rohc-sigcomp-user-guide-00), as well as the Torture Test Guide (draft-price-rohc-sigcomp-torture-tests-02), which are both expired drafts (one actually individual), expected to provide useful material for implementers. These two should thus be resurrected, if we find people interested, as original author is not active in the WG anymore. Mark West expressed potential interest in doing this, and we should continue discussion on the list.

    RFC: RFC 3320
    Draft: draft-ietf-rohc-sigcomp-impl-guide-03.txt

    * ROHC TCP & Formal Notation (Pelletier)

    Three of our five drafts related to ROHC TCP, requirements, TCP behavior, and Context Replication, have been submitted to the IESG. However, the actual specification, consisting of the TCP profile draft and the Formal Notation, are still not finalized, although we are getting closer to completion. In latest update, packet formats have been redefined based on an updated and simplified FN. We need somewhat to start doing a thorough review of the packet formats themselves. In the FN, external coding methods (using underscore syntax) are gone and Profile Specific Encoding Methods are instead defined. Further has the formal meaning of annotations been removed and replaced by a note in the ROHC-TCP profile. The encoding methods for crc's have also been combined into one general method with arguments, and the environment of the let statement has been clarified. There are now mainly two issues left, about the definition and use of control fields, and how to completely capture list encoding in FN.

    The problem with list compression as it currently stands is that if one option is not present the entire list compression fails. Carsten noted that there are many ways to solve this, and suggested to try to keep the mechanisms simple. Ghyslain asked whether that means we should simply use English language, as we do for header chaining, although that is not formal notation. The concern Ghyslain had with that approach is that we seem to be removing many things from the FN just because we can not manage to make it work, which makes the value of the FN clearly questionable. Carsten suggested that we could make use of the recursion we have in the FN, which Ghyslain commented would not look very good. Carsten agreed but thought it might be a fast way to get to a resolution.

    The control field concept currently used in the FN and TCP profile has been questioned. Carsten means this goes against the core FN principle of only defining packet formats and encoding between uncompressed and compressed values, as control fields are rather functionality for interacting with the contexts. The alternative approach suggested is to provide control field data to packet formats as parameters. Others argued that control fields are very similar to other fields, it is just that they do not appear in any uncompressed header. Carsten went through an example with the two different approaches, and the conclusion was that the current way with control fields should be kept, but their meaning must be more precisely defined.

    Ghyslain then talked about the way forward with ROHC-TCP. Work on the FN has kept us away from the actual work on TCP compression, and still do. WG resources are also at a minimal level to get any work at all done. We should ask ourselves whether we really think we can manage to get a workable FN-based solution, and how much time we can spend before we start reconsidering Box Notation. Anyway, in any case we still need 2 committed reviewers for each document. We hope it is still possible to issue WGLC by the end of November. Carsten raised a couple of issues that he believed might still lack complete resolutions. Ghyslain answered that these should all be resolved by the latest update, but encouraged review of the details.

    Drafts: draft-ietf-rohc-tcp-08.txt

    * ROHC RTP towards Draft Standard

    - Introduction (Jonsson)

    Lars-Erik gave an overview of the various approaches available for taking RFC 3095 further to Draft Standard. At an early point we saw that it would be a good idea to split the current document into two separate parts, framework and profiles, and this was thus our original plan. However, during implementation we have identified a number of more or less complicated ambiguities, which so far have been documented in the implementer's guide. These issues will have to be incorporated when going through the update process for 3095, and it is then not clear whether we can go directly to DS, as the changes might be seen as non-trivial. We also know that implementers have expressed real concerns about the complexity of RFC 3095, and we know by now that if we had done it today we would simplify things significantly. When discussing the way forward with 3095, another potential option is to actually redefine the 3095 profiles based on our experience and standardize simplified profiles, which will then be given new profile numbers. If we go this path, there are several aspects to consider. Will we be able to go to DS with these new profiles? What happens with the current profiles, which are used by other bodies like 3GPP. With this approach, we will actually produce a new standard set that is not interoperable with the current one. Carsten noted that if we only use existing solutions from 3095, i.e. stick to simplifications, we should be able to get to DS as we will have tested interoperability for all features. There was a comment from the audience that the 3GPP reference to 3095 would not be a problem as 3095 will stay as it is. Lars-Erik noted that 3095 do has errors, which means we should ensure we provide error-fix documents for 3095. It was suggested that could be done as an appendix to the new profiles, but after discussion it was agreed it would make more sense to keep that as a separate document. Lars-Erik concluded that the sense of the room was to focus our effort on getting things right and say this is what goes to DS, instead of spending resources on fixing the old stuff. Someone in the audience asked for examples of what can be simplified. Examples mentioned were list compression, some other rather complex packet type combinations, and other redundancy in functionality that only gives minimal compression gains. The concept of modes could potentially also be simplified. Many of these simplified solutions are currently being used for the TCP profile, which means we have a rather good knowledge of both what should be made simpler and how it can be achieved.

    RFC: RFC 3095
    Drafts: draft-ietf-rohc-rtp-rfc3095-interoperability-03.txt

    - Implementer's Guide (Jonsson)

    The implementer's guide has been updated three times since the last IETF. A new chapter 7 has been added on Context management and CID re-use, as discussed and agreed on the mail list. A new section 8.12 on ack usage in O-mode has also been added as a response to questions from implementers, based on the outcome of the discussions that followed from that question.

    There is still no conclusion on the question about the potential use of an implicit slope to compress and decompress timestamps. This is an important issue that must be resolved to ensure interoperability. Ghyslain noted that RFC 3095 does not define the concept of slopes, one has to really over-interpret the document to get to this. Carsten asked whether anyone believes we have enough material in 3095 to even get slopes working, and expressed some doubts. Ghyslain asked for more chair support in this discussion, as we should ask the list to prove both that the slope concept exists in 3094, that it in needed, and that it works. We could of course spend significant efforts on writing a document to summarize all aspects of slope versus non-slope operation, but Ghyslain suggested we might not have to do that if chairs get more involved in the discussion.

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

    - RFC 3095 in Formal Notation (Bormann)

    Carsten gave a quick presentation on an ongoing work he is doing on defining packet formats for the profiles in RFC 3095 with formal notation. The goal is to get semantic checker for ROHC-FN to find typos, inconsistencies, and missing pieces, as well having a more formalized and consistent way of defining packet formats. Ghyslain commented that although this effort is good, it has a tendency to take focus away from the actual work, and so far formal notation has mainly made the work harder. Carsten responded that 3095 took a lot of work to complete too, and box notation is not always very accessible either. Existing implementers are comfortable with box notation, but new and simpler profiles could attract new implementers. This is work that is currently done outside of the ROHC WG, we will consider it when there is more results to look at.

    Draft: draft-brinkmann-rohc-3095-fn-00.txt

    * LLA ROHC RTP Implementer's guide (Sandlund)

    During implementation, a bug was identified in RFC 3242 that makes the CSP packet non-interoperable. The ROHC CRC is calculated over the whole uncompressed packet, including length fields, which are normally inferred from the packet length. However, with CSP the payload is dropped and the packet length can therefore not be inferred anymore. Through discussions on the mail list, it was agreed to add a two-octet payload length field to the CSP, as the overhead should not be a problem, considering the expected use of the CSP. This has been described in the new LLA implementer's guide, along with a clarification that CCP verification needs inferred length fields to be stored in context. One additional clarification should be added in an updated version, correcting a confusing cross-reference to RFC 3095, which might be interpreted to include more than was actually intended.

    Carsten asked about the implementation status of LLA, and Kristofer answered that he has a complete implementation, but he is not aware of any other implementations.

    Allison Mankin pointed out that this does looks more like a bug fix than an implementer's guide, and should be published with a proper label. Chairs will discuss the further handling of this with Allison.

    Draft: draft-ietf-rohc-rtp-lla-impl-guide-00.txt

    * ROHC over channels that can reorder packets (Pelletier)

    Ghyslain just wanted to remind people of the existence and purpose of this document. The goal at this point is to produce an Informational document, not to update any standard. If we want to do some actual standardization work later on, we will be able to use this document as a reference and problem analysis. We know now that ROHC has good potential to be used also if reordering can happen, although there are a number of issues to consider. Carsten asked about how ECRTP differs in its ability to handle reordering. Ghyslain answered that the situation is similar for ROHC and ECRTP. ECRTP can handle some reordering if properly implemented, but there is nothing in the standard that explains how to do that, and the compression efficiency will be significantly affected. There is a master thesis to be published at Lule? University on the subject of ECRTP over reordering channels. Allison reminded people of the ongoing work on header compression over MPLS, where they are meant to look at both ROHC and ECRTP. Lars-Erik asked about the status of that work, and where it is supposed to be carried out. Allison said it is mainly an AVT activity, with some MPLS involvement. The requirements are done, and now it is time to start working on solutions, based on existing IETF solutions. Someone in the audience asked whether ROHC would be a possible candidate, and Allison responded she believed that would be a reasonable assumption. It could be a good idea to write up a similar document as the ROHC over reordering analysis also for ECRTP, making it easier to compare the two and go further. Allison said she will feedback this to AVT, and she also encouraged people from ROHC to take part in the AVT work on header compression.

    Draft: draft-ietf-rohc-over-reordering-00.txt

    * ROHC over 802 networks (Bormann)

    Carsten Bormann gave an overview of his individual draft submission on ROHC over 802 networks. We have seen interest in this before, and now there are several new forms of 802 networks that could make use of header compression. In generale, being able to do ROHC over any link technology requires two things to be defined, encapsulation and negotiation. Carsten claimed that although it is not obvious how to do negotiation, the challenge is to find a proper encapsulation solution, as that is the key both to ensure one can get any gain at ll from header compression, as well as to make the solution deployable. A proper encapsulation should provide length information and try to minimize overhead, and most encapsulations that exist fail at least when it comes to overhead. In most of these systems, there is a little bit over Ethernet, requiring a minimal packet length of 46 bytes of payload. Considering that we would like to compress over a chain of bridged links where the bridges are not aware of compression, we must find a way to get the bridges not to insert padding, and encapsulation must be robust to padding. To get length information into the packets, Carsten suggest to use 802.2 LLC, with "Length field" instead of "Ethertype". Demultiplexing must then be handled in the payload, with an SSAP/DSAP identifier. Gorry noticed that IEEE claims to control these identifiers. Ghyslain asked whether this work really belongs in ROHC, which Carsten agreed is a very good question to ask ourselves. Gabriel Montenegro recommended interested ROHCers to come to the "IP over low-power WPAN" BOF.

    The draft currently focuses on the encapsulation part of the problem, but will of course have to address also negotiation if we manage to get a proper encapsulation defined. We also have to consider multicast and broadcast scenarios, where negotiation could be made in form of announcements and/or pre-configuration. Gorry asked how ROHC itself would work in such scenarios, and Carsten responded that we already have the U-mode operation.

    Draft: draft-bormann-rohc-over-802-00.txt


    RObust Header Compression WG (ROHC)