Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
 

RSVP の概要

RSVP の概要

RSVP プロトコルは、ルーターによって使用され、データフローパスに沿ったすべてのノードにサービス品質 (QoS) 要求を配信し、要求されたサービスの状態を確立して維持します。一般に、RSVP 要求では、データパスに沿った各ノードでリソースの予約が発生します。RSVP には以下の属性があります。

  • 単方向のデータフローでリソースの予約を行います。

  • データフローの受信者は、そのフローに使用されるリソース予約を初期化して維持でき図 1ます (を参照)。

  • ルーターとホストでソフトの状態を維持し、動的メンバーシップ変更とルーティング変更への自動適合をサポートします。

  • 現在および将来のルーティングプロトコルに依存していますが、ルーティングプロトコルそのものではありません。

  • さまざまなアプリケーションに適したいくつかの予約モデルまたはスタイルを提供します。

  • RSVP シグナル Lsp を介して送信できる IPv4 および IPv6 パケットの両方をサポートしています。

図 1: RSVP 予約要求とデータフローRSVP 予約要求とデータフロー

RSVP 操作の概要

RSVP は、各データフローを処理する独立したセッションを作成します。セッションは、宛先アドレス、オプションの宛先ポート、およびプロトコルの組み合わせによって識別されます。セッション内には、1つ以上の送信者を指定できます。各センダーは、送信元アドレスと送信元ポートの組み合わせによって識別されます。セッションのアナウンスプロトコルや人間の通信などのアウトオブバンドメカニズムを使用して、セッション id をすべての送信者と受信者に伝達します。

典型的な RSVP セッションには、以下の一連のイベントが含まれます。

  1. 潜在的なセンダーによって、セッションアドレスへの RSVP path メッセージ送信が開始されます。

  2. セッションに参加する受信者は、必要に応じて自身を登録します。たとえば、マルチキャストアプリケーションの受信者は IGMP に登録します。

  3. 受信者は path メッセージを受信します。

  4. 受信者は、送信元への適切な Resv メッセージを送信します。これらのメッセージにはフロー記述子があります。これは、パスに沿ったルーターによって使用され、リンクレイヤーのメディアで予約を行います。

  5. 送信者は Resv メッセージを受信し、アプリケーションデータの送信を開始します。

この一連のイベントは、必ずしも厳密に同期されるわけではありません。たとえば、受信者は送信者からの path メッセージを受信する前に自身を登録でき、アプリケーションデータはセンダーが Resv メッセージを受信する前にフローできます。Resv メッセージに実際の予約が含まれる前に配信されるアプリケーションデータは、通常、CoS 保証のない、リアルタイムではないトラフィックとして扱われます。

RSVP シグナリングプロトコルについて

RSVP は、MPLS ネットワーク上で帯域幅の割り当てと真のトラフィックエンジニアリングを処理する信号プロトコルです。LDP と同様に、RSVP は証拠開示メッセージとアドバタイズメントを使用して、すべてのホスト間で exchange LSP パス情報を取得します。ただし、RSVP には、MPLS ネットワークを介したトラフィックフローを制御する一連の機能も含まれています。LDP は、設定された IGP の最短パスをネットワーク経由のトランジット パスとして使用する方法に制限されています。一方、RSVP は、Constrained Shortest Path First(CSPF)アルゴリズムと Explicit Route Objects(EROs)の組み合わせを使用して、ネットワークを通過するトラフィックのルーティング方法を決定します。

基本的な RSVP セッションは、LDP セッションの確立とまったく同じ方法で確立されます。適切な通過インターフェイスで MPLS と RSVP の両方を設定することで、RSVP パケットの交換と Lsp の確立を可能にします。ただし、RSVP では、リンク認証、明示的な LSP パス、リンクの色分けを設定することもできます。

このトピックは、以下のセクションで構成されています。

RSVP の基礎

RSVP はその機能を実行するために、ネットワーク全体で単一方向とシンプレックスのフローを使用しています。受信ルーターは、RSVP path メッセージを開始し、それを下位ルーターに送信します。Path メッセージには、接続に必要なリソースに関する情報が含まれています。パス上の各ルーターは、予約に関する情報を管理し始めています。

Path メッセージが発信ルーターに到達すると、リソース予約が開始されます。アウトバウンドルーターは、着信ルーターに対して上位に予約メッセージを送信します。パス上の各ルーターは、予約メッセージを受信し、元の path メッセージのパスに従って、それを上流に送信します。受信ルーターが予約メッセージを受信すると、双方向のネットワークパスが確立されます。

RSVP セッションがアクティブになっている間、確立したパスはオープンされたままです。セッションは、セッション状態を30秒ごとに通知する追加のパスと予約メッセージを送信することによって維持されます。ルーターが3分間保守メッセージを受信しない場合は、RSVP セッションを終了し、別のアクティブなルーターを通じて LSP を再ルーティングします。

帯域幅予約の要件

帯域幅予約が構成されている場合、予約メッセージは LSP 全体で帯域幅の値を伝達します。ルーターは、特定の LSP のリンク上で指定された帯域幅を確保する必要があります。帯域幅の合計が特定の LSP セグメントで利用可能な帯域幅を超える場合、LSP は別の LSR 経由で再ルーティングされます。帯域幅の予約をサポートするセグメントがない場合、LSP のセットアップは失敗し、RSVP セッションは確立されません。

明示的ルートオブジェクト

明示的ルートオブジェクト (EROs) は、指定された LSRs のリストへの LSP ルーティングを制限します。デフォルトでは、RSVPメッセージはネットワーク通知の最短パスによって決定IGPたパスに従います。ただし、構成された ERO が存在する場合、RSVP メッセージは指定されたパスに従います。

EROs は2種類の命令で構成されています。緩やかなホップと厳密なホップ。緩やかなホップが設定されると、LSP をルーティングする1つ以上の転送用の LSRs を識別します。ネットワーク IGP は、受信ルーターから、最初の緩やかなホップへの正確なルートまたは1つの緩やかなホップから次のようなトラフィックを特定します。緩やかなホップは、特定の LSR が LSP に含まれていることのみを指定します。

厳格なホップが設定されている場合、LSP をルーティングする必要がある正確なパスを特定します。Strict ホップ EROs では、RSVP メッセージの送信に使用されるルーターの正確な順序を指定します。

緩やかなホップと厳密なホップ EROs を同時に構成できます。この場合、IGP は厳しいホップ間のルートを決定し、strict ホップ構成は特定の LSP パスセグメントの正確なパスを指定します。

図 2は、EROs を使用する典型的な RSVP シグナル LSP を示しています。

図 2: EROs を使用した典型的な RSVP シグナル LSPEROs を使用した典型的な RSVP シグナル LSP

に示すトポロジーでは 図 2 、トラフィックがホスト C1 からホスト C2 にルーティングされます。LSP はルーター R4 またはルーター R7 を通過できます。LSP で R4 を使用するように設定するには、ルースホップまたは strict ホップを指定し、LSP のホップとして R4 を規定することができます。ルーター R4、R3、R6 を通る特定のパスを強制するには、3 つの LSR を通してス厳しいホップ ERO を設定します。

最も制約された最短パス

IGPs は最短パスの First (SPF) アルゴリズムを使用して、ネットワーク内でトラフィックをルーティングする方法を決定しますが、RSVP は、制限された最短パスの最初 (CSPF) アルゴリズムを使用して、以下の制約の対象となるトラフィックパスを計算します。

  • LSP 属性 — リンクカラーリング、帯域幅要件、EROs などの管理グループ

  • リンク属性 — 特定のリンクと使用可能な帯域幅の色

これらの制約は、TED (トラフィックエンジニアリングデータベース) に保持されます。このデータベースは、CSPF に最新のトポロジー情報、現在の reservable 帯域幅、リンクの色を提供しています。

どのパスを選択するかを決定する際に、CSPF は以下のルールに従います。

  • LSP は、最も優先度の高い LSP(セットアップ優先度値が最も低い LSP)から始めて、1 つ 1 つ計算します。同じ優先度の Lsp のうち、CSPF は、最も帯域幅の高い要件を持つものから開始します。

  • 全二重ではないリンクのトラフィックエンジニアリングデータベースを排除し、十分な reservable 帯域幅を確保できません。

  • LSP 設定にincludeステートメントが含まれている場合、含まれているすべてのカラーを共有していないすべてのリンクが排除されます。

  • LSP 設定にexcludeステートメントが含まれている場合、除外された色を含むすべてのリンクが排除されます。リンクがカラーを持っていない場合は、それが受け入れられます。

  • LSP のアウトバウンド ルーターに向かう最短の道のりを、すべての EROS を考慮して見つけ出します。たとえば、パスがルーター A を通過する必要がある場合、2つの個別の SPF アルゴリズムが計算されます。1つは受信ルーターからルーター A へ、1台はルーター A からアウトバウンドルーターまでです。

  • 複数のパスのコストが同じ場合は、最後ホップ アドレスを持つパスを LSP の宛先と同じパスを選択します。

  • 複数の等コストパスが残っている場合は、ホップ数が最小のパスを選択します。

  • 複数の等しいコストのパスが残っている場合は、LSP に設定されている CSPF 負荷分散ルールを適用します。

リンクの色分け

RSVP では、CSPF path 選択用の管理グループを構成できます。管理グループには、通常、カラーで名前を付け、数値を割り当て、適切なリンクのために RSVP インターフェイスに適用します。数値が小さいほど、優先度は高くなります。

管理グループを構成すると、その色のリンクを TED に除外するか、含めないか、または無視することができます。

  • 特定の色を除外すると、その色の管理グループを持つすべてのセグメントが CSPF path の選択から除外されます。

  • 特定のカラーを選択した場合は、該当するカラーのセグメントだけが選ばれます。

  • この色をエクスクルードまたはインクルードしていない場合は、管理グループに関連付けられ、特定のセグメントに適用されるメトリックが、そのセグメントのパスコストを決定します。

最も低いパスコストを持つ LSP が TED のに選択されます。

FRR 用の RSVP TE プロトコルの拡張

Junos OS リリース16.1 から開始しています。更新間隔独立 RSVP (RI-RSVP) 定義の RFC 8370 をサポートするプロトコル拡張である TE、高速再ルーティング (FRR) 機能が導入されました。拡張性の向上を可能にするためのファシリティ保護ラベルスイッチパス (Lsp) の収束時間が短縮され、定期的な更新による RSVP シグナリングメッセージのオーバーヘッドが減少します。Junos RSVP-TE は、RFC 4090 で規定されている FRR ファシリティ回避用の RI-RSVP をサポートするプロトコル拡張機能を含む拡張された FRR の RI-RSVP モードで動作します。

Junos に実装されている RI-RSVP プロトコル拡張には、完全に下位互換性があります。混合環境では、この機能が含まれていない Lsp スキャンノードのサブセットがあるため、Junos RSVP TE が拡張 FRR モードで動作している場合、その新しいプロトコル拡張機能が自動ではないノードとの間で自動的に延長.

拡張 FRR の一部として、多数の変更が行われ、新しいデフォルトを採用しました。これらについては、ここに記載されています。

  • RSVP-TEデフォルトでは、「拡張」FRR(RI-RSVP モード)を実行します。このモードでは、拡張シナリオを容易に実行するための拡張機能が含まれます。このような新しいプロトコル拡張は、非拡張型の r バイパスコマンドを使用してルーター上で無効にすることができます。

  • デフォルトでは、RFC 2961 で定義されている RSVP 更新を削減する拡張機能が有効になっています。ユーザーは、信頼性の低いコマンド (下記を参照) を使用して、これらの機能を無効にすることができます。

    注:

    拡張された FRR または RI-RSVP の拡張により、ノード id ベースのこの機能はデフォルトで有効になっており、ノード id をベースとした Hello メッセージの交換が必要になります。コマンドを使用して、ノード id をベースnode-helloとした状態を無効にすることができます。強化された FRR または RI-RSVP 拡張では、更新を削減する拡張機能とノード id ベースの Hello メッセージが重要になります。これらのいずれかを無効にすると、ノード上の拡張 FRR 拡張機能が自動的に無効になります。

  • RSVP メッセージのデフォルト更新時間は、30秒から20分に増えました。

  • 新しいデフォルト更新時間には、キープマルチプライヤー(3) のデフォルト値が適用されます。

  • デフォルトでは、ローカル reversion は無効になっています。Node ・ Los [edit protocols rsvp node-hello]の既存の CLI 構成はまだ利用可能ですが、アクションは冗長化されています。この機能が有効になっている場合、構成が拡張 FRR と連携していないことを示すメッセージが表示されます。

  • RSVP 更新の削減を無効にするために、メッセージの信頼性を無効にする既存のコマンドが使用されるようになりました。更新を削減する前のデフォルトに戻すには、以下deleteのコマンドのバージョンを使用します。

    • 特定no-reliableのインターフェイスに設定すると、そのインターフェイスを通過するすべての lsp に対して、frr の拡張性の強化が自動的に実行されないようになります。同様に、r 施設の保護機能を強化せずに RSVP TE を実行するために、更新を削減せずに、各インターフェイスの更新の削減を無効にします。次のいずれかのコマンドを使用します。

      • [edit protocols rsvp interface name no-reliable]

      • [edit logical-systems name protocols rsvp interface name no-reliable]

  • LSP のローカルな修復が行われている場合、または lsp がバックアップ LSP シグナリングで更新されている場合、グレースフルリスタートおよび無着陸アクティブルーティング (NSR) はサポートされていません。この制限はすでに実装されています。これは、FRR ローカル修復中の GR または NSR スイッチオーバーによって複数の障害が発生した場合に生じます。

  • 次の操作コマンドは、FRR ファシリティ保護のための RSVP TE プロトコル拡張に導入された新しい手順に関する新しい情報を含むように更新しています。

    • show rsvp version拡張 FRR プロシージャが有効になっているかどうかを表示します。

    • show rsvp neighbor detail拡張された FRR プロシージャが隣接ノードで有効になっているかどうかを表示します。

    • show rsvp interface detail条件 PathTear 統計を表示します。

    • show rsvp statistics他の統計とともに、条件付きの PathTear の送信および受信した統計を表示します。

    • show rsvp session extensiveノードがマージポイントであるかどうかを表示し、結合点がある場合は、ローカル修復 (PLR) アドレスのポイントを表示します。

  • メッセージバンドルを有効または無効にする前の CLI 設定オプションは廃止されました (既存の構成は受け入れられるが、[設定の表示] に警告が表示される)。これらのコマンドは以下のとおりです。

    • [edit protocols rsvp interface name aggregate]

    • [edit logical-systems name protocols rsvp interface name aggregate]

    • [edit protocols rsvp interface name no-aggregate]

    • [edit logical-systems name protocols rsvp interface name no-aggregate]

  • 以下の CLI 設定オプションは、現在の変更によって冗長化されています (既存の構成は受け入れられるが、[設定の表示] に警告が表示される):

    • [edit protocols rsvp interface name reliable]

    • [edit logical-systems name protocols rsvp interface name reliable]

RSVP プロトコルの実装 Junos OS

RSVP の Junos 実装では、RSVP バージョン1がサポートされます。このソフトウェアには、すべての必須オブジェクトと RSVP メッセージタイプがサポートされており、整合性オブジェクトを介してメッセージ整合性とノード認証をサポートします。

Junos RSVP ソフトウェアの主な目的は、MPLS ラベル交換パス (Lsp) 内での動的シグナリングをサポートすることです。インターネット上でのリソース予約は、Junos OS 実装の第2の目的としてのみサポートされています。リソースの予約は二次的なものであるため、Junos RSVP ソフトウェアは次の機能をサポートしていません。

  • IP マルチキャストセッション。

  • トラフィック制御。ソフトウェアは、リアルタイムのビデオまたはオーディオセッションに対してリソースの予約を行うことはできません。

サポートされているプロトコルメカニズム、パケット処理、および RSVP オブジェクトに関しては、ソフトウェアの Junos OS 実装を他の RSVP 実装と相互運用できます。

RSVP 認証

Junos OSは、RFC 2747で説明されているRSVP認証スタイル(マルチベンダの互換性を許可)と、インターネットドラフト draft-ietf-rsvp-md5-03.テキストで説明されているRSVP認証スタイルの両方をサポートしています。Junos OS では、デフォルトで Internet draft draft-ietf-rsvp-md5-08 に記載されている認証スタイルが使用されます。ルーターがネイバーからRFC 2747スタイルのRSVP認証を受信すると、そのネイバーに対してこの認証スタイルに切り替わりします。各近隣ルーターの RSVP 認証スタイルは個別に決定されます。

RSVP および IGP Hello パケットとタイマー

RSVP は、内部ゲートウェイプロトコル (IGP) のステータス (IS-IS または OSPF) を監視し、IGP プロトコルを使用してノードに障害が発生した場合を検知します。IGP プロトコルが近隣ノードを宣言すると (hello パケットが受信されなくなるため)、その近隣ノードも停止します。ただし、IGP のプロトコルと RSVP は、近隣ノードを導入する際には独立して機能します。

Junos OS では、RSVP は通常 IGP hello パケット検出を使用して、ノード障害をチェックします。IS-IS または OSPF hello タイマーに短時間で設定することで、これらのプロトコルでノード障害を迅速に検出できます。ノードに障害が発生するかノード障害が検知されると、パスエラーメッセージが生成されますが、RSVP セッションはダウンしても、IGP の隣接機器は稼働したままになっています。

RSVP/los は、IGP が特定の近隣ノードを認識しない場合に依存することがあります (たとえば、IGP がインターフェイスで有効になっていない場合)、または IGP が RIP (IS-IS または OSPF ではない) の場合に適しています。また、他のベンダーの機器も RSVP hello パケットに基づいて RSVP セッションを監視するように設定されている場合があります。また、この機器は RSVP hello パケットが失われたことにより、RSVP セッションを停止させることもあります。

短い RSVP hello タイマーを設定することは推奨されていません。失敗した隣接ノードのクイック検出が必要な場合は、短い IGP (OSPF または IS-IS) hello タイマーを構成します。

OSPF と IS-IS は、ルーティングプロトコルやその他のプロセスがルーターの処理能力に負担をかける場合でも、迅速な hello メッセージの送受信を信頼性の高い方法で管理するインフラストラクチャを備えています。同じ状況下では、近傍が正常に機能しているにもかかわらず、RSVP モードが途中でタイムアウトすることがあります。

RSVP メッセージタイプ

RSVP は以下のタイプのメッセージを使用して、データフローのパスを確立して削除し、予約情報を確立し、削除し、予約データを取得し、確認してから、エラーを報告します。

Path メッセージ

各センダーホストは、ユニキャストおよびマルチキャストルーティングプロトコルによって提供されるルートに沿って、パスメッセージを下流に送信します。Path メッセージは、アプリケーションデータの正確なパスに従って、ルーターにパス状態が作成されるため、ルーターはセッションの前ホップと次ホップノードを学習できるようになります。Path メッセージは定期的に送信され、パスの状態を更新します。

更新間隔は、 ( 秒で示す定期的な更新タイマー)と呼ばれる refresh-time 変数によって制御されます。ルーターが指定された数の連続する path メッセージを受信できない場合、パスの状態はタイムアウトになります。この数値は、というkeep-multiplier変数で指定されています。パスの状態は( + keep-multiplier 0.5)x 1.5 x refresh-time )秒に維持されます。

Resv メッセージ

各受信者ホストは、送信側および送信側のアプリケーションに対して、予約要求 (Resv) メッセージを上流から送信します。Resv メッセージはパスメッセージの逆パスに従っている必要があります。Resv メッセージは、各ルーターにおいて、その過程で予約状態を作成し、維持します。

Resv メッセージは、予約状態を更新するために定期的に送信されます。更新間隔は同じ更新時間変数によって制御され、予約状態は( keep-multiplier + 0.5)x 1.5 x refresh-time )秒に維持されます。

パスの切り取りメッセージ

PathTear メッセージは、パス上のすべてのルーターで、パスの状態と、依存する予約状態を削除 (ティアオフ) します。パスのティアオフメッセージは path メッセージと同じパスに従います。PathTear は通常、送信元アプリケーションまたはパスの状態がタイムアウトになった場合、ルーターによって開始されます。

パスの切り取りメッセージは必須ではありませんが、ネットワークのパフォーマンスを向上させるのは、ネットワークリソースを迅速に解放するためです。PathTear メッセージが失われたり、生成されなかったりすると、パスの状態が更新されないと、最終的にタイムアウトになり、パスに関連付けられているリソースが解放されます。

ResvTear メッセージ

ResvTear メッセージは、パスに従って予約状態を削除します。これらのメッセージは、セッションの送信者に向かって上流へと移動します。意味では、ResvTear メッセージは Resv メッセージの逆です。ResvTear メッセージは通常、予約状態がタイムアウトになった場合に、受信側アプリケーションまたはルーターによって開始されます。

ResvTear メッセージは必須ではありませんが、ネットワークのパフォーマンスを向上させるのは、ネットワークリソースを迅速に解放するためです。ResvTear メッセージが失われるか生成されない場合、予約状態は更新されなかった場合、最終的にタイムアウトになり、予約に関連付けられたリソースが解放されます。

PathErr メッセージ

パスエラーが発生した場合、通常、path メッセージ内のパラメーターの問題が原因で、ルーターはユニキャスト PathErr メッセージを、path メッセージを発行した送信者に送信します。PathErr メッセージはアドバイザリです。これらのメッセージは、パスの状態を変更することはありません。

ResvErr メッセージ

予約要求が失敗すると、関連するすべての受信者に対して、ResvErr エラーメッセージが配信されます。ResvErr メッセージはアドバイザリです。これらのメッセージは、予約状態を変更することはありません。

ResvConfirm メッセージ

受信者は予約要求の確認を要求できます。この確認は、ResvConfirm メッセージと共に送信されます。RSVP フローの複雑なルールがあるため、確認メッセージでは、パス全体がエンドツーエンドで確認されるとは限りません。したがって、ResvConfirm メッセージは、潜在的な成功の保証ではなく、指示であることを示しています。

ジュニパーネットワークス ResvConfirm メッセージを使用して確認を要求しない。ただし、ジュニパーネットワークスの機器からリクエストを受信した場合は、ResvConfirm メッセージを送信できます。

RSVP 自動メッシュの理解

BGP にサイトを追加し、RSVP シグナリングを使用する Vpn を MPLS 場合、顧客エッジ (CE) デバイスを追加するのに必要なものよりも、プロバイダエッジ (PE) ルーターを追加するためにより多くの構成が必要になります。RSVP 自動メッシュは、このように設定の負荷を軽減するのに役立ちます。

サービスプロバイダは多くの場合、BGP と MPLS Vpn を使用してネットワークを効率的に拡張しながら、収益を生み出すサービスを提供しています。このような環境では、BGP を使用して VPN ルーティング情報をサービス プロバイダのネットワークに分散し、MPLS を使用して VPN トラフィックをある VPN サイトから別の VPN サイトに転送します。BGP と MPLS Vpn はピアモデルに基づいています。既存の VPN に新しい CE デバイス (サイト) を追加するには、新しいサイトに CE ルーターを設定し、CE ルーターに接続された PE ルーターを構成する必要があります。VPN に参加している他のすべての PE ルーターの設定を変更する必要はありません。その他の PE ルーターは、新しいサイトに関連付けられたルートについて、自動検出 (AD) と呼ばれるプロセスを自動的に学習します。

ネットワークに新しい PE ルーターを追加する必要がある場合、要件は多少異なります。BGP と MPLS VPN では、BGP セッションが完全にメッシュされ、ネットワーク内のすべての PE ルーター間で、PE ルーターから PE へのルーター MPLS ラベル交換パス (Lsp) のフルメッシュが存在する必要があります。新しい PE ルーターをネットワークに追加する場合、既存のすべての PE ルーターを新しい PE ルーターとピアに再構成する必要があります。BGP ルートのリフレクタを設定すると (BGP に対するフルメッシュの要件を緩和するために)、(LDP) を MPLS のシグナリングプロトコルとして設定することで、構成作業の大部分を軽減できます。

ただし、RSVP シグナル Lsp のフルメッシュで構成されたネットワークに新しい PE ルーターを追加する必要がある場合は、各 PE ルーターを新しい PE ルーターとピアリレーションシップを持つように再構成する必要があります。この特定の運用シナリオに対応するために、RSVP 自動メッシュを構成できます。RSVP の自動メッシュを有効にすると、新しい PE ルーターと既存の PE ルーターとの間で RSVP Lsp が動的に作成されるため、すべての PE ルーターを手動で再設定する必要がなくなります。動的な LSP 作成を適切に機能させるには、参加しているすべての PE ルーター間でルートを交換するように BGP を構成する必要があります。2つの BGP ピアがルートを交換しない場合、その間に動的 LSP を構成することはできません。ローカル ルーターの inet.3 ルーティング テーブル には、それぞれの潜在的な IBGP ネクスト ホップ(将来の潜在的な PE ルーターまたは LSP 宛先)にラベル付けされたルートを含める必要があります。

RSVP には、LDP では提供されていない多数の機能が含まれています。これには、高速再ルーティング、エンドポイント制御、リンク管理などがあります。Rsvp 自動メッシュは rsvp の運用と保守の要件を削減するのに役立ち、より大規模で複雑なネットワークに RSVP を導入することを可能にします。

この情報は IGP によって分散されているため、すべての PE ルーターがネットワーク内のすべての PE ルーターにアクセスできます。PE ルーターは、そのような LSP が必要であることを認識できる限り、ネットワーク内の他の PE ルーターにポイントツーポイント RSVP LSP を設定できます。Lsp の完全なメッシュを PE ルーター間で構築するには、各 PE ルーターでフルメッシュを構成する PE ルーターが他にどれであるかを確認する必要があります。

注:

Junos OS では、RSVP 自動メッシュは、階層rsvp-teレベルの[edit routing-options dynamic-tunnels dynamic-tunnel-name]設定ステートメントを使用して設定されます。構成rsvp-te文は、ルーティングインスタンス内でプロバイダトンネルオプションとして使用することもできます。Provider tunnel オプションとして実装されrsvp-teた場合、は rsvp 自動メッシュを構成するのではなく、マルチプロトコル BGP マルチキャスト vpn 用の rsvp ポイントツーマルチポイント lsp を構成するために使用されます。

RSVP 予約スタイル

予約要求には、予約スタイルを指定するためのオプションが含まれています。予約スタイルは、同一セッション内のさまざまなセンダーの予約方法と送信者の選択方法を定義します。

2つのオプションで、同一セッション内のさまざまなセンダーの予約方法を指定します。

  • 個別の予約 —各レシーバは、各アップストリームの送信者に対して独自の予約を確立します。

  • 共有予約 — すべてのレシーバーが、多くの送信者と共有されている 1 つの予約を作成します。

送信者の選択方法を以下の2つのオプションで指定します。

  • 明示的な送信者 — 選択した送信者すべての一覧を表示します。

  • ワイルドカード送信者 — すべての送信者を選択し、セッションに参加します。

以下の予約スタイルは、これら4つのオプションの組み合わせによって定義されています。

  • 固定フィルター(FF) — この予約スタイルは、明示的な送信者間の個別の予約で構成されます。固定フィルタ・スタイルの予約を使用するアプリケーションの例として、ビデオ・アプリケーションとユニキャスト・アプリケーションがあります。どちらも、送信者ごとに別々の予約を持つフローが必要です。固定フィルター予約形式は、デフォルトで RSVP Lsp で有効になっています。

  • ワイルドカード フィルター(WF) — この予約スタイルは、ワイルドカード送信者間の共有予約で構成されています。この種類の予約では、すべてのセンダーに帯域幅が割り当てられ、すべてのセンダーに対して上流への伝播が行われます。新しいセンダーが表示されると自動的に拡張します。ワイルドカードフィルタ予約用のサンプルアプリケーションは、各送信者が個別のデータストリームを送信するオーディオアプリケーションです。通常、一度に送信するセンダーの数はごくわずかです。このようなフローでは、送信者ごとに個別の予約が必要になるわけではありません。1つの予約で十分です。

  • 共有明示的(SE) — この予約スタイルは、明示的な送信者間の共有予約で構成されています。この種類の予約では、限定されたグループのセンダーの帯域幅を予約します。サンプルアプリケーションは、ワイルドカードフィルター予約で説明するものと同様のオーディオアプリケーションです。

RSVP 更新の削減

RSVP は、各ルーターのパスと予約状態を維持するために、ソフト状態に依存しています。対応する更新メッセージが定期的に送信されていない場合は、最終的には状態がタイムアウトになり、予約が削除されます。また、RSVP は信頼性保証のない IP データグラムとして制御メッセージを送信します。定期的な更新メッセージによって、Path または Resv メッセージがときどき失われることに対処します。

RFC 2961 に基づく RSVP 更新リダクション拡張は、メッセージ損失を処理するために定期的な更新メッセージに依存することにより発生する次の問題を解決します。

  • 拡張性—拡張に関する問題は、更新メッセージの定期的な送信と処理のオーバーヘッドによって発生し、RSVP セッションの数が増えるにとって増加します。

  • 信頼性と遅延: 信頼性と遅延の問題は、非リファレンスRSVPメッセージの喪失、または PathTearや PathErrなどのRSVPメッセージの1回限りによる原因です。このような損失からの復旧にかかる時間は、通常、更新間隔と keepalive タイマーに関連しています。

Rsvp 共通ヘッダーで refresh reduction (RR) 対応ビットを有効にすることによって、非表示の更新削減機能が提供されます。このビットは、RSVP 隣接関係の間でのみ重要です。

RSVP の更新を削減するには、以下の機能が含まれます。

  • バンドルメッセージを使用した RSVP メッセージのバンドル

  • メッセージ処理のオーバーヘッドを削減する RSVP メッセージ ID

  • メッセージ ID、メッセージ Ack、およびメッセージ Nack を使用した信頼性の高い RSVP メッセージ配信

  • 概要の更新により、すべての更新間隔で送信される情報量を削減します。

RSVP 更新リダクション仕様(RFC 2961)を使用すると、ルーターで上記の機能の一部またはすべての機能を有効にできます。また、近隣ノードの更新削減機能を検出するためにルーターが使用するさまざまな手順についても説明します。

Junos OS は、すべての refresh リダクション拡張機能をサポートします。一部は、有効または無効にすることもできます。Junos OS は、メッセージ ID をサポートするため、Path および Resv メッセージに対してのみ信頼性の高いメッセージ配信を実行できます。

RSVP の更新を削減する方法については、「 rsvp 更新の削減の構成」を参照してください。

RSVP の MTU シグナリング

データ 最大送信単位(MTU)は、ネットワークで送信できる最大規模のパケットまたはフレーム(単位はバイト)です。MTU が大きすぎると、再送が発生する可能性があります。MTU が小さすぎると、ルーターは比較的多くのヘッダーのオーバーヘッドと受信確認を送信して処理できるようになる可能性があります。さまざまなプロトコルに関連付けられた Mtu にはデフォルト値があります。インターフェイスで MTU を明示的に設定することもできます。

さまざまな MTU サイズを持つ一連のリンクを使用して LSP を作成すると、受信ルーターは LSP パスに存在する最小の MTU を把握できません。デフォルトでは、LSP の MTU は1500バイトです。

この MTU が中間リンクの1つの MTU よりも大きい場合、MPLS パケットが断片化されないため、トラフィックは破棄される可能性があります。また、受信ルーターは、LSP の制御プレーンが引き続き正常に機能するため、この種のトラフィック損失を認識していません。

MPLS Lsp でこのようなパケットロスを防止するには、RSVP に MTU シグナリングを構成できます。この機能は RFC 3209 に記載されています。ジュニパーネットワークスは、RSVP の MTU シグナリング用統合サービスオブジェクトをサポートしています。統合サービスオブジェクトは、Rfc 2210 および2215に記載されています。RSVP の MTU シグナリングはデフォルトで無効になっています。

MTU の不一致によるパケットロスを回避するには、受信ルーターで以下を実行する必要があります。

  • RSVP LSP の MTU を信号します。MTU 不一致によるパケット ロスを防ぐために、イングレス ルーターは、LSP が取得するパスに沿って最小 MTU 値が何かを知る必要があります。この MTU 値を取得すると、受信ルーターはそれを LSP に割り当てることができます。

  • フラグメント パケット — 割り当てられた MTU 値を使用すると、MTU のサイズを超えるパケットは、MPLS でカプセル化して RSVP 信号 LSP を使用して送信される前に、イングレス ルーター上の小さなパケットにフラグメント化できます。

受信ルーターで MTU シグナリングとパケットフラグメンテーションの両方を有効にすると、このルーターの RSVP LSP に解決されるすべてのルートがシグナル MTU 値を使用します。この機能を構成する方法の詳細については、「 RSVP における MTU シグナリングの構成」を参照してください。

以下のセクションでは、RSVP でのシグナリングの動作 MTU について説明します。

RSVP での正しい MTU の通知方法

RSVP で正しい MTU が通知される方法は、ネットワークデバイス (ルーターなど) が RSVP の MTU シグナリングを明示的にサポートしているかどうかによって変化します。

ネットワークデバイスが RSVP の MTU シグナリングをサポートしている場合は、MTU シグナリングを有効にすると、以下のことが行われます。

  • MTU は、受信ルーターから送信ルーターへ、Adspec オブジェクトを介して送信されます。このオブジェクトを転送する前に、受信ルーターは、path メッセージが送信されるインターフェイスに関連付けられた MTU 値に入力します。パスの各ホップでは、Adspec オブジェクト内の MTU 値が、受信した値および送信インターフェイスの値の最低条件に更新されます。

  • 受信ルーターは、トラフィック仕様 (Tspec) オブジェクトを使用して、送信するトラフィックのパラメーターを指定します。イングレス ルーターの Tspec オブジェクトに対してシグナリングされた MTU 値は、最大 MTU 値(M Series および T Series ルーターの場合は 9192 バイト、PTX シリーズ パケット トランスポート ルーター の場合は 9500 バイト)です。この値は、送信ルーターへのルートを変更するわけではありません。

  • Adspec オブジェクトが送信ルーターに到着すると、そのパスに対して適切な MTU 値になります (つまり、検出された MTU の最小値です)。送信ルーターは、Adspec オブジェクトの MTU 値と Tspec オブジェクトの MTU 値を比較します。また、Resv メッセージ内の Flowspec オブジェクトを使用して、小規模な MTU を通知します。

  • 受信ルーターに Resv オブジェクトが到着すると、このオブジェクトの MTU 値が LSP を使用する次ホップの MTU として使用されます。

RSVP の MTU シグナリングをサポートしないデバイスが存在するネットワークでは、以下のような問題が発生する可能性があります。

  • 送信ルーターが RSVP の MTU シグナリングをサポートしていない場合、MTU はデフォルトで1500バイトに設定されます。

  • RSVP の MTU シグナリングをサポートしていないジュニパーネットワークス伝送ルーターは、デフォルトで Adspec オブジェクトの MTU 値を1500バイトに設定します。

送信 MTU 値の確認

送信 MTU 値は、アウトゴーイングインターフェイスの MTU 値と比較して、Adspec オブジェクトで受信した値のうち、小さい方を示します。アウトゴーイングインターフェイスの MTU 値は、以下のように決定されます。

  • 階層レベルの[family mpls]下で MTU 値を設定した場合、この値はシグナルされます。

  • MTU を設定していない場合、 inet MTU はシグナルステートになります。

RSVP の制限でシグナリング MTU

RSVP におけるシグナリングの MTU には、以下の制限があります。

  • MTU の値を変更すると、以下の状況で一時的にトラフィックが失われる可能性があります。

    • リンク保護とノード保護の場合、バイパスの MTU はバイパスがアクティブになる時点でのみ通知されます。新しいパス MTU 伝達されるまでの間、MTU 不一致が原因でパケットロスが発生する可能性があります。

    • 高速再ルーティングの場合、detour がアクティブになるまではパスの MTU が更新され、受信ルーターで MTU の更新遅延が発生します。MTU が更新されるまで、MTU 不一致があるとパケットロスが発生する可能性があります。

      どちらの場合も、detour またはバイパス MTU よりも大きいパケットだけが失われます。

  • MTU が更新されると、次のホップの変更がトリガーされます。次ホップの変化によってルート統計が失われる原因となっています。

  • RSVPでのMTUのMTUサポートされる最小パケット数は1,488バイトです。この値により、false または誤って設定された値が使用されるのを防ぎます。

  • シングルホップ Lsp の場合、 showコマンドによって表示される MTU 値は RSVP シグナル値です。ただし、この MPLS 値は無視され、正しい IP 値が使用されます。

リリース履歴テーブル
リリース
説明
16.1
Junos OS リリース16.1 から開始しています。更新間隔独立 RSVP (RI-RSVP) 定義の RFC 8370 をサポートするプロトコル拡張である TE、高速再ルーティング (FRR) 機能が導入されました。拡張性の向上を可能にするためのファシリティ保護ラベルスイッチパス (Lsp) の収束時間が短縮され、定期的な更新による RSVP シグナリングメッセージのオーバーヘッドが減少します。