Protocol Action: 'RObust Header Compression (ROHC): A Profile for TCP/IP (ROHC-TCP)' to Proposed Standard

[The IESG <[e-mail]>]

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 mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/ietf-announce