メインコンテンツまでスキップ

10. Header Compression (ヘッダー圧縮)

ヘッダー圧縮に関しては、公開されている標準化作業と進行中の標準化作業が多数あります。しかし、IPv6 over IEEE 802.15.4のヘッダー圧縮には異なる制約があり、以下のように要約されます:

  • 既存の作業は、任意の2つのデバイス間に多数のフロー (Flows) が存在することを想定しています。ここでは、非常にシンプルで低コンテキスト (Low-Context) のヘッダー圧縮スタイルを想定します。これはフローとは独立して機能しますが（複数ある可能性があります）、特定のフローに固有のコンテキストは使用しません。したがって、圧縮する各フローに対して個別のコンテキストを構築するスキームが達成できるほどの圧縮を実現することはできません。

  • 非常に限られたパケットサイズを考えると、レイヤー2とレイヤー3の圧縮を統合することが非常に望ましいですが、これは従来行われていませんでした（ただし、現在はROHC (RObust Header Compression, ロバストヘッダー圧縮) ワーキンググループによって変化しています）。

  • IEEE 802.15.4デバイスはマルチホップネットワーク (Multi-Hop Networks) に展開されることが予想されます。ただし、メッシュネットワークにおけるヘッダー圧縮は、圧縮器と解凍器が互いに直接かつ排他的に通信する通常のポイントツーポイントリンクシナリオとは異なります。IEEE 802.15.4ネットワークでは、デバイスが最小限の事前コンテキスト構築で、任意の隣接ノードを介してヘッダー圧縮されたパケットを送信できることが非常に望ましいです。

ヘッダー圧縮に必要な新しいパケット形式は、第5節で定義された基本パケット形式を異なるディスパッチ値 (Dispatch Values) を使用して再利用します。

ヘッダー圧縮は、オクテット境界に整列しない可能性があります。ハードウェアは通常、オクテット未満の単位でデータを送信できないため、パディング (Padding) を使用する必要があります。パディングは次のように行われます: まず、連続する圧縮ヘッダーシーケンス全体をレイアウトします（本文書ではIPv6およびUDPヘッダー圧縮スキームのみを定義していますが、他のスキームは他の場所で定義できます）。次に、必要に応じてゼロビットを追加してオクテット境界に整列させます。これにより、ヘッダー圧縮によって生じる潜在的な不整合が相殺されるため、後続のフィールド（たとえば、非圧縮ヘッダーまたはデータペイロード）はオクテット境界から始まり、通常どおり続きます。

10.1. Encoding of IPv6 Header Fields (IPv6ヘッダーフィールドのエンコーディング)​

同じ6LoWPANネットワークに参加することにより、デバイスは何らかの状態を共有します。これにより、圧縮コンテキスト状態を明示的に構築することなくヘッダーを圧縮できます。したがって、6LoWPANヘッダー圧縮はフロー状態を保持しません。代わりに、リンク全体に関連する情報に依存します。以下のIPv6ヘッダー値は6LoWPANネットワーク上で一般的であると予想されるため、HC1ヘッダーは最初から効率的に圧縮するように構築されています:

  • Version (バージョン) はIPv6
  • IPv6送信元アドレスと宛先アドレスは両方ともリンクローカル (Link Local)
  • 送信元または宛先アドレスのIPv6インターフェース識別子（下位64ビット）は、レイヤー2の送信元アドレスと宛先アドレスから推測できます（もちろん、これは基礎となる802.15.4 MACアドレスから派生したインターフェース識別子にのみ可能です）
  • パケット長は、レイヤー2（IEEE 802.15.4 PPDUの「Frame Length」）またはフラグメンテーションヘッダーの「datagram_size」フィールド（存在する場合）から推測できます
  • Traffic ClassとFlow Labelは両方ともゼロ
  • Next HeaderはUDP、ICMP、またはTCP

IPv6ヘッダーで常に完全に伝送する必要がある唯一のフィールドは、Hop Limit（ホップ制限、8ビット）です。パケットがこの一般的なケースとどの程度一致するかに応じて、さまざまなフィールドが圧縮できない場合があり、したがって「インライン」(In-Line) で伝送する必要があります（第10.3.1節）。この一般的なIPv6ヘッダー（上記のとおり）は、40オクテットではなく2オクテット（HC1エンコーディングに1オクテット、Hop Limitに1オクテット）に圧縮できます。

このようなパケットは、LOWPAN_HC1形式で圧縮できます。LOWPAN_HC1のディスパッチ値を使用し、その後にLOWPAN_HC1ヘッダー「HC1エンコーディング」フィールド（8ビット）が続き、以下に示すようなさまざまな組み合わせをエンコードします。

                   1                   2                   3
   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  | HC1 encoding  |     Non-Compressed fields follow...
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

「HC1エンコーディング」によってエンコードされるアドレスフィールドは次のように解釈されます:

  • PI: Prefix carried in-line (プレフィックスをインラインで伝送)
  • PC: Prefix compressed (プレフィックス圧縮、リンクローカルプレフィックスを想定)
  • II: Interface identifier carried in-line (インターフェース識別子をインラインで伝送)
  • IC: Interface identifier elided (インターフェース識別子省略、対応するリンク層アドレスから派生可能)

HC1エンコーディング（ビット0からビット7）:

IPv6送信元アドレス（ビット0および1）:

  • 00: PI, II
  • 01: PI, IC
  • 10: PC, II
  • 11: PC, IC

IPv6宛先アドレス（ビット2および3）:

  • 00: PI, II
  • 01: PI, IC
  • 10: PC, II
  • 11: PC, IC

Traffic ClassとFlow Label（ビット4）:

  • 0: 非圧縮; 完全な8ビットTraffic Classと20ビットFlow Labelを送信
  • 1: Traffic ClassとFlow Labelはゼロ

Next Header（ビット5および6）:

  • 00: 非圧縮; 完全な8ビットを送信
  • 01: UDP
  • 10: ICMP
  • 11: TCP

HC2エンコーディング（ビット7）:

  • 0: これ以上のヘッダー圧縮ビットはありません
  • 1: HC1エンコーディングの直後に、HC2エンコーディング形式に従ってさらにヘッダー圧縮ビットが続きます。ビット5および6が、どのHC2エンコーディング（たとえば、UDP、ICMP、またはTCPエンコーディング）が適用されるかを決定します。

10.2. Encoding of UDP Header Fields (UDPヘッダーフィールドのエンコーディング)​

LOWPAN_HC1のビット5および6により、IPv6ヘッダーのNext Headerフィールド（UDP、TCP、およびICMP用）を圧縮できます。これらのプロトコルヘッダーのそれぞれをさらに圧縮することも可能です。本節では、UDPヘッダー自体を圧縮する方法について説明します。本節のHC2エンコーディングはHC_UDPエンコーディングであり、HC1のビット5および6がIPv6ヘッダーの後に続くプロトコルがUDPであることを示す場合にのみ適用されます。

HC_UDPエンコーディングにより、UDPヘッダーの次のフィールドを圧縮できます: 送信元ポート (Source Port)、宛先ポート (Destination Port)、および長さ (Length)。UDPヘッダーのチェックサム (Checksum) フィールドは圧縮されないため、完全に伝送されます。以下に定義するスキームにより、UDPヘッダーを元の8オクテットではなく4オクテットに圧縮できます。

他の場所で利用可能な情報からその値を推測できる唯一のUDPヘッダーフィールドはLengthです。他のフィールドは、完全または部分圧縮形式でインラインで伝送する必要があります（第10.3.2節）。

                   1                   2                   3
   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |HC_UDP encoding|     Fields carried in-line follow...
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

UDPの「HC_UDPエンコーディング」（ビット0からビット7）:

UDP送信元ポート（ビット0）:

  • 0: 非圧縮、インラインで伝送
  • 1: 4ビットに圧縮。実際の16ビット送信元ポートは次の計算によって取得されます: P + short_port値。Pの値は数値61616（0xF0B0）です。short_portは4ビット値として表され、インラインで伝送されます

UDP宛先ポート（ビット1）:

  • 0: 非圧縮、インラインで伝送
  • 1: 4ビットに圧縮。実際の16ビット宛先ポートは次の計算によって取得されます: P + short_port値。Pの値は数値61616（0xF0B0）です。short_portは4ビット値として表され、インラインで伝送されます

Length（ビット2）:

  • 0: 非圧縮、インラインで伝送
  • 1: 圧縮、長さはIPv6ヘッダー長情報から計算されます。UDP長さフィールドの値は、IPv6ヘッダーのPayload Lengthから、IPv6ヘッダーとUDPヘッダーの間に存在する拡張ヘッダーの長さを引いた値に等しくなります

予約済み（ビット3からビット7）

10.3. Non-Compressed Fields (非圧縮フィールド)​

10.3.1. Non-Compressed IPv6 Fields (非圧縮IPv6フィールド)​

このスキームにより、IPv6ヘッダーをさまざまな程度に圧縮できます。したがって、完全な（標準的な）IPv6ヘッダーの代わりに、非圧縮フィールドのみを送信する必要があります。後続のヘッダー（元のIPv6ヘッダーのNext Headerフィールドによって指定）は、IPv6非圧縮フィールドの直後に続きます。

常に存在しなければならない (MUST) 非圧縮IPv6フィールドは、Hop Limit（8ビット）です。このフィールドは、常にエンコーディングフィールド（たとえば、図9に示されている「HC1エンコーディング」、将来の他のエンコーディングフィールドを含む可能性があります）の直後に続かなければなりません (MUST)。他の非圧縮フィールドは、「HC1エンコーディング」によって暗示される正確な順序でHop Limitの後に続かなければなりません (MUST)（第10.1節で示されているとおり）: 送信元アドレスプレフィックス（64ビット）および/またはインターフェース識別子（64ビット）、宛先アドレスプレフィックス（64ビット）および/またはインターフェース識別子（64ビット）、Traffic Class（8ビット）、Flow Label（20ビット）、およびNext Header（8ビット）。実際の次のヘッダー（たとえば、UDP、TCP、ICMPなど）は、非圧縮フィールドの後に続きます。

10.3.2. Non-Compressed and Partially Compressed UDP Fields (非圧縮および部分圧縮UDPフィールド)​

このスキームにより、UDPヘッダーをさまざまな程度に圧縮できます。したがって、完全な（標準的な）UDPヘッダーの代わりに、非圧縮または部分圧縮フィールドのみを送信する必要があります。

UDPヘッダーの非圧縮または部分圧縮フィールドは、常にIPv6ヘッダーとその関連するインラインフィールドの直後に続かなければなりません (MUST)。存在するUDPヘッダーインラインフィールドは、通常のUDPヘッダー [[RFC0768]] で対応するフィールドが出現するのと同じ順序で出現しなければなりません (MUST)。たとえば、送信元ポート、宛先ポート、長さ、チェックサムです。送信元ポートまたは宛先ポートが「short_port」表記（圧縮されたUDPヘッダーで示されているとおり）を採用している場合、インラインポート番号は16ビットではなく4ビットを占めます。

に最終更新