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

3.1. SCHC Compound ACK Message Format (SCHC 複合確認応答メッセージ形式)

3.1. SCHC Compound ACK Message Format (SCHC 複合確認応答メッセージ形式)​

図 1 は成功した SCHC ACK 形式を示しています, すなわち, すべての fragments (フラグメント) が正しく受信された場合 (C=1), [RFC8724] で定義されているとおりです。

              |--- SCHC ACK Header ---|
              |        |--T-|--M--| 1 |
              +--------+----+-----+---+~~~~~~~~~~~~~~~~~~
              | RuleID |DTag|  W  |C=1| padding as needed
              +--------+----+-----+---+~~~~~~~~~~~~~~~~~~

図 1: SCHC 成功 ACK メッセージ形式, RFC 8724 で定義されているとおり

SCHC Packet のいずれかの windows (ウィンドウ) で SCHC Fragment の損失が見つかった場合, SCHC Compound ACK を使用してもよい。SCHC Compound ACK メッセージ形式は図 2 と図 3 に示されています。

 |--- SCHC ACK Header --|- W=w1 -|...|---- W=wi -----|
        |--T-|---M--|-1-|        |...|---M--|        |---M--|
 +------+----+------+---+--------+...+------+--------+------+~~~~~+
 |RuleID|DTag| W=w1 |C=0| Bitmap |...| W=wi | Bitmap |00..00| pad |
 +------+----+------+---+--------+...+------+--------+------+~~~~~+
                           next L2 Word boundary ->|<-- L2 Word ->|

図 2: SCHC Compound ACK メッセージ形式。windows W = w1,...,wi で損失が見つかりました, ここで w1 < w2 <...< wi。

SCHC Compound ACK は window number (ウィンドウ番号) (W) とその対応する bitmap (ビットマップ) をグループ化します。Window numbers は連続している必要はありません。ただし, SCHC Compound ACK メッセージに含まれる window numbers とその対応する bitmaps は, 最も番号の小さい window から最も番号の大きい window まで順序付けられなければなりません。したがって, window number ゼロの bitmap が SCHC Compound ACK メッセージに存在する場合, それは常に順序で最初のものでなければならず, その window number は SCHC ACK Header に配置されなければなりません。

メッセージ内の最後の bitmap の後に最後の layer two (L2, レイヤ 2) Word を埋めるために M 個以上の padding (パディング) bits が必要な場合, 最後の bitmap の後に 0 の M bits を追加しなければならず, その後必要に応じて padding が適用されます (図 2 参照)。window number 0 (メッセージに存在する場合) は w1 として配置されるため, ゼロに設定された M bits は window number 0 と混同されることはありません; したがって, それらは SCHC Compound ACK メッセージの終わりを示します。

図 3 は, 必要な padding bits が M bits より厳密に少ない場合を示しています。この場合, L2 Maximum Transmission Unit (MTU, 最大転送ユニット) は追加の window value のための余地を残しません, ましてや bitmap のための余地もないため, SCHC Compound ACK メッセージの終わりを示します。

 |--- SCHC ACK Header --|- W=w1 -|...|---- W=wi -----|
        |--T-|---M--|-1-|        |...|---M--|        |---M--|
 +------+----+------+---+--------+...+------+--------+~~~+
 |RuleID|DTag| W=w1 |C=0| Bitmap |...| W=wi | Bitmap |pad|
 +------+----+------+---+--------+...+------+--------+~~~+
                                 next L2 Word boundary ->|

図 3: M 個未満の Padding Bits を持つ SCHC Compound ACK メッセージ形式。windows W = w1,...,wi で損失が見つかりました, ここで w1 < w2 <...< wi。

SCHC Compound ACK は中間 windows/bitmaps (すなわち, SCHC Compound ACK メッセージの最後のものではない bitmaps) に対して Compressed Bitmap (圧縮ビットマップ) 形式を使用してはならない; したがって, 中間 bitmap フィールドのサイズは WINDOW_SIZE でなければなりません。したがって, SCHC Compound ACK はメッセージ内の最後の bitmap に対してのみ Compressed Bitmap 形式を使用してもよい。最後の bitmap に対するこの Compressed Bitmap のオプション使用は, 技術固有の SCHC Profile (プロファイル) によって指定されなければなりません。

最後の bitmap が効果的に圧縮されるケースは図 3 に対応し, 最後の bitmap が (構造上) L2 Word 境界で終わるため, padding がまったく不要になります。

図 4 は SCHC Compound ACK の bitmap 圧縮例を示しています, ここで最後の window (wi) の bitmap は最初の tile (タイル) が正しく受信されなかったことを示しています。圧縮アルゴリズムが効果的な圧縮をもたらしたため, padding は必要ありません。

 |--- SCHC ACK Header --|- W=w1 -|...|-------- W=wi -------|
        |--T-|---M--|-1-|        |...|---M--|
 +------+----+------+---+--------+...+------+--------------+
 |RuleID|DTag| W=w1 |C=0| Bitmap |...| W=wi |0 1 1 1 1 1 1 |
 +------+----+------+---+--------+...+------+--------------+
                        next L2 Word boundary ->|

                非圧縮 Bitmap を持つ SCHC Compound ACK

 |--- SCHC ACK Header --|- W=w1 -|...|-- W=wi --|
        |--T-|---M--|-1-|        |...|---M--|
 +------+----+------+---+--------+...+------+---+
 |RuleID|DTag| W=w1 |C=0| Bitmap |...| W=wi |0 1|
 +------+----+------+---+--------+...+------+---+
                        next L2 Word boundary ->|

       圧縮 Bitmap を持つ送信された SCHC Compound ACK

図 4: 圧縮 Bitmap を持ち Padding が追加されていない SCHC Compound ACK メッセージ形式。windows W = w1,...,wi で損失が見つかりました, ここで w1 < w2 <...< wi。

図 5 は SCHC Compound ACK のもう1つの bitmap 圧縮例を示しています, ここで最後の window (wi) の bitmap は2番目と4番目の tiles が正しく受信されなかったことを示しています。この例では, 圧縮アルゴリズムは最後の bitmap の効果的な圧縮をもたらしません。さらに, 最後の L2 Word を埋めるために M bits を超える padding が必要になるため, padding が適用される前に 0 の M bits がメッセージに追加されます。

|--- SCHC ACK Header --|-W=w1-|...|-------- W=wi -------|
       |--T-|---M--|-1-|      |...|---M--|
+------+----+------+---+------+...+------+--------------+
|RuleID|DTag| W=w1 |C=0|Bitmap|...| W=wi |1 0 1 0 1 1 1 |
+------+----+------+---+------+...+------+--------------+
                   next L2 Word boundary ->|

                非圧縮 Bitmap を持つ SCHC Compound ACK

|--- SCHC ACK Header --|-W=w1-|...|-------- W=wi -------|
       |--T-|---M--|-1-|      |...|---M--|              |---M--|
+------+----+------+---+------+...+------+--------------+------+~~~+
|RuleID|DTag| W=w1 |C=0|Bitmap|...| W=wi |1 0 1 0 1 1 1 |00..00|pad|
+------+----+------+---+------+...+------+--------------+------+~~~+
                   next L2 Word boundary ->|<------ L2 Word ------>|

                 送信された SCHC Compound ACK

図 5: L2 境界に達するために Padding が追加された圧縮 Bitmap を持つ SCHC Compound ACK メッセージ形式。windows W = w1,...,wi で損失が見つかりました, ここで w1 < w2 <...<wi。

SCHC sender (送信機) が無効な window numbers を持つ SCHC Compound ACK を受け取った場合, 重複する W 値やまだ送信されていない W 値など, SCHC Compound ACK メッセージ全体を破棄しなければなりません。

注: SCHC Compound ACKs は, 通常の SCHC ACKs が区別可能であるのと同じ方法で Receiver-Abort (受信機中止) メッセージと区別できます, なぜなら Receiver-Abort パターンは正当な SCHC Compound ACK [RFC8724] には決して現れないからです。

に最終更新