要約

  • RFC 1992 は、提供者による配布制限、受信者による選択保存、要求者ごとに異なる内部地図、古くなり得るキャッシュを認め、ルーティング・データベースの不完全さと不一致を通常状態として扱った。
  • 特別な制約を求める利用者または代理が経路計算の費用を負い、一つの装置が決めた経路に従うことで不一致な次ホップ判断によるループを避ける。ただし地図の正しさやサービス実現、実装・普及は証明しない。

Nimrod の設計を読むとき、最初に見るべきものは新しいアドレス形式ではない。捨てられた前提である。すべてのルータが、完全で、新しく、同一のトポロジー情報を持つという前提を RFC 1992 は置かなかった。

想定されたインターネットは、ネットワーク数も利用者数も増え続け、媒体、遅延、損失、料金、利用条件が異なる世界だった。機器のメモリと処理能力には限界がある。事業者は内部事情や提供条件をすべて公表したいとは限らない。そこで情報の不一致を同期の失敗ではなく、設計が吸収すべき入力として扱った。

地図は一枚の写しではない

Nimrod の map は、node と方向を持つ adjacency から成る。接続可能性だけでなく、利用できるサービスや制限も node の属性として表す。同じ物理領域は、ある地図では一つの node、別の地図では詳細な internal map になり得る。node の代表者は要求に応じて内部地図を返し、セキュリティ上の理由などから要求者ごとに異なる内容を返すこともできる。

したがって「どの地図が本物か」という問いだけでは足りない。複数の地図は、同じ領域を異なる粒度と目的で記述する。問題は、経路が必要とする差異を、その地図が残しているかどうかである。

clustering は計算から見える entity の数を減らす。既存の cluster をさらにまとめ、多層の階層を作ることができる。各層で同じ手法を使う必要はなく、論理的な境界が物理的なルータやネットワーク境界と一致する必要もない。

abstraction は entity 一つあたりの説明量を減らす。RFC は、少数の構成要素だけが提供するサービスを省く例や、サービスを平均値で表す例を挙げる。これは無損失の圧縮ではない。平均値で十分な通信もあれば、消された少数サービスこそ必要な通信もある。情報量を抑えることと、最適な経路を得ることは交換関係にある。

誰が見せず、誰が捨てるのか

配布制限と保存選択は、結果が似ていても権限が違う。cluster は、どの情報を誰に配るかを決める。受信者は、届いた情報のうち何を保持するかを決める。前者は内部構造の秘匿やサービス政策に関係し、後者はメモリ、計算量、ローカルな関心に関係する。

不足している edge を見ただけでは、非公開なのか、抽象化で消えたのか、受信側が保存しなかったのか判断できない。責任を追跡するには、欠落そのものではなく、その欠落を生んだ操作を記録しなければならない。

cache も別の操作である。取得済み情報を再利用すれば、問い合わせの遅延と資源を節約できる。しかし RFC 1992 は、古いキャッシュが質の低い経路を生むと明記する。有効期間は単なる性能調整ではなく、地図が現在を語っているかどうかの条件になる。

難しい要求の計算は要求者へ

複数制約を満たす経路生成は通常 NP-complete で、計算負荷が高い。Nimrod は全ルータに同じ高度な計算を課さない。特別な経路を必要とする entity だけが、その情報収集と計算の費用を負う。利用者自身よりも、利用者に代わる装置が実行する場合を RFC は現実的と見ていた。

各地点のアルゴリズムは同じでなくてよい。新しい選択方法を試すために、世界中のルータの更新を待つ必要がない。この性質は段階的な導入と実験を可能にする。

一方で、計算を分散すれば情報の力まで均等になるわけではない。事業者が開示しない内部情報は、利用者の計算能力では補えない。豊富な地図と予算を持つ代理は、粗い地図しか持たない利用者より多くの候補を検討できる。RFC 1992 は計算費用の所在を示したのであって、政策の公平性を保証したのではない。

一つの計算が防ぐループ

異なる地図を持つルータが各 hop で次の行き先を独立に決めると、判断の組合せがループを作り得る。A は B を出口と考え、B は A を出口と考える。各自の地図の中では合理的でも、連結すると戻ってくる。

Nimrod の path-oriented forwarding は、経路全体を一つの装置が一つの情報集合から計算する。中間ルータは、その結果に従う。別の地図を使って毎回経路を作り直さないため、地図の不一致がそのまま次ホップの循環にならない。

ただし状態の置き方は mode ごとに異なる。flow mode では path-id が中間ルータに事前設定された状態を指す。setup には bandwidth や delay などの資源要求を含め、成功または失敗の応答があり得る。CSC と CSS は connectivity specification の列で選択結果を表す。datagram mode は事前設定した flow state を用い、IPv4 の source route を置かずに厳密な非ループ経路を支える。

よって「Nimrod は source routing だった」という一文では足りない。全パケットが物理的な hop 一覧を持つわけではない。共通するのは、転送前に一つの判断主体が経路を決め、その判断を packet と router state に分配する点である。

非ループ性も限定された結論だ。経路を計算した地図が古い、誤っている、粗すぎるという可能性は残る。path state が消えたかもしれず、リンクが故障したかもしれず、事業者の service characterization が実測と一致しないかもしれない。戻ってこない packet が、目的地に届くとは限らない。

認証済みでも、正しいとは限らない

RFC 1992 の trust の議論は、認証の限界をはっきり書く。内部地図を公開しない node は外部向けの記述を満たすべきだが、文書中の例では、広告された地図が privacy を暗示しても物理構成がそれを強制できない。さらに、信頼できる node から認証済み情報を受け取っても、honest mistake は残る。

発信者の同一性、伝送中の完全性、内容の正確性、鮮度、抽象の適合性、設定の実行、サービス結果は別々の証拠である。RFC 1992 の Security Considerations は、セキュリティ問題を扱わないと明記する。ここから認証、認可、機密性、耐攻撃性を読み込むことはできない。

RFC の存在から採用へ飛ばない

RFC 1992 は Informational であり、protocol と distributed database の仕様は他文書にあるとする。RFC 1752 は IESG が Nimrod を IPng 候補としては研究色が強すぎると見た記録を残す。RFC 1753 は、実地の導入、試行、検証を経ていないため広範な採用を仮定しないと書いた。RFC 2102 でも unicast route generation は個別の routing agent に委ねられ、multicast の生成と転送は特定されていない。

これは失敗の断定ではなく、証拠の終点である。Lu Heng の Localized Future Decision は、異なる場所が異なるアルゴリズムを選ぶ構造を読む助けになる。Running-Code Primacy は、文書の公開と実装・運用を区別する。Reality Layers は、地図の主張、path state、実際の packet、利用者の結果を一つに潰さない。

RFC 1992 が残したのは、万能な地図ではなく責任の配置だった。誰も全体を知らなくても、一つの経路について誰が計算したかは明確にできる。その仕組みは一種類のループを防ぐ。しかし、知らない部分を正しいことにはしない。そこにこそ Nimrod の大胆さと限界が同時にある。

情報源