2.7.13 Robust Header Compression (rohc)

NOTE: This charter is a snapshot of the 63rd IETF Meeting in Paris, France. 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: 2005-07-08


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
Done  ROHC UDP Lite schemes submitted to IESG for publication as Proposed Standard.
Done  Requirements for IP/TCP header compression submitted to IESG for publication as Informational.
Apr 05  Problem analysis ROHC-over-channels-that-can-reorder-packets submitted to IESG for publication as Informational
May 05  I-Ds of ROHC IP/UDP/RTP bis, framework and profiles separated.
Sep 05  ROHC framework submitted to IESG for publication as Draft Standard.
Sep 05  IP/TCP compression scheme submitted to IESG for publication as Proposed Standard
Nov 05  ROHC IP/UDP/RTP schemes submitted to IESG for publication as Draft Standard.
Dec 05  Possible recharter of WG to develop additional compression schemes


  • draft-ietf-rohc-tcp-requirements-08.txt
  • draft-ietf-rohc-tcp-10.txt
  • draft-ietf-rohc-rtp-impl-guide-13.txt
  • draft-ietf-rohc-tcp-field-behavior-04.txt
  • draft-ietf-rohc-rtp-rfc3095-interoperability-04.txt
  • draft-ietf-rohc-formal-notation-09.txt
  • draft-ietf-rohc-sigcomp-impl-guide-05.txt
  • draft-ietf-rohc-sigcomp-user-guide-02.txt
  • draft-ietf-rohc-context-replication-06.txt
  • draft-ietf-rohc-rtp-lla-impl-guide-01.txt
  • draft-ietf-rohc-over-reordering-03.txt
  • draft-ietf-rohc-sigcomp-torture-tests-01.txt
  • draft-ietf-rohc-rfc3242bis-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
    RFC4019 Standard RObust Header Compression (ROHC):Profiles for UDP-Lite
    RFC4077 Standard A Negative Acknowledgement Mechanism for Signaling Compression

    Current Meeting Report

    Minutes of the ROHC WG session at IETF 63

    Le Palais des Congress De Paris, Paris, France
    Monday Afternoon, 2005-08-01

    Chairs: Carsten Bormann & Lars-Erik Jonsson

    Reported by: Lars-Erik Jonsson
    Note taker: Andrew McDonald

    Afternoon session, 16:30-18:00

    * WG admonishments (L-E 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 3379.

    * Agenda bashing (L-E Jonsson)

    Lars-Erik presented the proposed agenda, which was accepted without modifications.

     - Chair admonishments and agenda bashing   
     - WG and document status update
     - SigComp work, status and future
     - ROHC TCP & Formal Notation
     - HC over IPsec Security Associations
     - HC over MPLS (AVT work item)
     - ROHC RTP, time for a second version?

    * WG and document status update (L-E Jonsson)

    Lars-Erik reviewed WG milestones and document status. The WG had 13 published RFC's last time we met, and two new publications have been made since Washington, RFC4019 (the UDP-Lite profiles), and RFC4077 (SigComp Nack). Three documents are in the RFC editor queue (Context Replication, ROHC TCP Requirements, ROHC over Reordering), and one just got approved by the IESG (TCP field behavior). No ROHC drafts are currently in the IESG approval process, but the 3242bis draft will soon be submitted as it has passed WGLC. This leaves us with 8 WG drafts currently being worked on, four related to SigComp, two for ROHC TCP, as well as the ROHC RTP implementer's guide and implementation status documents.

    Looking at the milestones, we are on track, but the ROHC RTP DS milestone will probably have to be redefined, as addressed by the last item on the meeting agenda.

    * SigComp work, status and future (Mark West)

    Mark went through the four current WG drafts related to SigComp.

    Torture Tests define tests for correct behavior and boundary cases of the udvm. Recent changes have been minor, and the authors believe the document is ready to ship.

    The User Guide, which includes mnemonic code, example decompressors, and other common functions, has been there for a long time and only some few changes have been made lately. The most recent changes are the addition of a "read only directive" and a simplified shared mode example. Some feedback on these parts would be appreciated, but apart from that authors believe it is ready to ship.

    It was agreed to issue WGLC for the Torture Tests and User Guide documents, after having explicitly asked some known implementers to comment on the most recent changes to the User Guide.

    The Implementer's Guide provides clarifications to rfc3320, and has been stable for a while as well. It might, however, be nice to keep this document open, e.g. to leave time for some nack implementation experience. Mark asked whether anyone got a nack implementation? Adam Roach answered that he has nack working (implemented before it was documented), but he has not had anyone to interoperate with. It was thus agreed to keep the Implementer's Guide open for some more time.

    SigComp for SIP is a currently expired draft. While RFC3486 covers SIP-level aspects of sigcomp, this draft discussed sigcomp-level aspects for SIP, such as minimum SMS/DMS, locally available state, and compartment mapping. An update was initiated, but not completed. The document is in general trivial, but important. The non-trivial part is the compartment mapping. To have it per dialog means not much state must be kept, which is both good and bad. However, Adam pointed out that this is catastrophic rather than bad. To have it per registration means lots of state is to be kept, which can also be considered both good and bad. Adam meant this isn't that bad, but rather necessary. Carsten noticed that because memory is cheap, he also prefer per registration. However, when trying to write this up, he found it rather hard, because of relationship between sip entities it is not clear how messages relate to a particular registration. Adam pointed out that there is relevant work in a sip draft, registration instances, and we should talk to Cullen Jennings about this. There might be a solution there, but it might also be a bad idea, someone has to look at it. Carsten/Mark/Adam should cooperate to get this draft finalized, and potentially engage more people (with good SIP knowledge) in the process.

    Gabor Bajko asked about the sip multiplexing that was taken away according to one of the slides on SigComp for SIP. Mark answered that it was about how to multiplex sigcomp and non-sigcomp in single TCP connection, which was agreed not to be needed. Lars-Erik noted that we had this discussion several times, and always came to same conclusion. Mark reminded us of the most important points from the discussion, and why we came to that conclusion.

    SigComp, RFC3320, has been there for some time now, and tested for interoperability at least at one dedicated event in February 2003. The specification seems to be solid and stable, with only some few minor issues identified by the implementer's guide. It should thus be possible to prepare for Draft Standard advancement. Lars-Erik noted that we would need a volunteer for the editorial work for Draft Standard. Mark asked how much work is required, to which L-E responded that this is very much up to the editor, but implementer's guide is fairly short, which suggests it should not require too much work. Mark said we may have a volunteer, but he could not promise anything at the meeting.

    RFC's: RFC 3320, RFC 3321
    Drafts: draft-ietf-rohc-sigcomp-sip-01.txt (EXPIRED)
    * ROHC TCP & Formal Notation (Carsten Bormann)

    Carsten noted that the current documents are tcp-10 and notation-09, versions got wrong in early revisions of the agenda. The documents are currently in WGLC due to end tomorrow. However, there have not been any comments on the documents yet, although we have received comments that doing WGLC at the time of reading lots of drafts before an IETF was not a good idea. Ted Faber (tcpm chair)said that he and others from tcpm will read these if they get more time. We will thus extend the WGLC to the end of August to give reasonable time for in-depth review.

    Drafts: draft-ietf-rohc-tcp-10.txt
    * HC over IPsec Security Associations (Emre Ertekin)

    The objective with this proposal is to reduce the overhead of IP packets over IPsec Security Associations. IPsec comes at the cost of increased overhead, and per-link header compression can not compress the inner headers since these are hidden through encryption. Only if compression is applied at the tunnel endpoints, this overhead can be reduced. Although an IPsec tunnel may have intermediate hops, it has a source/destination association to which HC can be applied. The order would thus be to; map packets to HC context, compress, encrypt, and finally add ESP/IP headers for the secured tunnel. These outer headers may then of course be compressed on a per-link basis

    The draft outlines a solution framework by giving work assumptions, and work items:
    • First of all, HC scheme specific extensions may be needed, i.e. increased tolerance to reordering, packet loss (solutions based on the "rohc over reordering channels" document)
    • Secondly, initialization and negotiation of the HC channel as part of the IPsec SA. This means leverage IKEv1/IKEv2.
    • Finally, we need encapsulation and identification of HC packets, which should be straightforward for ROHC, as ROHC identifies its own packet types (other HC schemes, e.g. eCRTP, require external packet type identification).
    There have been some comments and questions raised on the list. The first was about whether the ROHC uncompressed profile can be used to multiplex compressed and uncompressed flows. However, access control enforcement may not allow this proposed resolution. An alternative could then instead be to establish two SAs, one for compressed, one for uncompressed. Mark commented that using two SAs seems to be a warped mapping as it implies IPsec processing knows whether flow is compressible or not rather than just handing it to HC processing. L-E reminded us that this would not be the first time ROHC is put on top of a "multi-channel link", so such a solution is not that warped. On the other hand, how this is done is out of scope for the actual standards work, it is an implementation/realization issue.

    An other question is how to identify and multiplex traffic, whether to register new IP protocol numbers. For ROHC, there would be only one packet type, but for eCRTP and other schemes, multiple types are needed, and that may consume many protocol numbers. One way could be to register one protocol number for ROHC and one for "other HC", and for the latter type there would be one additional byte added to indicate packet type. This approach would be similar to how it is suggested to work for ECRTP over MPLS.

    Next steps with this work would be to update the draft based on feedback and discussions, and to initiate work on a draft detailing the extension to IKEv2 for HC parameter negotiation (IKEv2 seems to be easier than IKEv1).

    Hideaki Yoshifuji said he could not understand benefit of this proposal, and asked how this is different from IPcomp. Emre answered that IPcomp is a simple per-packet payload compression, which does not provide much gain when compressing packet headers. Ajoy Singh asked whether this can be applied to other tunneling, e.g. v6 over v4. Emre answered that the big issue would be that we are leveraging IKE for negotiation. L-E pointed out that the thing here is that you can not compress on a per-link basis, because of encryption. When there is no encryption, ROHC can already compress tunnel stacks, and a ROHC implementation must support both IPv4 and IPv6 compression.

    L-E observed that the ROHC WG is not chartered to do this work, but it is something to look at. Negotiation would not be work for rohc, but rather work for the IPsec WG, monitored by ROHC. Work for us is to improve the reordering tolerance of ROHC, and packet multiplexing. It would probably also be useful to have an overview draft, like the individual one presented, as informational. There were no objections to the proposal to adopt this as a WG item.

    Draft: draft-ertekin-rqts-hcoipsec-01.txt

    * HC over MPLS [AVT work item] (Jerry Ash)

    L-E explained that this could be seen as a guest presentation from the AVT WG, but as it includes ROHC we thought it was a good idea to have it here too, to make people aware of it. Jerry explained that it outlines a pseudo-wire approach to HC over MPLS, and is not limited to ECRTP. It is now a work item in the AVT charter, for submission by December. Idea is to run HC over an MPLS tunnel, i.e. to leave headers compressed over multiple hops, and just route on MPLS labels. This way HC compression/decompression cycles at intermediate routers can be avoided. Discussions have been cross-posted to AVT, ROHC and PWE3, as competence is needed from all three WG's. The underlying approach is to use pseudo wires carrying layer 2 PDUs on an encapsulated MPLS path. It builds on top of the work defined for pseudo wire signaling in PWE3. Pseudo wire type indicates HC scheme, and these types have already been defined in the PWE3 IANA draft. Carsten noted that one document mentioned is RFC1144, while RFC1144 does not handle reordering. There should at least be a dire warning about that. Jerry responded that the goal was to be generic, and maybe it became too generic. We will have to look at that. L-E reminded people that this is not an item for ROHC WG work, but it has many similarities and some same issues as HC over IPsec. ROHC folks are thus encouraged to keep an eye on and participate in these AVT discussions.

    Draft: draft-ash-avt-hc-over-mpls-protocol-01.txt

    * ROHC RTP, time for a second version? (L-E Jonsson)

    The following will be a continuation of the discussion we had in Washington, and on the list thereafter. Those who were in Washington will thus recognize some of the initial slides.

    Originally, our "Plan A" was to move from framework + profiles (uncomp, IP/UDP/RTP, IP/UDP, IP/ESP) in one single Proposed Standard document, RFC 3095, to separate Draft Standard documents for framework and profiles. However, implementation has unveiled lots of issues in RFC3095, which made us create the "implementer's guide", and incorporating that material when going to Draft Standard became our "Plan B". However, considering the significance of the issues clarified and corrected by the implementer's guide, we have realized that going to Draft Standard from RFC 3095 might thus not be realistic. Framework could be taken to Draft Standard, but the profiles would have to be recycled at Proposed Standard. However, the sense of the room in Washington, as well as opinions from implementer's and others on the mailing list, has indicated that we have a clear consensus to not spend our limited resources on updating existing profiles. Instead, it would be better to issue new profiles based on experience, a ROHC version 2. This means we will have two sets of profiles.

    The Implementers guide originally identified problems that had to be resolved to create interoperable RFC 3095 implementations. Appendix B now gives also the things we would like to do better, i.e. a summary of the "lessons learned from RFC 3095", as discussed on the mailing list. There are a number of more or less significant changes, but all have been carefully reviewed and agreed on the mailing list before being added. There is, however, one item that we have not been able to reach consensus on, yet; whether the CRC should not be split into static/dynamic, as it is in RFC 3095. We encourage implementers to speak up and express opinions on this. Mark commented that it should be fairly easy to do some quick experiments. According to Carsten, the original discussion was based on the observation that people were struggling to make CRTP fast. ROHC/CRTP cost about the same number of instructions before the CRC calculation, and static/dynamic split sounded a good idea. Of course, splitting fields also involves instructions. L-E concluded that we will have to figure out what to do with this, based on more concrete material.

    To sum up, L-E suggested a way forward. We are currently chartered to do Draft standard of RFC 3095. Since we have WG consensus to better spend resources on doing a real update, the proposal is to:
    1. remove RFC 3095 profiles Draft Standard from the milestones
    2. instead add milestones for revised profiles, which would solve current issues and address new requirements (i.e. be based on Appendix B of the Implementer's Guide)
    One issue would then be what to do with the Implementer's Guide and the RFC 3095 profiles? The original intention was to never publish the Implementer's Guide as an RFC, but incorporate its content into the DS. When we now change our plan for RFC 3095 DS, we should also reconsider what to do with the Implementer's Guide. The proposal is therefore to:
    1. publish the implementers guide as a stable reference for implementing the RFC 3095 profiles
    Question is what sort of RFC this should be? Allison Mankin answered that we need to make clear in the document what it does for people, and then worry about category later. We should make clear who is supposed to reference it, and how. That would probably indicate which category it should belong in. L-E will revise the Implementer's Guide to make its purpose clear, and at the same time split out Appendix B.

    RFC: RFC 3095
    Draft: draft-ietf-rohc-rtp-impl-guide-13.txt


    Agenda and all Slides