Last Modified: 2004-10-15
| 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 |
| 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 |
|
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 modifications. Agenda: - 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 draft-ietf-rohc-formal-notation-04.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 |