要約

  • RFC 3654は、Control Element（CE）との関連を失ったとき、Forwarding Element（FE）が常に転送を続けるとも必ず停止するとも定めなかった。アーキテクチャには喪失の検知、関連の回復、状態の再同期、そしてFEの動作を事前に決められる仕組みを求めた。
  • RFC 7121は後に二つの回復モードを記述した。一方は事前関連フェーズへ戻り、もう一方は予備CEを試しながらタイムアウトまで転送を続ける場合がある。関連の再確立だけでは、FEの状態すべてが戻った証明にならない。

ひとつのルーターに、異なる仕事を置く

2003年11月のRFC 3654は、制御と転送の各要素が協調し、外部からは統合されたIPネットワーク要素に見える構成を示した。Control Elementはルーティングやシグナリングを扱い、Forwarding Elementはパケット単位の処理を担う。これは論理的な役割分担であり、二つの筐体を必須とする定義ではない。文書は拡張性と独立した進化を理由に挙げているが、広く展開されたという証拠を示してはいない。 RFC 3654

難題は、FEに表や設定済み機能が残っている一方、そのCEとの関連が切れた場合に現れる。「制御側が失敗した」だけでは、パケットがどうなるかはわからない。FEは手元の状態で転送を続けるか、停止するか、予備CEへ接続を試みるかもしれない。RFC 3654は、この三つを同じ結果として扱わなかった。

規定されたのは選択の余地であり、万能の答えではない

アーキテクチャ要件7は、関連喪失の検知、関連の復旧、効率的な状態再同期、そしてCEを失ったFEの動作を事前設定できることを一組の要件にした。転送を続けることと運転を止めることは例として挙げられ、どちらか一方を全装置に適用するよう命じてはいない。プロトコル要件8も同じ境界を繰り返す。 RFC 3654

転送を続ければ通信を保てる一方、FEは現在持っている状態に依存する。停止すれば制御状態が不明な期間を短くできるが、サービスは制御関連に依存する。これは設計時に評価する帰結であって、RFCが報告する事故ではない。重要なのは、障害時に実装が黙ったまま選択するのではなく、動作を先に決めておくことだ。

後続仕様は判断を状態と期限に結び付けた

2010年のStandards Track文書RFC 5810は、RFC 3654のプロトコル要件を満たすForCESプロトコルとTransport Mapping Layerを定義した。RFC 5812はFEの能力、現在状態、望ましい設定、論理機能ブロックを記述するモデルを定めた。「できること」「今そうなっていること」「そうするよう指示されたこと」は別の情報である。 RFC 5810 RFC 5812

2014年のRFC 7121はネットワーク要素内の高可用性手順を加えた。FE Protocol ObjectはマスターCEと予備CEを識別し、heartbeat間隔とポリシーが接続問題の検出に使われる。既定のモード0では関連が失われるとFEは事前関連フェーズへ戻り、再接続した場合はFE状態を作り直す必要がある。モード1は再起動回復を使い、CE Failover Timeout Intervalの間、予備CEを順番に試す。未関連の状態でも、設定されたポリシーによってはパケット転送を続けられる。期限までにどのCEとも関連できなければ、FEは事前関連へ移り、転送経路を停止する。再関連後にCEが失われた状態の同期を試みることはできるが、その手法はForCESアーキテクチャの範囲外で、通常は新たな設定メッセージと照会を伴う。 RFC 7121

heartbeatは経路の正しさを判定する信号ではない。RFC 3654は関連喪失の検知に使うheartbeatについて、厳密な配送保証より即時性を優先できるとする。一方、転送表や設定など重要な情報には堅牢な配送を求める。信号が届かなかったことだけで、物理故障、誤った経路、装置全体の停止を証明することはできない。 RFC 3654

別のForCES文書RFC 3532は、スイッチング要素の資源再割り当てと、制御側のモデルが遅れて更新される問題を扱った。隣接するテーマではあるが、ここで追うのは関連喪失後のFEの事前動作と高可用性回復であり、資源の移動や古い目録ではない。RFC 3654はInformationalであり、後続標準は設計が具体化した記録であって、個別事業者の採用証明ではない。 RFC 3532 RFC 3746 RFC 1812 RFC EditorのRFC 3654記録 IETF DatatrackerのRFC 3654記録

出典