RSVP の概要
RSVP の概要
RSVPプロトコルは、ルータがQoS要求をデータフロー経路上の全ノードに配信し、要求されたサービスの状態を確立・維持するために使用されます。RSVPのリクエストは、一般的にデータパス上の各ノードでリソースの予約につながる。RSVPは以下の属性を持つ。
一方向性のデータフローに対してリソースの予約を行う。
図 1に示すように、データフローの受信者がそのフローに使用されるリソース予約を開始し、維持することを可能にする。
ルーターとホストのソフトステートを維持し、動的なメンバーシップの変更とルーティングの変更への自動適応を優雅にサポートする。
現在および将来のルーティングプロトコルに依存するが、ルーティングプロトコルそのものではない。
様々な用途に対応するため、複数の予約モデルやスタイルを用意しています。
RSVPシグナル付きLSPで送信可能なIPv4、IPv6パケットをサポートします。
RSVP動作の概要
RSVPは、各フローを処理するための独立したセッションを作成します。セッションは、宛先アドレス、オプションの宛先ポート、およびプロトコルの組み合わせで識別されます。セッション内には、1つ以上の送信者を含めることができます。各々の送信者は、送信元アドレスと送信元ポートの組み合わせで識別されます。すべての送受信者にセッション識別子を伝達するために、セッションアナウンスプロトコルや人的コミュニケーションなどの帯域外メカニズムが使用されます。
典型的なRSVPセッションは、以下のイベント順序で行われます。
潜在送信者が、RSVPパスメッセージをセッションアドレスに送信し始めます。
セッションへの参加を求める受信者が、必要に応じて自分自身を登録します。例えば、マルチキャストアプリケーションの受信者は、IGMPに自らを登録することになります。
受信者はパスメッセージを受信します。
受信者は、送信者に向けて適切なResvメッセージを送信します。これらのメッセージでフロー記述子が送信され、パス上のルーターはこれを使用して、リンク層メディアに予約を行います。
送信者はResvメッセージを受信した後に、アプリケーションデータの送信を開始します。
この一連のイベントは、必ずしも厳密に同期しているわけではありません。例えば、受信者は送信者からのパスメッセージを受信する前に自分自身を登録することができ、アプリケーションデータは送信者がResvメッセージを受信する前に送信することができます。Resvメッセージに含まれる実際の予約の前に配信されたアプリケーションデータは、通常、CoS保証を持たないベストエフォート型の非リアルタイムトラフィックとして扱われます。
RSVP シグナリング プロトコルの理解
RSVP は、MPLS ネットワーク全体に帯域幅割り当てと真のトラフィック制御を処理するシグナリング プロトコルです。LDP と同様、RSVP は、ディスカバリー メッセージとアドバタイズを使用して、すべてのホスト間で LSP パス情報を交換します。ただし、RSVP には、MPLS ネットワークを介してトラフィックのフローを制御する一連の機能も含まれています。LDP は設定された IGP の最短パスをネットワークを通る通過経路として使用するように制限されていますが、RSVPは、CSPF（制限付き最短パス ファースト）アルゴリズムとERO（明示的なルート オブジェクト）を組み合わせて、トラフィックがどのようにネットワークを通過するかを決定します。
基本的な RSVP セッションは、LDP セッションの確立と全く同じ方法で確立されます。適切なトランジット インターフェイスで MPLSと RSVP の両方を設定することで、RSVP パケットの交換と LSP の確立を有効にします。ただし、RSVP によって、リンク認証、明示的な LSP パス、およびリンクの色を設定できます。
このトピックには、以下のセクションが含まれています。
RSVP の基礎
RSVP は、ネットワークを通して単方向およびシンプレックス フローを使用して、その機能を実行します。インバウンド ルーターは、RSVP パス メッセージを開始し、ダウンストリームをアウトバウンド ルーターに送信します。パス メッセージには、接続に必要なリソースに関する情報が含まれています。パスに沿った各ルーターは、予約に関する情報を維持するようになります。
パス メッセージがアウトバウンド ルーターに到達すると、リソース予約が開始されます。アウトバウンド ルーターは、インバウンド ルーターに予約メッセージ アップストリームを送信します。パスに沿った各ルーターは、元のパス メッセージのパスに従って、予約メッセージを受信し、そのアップストリームを送信します。インバウンド ルーターが予約メッセージを受信すると、単方向ネットワーク パスが確立されます。
RSVP セッションがアクティブになっている限り、確立されたパスは開いたセッションは、30秒ごとにセッション状態を報告する追加パスおよび予約メッセージの送信によって維持されます。ルーターが3分間保守メッセージを受信しなかった場合、RSVP セッションを終了し、別のルーターを介して LSP を再ルーティングします。
帯域幅予約要件
帯域幅予約が設定されすると、予約メッセージが LSP 全体に帯域幅値を伝送します。ルーターは、特定の LSP のリンクに指定された帯域幅を予約する必要があります。特定の LSP セグメントに利用可能な帯域幅を超えた場合、LSP が別の LSR を介して再ルーティングされます。セグメントが帯域幅予約をサポートできない場合、LSP 設定に失敗し、RSVP セッションは確立されません。
明示的なルート オブジェクト
明示的なルート オブジェクト（ERO）は、LSP ルーティングを指定された LSR のリストに制限します。デフォルトでは、RSVP メッセージはネットワーク IGP の最短パスによって決定されるパスに従います。ただし、設定された ERO が存在する場合、RSVP メッセージは指定されたパスに従います。
ERO は 2 種類の手順で構成されます。それは、ルーズ ホップとストリクト ホップです。ルーズ ホップが設定されると、LSP をルーティングする必要がある 1 つ以上のトランジット LSR を特定します。ネットワーク IGP は、インバウンド ルーターから最初のルート ホップまで、またはあるルーズ ホップから次のルーズ ホップまでの正確なルートを決定します。ルーズ ホップは、特定の LSRが LSP に含まれることのみを指定します。
ストリクト ホップが設定されると、LSP をルーティングする必要がある正確なパスを識別します。ストリクト ホップ ERO は、RSVP メッセージが送信されるルーターの正確な順序を指定します。
ルーズ ホップおよびストリクト ホップ EROを同時に設定できます。この場合、IGP はルーズ ホップ間のルートを決定し、ストリクト ホップ設定は特定の LSP パス セグメントの正確なパスを指定します。
図 2 は、ERO を使用する典型的な RSVP シグナリング LSP を示しています。
図 2 に示されるトポロジーでは、トラフィックがホスト C1 からホスト C2 にルーティングされます。LSP は、ルーター R4 またはルーター R7 を通過できます。LSP が R4 を使用するように設定すると、LSP で R4 をホップとして指定するルーズ ホップまたはストリクト ホップ ERO を設定できます。ルーター R4、R3、および R6 を介して特定のパスを強制するには、3 つの LSR を介してストリクト ホップ ERO を設定します。
制限付き最短パス ファースト
IGP は SPF（最短パス ファースト）アルゴリズムを使用して、どのようにネットワーク内トラフィックがルーティングされるかを決定しますが、RSVP は CSPF（制約付き最短パス ファースト）アルゴリズムを使用して、以下の制約を受けられるトラフィック パスを計算します。
LSP 属性—リンク カラー、帯域幅要件、ERO などの管理グループ
リンク属性—特定のリンクと利用可能な帯域幅の色
これらの制約は、TED（トラフィック制御データベース）で維持されます。データベースは、最新のトポロジー情報、現在のリンクの予約可能な帯域幅、およびリンク カラーを CSPF に提供します。
CSPF がこれらのルールに従って、選択するパスを決定します。
優先度が高い順に LSP（設定優先度値が最も低い LSP）を 1 つずつ計算します。優先度が等しい LSP については、CSPF は帯域幅要件が高い順に計算します。
全二重ではなく、予約可能な帯域幅が十分にないリンクのトラフィック制御データベースを除外します。
LSP 設定に
includeステートメントが含まれている場合、含まれているカラーを共有しないすべてのリンクを除外します。LSP 設定に
excludeステートメントが含まれている場合、除外されたカラーが含まれるすべてのリンクを除外します。リンクにカラーがない場合、それを受け入れます。ERO を考慮して、LSP のアウトバウンド ルーターへの最短パスを指定します。例えば、パスがルーター A を通過する必要がある場合、2 つの個別の SPF アルゴリズムが計算されます。それは、インバウンド ルーターからルーター A へのものとルーター A からアウトバウンド ルーターへのものです。
複数のパスのコストが等価である場合、LSP の宛先と同じ最終ホップ アドレスがあるものを選択します。
複数の等価コスト パスがある場合、ホップが最も少ないパスを選択します。
複数の等価コスト パスがある場合、LSP に設定された CSPF 負荷分散ルールを適用します。
リンク カラー
RSVP によって、CSPF パス選択向け管理グループを設定できます。管理グループは通常、カラーで名前が付けられ、数値が割り当てられ、適切なリンクの RSVP インターフェイスに適用されます。数字が低いほど、優先度が高いことを示します。
管理グループを設定した後、TED でそのカラーのリンクを除外する、含める、または無効にすることができます。
特定のカラーを除外した場合、そのカラーの管理グループがあるすべてのセグメントが CSPF パス選択から除外されます。
特定のカラーを含めた場合、適切なカラーがあるセグメントのみが選択されます。
カラーを除外するか、含めた場合、管理グループに関連付けられ、特定のセグメントに適用されたメトリックがそのセグメントのパス コストを決定します。
TED に総パス コストが最も低い LSP が選択されます。
FRRのためのRSVP-TEプロトコル拡張機能
Junos OS Release 16.1以降、RFC 8370で定義された高速リルート（FRR）施設保護のためのリフレッシュ間隔に依存しないRSVP（RI-RSVP）をサポートするRSVP Traffic Engineering（TE）プロトコル拡張が導入され、ラベルスイッチパス（LSP）の拡張性が高く、収束時間が短く、周期的リフレッシュによるRSVP信号メッセージのオーバーヘッドが低減されています。Junos RSVP-TEは、もともとRFC 4090で規定されたFRR施設バイパス用のRI-RSVPをサポートするプロトコル拡張を含む、拡張FRR別名RI-RSVPモードでデフォルトで実行されます。
Junosに実装されているRI-RSVPプロトコル拡張は、完全な後方互換性があります。LSPのサブセットがこの機能を含まないノードを通過する混合環境では、拡張FRRモードで動作するJunos RSVP-TEは、新しい拡張機能をサポートしないノードとのシグナリング交換において、新しいプロトコル拡張機能を自動的にオフにします。
FRRプロファイルの強化の一環として、多くの変更がなされ、新しいデフォルトが採用されました。これらを一覧にしてみました。
RSVP-TEは、デフォルトで「拡張」FRR、またはRI-RSVPモードを実行し、スケールアップシナリオを促進するための拡張機能を備えています。no-enhanced-frr-bypass (Protocols RSVP)これらの新しいプロトコル拡張は、ルータ上でno-enhanced-frr-bypassコマンドを使用して無効にすることができます。
RFC 2961で定義されたRSVPリフレッシュ削減拡張は、デフォルトで有効である。ユーザーは、no-reliableコマンド（下記参照）でこれらを無効にすることができます。
注:拡張FRRまたはRI-RSVP拡張がノードIDベースのHelloメッセージの交換を必要とするため、ノードIDベースのHelloはデフォルトで有効になっています。
node-helloNode-idベースのHellosは、コマンドで無効にできます。リフレッシュ削減拡張とノードIDベースのHelloメッセージは、拡張FRRまたはRI-RSVP拡張に不可欠であるため、これらのいずれかを無効にすると、ノード上で拡張FRR拡張が自動的にオフになる。RSVPメッセージのデフォルトの更新時間が、30秒から20分に増加しました。
keep-multiplierkeep-multiplierのデフォルト値である3が、新しいデフォルトのリフレッシュ時間に適用されます。
ローカル復帰はデフォルトで無効になっています。
[edit protocols rsvp node-hello]ノードHellosの既存のCLI設定、 、はまだ利用可能ですが、アクションは冗長です。有効な場合、拡張 FRR と共に設定が不要であることを示すメッセージが表示される。
メッセージの信頼性を無効にする既存のコマンドは、RSVPのリフレッシュ削減を無効にするために使用されるようになりました。
deleteリフレッシュリダクションを有効にする以前のデフォルトに戻すには、以下のコマンドのバージョンを使用します。no-reliable特定のインタフェースで，インタフェースを通過するすべてのLSPのFRRスケーラビリティ強化を自動的に無効化するために設定します。同様に、RSVP-TEをFRR設備保護機能なし、リフレッシュリダクションなしで実行するには、各インタフェースでリフレッシュリダクションを無効にします。ここで紹介するコマンドのいずれかを使用します。[edit protocols rsvp interface name no-reliable][edit logical-systems name protocols rsvp interface name no-reliable]
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（Point of Local Repair）アドレスを表示します。
メッセージバンドリングを有効または無効にするための以前のCLI設定オプションは非推奨です（既存の設定は受け入れられますが、show configurationの出力に警告が表示されます）。これらのコマンドは以下の通りです。
Junos OS RSVP プロトコルの実装
RSVP の Junos 実装は、RSVP バージョン 1 をサポートしています。このソフトウェアは、すべての必須オブジェクトと RSVP メッセージタイプをサポートしており、整合性オブジェクトを通して、メッセージの整合性とノード認証をサポートします。
Junos RSVP ソフトウェアの主な目的は、MPLS LSP（ラベルスイッチ パス）内で動的シグナリングをサポートすることです。インターネット上でリソース予約をサポートするのは、Junos OS 実装の二次的な目的にすぎません。リソース予約のサポートは二次的なものであるため、Junos RSVP ソフトウェアは以下の機能をサポートしていません。
IPマルチキャスト セッション。
トラフィック制御。本ソフトウェアでは、リアルタイム 映像またはオーディオ セッション向けリソース予約はできません。
プロトコル メカニズム、パケット処理、およびサポートされている RSVP オブジェクトに関して、ソフトウェアの Junos OS の実装は他の RSVP 実装と相互運用性があります。
RSVP認証
Junos OSは、RFC 2747に記載されたRSVP認証スタイル（マルチベンダーの互換性を可能にする）と、インターネットドラフト、ietf-rsvp-md5-03.txtに記載されたRSVP認証スタイルの両方をサポートしています。Junos OSは、インターネットドラフト-ietf-rsvp-md5-08.txtに記述された認証スタイルを使用しています。ルーターがネイバーからRFC 2747スタイルのRSVP認証を受信すると、そのネイバーに対してこのスタイルの認証に切り替わります。隣接する各ルーターのRSVP認証スタイルは、個別に決定されます。
RSVP および IGP ハロー パケットとタイマー
RSVP は、IGP（インテリア ゲートウェイ プロトコル）（IS-IS または OSPF）のネイバーの状態を監視し、ノードが故障したときには IGP プロトコルに依存して検出します。IGPプロトコルがネイバーをダウンさせた場合（helloパケットが受信できなくなったため）、RSVPもそのネイバーをダウンさせます。しかし、IGP プロトコルと RSVP は、ネイバーをアップする際に独立して動作します。
Junos OS では、RSVP は通常、IGPの hello パケット検出に依存してノードの障害をチェックします。IS-IS や OSPF の hello timers に短い時間を設定することで、これらのプロトコルがノードの障害を迅速に検出できるようになります。ノード に障害が発生したり、ノード の障害が検出されると、パス エラー メッセージが生成され、RSVP セッションはダウンしますが、IGP ネイバーはアップしたままになります。
RSVP hellos は、IGP が特定の隣人を認識できない場合（たとえば、インターフェースで IGP が有効になっていない場合）や、IGP が RIP（IS-IS や OSPF ではない）の場合に依存することができます。また、他のベンダーの機器は、RSVP helloパケットに基づいて RSVP セッションを監視するように設定することができます。また、この機器は、RSVP の hello パケットの損失により、RSVP セッションをダウンさせる可能性があります。
短い RSVP hello タイターを設定することは推奨しません。障害のあるネイバーの迅速な発見が必要な場合は、Short IGP（OSF または IS-IS）hello タイマーを設定します。
OSPF と IS-IS は、ルーティング プロトコルや他のプロセスがルーターの処理能力を圧迫している場合でも、迅速な hello メッセージの送受信を確実に管理するインフラストラクチャを備えています。同じ状況では、ネイバーが正常に機能しているにもかかわらず、RSVP hellos が早々にタイムアウトする可能性があります。
RSVPメッセージタイプ
RSVPは、以下のタイプのメッセージを使用して、データフローのパスの確立と削除、予約情報の確立と削除、予約確立の確認、およびエラー報告を行います。
パスメッセージ
各送信側ホストは、ユニキャストとマルチキャストのルーティングプロトコルが提供するルートに沿って、パスメッセージをダウンストリームに送信します。パスメッセージは、アプリケーションデータと同じパスを正確にたどり、その途中でパス状態を作成します。結果として、ルーターがセッションの前のホップと次のホップノードを学習することができます。パスメッセージは定期的に送信され、パス状態を更新します。
リフレッシュ間隔は、refresh-timeと呼ばれる変数によって操作され、秒単位で表示される定期的リフレッシュタイマーです。パス状態は、ルーターが特定の連続パスメッセージ数を受信しないと、タイムアウトします。この数は、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メッセージ
PathTearメッセージは、パス状態と、またパス途上にあるすべてのルーターにある依存予約状態を削除（破棄）します。PathTearメッセージは、パスメッセージと同じパスをたどります。PathTearは、通常、送信側アプリケーション、もしくはパス状態がタイムアウトした時にはルーターによって、起動されます。
PathTearメッセージは不可欠ではありませんが、ネットワークリソースを迅速にリリースするので、ネットワークパフォーマンスを向上させます。PathTearメッセージが失われたり、作成されない場合、パス状態はいずれ更新されないとタイムアウトし、パスに関連するリソースはリリースされます。
ResvTearメッセージ
ResvTearメッセージは、パス途上の予約状態を除去します。このようなメッセージは、セッションの送信側に向かうアップストリームを移動します。ある意味、ResvTearメッセージはResvメッセージとは正反対のものです。ResvTearメッセージは、通常、受信側アプリケーション、または予約状態がタイムアウトした場合にはルーターによって起動されます。
ResvTearメッセージは不可欠ではありませんが、ネットワークリソースを迅速にリリースするので、ネットワークパフォーマンスを向上させます。ResvTearメッセージが失われたり、作成されない場合、予約状態は更新されないといずれタイムアウトし、予約に関するリソースはリリースされます。
PathErrメッセージ
パスエラーが発生した場合（パスメッセージでパラメーターの問題が原因）、ルーターは、パスメッセージを出した送信側にユニキャストPathErrメッセージを送信します。PathErrメッセージはアドバイザリです。そのメッセージは、途上にあるパス状態を変更することはありません。
ResvErrメッセージ
予約リクエストに失敗した場合、ResvErrエラーメッセージが、関係のあるすべての受信側に配信されます。ResvErrメッセージはアドバイザリです。そのメッセージは、途上にある予約状態を変更することはありません。
ResvConfirmメッセージ
受信側は予約リクエストの確認を要求することができ、この確認は、ResvConfirmメッセージとともに送信されます。複雑なRSVPのフロー統合ルールのため、確認メッセージがパス全体のエントツーエンド確認を提供をするとは限りません。したがって、ResvConfirmメッセージは成功の可能性であり、保証ではありません。
ジュニパーネットワークスのルーターは、Resv Confirmメッセージで確認をリクエストすることはありません。ただし、ジュニパーネットワークス のルーターは、別のベンダーの機器からリクエストされた場合、Resv Confirmメッセージを送信することもあります。
RSVP自動メッシュの理解
RSVP信号を使用するBGPおよびMPLS VPNにサイトを追加する場合、カスタマーエッジ（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ルータ間のMPLSラベルスイッチパス（LSP）が完全にメッシュ化されていることが必要です。新しい PE ルーターをネットワークに追加する場合、既存のすべての PE ルーターは、新しい PE ルーターとピアリングするように再設定する必要があります。BGPルートリフレクタを設定し（BGPのフルメッシュの要件を緩和）、MPLSのシグナリングプロトコルとして（LDP）を設定すれば、設定の手間を大幅に削減することができます。
しかし、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の運用・保守の手間を軽減し、より大規模で複雑なネットワークへの導入を可能にします。
この情報はIGPによって配布されるため、すべてのPEルーターはネットワーク内の他のすべてのPEルーターに到達することができます。PEルーターは、そのようなLSPが必要であることを知っている限り、ネットワーク内の他のPEルーターにポイント・ツー・ポイントのRSVP LSPを設定することができます。PEルータ間でLSPのフルメッシュを構築するには、各PEルータが他のPEルータのどれがフルメッシュを構成しているかを知っている必要があります。
rsvp-te[edit routing-options dynamic-tunnels dynamic-tunnel-name]Junos OSでは、RSVP自動メッシュは階層レベルのコンフィグレーションステートメントで設定されます。rsvp-teこの設定文は、ルーティングインスタンスでプロバイダトンネルのオプションとして使用することも可能です。rsvp-teプロバイダトンネルオプションとして実装された場合，マルチプロトコルBGPマルチキャストVPNのRSVPポイントツーマルチポイントLSPを設定するために使用され，RSVP自動メッシュを設定するために使用されるわけではありません。
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 メッセージの損失に起因しています。このような損失から回復する時間は、通常、リフレッシュ間隔とキープアライブタイマーに結びつきます。
RSVPリフレッシュリダクション機能は、RSVP共通ヘッダーのリフレッシュリダクション（RR）可能ビットを有効にすることで広告される。このビットは、RSVPネイバー間でのみ意味を持つ。
RSVPリフレッシュリダクションには以下の機能があります。
バンドルメッセージを用いたRSVPメッセージのバンドル
RSVPメッセージIDによるメッセージ処理のオーバーヘッド軽減
Message ID、Message Ack、Message Nackを用いたRSVPメッセージの確実な配信
リフレッシュ間隔ごとに送信される情報量を削減するサマリーリフレッシュ
RSVPリフレッシュリダクション仕様（RFC 2961）では、ルーターで上記の機能の一部または全部を有効にすることができます。また、ルーターが近隣のリフレッシュ削減能力を検出するために使用できるさまざまな手順についても説明します。
Junos OSは、リフレッシュリダクションの拡張機能をすべてサポートしており、そのうちのいくつかは、選択的に有効または無効にすることができます。Junos OSはメッセージIDをサポートしているため、PathとResvメッセージに対してのみ信頼性の高いメッセージ配信を実行することができます。
RSVPインターフェイスを設定するRSVPリフレッシュリダクションの設定方法については、「RSVPリフレッシュリダクションの設定」を参照してください。
RSVP における MTU シグナリング
最大送信単位 (MTU) は、ネットワークで送信できる最大のパケットまたはフレーム（バイト単位）です。MTU が大きすぎると再送信が発生する可能性があります。MTU が小さすぎると、ルーターが比較的高いヘッダーオーバーヘッドと確認を送信して対応する可能性があります。さまざまなプロトコルに関連付けられた MTU のデフォルト値があります。また、インターフェイス上の MTU を明示的に設定することもできます。
MTU サイズが異なる一連のリンクに LSP が作成された場合、イングレスルーターは LSP パス上の最小 MTU を知りません。デフォルトでは、LSP の MTU は 1,500 バイトです。
この MTU が中間リンクの 1 つの MTU より大きい場合、トラフィックが落ちる場合があります。これは、MPLS パケットをフラグメント化できないためです。また、イングレス ルーターは、LSP のコントロールプレーンがまだ正常に機能するため、このタイプのトラフィック喪失を認識していません。
MPLS LSP でこのタイプのパケット喪失を回避するために、RSVP で MTU シグナリングを設定できます。この機能は、RFC 3209で説明されます。ジュニパーネットワークスは、RSVP における MTU シグナリング向けに統合サービス オブジェクトをサポートしています。統合サービスオブジェクトは、RFCs 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 シグナリングの仕組みを説明しています：
正しい MTU が RSVP においてどのようにシグナリングされるか
RSVP で正しい MTU がどのようにシグナリングされるかは、ネットワーク デバイス（ルーターなど）が RSVP で MTU シグナリングを明示的にサポートしているかどうかによって異なります。
ネットワーク デバイスが RSVP で MTU シグナリングをサポートする場合、MTU シグナリングを有効にすると、以下のような状態が発生します。
MTU は、イングレス ルーターから Adspec オブジェクトによって、エグレス ルーターにシグナリングされます。このオブジェクトを転送する前に、イングレス ルーターが、パス メッセージが送信されたインターフェイスに関連する 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 がデフォルトで 1,500 バイトに設定されます。
RSVP で MTU シグナリングをサポートしていないジュニパーネットワークス トランジット ルーターは、Adspec オブジェクトで 1,500 バイトの MTU 値がデフォルトで設定されます。
送信MTU値の決定
送信MTU値は、Adspecオブジェクトで受信した値のうち、送信インターフェイスのMTU値と比較して小さい方の値です。送信インターフェイスのMTU値は、次のように決定されます。
[family mpls]階層レベルでMTU値を設定すると、この値が通知されます。MTUを設定しない場合、
inetMTUが通知されます。
RSVP の制限における MTU シグナリング
RSVP での MTU シグナリングに対する制限は以下の通りです。
MTU 値の変更によって、以下の状況でトラフィックの一時的な損失が発生します。
リンク保護およびノード保護では、バイパスの MTU はバイパスがアクティブになった時点でのみシグナリングされます。新しいパス MTU を伝送する時間中に、MTU 不一致によってパケット損失が発生する可能性があります。
高速再ルートでは、迂回がアクティブにならないとパスの MTU が更新されないため、イングレス ルーターの MTU への更新が遅れます。MTU 不一致がある場合、MTU が更新されるまでパケット損失が発生する可能性があります。
いずれの場合でも、迂回またはバイパス MTU よりも大きなパケットのみ失われます。
MTU が更新されると、ネクスト ホップの変更をトリガーします。ネクスト ホップの変更により、ルート統計が失われます。
RSVP の MTU シグナリングでサポートされている最小 MTU は、1,488 バイトです。この値によって、false または不正設定の値の使用を防止できます。
シングル ホップ LSP については、
showコマンドで表示される MTU 値は RSVP シグナリング値です。しかし、MPLS 値は無視され、正しい IP 値が使用されます。
変更履歴
サポートされる機能は、使用しているプラットフォームとリリースによって決まります。 特定の機能がお使いのプラットフォームでサポートされているかどうかを確認するには、 Feature Explorer をご利用ください。