要約

  • RFC 3479 は保護対象の LDP 操作にセッション単位の番号を付け、累積 ACK によって相手が永続化した接頭部分を示した。
  • 再接続では不明な末尾を再発行し、チェックポイントで境界を確定し、Cork の三段交換で双方向を同じ位置に停止させた。

TCP が連続している間、LDP は配送順序を自明のものとして扱える。しかし制御系の切替で接続が消えれば、新しい接続は、直前の Label Request が相手に届いたのか、処理されたのか、障害後にも残る形で保存されたのかを教えてくれない。RFC 3479 が扱った中心問題は転送そのものではなく、この欠けた操作履歴だった。

まず FT Session TLV が台帳の範囲を決める。S bit は選択されたラベル操作にシーケンス保護を与え、A bit は全ラベルへの適用を要求できる。C bit はチェックポイントを選び、S なしでも利用できる。したがって同じ Keepalive の確認でも、協商した bit が違えば対象集合は違う。能力表示を保存しなければ、後から「何を確認したか」を復元できない。

Sequence Numbered FT Label に関する操作では、送信側が FT Protection TLV とセッション固有の連番を付けた。受信側は、メッセージ全体または処理後の状態を、再起動後にも取り出せるよう確保してから FT ACK を返す。仕様は保存形式を一つに固定しない。固定したのは、受信しただけの揮発的事実と、回復に使える耐久事実の境界である。

ACK は累積である。番号四の ACK は一から四までの保存済み接頭部を示し、五以降には何も言わない。複数の ACK をまとめてよく、同じ ACK の再送も許される一方、順序外の ACK は接頭部の意味を壊すため禁止された。未確認番号がたまり過ぎれば番号空間が尽き、新しい FT 操作を発行できない。この台帳には帯域節約と未確定債務の両方があった。

接続が戻ると、双方は Initialization で最後に確保した番号を交換する。相手の境界を越えて送った操作は再発行され、受信側は初回と同様に処理する。古い TCP byte stream を再生するのではない。二つの保存済み境界を比較し、結果が不明な末尾だけを再構成する。

再発行には限定された短縮規則がある。Label Request と対応する Label Abort、Label Mapping と対応する Label Withdraw は net-zero の組として省略できる。ただし故障前に送信済みの操作を、ローカル queue に逆操作があるというだけで消してはならない。どちらの半分が相手に届いたかを ACK で確定した後に初めて、安全な相殺を判断できる。

Address と Address Withdraw も保護対象だった。ここを曖昧にすれば、再接続後に一方だけが古い address を有効だと考える。以前広告した address が無効になったなら明示的な Withdraw が必要であり、双方が保存を宣言しない場合は旧 address をすべて撤回済みとして再構築した。

チェックポイントは粒度を変える。FT Protection TLV 付き Keepalive は、それ以前の check-pointable message またはその結果状態をすべて確保し、ACK を返すよう求める。C のみなら通常メッセージは個別の有効番号を持たず、集合として同期される。S も有効なら、sequence 保護された label 操作と address が対象になる。チェックポイントという名称だけでは coverage は決まらない。

さらに、一方向の checkpoint は双方向の停止を証明しない。制御された shutdown では、停止を求めた node 自身も、相手から受けた状態をすべて保存したことを確認する必要がある。FT Cork TLV の三段 handshake は、要求、相手側の処理完了と静止、逆方向の最終確認を順に閉じる。三つ目がなければ二つの台帳は同じ終端に止まったとは言えない。

保存できない場合の規則も明確だった。操作を保持または pending にできない peer は FT Reconnect Flag をゼロにしなければならない。どちらかがゼロなら旧 session の FT state を破棄する。label-space の範囲など session parameter が変われば、昔の label 操作の意味も変わり得るため、そのまま継続できない。

歴史を美化しないためには IESG Note が重要である。そこでは timer と retry 値の指針が不十分で、premature failover の危険があり、将来の TCP fault tolerance の模範にすべきでないと警告された。RFC 3479 は帳尻合わせの手順を示したが、どの運用環境にも安全な時間設定を証明したわけではない。

既存記事との境界も保つ必要がある。RFC 3478 の記事は stale forwarding と回復時間を扱い、RFC 3612 の記事は保存状態や ACK が forwarding truth ではないことを扱う。本稿が扱うのは、操作集合の協商、sequence、耐久 ACK frontier、再発行、net-zero、checkpoint、Cork quiescence という制御履歴の仕組みだけである。

Heng Lu の reality-layer の順序に従えば、監査は旧新 session ID、S/A/C/R bit、変化していない parameter から始まる。次に peer ごとに送信番号、確保済み番号、実際に送った ACK を別々に並べる。故障時点の未確認、未保存、pending を凍結し、再接続後の再発行と相殺を一件ずつ照合する。計画停止なら三つの Cork message と新規操作が止まった時刻を残す。

この順序なら、ACK が後続番号まで覆う、checkpoint が全状態を写す、一つの Cork が双方向を止める、といった誤読を防げる。これらは packet delivery の証拠でもない。より前段の問い、すなわち二つの peer が同じものとして証明できる操作史の範囲を答える receipt である。

RFC 3479 が Internet 史に残したのは、障害後の楽観ではなく部分記憶の突合である。sequence が争点を限定し、ACK が共通の過去を示し、再発行が不明な末尾を埋め、Cork が共有の句点を作った。TCP session は切れた。だから操作台帳を突き合わせなければならなかった。

出典