The IESG has approved the following document: - 'RObust Header Compression (ROHC): A Profile for TCP/IP (ROHC-TCP) ' <draft-ietf-rohc-tcp-16.txt> as a Proposed Standard This document is the product of the Robust Header Compression Working Group. The IESG contact persons are Magnus Westerlund and Lars Eggert. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-rohc-tcp-16.txt Technical Summary This document specifies a ROHC (RObust Header Compression) profile for compression of TCP/IP packets. The profile, called ROHC-TCP, provides efficient and robust compression of TCP headers, including frequently used TCP options such as SACK (Selective Acknowledgments) and Timestamps. ROHC-TCP works well when used over links with significant error rates and long round-trip times. For many bandwidth-limited links where header compression is essential, such characteristics are common. Working Group Summary This document has been in the workings for several years. It first appeared as an official WG draft in January 2002, and has since then changed shape a couple of times. It has now been rather stable for a long time, it has been carefully reviewed by both the WG and externals, and there is WG consensus that the document should now be published as an RFC. Protocol Quality The document has been both manually reviewed by several parties with different perspectives, and checked by automated tools. During WGLC, the document was reviewed by the committed WG reviewers Joe Touch and Ted Faber, as well as by Sally Floyd, who provided a review at the request of the Transport Area Directorate. Personnel Document Sheperd for this document is Lars-Erik Jonsson, and Magnus Westerlund is the Responsible Area Director. Note to RFC Editor Please update reference [RFC2001] to use RFC 2581 instead. Section 6.1.3: OLD: 6.1.3. Explicit Congestion Notification (ECN) When ECN [RFC3168] is used once on a flow, the ECN bits could change quite often. ROHC-TCP maintains a control field in the context to indicate if ECN is used or not. This control field is transmitted in the dynamic chain of the TCP header, and its value can be updated using specific compressed headers carrying a 7-bit CRC. When this control field indicates that ECN is being used, items of IP and TCP headers in the irregular chain include bits used for ECN. To preserve octet-alignment, all of the TCP reserved bits are transmitted and, for outer IP headers, the entire TOS/TC field is included in the irregular chain. The design rationale behind this is the possible use of the "full- functionality option" of section 9.1 of [RFC3168]. ******************************* NEW: 6.1.3. Explicit Congestion Notification (ECN) When ECN [RFC3168] is used once on a flow, the ECN bits could change quite often. ROHC-TCP maintains a control field in the context to indicate if ECN is used or not. This control field is transmitted in the dynamic chain of the TCP header, and its value can be updated using specific compressed headers carrying a 7-bit CRC. When this control field indicates that ECN is being used, items of all IP and TCP headers in the irregular chain include bits used for ECN. To preserve octet-alignment, all of the TCP reserved bits are transmitted and, for outer IP headers, the entire TOS/TC field is included in the irregular chain. When there is only one IP header present in the packet (i.e. no IP tunneling is used), this compression behavior allows the compressor to handle changes in the ECN bits by adding a single octet to the compressed header. The reason for including the ECN bits of all IP headers in the compressed packet when the control field is set is that the profile needs to efficiently compress flows containing IP tunnels using the "full- functionality option" of section 9.1 of [RFC3168]. For these flows, a change in the ECN bits of an inner IP header is propagated to the outer IP headers. When the "limited-functionality" option is used, the compressor will therefore sometimes send one octet more than necessary per tunnel header, but this has been considered a reasonable tradeoff when designing this profile. _______________________________________________ IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
