ROHC

ROHC

Robust Header Compression (ROHC) is a standardized method to compress the IP, UDP, RTP, and TCP headers of Internet packets. This compression scheme differs from other compression schemes such as IETF RFC 1144 and RFC 2508 by the fact that it performs well over links where the packet loss rate is high, such as wireless links.

In streaming applications, the overhead of IP, UDP, and RTP is 40 bytes for IPv4, or 60 bytes for IPv6. For VoIP this corresponds to around 60% of the total amount of data sent.Such large overheads may be tolerable in wired links where capacity is often not an issue, but are excessive for wireless systems where bandwidth is scarce.

ROHC compresses these 40 bytes or 60 bytes of overhead typically into only 1 or 3 bytes by placing a compressor before the link that has limited capacity, and a decompressor after that link. The compressor converts the large overhead to only a few bytes, while the decompressor does the opposite.

According to RFC 3095 the ROHC scheme has three modes of operation: the Unidirectional, the Bidirectional Optimistic, and the Bidirectional Reliable mode.

Unidirectional Mode (U-Mode)

In the Unidirectional mode of operation, packets are only sent in one direction: from compressor to decompressor. This mode therefore makes ROHC usable over links where a return path from decompressor to compressor is unavailable or undesirable.

Bidirectional Optimistic Mode (O-Mode)

The Bidirectional Optimistic mode is similar to the Unidirectional mode, except that a feedback channel is used to send error recovery requests and (optionally) acknowledgments of significant context updates from the decompressor to compressor. The O-mode aims to maximize compression efficiency and sparse usage of the feedback channel.

Bidirectional Reliable Mode (R-Mode)

The Bidirectional Reliable mode differs in many ways from the previous two. The most important differences are a more intensive usage of the feedback channel and a stricter logic at both the compressor and the decompressor that prevents loss of context synchronization between compressor and decompressor except for very high residual bit error rates.

Initialization & Refresh, First-Order, Second-Order States

The ROHC algorithm is similar to video compression, in that a base frame and then several difference frames are sent to represent an IP packet flow. This has the advantage of allowing ROHC to survive many packet losses in its highest compression state, as long as the base frames are not lost.

A ROHC compressor is in one of 3 main states. In Initialization and Refresh (IR) state, the compressor has just been created or reset, and full packet headers are sent. In First-Order (FO) state, the compressor has detected and stored the static fields (such as IP addresses and port numbers) on both sides of the connection. The compressor is also sending dynamic packet field differences in FO state. Thus, FO state is essentially static and pseudo-dynamic compression. In Second-Order (SO) state, the compressor is suppressing all dynamic fields such as RTP sequence numbers, and sending only a logical sequence number and partial checksum to cause the other side to predictively generate and verify the headers of the next expected packet. In general, FO state compresses all static fields and most dynamic fields. SO state is compressing all dynamic fields predictively using a sequence number and checksum.

The size of the sequence number field governs the number of packets that ROHC can lose before the compressor must be reset to continue. The size of the sequence number in 1 and 2 byte ROHC packets is either 4 bits ( -1/+14 frame offset ), or 6 bits ( -1/+62 frame offset ), respectively, so ROHC can tolerate at most 62 lost frames with a 1-2 byte header.

External links

* [http://www.ietf.org/html.charters/rohc-charter.html Official charter of the ROHC IETF working group]
* RFC 3095 - "ROHC Framework and four profiles: RTP, UDP, ESP, and uncompressed"
* RFC 4815 - Corrections and Clarifications to RFC 3095


Wikimedia Foundation. 2010.

Игры ⚽ Нужна курсовая?

Look at other dictionaries:

  • ROHC — Robust Header Compression (ROHC) est une méthode normalisée dans la RFC 3095 pour compresser les entêtes IP, UDP, RTP et TCP des paquets réseau. Ce système de compression diffère des autres systèmes de compression comme ceux décrits dans les RFC… …   Wikipédia en Français

  • ROHC — im TCP/IP‑Protokollstapel: Anwendung HTTP SIP RTP …   ROHC Transport TCP UDP Int …   Deutsch Wikipedia

  • ROHC — abbr. RObust Header Compression (RFC 3095, RTP, UDP, ESP) …   United dictionary of abbreviations and acronyms

  • RObust Header Compression — ROHC Robust Header Compression (ROHC) est une méthode normalisée dans la RFC 3095 pour compresser les entêtes IP, UDP, RTP et TCP des paquets réseau. Ce système de compression diffère des autres systèmes de compression comme ceux décrits dans les …   Wikipédia en Français

  • Robust Header Compression — (ROHC) est une méthode normalisée dans la RFC 3095 pour compresser les entêtes IP, UDP, RTP et TCP des paquets réseau. Ce système de compression diffère des autres systèmes de compression comme ceux décrits dans les RFC 1144 et RFC 2508 de l IETF …   Wikipédia en Français

  • Compressed SLIP — CSLIP im TCP/IP‑Protokollstapel: Anwendung HTTP SIP RTP …   CSLIP Transport TCP …   Deutsch Wikipedia

  • Real-time Transport Protocol — The Real time Transport Protocol (or RTP) defines a standardized packet format for delivering audio and video over the Internet. It was developed by the Audio Video Transport Working Group of the IETF and first published in 1996 as RFC 1889 which …   Wikipedia

  • CSLIP — im TCP/IP‑Protokollstapel: Anwendung HTTP SIP RTP …   CSLIP Transport TCP UDP I …   Deutsch Wikipedia

  • Signaling Compression — Signaling compression, or SigComp, is a compression method designed especially for compression of text based communication data as SIP or RTSP. SigComp had originally been defined in RFC 3320 and was later updated with RFC 4896. A Negative… …   Wikipedia

  • Protokoll (IP) — Das Feld Protokoll (protocol) im IPv4 Header gibt an, zu welchem Protokoll (auch „Folgeprotokoll“ genannt) die im betreffenden IPv4 Paket transportierten Nutzdaten gehören. Das Feld ist 8 Bit breit und kann daher Werte von 0 bis 255 (dezimal)… …   Deutsch Wikipedia

Share the article and excerpts

Direct link
Do a right-click on the link above
and select “Copy Link”