要約

  • 2001 年の要約リフレッシュは、完全な状態説明を識別子のリストに置き換えた。基本的には送信間隔を延ばす仕組みではなく、繰り返す内容を減らす仕組みだった。
  • 状態が見つからなければ完全な説明を求められる。しかし、識別子に対応する記録が残っていて、その内容が壊れている場合まで同じ方法で検出できるわけではない。
  • 完全なリフレッシュを時折残す方法や、その後の隣接障害検出は、省略された反復が担っていた仕事を別に引き受けた。受信確認だけで、予約や転送の正しさが証明されることもない。

短くしても、間隔はそのままだった

通信の負担を減らす拡張と聞けば、まず「送る回数を減らした」と考えたくなる。ところが、2001 年 4 月の RFC 2961 で定義された要約リフレッシュでは、対象の状態について、置き換え前の完全なリフレッシュより送信頻度を落としてはならなかった。

節約する場所が違ったのである。以前なら Path や Resv の説明を繰り返したところで、すでに知らせた状態の識別子を送る。受信側は自分が保存している状態を探し、その寿命を更新する。状態を維持する周期を変えなくても、毎回運ぶ情報と処理する説明を減らせる。

この小さな違いは、後に登場する長いリフレッシュ間隔と区別するためにも重要だ。2001 年の設計が最初に問うたのは、どれほど長く沈黙してよいかではない。同じ状態をもう一度説明する必要が、毎回本当にあるのかという問いだった。

説明の反復は保険でもあった

RSVP はネットワーク内の資源予約を扱うシグナリングプロトコルだ。1997 年 9 月の RFC 2205 では、Path と Resv の状態は定期的なリフレッシュによって維持される。更新が十分長く途絶えると状態は消去される。明示的な解放メッセージも使えるが、それが失われたからといって予約状態を永久に残す設計ではない。

このソフトステートには二つの顔がある。一つは期限付きの維持であり、もう一つは情報を送り直すことによる回復である。変更を知らせるメッセージが失われても、完全な説明がまた届けば、欠けていた情報を得る機会が生まれる。経路が変わった場合にも、新たな経路上で状態を構成し直さなければならない。

周期を長くすれば通信や処理の負担は軽くなるが、回復や消去が遅くなる場合がある。短くすればその逆になる。したがって、反復を単なる無駄と見なすと、同じ反復が提供していた回復の機会まで見落としてしまう。

RFC 2961 は、まず変更を伴うメッセージと、同じ状態の維持とを分けた。新しい情報や変更はトリガーメッセージで運び、変化のないものをリフレッシュとする。帯域の要求値が変わっていなくても、ポリシーなどの関連オブジェクトが変われば、それは古い識別子だけで済ませてよい更新ではない。

識別子が答えられる質問

MESSAGE_ID には識別子と epoch があり、生成元のアドレスも解釈の範囲を定める。再起動などによって、以前の実行状態と新しい状態を混同しないための仕組みである。元の Path と Resv では、生成元のアドレスは RSVP_HOP にある情報であり、常に外側の IP パケットの送信元と同じだと考えてはいけない。

この識別子は、保存された内容を計算して得たハッシュではない。世界共通の予約番号でもない。答えられるのは、一定の相手と実行時期の文脈で「以前のどの状態を指しているか」という質問だ。

最初に完全な状態を MESSAGE_ID とともに知らせておくからこそ、後の Srefresh で説明を省ける。受信側が該当する Path または Resv を見つければ、その状態をリフレッシュする。新しい予約や変更された説明を、既存の番号だけで作り出せるわけではない。

同じ仕様には Bundle もある。こちらは複数の完全な RSVP メッセージを一つのデータグラムに収める方法であり、複数の資源要求を一つの許可済み予約にまとめることではない。さらに MESSAGE_ID に対する確認と再送は、メッセージを届けるための仕組みだ。梱包、識別、受信確認、資源の許可は、同じ装置で実行されても別の仕事である。

見つからない記録には返事ができる

受信側が要約中の状態を見つけられないとき、MESSAGE_ID_NACK によって、その識別子について完全な説明が必要だと知らせる。送信側が対応する状態を持っていれば、標準の Path または Resv を送る。送信側にも該当する状態がなければ、存在しない内容を補う動作までは要求されない。

この否定確認は、帯域の要求を拒否したという意味ではない。状態の所在に関する返事である。したがって、NACK が返ったから容量不足だと決めつけたり、補送が終わったから予約全体が承認されたと判断したりするのは、異なる手続きを混ぜている。

マルチキャストでは、さらに自分がその状態を扱うべき相手かどうかを判断する必要がある。送信元やグループの情報、逆方向の経路確認によって、無関係な受信側が「持っていない」と大量に返事をすることを避ける。要約は、全世界の参加者が同じ一覧を持つことを前提にしていない。

ここまでは、欠落を扱う話だ。難しいのは、欠落していない場合である。識別子に対応する場所に何かが保存されていることと、その内容が現在も正しいことは一致しない。

仕様が書き残した限界

RFC 2961 の第 5.5 節は、要約リフレッシュが普通のリフレッシュと完全に同じエラー回復特性を持たないと述べ、内部状態の破損を例に挙げている。これは実際の障害件数を報告した箇所ではない。仕組みの適用範囲を説明したものだ。

仮に識別子は残ったままで、保存された説明の一部が誤っていたとする。要約には元の説明が入っていないので、その受信だけで内容を照合し直すとは限らない。番号を認識した結果として寿命が延びても、誤りが見つかったことにはならない。NACK が出ていないという静けさにも、ここでは限界がある。

同節は二つの補助手段を示す。第一は、トリガーを送った時点で内部状態のチェックサムなどを保存し、後で比較する方法だ。これは状態が変化したのにトリガーを送らなかった場合を検出するためのもので、仕様自身が、内部状態の破損を防ぐものではないと区別している。

第二は、ときどき完全な Path と Resv のリフレッシュも送ることだ。要約より長い周期で完全な説明を再送すれば、通常の RSVP が持つ回復の機会を残しつつ、毎回の重い反復を避けられる。完全なものを送る周期には、同じ状態の要約を重ねて送る必要はない。

重要なのは、二つを合体させて「チェックサムが相手の状態をすべて保証する」と言わないことである。一方は通知漏れの検出、もう一方は完全な説明の再提供だ。どちらも、装置のあらゆる正しさを一度に証明する仕組みではない。

正しい相手から届いても、中身は増えない

メッセージ認証を加えても、この情報量の違いは変わらない。RFC 2747 の RSVP 完全性保護は、鍵を共有する相手からのメッセージと、その改変に関する問題を扱う。MESSAGE_ID 自体が認証をするわけでも、完全性保護が暗号化を意味するわけでもない。

仮に短い要約が本物の隣接ノードから届いたことを確かめられても、省略された状態説明がそこに復活することはない。相手の確認と、相手が指すローカル記録の内容確認とは別だ。この区別は歴史的な設計の説明であって、当時の暗号方式を現在の設定として勧めるものではない。

2007 年の RFC 5063 は、GMPLS RSVP の再起動回復に要約を使う際にも慎重だった。下流の隣接ノードが、以前に受け取った Path の識別子を上流の再起動した制御装置へ知らせる。通常の「自分が送った状態」の要約とは向きが違う。

失われた説明は RecoveryPath で補えるが、それだけで存在しない転送状態を作ってよいわけではない。回復では、残っている転送状態とシグナリングを対応づける必要がある。新たな転送の構成は、別途の正規の Path や入口での管理指示などに従う。隣人の記憶は回復の材料にはなるが、動作中の経路を無条件に証明するものではなかった。

長い間隔には、別の検出器が要る

要約でメッセージが小さくなっても、状態の数が消えるわけではない。2009 年の RFC 5439 が分析した拡張性には、状態ごとのメモリーや処理も含まれる。長いリストには、それぞれの識別子を調べる仕事が残る。単純なパケット数だけで装置の余裕は決まらない。

2018 年の RFC 8370 では、リフレッシュ間隔を長くする設計が、信頼性のあるメッセージ配送、未確認の状態を扱う短い周期、明示的な隣接障害検出と組み合わされた。障害を見つける役割を、遠い将来のリフレッシュにただ預けたわけではない。

信号を交換する隣接関係が失われたと判定すれば、その関係を通して学んだ Path と Resv を期限切れとして扱う。新しい確認の要求や能力表示も必要になる。対応しない相手には、従来の短い周期を使う。大きな間隔の数字だけを抜き出しても、同じ機能にはならない。

IANA の RSVP パラメーター登録 には、Srefresh や確認、識別子リスト、後の能力ビットが記録されている。しかし、番号が登録されていることは、目の前の相手が対応している証拠ではない。実際のメッセージで能力が示されなくなれば、以前の合意を無期限に信じて要約を送り続けることもできない。

これらの文書が示すのは、設計とその条件の変化であり、すべてのネットワークが同じ順番で移行したという統計ではない。共通しているのは、安く済ませる処理の範囲を明確にしたことだ。予約を生かすための返事は、その内容をもう一度調べたという返事ではなかった。