Minutes of the ROHC WG session at IETF 66 ========================================= Tuesday evening, 2006-07-11, 17:40-19:50 Meeting Chair: Carsten Bormann WG Chair: Lars-Erik Jonsson (on Jabber) Reported by: Lars-Erik Jonsson Note taker: Andrew McDonald * WG admonishments and agenda (Carsten Bormann) Carsten serves as chair for the meeting since L-E is not present. Agenda (accepted as is): 1740 Chair admonishments and agenda bashing 1745 WG and document status update 1800 Corrections and Clarifications to RFC 3095 1810 ROHC Framework and ROHCv2 1900 HC over IPsec Security Associations 1940 ROHC TCP & Formal Notation * WG and document status update (Carsten Bormann) Since the last ROHC meeting (IETF63) some new ROHC RFCs have been published, more specifically the ROHC TCP requirements, TCP field behavior, Context replication, ROHC over reordering channels, the corrected RTP LLA profile, and the SigComp users guide and torture tests. Currently, there are no ROHC documents in the publication pipe, neither in the RFC editor queue nor among the IESG. However, there are several documents that should soon be ready to leave the WG. A charter update proposal was sent out on June 22. The whole charter has been rewritten, making the background and history short while focus is on current aims, i.e. ROHCv2, RFC3095 clarifications and corrections, ROHC over IPsec, and the remaining SigComp work. There are quite a few milestones, but a lot of work is already done. Carsten asked for comments on the milestones, and Magnus answered that the text should make clear that the framework is backwards compatible with RFC 3095, that was the only comment from the IESG review. L-E noted (via Jabber) that one must remember that ROHCv2 will provide a new set of profiles, and these will be different than the v1 profiles. Since we do not intend to enforce implementation of the v1 profiles, ROHCv2 as a whole will not be backwards compatible with ROHC as given by RFC 3095. * Corrections and Clarifications to RFC 3095 (Ghyslain Pelletier) This document started as collection of guidelines from interop tests, the goal with it has changed during its lifetime. It includes corrections, clarifications and guidelines to RFC 3095 and profiles based on RFC 3095. It does not change profile version numbers, but actually says how the RFC 3095 profiles must be implemented. Between -18 and -19, the draft has been rewritten to be clearer on what is corrected/invalidated/added to RFC 3095. Target is to publish it as a Standards Track RFC (PS). There are still some open items about context repair, TS_STRIDE, TIME_STRIDE, updating properties of ext-3 with UO-1ID, and possibly a rewrite of section 3.3 to make its content clearer. We want to proceed carefully to get careful review, but the goal is to send this draft to the IESG around September/October. RFC's: RFC 3095 Draft: draft-ietf-rohc-rtp-impl-guide-19.txt * ROHC Framework and ROHCv2 (Ghyslain Pelletier) - The ROHC Framework The idea is to split out common part from profile specific parts. The ROHC framework describes core definitions and parts common to all profiles, it existed in RFC 3095 but it was not explicitly separated from the profiles. The ROHC framework is not changed from RFC 3095, which means there is only one single ROHC basis and backwards compatibility is guaranteed. Recent changes to the draft include text to clarify what sort of channels rohc is applicable to, explicit identification of all packet type identifiers which are unused by the framework, clarifying text on the roles of the three different CRCs (which have different purposes), and the uncompressed profile is now defined by the framework. The updated draft also includes a proposed new channel parameter, "maximum reordering depth", intended to be used to better adjust tolerance to reordering in v2 profiles. It is optional to negotiate and may be used by a profile. Another option was to have a feedback option. Carsten questioned whether this is something the network can know proper values for, i.e. if the parameter really makes sense. L-E said he would like to avoid adding things in the negotiation, and he wants alternatives to be carefully investigated and presented to the WG before we settle on including this new negotiation parameter. Carsten strongly agreed on that. Emre noted that at least from an HCoverIPsec point of view, this parameter seems useless since you do not know what the reordering characteristics are as the number of hops may change over time. Ghyslain responded that it is supposed to be optional, one do not have to negotiate it. There was a discussion about target document class for this draft, but the idea is clearly to make it PS, anything else would be hard to defend. We should try to freeze this document and focus on rohcv2 profiles, although we should probably publish them in parallel. Two committed reviewers are needed, it is only 30 pages and should not be hard to review. - 3095-based profiles and reordering Reordering of packets before the compression point can be handled by RFC 3095, but RFC 3095 assumes there is no reordering of packets between compressor and decompressor. Not having a CRC on all packets (e.g. R-mode) also complicates things if there can be reordering. RFC 4224 covers most problems with 3095 and reordering. There have been comments on list that there are lots of changes to the profiles in the v2 profile proposal. These mainly based on the problems identified by RFC 4224. If you read 4224 you will see that there is much more to consider than just the interpretation interval. Carsten noted that there is a difference between reordering and undetected reordering. If there is something in the channel that tell the decompressor when packets have been reordered, life gets easier. Ghyslain responded that this is a strong assumption, but Carsten pointed out that there are channels that have this property, and Ghyslain agreed it is much easier if you know this. - ROHCv2 profiles Ghyslain presented the proposed new profile set for ROHCv2. New profile numbers will of course be assigned, since these profiles are different and are supposed to coexist side by side with the old profiles defined by RFC 3095. There is not a requirement for backward compatibility with the RFC 3095 profiles, and it would be wrong to have such a requirement, with v2 we want to open up for simpler ROHC implementations One can summarize the goals with the v2 profiles as; simpler to implement, improved clarity and conciseness, existing features updated based on experience, new features added (e.g. robustness to reordering), errors corrected, and previous "mistakes" avoided. The draft is written to meet what is in the improvements draft, it does not go much longer than that. Design currently uses formal notation, while the encoding methods are the same as 3095. The aim is to under the same operating conditions have at least similar efficiency and robustness as with the 3095 profiles. One issue for discussion is timer-based compression, which is not included in the initial draft, although the improvements draft does not suggest this. Ghyslain asked whether this draft can be adopted as WG document. Carsten asked how many people have looked at the draft, and got a few hands as a response. Drafts: draft-ietf-rohc-rfc3095bis-framework-01.txt draft-ietf-rohc-rfc3095bis-improvements-02.txt draft-pelletier-rohc-rohcv2-profiles-00.txt * HC over IPsec Security Associations (Emre Ertekin) The latest draft has number of updates. Draft now takes a framework flavor rather than a work proposal, based on previous discussion on alternative solution approaches. The idea is to use the next header field to multiplex/demultiplex compressed and uncompressed packets in an SA, i.e. to get a protocol number for ROHC/HC. This means one would have a single SA for both compressed/uncompressed traffic and no HC overhead for uncompressed packets. The downside is that it requires the reservation of a protocol number from the IANA, but this should be viable if its definition and potential use is rather general (not specific to the SA case). Documents needed for this work, as reflected in the ROHC milestones: - extensions for reordering - work on RoHCv2 and ECRTP cover this - initialization and negotiation of HC parameters with IKEv2 - allocation of next header value for ROHC packets Currently we have envisioned requesting one single protocol number, but we may need more than one, this depends on if we can unify ROHC and other HC protocols (most specifically eCRTP). The suggested unification approach makes ECRTP/CRTP/IPHC effectively become new ROHC profiles, thus a protocol number is needed only for ROHC. Ghyslain questioned why we need to support anything but ROHC. The answer was (as always) that *some* people want this, based on the regular fuzzy arguments about ROHC complexity. The discussion also ended as always (faded out), but Ghyslain made clear that his point was really to question the unification approach, which he believes is strange. Magnus asked more than one level of demultiplexing is needed, and Carsten responded that older schemes use PPP for packet type identification, so these schemes need something for this purpose, and incorporating them into ROHC through the proposed unification would solve that problem. One could then also replace their CID schemes with the ROHC CID mechanism, which is more flexible. Having a dynamic protocol number ("Compressed header") value is also an alternative, where e.g. IKE negotiation would indicate the actual HC scheme. L-E dislikes this approach since the protocol type would not be self-describing. Carsten also pointed out that IPsec says that next header field must identify the format of the header. There was clearly no conclusion (or consensus) on these issues, the discussions will have to continue on the list. Draft: draft-ietf-rohc-hcoipsec-02.txt * ROHC TCP & Formal Notation (Ghyslain Pelletier) The formal notation is a documentation tool, and we have tried to make it readable. There have therefore been many changes based on the comments we got from the WGLC, and it took some time to make this update happen. We should now send it back to the committed reviewers, and aim for a second WGLC in August or September. The ROHC TCP draft has also been significantly updated with various editorial changes, some minor technical changes, and the descriptive box notation has been removed. It would really be useful if someone could verify the ROHC TCP packet formats, but we know this is hard to do without actually implementing and testing the protocol. This draft should soon be ready for a second WGLC, the work has a five year history and we are getting there. Carsten noted that we had two in-depth reviews from Joe Touch and Ted Faber on previous version. We should get similar detailed reviews on this version, then we are hopefully done. Drafts: draft-ietf-rohc-tcp-12.txt draft-ietf-rohc-formal-notation-10.txt