Last Modified: 2005-07-08
| 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 |
| RFC | Status | Title |
|---|---|---|
| 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 |
|
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. Agenda: - 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)
draft-ietf-rohc-sigcomp-impl-guide-05.txt
draft-ietf-rohc-sigcomp-torture-tests-01.txt
draft-ietf-rohc-sigcomp-user-guide-02.txt
* 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
draft-ietf-rohc-formal-notation-09.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:
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:
RFC: RFC 3095 Draft: draft-ietf-rohc-rtp-impl-guide-13.txt |