各ドメインは経路を改善した。境界の並びは一度も変わらなかった。

要約

RFC 5152 は head end が完全なドメイン間経路を持たない場合に、各ドメインが順番に TE LSP を計算する方法を定める。
ABR/ASBR は自ドメインの TED、到達性、能力、policy を使い、次の区間と出口を選び得る。
ERO は strict hop と loose hop を混在でき、事前指定と境界への委任を同じ経路に置ける。
次の境界は静的設定または IGP、BGP、policy 情報からの発見で決まり、出口情報がなければ計算は失敗する。
downstream の制約失敗は PathErr を返し、crankback が許可されれば前の境界が別出口を試せる。
head end は別の loose-hop 列、古い TED を疑う同一 retry、または制約緩和を選べる。
どの回復動作も元の探索空間を完全に調べた証明にはならない。
RFC は per-domain 計算が最適なドメイン間経路を保証しないと明記する。
trapping 例では、最初の有効経路が二本目を塞ぐが、別の組合せなら分離経路ペアが存在する。
局所再最適化は各区間を改善しても同じ境界列を残し、全体の組合せを直さないことがある。
PCE など別方式を選べるが、名称だけでは完全な情報や成功を保証しない。
保証には目的、方式、可視範囲、出口順、先行予約、除外、試行、切替、実トラフィックの別々の記録が要る。

透明な改善には見えない境界がある

非連続のドメイン間 LSP は、ドメイン内 S-LSP または H-LSP と別の RSVP session を持つ。各ドメインは自分の transport LSP を make-before-break で再最適化でき、その上に載る複数のドメイン間 LSP も自動的に新しい内部経路を使う。

この操作は追加のドメイン間 RSVP signaling を必要とせず、head end に対して透明になり得る。頻度、metric、利用可能帯域といった判断基準もドメインごとに異なる。運用の自律性という点では合理的である。

ただし透明であることは、end-to-end で最適になったことを意味しない。loose hop が同じ boundary LSR を指し続ける限り、各内部区間が改善しても、LSP は同じドメイン列を通る。

「改善した」は何を変更したのか

連続 LSP の場合、downstream に良い経路が現れたことを RFC 4736 で head end に通知できる。head end が make-before-break を起動し、切替を管理する。stitched/nested では、局所操作が head end を経由しない。

局所再最適化を望まない LSP については、ドメイン内のイベントを head end へ報告する policy が必要になる。これで変更を知ることはできるが、選択済みの境界を再検討したとは限らない。

再最適化の receipt は、metric が下がったという一行では足りない。内部 segment、egress、境界列、二本の経路の関係のうち、どれを変更したのかを示す必要がある。

経路は signaling の進行とともに確定する

per-domain 計算は、完全な end-to-end path が head end で決められず、境界を越えて signaling されない状況に適用される。Path message は destination と次の境界までの情報を運び、後続の boundary や domain identifier を含む場合もある。

計算を担当する node は、最終的にその LSP 上に位置する。要求を受けた境界は、自分の domain の strict section を計算し、場合によっては出口を選び、決定後の問題を次へ渡す。domain がさらに area や sub-AS に分かれるなら同じ構造が再帰する。

全体は一度に解かれず、時間順に組み立てられる。したがって初期の局所有効解は、後続が使える resource と組合せを変える。

ERO の loose hop は計算権限を委ねる

ERO は全 strict path、source domain の strict path と後続境界、すべての境界、または現在の境界と destination だけを表せる。strict と loose は混在できる。

strict node は RSVP-TE の通常手順で処理される。loose hop や複数 LSR を表す abstract node は、境界が RFC 5151 の手順を含めて展開する。見えている区間は指定し、見えない区間は所有者に任せる設計である。

完成した ERO は採用された path description の receipt になる。しかし、検討した出口、棄却した候補、探索順序、単一路を最適化したのか経路ペアを最適化したのかまでは表さない。

最初の成功が二本目の失敗条件を作る

RFC 5152 の A-B-C-D 例では、serialized computation が最初に A-B-C-D を選ぶ。その path と分離する二本目は見つからない。にもかかわらず A-C-D と A-B-D という分離した pair は存在する。

最初の LSP は制約を満たし、正常に destination へ到達し得る。誤りは protocol conformance ではなく objective の分割にある。「まず一つを成功させる」と「二つの関係を満たす」は同じ最適化問題ではない。

したがって no diverse path は、first-path fingerprint、除外対象、topology/TED version、可視範囲、algorithm と順序を伴わなければならない。それらが欠ければ、条件付き失敗を物理的不可能性に見せてしまう。

crankback は一つ前の選択へ戻る

downstream boundary が制約を満たせないと PathErr を返す。crankback が許可・設定されていれば upstream boundary は別の egress を試せる。そうでなければ signaling を止め、error を head end へ送る。

head end は別の loose-hop sequence を選べる。downstream IGP-TE database の古さが原因と考えるなら同じ経路を retry でき、制約を緩めて再試行することもできる。

これらは探索の範囲を広げるが、全組合せを列挙するものではない。また constraint relaxation 後の成功は、元の service が成立した証拠ではない。attempt ID ごとに入力条件と答えを固定する必要がある。

reachable な出口は pair に最適とは限らない

next hop が TED にない場合、境界は domain 外であること、packet switching と in-band control の条件、IP reachability を確認する。到達できなければ Routing Problem を返す。auto-discovery は IGP、BGP、policy routing information を利用できる。

この確認は signaling を次の責任者へ届けるために必要である。downstream TE resource の reservation や、別の出口と比べた pair 全体の価値までは証明しない。

「到達可能」「現在の LSP に feasible」「diverse pair の自由度を保存」の三段階を分ければ、局所 receipt の意味を拡大せずに済む。

計算方式は service class の一部である

RFC は per-domain computation が optimal inter-domain path を保証できず、trapping により diverse paths を見つけられない topology があると明記する。provider は必要条件に応じて LSP ごとに方式を選べる。

end-to-end constraint-based shortest path や経路集合が要求されるとき、PCE-based technique が候補になる。ただし PCE という名称は、完全・最新の graph、正しい SRLG、適切な algorithm を自動で供給しない。

契約に必要なのは製品名ではなく、どの objective を、どの情報範囲と algorithm で計算し、negative result をどの範囲で主張できるかという specification である。

Topology を隠すことと結論を誇張しないこと

RFC 5152 は AS 間で交換する topology information を増やさない。各 domain は内部 graph を保有したまま計算できる。これは confidentiality と運用自律性を守る。

一方、boundary node は path computation work を受ける攻撃面にもなる。許可されない ERO expansion の拒否、bandwidth/priority contract、rate limit、outbound filtering、RSVP authentication と key rotation が必要になる。FRR では PLR と MP の key coordination も関わり得る。

これらは誰の要求を処理したか、どの work が許可されたかを守る。全出口比較、global optimality、pair diversity、recovery 実行、packet delivery の証明とは別である。

各ドメインは経路を改善した。境界の並びは一度も変わらなかった。

なぜ重要か

要約

透明な改善には見えない境界がある

「改善した」は何を変更したのか

経路は signaling の進行とともに確定する

ERO の loose hop は計算権限を委ねる

最初の成功が二本目の失敗条件を作る

crankback は一つ前の選択へ戻る

reachable な出口は pair に最適とは限らない

計算方式は service class の一部である

Topology を隠すことと結論を誇張しないこと

Sources

プロフィールの詳細

Strategic Circle

Leadership Alliance

Strategic Circle 向けブリーフィング

Leadership Alliance 解説