<reference title="RSVP-TE: Extensions to RSVP for LSP Tunnels" url="https://www.rfc-editor.org/rfc/rfc3209.txt" rfc="3209" lang="ja" translators="["AI"]" />
RFC 3209
LSP トンネルのための RSVP 拡張 (RSVP-TE: Extensions to RSVP for LSP Tunnels)
本訳文は英文原文 https://www.rfc-editor.org/rfc/rfc3209.txt に基づき逐語訳しており、全セクション・ビット図・コードブロック・表を保持しています。
英文原文メタ情報
- 文書題名：RSVP-TE: Extensions to RSVP for LSP Tunnels
- カテゴリ：Standards Track
- 状態：Proposed Standard
- 著者：D. Awduche, L. Berger, D. Gan, T. Li, V. Srinivasan, G. Swallow
- 日付：2001 年 12 月
文書ヘッダ情報（原文）
Network Working Group D. Awduche
Request for Comments: 3209 Movaz Networks, Inc.
Category: Standards Track L. Berger
D. Gan
Juniper Networks, Inc.
T. Li
Procket Networks, Inc.
V. Srinivasan
Cosine Communications, Inc.
G. Swallow
Cisco Systems, Inc.
December 2001
RSVP-TE: Extensions to RSVP for LSP Tunnels
本メモの状態 (Status of this Memo)
本メモは、インターネットコミュニティ向けのインターネット標準トラックプロトコルを規定し、議論および改善提案を求めている。このプロトコルの標準化状態および位置づけについては、"Internet Official Protocol Standards" (STD 1) の最新版を参照されたい。本メモの配布は無制限である。
著作権表示 (Copyright Notice)
著作権 (C) The Internet Society (2001)。All Rights Reserved.
概要 (Abstract)
本メモは、MPLS (Multi-Protocol Label Switching) においてラベルスイッチドパス (LSP) を確立するための、必要なすべての拡張を含む RSVP (Resource Reservation Protocol) の使用について説明する。LSP に沿ったフローは、パスの入口ノードで適用されるラベルによって完全に識別されるため、これらのパスはトンネルとして扱うことができる。LSP トンネルの主要な応用は、RFC 2702 に規定される MPLS によるトラフィックエンジニアリングである。
我々は、RSVP を拡張するいくつかの追加オブジェクトを提案する。これにより、RSVP をシグナリングプロトコルとして用いて、明示的にルーティングされたラベルスイッチドパスを確立できる。その結果、ネットワーク障害、輻輳、ボトルネックを避けるよう自動的にルーティングできるラベルスイッチドトンネルが実体化される。
目次 (Contents)
- 本メモの状態 (Status of this Memo)
- 著作権表示 (Copyright Notice)
- 概要 (Abstract)
-
- はじめに (Introduction)
- 1.1 背景 (Background)
- 1.2 用語 (Terminology)
-
- 概要 (Overview)
- 2.1 LSP トンネルとトラフィックエンジニアリングトンネル (LSP Tunnels and Traffic Engineered Tunnels)
- 2.2 LSP トンネルの動作 (Operation of LSP Tunnels)
- 2.3 サービスクラス (Service Classes)
- 2.4 予約スタイル (Reservation Styles)
- 2.4.1 固定フィルタ (FF) スタイル (Fixed Filter (FF) Style)
- 2.4.2 ワイルドカードフィルタ (WF) スタイル (Wildcard Filter (WF) Style)
- 2.4.3 共有明示 (SE) スタイル (Shared Explicit (SE) Style)
- 2.5 トラフィックエンジニアリングトンネルの再ルーティング (Rerouting Traffic Engineered Tunnels)
- 2.6 パス MTU (Path MTU)
-
- LSP トンネルに関連するメッセージ形式 (LSP Tunnel related Message Formats)
- 3.1 Path メッセージ (Path Message)
- 3.2 Resv メッセージ (Resv Message)
-
- LSP トンネルに関連するオブジェクト (LSP Tunnel related Objects)
- 4.1 Label オブジェクト (Label Object)
- 4.1.1 Resv メッセージにおける Label オブジェクトの処理 (Handling Label Objects in Resv messages)
- 4.1.2 Label オブジェクトの非サポート (Non-support of the Label Object)
- 4.2 Label Request オブジェクト (Label Request Object)
- 4.2.1 ラベル範囲なしの Label Request (Label Request without Label Range)
- 4.2.2 ATM ラベル範囲付き Label Request (Label Request with ATM Label Range)
- 4.2.3 フレームリレーラベル範囲付き Label Request (Label Request with Frame Relay Label Range)
- 4.2.4 LABEL_REQUEST の処理 (Handling of LABEL_REQUEST)
- 4.2.5 Label Request オブジェクトの非サポート (Non-support of the Label Request Object)
- 4.3 Explicit Route オブジェクト (Explicit Route Object)
- 4.3.1 適用性 (Applicability)
- 4.3.2 Explicit Route オブジェクトの意味論 (Semantics of the Explicit Route Object)
- 4.3.3 サブオブジェクト (Subobjects)
- 4.3.4 Explicit Route オブジェクトの処理 (Processing of the Explicit Route Object)
- 4.3.5 ループ (Loops)
- 4.3.6 前方互換性 (Forward Compatibility)
- 4.3.7 Explicit Route オブジェクトの非サポート (Non-support of the Explicit Route Object)
- 4.4 Record Route オブジェクト (Record Route Object)
- 4.4.1 サブオブジェクト (Subobjects)
- 4.4.2 適用性 (Applicability)
- 4.4.3 RRO の処理 (Processing RRO)
- 4.4.4 ループ検出 (Loop Detection)
- 4.4.5 前方互換性 (Forward Compatibility)
- 4.4.6 RRO の非サポート (Non-support of RRO)
- 4.5 ERO と RRO のエラーコード (Error Codes for ERO and RRO)
- 4.6 Session、Sender Template、Filter Spec オブジェクト (Session, Sender Template, and Filter Spec Objects)
- 4.6.1 Session オブジェクト (Session Object)
- 4.6.2 Sender Template オブジェクト (Sender Template Object)
- 4.6.3 Filter Specification オブジェクト (Filter Specification Object)
- 4.6.4 再ルーティングと帯域増加の手順 (Reroute and Bandwidth Increase Procedure)
- 4.7 Session Attribute オブジェクト (Session Attribute Object)
- 4.7.1 リソースアフィニティなしの形式 (Format without resource affinities)
- 4.7.2 リソースアフィニティ付きの形式 (Format with resource affinities)
- 4.7.3 両方の C-Type に適用される手順 (Procedures applying to both C-Types)
- 4.7.4 リソースアフィニティの手順 (Resource Affinity Procedures)
-
- Hello 拡張 (Hello Extension)
- 5.1 Hello メッセージ形式 (Hello Message Format)
- 5.2 HELLO オブジェクト形式 (HELLO Object formats)
- 5.2.1 HELLO REQUEST オブジェクト (HELLO REQUEST object)
- 5.2.2 HELLO ACK オブジェクト (HELLO ACK object)
- 5.3 Hello メッセージの使用 (Hello Message Usage)
- 5.4 マルチリンクに関する考慮事項 (Multi-Link Considerations)
- 5.5 互換性 (Compatibility)
-
- セキュリティに関する考慮事項 (Security Considerations)
-
- IANA に関する考慮事項 (IANA Considerations)
- 7.1 メッセージタイプ (Message Types)
- 7.2 クラス番号と C-Type (Class Numbers and C-Types)
- 7.3 エラーコードとグローバルに定義されたエラー値サブコード (Error Codes and Globally-Defined Error Value Sub-Codes)
- 7.4 サブオブジェクト定義 (Subobject Definitions)
-
- 知的財産権に関する考慮事項 (Intellectual Property Considerations)
-
- 謝辞 (Acknowledgments)
-
- 参考文献 (References)
-
- 著者のアドレス (Authors' Addresses)
-
- 完全な著作権表示 (Full Copyright Statement)
- 謝辞 (Acknowledgement)
1. はじめに (Introduction)
MPLS アーキテクチャ [2] の 2.9 節では、ラベル分配プロトコルを、あるラベルスイッチングルータ (LSR) が別の LSR に対して、両者間および両者を通過するトラフィックの転送に使用されるラベルの意味を通知する一連の手順として定義している。MPLS アーキテクチャは単一のラベル分配プロトコルを前提としていない。本書は、MPLS ネットワークにおいてラベルスイッチドパス (LSP) を確立するための RSVP の拡張仕様である。
本書で述べる新機能のいくつかは、MPLS 上でのトラフィックエンジニアリングの要求 ([3] 参照) に動機付けられたものである。特に、拡張 RSVP プロトコルは、リソース予約の有無にかかわらず、明示的にルーティングされた LSP の生成をサポートする。また、LSP の円滑な再ルーティング、プリエンプション、およびループ検出もサポートする。
RSVP で作成された LSP は、[3] で述べられている「トラフィックトランク」を運ぶために使用できる。トラフィックトランクを運ぶ LSP とトラフィックトランクは、密接に関連しているが別個の概念である。例えば、同じ送信元と宛先の間の 2 つの LSP を負荷分散して、単一のトラフィックトランクを運ぶことができる。逆に、例えばその LSP が複数のサービスクラスを運ぶことができれば、複数のトラフィックトランクを同じ LSP で運ぶこともできる。これらの拡張の適用可能性については、[10] でさらに論じられている。
ラベルスイッチドパスに沿って流れるトラフィックは、その LSP の入口ノードで付与されるラベルによって定義されるため、これらのパスはトンネルとして扱うことができ、通常の IP ルーティングおよびフィルタリング機構の下層をトンネリングする。LSP がこのように使用される場合、これを LSP トンネルと呼ぶ。
LSP トンネルは、ネットワーク性能の最適化に関連するさまざまなポリシーの実装を可能にする。例えば、LSP トンネルは、ネットワーク障害、輻輳、およびボトルネックを避けるように自動的または手動でルーティングすることができる。さらに、2 つのノード間に複数の並列 LSP トンネルを確立でき、2 つのノード間のトラフィックは、ローカルポリシーに従って LSP トンネルにマッピングできる。トラフィックエンジニアリング (すなわち、運用ネットワークの性能最適化) は本仕様の重要な応用であると期待されているが、拡張 RSVP プロトコルははるかに広い文脈で使用できる。
本書の目的は、LSP トンネルを確立するための RSVP の使用法を記述することである。その意図は、相互運用可能な実装を実現するために必要なすべてのオブジェクト、パケットフォーマット、および手順を完全に記述することにある。LSP トンネルの管理と診断を強化するいくつかの新しいオブジェクトも定義する。
本書はまた、新しい HELLO メッセージによる迅速なノード障害検出の手段についても記述する。
本仕様で記述されるすべてのオブジェクトおよびメッセージは、RSVP に関して任意である。本書では、ここで記述されるオブジェクトがノードでサポートされていない場合に何が起こるかについて論じる。
本書全体を通じて、議論はユニキャストのラベルスイッチドパスに限定する。マルチキャスト LSP は今後の検討課題として残す。
1.1 背景 (Background)
RSVP [1] とマルチプロトコルラベルスイッチング [2] の両方をサポートするホストおよびルータは、ラベルを RSVP フローに関連付けることができる。MPLS と RSVP を組み合わせると、フローの定義をより柔軟にできる。ラベルスイッチドパス (LSP) が確立されると、そのパスを通るトラフィックは、LSP の入口ノードで付与されるラベルによって定義される。ラベルからトラフィックへのマッピングは、多数の異なる基準を用いて行うことができる。特定のノードによって同じラベル値が割り当てられたパケットの集合は、同じ転送等価クラス (FEC) に属すると言われ ([2] 参照)、実質的に「RSVP フロー」を定義する。トラフィックがこのようにラベルスイッチドパスにマッピングされる場合、その LSP を「LSP トンネル」と呼ぶ。ラベルがトラフィックフローに関連付けられると、ルータはパケットのラベル値に基づいてそのパケットに適切な予約状態を識別することが可能になる。
シグナリングプロトコルモデルは、下流オンデマンドのラベル分配を使用する。特定の LSP トンネルにラベルをバインドする要求は、入口ノードによって RSVP Path メッセージを通じて開始される。この目的のために、RSVP Path メッセージは LABEL_REQUEST オブジェクトで拡張される。ラベルは下流で割り当てられ、RSVP Resv メッセージによって分配される (上流へ伝播される)。この目的のために、RSVP Resv メッセージは特別な LABEL オブジェクトで拡張される。ラベルの割り当て、分配、バインド、およびスタッキングの手順は、本書の後続の節で記述される。
シグナリングプロトコルモデルは、明示的ルーティング機能もサポートする。これは、単純な EXPLICIT_ROUTE オブジェクトを RSVP Path メッセージに組み込むことによって実現される。EXPLICIT_ROUTE オブジェクトは、明示的にルーティングされたパスを構成するホップの連結をカプセル化する。このオブジェクトを使用すると、ラベルスイッチされた RSVP-MPLS フローがたどるパスを、従来の IP ルーティングとは独立に事前決定することができる。明示的にルーティングされたパスは、管理上指定することも、QoS およびポリシーの要件に基づいて適切なエンティティが、支配的なネットワーク状態を考慮して自動的に計算することもできる。一般に、パス計算は制御駆動型でもデータ駆動型でもよい。明示的にルーティングされたパスを計算するために使用される機構、プロセス、およびアルゴリズムは、本仕様の範囲外である。
明示的ルーティングの有用な応用の 1 つは、トラフィックエンジニアリングである。明示的にルーティングされた LSP を使用すると、MPLS ドメインの入口エッジにあるノードは、それ自体から MPLS ネットワークを通って出口ノードへトラフィックが通過するパスを制御できる。明示的ルーティングは、ネットワークリソースの利用を最適化し、トラフィック指向の性能特性を向上させるために使用できる。
明示的にルーティングされたラベルスイッチドパスの概念は、抽象ノードの概念によって一般化できる。抽象ノードとは、その内部トポロジが LSP の入口ノードにとって不透明であるノードのグループである。抽象ノードは、単一の物理ノードのみを含む場合、単純であると言われる。この抽象化の概念を用いると、明示的にルーティングされた LSP を IP プレフィックスの系列または自律システムの系列として指定できる。
シグナリングプロトコルモデルは、明示的パスを厳密 (strict) ルートおよび緩和 (loose) ルートの系列として指定することをサポートする。抽象ノードと、厳密 (strict) ルートおよび緩和 (loose) ルートの組み合わせは、パス定義の柔軟性を大幅に高める。
LSP トンネルを確立するために RSVP を使用する利点は、パスに沿ってリソースを割り当てることが可能になることである。例えば、標準の RSVP 予約および Integrated Services のサービスクラス [4] を使用して、帯域幅を LSP トンネルに割り当てることができる。
リソース予約は有用であるが、必須ではない。実際、LSP はリソース予約をまったく行わずに生成できる。リソース予約を伴わないこのような LSP は、例えばベストエフォートトラフィックを運ぶために使用できる。また、障害発生時のフォールバックおよびリカバリポリシーの実装など、他の多くの文脈で使用できる。
1.2 用語 (Terminology)
本書におけるキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は、RFC2119 [6] に記述されているとおりに解釈されるものとする。
読者は [1]、[2]、および [3] の用語に精通していることを前提とする。
Abstract Node（抽象ノード）
その内部トポロジが LSP の入口ノードにとって不透明であるノードのグループ。抽象ノードは、単一の物理ノードのみを含む場合、単純であると言われる。
Explicitly Routed LSP（明示的にルーティングされた LSP）
通常の IP ルーティング以外の手段によってパスが確立される LSP。
Label Switched Path（ラベルスイッチドパス）
1 つ以上のラベルスイッチドホップの連結によって作成されるパスであり、MPLS ノードから別の MPLS ノードへラベルをスワップすることによってパケットを転送できるようにする。より正確な定義については [2] を参照。
LSP
ラベルスイッチドパス
LSP Tunnel（LSP トンネル）
通常の IP ルーティングおよび/またはフィルタリング機構の下層をトンネリングするために使用される LSP。
Traffic Engineered Tunnel (TE Tunnel)（トラフィックエンジニアリングトンネル (TE トンネル)）
トラフィックトランクを運ぶ 1 つ以上の LSP トンネルの集合。
Traffic Trunk（トラフィックトランク）
サービスクラスによって集約され、次いでトラフィックエンジニアリングトンネルと呼ばれる LSP または LSP の集合上に配置されるフローの集合。さらなる議論については [3] を参照。
2. 概要 (Overview)
2.1 LSP トンネルとトラフィックエンジニアリングトンネル (LSP Tunnels and Traffic Engineered Tunnels)
[1] によれば、「RSVP は『セッション』を、特定の宛先とトランスポート層プロトコルを持つデータフローであると定義する」。しかしながら、RSVP と MPLS を組み合わせると、フローすなわちセッションを、より大きな柔軟性と一般性をもって定義できる。LSP の入口ノードは、どのパケットに特定のラベルを割り当てるかを決定するために、さまざまな手段を用いることができる。一度ラベルがパケットの集合に割り当てられると、そのラベルは LSP を通る「フロー」を実効的に定義する。このような LSP を我々は「LSP トンネル」と呼ぶ。それは、その中を通るトラフィックが、ラベルスイッチドパスに沿った中間ノードにとって不透明であるからである。
LSP トンネル機能をサポートするために、LSP_TUNNEL_IPv4 および LSP_TUNNEL_IPv6 と呼ばれる新しい RSVP の SESSION、SENDER_TEMPLATE、および FILTER_SPEC オブジェクトが定義されている。ラベルスイッチドパスに沿ったノードの観点から見たこれらのオブジェクトの意味は、LSP トンネルに属するトラフィックが、PHOP すなわち「前のホップ」(previous hop)（[1] を参照）から到着し、このノードがそのセッションへの上流の送信者に割り当てた特定のラベル値を伴うパケットのみに基づいて識別される、というものである。実際には、オブジェクト名に現れる IPv4(v6) は、宛先アドレスが IPv4(v6) アドレスであることを示しているにすぎない。これらのオブジェクトを総称して指す場合、我々は修飾子 LSP_TUNNEL を用いる。
一部のアプリケーションでは、LSP トンネルの集合を関連付けることが有用である。これは再ルーティング操作の間に、あるいはトラフィックトランクを複数のパスに分散させるために有用でありうる。トラフィックエンジニアリングのアプリケーションでは、そのような集合はトラフィックエンジニアリングトンネル (TE トンネル) と呼ばれる。そのような LSP トンネルの識別と関連付けを可能にするために、2 つの識別子が運ばれる。トンネル ID は SESSION オブジェクトの一部である。SESSION オブジェクトはトラフィックエンジニアリングトンネルを一意に定義する。SENDER_TEMPLATE および FILTER_SPEC オブジェクトは LSP ID を運ぶ。SENDER_TEMPLATE（または FILTER_SPEC）オブジェクトは SESSION オブジェクトとともに、LSP トンネルを一意に識別する。
2.2 LSP トンネルの動作 (Operation of LSP Tunnels)
本節では、LSP トンネルの動作に関して、本文書によって拡張された RSVP がサポートする機能のいくつかを要約する。それらには以下が含まれる。(1) QoS 要件の有無にかかわらず LSP トンネルを確立する能力、(2) 確立された LSP トンネルを動的に再ルーティングする能力、(3) 確立された LSP トンネルが実際にたどる経路を観測する能力、(4) LSP トンネルを識別および診断する能力、(5) 管理ポリシーの制御の下で確立された LSP トンネルをプリエンプトする能力、および (6) 下流オンデマンド (downstream-on-demand) のラベル割り当て、配布、およびバインディングを実行する能力。以下の段落では、これらの機能を簡単に説明する。より詳細な説明は、本文書の以降の節にある。
LSP トンネルを作成するために、パス上の最初の MPLS ノード、すなわちそのパスに関する送信者ノードは、セッションタイプが LSP_TUNNEL_IPv4 または LSP_TUNNEL_IPv6 である RSVP Path メッセージを作成し、LABEL_REQUEST オブジェクトを Path メッセージに挿入する。LABEL_REQUEST オブジェクトは、このパスに対するラベルバインディングが要求されていることを示し、またこのパス上で運ばれるべきネットワーク層プロトコルの指示を与える。その理由は、LSP に沿って送られるネットワーク層プロトコルは IP であると仮定できず、また、上位層プロトコルを単に MPLS として識別するだけの L2 ヘッダから推測することもできないからである。
送信者ノードが、トンネルの QoS 要件を満たす可能性が高い経路、あるいはネットワーク資源を効率的に利用する経路、あるいは何らかのポリシー基準を満たす経路を知っている場合、そのノードはその経路を自身のセッションの一部または全部に使用すると決定できる。これを行うために、送信者ノードは RSVP Path メッセージに EXPLICIT_ROUTE オブジェクトを追加する。EXPLICIT_ROUTE オブジェクトは、経路を抽象ノードの系列として指定する。
セッションが正常に確立された後に送信者ノードがより良い経路を発見した場合、送信者は単に EXPLICIT_ROUTE オブジェクトを変更することによって、そのセッションを動的に再ルーティングできる。EXPLICIT_ROUTE オブジェクトに問題が生じた場合、それがルーティングループを引き起こすためであれ、一部の中間ルータがそれをサポートしていないためであれ、送信者ノードに通知される。
Path メッセージに RECORD_ROUTE オブジェクトを追加することにより、送信者ノードは LSP トンネルが実際にたどる経路に関する情報を受け取ることができる。送信者ノードはまた、このオブジェクトを用いて、ルーティングパスの変更に関する通知をネットワークから要求することができる。RECORD_ROUTE オブジェクトはパスベクトルに類似しており、したがってループ検出に使用できる。
最後に、セッションの識別と診断を助けるために、SESSION_ATTRIBUTE オブジェクトを Path メッセージに追加できる。セットアップ優先度および保持優先度、リソースアフィニティ（[3] を参照）、ローカル保護といった追加の制御情報も、このオブジェクトに含まれる。
パスに沿ったルータは、セットアップ優先度および保持優先度を、SENDER_TSPEC および Path メッセージに含まれるあらゆる POLICY_DATA オブジェクトとともに、ポリシー制御への入力として使用してもよい。例えば、トラフィックエンジニアリングのアプリケーションでは、より低い優先度の予約をプリエンプトする前に、パス全体にわたって特定の優先度の帯域幅が存在することを検証する手段として Path メッセージを使用することが非常に有用である。資源が不十分なときに Path メッセージの進行が許可されると、この地点より下流のより低い優先度の予約が、この要求に応えようとする無駄な試みの中で不必要にプリエンプトされる危険がある。
EXPLICIT_ROUTE オブジェクト (ERO) が存在する場合、Path メッセージは ERO によって指定された経路に沿って宛先へ向けて転送される。パスに沿った各ノードは、自身のパス状態ブロックに ERO を記録する。ノードはまた、Path メッセージを転送する前に ERO を変更してもよい。この場合、変更後の ERO は、受信した ERO に加えて、パス状態ブロックに格納されるべきである (SHOULD)。
LABEL_REQUEST オブジェクトは、中間ルータおよび受信者ノードに対して、そのセッションのラベルバインディングを提供するよう要求する。ノードがラベルバインディングを提供できない場合、そのノードは "unknown object class" エラーを伴う PathErr メッセージを送信する。LABEL_REQUEST オブジェクトがエンドツーエンドでサポートされていない場合、送信者ノードは、このサポートを提供しない最初のノードによって通知される。
ラベルスイッチドパスの宛先ノードは、LABEL_REQUEST に応答して、応答の RSVP Resv メッセージに LABEL オブジェクトを含める。LABEL オブジェクトは、それが関係するフィルタスペックの直後にフィルタスペックリスト内へ挿入される。
Resv メッセージは、Path メッセージによって作成されたパス状態に従い、逆順で送信者へ向けて上流に送り返される。パス状態が ERO の使用によって作成された場合、Resv メッセージは ERO の逆のパスをたどることに注意する。
LABEL オブジェクトを含む Resv メッセージを受信した各ノードは、この LSP トンネルに関連する発信トラフィックに対してそのラベルを使用する。そのノードが送信者でない場合、ノードは新しいラベルを割り当て、そのラベルを、自身が PHOP へ上流に送信する Resv メッセージの対応する LABEL オブジェクトに格納する。LABEL オブジェクト内で上流に送られるラベルは、このノードがこの LSP トンネルに関連する着信トラフィックを識別するために使用するラベルである。このラベルはまた、フィルタスペックの略記としても機能する。これでノードは、着信するラベル付きパケットを "Next Hop Label Forwarding Entry" (NHLFE) にマップするために使用される自身の "Incoming Label Map" (ILM) を更新できる（[2] を参照）。
Resv メッセージが送信者ノードへ上流に伝搬すると、ラベルスイッチドパスが実効的に確立される。
2.3 サービスクラス (Service Classes)
本文書は、予約のための統合サービスの要求のタイプを制限しない。しかしながら、実装は Controlled-Load サービス [4] および Null サービス [16] をサポートすべきである (SHOULD)。
2.4 予約スタイル (Reservation Styles)
受信者ノードは、セッションごとに、可能な予約スタイルの集合の中から選択でき、各 RSVP セッションは特定のスタイルを持たなければならない。送信者は予約スタイルの選択に影響を持たない。受信者は、異なる LSP に対して異なる予約スタイルを選択できる。
RSVP セッションは、選択された予約スタイルに応じて、1 つまたは複数の LSP をもたらしうる。
FF のようないくつかの予約スタイルは、特定の予約を個々の送信者ノードに専用に割り当てる。WF や SE のような他の予約スタイルは、複数の送信者ノード間で予約を共有できる。以下の節では、さまざまな予約スタイルとそれらの利点および欠点を論じる。予約スタイルに関するより詳細な議論は [1] にある。
2.4.1 固定フィルタ (FF) スタイル (Fixed Filter (FF) Style)
固定フィルタ (FF) 予約スタイルは、他の送信者と共有されない、各送信者からのトラフィックに対する個別の予約を作成する。このスタイルは、各送信者からのトラフィックが同時並行的かつ独立である可能性が高いアプリケーションで一般的である。FF を使用するセッションについてリンク上で予約される帯域幅の総量は、個々の送信者に対する予約の合計である。
各送信者が自身の予約を持つため、各送信者に一意のラベルが割り当てられる。これは、すべての送信者/受信者ペアの間のポイントツーポイント LSP をもたらしうる。
2.4.2 ワイルドカードフィルタ (WF) スタイル (Wildcard Filter (WF) Style)
ワイルドカードフィルタ (WF) 予約スタイルでは、セッションへのすべての送信者に対して単一の共有予約が使用される。リンク上の総予約は、送信者の数にかかわらず同じままである。
セッションへのすべての送信者に対して、単一の多点対点ラベルスイッチドパスが作成される。セッションへの送信者が共有するリンク上では、単一のラベル値がそのセッションに割り当てられる。送信者が 1 つだけの場合、LSP は通常のポイントツーポイント接続のように見える。複数の送信者が存在する場合、多点対点 LSP（逆ツリー）が作成される。
このスタイルは、すべての送信者が同時にトラフィックを送信するわけではないアプリケーションに有用である。例えば電話会議は、すべての話者が同時に話すわけではないアプリケーションである。しかしながら、すべての送信者が同時に送信する場合、適切な予約を行わせる手段がない。宛先に近いリンク上の予約帯域幅が必要な量より少なくなるか、そうでなければ一部の送信者に近いリンク上の予約帯域幅が必要な量より大きくなる。これは、トラフィックエンジニアリングの目的に対する WF の適用可能性を制限する。
さらに、WF のマージ規則のために、EXPLICIT_ROUTE オブジェクトを WF 予約とともに使用することはできない。この問題およびトラフィックエンジニアリングへの適用可能性の欠如の結果として、本文書では WF の使用は考慮しない。
2.4.3 共有明示 (SE) スタイル (Shared Explicit (SE) Style)
共有明示 (SE) スタイルは、受信者が予約に含める送信者を明示的に指定することを可能にする。列挙されたすべての送信者に対して、リンク上に単一の予約が存在する。各送信者が Resv メッセージ内に明示的に列挙されるため、異なる送信者に異なるラベルを割り当てることができ、それによって別個の LSP が作成される。
SE スタイルの予約は、多点対点ラベルスイッチドパスまたは送信者ごとの LSP を用いて提供できる。多点対点 LSP は、Path メッセージが EXPLICIT_ROUTE オブジェクトを運ばない場合、または Path メッセージが同一の EXPLICIT_ROUTE オブジェクトを持つ場合に使用してもよい。これらのいずれの場合でも、共通のラベルを割り当ててもよい。
異なる送信者からの Path メッセージは、それぞれが自身の ERO を運ぶことができ、送信者がたどるパスはネットワークトポロジ内の任意の地点で合流し、また分岐しうる。Path メッセージが異なる EXPLICIT_ROUTE オブジェクトを持つ場合、EXPLICIT_ROUTE オブジェクトごとに別個の LSP を確立しなければならない。
2.5 トラフィックエンジニアリングトンネルの再ルーティング (Rerouting Traffic Engineered Tunnels)
トラフィックエンジニアリングの要件の 1 つは、管理ポリシーに基づき、いくつかの条件下で確立された TE トンネルを再ルーティングする能力である。例えば、ある状況では、より「最適な」経路が利用可能になったときに、所与の TE トンネルを再ルーティングすべきであると管理ポリシーが定めることがある。TE トンネルの再ルーティングが通常必要とされるもう 1 つの重要な状況は、TE トンネルの確立されたパスに沿った資源の障害が発生したときである。一部のポリシーでは、障害のあった資源が再び有効になったときに TE トンネルを元のパスに戻すことが必要となることもある。
一般に、TE トンネルの再ルーティングの進行中にトラフィックを中断させたり、ネットワーク運用に悪影響を与えたりしないことが非常に望ましい。この適応的かつ円滑な再ルーティングの要件は、新しい LSP トンネルを確立し、古い LSP トンネルを撤去する前にトラフィックを古い LSP トンネルから新しい LSP トンネルへ移すことを必要とする。この概念は「make-before-break」と呼ばれる。古い LSP トンネルと新しい LSP トンネルが、それらが共通に持つネットワーク区間上の資源を互いに奪い合う可能性があるために、問題が生じうる。資源の可用性に応じて、この競合はアドミッション制御が新しい LSP トンネルの確立を妨げる原因となりうる。LSP トンネルを確立するために RSVP を使用することの利点は、この問題を非常にエレガントに解決することである。
円滑な方法で make-before-break をサポートするには、古い LSP と新しい LSP に共通のリンク上で、古い LSP トンネルによって使用されている資源が、トラフィックが新しい LSP トンネルへ移行される前に解放されるべきではなく (SHOULD NOT)、また予約が二重に計上されるべきではない (SHOULD NOT)。それは、アドミッション制御が新しい LSP トンネルを拒否する原因となりうるからである。
同様の状況は、TE トンネルの帯域幅を増やしたいときにも生じうる。新しい予約は必要な全量に対するものとなるが、実際に必要な割り当ては新しい帯域幅と古い帯域幅の差分にすぎない。中間ノードによって PATH メッセージにポリシーが適用されている場合、過大な帯域幅を要求する PATH メッセージは拒否される。この状況では、SENDER_TEMPLATE を変更せずに帯域幅要求を単に増やすと、ローカルポリシーによってはトンネルが撤去される結果となりうる。
LSP_TUNNEL SESSION オブジェクトと SE 予約スタイルの組み合わせは、帯域幅とルーティングの円滑な遷移を自然に収容する。その考え方は、古い LSP トンネルと新しい LSP トンネルが、それらが共通に持つリンクに沿って資源を共有する、というものである。LSP_TUNNEL SESSION オブジェクトは、RSVP セッションの範囲を、問題となっている特定の TE トンネルに絞り込むために使用される。TE トンネルを一意に識別するために、我々は宛先 IP アドレス（トンネルの出口であるノードのアドレス）、トンネル ID、および Extended Tunnel ID フィールドに置かれるトンネル入口ノードの IP アドレスの組み合わせを使用する。
再ルーティングまたは帯域幅増加の操作の間、トンネル入口は RSVP セッションに対して 2 つの異なる送信者として見える必要がある。これは、SENDER_TEMPLATE および FILTER_SPEC オブジェクトで運ばれる「LSP ID」を含めることによって達成される。これらのオブジェクトの意味が変更されるため、新しい C-Type が割り当てられる。
再ルーティングを実行するために、入口ノードは新しい LSP ID を選び、新しい SENDER_TEMPLATE を形成する。次に入口ノードは、新しいパスを定義する新しい ERO を作成する。その後、ノードは元の SESSION オブジェクトと新しい SENDER_TEMPLATE および ERO を用いて新しい Path メッセージを送信する。ノードは古い LSP を使用し続け、古い Path メッセージをリフレッシュする。共通に保持されていないリンク上では、新しい Path メッセージは従来の新しい LSP トンネルのセットアップとして扱われる。共通に保持されているリンク上では、共有された SESSION オブジェクトと SE スタイルにより、LSP は古い LSP と資源を共有して確立されることが可能になる。入口ノードが新しい LSP に対する Resv メッセージを受信すると、ノードはトラフィックをそれへ移行し、古い LSP を撤去できる。
帯域幅増加を実行するために、新しい LSP_ID を持つ新しい Path メッセージを使用して、より大きな帯域幅の予約を試みることができる。その間、現在の LSP_ID はリフレッシュされ続け、より大きな予約が失敗した場合に予約が失われないことを保証する。
2.6 パス MTU (Path MTU)
標準の RSVP [1] および Int-Serv [11] は、RSVP 送信者に対して、送信者と受信者の間で利用可能な最小 MTU を提供する。このパス MTU 識別能力は、RSVP を介して確立される LSP に対しても提供される。
パス MTU 情報は、どちらが存在するかに応じて、統合サービスオブジェクトまたは Null サービスオブジェクト内で運ばれる。統合サービスオブジェクトを使用する場合、パス MTU は [11] で定義される手順に基づいて提供される。Null サービスオブジェクトを使用する場合のパス MTU 識別は [16] で定義されている。
標準の RSVP では、パス MTU 情報は、どの IP パケットがパス MTU を超えているかを確認するために送信者によって使用される。パス MTU を超えるパケットについて、送信者はパケットをフラグメント化するか、IP データグラムに "Don't Fragment" ビットが設定されている場合には、ICMP 宛先到達不能メッセージを発行する。このパス MTU に関連する扱いも、RSVP を介して確立される LSP に対して要求される。
以下のアルゴリズムは、すべてのラベルなし IP データグラム、およびノードが IP データグラムであると認識しており転送前にラベルを追加する必要がある任意のラベル付きパケットに適用される。ラベル付きパケットについては、スタックの底 (bottom of stack) を求め、IP ヘッダを検査する。
[5] で定義される用語を用いて、LSR は以下のアルゴリズムを実行しなければならない (MUST)。
-
N を、このノードが追加するラベルを含めたラベルスタック内のバイト数（すなわち、ラベルスタックエントリ数の 4 倍）とする。
-
M を、"Maximum Initially Labeled IP Datagram Size" または (Path MTU - N) のうち小さい方とする。
IPv4 データグラム（ラベルなし）のサイズが M の値を超える場合、
IPv4 ヘッダで DF ビットが設定されていない場合は、次のとおりである。
- (a) データグラムは、そのそれぞれのサイズが M を超えない断片に分割されなければならない (MUST)、および
- (b) 各断片はラベル付けされた後、転送されなければならない (MUST)。
IPv4 ヘッダで DF ビットが設定されている場合は、次のとおりである。
- (a) データグラムは転送されてはならない (MUST NOT)
- (b) ICMP Destination Unreachable Message を作成する:
- i. その Code フィールド [12] を "Fragmentation Required and DF Set" に設定し、
- ii. その Next-Hop MTU フィールド [13] を M に設定する
- (c) 可能であれば、廃棄されたデータグラムの送信元へ ICMP Destination Unreachable Message を送信する。
IPv6 データグラム（ラベルなし）のサイズが M の値を超える場合は、次のとおりである。
- (a) データグラムは転送されてはならない (MUST NOT)
- (b) Next-Hop link MTU フィールド [14] を M に設定した ICMP Packet too Big Message を作成する
- (c) 可能であれば、廃棄されたデータグラムの送信元へ ICMP Packet too Big Message を送信する。
3. LSP トンネルに関連するメッセージ形式 (LSP Tunnel related Message Formats)
この節では 5 つの新しいオブジェクトを定義する。
Object name Applicable RSVP messages
--------------- ------------------------
LABEL_REQUEST Path
LABEL Resv
EXPLICIT_ROUTE Path
RECORD_ROUTE Path, Resv
SESSION_ATTRIBUTE Path
SESSION、SENDER_TEMPLATE、FILTER_SPEC オブジェクト用にも新しい C-Type が割り当てられる。
新しいオブジェクトの詳細な説明は後の節で与える。すべての新しいオブジェクトは RSVP に関して任意である (OPTIONAL)。実装はオブジェクトのサブセットをサポートすることを選択できる。しかし、LABEL_REQUEST オブジェクトと LABEL オブジェクトは本仕様に関して必須である。
LABEL オブジェクトと RECORD_ROUTE オブジェクトは、送信者固有である。Resv メッセージ内では、これらは対応する FILTER_SPEC の後に、かつ後続の FILTER_SPEC より前に現れなければならない (MUST)。
EXPLICIT_ROUTE、LABEL_REQUEST、SESSION_ATTRIBUTE オブジェクトの相対的な配置は、単なる推奨である。これらのオブジェクトの順序は重要ではないので、実装はいかなる順序でもオブジェクトを受け入れる用意がなければならない (MUST)。
3.1 Path メッセージ (Path Message)
Path メッセージの形式は以下のとおりである。
<Path Message> ::= <Common Header> [ <INTEGRITY> ]
<SESSION> <RSVP_HOP>
<TIME_VALUES>
[ <EXPLICIT_ROUTE> ]
<LABEL_REQUEST>
[ <SESSION_ATTRIBUTE> ]
[ <POLICY_DATA> ... ]
<sender descriptor>
<sender descriptor> ::= <SENDER_TEMPLATE> <SENDER_TSPEC>
[ <ADSPEC> ]
[ <RECORD_ROUTE> ]
3.2 Resv メッセージ (Resv Message)
Resv メッセージの形式は以下のとおりである。
<Resv Message> ::= <Common Header> [ <INTEGRITY> ]
<SESSION> <RSVP_HOP>
<TIME_VALUES>
[ <RESV_CONFIRM> ] [ <SCOPE> ]
[ <POLICY_DATA> ... ]
<STYLE> <flow descriptor list>
<flow descriptor list> ::= <FF flow descriptor list>
| <SE flow descriptor>
<FF flow descriptor list> ::= <FLOWSPEC> <FILTER_SPEC>
<LABEL> [ <RECORD_ROUTE> ]
| <FF flow descriptor list>
<FF flow descriptor>
<FF flow descriptor> ::= [ <FLOWSPEC> ] <FILTER_SPEC> <LABEL>
[ <RECORD_ROUTE> ]
<SE flow descriptor> ::= <FLOWSPEC> <SE filter spec list>
<SE filter spec list> ::= <SE filter spec>
| <SE filter spec list> <SE filter spec>
<SE filter spec> ::= <FILTER_SPEC> <LABEL> [ <RECORD_ROUTE> ]
注: LABEL と RECORD_ROUTE（存在する場合）は、先行する FILTER_SPEC にバインドされる。各 FILTER_SPEC に続くことができる LABEL および RECORD_ROUTE は 1 つ以下である。
4. LSP トンネルに関連するオブジェクト (LSP Tunnel related Objects)
4.1 Label オブジェクト (Label Object)
ラベルは Resv メッセージ内で運ばれてもよい (MAY)。FF スタイルと SE スタイルでは、ラベルは各送信者に関連付けられる。ある送信者に対するラベルは、Resv メッセージ内でその送信者に対する FILTER_SPEC の直後に続かなければならない (MUST)。
LABEL オブジェクトは以下の形式を持つ。
LABEL class = 16, C_Type = 1
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| (top label) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
LABEL の内容は、4 オクテットで符号化された単一のラベルである。各汎用 MPLS ラベルは、0 から 1048575 の範囲の符号なし整数である。汎用 MPLS ラベルと FR ラベルは、4 オクテット内で右詰めで符号化される。ATM ラベルは、VPI をビット 0-15 に右詰めで、VCI をビット 16-31 に右詰めで符号化される。
4.1.1 Resv メッセージにおける Label オブジェクトの処理 (Handling Label Objects in Resv messages)
MPLS では、ノードは複数のラベル空間をサポートしてもよく、おそらく各入力インターフェースに固有の空間を関連付ける。以下の議論では、「同一のラベル (same label)」という用語は、同一のラベル空間から取られた同一のラベル値を意味する。さらに、以下はユニキャストセッションにのみ適用される。
異なるインターフェース上で Resv メッセージ内で受信されたラベルは、ラベル値が同じであっても、常に異なるものと見なされる。
4.1.1.1 下流 (Downstream)
下流ノードは、フローを表すラベルを選択する。ラベル要求でラベル範囲が指定されている場合、ラベルはその範囲から取られなければならない (MUST)。利用可能なラベルがない場合、ノードはエラーコード「routing problem」およびエラー値「label allocation failure」を持つ PathErr メッセージを送信する。
ノードが、複数の送信者に同じラベル値を割り当てた Resv メッセージを受信した場合、そのノードはそれらの同じ送信者、またはそれらの送信者の任意のサブセットに単一の値を割り当ててもよい (MAY)。ノードがセッション内の個々の送信者をポリシングする意図を持つ場合、それらの送信者に一意のラベルを割り当てなければならない (MUST) ことに注意する。
ATM の場合、さらに 1 つの条件が適用される。一部の ATM ノードはストリームのマージができない。これらのノードは、ラベル要求内の 1 ビットをゼロに設定することによってこれを示してもよい (MAY)。C-Type 2 の LABEL_REQUEST オブジェクト、すなわち ATM ラベル範囲付きラベル要求、内の M ビットがこの目的を果たす。M ビットは、マージ可能なノードによって設定されるべきである (SHOULD)。いずれかの送信者について M ビットが設定されていない場合、下流ノードはそれらの送信者に一意のラベルを割り当てなければならない (MUST)。
ラベルが一度割り当てられると、ノードは新しい LABEL オブジェクトをフォーマットする。次にノードは、Resv メッセージの一部として新しい LABEL オブジェクトを前のホップへ送信する。ノードは、Resv メッセージを送信する前に、割り当てられたラベルを運ぶパケットを転送する用意ができているべきである (SHOULD)。LABEL オブジェクトは予約状態ブロック (Reservation State Block) に保持されるべきである (SHOULD)。その後、Resv メッセージをフォーマットするための次の Resv リフレッシュイベントで使用される。
LABEL オブジェクトの内容が変化した場合、ノードは自身のリフレッシュタイマーが満了する前に Resv メッセージを送信することが期待される。
4.1.1.2 上流 (Upstream)
ノードは、LABEL オブジェクト内で運ばれたラベルを、送信者に関連付けられた出力ラベルとして使用する。ルータは新しいラベルを割り当て、それをこのセッション/送信者の入力インターフェースにバインドする。これは、ルータが Resv メッセージを前のホップへ転送するために使用するのと同じインターフェースである。
いくつかの状況が、受け入れられないラベルにつながる可能性がある。
-
ノードはマージ不能な ATM スイッチであるが、下流ノードが 2 つの送信者に同じラベルを割り当てている
-
暗黙ヌルラベルが割り当てられたが、ノードは関連する L3PID に対してペナルティメイトポップ (penultimate pop) を行うことができない
-
割り当てられたラベルが要求されたラベル範囲外である
これらのいずれかの事象では、ノードはエラーコード「routing problem」およびエラー値「unacceptable label value」を持つ ResvErr メッセージを送信する。
4.1.2 Label オブジェクトの非サポート (Non-support of the Label Object)
通常の状況では、ノードは、対応する Path メッセージに LABEL_REQUEST オブジェクトを含めていなかった限り、Resv メッセージ内で LABEL オブジェクトを受信すべきではない。しかし、LABEL オブジェクトを認識しない RSVP ルータは、エラーコード「Unknown object class」を持つ ResvErr を受信者へ向けて送信する。これにより、予約は失敗する。
4.2 Label Request オブジェクト (Label Request Object)
Label Request クラスは 19 である。現在、3 つの可能な C_Type が存在する。タイプ 1 はラベル範囲なしの Label Request である。タイプ 2 は ATM ラベル範囲付きのラベル要求である。タイプ 3 はフレームリレーラベル範囲付きのラベル要求である。LABEL_REQUEST オブジェクトの形式を以下に示す。
4.2.1 ラベル範囲なしの Label Request (Label Request without Label Range)
Class = 19, C_Type = 1
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | L3PID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Reserved
このフィールドは予約済みである。送信時にはゼロに設定しなければならず (MUST)、受信時には無視しなければならない (MUST)。
L3PID
この経路を使用するレイヤ 3 プロトコルの識別子。標準の Ethertype 値が使用される。
4.2.2 ATM ラベル範囲付き Label Request (Label Request with ATM Label Range)
Class = 19, C_Type = 2
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | L3PID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|M| Res | Minimum VPI | Minimum VCI |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Res | Maximum VPI | Maximum VCI |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Reserved (Res)
このフィールドは予約済みである。送信時にはゼロに設定しなければならず (MUST)、受信時には無視しなければならない (MUST)。
L3PID
この経路を使用するレイヤ 3 プロトコルの識別子。標準の Ethertype 値が使用される。
M
このビットを 1 に設定することは、ノードがデータプレーンでマージ可能であることを示す。
Minimum VPI (12 bits)
この 12 ビットのフィールドは、発信スイッチでサポートされる Virtual Path Identifier のブロックの下限を指定する。VPI が 12 ビット未満の場合、このフィールド内で右詰めにしなければならず (MUST)、先行するビットはゼロに設定しなければならない (MUST)。
Minimum VCI (16 bits)
この 16 ビットのフィールドは、発信スイッチでサポートされる Virtual Connection Identifier のブロックの下限を指定する。VCI が 16 ビット未満の場合、このフィールド内で右詰めにしなければならず (MUST)、先行するビットはゼロに設定しなければならない (MUST)。
Maximum VPI (12 bits)
この 12 ビットのフィールドは、発信スイッチでサポートされる Virtual Path Identifier のブロックの上限を指定する。VPI が 12 ビット未満の場合、このフィールド内で右詰めにしなければならず (MUST)、先行するビットはゼロに設定しなければならない (MUST)。
Maximum VCI (16 bits)
この 16 ビットのフィールドは、発信スイッチでサポートされる Virtual Connection Identifier のブロックの上限を指定する。VCI が 16 ビット未満の場合、このフィールド内で右詰めにしなければならず (MUST)、先行するビットはゼロに設定しなければならない (MUST)。
4.2.3 フレームリレーラベル範囲付き Label Request (Label Request with Frame Relay Label Range)
Class = 19, C_Type = 3
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | L3PID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved |DLI| Minimum DLCI |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | Maximum DLCI |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Reserved（予約済み）
このフィールドは予約済みである。送信時にはゼロに設定しなければならず (MUST)、受信時には無視しなければならない (MUST)。
L3PID
このパスを使用するレイヤ 3 プロトコルの識別子。標準の Ethertype 値が使用される。
DLI
DLCI Length Indicator。DLCI のビット数。以下の値がサポートされる。
Len DLCI bits
0 10
2 23
Minimum DLCI
この 23 ビットフィールドは、発信スイッチ上でサポートされる Data Link Connection Identifier (DLCI) のブロックの下限を指定する。DLCI はこのフィールド内で右詰めにしなければならず (MUST)、未使用ビットは 0 に設定しなければならない (MUST)。
Maximum DLCI
この 23 ビットフィールドは、発信スイッチ上でサポートされる Data Link Connection Identifier (DLCI) のブロックの上限を指定する。DLCI はこのフィールド内で右詰めにしなければならず (MUST)、未使用ビットは 0 に設定しなければならない (MUST)。
4.2.4 LABEL_REQUEST の処理 (Handling of LABEL_REQUEST)
LSP トンネルを確立するために、送信者は LABEL_REQUEST オブジェクトを持つ Path メッセージを生成する。LABEL_REQUEST オブジェクトは、このパスに対するラベルバインディングが要求されていることを示し、このパス上で伝送されるネットワーク層プロトコルの指示を提供する。これにより、非 IP ネットワーク層プロトコルを LSP に沿って送信することが可能になる。この情報は実際のラベル割り当てにおいても有用である。というのも、一部の予約済みラベルはプロトコル固有だからである（[5] 参照）。
LABEL_REQUEST は Path State Block に保存すべきである (SHOULD)。そうすれば、Path リフレッシュメッセージにも LABEL_REQUEST オブジェクトが含まれるようになる。Path メッセージが受信者に到達すると、LABEL_REQUEST オブジェクトの存在が受信者にラベルを割り当てさせ、対応する Resv メッセージ用の LABEL オブジェクトにそのラベルを配置させる。ラベル範囲が指定されていた場合、ラベルはその範囲から割り当てなければならない (MUST)。LABEL_REQUEST オブジェクトを受け入れる受信者は、その Path メッセージに関連する Resv メッセージに LABEL オブジェクトを含めなければならない (MUST)。Path メッセージに LABEL_REQUEST オブジェクトが存在しなかった場合、ノードはその Path メッセージのセッションおよび PHOP に対する Resv メッセージに LABEL オブジェクトを含めてはならない (MUST NOT)。
LABEL_REQUEST オブジェクトを送信するノードは、対応する Resv メッセージ内の LABEL オブジェクトを受け入れ、正しく処理する準備ができていなければならない (MUST)。
LABEL_REQUEST オブジェクトを認識するが、それをサポートできない（おそらくラベル割り当ての失敗による）ノードは、エラーコード "Routing problem" とエラー値 "MPLS label allocation failure" を持つ PathErr を送信すべきである (SHOULD)。これには、ラベル範囲が指定されていて、その範囲からラベルを割り当てられない場合も含まれる。
LABEL_REQUEST オブジェクトをそれぞれ伴う Path メッセージを受信して転送するノードは、受信した LABEL_REQUEST オブジェクトから転送する LABEL_REQUEST オブジェクトへ L3PID をコピーしなければならない (MUST)。
受信者がプロトコル L3PID をサポートできない場合、エラーコード "Routing problem" とエラー値 "Unsupported L3PID" を持つ PathErr を送信すべきである (SHOULD)。これは RSVP セッションを失敗させる。
4.2.5 Label Request オブジェクトの非サポート (Non-support of the Label Request Object)
LABEL_REQUEST オブジェクトを認識しない RSVP ルータは、送信者に向けてエラーコード "Unknown object class" を持つ PathErr を送信する。LABEL_REQUEST オブジェクトを認識するが C_Type を認識しない RSVP ルータは、送信者に向けてエラーコード "Unknown object C_Type" を持つ PathErr を送信する。これはパス設定を失敗させる。送信者は、LSP を確立できないことを管理系に通知し、場合によっては LABEL_REQUEST なしで予約を継続するための処置をとるべきである。
RSVP は、送信者と受信者の間のどこにでも存在する非 RSVP ルータにうまく対処できるよう設計されている。しかし、明らかに、非 RSVP ルータは RSVP を介してラベルを伝えることができない。これは、ルータが RSVP に対応していないことが知られている隣接ノードを持つ場合、そのルータは非 RSVP ルータを通過するメッセージを送信するときに LABEL_REQUEST オブジェクトを広告してはならない (MUST NOT) ことを意味する。ルータは、エラーコード "Routing problem" とエラー値 "MPLS being negotiated, but a non-RSVP capable router stands in the path" を持つ PathErr を送信者に返すべきである (SHOULD)。ルータが非 RSVP 対応ルータからのメッセージ内で LABEL_REQUEST オブジェクトを受信した場合にも、同じメッセージを送信すべきである (SHOULD)。下流ルータが非 RSVP ルータの存在をどのように判定できるかについては [1] を参照。
4.3 Explicit Route オブジェクト (Explicit Route Object)
明示的経路は EXPLICIT_ROUTE オブジェクト (ERO) を介して指定される。Explicit Route クラスは 20 である。現在 1 つの C_Type、Type 1 Explicit Route が定義されている。EXPLICIT_ROUTE オブジェクトは以下の形式を持つ。
Class = 20, C_Type = 1
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
// (Subobjects) //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Subobjects（サブオブジェクト）
EXPLICIT_ROUTE オブジェクトの内容は、サブオブジェクトと呼ばれる可変長データ項目の系列である。サブオブジェクトは以下の 4.3.3 節で定義される。
Path メッセージが複数の EXPLICIT_ROUTE オブジェクトを含む場合、最初のオブジェクトのみが意味を持つ。後続の EXPLICIT_ROUTE オブジェクトは無視してもよく (MAY)、伝播させるべきではない (SHOULD NOT)。
4.3.1 適用性 (Applicability)
EXPLICIT_ROUTE オブジェクトはユニキャストの状況でのみ使用されることを意図している。マルチキャストへの明示的ルーティングの適用は今後の研究課題である。
EXPLICIT_ROUTE オブジェクトは、明示的経路に沿ったすべてのルータが RSVP と EXPLICIT_ROUTE オブジェクトをサポートする場合にのみ使用されるべきである。EXPLICIT_ROUTE オブジェクトには 0bbbbbbb の形式のクラス値が割り当てられる。したがって、このオブジェクトをサポートしない RSVP ルータは "Unknown Object Class" エラーで応答する。
4.3.2 Explicit Route オブジェクトの意味論 (Semantics of the Explicit Route Object)
明示的経路は、ネットワークトポロジ内の特定のパスである。通常、明示的経路は、そのパスに沿ってトラフィックを誘導する意図を持ってノードによって決定される。
明示的経路は、明示的経路に沿ったノードのグループのリストとして記述される。パスに沿った特定のノードを識別する能力に加えて、明示的経路は、パスに沿って通過しなければならないノードのグループを識別することができる。この能力により、ルーティングシステムは明示的経路の要求を満たす上でかなりの局所的柔軟性を得ることができる。この能力により、明示的経路の生成者はパスの詳細について不完全な情報を持つことができる。
明示的経路は、EXPLICIT_ROUTE オブジェクトに含まれる一連のサブオブジェクトとして符号化される。各サブオブジェクトは、明示的経路内のノードのグループを識別する。したがって明示的経路は、通過すべきノードのグループの指定である。
議論を形式化するため、我々はノードの各グループを抽象ノードと呼ぶ。したがって、明示的経路とは、通過すべき抽象ノードの集合の指定であると言える。抽象ノードが 1 つのノードのみから成る場合、それを単純抽象ノードと呼ぶ。
抽象ノードの概念の例として、自律システム番号サブオブジェクトのみから成る明示的経路を考える。各サブオブジェクトは、グローバルトポロジ内の 1 つの自律システムに対応する。この場合、各自律システムは抽象ノードであり、明示的経路は指定された各自律システムを含むパスである。各自律システム内には複数のホップが存在しうるが、これらは明示的経路の送信元ノードにとって不透明である。
4.3.3 サブオブジェクト (Subobjects)
EXPLICIT_ROUTE オブジェクトの内容は、サブオブジェクトと呼ばれる可変長データ項目の系列である。各サブオブジェクトは以下の形式を持つ。
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-------------//----------------+
|L| Type | Length | (Subobject contents) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-------------//----------------+
L
L ビットはサブオブジェクトの属性である。L ビットは、サブオブジェクトが明示的経路内の緩和ホップを表す場合に設定される。ビットが設定されていない場合、サブオブジェクトは明示的経路内の厳密ホップを表す。
Type
Type はサブオブジェクトの内容の型を示す。現在定義されている値は以下のとおりである。
1 IPv4 prefix
2 IPv6 prefix
32 Autonomous system number
Length
Length は、L、Type、Length の各フィールドを含むサブオブジェクトの全長をバイト単位で含む。Length は少なくとも 4 でなければならず (MUST)、4 の倍数でなければならない (MUST)。
4.3.3.1 厳密サブオブジェクトと緩和サブオブジェクト (Strict and Loose Subobjects)
サブオブジェクト内の L ビットは 1 ビットの属性である。L ビットが設定されている場合、その属性の値は 'loose' である。そうでなければ、その属性の値は 'strict' である。簡潔さのため、サブオブジェクト属性の値が 'loose' であるものを「緩和サブオブジェクト」と呼ぶ。そうでなければ「厳密サブオブジェクト」である。さらに、厳密サブオブジェクトまたは緩和サブオブジェクトの抽象ノードを、それぞれ厳密ノードまたは緩和ノードと呼ぶ。緩和ノードと厳密ノードは常に、それより前の抽象ノードを基準として解釈される。
厳密ノードとその先行ノードとの間のパスは、その厳密ノードとその先行抽象ノードからのネットワークノードのみを含まなければならない (MUST)。
緩和ノードとその先行ノードとの間のパスは、その厳密ノードまたはその先行抽象ノードの一部ではない他のネットワークノードを含んでもよい (MAY)。
4.3.3.2 サブオブジェクト 1：IPv4 プレフィックス (Subobject 1: IPv4 prefix)
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|L| Type | Length | IPv4 address (4 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 address (continued) | Prefix Length | Resvd |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
L
L ビットはサブオブジェクトの属性である。L ビットは、サブオブジェクトが明示的経路内の緩和ホップを表す場合に設定される。ビットが設定されていない場合、サブオブジェクトは明示的経路内の厳密ホップを表す。
Type
0x01 IPv4 アドレス
Length
Length は、Type および Length の各フィールドを含むサブオブジェクトの全長をバイト単位で含む。Length は常に 8 である。
IPv4 address
IPv4 アドレス。このアドレスは、以下のプレフィックス長の値に基づいてプレフィックスとして扱われる。プレフィックスを超えるビットは受信時に無視され、送信時にはゼロに設定すべきである (SHOULD)。
Prefix length
IPv4 プレフィックスのビット単位の長さ
Padding
送信時はゼロ。受信時は無視される。
IPv4 プレフィックスサブオブジェクトの内容は、4 オクテットの IPv4 アドレス、1 オクテットのプレフィックス長、1 オクテットのパッドである。このサブオブジェクトが表す抽象ノードは、このプレフィックス内に存在する IP アドレスを持つノードの集合である。プレフィックス長 32 は単一の IPv4 ノードを示すことに注意。
4.3.3.3 サブオブジェクト 2：IPv6 プレフィックス (Subobject 2: IPv6 Prefix)
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|L| Type | Length | IPv6 address (16 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6 address (continued) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6 address (continued) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6 address (continued) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6 address (continued) | Prefix Length | Resvd |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
L
L ビットはサブオブジェクトの属性である。L ビットは、サブオブジェクトが明示的経路内の緩和ホップを表す場合に設定される。ビットが設定されていない場合、サブオブジェクトは明示的経路内の厳密ホップを表す。
Type
0x02 IPv6 アドレス
Length
Length は、Type および Length の各フィールドを含むサブオブジェクトの全長をバイト単位で含む。Length は常に 20 である。
IPv6 address
IPv6 アドレス。このアドレスは、以下のプレフィックス長の値に基づいてプレフィックスとして扱われる。プレフィックスを超えるビットは受信時に無視され、送信時にはゼロに設定すべきである (SHOULD)。
Prefix Length
IPv6 プレフィックスのビット単位の長さ。
Padding
送信時はゼロ。受信時は無視される。
IPv6 プレフィックスサブオブジェクトの内容は、16 オクテットの IPv6 アドレス、1 オクテットのプレフィックス長、1 オクテットのパッドである。このサブオブジェクトが表す抽象ノードは、このプレフィックス内に存在する IP アドレスを持つノードの集合である。プレフィックス長 128 は単一の IPv6 ノードを示すことに注意。
4.3.3.4 サブオブジェクト 32：自律システム番号 (Subobject 32: Autonomous System Number)
自律システム (AS) 番号サブオブジェクトの内容は、2 オクテットの AS 番号である。このサブオブジェクトが表す抽象ノードは、その自律システムに属するノードの集合である。
AS 番号サブオブジェクトの長さは 4 オクテットである。
4.3.4 Explicit Route オブジェクトの処理 (Processing of the Explicit Route Object)
4.3.4.1 次ホップの選択 (Selection of the Next Hop)
EXPLICIT_ROUTE オブジェクトを含む Path メッセージを受信するノードは、このパスの次ホップを決定しなければならない。これは、明示的経路に沿った次の抽象ノードが IP サブネットまたは自律システムである可能性があるため必要である。したがって、この次ホップの選択は、実行可能な代替案の集合からの決定を伴う場合がある。実行可能な代替案から選択を行うために用いられる基準は実装依存であり、ローカルポリシーの影響も受けうるものであり、本仕様の範囲を超える。しかし、各ノードがループのないパスを決定するよう最善の努力を行うことが想定されている。このように決定されたパスはローカルポリシーによって上書きされうることに注意。
パスの次ホップを決定するため、ノードは以下のステップを実行する。
-
RSVP メッセージを受信するノードは、まず最初のサブオブジェクトを評価しなければならない (MUST)。ノードが最初のサブオブジェクトによって記述される抽象ノードの一部でない場合、そのノードは誤ってメッセージを受信したのであり、"Bad initial subobject" エラーを返すべきである (SHOULD)。最初のサブオブジェクトが存在しない場合もメッセージは誤っており、システムは "Bad EXPLICIT_ROUTE object" エラーを返すべきである (SHOULD)。
-
2 番目のサブオブジェクトが存在しない場合、これは明示的経路の終端を示す。EXPLICIT_ROUTE オブジェクトは Path メッセージから削除すべきである (SHOULD)。このノードはパスの終端である場合もそうでない場合もある。処理は 4.3.4.2 節に続き、そこでは新しい EXPLICIT_ROUTE オブジェクトを Path メッセージに追加してもよい (MAY)。
-
次に、ノードは 2 番目のサブオブジェクトを評価する。ノードが 2 番目のサブオブジェクトによって記述される抽象ノードの一部でもある場合、ノードは最初のサブオブジェクトを削除し、上記のステップ 2 で処理を続ける。これにより 2 番目のサブオブジェクトが次の反復の最初のサブオブジェクトになり、ノードがステップ 2 と 3 を繰り返し適用した後にメッセージのパス上の次の抽象ノードを識別できるようになることに注意。
-
抽象ノードの境界の場合: ノードは、2 番目のサブオブジェクトによって記述される抽象ノードにトポロジ的に隣接しているかどうかを判定する。隣接している場合、ノードはその抽象ノードのメンバーである特定の次ホップを選択する。次にノードは最初のサブオブジェクトを削除し、4.3.4.2 節で処理を続ける。
-
抽象ノードの内部の場合: そうでなければ、ノードは (ノードが属する) 最初のサブオブジェクトの抽象ノード内で、2 番目のサブオブジェクトの抽象ノード (次の抽象ノード) へのパスに沿った次ホップを選択する。そのようなパスが存在しない場合、2 つの場合がある。
5a) 2 番目のサブオブジェクトが厳密サブオブジェクトである場合、エラーであり、ノードは "Bad strict node" エラーを返すべきである (SHOULD)。
5b) そうでなく、2 番目のサブオブジェクトが緩和サブオブジェクトである場合、ノードは次の抽象ノードへのパスに沿った任意の次ホップを選択する。パスが存在しない場合、エラーであり、ノードは "Bad loose node" エラーを返すべきである (SHOULD)。
-
最後に、ノードは最初のサブオブジェクトを、次ホップを含む抽象ノードを表す任意のサブオブジェクトで置き換える。これは、明示的経路が次のホップによって受信されたときに受け入れられるようにするために必要である。
4.3.4.2 Explicit Route オブジェクトへのサブオブジェクトの追加 (Adding subobjects to the Explicit Route Object)
次ホップを選択した後、ノードは以下の方法で明示的経路を変更してもよい (MAY)。
4.3.4.1 節のアルゴリズムを実行する一環として EXPLICIT_ROUTE オブジェクトが削除された場合、ノードは新しい EXPLICIT_ROUTE オブジェクトを追加してもよい (MAY)。
そうでない場合、ノードが最初のサブオブジェクトの抽象ノードのメンバーであるならば、一連のサブオブジェクトを最初のサブオブジェクトの前に挿入してもよく (MAY)、あるいは最初のサブオブジェクトを置き換えてもよい (MAY)。この系列内の各サブオブジェクトは、現在の抽象ノードのサブセットである抽象ノードを表さなければならない (MUST)。
あるいは、最初のサブオブジェクトが緩和サブオブジェクトである場合、任意の一連のサブオブジェクトを最初のサブオブジェクトの前に挿入してもよい (MAY)。
4.3.5 ループ (Loops)
EXPLICIT_ROUTE オブジェクトは有限長であるが、緩和ノードの存在は、基盤となるルーティングプロトコルの過渡期に転送ループを構成することが可能であることを意味する。これは、RECORD_ROUTE オブジェクトと呼ばれる別の不透明ルートオブジェクトを使用することにより、明示的経路の生成者によって検出できる。RECORD_ROUTE オブジェクトは詳細なパス情報を収集するために使用され、ループ検出および診断に有用である。
4.3.6 前方互換性 (Forward Compatibility)
新しいサブオブジェクトが時間の経過とともに定義されることが予想される。通常の ERO 処理中に認識できないサブオブジェクトに遭遇したノードは、エラーコード "Routing Error" とエラー値 "Bad Explicit Route Object" を持つ PathErr を送信者に向けて送信する。EXPLICIT_ROUTE オブジェクトは、問題のあるサブオブジェクトまで (左側で) 切り詰められて含められる。ノードの ERO 処理において遭遇しない認識できないサブオブジェクトの存在は無視すべきである (SHOULD)。それは残りの ERO スタックの残りとともに前方へ渡される。
4.3.7 Explicit Route オブジェクトの非サポート (Non-support of the Explicit Route Object)
EXPLICIT_ROUTE オブジェクトを認識しない RSVP ルータは、送信者に向けてエラーコード "Unknown object class" を持つ PathErr を送信する。これはパス設定を失敗させる。送信者は、LSP を確立できないことを管理系に通知し、場合によっては EXPLICIT_ROUTE なしで、または異なる明示的経路を介して予約を継続するための処置をとるべきである。
4.4 Record Route オブジェクト (Record Route Object)
経路は RECORD_ROUTE オブジェクト (RRO) を介して記録できる。オプションとして、ラベルも記録してもよい (MAY)。Record Route クラスは 21 である。現在、1 つの C_Type が定義されている。すなわちタイプ 1 の Record Route である。RECORD_ROUTE オブジェクトは以下の形式を持つ。
Class = 21, C_Type = 1
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
// (Subobjects) //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Subobjects（サブオブジェクト）
RECORD_ROUTE オブジェクトの内容は、サブオブジェクトと呼ばれる可変長データ項目の系列である。サブオブジェクトは、後述の 4.4.1 節で定義される。
RRO は RSVP の Path メッセージと Resv メッセージの両方に存在しうる。Path メッセージが複数の RRO を含む場合、最初の RRO のみが意味を持つ。後続の RRO は無視すべきであり (SHOULD)、伝播させるべきではない (SHOULD NOT)。同様に、Resv メッセージ内で、ある FILTER_SPEC に続いて別の FILTER_SPEC に遭遇する前に複数の RRO に遭遇した場合、最初の RRO のみが意味を持つ。後続の RRO は無視すべきであり (SHOULD)、伝播させるべきではない (SHOULD NOT)。
4.4.1 サブオブジェクト (Subobjects)
RECORD_ROUTE オブジェクトの内容は、サブオブジェクトと呼ばれる可変長データ項目の系列である。各サブオブジェクトは自身の Length フィールドを持つ。Length は、Type フィールドと Length フィールドを含む、サブオブジェクトの全長をバイト単位で格納する。Length は常に 4 の倍数であり、かつ少なくとも 4 でなければならない (MUST)。
サブオブジェクトは、後入れ先出し (last-in-first-out) スタックとして編成される。RRO の先頭を基準とした最初のサブオブジェクトがトップと見なされる。最後のサブオブジェクトがボトムと見なされる。新しいサブオブジェクトが追加されるとき、それは常にトップに追加される。
サブオブジェクトを持たない空の RRO は不正であると見なされる。
現在、3 種類のサブオブジェクトが定義されている。
4.4.1.1 サブオブジェクト 1：IPv4 アドレス (Subobject 1: IPv4 address)
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | IPv4 address (4 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 address (continued) | Prefix Length | Flags |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
0x01 IPv4 address
Length
Length は、Type フィールドと Length フィールドを含む、サブオブジェクトの全長をバイト単位で格納する。Length は常に 8 である。
IPv4 address
32 ビットのユニキャストホストアドレス。ここでは、ネットワークから到達可能な任意のインターフェースアドレスが許される。特定のループバックアドレスなど、不正なアドレスは使用すべきではない (SHOULD NOT)。
Prefix length
32
Flags
0x01 Local protection available
このノードの下流のリンクがローカル修復メカニズムによって保護されていることを示す。このフラグは、対応する Path メッセージの SESSION_ATTRIBUTE オブジェクトで Local protection フラグが設定されていた場合にのみ設定できる。
0x02 Local protection in use
ローカル修復メカニズムがこのトンネルを維持するために使用されていること（通常、以前にルーティングされていたリンクの障害に直面した場合）を示す。
4.4.1.2 サブオブジェクト 2：IPv6 アドレス (Subobject 2: IPv6 address)
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | IPv6 address (16 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6 address (continued) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6 address (continued) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6 address (continued) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6 address (continued) | Prefix Length | Flags |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
0x02 IPv6 address
Length
Length は、Type フィールドと Length フィールドを含む、サブオブジェクトの全長をバイト単位で格納する。Length は常に 20 である。
IPv6 address
128 ビットのユニキャストホストアドレス。
Prefix length
128
Flags
0x01 Local protection available
このノードの下流のリンクがローカル修復メカニズムによって保護されていることを示す。このフラグは、対応する Path メッセージの SESSION_ATTRIBUTE オブジェクトで Local protection フラグが設定されていた場合にのみ設定できる。
0x02 Local protection in use
ローカル修復メカニズムがこのトンネルを維持するために使用されていること（通常、以前にルーティングされていたリンクの障害に直面した場合）を示す。
4.4.1.3 サブオブジェクト 3：ラベル (Subobject 3, Label)
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Flags | C-Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Contents of Label Object |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
0x03 Label
Length
Length は、Type フィールドと Length フィールドを含む、サブオブジェクトの全長をバイト単位で格納する。
Flags
0x01 = Global label
このフラグは、任意のインターフェースで受信された場合にそのラベルが理解されることを示す。
C-Type
含まれる Label オブジェクトの C-Type。Label オブジェクトからコピーされる。
Contents of Label Object
Label オブジェクトの内容。Label オブジェクトからコピーされる。
4.4.2 適用性 (Applicability)
ここでは、ユニキャストセッションで使用するための手順のみを定義する。
RSVP における RRO の用途には 3 つありうる。第 1 に、RRO は、L3 ルーティングループ、または明示的経路に固有のループを発見するためのループ検出機構として機能できる。そのための正確な手順は、本文書の後半で説明する。
第 2 に、RRO は RSVP セッションに関する最新の詳細なパス情報をホップ単位で収集し、送信者または受信者に貴重な情報を提供する。ネットワークトポロジの変化によるあらゆるパス変更が報告される。
第 3 に、RRO の構文は、わずかな変更を加えるだけでオブジェクト全体を EXPLICIT_ROUTE オブジェクトへの入力として使用できるように設計されている。これは、送信者が Resv メッセージ内で受信者から RRO を受信し、それを次の Path メッセージ内の EXPLICIT_ROUTE オブジェクトに適用して「セッションパスを固定する (pin down session path)」場合に有用である。
4.4.3 RRO の処理 (Processing RRO)
通常、ノードは Path メッセージに RRO を追加することによって RSVP セッションを開始する。初期の RRO は 1 つのサブオブジェクト、すなわち送信者の IP アドレスのみを含む。ノードがラベル記録も望む場合、それは SESSION_ATTRIBUTE オブジェクト内の Label_Recording フラグを設定する。
RRO を含む Path メッセージが中間ルータによって受信されると、そのルータはそのコピーをパス状態ブロックに格納する。次に RRO は、Path メッセージをフォーマットするための次の Path リフレッシュイベントで使用される。新しい Path メッセージを送信しようとするとき、ルータは RRO に新しいサブオブジェクトを追加し、結果として得られる RRO を送信前に Path メッセージへ付加する。
新たに追加されるサブオブジェクトは、このルータの IP アドレスでなければならない (MUST)。追加されるアドレスは、送信する Path メッセージのインターフェースアドレスであるべきである (SHOULD)。そこから選択すべきアドレスが複数ある場合、その決定はローカルな事項である。しかしながら、同一のアドレスを一貫して選択することが推奨される (RECOMMENDED)。
SESSION_ATTRIBUTE オブジェクト内で Label_Recording フラグが設定されている場合、経路記録を行うノードは Label Record サブオブジェクトを含めるべきである (SHOULD)。ノードがグローバルラベル空間を使用している場合、それは Global Label フラグを設定すべきである (SHOULD)。
Label Record サブオブジェクトは、ノードの IP アドレスをプッシュする前に RECORD_ROUTE オブジェクトへプッシュされる。ノードは、IPv4 または IPv6 サブオブジェクトもプッシュすることなしに Label Record サブオブジェクトをプッシュしてはならない (MUST NOT)。
注: 初期の Path メッセージを受信した時点では、ノードが含めるべきラベルを持っている可能性は低い。ラベルが一旦取得されると、ノードは次の Path リフレッシュイベントにおいてそのラベルを RRO に含めるべきである (SHOULD)。
新たに追加されたサブオブジェクトによって RRO が大きくなりすぎて Path (または Resv) メッセージに収まらなくなった場合、その RRO オブジェクトはメッセージから削除されなければならず (SHALL)、メッセージ処理は通常どおり継続する。PathErr (または ResvErr) メッセージが送信者 (または受信者) へ返送されるべきである (SHOULD)。エラーコード「Notify」およびエラー値「RRO too large for MTU」が使用される。受信者がそのような ResvErr を受信した場合、それはエラーコード「Notify」およびエラー値「RRO notification」を持つ PathErr メッセージを送信すべきである (SHOULD)。
これらのエラー値のいずれかを受信した送信者は、Path メッセージから RRO を削除すべきである (SHOULD)。
ノードは、上記の PathErr または ResvErr メッセージを n 秒ごとに再送すべきである (SHOULD)。ここで n は 15 と、関連する Path メッセージまたは RESV メッセージのリフレッシュ間隔とのうち大きい方である。ノードは、送信するメッセージ数を制限するために、制限および/またはバックオフタイマーを適用してもよい (MAY)。
RSVP ルータは、次の Path メッセージ内の RRO が前回のものと異なる場合、自身のリフレッシュ時刻よりも前に Path メッセージを送信することを決定できる。これは、前のホップルータから受信した RRO の内容が変化した場合、またはこの RRO が Path メッセージに新たに追加された (もしくは削除された) 場合に起こりうる。
RSVP セッションの宛先ノードが RRO 付きの Path メッセージを受信した場合、これは送信者ノードが経路記録を必要としていることを示す。宛先ノードは、Resv メッセージに RRO を追加することによって RRO 処理を開始する。その処理は Path メッセージの処理を反映したものである。唯一の違いは、Resv メッセージ内の RRO が逆方向のパス情報を記録することである。
注: パスに沿った各ノードは、これで送信元から宛先までの完全な経路を持つことになる。Path RRO は送信元からこのノードまでの経路を持ち、Resv RRO はこのノードから宛先までの経路を持つ。これはネットワーク管理に有用である。
RRO なしで受信された Path メッセージは、送信者ノードがもはや経路記録を必要としていないことを示す。後続の Resv メッセージは RRO を含んではならない (SHALL NOT)。
4.4.4 ループ検出 (Loop Detection)
受信した RRO を処理する一環として、中間ルータは RRO 内に含まれるすべてのサブオブジェクトを調べる。ルータが自身がすでにそのリスト内にあると判断した場合、転送ループが存在する。
下流ノードが Path メッセージを受信するか、上流ノードが Resv メッセージを受信する際に、含まれる RRO 内でルーティングループが検出されなければ、その RSVP セッションはループフリーである。
転送ループには大きく分けて 2 つの分類がある。第 1 のクラスは過渡的ループであり、これは L3 ルーティングがすべての宛先に対して一貫した転送パスへ収束しようとする際に、運用の正常な一部として発生する。転送ループの第 2 のクラスは永続的ループであり、これは通常、ネットワークの設定ミスに起因する。
RRO の受信時にノードが実行するアクションは、RRO がどのメッセージタイプで受信されるかに依存する。
転送ループを含む Path メッセージに対して、ルータは、エラー値「loop detected」を伴う「Routing problem」PathErr メッセージを構築して送信し、その Path メッセージを廃棄する。ループが解消されるまで、このセッションはデータパケットの転送に適さない。ループがどのように解消されるかは、本文書の範囲外である。
転送ループを含む Resv メッセージに対して、ルータは単純にそのメッセージを廃棄する。Path メッセージがループしなければ、Resv メッセージはループすべきではない。
4.4.5 前方互換性 (Forward Compatibility)
RRO に対して新しいサブオブジェクトが定義されることがある。RRO を処理する際、認識されないサブオブジェクトは無視して通過させるべきである (SHOULD)。ループ検出のために RRO を処理する際、ノードは認識されないオブジェクトを解析して読み飛ばすべきである (SHOULD)。ループ検出は、オブジェクトの以前の通過時にノード自身によって挿入されたサブオブジェクトを検出することによって機能する。これにより、ループ検出に必要なサブオブジェクトが常に理解されることが保証される。
4.4.6 RRO の非サポート (Non-support of RRO)
RRO オブジェクトは、パスに沿ったすべてのルータが RSVP および RRO オブジェクトをサポートする場合にのみ使用されるものである。RRO オブジェクトには、0bbbbbbb という形式のクラス値が割り当てられる。したがって、このオブジェクトをサポートしない RSVP ルータは、「Unknown Object Class」エラーで応答することになる。
4.5 ERO と RRO のエラーコード (Error Codes for ERO and RRO)
上述の処理において、特定のエラーは「Routing Problem」または「Notify」のいずれかとして報告されなければならない。エラーコード「Routing Problem」の値は 24 であり、エラーコード「Notify」の値は 25 である。
以下は、Routing Problem エラーコードに対するエラー値を定義する。
値 エラー:
-
Bad EXPLICIT_ROUTE object（不正な EXPLICIT_ROUTE オブジェクト）
-
Bad strict node（不正な厳密ノード）
-
Bad loose node（不正な緩和ノード）
-
Bad initial subobject（不正な初期サブオブジェクト）
-
No route available toward destination（宛先へ向かう利用可能な経路がない）
-
Unacceptable label value（受け入れられないラベル値）
-
RRO indicated routing loops（RRO がルーティングループを示した）
-
MPLS being negotiated, but a non-RSVP-capable router stands in the path（MPLS がネゴシエートされているが、RSVP 非対応ルータがパス上に存在する）
-
MPLS label allocation failure（MPLS ラベル割り当て失敗）
-
Unsupported L3PID（サポートされない L3PID）
Notify エラーコードについて、Error Value フィールドの 16 ビットは以下のとおりである。
ss00 cccc cccc cccc
上位ビットは、エラーコード 1 の下で定義されるとおりである ([1] を参照)。
ss = 00 の場合、以下のサブコードが定義される。
-
RRO too large for MTU（RRO が MTU に対して大きすぎる）
-
RRO notification（RRO 通知）
-
Tunnel locally repaired（トンネルがローカル修復された）
4.6 Session、Sender Template、Filter Spec オブジェクト (Session, Sender Template, and Filter Spec Objects)
SESSION、SENDER_TEMPLATE および FILTER_SPEC オブジェクトに対して新しい C-Type が定義される。
LSP_TUNNEL オブジェクトは以下の形式をとる。
4.6.1 Session オブジェクト (Session Object)
4.6.1.1 LSP_TUNNEL_IPv4 Session オブジェクト (LSP_TUNNEL_IPv4 Session Object)
Class = SESSION, LSP_TUNNEL_IPv4 C-Type = 7
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 tunnel end point address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MUST be zero | Tunnel ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Extended Tunnel ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
IPv4 tunnel end point address
トンネルの出口ノードの IPv4 アドレス。
Tunnel ID
SESSION で使用される 16 ビットの識別子であり、トンネルの存続期間を通じて一定に保たれる。
Extended Tunnel ID
SESSION で使用される 32 ビットの識別子であり、トンネルの存続期間を通じて一定に保たれる。通常はすべてゼロに設定される。SESSION のスコープを入口-出口ペアに狭めたい入口ノードは、グローバルに一意な識別子として自身の IPv4 アドレスをここに置くことができる。
4.6.1.2 LSP_TUNNEL_IPv6 Session オブジェクト (LSP_TUNNEL_IPv6 Session Object)
Class = SESSION, LSP_TUNNEL_IPv6 C_Type = 8
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| IPv6 tunnel end point address |
+ +
| (16 bytes) |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MUST be zero | Tunnel ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| Extended Tunnel ID |
+ +
| (16 bytes) |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
IPv6 tunnel end point address
トンネルの出口ノードの IPv6 アドレス。
Tunnel ID
SESSION で使用される 16 ビットの識別子であり、トンネルの存続期間を通じて一定に保たれる。
Extended Tunnel ID
SESSION で使用される 16 バイトの識別子であり、トンネルの存続期間を通じて一定に保たれる。通常はすべてゼロに設定される。SESSION のスコープを入口-出口ペアに狭めたい入口ノードは、グローバルに一意な識別子として自身の IPv6 アドレスをここに置くことができる。
4.6.2 Sender Template オブジェクト (Sender Template Object)
4.6.2.1 LSP_TUNNEL_IPv4 Sender Template オブジェクト (LSP_TUNNEL_IPv4 Sender Template Object)
Class = SENDER_TEMPLATE, LSP_TUNNEL_IPv4 C-Type = 7
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 tunnel sender address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MUST be zero | LSP ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
IPv4 tunnel sender address
送信者ノードの IPv4 アドレス。
LSP ID
SENDER_TEMPLATE および FILTER_SPEC で使用される 16 ビットの識別子であり、送信者が自身とリソースを共有できるようにするために変更できる。
4.6.2.2 LSP_TUNNEL_IPv6 Sender Template オブジェクト (LSP_TUNNEL_IPv6 Sender Template Object)
Class = SENDER_TEMPLATE, LSP_TUNNEL_IPv6 C_Type = 8
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| IPv6 tunnel sender address |
+ +
| (16 bytes) |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MUST be zero | LSP ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
IPv6 tunnel sender address
送信者ノードの IPv6 アドレス。
LSP ID
SENDER_TEMPLATE および FILTER_SPEC で使用される 16 ビットの識別子であり、送信者が自身とリソースを共有できるようにするために変更できる。
4.6.3 Filter Specification オブジェクト (Filter Specification Object)
4.6.3.1 LSP_TUNNEL_IPv4 Filter Specification オブジェクト (LSP_TUNNEL_IPv4 Filter Specification Object)
Class = FILTER SPECIFICATION, LSP_TUNNEL_IPv4 C-Type = 7
LSP_TUNNEL_IPv4 FILTER_SPEC オブジェクトの形式は、LSP_TUNNEL_IPv4 SENDER_TEMPLATE オブジェクトと同一である。
4.6.3.2 LSP_TUNNEL_IPv6 Filter Specification オブジェクト (LSP_TUNNEL_IPv6 Filter Specification Object)
Class = FILTER SPECIFICATION, LSP_TUNNEL_IPv6 C_Type = 8
LSP_TUNNEL_IPv6 FILTER_SPEC オブジェクトの形式は、LSP_TUNNEL_IPv6 SENDER_TEMPLATE オブジェクトと同一である。
4.6.4 再ルーティングと帯域増加の手順 (Reroute and Bandwidth Increase Procedure)
この節では、再ルーティングされている間、または帯域の増加を試みている間に、（二重計上することなく）リソース予約を維持できるトンネルをどのようにセットアップするかを説明する。最初の Path メッセージにおいて、入口ノードは SESSION オブジェクトを形成し、Tunnel_ID を割り当て、自身の IPv4 アドレスを Extended_Tunnel_ID に置く。また SENDER_TEMPLATE を形成し、LSP_ID を割り当てる。その後、トンネルのセットアップは通常の手順に従って進む。
Path メッセージを受信すると、出口ノードは STYLE Shared Explicit を持つ Resv メッセージを入口ノードに向けて送信する。
確立されたパスを持つ入口ノードがそのパスを変更したいときは、以下のようにして新しい Path メッセージを形成する。既存の SESSION オブジェクトを使用する。特に Tunnel_ID および Extended_Tunnel_ID は変更しない。入口ノードは新しい SENDER_TEMPLATE を形成するために新しい LSP_ID を選ぶ。新しい経路のための EXPLICIT_ROUTE オブジェクトを作成する。新しい Path メッセージが送信される。入口ノードは古いパスメッセージと新しいパスメッセージの両方をリフレッシュする。
出口ノードは、以下のようにフォーマットされた SE フロー記述子を持つ Resv メッセージで応答する。
<FLOWSPEC><old_FILTER_SPEC><old_LABEL_OBJECT><new_FILTER_SPEC>
<new_LABEL_OBJECT>
（PHOP が異なる場合には、それぞれ適切な FILTER_SPEC と LABEL_OBJECT を持つ 2 つのメッセージが送信されることに注意。）
入口ノードは Resv メッセージを受信すると、新しい経路の使用を開始してよい。古い経路に対して PathTear メッセージを送信すべきである (SHOULD)。
4.7 Session Attribute オブジェクト (Session Attribute Object)
Session Attribute クラスは 207 である。2 つの C_Type、すなわち LSP_TUNNEL（C-Type = 7）と LSP_TUNNEL_RA（C-Type = 1）が定義される。LSP_TUNNEL_RA C-Type は LSP_TUNNEL C-Type と同じフィールドをすべて含む。さらに、リソースアフィニティ情報を運ぶ。形式は以下のとおりである。
4.7.1 リソースアフィニティなしの形式 (Format without resource affinities)
SESSION_ATTRIBUTE class = 207, LSP_TUNNEL C-Type = 7
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Setup Prio | Holding Prio | Flags | Name Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
// Session Name (NULL padded display string) //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Setup Priority
リソースを取得するという観点でのセッションの優先度であり、0 から 7 の範囲をとる。値 0 が最も高い優先度である。セットアップ優先度は、このセッションが別のセッションをプリエンプトできるかどうかを決定する際に使用される。
Holding Priority
リソースを保持するという観点でのセッションの優先度であり、0 から 7 の範囲をとる。値 0 が最も高い優先度である。保持優先度は、このセッションが別のセッションによってプリエンプトされるかどうかを決定する際に使用される。
Flags
0x01 Local protection desired（ローカル保護希望）
このフラグは、明示的経路オブジェクトに違反する結果になりうるローカル修復メカニズムを中継ルータが使用することを許可する。隣接する下流リンクまたはノードで障害が検出されると、中継ルータは迅速なサービス復旧のためにトラフィックを再ルーティングできる。
0x02 Label recording desired（ラベル記録希望）
このフラグは、経路記録を行う際にラベル情報を含めるべきであることを示す。
0x04 SE Style desired（SE スタイル希望）
このフラグは、トンネルの入口ノードがこのトンネルを解体することなく再ルーティングすることを選択してよいことを示す。トンネルの出口ノードは、Resv メッセージで応答する際に SE Style を使用すべきである (SHOULD)。
Name Length
パディング前の表示文字列の長さ（バイト単位）。
Session Name
ヌルでパディングされた文字列。
4.7.2 リソースアフィニティ付きの形式 (Format with resource affinities)
SESSION_ATTRIBUTE class = 207, LSP_TUNNEL_RA C-Type = 1
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Exclude-any |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Include-any |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Include-all |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Setup Prio | Holding Prio | Flags | Name Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
// Session Name (NULL padded display string) //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Exclude-any
トンネルに関連付けられた属性フィルタの集合を表す 32 ビットのベクタであり、そのいずれかがリンクを許容不可にする。
Include-any
トンネルに関連付けられた属性フィルタの集合を表す 32 ビットのベクタであり、（このテストに関して） そのいずれかがリンクを許容可能にする。空集合（すべてのビットがゼロ） は自動的に合格する。
Include-all
トンネルに関連付けられた属性フィルタの集合を表す 32 ビットのベクタであり、（このテストに関して） リンクが許容可能となるためにはそのすべてが存在しなければならない。空集合（すべてのビットがゼロ） は自動的に合格する。
Setup Priority
リソースを取得するという観点でのセッションの優先度であり、0 から 7 の範囲をとる。値 0 が最も高い優先度である。セットアップ優先度は、このセッションが別のセッションをプリエンプトできるかどうかを決定する際に使用される。
Holding Priority
リソースを保持するという観点でのセッションの優先度であり、0 から 7 の範囲をとる。値 0 が最も高い優先度である。保持優先度は、このセッションが別のセッションによってプリエンプトされるかどうかを決定する際に使用される。
Flags
0x01 Local protection desired（ローカル保護希望）
このフラグは、明示的経路オブジェクトに違反する結果になりうるローカル修復メカニズムを中継ルータが使用することを許可する。隣接する下流リンクまたはノードで障害が検出されると、中継ルータは迅速なサービス復旧のためにトラフィックを再ルーティングできる。
0x02 Label recording desired（ラベル記録希望）
このフラグは、経路記録を行う際にラベル情報を含めるべきであることを示す。
0x04 SE Style desired（SE スタイル希望）
このフラグは、トンネルの入口ノードがこのトンネルを解体することなく再ルーティングすることを選択してよいことを示す。トンネルの出口ノードは、Resv メッセージで応答する際に SE Style を使用すべきである (SHOULD)。
Name Length
パディング前の表示文字列の長さ（バイト単位）。
Session Name
ヌルでパディングされた文字列。
4.7.3 両方の C-Type に適用される手順 (Procedures applying to both C-Types)
セットアップ優先度と保持優先度のサポートは任意である (OPTIONAL)。ノードはこの情報を認識できても、要求された操作を実行できないことがある。ノードはこの情報を変更せずに下流へ渡すべきである (SHOULD)。
上述したように、プリエンプションは 2 つの優先度によって実装される。セットアップ優先度はリソースを取得するための優先度である。保持優先度はリソースを保持するための優先度である。具体的には、保持優先度はこのセッションに割り当てられたリソースが予約される際の優先度である。セットアップ優先度は、所与のセッションにおいて保持優先度より高くすべきではない (SHOULD NOT)。
セットアップ優先度と保持優先度は、[9] で定義されているプリエンプション優先度と防御優先度に直接類似している。これら 2 つのオブジェクトの相互作用は最終的にはポリシーの問題であるが、以下のデフォルトの相互作用が推奨される (RECOMMENDED)。
両方のオブジェクトが存在する場合、プリエンプション優先度ポリシー要素が使用される。優先度空間間のマッピングは以下のように定義される。セッション属性優先度 S は、式 P = 2^(14-2S) によってプリエンプション優先度 P にマッピングされる。逆方向のマッピングを以下の表に示す。
Preemption Priority Session Attribute Priority
0 - 3 7
4 - 15 6
16 - 63 5
64 - 255 4
256 - 1023 3
1024 - 4095 2
4096 - 16383 1
16384 - 65535 0
新しい Path メッセージがアドミッションの対象として検討される際、要求された帯域が、セットアップ優先度で指定された優先度において利用可能な帯域と比較される。
要求された帯域が利用できない場合、エラーコード 01（Admission Control Failure） およびエラー値 0x0002 を持つ PathErr メッセージが返される。エラー値の最初の 0 はグローバルに定義されたサブコードであることを示し、情報としての意味はない。002 は「要求された帯域が利用不可」であることを示す。
要求された帯域が未使用帯域より少ない場合、処理は完了する。要求された帯域が利用可能であるが、より低い優先度のセッションによって使用されている場合、必要な帯域を解放するために、より低い優先度のセッション（最も低い優先度のものから順に）をプリエンプトしてもよい (MAY)。
プリエンプションがサポートされる場合、プリエンプトされた各予約は、理由を示すサブコードを渡してローカルクライアントへの TC_Preempt() アップコールをトリガする。コード「Policy Control failure」を持つ ResvErr および/または PathErr を、下流の受信者と上流の送信者に向けて送信すべきである (SHOULD)。
ローカル保護のサポートは任意である (OPTIONAL)。ノードはローカル保護フラグを認識できても、要求された操作を実行できないことがある。この場合、ノードはこの情報を変更せずに下流へ渡すべきである (SHOULD)。
ROUTE_RECORD オブジェクトにおける Label サブオブジェクトの記録は、SESSION_ATTRIBUTE オブジェクト内のラベル記録希望フラグによって制御される。Label サブオブジェクトはすべてのアプリケーションに必要なわけではないため、自動的には記録されない。このフラグにより、アプリケーションは必要なときにのみこれを要求できる。
Session Name フィールドの内容は文字列であり、通常は表示可能な文字からなる。長さは常に 4 の倍数でなければならず (MUST)、少なくとも 8 でなければならない (MUST)。オブジェクト長が 4 の倍数でない場合、オブジェクトは末尾の NULL 文字でパディングされる。Name Length フィールドには実際の文字列長が入る。
4.7.4 リソースアフィニティの手順 (Resource Affinity Procedures)
リソースクラスとリソースクラスアフィニティは [3] で説明されている。本書では後者の用語に対して、より簡潔な用語であるリソースアフィニティを用いる。リソースクラスはリンクに関連付けることができ、ルーティングプロトコルで広告できる。リソースクラスアフィニティは RSVP によって 2 つの方法で使用される。検証されるためには、リンクは以下の 3 つのテストに合格しなければならない (MUST)。テストに失敗した場合、コード「policy control failure」を持つ PathErr を送信すべきである (SHOULD)。
新しい予約が ERO 内の厳密 (strict) ノードを越えてアドミッションの対象として検討される場合、ノードはそのリンクのリソースクラスを用いてリソースアフィニティを検証してもよい (MAY)。ノードが ERO の緩和 (loose) ノードを拡張するためにリンクを選択している場合、ノードはそれらのリンクのリソースクラスをリソースアフィニティに対して検証しなければならない (MUST)。ERO を拡張するために許容可能なリンクが見つからない場合、ノードはエラーコード「Routing Problem」およびエラー値「no route available toward destination」を持つ PathErr メッセージを送信すべきである (SHOULD)。
検証されるためには、リンクは以下の 3 つのテストに合格しなければならない (MUST)。
テストを正確に記述するために、上記のオブジェクト記述における定義を用いる。さらに以下を定義する。
Link-attr
リンクに関連付けられた属性を表す 32 ビットのベクタ。
3 つのテストは次のとおりである。
-
Exclude-any
このテストは、リンクが集合内のいずれかの属性を持つ場合に、そのリンクを検討対象から除外する。
(link-attr & exclude-any) == 0 -
Include-any
このテストは、リンクが集合内のいずれかの属性を持つ場合に、そのリンクを受け入れる。
(include-any == 0) | ((link-attr & include-any) != 0) -
Include-all
このテストは、リンクが集合内のすべての属性を持つ場合にのみ、そのリンクを受け入れる。
(include-all == 0) | (((link-attr & include-all) ^ include-
all) == 0)
リンクが許容可能であるためには、3 つのテストすべてに合格しなければならない (MUST)。テストに失敗した場合、ノードはエラーコード「Routing Problem」およびエラー値「no route available toward destination」を持つ PathErr メッセージを送信すべきである (SHOULD)。
Path メッセージが複数の SESSION_ATTRIBUTE オブジェクトを含む場合、最初の SESSION_ATTRIBUTE オブジェクトのみが意味を持つ。後続の SESSION_ATTRIBUTE オブジェクトは無視でき、転送する必要はない。
すべての RSVP ルータは、SESSION_ATTRIBUTE オブジェクトをサポートするか否かに関わらず、そのオブジェクトを変更せずに転送しなければならない (SHALL)。送信者と受信者の間のどこかに非 RSVP ルータが存在しても、このオブジェクトには影響しない。
5. Hello 拡張 (Hello Extension)
RSVP Hello 拡張は、RSVP ノードが隣接ノードに到達できないことを検出できるようにする。このメカニズムはノード間の障害検出を提供する。そのような障害が検出されると、リンク層の通信障害とほぼ同様に扱われる。このメカニズムは、リンク層障害の通知が利用できず、かつ番号なしリンクが使用されていない場合、またはリンク層が提供する障害検出メカニズムがタイムリーなノード障害検出に十分でない場合に使用することを意図している。
ノード障害検出は、特に複数の並列な番号なしリンクが存在する場合、リンク障害検出メカニズムとは同じではないことに注意すべきである。
Hello 拡張は、一方の側がこのメカニズムを使用し、もう一方の側が使用しないことを可能にするよう特に設計されている。隣接ノード障害検出はいつでも開始してもよい。これには、隣接ノードが最初に互いを認識したとき、または隣接ノードが Resv または Path 状態を共有しているときが含まれる。
Hello 拡張は、Hello メッセージ、HELLO REQUEST オブジェクト、および HELLO ACK オブジェクトから構成される。2 つの隣接ノード間の Hello 処理は、通常は設定される障害検出間隔の独立した選択をサポートする。各隣接ノードは自律的に HELLO REQUEST オブジェクトを発行できる。各要求は肯定応答によって応答される。Hello メッセージはまた、一方の隣接ノードが hello 要求の発行を抑制してもなお隣接ノード障害検出を実行できるだけの十分な情報を含む。Hello メッセージは、バンドルメッセージ内のサブメッセージとして含めてもよい。
隣接ノード障害検出は、隣接ノードの「インスタンス」値を収集して保存することによって実現される。値の変化が見られた場合、または隣接ノードがローカルに通知した値を正しく報告していない場合、その隣接ノードはリセットされたと推定される。隣接ノードの値が変化したことが確認されたとき、または隣接ノードとの通信が失われたときは、その隣接ノードに通知するインスタンス値も変更される。HELLO オブジェクトは、インスタンス値をポーリングし、提供するためのメカニズムを提供する。ポーリング要求には送信者のインスタンス値も含まれる。これにより、ポーリングの受信者は、そのポーリングを暗黙のポーリング応答として任意に扱うことができる。この任意の扱いは、一対の隣接ノードが処理するポーリングと応答の総数を削減できる最適化である。いずれの場合も、両側がこの最適化をサポートするときは、障害検出間隔ごとにポーリングと応答は 1 組だけになる。選択された間隔によっては、一方の隣接ノードだけが最適化をサポートする場合でも同じ利点が得られる。
5.1 Hello メッセージ形式 (Hello Message Format)
Hello メッセージは常に 2 つの RSVP 隣接ノード間で送信される。IP 送信元アドレスは送信側ノードの IP アドレスである。IP 宛先アドレスは隣接ノードの IP アドレスである。
HELLO メカニズムは直接の隣接ノード間での使用を意図している。HELLO メッセージが直接の隣接ノード間で交換されているときは、送出するすべての HELLO メッセージの IP TTL フィールドを 1 に設定すべきである (SHOULD)。
Hello メッセージの Msg Type は 20 である。Hello メッセージの形式は次のとおりである。
<Hello Message> ::= <Common Header> [ <INTEGRITY> ]
<HELLO>
5.2 HELLO オブジェクト形式 (HELLO Object formats)
HELLO クラスは 22 である。2 つの C_Type が定義されている。
5.2.1 HELLO REQUEST オブジェクト (HELLO REQUEST object)
Class = HELLO Class, C_Type = 1
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Src_Instance |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Dst_Instance |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
5.2.2 HELLO ACK オブジェクト (HELLO ACK object)
Class = HELLO Class, C_Type = 2
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Src_Instance |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Dst_Instance |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Src_Instance: 32 ビット
32 ビット値であり、送信者のインスタンスを表す。アドバタイザは隣接ノードごとの表現/値を維持する。この値は、送信者がリセットされたとき、ノードが再起動したとき、または隣接ノードとの通信が失われたときに変更しなければならず (MUST)、それ以外の場合は同じままである。このフィールドはゼロ (0) に設定してはならない (MUST NOT)。
Dst_Instance: 32 ビット
隣接ノードから受信した最も最近の Src_Instance 値。隣接ノードからこれまでに値が一度も見られていない場合、このフィールドはゼロ (0) に設定しなければならない (MUST)。
5.3 Hello メッセージの使用 (Hello Message Usage)
Hello メッセージは完全に任意である (OPTIONAL)。Hello メッセージ処理に参加することを望まないノードは、すべてのメッセージを無視してもよい。この節の残りは、送信者と同様に受信者も参加していると仮定して書かれている。特に、受信者に関する MUST および SHOULD の使用は、Hello メッセージ処理をサポートするノードにのみ適用される。
ノードは、状態が追跡されている各隣接ノードに対して、HELLO REQUEST オブジェクトを含む Hello メッセージを定期的に生成する。周期性は hello_interval によって規定される。この値は隣接ノードごとに設定してもよい (MAY)。デフォルト値は 5 ms である。
HELLO REQUEST オブジェクトを含むメッセージを生成するとき、送信者は Src_Instance フィールドに、自身の隣接ノードごとのインスタンスを表す値を設定する。この値は、エージェントが対応する隣接ノードと Hello を交換している間は変更してはならない (MUST NOT)。送信者はまた、Dst_Instance フィールドに、隣接ノードから最も最近受信した Src_Instance 値を設定する。参照用に、この変数を Neighbor_Src_Instance と呼ぶ。隣接ノードからこれまでに値を受信していない場合、またはこのノードが隣接ノードへの通信が失われたとみなす場合、Neighbor_Src_Instance はゼロ (0) に設定される。直前の hello_interval 間隔内に宛先ノードから HELLO REQUEST オブジェクトを受信した場合は、メッセージの生成を抑制すべきである (SHOULD)。
HELLO REQUEST オブジェクトを含むメッセージを受信すると、受信者は HELLO ACK オブジェクトを含む Hello メッセージを生成しなければならない (MUST)。受信者はまた、隣接ノードがリセットされていないことを検証すべきである (SHOULD)。これは、送信者の Src_Instance フィールド値を以前に受信した値と比較することによって行われる。Neighbor_Src_Instance 値がゼロであり、Src_Instance フィールドが非ゼロである場合、Neighbor_Src_Instance は新しい値で更新される。値が異なる場合、または Src_Instance フィールドがゼロである場合、ノードは通信が失われたものとして隣接ノードを扱わなければならない (MUST)。
HELLO REQUEST オブジェクトの受信者はまた、隣接ノードが受信者のインスタンス値を返送していることを検証すべきである (SHOULD)。これは、受信した Dst_Instance フィールドを、その隣接ノードに最も最近送信した Src_Instance フィールド値と比較することによって行われる。設定された間隔数の後も隣接ノードが誤った非ゼロ値を通知し続ける場合、ノードは通信が失われたものとして隣接ノードを扱わなければならない (MUST)。
HELLO ACK オブジェクトを含むメッセージを受信すると、受信者は隣接ノードがリセットされていないことを検証しなければならない (MUST)。これは、送信者の Src_Instance フィールド値を以前に受信した値と比較することによって行われる。Neighbor_Src_Instance 値がゼロであり、Src_Instance フィールドが非ゼロである場合、Neighbor_Src_Instance は新しい値で更新される。値が異なる場合、または Src_Instance フィールドがゼロである場合、ノードは通信が失われたものとして隣接ノードを扱わなければならない (MUST)。
HELLO ACK オブジェクトの受信者はまた、隣接ノードが受信者のインスタンス値を返送していることを検証しなければならない (MUST)。隣接ノードが Dst_Instance フィールドで誤った値を通知する場合、ノードは通信が失われたものとして隣接ノードを扱わなければならない (MUST)。
設定された数の hello_intervals 以内に隣接ノードから REQUEST または ACK オブジェクトのいずれを介してもインスタンス値を受信しない場合、ノードは隣接ノードと通信できないと推定しなければならない (MUST)。この数のデフォルトは 3.5 である。
上記のように通信が失われたか、または失われたと推定された場合、ノードは HELLO を再開始してもよい (MAY)。ノードが再開始する場合、以前の HELLO メッセージで通知した値とは異なる Src_Instance 値を使用しなければならない (MUST)。この新しい値は、リセットまたは再起動が発生するまで、あるいは別の通信障害が検出されるまで、対応する隣接ノードに通知し続けなければならない (MUST)。隣接ノードから新しいインスタンス値を受信していない場合、ノードは Dst_instance 値フィールドにゼロを通知しなければならない (MUST)。
5.4 マルチリンクに関する考慮事項 (Multi-Link Considerations)
前述のように、Hello 拡張はリンクごとの障害ではなくノード障害の検出を対象としている。隣接ノード間に 1 本のリンクしかない場合、または一対のノード間のすべてのリンクが障害となる場合、ノード障害とリンク障害の区別は実際には意味がなく、そのような障害の扱いはすでに述べている。隣接ノード間で複数のリンクが共有されている場合には、特別な考慮事項がある。隣接ノード間のリンクに番号が付されている場合、Hello は各リンク上で実行しなければならず (MUST)、前述のメカニズムが適用される。
リンクが番号なしである場合、リンク障害検出は Hello 以外の何らかの手段によって提供しなければならない (MUST)。各ノードは隣接ノードとの間で単一の Hello 交換を使用すべきである (SHOULD)。すべてのリンクが障害となった場合は、前の節で述べた値を受信しない場合と同じである。
5.5 互換性 (Compatibility)
Hello 拡張は他の RSVP メッセージの処理には影響しない。唯一の効果は、リンク (ノード) ダウンイベントを、そうでなければ宣言されるよりも早く宣言できるようにすることである。その状況に対する RSVP の応答は変わらない。
Hello 拡張は完全に後方互換である。Hello クラスには 0bbbbbbb という形式のクラス値が割り当てられている。実装に応じて、拡張をサポートしない実装は、Hello メッセージを黙って破棄するか、「Unknown Object Class」エラーで応答するかのいずれかである。いずれの場合も、送信者は発行した Hello に対する肯定応答を確認できない。
6. セキュリティに関する考慮事項 (Security Considerations)
原則として、これらの RSVP への拡張は RFC 2205[1] を超えるセキュリティ上の露出をもたらさない。しかし、トラストモデルに若干の変更がある。通常の RSVP セッションで送信されるトラフィックは、送信元アドレスと宛先アドレス、およびポート番号に従ってフィルタリングできる。この仕様では、フィルタリングは受信ラベルのみに基づいて行われる。このため、管理ドメインは LSP トンネルを確立できるドメインを制限したいと考えるかもしれない。これは、種々のポートにフィルタを設定して、LSP_TUNNEL_IPv4 (7) または LSP_TUNNEL_IPv6 (8) タイプの SESSION オブジェクトを持つ RSVP path メッセージに対する処理を拒否することによって実現できる。
7. IANA に関する考慮事項 (IANA Considerations)
IANA は RSVP プロトコルパラメータに値を割り当てる。本文書では、EXPLICIT_ROUTE オブジェクトと ROUTE_RECORD オブジェクトが定義されている。これらの各オブジェクトはサブオブジェクトを含む。この節では、サブオブジェクト番号の割り当てに関する規則を定義する。この節では、BCP 26「Guidelines for Writing an IANA Considerations Section in RFCs」[15] の用語を使用する。
EXPLICIT_ROUTE サブオブジェクトタイプ (EXPLICIT_ROUTE Subobject Type)
EXPLICIT_ROUTE サブオブジェクトタイプは、サブオブジェクトの機能を識別する 7 ビットの番号である。範囲の制限はない。すべての可能な値が割り当てに利用可能である。
[15] で概説されたポリシーに従い、0 - 63 (0x00 - 0x3F) の範囲のサブオブジェクトタイプは IETF Consensus アクションを通じて割り当てられ、64 - 95 (0x40 - 0x5F) の範囲のコードは First Come First Served として割り当てられ、96 - 127 (0x60 - 0x7F) の範囲のコードは Private Use 用に予約される。
ROUTE_RECORD サブオブジェクトタイプ (ROUTE_RECORD Subobject Type)
ROUTE_RECORD サブオブジェクトタイプは、サブオブジェクトの機能を識別する 8 ビットの番号である。範囲の制限はない。すべての可能な値が割り当てに利用可能である。
[15] で概説されたポリシーに従い、0 - 127 (0x00 - 0x7F) の範囲のサブオブジェクトタイプは IETF Consensus アクションを通じて割り当てられ、128 - 191 (0x80 - 0xBF) の範囲のコードは First Come First Served として割り当てられ、192 - 255 (0xC0 - 0xFF) の範囲のコードは Private Use 用に予約される。
以下の割り当てが本文書で行われる。
7.1 メッセージタイプ (Message Types)
Message Message
Number Name
20 Hello
7.2 クラス番号と C-Type (Class Numbers and C-Types)
Class Class
Number Name
1 SESSION
Class Types or C-Types:
7 LSP Tunnel IPv4
8 LSP Tunnel IPv6
10 FILTER_SPEC
Class Types or C-Types:
7 LSP Tunnel IPv4
8 LSP Tunnel IPv6
11 SENDER_TEMPLATE
Class Types or C-Types:
7 LSP Tunnel IPv4
8 LSP Tunnel IPv6
16 RSVP_LABEL
Class Types or C-Types:
1 Type 1 Label
19 LABEL_REQUEST
Class Types or C-Types:
1 Without Label Range
2 With ATM Label Range
3 With Frame Relay Label Range
20 EXPLICIT_ROUTE
Class Types or C-Types:
1 Type 1 Explicit Route
21 ROUTE_RECORD
Class Types or C-Types:
1 Type 1 Route Record
22 HELLO
Class Types or C-Types:
1 Request
2 Acknowledgment
207 SESSION_ATTRIBUTE
Class Types or C-Types:
1 LSP_TUNNEL_RA
7 LSP Tunnel
7.3 エラーコードとグローバルに定義されたエラー値サブコード (Error Codes and Globally-Defined Error Value Sub-Codes)
以下のリストは、[RFC2205] で定義されているエラーコードと値の基本リストを拡張する。
Error Code Meaning
24 Routing Problem
This Error Code has the following globally-defined
Error Value sub-codes:
1 Bad EXPLICIT_ROUTE object
2 Bad strict node
3 Bad loose node
4 Bad initial subobject
5 No route available toward
destination
6 Unacceptable label value
7 RRO indicated routing loops
8 MPLS being negotiated, but a
non-RSVP-capable router stands
in the path
9 MPLS label allocation failure
10 Unsupported L3PID
25 Notify Error
This Error Code has the following globally-defined
Error Value sub-codes:
1 RRO too large for MTU
2 RRO Notification
3 Tunnel locally repaired
7.4 サブオブジェクト定義 (Subobject Definitions)
C-Type 1 の EXPLICIT_ROUTE オブジェクトのサブオブジェクト:
1 IPv4 prefix
2 IPv6 prefix
32 Autonomous system number
C-Type 1 の RECORD_ROUTE オブジェクトのサブオブジェクト:
1 IPv4 address
2 IPv6 address
3 Label
8. 知的財産権に関する考慮事項 (Intellectual Property Considerations)
IETF は、本文書に含まれる仕様の一部または全部に関して主張されている知的財産権について通知を受けている。詳細については、主張されている権利のオンラインリストを参照されたい。
9. 謝辞 (Acknowledgments)
本文書には、以前の Internet-Draft に現れたアイデアおよびテキストが含まれている。本文書の著者は、それらのドラフトの著者に感謝したい。彼らは Steven Blake、Bruce Davie、Roch Guerin、Sanjay Kamat、Yakov Rekhter、Eric Rosen、および Arun Viswanathan である。また、本文書へのコメントについて Bora Akyol、Yoram Bernet、Alex Mondrus に感謝したい。
10. 参考文献 (References)
[1] Braden, R., Zhang, L., Berson, S., Herzog, S. および S. Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1, Functional Specification", RFC 2205, 1997 年 9 月.
[2] Rosen, E., Viswanathan, A. および R. Callon, "Multiprotocol Label Switching Architecture", RFC 3031, 2001 年 1 月.
[3] Awduche, D., Malcolm, J., Agogbua, J., O'Dell および J. McManus, "Requirements for Traffic Engineering over MPLS", RFC 2702, 1999 年 9 月.
[4] Wroclawski, J., "Specification of the Controlled-Load Network Element Service", RFC 2211, 1997 年 9 月.
[5] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y., Farinacci, D., Li, T. および A. Conta, "MPLS Label Stack Encoding", RFC 3032, 2001 年 1 月.
[6] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, 1997 年 3 月.
[7] Almquist, P., "Type of Service in the Internet Protocol Suite", RFC 1349, 1992 年 7 月.
[8] Nichols, K., Blake, S., Baker, F. および D. Black, "Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers", RFC 2474, 1998 年 12 月.
[9] Herzog, S., "Signaled Preemption Priority Policy Element", RFC 2751, 2000 年 1 月.
[10] Awduche, D., Hannan, A. および X. Xiao, "Applicability Statement for Extensions to RSVP for LSP-Tunnels", RFC 3210, 2001 年 12 月.
[11] Wroclawski, J., "The Use of RSVP with IETF Integrated Services", RFC 2210, 1997 年 9 月.
[12] Postel, J., "Internet Control Message Protocol", STD 5, RFC 792, 1981 年 9 月.
[13] Mogul, J. および S. Deering, "Path MTU Discovery", RFC 1191, 1990 年 11 月.
[14] Conta, A. および S. Deering, "Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6)", RFC 2463, 1998 年 12 月.
[15] Narten, T. および H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, 1998 年 10 月.
[16] Bernet, Y., Smiht, A. および B. Davie, "Specification of the Null Service Type", RFC 2997, 2000 年 11 月.
11. 著者のアドレス (Authors' Addresses)
- Daniel O. Awduche — Movaz Networks, Inc. / 7926 Jones Branch Drive, Suite 615 / McLean, VA 22102 / 電話: +1 703-298-5291 / 電子メール: [email protected]
- Lou Berger — Movaz Networks, Inc. / 7926 Jones Branch Drive, Suite 615 / McLean, VA 22102 / 電話: +1 703 847 1801 / 電子メール: [email protected]
- Der-Hwa Gan — Juniper Networks, Inc. / 385 Ravendale Drive / Mountain View, CA 94043 / 電子メール: [email protected]
- Tony Li — Procket Networks / 3910 Freedom Circle, Ste. 102A / Santa Clara CA 95054 / 電子メール: [email protected]
- Vijay Srinivasan — Cosine Communications, Inc. / 1200 Bridge Parkway / Redwood City, CA 94065 / 電話: +1 650 628 4892 / 電子メール: [email protected]
- George Swallow — Cisco Systems, Inc. / 250 Apollo Drive / Chelmsford, MA 01824 / 電話: +1 978 244 8143 / 電子メール: [email protected]
12. 完全な著作権表示 (Full Copyright Statement)
著作権 (C) The Internet Society (2001)。すべての権利は留保されている。
この文書およびその翻訳は、複製し、他者に提供することができ、また、これにコメントするか、その他の方法で説明するか、もしくはその実装を支援する派生著作物は、種類のいかんを問わず制限なく、全体または一部を準備、複製、公開、配布することができる。ただし、上記の著作権表示およびこの段落が、そのようなすべての複製および派生著作物に含まれていることを条件とする。ただし、この文書自体は、著作権表示または Internet Society その他のインターネット組織への参照を削除するなど、いかなる方法でも変更してはならない。ただし、インターネット標準を開発する目的で必要な場合、その場合はインターネット標準プロセスで定義された著作権の手続きに従わなければならず、または英語以外の言語に翻訳するために必要な場合はこの限りでない。
上記で付与された限定的な許可は永続的であり、Internet Society またはその後継者もしくは譲受人はこれを取り消さない。
本文書およびここに含まれる情報は「現状のまま (AS IS)」の基準で提供され、THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE は、明示的か黙示的かを問わず、ここに含まれる情報の使用が何らかの権利を侵害しないという保証、および商品性または特定目的への適合性に関する黙示の保証を含むがこれらに限定されないすべての保証を否認する。
謝辞 (Acknowledgement)
RFC Editor 機能への資金提供は現在 Internet Society によって行われている。