Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
 

MPLSトラフィック制御の構成

MPLS およびトラフィックエンジニアリング

トラフィックエンジニアリングでは、ルーティングテーブルを使用する標準ルーティングモデルを迂回して、データパケットがたどるパスを制御できます。トラフィックエンジニアリングは、輻輳リンクから、自動的に計算された宛先ベースの最短パスによって選択されることのない代替リンクへフローを移動します。トラフィックエンジニアリングにより、以下のことが可能になります。

  • 高価な長距離ファイバーをより効率的に使用できるようにします。

  • 1つまたは複数の障害が発生した場合に、トラフィックの経路を再ルーティングする方法を制御します。

  • パスごとに重要なトラフィックと通常の通信を分類します。

トラフィックエンジニアリング設計のコアは、ルーター間でラベル交換パス (Lsp) を構築することに基づいています。LSP は、フレームリレーまたは ATM のバーチャルサーキットなど、コネクション型の接続指向機能を備えています。Lsp は信頼できません。LSP に送信されるパケットには、配信保証はありません。ただし、優先処理が可能です。また、Lsp は、経路に入ってくるパケットがエンベロープにカプセル化され、中間ノードではなくパス全体にわたって切り替えられるという、単方向トンネルと似ています。Lsp は、ネットワークでパケットを転送する方法をきめ細かく制御できます。LSP は、信頼性を提供するために、プライマリパスとセカンダリアドレスのセットを使用できます。

Lsp は、BGP トラフィックのみ (宛先が自律システムの外側にあるトラフィック (AS) で構成できます。この場合、AS 内のトラフィックは Lsp の存在による影響を受けません。Lsp は、BGP と内部ゲートウェイプロトコル (IGP) の両方のトラフィックに対して設定することもできます。したがって、Lsp によって、同一のトラフィックと同一の AS 間通信の両方が影響を受けます。

MPLS トラフィックエンジニアリングとシグナリングプロトコルの概要

トラフィックエンジニアリングにより、効率的で信頼性の高いネットワーク運用が可能になり、同時にネットワークリソースとトラフィックのパフォーマンスも最適化されます。トラフィックエンジニアリングでは、内部ゲートウェイプロトコル (IGP) によって選択された最短パスから、ネットワーク全体の輻輳の少ない物理パスへと、トラフィックフローを移動することができます。ソースルーティング以外にトラフィックエンジニアリングをサポートするには、ネットワークが以下のことを実行する必要があります。

  • 帯域幅や管理要件など、すべての制約事項を考慮して、ソースでパスを計算します。

  • パスの計算が完了したら、ネットワークのトポロジーとリンクの属性に関する情報をネットワーク全体に配布します。

  • ネットワークリソースを確保し、リンク属性を変更します。

伝送トラフィックが IP ネットワークを介してルーティングされる場合、MPLS は多くの場合、その通過をエンジニアリングするために使用されます。トラフィックの送信側と受信側のどちらかにおいて、転送先ネットワーク全体の正確なパスは重要ではありませんが、ネットワーク管理者は、特定の送信元と宛先のアドレスペアの間で、トラフィックをより効率的にルーティングする必要があります。各パケットに特定のルーティング命令が記載された短いラベルを追加することで、MPLS は、次ホップルックアップに基づいてパケットを転送するのではなく、ルーターからルーターにパケットを切り替えます。結果として得られるルートは、ラベルスイッチパス (lsp)と呼ばれます。Lsp は、ネットワーク経由のトラフィックの通過を制御し、トラフィック転送をスピードアップします。

Lsp は手動で、またはシグナリングプロトコルを使用して作成できます。MPLS 環境では、シグナリングプロトコルを使用して、転送ネットワーク全体でのトラフィックの Lsp を確立します。Junos OS 2 つのシグナリング プロトコル(LDP と RSVP(リソース予約プロトコル)をサポートします。

MPLS トラフィックエンジニアリングは、以下のコンポーネントを使用します。

  • MPLS Lsp for パケット転送

  • ネットワークトポロジとリンクの属性に関する情報を配信するための拡張機能 IGP

  • パス計算用およびパス選択用の制約された最短パスファースト (CSPF)

  • パスに沿って転送状態を確立し、パスに沿ってリソースを予約するための RSVP 拡張

また Junos OS は、さまざまな OSPF 領域間でトラフィックエンジニアリングをサポートしています。

トラフィックエンジニアリング機能

トラフィックフローを既存の物理トポロジにマッピングするタスクは、トラフィックエンジニアリングと呼ばれています。トラフィックエンジニアリングは、トラフィックフローを、内部ゲートウェイプロトコル (IGP) によって選択された最短パスから離れた場所に移動し、混雑していない物理パスにネットワーク全体に移行する機能を提供します。

トラフィックエンジニアリングには、以下を実行する機能が用意されています。

  • 既知のボトルネックまたはネットワークの輻輳ポイントを中心としたプライマリパスをルーティングします。

  • 1つまたは複数の障害において、プライマリパスが直面した場合のトラフィックの再ルーティング方法を正確に制御できます。

  • ネットワークのサブセットが使用率が高くないことを保証することで、利用可能な総帯域幅と長距離光ファイバーをより効率的に活用することができます。これにより、代替パスに関するネットワークの他の部分は十分に活用されなくなります。

  • 運用効率を最大化します。

  • パケットロスの最小化、輻輳時間の延長、スループットの最大化によって、ネットワークのトラフィック指向のパフォーマンス特性を高めます。

  • マルチサービスインターネットをサポートするために必要な、ネットワークの統計的にバインドされたパフォーマンス特性 (損失率、遅延偏差、転送遅延など) を強化します。

トラフィックエンジニアリングのコンポーネント

オペレーティングシステム(Junos®)では、ソフトウェアインターフェイストラフィック制御RSVPとともにMPLS実装されます。トラフィックエンジニアリングは4つの機能コンポーネントで構成されています。

Lsp に対するトラフィックエンジニアリングの構成

LSP を構成すると、ホストルート (32 ビットマスク) が受信ルーターにインストールされます。ホストルートのアドレスは、LSP の宛先アドレスです。階層bgpレベルのtraffic engineering[edit protocols mpls]ステートメントのオプションはデフォルトで有効になっています (このbgpオプションを明示的に設定することもできます)。 BGP のみがルート計算で lsp を使用できるようにします。その他traffic-engineeringのステートメントオプションを使用すると、マスタールーティングインスタンスでこの動作を変更できます。この機能は、特定のルーティングインスタンスでは使用できません。またtraffic-engineering 、ステートメントオプション (bgpbgp-igpbgp-igp-both-ribs、、、またはmpls-forwarding) の1つだけを有効にすることもできます。

注:

いずれかのtraffic-engineeringステートメントオプションを有効または無効にすると、すべての MPLS ルートが削除され、ルーティングテーブルに再挿入が行われます。

「」セクションLSP メトリックを概要 LSAs に公開していますで説明されているように、OSPF とトラフィックエンジニアリングを設定して、概要リンク状態広告 (LSAs) に LSP メトリックをアドバタイズできます。

以下のセクションでは、Lsp のトラフィックエンジニアリングを構成する方法について説明します。

Lsp を BGP と IGP のトラフィック転送に使用する

BGP を設定し、IGPs を使用して、送信ルーターに送信するトラフィックを転送するbgp-igpように lsp traffic-engineeringを指定するには、ステートメントにオプションを組み込みます。このbgp-igpオプションを選択すると、すべての inet ルートが inet. 0 ルーティングテーブルに移動します。

受信ルーターでは、以下bgp-igptraffic-engineeringステートメントの include オプションを使用します。

このステートメントは、以下の階層レベルで含めることができます。

  • [edit protocols mpls]

  • [edit logical-systems logical-system-name protocols mpls]

    注:

    文のオプションは、 bgp-igp VPN 用には設定できません)。 traffic-engineering Vpn では、ルートが inet. 3 ルーティングテーブルに存在している必要があります。

仮想プライベートネットワークでの転送に Lsp を使用

Vpn を適切に機能させるには、ルートが inet. 3 ルーティングテーブルに残っている必要があります。Vpn についてはbgp-igp-both-ribstraffic-engineering文のオプションを設定して BGP を発生させ、igps を使用して送信ルーターに送信するトラフィックを転送します。このbgp-igp-both-ribsオプションは、inet .0 ルーティングテーブル (IPv4 ユニキャストルート用) と inet. 3 ルーティングテーブル (MPLS パス情報用) の両方に受信ルートをインストールします。

受信ルーターでは、以下のtraffic-engineering bgp-igp-both-ribsステートメントを含めます。

このステートメントは、以下の階層レベルで含めることができます。

  • [edit protocols mpls]

  • [edit logical-systems logical-system-name protocols mpls]

このbgp-igp-both-ribsステートメントを使用すると、inet. 3 テーブルのルートが inet. 0 テーブルにコピーされます。コピーされたルートは、「LDP シグナル」または「RSVP シグナル」であり、inet の他のルートよりも優先度が低いと考えられます。優先度の低いルートは、アクティブルートとして選択される可能性が高くなります。ルーティングポリシーはアクティブルートのみで動作するため、これは問題になる可能性があります。この問題を回避するにはmpls-forwarding 、代わりにこのオプションを使用してください。

転送に RSVP および LDP ルートを使用するが、ルートの選択は行わない

ステートメントのbgp-igpまたはbgp-igp-both-ribsオプションを設定すると、優先度の高い lsp は、inet .0 ルーティングテーブル内の IGP ルートを置き換えることができます。 traffic-engineering IGP ルートは、アクティブなルートではなくなっているため、今後再配布されない可能性があります。

mpls-forwarding明細書のtraffic-engineeringオプションを設定した場合、lsp は転送に使用されますが、工順の選択から除外されます。これらのルートは、inet. 0 と inet. 3 ルーティングテーブルの両方に追加されます。アクティブルートが選択されている場合、inet. 0 ルーティングテーブル内の Lsp には低優先の設定が割り当てられます。ただし、inet. 3 ルーティングテーブル内の Lsp は通常の優先度を与えられるため、次ホップの転送を選択するために使用されます。

このmpls-forwardingオプションを有効にすると、現在アクティブForwardingOnlyなルートの優先順位が設定されている場合でも、転送に適した状態を持つルートが使用されます。ルートの状態を確認するには、コマンドshow route detailを実行します。

Lsp を転送に使用し、ルートの選択から除外するにmpls-forwardingは、 traffic-engineeringステートメントのオプションを含めます。

このステートメントは、以下の階層レベルで含めることができます。

  • [edit protocols mpls]

  • [edit logical-systems logical-system-name protocols mpls]

このmpls-forwardingオプションを設定すると、IGP ショートカットルートが inet. 0 ルーティングテーブルにのみコピーされます。

bgp-igp-both-ribsオプションとは異なり、 mpls-forwardingこのオプションを使用すると、転送に LDP 信号または RSVP 信号のルートを利用でき、ルーティングを目的として BGP と IGP ルートをアクティブに保つことができます。ルーティングポリシーによって経路を設定できるようになります。

たとえば、ルーターが BGP 動作していて、別の BGP スピーカーに送信する必要がある 10.10.10.1/32 の BGP ルートを持っているとします。このbgp-igp-both-ribsオプションを使用していて、ルーターに10.10.10.1 のラベルスイッチパス (LSP) がある場合、10.10.10.1 用の MPLS ルートは inet. 0 ルーティングテーブルでアクティブになります。これにより、ルーターは他の BGP ルーターへの10.10.10.1 ルートをアドバタイズできなくなります。一方、 mpls-forwardingbgp-igp-both-ribsオプションの代わりにこのオプションを使用すると、10.10.10.1/32 BGP ルートは他の BGP スピーカーにアドバタイズされますが、LSP は依然として10.10.10.1 の宛先にトラフィックを転送するために使用されます。

LSP メトリックを概要 LSAs に公開しています

LSP をリンクとして扱うように MPLS と OSPF を構成できます。この設定により、ネットワーク内の他のルーターがこの LSP を使用できるようになります。この目標を達成するには、MPLS と OSPF トラフィックエンジニアリングを設定して、LSP メトリックをサマリ LSAs にアドバタイズする必要があります。

MPLS には、 traffic-engineering bgp-igp and label-switched-pathステートメントを含めます。

これらのステートメントを以下の階層レベルで含めることができます。

  • [edit protocols mpls]

  • [edit logical-systems logical-system-name protocols mpls]

OSPF には、以下lsp-metric-into-summaryのステートメントを含めます。

このステートメントは、以下の階層レベルで含めることができます。

  • [edit protocols ospf traffic-engineering shortcuts]

  • [edit logical-systems logical-system-name protocols ospf traffic-engineering shortcuts]

ルーティング デバイスの詳細OSPF トラフィック制御ルーティング デバイス Junos OSルーティング プロトコル ライブラリ を参照してください

Interarea トラフィックエンジニアリングの有効化

Junos OS は、複数の OSPF 領域にわたって連続したトラフィックエンジニアリング LSP に通知できます。LSP シグナリングは、RFC 4206、ラベルスイッチ パス (LSP)階層(GMPLS(Generalized Multi-Protocol Label Switching)トラフィック エンジニアリング(TE)に記載されているネストまたは連続シグナリングのいずれかを使用して行う必要があります。ただし、連続したシグナリングのサポートは、基本的な信号だけに制限されています。再最適化は連続したシグナリングではサポートされていません。

次のセクションでは、interarea トラフィックエンジニアリング機能について説明します。

  • Interarea トラフィックエンジニアリングは、CSPF を使用して受信ルーター上で、OSPF 領域内で明示的ルートオブジェクト (ERO) の計算において、緩やかなホップ領域境界ルーター (Abr) が設定されている場合に有効にすることができます。ERO 拡張は Abr で完了しました。

  • Interarea トラフィックエンジニアリングは、CSPF が有効になっていても、受信ルーター上の LSP 設定で Abr が指定されていない場合に有効にすることができます (Abr が自動的に指定されます)。

  • DiffServ (差別化サービス) トラフィックエンジニアリングは、クラス型マッピングが複数の領域で一様になる限りサポートされます。

Interarea トラフィックエンジニアリングを有効にするにexpand-loose-hopは、各 LSP の伝送ルーターの構成にステートメントを含めます。

このステートメントは、以下の階層レベルで含めることができます。

  • [edit protocols mpls]

  • [edit logical-systems logical-system-name protocols mpls]

Lsp のトラフィックエンジニアリングの相互関係を有効にする

一般に、以下の条件を満たす Lsp に対しては、トラフィックエンジニアリングが可能です。

  • LSP の両方のエンドは同じ OSPF 領域にあるか、または同じ IS-IS レベルにあります。

  • LSP の2つのエンドは、同じ自律システム内の異なる OSPF 領域にあります (AS)。異なる IS-IS レベルで終了する Lsp はサポートされていません。

  • ASBRs は、明示的パス LSP の2つのエンドは異なる OSPF として機能し、自律システム境界ルーターは、明示的パス LSP でサポートされる緩やかなホップとして静的に構成されています。詳細については、明示的パス lsp の設定を参照してください。

Lsp に ASBRs が静的に定義されていない場合、トラフィックエンジニアリングは、1つのルーティングドメイン間またはその他の方法では実行できません。しかし、ASBRs が1つのサービスプロバイダによって制御されている場合、Lsp が、トラフィックのエンジニアリングを実行し、それらをリンクしている OSPF を動的に発見することができます (IS-IS はこの機能ではサポートされていません)。

特定のネットワーク要件が満たされている限り、Lsp を設計する際には、制限条件は適用されません。また、EBGP を使用してパッシブモードを構成することも OSPF ます。詳細については、以下のセクションをご覧ください。

AS 間トラフィックエンジニアリングの要件

Lsp を設計するためのトラフィックの適切な確立と機能は、以下のネットワーク要件に依存しています。これらはすべて満たされている必要があります。

  • すべての事業は、1つのサービスプロバイダによって管理されています。

  • OSPF は、それぞれの内部でルーティングプロトコルとして使用され、EBGP は、この2つの間のルーティングプロトコルとして使用されます。

  • ASBR 情報は、それぞれの内部で使用できます。

  • EBGP ルーティング情報は OSPF によって分散され、IBGP フルメッシュがそれぞれの内部に配置されます。

  • トランジット LSPはインタータイプリンクAS設定されていませんが、各インターフェイス上のエントリーおよび出口点 ASB 間の設定はAS。

  • 異なる ASBRs の間にある EBGP リンクはダイレクトリンクであり、OSPF のパッシブトラフィックエンジニアリングリンクとして設定する必要があります。リモートリンクアドレス自体は、ループバックやその他のリンクアドレスではなく、このパッシブリンクのリモートノード識別子として使用されます。パッシブトラフィックエンジニアリングモード構成の OSPF の詳細についてOSPF パッシブ TE モードの構成は、を参照してください。

さらに、OSPF パッシブトラフィックエンジニアリングリンクのリモートノードに使用されるアドレスは、EBGP リンクに使用されるアドレスと同じでなければなりません。ルーティング デバイスとルーティングOSPF BGPの詳細については、「 ルーティング デバイス向け Junos OS ルーティング プロトコル ライブラリ 」 を参照してください

AS 間トラフィックエンジニアリングの制限事項

Lsp を設計した AS トラフィックでサポートされています。ポイントツーポイントの Lsp のみがサポートされています (ポイントツー multipoint サポートはありません)。

さらに、以下の制限が適用されます。これらの条件のいずれかがあれば、上記の要件が満たされていても、Lsp が不可能であることを示すトラフィックをレンダリングするには十分です。

  • マルチホップ BGP の使用はサポートされていません。

  • BGP ルートが AS 内で認識されないようにするために、ポリサーまたはトポロジを使用することはサポートされていません。

  • EBGP ピア間の LAN での複数の ASBRs はサポートされていません。EBGP ピア間の LAN には1つの ASBR のみがサポートされています (その他の ASBRs は LAN に存在することがありますが、アドバタイズできません)。

  • ASBR 情報を隠されたり、リフレクタ内での ASBR 情報の配信を阻止したりするルートまたはポリシーは、サポートされていません。

  • 双方向 Lsp はサポートされていません (Lsp は、トラフィックエンジニアリングの視点からの片方向です)。

  • 同一宛先へのインターアドレスと AS a の両方を持つトポロジはサポートされていません。

さらに、すべての Lsp で日常的に行われているいくつかの機能は、AS 間トラフィックエンジニアリングでサポートされていません。

  • 管理グループのリンクカラーはサポートされていません。

  • セカンダリスタンバイはサポートされていません。

  • 再最適化はサポートされていません。

  • Crankback ルーターはサポートされていません。

  • 多様なパス計算はサポートされていません。

  • グレースフルリスタートはサポートされていません。

このような制限やサポートされない機能のリストは、Lsp を設計した AS トラフィックによって完全にはありません。

OSPF パッシブ TE モードの構成

通常、OSPF などの内部ルーティングプロトコルは、通信の間のリンクでは実行されません。しかし、トラフィックエンジニアリングを正しく機能させるには、as 間リンクに関する情報 (特に、リモートインターフェイス上のアドレス) を AS 内で使用できるようにする必要があります。この情報は、通常は EBGP 到達可能性メッセージまたは OSPF ルーティング広告には含まれません。

このリンクアドレス情報を AS してトラフィックエンジニアリングの計算に使用できるようにするには、各インターフェイスでトラフィックエンジニアリングのために OSPF パッシブモードを構成する必要があります。また、OSPF のリモートアドレスを配布し、トラフィックエンジニアリングデータベースに含める必要があります。

AS at インターフェイスでのトラフィックエンジニアリング用にパッシブモード OSPF 構成するには、 passiveリンクのステートメントを[edit protocols ospf area area-id interface interface-name]階層レベルで含めます。

OSPF はルーター上で適切に設定されている必要があります。次の例では、as 内のso-1/1/0 OSPF との間でトラフィックエンジニアリング情報を配信するように、インター as link を設定しています。リモート IP アドレスは192.168.207.2です。

パケット転送コンポーネント

Junos トラフィックエンジニアリングアーキテクチャのパケット転送コンポーネントは MPLS であり、ネットワーク全体で事前定義されたパスに沿って IP パケットのフローを指示します。このパスはラベルスイッチパス (LSP)と呼ばれます。Lsp は、シンプレックスです。つまり、ヘッドエンド (受信) ルーターからテールエンド (送信) ルーターへの一方向のトラフィックフローが行われます。二重トラフィックには、2人の Lsp が必要です。1つの LSP が各方向でトラフィックを伝送します。LSP は、1つまたは複数のラベル交換ホップを連結することで作成され、パケットを1つのルーターから MPLS ドメイン全体に転送できます。

受信ルーターは IP パケットを受け取ると、パケットに MPLS ヘッダーを追加し、それを LSP 内の次のルーターに転送します。ラベル付けされたパケットは、lsp の各ルーターによって、その送信ルーターの尾部に到達するまで、その後、LSP が転送します。この時点でMPLSヘッダーが削除され、パケットは IP 宛先アドレスなどのレイヤー 3 情報に基づいて転送されます。このスキームの価値は、LSP の物理パスが、宛先 IP アドレスに到達するために最短パスとして選択されるのは IGP だけではありません。

ラベル交換に基づくパケット転送

各ルーターのパケット転送プロセスは、ラベル交換の概念に基づいています。この概念は、恒久バーチャルサーキット (PVC) の各非同期転送モード (ATM) スイッチで発生するものに似ています。各 MPLS パケットには、20ビットの固定長ラベルフィールドを含む4バイトのカプセル化ヘッダーがあります。ラベルを含むパケットがルーターに到着すると、ルーターはそのラベルをチェックして、インデックスとして MPLS 転送テーブルにコピーします。転送テーブルの各エントリーには、同じインバウンドラベルを使用して特定のインターフェースに到着したすべてのパケットに適用される、転送情報のセットにマッピングされるインターフェイスインバウンドラベルペアが含まれています。

パケットが MPLS バックボーンを通過する方法

このセクションでは、MPLS バックボーンネットワークを通過する際の IP パケットの処理方法について説明します。

MPLS バックボーンのエントリーエッジでは、IP ヘッダーが受信ルーターによって検査されます。この分析に基づいて、パケットを分類し、ラベルを割り当て、MPLS ヘッダーにカプセル化して、LSP の次ホップに向けて転送します。MPLS は、IP パケットを LSP に割り当てることができるように、高い柔軟性を備えています。たとえば、Junos トラフィック制御 実装では、同じ MPLS ドメインから送信されるイングレス ルーターに到着したパケットすべてが、同じ エグレス ルーター に沿って転送されます。

パケットが LSP のトラバースを開始すると、各ルーターはラベルを使用して転送決定を行います。MPLS 転送の決定は、元の IP ヘッダーとは無関係に行われます。着信インターフェイスとラベルは、MPLS 転送テーブルへのルックアップキーとして使用されます。古いラベルが新しいラベルに置き換わり、そのパケットは LSP の次ホップに転送されます。このプロセスは、パケットが送信ルーターに到達するまで LSP の各ルーターで繰り返されます。

パケットが送信ルーターに到着すると、ラベルが削除され、パケットは MPLS ドメインから出ます。その後、パケットは、IP ルーティング プロトコルによって計算された従来の最短パスに従って、パケットの元の IP ヘッダーに含まれる宛先 IP アドレスに基づいて転送されます。

情報配信コンポーネント

トラフィックエンジニアリングには、ネットワークトポロジに関する詳細な知識のほか、ネットワークの負荷に関する動的情報が必要です。情報配信コンポーネントを実装するには、IGPs のシンプルな拡張機能が定義されています。各ルーターのリンク状態アドバタイズメントの一部として、リンク属性が含まれます。IS-IS 拡張機能には、新しいタイプ長の値 (TLVs) の定義が含まれていますが、OSPF 拡張は不透明なリンク状態アドバタイズメント (LSAs) によって実装しています。リンク状態 IGPs によって使用される標準フラッディングアルゴリズムにより、ルーティングドメイン内のすべてのルーターにリンク属性が確実に配布されます。IGP のリンク状態アドバタイズに追加するトラフィックエンジニアリング拡張機能には、最大リンク帯域幅、最大予約リンク帯域幅、現在の帯域幅予約、およびリンクカラーリングが含まれています。

各ルーターは、特化されたトラフィックエンジニアリングデータベースでネットワークリンク属性とトポロジー情報を管理します。トラフィックエンジニアリングデータベースは、物理トポロジ全体に Lsp を配置するための明示的なパスの計算にのみ使用されます。独立したデータベースが維持され、トラフィック制御の計算は IGP および IGP のリンク状態データベースに依存しない状態になります。一方、IGP は変更せずに動作を継続し、ルーターのリンク状態データベースに含まれる情報に基づいて従来の最短パス計算を実行します。

パス選択コンポーネント

ネットワークリンク属性とトポロジー情報が IGP によってあふれ、トラフィックエンジニアリングデータベースに格納された後、受信した各ルーターはトラフィックエンジニアリングデータベースを使用して、ルーティングドメイン全体で独自の Lsp セットのパスを計算します。各 LSP のパスは、厳密または緩やかに明示的なルートによって表すことができます。明示的ルートとは、事前に構成されたルーターの順序で、LSP の物理パスの一部として存在する必要があります。受信ルーターが LSP 内のすべてのルーターを指定している場合、LSP は厳密に明示的なルートによって識別されます。受信ルーターが LSP のルーターの一部のみを指定している場合、LSP は緩やかに明確なルートとして説明されます。厳密で緩やかな明示的ルートをサポートすることで、可能な場合にはパス選択プロセスに幅広い緯度を与えることができます。ただし、必要に応じて制約を受けることができます。

受信ルーターは、トラフィックエンジニアリングデータベースの情報に、制限された最短パスのファースト (CSPF) アルゴリズムを適用することで、各 LSP の物理パスを決定します。CSPF は、ネットワーク全体で最短パスが計算されるときに、特定の制限を考慮して修正した最短パス最初のアルゴリズムとして機能します。CSPF アルゴリズムへの入力には以下が含まれます。

  • IGP から学習されたトポロジーリンク状態情報とトラフィックエンジニアリングデータベースでの管理

  • IGP 拡張によって運ばれ、トラフィックエンジニアリングデータベースに保存される、ネットワークリソースの状態 (総リンク帯域幅、予約リンク帯域幅、利用可能なリンク帯域幅、リンクカラー) に関連する属性

  • 提案された LSP を通過するトラフィック (帯域幅要件、最大ホップ数、管理ポリシー要件など) をサポートするために必要な管理属性。ユーザーの構成から取得します。

CSPF は新しい LSP の各候補ノードとリンクを考慮していますが、リソースの可用性に基づいて特定のパスコンポーネントを承認または拒否するか、またはコンポーネントを選択しているかをユーザーポリシーの制約に違反するかどうかを判断します。CSPF 計算の出力は、制約条件を満たすネットワークを通過する最短パスを提供するルーターアドレスのシーケンスで構成される明示的なルートです。この明示的ルートはシグナル化コンポーネントに渡され、LSP に関するルーターで転送状態が確立します。

シグナリングコンポーネント

LSP は、その通知コンポーネントによって実際に設定されるまで、正常に動作しているとは限りません。LSP の状態を確立し、ラベルを配布するためのシグナルコンポーネントは、RSVP のさまざまな拡張機能に依存しています。

  • 明示的ルートオブジェクトを使用すると、従来の最短パス IP ルーティングに依存しない明示的なルーターのシーケンスを、RSVP path メッセージで走査できます。明示的ルートは、strict またはルースのどちらでもかまいません。

  • ラベル要求オブジェクトは、中間ルーターが、それが確立している LSP のラベルバインドを提供することを、RSVP path メッセージによって要求することを許可します。

  • Label オブジェクトを使用すると、既存のメカニズムを変更することなく、RSVP がラベルの分散をサポートできるようになります。Rsvp Resv メッセージは RSVP path メッセージの逆方向のパスに従っているため、Label オブジェクトはダウンストリームノードからアップストリームノードへのラベルの分散をサポートします。

オフラインパスの計画と分析

オンラインでのパス計算による管理作業の削減にもかかわらず、オフライン計画と分析ツールは、トラフィックエンジニアリングをグローバルに最適化するために依然として求められています。オンライン計算では、リソースの制約を考慮し、一度に1人の LSP を計算します。このアプローチの課題は、確定的ではないということです。LSP の計算順序は、ネットワーク上の各 LSP の物理パスを決定する上で重要な役割を果たします。プロセスの早い時期に計算された Lsp は、そのプロセスの後半で計算した lsp よりも多くのリソースを利用できます。これまでに計算した Lsp は、ネットワークリソースを消費しているからです。Lsp の計算順が変更された場合、Lsp の物理パスの結果セットも変更される可能性があります。

オフラインの計画および分析ツールが、各リンクのリソース制約と各 LSP の要件を同時に検証します。オフラインアプローチでは、完了まで数時間を必要としますが、グローバルな計算を実行し、各計算結果を比較してから、ネットワーク全体に最適なソリューションを選択します。オフライン計算の出力は、ネットワークリソースの利用率を最適化する Lsp のセットです。オフラインでの計算が完了した後は、グローバルに最適化されたソリューションのルールに従って各プラグインをインストールするため、Lsp は任意の順序で設定できます。

柔軟な LSP の計算と構成

トラフィックエンジニアリングは、トラフィックフローを物理トポロジにマッピングします。制約ベースのルーティングを使用して、パスをオンラインで確認できます。物理パスがどのように計算されているかに関係なく、転送状態は RSVP を介してネットワーク全体にインストールされます。

Junos OS では、LSP をルーティングおよび構成するために次の方法をサポートしています。

  • LSP のフルパスをオフラインで計算し、必要な静的転送状態を使用して LSP の各ルーターを個別に構成できます。これは、一部のインターネットサービスプロバイダ (Isp) が IP over ATM コアを構成する方法に類似しています。

  • LSP のフルパスをオフラインで計算し、受信したルーターをフルパスで静的に構成できます。受信ルーターは、動的なシグナリングプロトコルとして RSVP を使用して、LSP にある各ルーターに転送状態をインストールします。

  • 動的なオンライン LSP 計算を実行するには、制約ベースのルーティングを利用できます。各 LSP に制約を設定します。そのため、ネットワーク自体がこれらの制約に最適なパスを決定します。特に、受信ルーターは、制約に基づいて LSP 全体を計算してから、ネットワーク全体のシグナリングを開始します。

  • LSP の一部のパスをオフラインで計算し、受信したルーターをパス内のルーターのサブセットによって静的に構成することができます。その後、オンラインでの計算によって完全なパスを決定できます。

    たとえば、次のようなトポロジでは、米国内で2つの東西部のパスが含まれているとします。1つは北東からシカゴ、そして南部はダラスです。ニューヨークのルーターとサンフランシスコの1台の間で LSP を確立する場合は、LSP に対して部分的なパスを設定して、ダラスにルーターを1つの緩やかなルートホップとして含めることができます。その結果、南部のパスに沿って LSP がルーティングされます。受信ルーターは、CSPF を使用して完全なパスと RSVP を計算し、LSP に転送状態をインストールします。

  • 受信ルーターを制約なしで設定できます。この場合、通常の IGP 最短パスルーティングを使用して LSP のパスが決定されます。この構成では、トラフィックエンジニアリングの面でどのような価値も提供されません。しかし、仮想プライベートネットワーク (Vpn) などのサービスが必要になった場合には、これは簡単で、状況によっては便利です。

いずれの場合も、プライマリ LSP のバックアップとして Lsp をいくつでも指定できるため、複数の構成アプローチを組み合わせることができます。たとえば、プライマリパスを明示的にオフラインにして、セカンダリパスを制約ベースに設定し、3番目のパスを拘束しないようにすることができます。プライマリ LSP のルーティングが失敗した場合、受信ルーターはダウンストリームルーターから発生したエラー通知の停止または RSVP ソフトステータス情報の有効期限切れを通知します。その後、ルーターは、ホットスタンバイ LSP に対してトラフィックを動的に転送するか、RSVP を呼び出して新しいバックアップ LSP 用の転送状態を作成します。

RSVP PathErr メッセージを使用してトラフィックエンジニアリングの精度を高める

RSVP ベースのトラフィックエンジニアリングの重要な要素は、トラフィックエンジニアリングデータベースです。トラフィックエンジニアリングデータベースには、トラフィックエンジニアリングに参加するすべてのネットワークノードとリンクのリストと、各リンクに保持できる属性のセットが含まれています。トラフィックエンジニアリングデータベースの詳細については、「制約付きパス LSP 計算」を参照してください。最も重要なリンク属性の1つは帯域幅です。

RSVP Lsp が確立されて終了すると、リンクの帯域幅の可用性は急速に変化します。トラフィックエンジニアリングデータベースによって、実際のネットワークに対して矛盾が生じる可能性があります。このような矛盾は、IGP 更新の割合を増やして修正することはできません。

リンクの可用性は、同じ不整合の問題を共有することができます。利用できなくなったリンクは、既存のすべての RSVP Lsp を中断することがあります。ただし、利用できない場合でも、ネットワークによって簡単に知られているとは限りません。

このrsvp-error-hold-time文を設定する場合、ソースノード (RSVP LSP の受信) は、下流ノードから送信された PathErr メッセージを監視することで、LSP の障害から学習します。PathErr メッセージからの情報は、その後の LSP 計算に組み込まれているため、LSP の設定の精度と速度が向上します。一部の PathErr メッセージは、トラフィックエンジニアリングデータベースの帯域幅情報を更新するためにも使用され、トラフィックエンジニアリングデータベースとネットワークの間の矛盾を削減します。

update-thresholdステートメントを使用して、IGP 更新の頻度を制御できます。インターフェイスの RSVP Update しきい値の設定を参照してください。

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

PathErr メッセージ

PathErr のメッセージは、さまざまなコードとサブコード番号を使ってさまざまな問題を報告します。これらの PathErr メッセージの完全なリストは、RFC 2205、リソース予約プロトコル(RSVP)、バージョン 1、Functional Specificationおよび RFC 3209、RSVP-TE: LSP トンネルの RSVP の拡張

このrsvp-error-hold-time文を設定すると、リンク障害を表す PathErr メッセージの2つのカテゴリーが次のように調査されます。

  • この LSP のリンク帯域幅は不足しています。要求された帯域幅を利用できない(コード 1、サブコード 2)

    このタイプの PathErr メッセージは、リンクはのすべての Lsp に影響を与えるグローバルな問題を表します。これらは、実際のリンク帯域幅が LSP の要求よりも低いことを示しており、トラフィックエンジニアリングデータベースの帯域幅情報は overestimate である可能性が高いと考えられています。

    この種のエラーが受信されると、ローカルトラフィックエンジニアリングデータベースで利用可能なリンク帯域幅が減少し、将来のすべての LSP 計算に影響が出ます。

  • この LSP のリンクは利用できません:

    • アドミッション コントロールの障害—コード 1、サブコード(2 を除く)

    • ポリシー制御の障害(コード 2)

    • Service Preempted—code 12

    • ルーティングに関する問題 — 宛先に向けてルートを使用できない — コード 24、サブコード 5

    これらのタイプの PathErr メッセージは、通常、指定された LSP に関連しています。この LSP に障害が発生しても、他の Lsp が失敗したことを示唆するとは限りません。これらのエラーは、最大転送ユニット (MTU) の問題、サービスプリエンプション (オペレーターによって手動で開始された場合、または優先度の高い別の LSP によって) を示している場合があります。その場合は、次ホップのリンクがダウンしているか、ネクストホップの近隣ノードがダウンしているか、ポリシーに関する考慮事項この特定の LSP をリンクからルーティングすることをお勧めします。

問題リンクの特定

各 PathErr メッセージには、送信者の IP アドレスが含まれています。この情報は、受信したルーターに対して変更せずに伝達されます。トラフィックエンジニアリングデータベースのルックアップによって、PathErr メッセージを生成したノードを識別できます。

各 PathErr メッセージには、メッセージをトリガーする RSVP セッションを識別するために十分な情報が表示されます。中継ルーターの場合は、メッセージを転送するだけです。このルーターが受信ルーター (この RSVP セッション用) の場合、セッションが通過するすべてのノードとリンクの完全なリストが表示されます。リンクは、発信元ノードの情報と組み合わせることで一意に識別されます。

トラフィックエンジニアリングのデータベース精度を向上させるためのルーターの設定

トラフィックエンジニアリングデータベースの精度を向上させるには、 rsvp-error-hold-timeステートメントを設定します。この文が設定されている場合、ソースノード (RSVP LSP の受信) は、下流ノードから送信された PathErr メッセージを監視することで、LSP のエラーを学習します。PathErr メッセージからの情報は、その後の LSP 計算に組み込まれているため、LSP の設定の精度と速度が向上します。PathErr の一部のメッセージは、トラフィックエンジニアリングデータベースの帯域幅情報を更新するために使用されるため、トラフィックエンジニアリングデータベースとネットワークの間の矛盾を削減できます。

RSVP PathErr メッセージを記憶する MPLS 期間を設定し、CSPF 計算でその方法を検討rsvp-error-hold-timeするには、以下のステートメントを含めます。

このステートメントは、以下の階層レベルで含めることができます。

  • [edit protocols mpls]

  • [edit logical-systems logical-system-name protocols mpls]

時間には1~240秒の値を指定できます。デフォルトは25秒です。値0を設定すると、PathErr メッセージの監視が無効になります。

リリース履歴テーブル
リリース
説明
20.4R1
リリース Junos OS 20.4R1から、IPv4 アドレスに加え、IS-IS トラフィック制御 で IPv6 情報を トラフィック制御 データベース(TED)に保存する設定を行います。
17.4R1
Junos OS リリース 17.4 R1 では、トラフィックエンジニアリングデータベースによって、内部ゲートウェイプロトコル (IGP) トポロジー情報と、lsdist の RSVP TE トポロジ情報がインストールされます。0ルーティングテーブル
17.2R1
Junos OS リリース 17.2 R1 では、BGP のリンク状態アドレスファミリーが拡張され、ネットワーク (SPRING) トポロジー情報を、ソフトウェア定義型ネットワーク (SDN) コントローラに配信しています。
17.1R1
QFX10000 のスイッチでは、Junos OS リリース 17.1 R1 から、BGP を使用したリンク状態分散をサポートしています。