要約

  • BTPU は、再送要求を返せない片方向リンクで、同じ Transfer message の完全なコピーを複数のリンク層 PDU に載せて送れる。
  • Transfer End は最後の Segment Index を示すだけである。受信側が 0..N をすべて保持して初めてローカルな再構成が完了し、その事実は BTPU から送信側へは戻らない。

深宇宙、放送、データダイオードのようなリンクでは、問いかけに答える経路が最初から存在しないことがある。その場合、同じ断片を何度も送るのは合理的だ。2026年9月7日版の draft-ietf-dtn-btpu-04 は、BPv7 Bundle などの大きなバイナリオブジェクトを、フレーム型の不安定な片方向リンクで運ぶための最小限の方法を定めている。

受信完了の条件は明快だ。同じ Transfer に属するセグメントは32ビットの Transfer number を共有し、Segment Index はゼロから増える。Transfer End message は最後のセグメントと、その番号 N を運ぶ。受信側が 0 から N までを漏れなく得て連結できたときに限り、再構成されたオブジェクトを上位層へ渡せる。

しかし Transfer End は肯定応答ではない。送信したという事実は、相手が受け取ったという事実ではない。受信側が末尾を見ても、途中の欠落は埋まらない。全セグメントの再構成に成功しても、BPv7 の解析、CRC、BPSec の処理、転送、宛先への配送、アプリケーションによる受理はまだ別の段階にある。

BTPU が損失に対して提供するのは、フィードバックではなく反復である。任意の message を別のリンク層 PDU で繰り返せるが、再送される message は元のものと完全に同一でなければならない。セグメントごと、Transfer ごとに回数を変えることもできる。リンクの事前分析、ローカルな重要度、あるいは帯域外で得た損失情報は方針に使えるが、草案は「何回なら到着」といった普遍的な閾値を与えていない。

滑動する Transfer Window にも証明できる範囲がある。これは有効な Transfer number の帯域を限定し、32ビット値の周回後に新旧を見分け、古い再構成状態を捨てるための受信側管理である。サイズは帯域外で合わせる必要があり、現稿は16を推奨しつつ、その値がまだ議論中であることも明記する。Window から落ちた状態は、受信側が保持をやめたことを示すだけで、以前の配送を肯定も否定もしない。

同じ理由で、BTPU の反復回数、リンク層の冗長化、消失訂正符号を一つの「信頼度」にまとめるべきではない。それぞれが異なる障害に作用し、観測点も異なる。任意の Bundle Length Hint もメモリ確保を助ける情報にすぎず、予想された長さは受信済みバイトではない。

運用上の限界は草案自身が明言している。BTPU は信頼性を保証せず、成功を知らせる帯域内の戻り経路も持たない。確認が必要なら、受信側から送信側へ向かう論理的に別の経路を用意しなければならない。また BTPU 自体には輻輳制御もシグナリングもないため、下位層がその責任を負わない限り、輻輳し得る公共経路へ置くことはできない。

BPv7 の status report は、受信、転送、配送、削除、application acknowledgement を区別できる。ただし、それらは後から別経路で届くかもしれない別の記録だ。片方向であることを隠さず、見えない結果を見えたことにしない点に、BTPU の設計上の価値がある。

出典