NOTE: This charter is a snapshot of the 51st IETF Meeting in London, England. It may now be out-of-date. Last Modified: 31-Jul-01
Carsten Bormann <cabo@tzi.org>
Mikael Degermark <micke@sm.luth.se>
Scott Bradner <sob@harvard.edu>
Allison Mankin <mankin@isi.edu>
Allison Mankin <mankin@isi.edu>
General Discussion:rohc@cdt.luth.se
To Subscribe: majordomo@cdt.luth.se
In Body: subscribe
Archive: http://www.cdt.luth.se/rohc/
Note: Erik Nordmark (nordmark@eng.sun.com) is serving as the Technical Advior to the group.
Due to limited bandwidth, IP/UDP/RTP/TCP packets sent over cellular links benefit considerably from header compression. Existing header compression schemes (RFC 1144, RFC 2508) do not perform well over cellular links due to high error rates and long link roundtrip times, particularly as topologies and traffic patterns become more complex. In addition, existing schemes do not compress TCP options such as SACK or Timestamps.
The goal of ROHC is to develop header compression schemes that perform well over links with high error rates and long roundtrip times. The schemes must perform well for cellular links built using technologies such as WCDMA, EDGE, and CDMA-2000. However, the schemes should also be applicable to other future link technologies with high loss and long roundtrip times. Ideally, it should be possible to compress over unidirectional links.
Good performance includes both minimal loss propagation and minimal added delay. In addition to generic TCP and UDP/RTP compression, applications of particular interest are voice and low-bandwidth video.
ROHC may develop multiple compression schemes, for example, some that are particularly suited to specific link layer technologies. Schemes in addition to those listed in the milestones below may be added in consultation with the area directors.
A robust header compression scheme must:
* assure that when a header is compressed and then decompressed, the result is semantically identical to the original;
* perform well when the end-to-end path involves more than one cellular link;
* support IPv4 and IPv6.
Creating more thorough requirements documents will be the first task of the WG.
The working group shall maintain connections with other standardization organizations developing cellular technology for IP, such as 3GPP and 3GPP-2, to ensure that its output fulfills their requirements and will be put to good use.
In addition, the WG should develop a solid understanding of the impact that specific error patterns have on the compression schemes, and document guidelines to Layer 2 designers regarding what Layer 2 features work best to assist Layer 3 and Layer 4 header compression.
Finally, working group documents will address interactions with IPSEC and other security implications.
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. |
May 00 |
|
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. |
Jul 00 |
|
Requirements for IP/TCP header compression submitted to IESG for publication as Informational. |
Done |
|
Resolve possibly multiple IP/UDP/RTP compression schemes into a single scheme. |
Aug 00 |
|
Submit I-D on IP/TCP header compression scheme. |
Sep 00 |
|
Layer-2 design guidelines submitted to IESG for publication as Informational. |
Done |
|
IP/UDP/RTP header compression scheme submitted to IESG for publication as Proposed Standard. |
Dec 00 |
|
IP/TCP compression scheme submitted to IESG for publication |
Jan 01 |
|
Possible recharter of WG to develop additional compression schemes. |
· Lower Layer Guidelines for Robust RTP/UDP/IP Header Compression
· TCP-Aware RObust Header Compression (TAROC)
· Requirements for ROHC IP/TCP Header Compression
· Requirements and assumptions for ROHC 0-byte IP/UDP/RTP compression
RFC |
Status |
Title |
RFC3095 |
PS |
RObust Header Compression (ROHC) |
RFC3096 |
Requirements for robust IP/UDP/RTP header compression |
None received.
None received.