要約

  • PDU-Concat は、通常は短い複数の PDU に一つの ULE 型と、存在する場合は一つの NPA 宛先を共有させることで効率を得る。その代わり、検証と廃棄も束単位で相関する。
  • 運用証拠は、束への収容、待機、送出、外側の完全性、内側の長さ照合、抽出、転送、上位層の受理を別々の受領記録として残さなければならない。

受信処理が五番目の PDU に到達する。長さ欄には、SNDU に残ったバイト数より大きい値が書かれている。ここで受信側は、途中まである PDU を「たぶん使える」として渡してはならない。先に現れた四個が整って見えても、外側の合計と内側の境界が一致しなければ、束そのものを正しく閉じることができない。

PDU-Concat の設計価値は、まさにこの厳密さと効率の同居にある。

受信側は共有された文脈を解く

PDU-Concat は ULE の必須拡張タイプ 3 である。SNDU の基本ヘッダーは全体長を示し、PDU-Concat-Type は内包されるすべての PDU を一度だけ記述する。再帰的な PDU-Concat は認められず、メンバーは同じ ULE 型でなければならない。各 PDU は 15 ビットの長さと本体を持ち、16 ビットや 32 ビット境界への整列は要求されない。

NPA 宛先があれば、その同じアドレスをすべてのメンバーに関連付ける。なければ、すべてを NPA なしとして扱う。PDU-Concat より前の TimeStamp などは、各 PDU ではなく複合体全体に作用する。

この共有こそが、型や宛先を何度も送らないという節約を生む。ただし NPA は安全な本人確認ではない。RFC 4259 は NPA フィルタリングを弱い安全策と位置づけ、ソフトウェアで変更可能な場合があると説明する。同じ NPA は、同じ IP 宛先、権限、取引、利用者を証明しない。

CRC の成功後にも別の帳尻がある

ULE では SNDU ごとに CRC-32 を検証する。分割された GSE では CRC が最後のフラグメントにあり、再構成後に取り除かれる。しかし外側の完全性が通っても、内側の長さが正しいとは限らない。

受信側は PDU-Concat-Type を扱えるか確認し、各 PDU の長さを順に検証し、処理した長さの合計が基本ヘッダーの値と一致することを確かめる。未対応型は廃棄し、PDU-Type エラーを記録することが望ましい。

合計と個別サイズが一致しない場合、RFC 5163 は SNDU 全体を廃棄し、サイズ不一致を記録することを SHOULD とする。一方、宣言長が残りのバイト数を超える部分 PDU は転送してはならない。こちらは MUST NOT である。報告ではこの強度差を保つ必要がある。

したがって証拠は階段状になる。送信側が同型 PDU を束へ入れたこと、閾値またはサイズ条件で送出したこと、外側の再構成と完全性が通ったこと、拡張と型を理解したこと、各メンバーが残り領域に収まったこと、合計が閉じたこと、完全な PDU を抽出・転送したこと、上位層がそれぞれ受理したこと。IANA 登録、CRC、SNDU 受理のどれも、この全段階を一度には証明しない。

束を作る時間も設計の一部である

小さな PDU を束ねるには、次の一個を待つ時間が要る。RFC は PDU Packing Threshold を有限にし、設定可能にすることを推奨する。長く待てば効率が上がり得るが、ジッターが増え、破損の確率も増える可能性がある。期限までに追加 PDU が来なければ、待機中の全 PDU を直ちに送る。

規格は万能の閾値を定めない。評価すべきなのは、節約したヘッダーバイトと処理量だけではなく、実際の待ち時間分布と、一回の不整合で同時に失う独立 PDU の数である。

TS-Concat は固定長の例を示す。188 バイトの MPEG-2 TS パケットを複数収め、残り長が 188 で割り切れなければ全パケットを廃棄しなければならない。束ねることは危険だという結論ではない。障害の単位を選んだという事実である。

省略できる拡張と省略できない構文

RFC 4326 の任意拡張は H-LEN から大きさを知れるため、未実装でも次へ進める。TimeStamp は任意であり、受信側は処理しても飛ばしてもよいが、その後の PDU 処理は続けなければならない。送信時計が同期していない限り一方向遅延は測れず、損失には追加の送信側情報が要る。

PDU-Concat は後続バイトの切り分け方そのものを変えるので、知らないまま飛ばせない。必須であることは構文理解の条件であり、配送成功の証明ではない。

出典