要約

  • draft-ietf-ippm-stamp-ext-hdr-14の新設3.3節は、出口ノードのデータプレーンが受け取ったIPヘッダーとIPv6拡張ヘッダーを、そのノードのSession-Reflectorに渡すことを求める。双方向測定では、逆方向の入口ノードからSession-Senderへの受け渡しも必須とする。
  • これは審議中のInternet-Draftであり、RFC成立や実装普及を示さない。選択子による照合や不一致時のCフラグは第13版にも実質的に存在した。新たな論点は、装置内部の情報引き渡しが規範として独立したことだ。

測定値の欠落を回線のせいにする前に、装置の中を一段見なければならない。転送面はパケットを処理したのに、STAMPの反射器が拡張ヘッダーを受け取っていなければ、反射器に返せる材料はない。受信カウンターと測定プロセスの入力は同義ではない。9月18日付の第14版は、その間にある境界を3.3節で正面から扱う。

出口ノードで送信側の試験パケットを処理したデータプレーンは、受信したIPヘッダーとIPv6拡張ヘッダーを同じノードの反射器に提供しなければならない。往復を測る場合には入口側にも対になる条件がある。反射器から戻った試験パケットを処理した逆方向のデータプレーンが、受信ヘッダーを送信側の測定機能に渡す。返信パケットが届いたという事実だけで、送信側が復路のヘッダーを見られたと見なすわけにはいかない。

どのヘッダーを写すかは、TLVの要求内容で決まる。非ゼロの要求では長さと、IPv6拡張ヘッダーなら先頭8オクテット、固定IPヘッダーなら先頭4オクテットを照合する。ゼロの要求では長さが合う最初のヘッダーを選ぶ。該当するものがなければCフラグを立てたTLVを返す。第14版はこれらを手順に整理したが、ゼロ指定やCフラグの原則は第13版のフィールド定義にもあった。同版は、データプレーンからヘッダーにアクセスできない場合さえ失敗例として挙げていた。したがって「失敗通知が今回初めて生まれた」という説明は正しくない。

反射されたデータが証明する範囲も慎重に扱うべきだ。選ばれたヘッダーが測定機能へ渡され、要求と合ったことを示すにとどまり、経路上の全ヘッダーや全中継点のIOAM情報が欠けずに残った保証にはならない。C=1だけでは選択子の不一致、内部の引き渡し不足、その他の制約を区別できない。以前のBTW記事が扱ったMTU・速度・総量制限の由来と、今回の内部引き渡しは異なる問題である。

新稿はパスMTUの判定対象をIP、UDP、STAMP、反射用TLVを含む試験パケット全体と明記した。サイズ上限そのものは旧稿にも存在する。Datatracker上の状態は引き続き審議中で、AD Evaluationを経てIESGに提出された段階だ。特定製品の不具合、相互運用の実績、正式なRFC化は読み取れない。

出典