強力なヘッダー圧縮

Robust Header Compression ( ROHC ) は、インターネットパケットのIP、UDP、UDP-Lite、RTP、およびTCPヘッダーを圧縮するための標準化された方法です。

ストリーミングアプリケーションでは、IP、UDP、RTPのオーバーヘッドは、IPv4の場合は40バイト、IPv6の場合は60バイトです。VoIPの場合、これは送信されるデータの総量の約60％に相当します。このような大きなオーバーヘッドは、容量が問題にならないことが多いローカル有線リンクでは許容できるかもしれませんが、帯域幅が不足している広域ネットワークや無線システムでは大きすぎます。 ^[1]

ROHC は、容量が制限されているリンクの前にコンプレッサを配置し、そのリンクの後にデコンプレッサを配置することで、通常、40 バイトまたは 60 バイトのオーバーヘッドを 1 バイトまたは 3 バイトに圧縮します。コンプレッサは大きなオーバーヘッドをわずか数バイトに変換し、デコンプレッサはその逆を行います。

ROHC 圧縮方式は、ワイヤレス リンクなどのパケット損失率が高いリンクでも優れたパフォーマンスを発揮するという点で 、IETF RFC 1144 やRFC 2508 などの他の圧縮方式とは異なります。

ROHC プロトコルは、次のヘッダーの情報冗長性を活用します。

• 1つのネットワークパケット（例：IPおよびUDPヘッダーのペイロード長）
• 1つのストリームに属する複数のネットワークパケット（例：IPアドレス）

冗長情報は最初のパケットでのみ送信されます。次のパケットには、識別子やシーケンス番号などの可変情報が含まれます。これらのフィールドは、より多くのビットを節約するために圧縮された形式で送信されます。

パフォーマンスを向上させるために、パケットは圧縮される前にストリームに分類されます。この分類では、パケット間の冗長性を活用します。分類アルゴリズムは ROHC プロトコル自体では定義されておらず、機器ベンダーの実装に委ねられています。パケットのストリームが分類されると、最も適した圧縮プロファイルに従って圧縮されます。圧縮プロファイルは、ネットワーク ヘッダー内のさまざまなフィールドを圧縮する方法を定義します。次のような複数の圧縮プロファイルが利用可能です。

• 非圧縮
• IPのみ
• UDP/IP
• UDP-Lite/IP
• ESP/IP
• RTP/UDP/IP
• RTP/UDP-Lite/IP
• プロトコル

RFC 3095 によれば、ROHC スキームには次の 3 つの動作モードがあります。

• 単方向モード（Uモード）
• 双方向楽観モード（Oモード）
• 双方向信頼性モード（Rモード）

コンプレッサとデコンプレッサは両方とも U モードで開始します。使用可能なリターン リンクが利用可能で、デコンプレッサが O モードを指定した肯定応答をコンプレッサに送信する場合、コンプレッサとデコンプレッサは O モードに遷移します。R モードへの移行も同様の方法で行われます。

単方向動作モードでは、パケットはコンプレッサからデコンプレッサへの一方向にのみ送信されます。したがって、このモードでは、デコンプレッサからコンプレッサへの戻りパスが利用できない、または望ましくないリンクでも ROHC を使用できます。潜在的なデコンプレッサ エラーを処理するために、コンプレッサはストリーム コンテキストの定期的な更新をデコンプレッサに送信します。

双方向オプティミスティック モードは、フィードバック チャネルを使用してエラー回復要求と (オプションで) 重要なコンテキスト更新の確認応答を解凍装置から圧縮装置に送信する点を除いて、単方向モードに似ています。O モードは、圧縮効率を最大化し、フィードバック チャネルをあまり使用しないことを目的とします。

双方向信頼性モードは、前の 2 つのモードとは多くの点で異なります。最も重要な違いは、フィードバック チャネルをより集中的に使用することと、非常に高い残留ビット エラー率を除き、コンプレッサーとデコンプレッサー間のコンテキスト同期の損失を防ぐ、コンプレッサーとデコンプレッサーの両方でのより厳格なロジックです。

コンプレッサ/デコンプレッサの状態の概念は、動作モードとは直交しています。モードが何であれ、コンプレッサとデコンプレッサはどちらも 3 つの状態のいずれかで動作します。これらは基本的に有限状態マシンです。受信パケットごとに、コンプレッサ/デコンプレッサの内部状態が変化する可能性があります。各状態は、定義された動作と圧縮レベルを指します。

ROHC アルゴリズムは、ベース フレームとその後のいくつかの差分フレームが送信されて IP パケット フローを表すという点で、ビデオ圧縮に似ています。これには、ベース フレームが失われない限り、ROHC が最高の圧縮状態で多くのパケット損失に耐えられるという利点があります。

コンプレッサーのステート マシンは、次の 3 つの状態を定義します。

• 初期化とリフレッシュ (IR) 状態
• ファーストオーダー（FO）状態
• 二次（SO）状態

初期化および更新 (IR) 状態では、コンプレッサが作成またはリセットされたばかりで、完全なパケット ヘッダーが送信されます。 ファースト オーダー (FO) 状態では、コンプレッサが接続の両側で静的フィールド (IP アドレスやポート番号など) を検出して保存しています。 コンプレッサは、FO 状態で動的パケット フィールドの差異も送信しています。 したがって、FO 状態は基本的に静的および疑似動的圧縮です。 セカンド オーダー (SO) 状態では、コンプレッサは RTP シーケンス番号などのすべての動的フィールドを抑制し、論理シーケンス番号と部分的なチェックサムのみを送信して、相手側が次に予想されるパケットのヘッダーを予測的に生成して検証できるようにします。 一般に、FO 状態では、すべての静的フィールドとほとんどの動的フィールドが圧縮されます。 SO 状態では、シーケンス番号とチェックサムを使用してすべての動的フィールドを予測的に圧縮します。

上記の状態間の遷移は、コンプレッサーが以下の場合に発生します。

• バリエーションが多すぎるパケットを圧縮する
• 減圧装置から正/負のフィードバックを受け取る
• 定期的にコンテキストを更新する

典型的な ROHC 実装は、端末を第 2 次状態にすることを目的とし、1 バイトの ROHC ヘッダーを 40 バイトの IPv4/UDP/RTP または 60 バイトの IPv6/UDP/RTP (つまり VoIP) ヘッダーに置き換えることができます。この状態では、8 ビットの ROHC ヘッダーに次の 3 つのフィールドが含まれます。

• 1 ビットのパケット タイプ フラグ (長い ROHC ヘッダーの場合のみ '1' に設定)
• 4ビットのシーケンス番号（ベースフレームから -1 ... +14 パケットの範囲）
• 3ビットCRC

デコンプレッサーのステート マシンは、次の 3 つの状態を定義します。

• コンテキスト状態なし
• 静的コンテキスト状態
• 完全なコンテキスト状態

上記の状態間の遷移は、デコンプレッサーが次の操作を実行したときに発生します。

• パケットを正常に解凍する
• いくつかのパケットの解凍に失敗する

シーケンス番号 (SN) フィールドのサイズは、ROHC が損失できるパケットの数を制御します。この数を超えると、圧縮機をリセットして続行する必要があります。W-LSB アルゴリズムは、SN を堅牢な方法で圧縮するために使用されます。1 バイトおよび 2 バイトの ROHC パケットのシーケンス番号のサイズは、それぞれ 4 ビット (-1/+14 フレーム オフセット) または 6 ビット (-1/+62 フレーム オフセット) であるため、ROHC は 1 バイトまたは 2 バイトのヘッダーを持つ最大 62 個のフレーム損失を許容できます。

RFC 3095 は、一般的な圧縮メカニズムを定義します。特定のプロトコル ヘッダー専用の新しい圧縮プロファイルを定義することで、このメカニズムを拡張できます。新しいプロトコルを圧縮するための新しい RFC が公開されました。

• RFC 3843 は、IP ヘッダーまたは IP トンネルの圧縮プロファイルを定義します。
• RFC 4019 は、UDP-Lite/IP および RTP/UDP-Lite/IP ヘッダーの圧縮プロファイルを定義します。
• RFC 6846 は、TCP/IP ヘッダーの圧縮プロファイルを定義します。

ROHC を解釈して実装しようとする際に一部の人が遭遇した混乱に対処するために、 RFC 4995 とRFC 5225という 2 つの新しい RFC が公開されました。最初のドキュメントでは ROHC フレームワークを定義し、2 番目のドキュメントでは確立された ROHC プロファイルの新しいバージョンを定義します。

• 6LoWPAN
• 静的コンテキスト ヘッダー圧縮(SCHC)

• ROHC IETFワーキンググループの公式憲章
• RFC 3095 - 「ROHC フレームワークと 4 つのプロファイル: RTP、UDP、ESP、非圧縮」
• RFC 3759 - 「ROHC 用語とチャネル マッピングの例」
• RFC 4815 - 「 RFC 3095の修正と説明」
• RFC 4995 - 「RObust ヘッダー圧縮 (ROHC) フレームワーク」(RFC 5795 により廃止)
• RFC 4996 - 「RObust ヘッダー圧縮 (ROHC): TCP/IP のプロファイル (ROHC-TCP)」(RFC 6846 により廃止)
• RFC 4997 - 「ROHC の正式な表記法」
• RFC 5225 - 「RObust ヘッダー圧縮バージョン 2 (ROHCv2): RTP、UDP、IP、ESP、UDP-Lite のプロファイル」。RFC 3095、RFC 3843、RFC 4019 にあるプロファイルの 2 番目のバージョンです。これらの定義に取って代わりますが、廃止されるわけではありません。
• RFC 5795 - 「RObust ヘッダー圧縮 (ROHC) フレームワーク」(RFC 4995 は廃止)
• RFC 6846 - 「RObust ヘッダー圧縮 (ROHC): TCP/IP のプロファイル (ROHC-TCP)」(RFC 4996 は廃止)
• sourceforge.net 上の ROHC の無料実装
• ROHC標準を実装した無料かつ効率的なライブラリ