要約

  • RFC 5150 は専用の GMPLS セグメント LSP、S-LSP をつないで一つの e2e LSP を構成する。
  • 一つの S-LSP に関連づけられる e2e LSP は最大一つで、全帯域をその関連に割り当てる。
  • 入口は LSP_ATTRIBUTES のビット 5 でステッチを要求し、出口は RRO の対応する ready ビットを返す。
  • 対応する出口は非 null ラベルを返し、非対応なら Routing Problem 値 30 を使う。
  • ready 応答は区間の参加準備を示すが、後続の e2e 転送状態を証明しない。
  • TE トポロジでは端点が隣接して見えても、データ面の forwarding adjacency は存在しない。
  • e2e の S-LSP hop で交換する Label と Upstream Label は意味を持たず、受信側は無視する。
  • 実際の連続性には両境界のローカル swap と、双方向なら両向きの状態が必要である。
  • e2e RRO はセグメント端点を記録するが、内部ノードとリンクを意図的に記録しない。
  • S-LSP と e2e LSP の teardown は独立し、区間故障後の具体的な回復手順は範囲外である。
  • RSVP 制御保護は通信相手を認証しても、別のデータ経路や利用者トラフィックを検証しない。
  • 能力遮蔽、抽象経路、実行状態、回復、配送には別々の証拠が必要である。

互換性の島を一つの hop に畳む

RFC 5150 は、同じ switching type の e2e LSP と S-LSP を結びつける。同一レイヤーであるため、階層化が使えない場面に適用できる。例の一つは、P2MP 対応 LSR の間に S-LSP を張り、途中のレガシー LSR を P2MP の分岐制御や新しいデータ処理から遮蔽する構成である。

この方法は全ノードの同時更新を避ける。しかし仕様自身が、こうした構成は RSVP P2MP の魅力を制限し得るので慎重に検討すべきだと述べる。互換性を保つために作った区間が、障害解析や機能展開の恒久的な境界になる可能性がある。

e2e RRO には S-LSP TE link の端点識別子を記録する一方、区間内部のノードとリンクは記録しない。旧ノードを隠す目的と、運用証拠から旧ノードが見えない結果は表裏一体である。

ready ビットは出口の参加表明

区間を準備する入口は Path の LSP_ATTRIBUTES に LSP stitching desired ビット 5 を設定する。出口が TLV とビットを認識し、動作を支援できるなら、Resv で非 null ラベルを割り当て、RRO Attributes に LSP segment stitching ready を設定する。

認識していて実行できない場合は、Routing Problem の値 30 Stitching unsupported を返す。オブジェクトを理解しても TLV やビットを理解しない実装は要求を無視できる。入口は戻ったビットを必ず調べ、未設定の S-LSP を使ってはならない。

このやり取りは能力ネゴシエーションとして重要である。ただし出口が「参加できる」と答えた時点の証拠であり、後に選ばれる e2e LSP の境界 swap、内部転送、アプリケーション到達を先取りしない。

意味を持たないラベルが手順をつなぐ

双方向 e2e LSP の Path は S-LSP hop に Upstream Label を載せ、Resv も Label を返す。ところが S-LSP の端点間には forwarding adjacency がない。仕様は任意の値を許し、受信側にこれらを処理しないよう要求する。

階層化の H-LSP では、複数の上位 LSP を区別するラベルが hop 内で意味を持つ。ステッチでは一つの S-LSP に一つの e2e LSPしか入らず、抽象 hop のラベルは直接の転送資源を指さない。

実際の動作は境界で作る。入口が上流 e2e から S-LSP へ swap し、出口が S-LSP から下流 e2e へ swap する。双方向なら逆も必要である。Label オブジェクトの存在を数えるだけでは、最も必要な二つの実行点を確認できない。

TE 上の隣接はデータ上の隣接ではない

S-LSP は TE link として管理・広告でき、その端点は TE トポロジで隣接に見える。実際にはゼロ個以上の中間ノードを通り、データ面で端点同士が直接隣接していない。そのため両端間のデータ資源識別子は意味を持たない。

広告はステッチの必須条件ではない。広告すれば TED を使った経路計算が可能になる一方、リンク状態データベースを増やす。外部ドメインには区間情報が出ず、head end が per-domain や PCE 計算に頼ることもある。

抽象は制御面を縮約するが、物理共有リスクや中間故障を消滅させない。TE 記録、区間内テレメトリ、境界 readback、データ probe を別々に保存する必要がある。

専用帯域は利用者結果ではない

一つの S-LSP は最大一つの e2e LSP に割り当てる。割当後は unreserved bandwidth をゼロにして、別の要求が同じ区間へ入るのを防ぐ。複数の S-LSP を bundle しても、各 component の一対一関係は残る。

これは admission と帳簿の保証である。利用可能帯域の実測、キュー、遅延、物理分離、アプリケーション配送を証明しない。switching type、ERO、帯域、本地 TE policy の一致も選択条件であり、転送結果そのものではない。

区間の作成契機は管理設定またはローカル方針による動的要求である。階層化の region boundary trigger を S-LSP 作成に流用してはならない。自動作成には、誰の方針がどの版で判断したかという出所が必要になる。

teardown は遮蔽された障害を表へ戻す

S-LSP と e2e LSP の RSVP セッションは別で、teardown も独立する。静的区間は e2e 終了後も残り得る。動的区間は未使用になればローカル方針で削除できる。片方が graceful に止まり、もう片方が即時に状態を消すこともある。

S-LSP の削除は関連する e2e LSP の故障として扱い、回復または teardown を起動すべきである。ただし具体的な信号手順は RFC の範囲外である。起動を復旧完了と読み替えてはならない。

動的区間の削除を約 30 秒遅らせる推奨は、複数イベントによる RSVP メッセージ集中を抑えるためで、サービス継続の証明ではない。制御メッセージの認証も同様に、通信隣接の保護とデータ面の実行を分ける。

情報源

  1. RFC 5150（HTML）
  2. RFC 5150（テキスト）
  3. RFC Editor の記録
  4. IETF Datatracker の記録
  5. RFC 5150 の履歴
  6. RFC 5150 の参照関係
  7. RFC 5150 の正誤表
  8. RFC 4206
  9. RFC 3209
  10. RFC 3473
  11. RFC 4420
  12. RFC 3477
  13. RFC 4201
  14. RFC 4203
  15. RFC 4205
  16. RFC 2747
  17. RFC 3032
  18. RFC 5151
  19. IANA RSVP パラメーター
  20. Minimum Initial Specification
  21. On Reality Layers
  22. Running-Code Primacy