RSVP の概要

RSVPプロトコルは、ルータがデータフロー経路上のすべてのノードにサービス品質(QoS)要求を配信し、要求されたサービスの状態を確立および維持するために使用されます。RSVPリクエストは、通常、データパス上の各ノードでリソースの予約につながる。RSVPには以下の属性があります。

• 一方向性のデータフローに対してリソースの予約を行います。

• 図1に示すように、データフローの受信者がそのフローに使用されるリソース予約を開始し、維持することを可能にします。

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

• 現在および将来のルーティングプロトコルに依存するが、ルーティングプロトコルそのものではない。

• 様々な用途に対応するため、複数の予約モデルやスタイルをご用意しています。

• RSVPシグナル付きLSPで送信可能なIPv4とIPv6の両方のパケットをサポートします。

図1:RSVP予約リクエストとデータフロー

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

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

1. 潜在送信者が、RSVPパスメッセージをセッションアドレスに送信し始めます。

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

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

4. 受信者は、送信者に向けて適切なResvメッセージを送信します。これらのメッセージはフロー記述子を伝送し、パス上のルーターはこれを使用して、リンク層メディアに予約を行います。

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

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

RSVP は、MPLS ネットワーク全体で帯域幅割り当てと真のトラフィック制御を処理するシグナリングプロトコルです。LDP と同様に、RSVP はディスカバリー メッセージとアドバタイズを使用して、すべてのホスト間で LSP パス情報を交換します。ただし、RSVP には、MPLS ネットワークを介したトラフィックのフローを制御する一連の機能も含まれています。LDP は設定された IGP の最短パスをネットワークを通る通過経路として使用するように制限されていますが、RSVP は、CSPF(Constrained Shortest Path First)アルゴリズムとERO(明示的なルート オブジェクト)を組み合わせて、トラフィックがどのようにネットワークを通過するかを決定します。

基本的な RSVP セッションは、LDP セッションの確立と全く同じ方法で確立されます。適切なトランジット インターフェイスで MPLS と RSVP の両方を設定することで、RSVP パケットの交換と LSP の確立を有効にします。ただし、RSVP では、リンク認証、明示的な LSP パス、およびリンクの色を設定することもできます。

このトピックでは、次のセクションについて説明します。

• RSVP の基礎
• 帯域幅予約要件
• 明示的なルート オブジェクト
• 制限付き最短パスファースト
• リンク カラー

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

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

ERO は、ルーズ ホップとストリクト ホップの 2 種類の命令で構成されます。ルーズ ホップが設定されると、LSP をルーティングする必要がある 1 つ以上のトランジット LSR を特定します。ネットワーク IGP は、インバウンド ルーターから最初のルーズ ホップまで、またはあるルーズ ホップから次のルーズ ホップまでの正確なルートを決定します。ルーズ ホップは、特定の LSR が LSP に含まれることのみを指定します。

ストリクト ホップが設定されると、LSP をルーティングする必要がある正確なパスを識別します。ストリクト ホップ ERO は、RSVP メッセージが送信されるルーターの正確な順序を指定します。

ルーズ ホップ ERO とストリクト ホップ EROを同時に設定できます。この場合、IGP はルーズ ホップ間のルートを決定し、ストリクト ホップ設定は特定の LSP パス セグメントの正確なパスを指定します。

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

図2:EROありの典型的なRSVPシグナル化LSP

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

Junos OSリリース16.1以降、高速再ルート(FRR)施設保護のためにRFC 8370で定義された更新間隔に依存しないRSVP(RI-RSVP)をサポートするRSVPトラフィックエンジニアリング(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 コマンドを使用して無効にすることができます。

• RFC 2961で定義されたRSVPリフレッシュ削減拡張は、デフォルトで有効になっています。ユーザーは、no-reliableコマンド(下記参照)でこれらを無効にすることができます。

  注:

  拡張FRRまたはRI-RSVP拡張がノードIDベースのHelloメッセージの交換を必要とするため、ノードIDベースのHelloはデフォルトで有効になっています。ノードIDベースのHellosは、 node-hello コマンドで無効にできます。リフレッシュ削減拡張とノードIDベースのHelloメッセージは、拡張FRRまたはRI-RSVP拡張に不可欠であるため、これらのいずれかを無効にすると、ノード上の拡張FRR拡張が自動的にオフになる。

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

• keep-multiplierのデフォルト値である3が、新しいデフォルトのリフレッシュ時間に適用されます。

• ローカル復帰はデフォルトで無効になっています。ノードHellosの既存のCLI設定( [edit protocols rsvp node-hello])はまだ使用できますが、アクションは冗長です。有効な場合、拡張 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の出力に警告が表示されます)。これらのコマンドは次のとおりです。

  • [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設定オプションが冗長化されました(既存の設定は受け入れられますが、show configurationの出力に警告が表示されます)。

  • [edit protocols rsvp interface name reliable]

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

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

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

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

• トラフィック制御。本ソフトウェアでは、リアルタイムのビデオまたはオーディオセッション用のリソース予約はできません。

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

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

RSVP は、内部ゲートウェイ プロトコル(IGP)(IS-IS または OSPF)ネイバーの状態を監視し、ノードが故障したときには IGP プロトコルに依存して検出します。IGPプロトコルがネイバーをダウンさせた場合(helloパケットが受信できなくなったため)、RSVPもそのネイバーをダウンさせます。しかし、IGPプロトコルとRSVPは、ネイバーをアップする際に独立して動作します。

Junos OSでは、RSVPは通常、IGP helloパケット検出に依存してノードの障害をチェックします。IS-IS または OSPF hello タイマーに短い時間を設定することで、これらのプロトコルがノードの障害を迅速に検出できるようになります。ノードに障害が発生したり、ノードの障害が検出されると、パスエラーメッセージが生成され、RSVPセッションはダウンしますが、IGPネイバーはアップしたままになります。

RSVP hellos は、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 hellos が早々にタイムアウトする可能性があります。

RSVPは、以下のタイプのメッセージを使用して、データフローのパスの確立と削除、予約情報の確立と削除、予約確立の確認、およびエラー報告を行います。

• パスメッセージ
• Resvメッセージ
• PathTearメッセージ
• ResvTearメッセージ
• PathErrメッセージ
• ResvErrメッセージ
• ResvConfirmメッセージ

サービスプロバイダは、収益を上げるサービスを提供しながら、ネットワークを効率的に拡張するために、BGPおよびMPLS VPNをよく使用します。このような環境では、BGP はサービス プロバイダのネットワーク全体に VPN ルーティング情報を配布するために使用され、MPLS はその VPN トラフィックをある VPN サイトから別の VPN サイトへ転送するために使用されます。BGPおよびMPLSはピアモデルに基づいています。既存の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の運用・保守の手間を軽減し、より大規模で複雑なネットワークへのRSVPの導入を可能にします。

この情報はIGPによって配布されるため、すべてのPEルーターはネットワーク内の他のすべてのPEルーターに到達することができます。PE ルーターは、そのような LSP が必要であることを知っている限り、ネットワーク内の他の PE ルーターにポイントツーポイントの RSVP LSP を設定することができます。PEルーター間でLSPのフルメッシュを構築するには、各PEルーターが他のPEルーターのどれがフルメッシュを構成しているかを知っている必要があります。

予約リクエストには、予約スタイルを指定するオプションが含まれています。予約スタイルは、同一セッション内の異なる送信者に対する予約の扱いと、送信者の選択方法を定義します。

2 つのオプションは、同一セッション内の異なる送信者に対する予約の扱いを指定します。

• 個別予約 - 各受信者は、アップストリームの送信者ごとに独自の予約を確立します。

• 共有予約 - すべての受信者が 1 つの予約を行い、それを多くの送信者で共有します。

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

• 明示的な送信者—選択されたすべての送信者をリストアップします。

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

現在、これら 4 つのオプションを組み合わせて形成される以下の予約スタイルが定義されています。

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

• ワイルドカードフィルター(WF)—この予約スタイルは、ワイルドカード送信者間の共有予約で構成されています。このタイプの予約は、すべての送信者のために帯域幅を予約し、すべての送信者に向かってアップストリームに伝播し、新しい送信者が現れると自動的に拡張されます。ワイルドカード フィルター予約のサンプル アプリケーションは、各送信者が異なるデータ ストリームを送信するオーディオ アプリケーションです。通常、一度に数人の送信者しか送信しません。このようなフローでは、各送信者に個別の予約は必要ありません。1回の予約で十分です。

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

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リフレッシュリダクションの設定を参照してください更新。

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

MTUサイズが異なる一連のリンクにまたがってMTUが作成された場合、ingressルーターはLSPパス上の最小MTUを知りません。デフォルトでは、LSP の MTU は 1,500 バイトです。

この MTU が中間リンクの 1 つの MTU より大きい場合、MPLS パケットをフラグメント化できないため、トラフィックがドロップされる可能性があります。また、LSP のコントロールプレーンはまだ正常に機能するため、ingressルーターはこのタイプのトラフィック損失を認識していません。

MPLS LSP でこのタイプのパケット損失を回避するために、RSVP で MTU シグナリングを設定できます。この機能は、RFC 3209で説明されます。ジュニパーネットワークスは、RSVP の MTU シグナリング向けに統合サービス オブジェクトをサポートしています。統合サービスオブジェクトは、RFCs 2210 および 2215で説明されます。RSVP の MTU シグナリングは、デフォルトで無効になっています。

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

• RSVP LSP で MTU にシグナリング — MTU不一致によるパケット喪失を防ぐため、ingressルーターはLSPがたどったパスに沿った最小MTU値が何かを把握する必要があります。この MTU 値を取得すると、ingressルーターはそれを LSP に割り当てることができます。

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

MTUシグナリングとパケットフラグメント化の両方がingressルーターで有効になったら、このルーター上でRSVP LSPに解決されるルートはすべてシグナルされたMTU値を使用します。この機能の設定方法については、 RSVP での MTU シグナリングの設定を参照してください。

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

• 正しい MTU が RSVP でどのようにシグナリングされるか

• 送信 MTU 値の決定

• RSVP の制限における MTU シグナリング

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

ネットワーク デバイスが RSVP で MTU シグナリングをサポートしている場合、MTU シグナリングを有効にすると、MTU シグナリングを有効にすると、以下のような状態が発生します。

• MTUは、Adspecオブジェクトによってingressルーターからegressルーターにシグナリングされます。このオブジェクトを転送する前に、ingressルーターは、パスメッセージが送信されるインターフェイスに関連するMTU値を入力します。パスの各ホップで、Adspec オブジェクトの MTU 値が受信した値の最小値と発信インターフェイスの値に更新されます。

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

• Adspec オブジェクトが egressルーターに到着すると、MTU 値がパスに対して正しくなります(つまり、検出された最小 MTU 値)。egressルーターは、AdspecオブジェクトのMTU値をTspecオブジェクトのMTU値と比較します。Resv メッセージの Flowspec オブジェクトを使用して小さい方の MTU をシグナリングします。

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

RSVP で MTU シグナリングをサポートしないデバイスが存在するネットワークでは、以下の動作が実行される場合があります。

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

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

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

• [family mpls]階層レベルでMTU値を設定すると、この値が通知されます。

• MTUを設定しない場合、 inet MTUが通知されます。

RSVP での MTU シグナリングに対する制限は次のとおりです。

• MTU値の変更によって、以下の状況でトラフィックの一時的な損失が発生することがあります。

  • リンク保護およびノード保護では、バイパスの MTU はバイパスがアクティブになった時点でのみシグナリングされます。新しいパス MTU が伝送されるまでの時間中に、MTU 不一致によりパケット損失が発生するMTU不一致が発生する可能性があります。

  • 高速再ルートでは、迂回がアクティブになった後にのみパスの MTU が更新されるため、ingressルーターでの MTU への更新が遅れます。MTU不一致がある場合、MTUが更新されるまでパケット損失が発生する可能性があります。

    いずれの場合も、迂回またはバイパス MTU よりも大きいパケットのみ失われます。

• MTUが更新されると、ネクストホップの変更をトリガーします。ネクスト ホップの変更により、ルート統計が失われます。

• RSVP の MTU シグナリングでサポートされている最小 MTU は 1,488 バイトです。この値により、false または不正設定の値の使用を防止できます。

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