5. LoWPAN Adaptation Layer and Frame Format (LoWPAN適応層とフレーム形式)

本節で定義されるカプセル化形式（以下「LoWPANカプセル化」と呼びます）は、IEEE 802.15.4 MACプロトコルデータユニット (Protocol Data Unit, PDU) 内のペイロードです。LoWPANペイロード（たとえば、IPv6パケット）は、このカプセル化ヘッダーの直後に続きます。

IEEE 802.15.4を介して伝送されるすべてのLoWPANカプセル化データグラム (Datagrams) には、カプセル化ヘッダースタック (Encapsulation Header Stack) がプレフィックスとして付けられます。ヘッダースタック内の各ヘッダーには、ヘッダータイプ (Header Type) が含まれ、その後にゼロ個以上のヘッダーフィールドが続きます。IPv6ヘッダーでは、スタックには次の順序で、アドレッシング (Addressing)、ホップバイホップオプション (Hop-by-Hop Options)、ルーティング (Routing)、フラグメンテーション (Fragmentation)、宛先オプション (Destination Options)、最後にペイロードが含まれます [[RFC2460]]。LoWPANヘッダーでは、同様のヘッダーシーケンスは、メッシュ (L2) アドレッシング、ホップバイホップオプション（L2ブロードキャスト/マルチキャストを含む）、フラグメンテーション、最後にペイロードです。

典型的なヘッダースタックの例:

LoWPANカプセル化されたIPv6データグラム:

+---------------+-------------+---------+
| IPv6 Dispatch | IPv6 Header | Payload |
+---------------+-------------+---------+

LoWPANカプセル化されたLOWPAN_HC1圧縮IPv6データグラム:

+--------------+------------+---------+
| HC1 Dispatch | HC1 Header | Payload |
+--------------+------------+---------+

メッシュアドレッシングが必要な場合:

+-----------+-------------+--------------+------------+---------+
| Mesh Type | Mesh Header | HC1 Dispatch | HC1 Header | Payload |
+-----------+-------------+--------------+------------+---------+

フラグメンテーションが必要な場合:

+-----------+-------------+--------------+------------+---------+
| Frag Type | Frag Header | HC1 Dispatch | HC1 Header | Payload |
+-----------+-------------+--------------+------------+---------+

メッシュアドレッシングとフラグメンテーションの両方が必要な場合:

+-------+-------+-------+-------+---------+---------+---------+
| M Typ | M Hdr | F Typ | F Hdr | HC1 Dsp | HC1 Hdr | Payload |
+-------+-------+-------+-------+---------+---------+---------+

同じパケットで複数のLoWPANヘッダーが使用される場合、それらは次の順序で出現しなければなりません (MUST): メッシュアドレッシングヘッダー、ブロードキャストヘッダー、フラグメンテーションヘッダー。

5.1. Dispatch Type and Header (ディスパッチタイプとヘッダー)

ディスパッチタイプは、最初の2ビットが "01" で定義されます。ディスパッチタイプとヘッダーは次のとおりです:

 0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
|0 1| Dispatch  |  type-specific header
+-+-+-+-+-+-+-+-+

• Dispatch: 6ビットセレクター。ディスパッチヘッダーの直後に続くヘッダータイプを識別します。
• type-specific header: ディスパッチヘッダーによって決定されるヘッダー。

ディスパッチ値のビットパターン:

Pattern	Header Type
00 xxxxxx	NALP - LoWPANフレームではない
01 000001	IPv6 - 未圧縮のIPv6アドレス
01 000010	LOWPAN_HC1 - LOWPAN_HC1圧縮IPv6
01 000011	reserved - 将来の使用のために予約
...	reserved - 将来の使用のために予約
01 001111	reserved - 将来の使用のために予約
01 010000	LOWPAN_BC0 - LOWPAN_BC0ブロードキャスト
01 010001	reserved - 将来の使用のために予約
...	reserved - 将来の使用のために予約
01 111110	reserved - 将来の使用のために予約
01 111111	ESC - 追加のディスパッチバイトが続く
10 xxxxxx	MESH - メッシュヘッダー
11 000xxx	FRAG1 - フラグメンテーションヘッダー（最初）
11 001000	reserved - 将来の使用のために予約
...	reserved - 将来の使用のために予約
11 011111	reserved - 将来の使用のために予約
11 100xxx	FRAGN - フラグメンテーションヘッダー（後続）
11 101000	reserved - 将来の使用のために予約
...	reserved - 将来の使用のために予約
11 111111	reserved - 将来の使用のために予約

• NALP: 後続のビットがLoWPANカプセル化の一部ではないことを指定します。ディスパッチ値 00xxxxxx に遭遇したLoWPANノードは、そのパケットを破棄しなければなりません (SHALL)。
• IPv6: 後続のヘッダーが未圧縮のIPv6ヘッダー [[RFC2460]] であることを指定します。
• LOWPAN_HC1: 後続のヘッダーがLOWPAN_HC1圧縮IPv6ヘッダーであることを指定します。
• LOWPAN_BC0: 後続のヘッダーがメッシュブロードキャスト/マルチキャストサポート用のLOWPAN_BC0ヘッダーであることを指定します。
• ESC: 後続のヘッダーがディスパッチ値用の単一8ビットフィールドであることを指定します。127より大きいディスパッチ値をサポートできます。

5.2. Mesh Addressing Type and Header (メッシュアドレッシングタイプとヘッダー)

メッシュタイプは、最初のビットが1、2番目のビットが0で定義されます。メッシュタイプとヘッダーは次のとおりです:

 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1 0|V|F|HopsLft| originator address, final address
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

フィールド定義:

• V: この1ビットフィールドは、発信者 (Originator)（または「Very first」）アドレスがIEEE拡張64ビットアドレス (EUI-64) の場合は0、短い16ビットアドレスの場合は1でなければなりません (SHALL)。
• F: この1ビットフィールドは、最終宛先アドレス (Final Destination Address) がIEEE拡張64ビットアドレス (EUI-64) の場合は0、短い16ビットアドレスの場合は1でなければなりません (SHALL)。
• Hops Left (残りホップ数): この4ビットフィールドは、各転送ノードがこのパケットを次のホップに送信する前にデクリメントされなければなりません (SHALL)。残りホップ数が0にデクリメントされた場合、パケットはもう転送されません。値0xFは予約されており、直後に8ビット深度の残りホップ数フィールド (Deep Hops Left) があることを示し、送信元ノードが14ホップを超えるホップ制限を指定できるようにします。
• Originator Address (発信者アドレス): これは発信者のリンク層アドレスです。
• Final Destination Address (最終宛先アドレス): これは最終宛先のリンク層アドレスです。

注意: 'V' および 'F' ビットは、16ビットアドレスと64ビットアドレスの混合使用を許可します。これは少なくともメッシュ層「ブロードキャスト」を許可するのに有用です。802.15.4ブロードキャストアドレスは16ビット短アドレスとして定義されているためです。

メッシュネットワークでのフレーム配信に関するさらなる議論は、第11節にあります。

5.3. Fragmentation Type and Header (フラグメンテーションタイプとヘッダー)

ペイロード全体（たとえば、IPv6）データグラムが単一の802.15.4フレームに収まる場合、フラグメント化されず、LoWPANカプセル化にはフラグメンテーションヘッダーを含めるべきではありません (SHOULD NOT)。データグラムが単一のIEEE 802.15.4フレームに収まらない場合、リンクフラグメント (Link Fragments) に分解されなければなりません (SHALL)。フラグメントオフセットは8オクテットの倍数のみを表すことができるため、データグラムのすべてのリンクフラグメント（最後のものを除く）は、8オクテット長の倍数でなければなりません (MUST)。最初のリンクフラグメントには、以下に定義する最初のフラグメンテーションヘッダーが含まれなければなりません (SHALL)。

最初のフラグメント:

 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1 1 0 0 0|    datagram_size    |         datagram_tag          |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

2番目以降のリンクフラグメント（最後を含む）には、次の形式に準拠したフラグメンテーションヘッダーが含まれなければなりません (SHALL)。

後続のフラグメント:

 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1 1 1 0 0|    datagram_size    |         datagram_tag          |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|datagram_offset|
+-+-+-+-+-+-+-+-+

フィールド定義:

• datagram_size (データグラムサイズ): この11ビットフィールドは、リンク層フラグメンテーション前（ただしIP層フラグメンテーション後）のIPパケット全体のサイズをエンコードします。datagram_size の値は、IPパケットのすべてのリンク層フラグメントで同じでなければなりません (SHALL)。IPv6の場合、これはパケットのIPv6ヘッダー [[RFC2460]] のペイロード長 (Payload Length) 値より40オクテット多くなければなりません (SHALL)（未圧縮IPv6ヘッダーのサイズ）。

• datagram_tag (データグラムタグ): datagram_tag の値は、ペイロード（たとえば、IPv6）データグラムのすべてのリンクフラグメントで同じでなければなりません (SHALL)。送信者は、連続するフラグメント化されたデータグラムに対して datagram_tag をインクリメントしなければなりません (SHALL)。datagram_tag のインクリメント値は、65535から0に折り返さなければなりません (SHALL)。このフィールドは16ビット長で、その初期値は未定義です。

• datagram_offset (データグラムオフセット): このフィールドは2番目以降のリンクフラグメントにのみ存在し、ペイロードデータグラムの先頭に対するフラグメントのオフセットを8オクテット単位で指定しなければなりません (SHALL)。データグラムの最初のオクテット（たとえば、IPv6ヘッダーの開始）のオフセットは0です。最初のリンクフラグメントの datagram_offset の暗黙値は0です。このフィールドは8ビット長です。

リンクフラグメントの受信者は、(1) 送信者の802.15.4送信元アドレス（メッシュアドレッシングフィールドが存在する場合は発信者アドレス）、(2) 宛先の802.15.4アドレス（メッシュアドレッシングフィールドが存在する場合は最終宛先アドレス）、(3) datagram_size、および (4) datagram_tag を使用して、特定のデータグラムに属するすべてのリンクフラグメントを識別しなければなりません (SHALL)。

リンクフラグメントを受信すると、受信者は datagram_size のサイズの元の未フラグメント化パケットの構築を開始します。datagram_offset フィールドを使用して、元の未フラグメント化パケット内の個々のフラグメントの位置を決定します。たとえば、データペイロード（カプセル化ヘッダーを除く）をデータグラム再構成バッファの datagram_offset で指定された位置に配置できます。再構成バッファのサイズは datagram_size によって決定されなければなりません (SHALL)。

IEEE 802.15.4解除関連イベントが検出されると、フラグメント受信者は、部分的に再構成されたすべてのペイロードデータグラムのすべてのリンクフラグメントを破棄しなければならず (MUST)、フラグメント送信者は、まだ送信されていない部分的に送信されたペイロード（たとえば、IPv6）データグラムのすべてのリンクフラグメントを破棄しなければなりません (MUST)。同様に、ノードが特定の datagram_tag を持つフラグメントを最初に受信したとき、再構成タイマーを開始します。このタイマーが期限切れになったときに、パケット全体がまだ再構成されていない場合、既存のフラグメントを破棄しなければならず (MUST)、再構成状態をクリアしなければなりません (MUST)。再構成タイムアウトは最大60秒に設定しなければなりません (MUST)（これは、IPv6再構成プロセス [[RFC2460]] のタイムアウトでもあります）。

---