MPLS-TE 導入のための主要項目
[目次]
- ◆[はじめに]
- ◆[MPLS トラフィック エンジニアリング]
- ◆[復元力、トンネルの復旧]
- ◆[トラフィック エンジニアリングの実装]
- ◆[MPLS と QoS の統合]
- ◆[付録 A: LSP の設定ステップ(RSVP-TE シグナリング)]
- ◆[付録 B: 設定、トポロジの例]
- ◆[お問い合せについて]
- ◆[参考文献と推奨文献]
コア ネットワークにおける仮想パス機能および正確なトラフィック処理能力により、Multiprotocol Label Switching(MPLS)は、サービス プロバイダーのコア ネットワークの標準機能になりつつあります。
この White Paper では、これらの技術を使用した障害回復など、MPLS とトラフィック エンジニアリングについて説明します。また、QoS と MPLS の統合についても取り上げます。付録には参考資料として、設定とトポロジについて詳しく記載します。
| はじめに |
MPLS 導入の動機
インターネットの爆発的な成長は、サービス プロバイダーやネットワーク機器サプライヤに、トラフィックの急増という深刻な問題を呈しています。差別化された IP サービスを構築し、迅速に市場に導入したいという需要も高まっています。そのほか、IP をレイヤ 2 ネットワークを介してマッピングするコスト、より効率のよいネットワークの利用方法や障害の処理方法を特定するむずかしさ、といった課題もあります。
サービス プロバイダーは、すでにこれらの問題にさまざまな方法で取り組んでいます。帯域幅の拡大、高性能のルータの導入、QoS を活用したトラフィックのシェーピングやポリシングの改善などにより、使用可能な帯域幅をさらに効率良く使用しています。
Cisco IOS MPLS は、ルーティングのインテリジェンスをスイッチングのパフォーマンスに融合させます。このため、純粋な IP インフラを持つネットワークや、IP と ATM、またはその他のレイヤ 2 テクノロジーが混在するネットワークでは、大きな利点となります。
MPLS テクノロジーは、拡張可能なバーチャル プライベート ネットワーク(VPN)とエンドツーエンドの QoS の鍵であり、既存のネットワークを効率よく使用して将来の成長に対応させ、リンクやノードに障害が発生した場合は、迅速に障害を修正できます。
MPLS の概要MPLS は従来のルーティングとは異なり、ラベルを使用して MPLS ドメイン全体にトラフィックを転送します。パケットが MPLS ドメインに入ると、そのパケットにラベルが付けられ、そのラベル(IP ヘッダーではなく)で次のホップが決まります。ラベルは、MPLS ドメインの出口で取りはずされます。
ラベルの付いたパケットが Label Switching Router(LSR; ラベル スイッチング ルータ)に到達すると、入力ラベルでこのパケットの MPLS ネットワーク内でのパスが決まります。MPLS ラベル フォーワーディングはその後、このラベルを適切な出力ラベルに交換し、パケットを次のホップに送信します。
ラベルはグルーピング、または forwarding equivalence classes(FEC; 転送等価クラス)に基づいてパケットに割り当てられます。同じ FEC に属するパケットは、同じように処理されます。 この MPLS ルックアップとフォワーディングシステムにより、宛先アドレスと送信元アドレスに基づき明示的な制御ルーティングが実現されるため、新しい IP サービスの導入が容易になります。
ラベル スイッチングは従来から、転送スキームとして使用されています。ATM ではペイロード(IP など)に関係なく同じ技術を利用し、virtual path identifier/virtual channel identifier(VPI; 仮想パス識別子/VCI; 仮想チャネル識別子)を介してパケットを転送します。 IETF(米国技術特別調査委員会)が公表した MPLS 規格は、シスコのタグ スイッチングの実装から発展したものです。
ラベル スイッチングに関する IETF 勧告は、32 ビット シム ヘッダーを基準にしています。32 ビット シム ヘッダーは、ラベル(20 ビット)、Exp(3 ビット)、Stack(1 ビット)、TTL(8 ビット)で構成されています。
図 1: MPLS シム ヘッダー
ラベルと TTL は詳しい説明を必要としません。Stack ビットで、スタックのボトムが到達したことを知らせます。このことは、マルチスタッキング ラベル(MPLS-VPN やリンクプロテクションなど)に有効です。Exp(experimental)ビットでは主に QoS 関連の情報を伝搬します。
ラベルはレイヤ 2 とレイヤ 3 ヘッダーの間(パケット環境において)、または ATM ネットワークの VPI/VCI フィールドに挿入されます。
図 2: MPLS ラベル付きパケットのカプセル化

| MPLS トラフィック エンジニアリング |
MPLS ラベル スイッチングでは、MPLS ネットワークを介したパケット転送の基礎となる技術を提供しますが、トラフィック処理ポリシーなど、トラフィック エンジニアリングのサポートのためのコンポーネントをすべて提供するわけではありません。
トラフィック エンジニアリング(TE)とは、ネットワーク リソースの使用状況とトラフィック パフォーマンスを同時に最適化し、効率良く、信頼性のあるネットワーク オペレーションを促進するために、データ トラフィックが選択したパスを選択するプロセスのことです。TE の目標は、パスが制約(帯域幅や管理上の要件)を侵害しないように、またスカラメトリックに対して最適になるように、任意のノードから任意のノードへのパスを計算することです。パスが計算されると、TE でそのパスに従って転送状態の確立と維持を行います。
トラフィック エンジニアリングのコンポーネントMPLS に対応しているルータを Label Switching Router(LSR; ラベル スイッチング ルータ)といいます。MPLS クラウドの最後の LSR の直前にある LSR は、penultimate hop(最後から 2 番目のホップ)になります。エンドツーエンドの MPLS パスが Label Switched Path(LSP; ラベル スイッチド パス)です。LSP はヘッド エンド ルータで始まり、テール エンド ルータで終端します。
既存の Interior Gateway Protocols(IGP; 内部ゲートウェイ プロトコル)は、トラフィック エンジニアリングには適しません。通常、加算メトリックを使用し、帯域幅の有無やトラフィックの特性を考慮しない最短パスアルゴリズムに基づいてルーティングは決定されます。
このような機能を最も簡単に提供できるのはオーバーレイ モデルであり、物理ネットワーク上で仮想トポロジを実現できます。仮想トポロジは、ルーティング プロトコルへの物理リンクとなる仮想リンクから構築されています。また、オーバーレイ モデルは、次のようなさまざまな機能を提供できます。(1)制約ベースのルーティング、(2)トラフィック シェーピング機能とトラフィック ポリシング機能、(3)仮想リンクの耐久性などがその一部です。これらの機能を利用することにより、オーバサブスクライブのリンクから利用効率の低いリンクへ、トラフィックを簡単に移動できます。
MPLS はトラフィック エンジニアリングで使用されるオーバーレイ モデルです。次の機能を提供します。
1. 従来の宛先ベースのトラフィック フォワーディングに制約されない、明示的なラベル スイッチド パス(既存の IGP すべてに搭載)
2. 効率のよい管理が可能な LSP
3. インスタンス化可能で、LSP にマッピング可能なトラフィック トランク
4. トラフィック トランクに関連付けが可能な属性のセット
5. LSP とトラフィック トランクの配置を制約するリソースに関連付けが可能な属性のセット
6. 宛先ベースの IP フォワーディングでは集約だけを実現できますが、MPLS ではトラフィックの集約と分割の両方を実現できます。 「制約ベースのルーティング」とトランクの保護は、MPLS に容易に統合できます。
次のコンポーネントは、TE のサポートに利用できます。
- 情報の配信: ネットワーク トポロジとリンクに関連する制約(帯域幅など)に関する情報を送信
- パス選択アルゴリズム: 制約に従う最良のパスを計算し、選択
- ルートの設定: シグナリング LSP 設定用 RSVP-TE(Resource Reservation Protocol TE)の拡張
- リンク アドミッション制御: リソースを持つトンネルを決定
- TE コントロール: トランクの確立と維持
- パス全体へのデータの転送
図 3: MPLS-TE システムのブロック ダイアグラム(ヘッド ルータ)

情報の配信
TE は IGP プロトコルに基づき、リンク関連情報リソースの可用性を配信、フラッディングします。このリソースの可用性として、優先順位ごとの帯域幅(0 ~ 7)[最大リンク帯域幅、最大予約帯域幅、予約帯域幅]、リンク属性、TE 固有のリンク メトリック、リンクのリソース クラス属性などがあります。
IGP は拡張され、フラッディングされた 3 つの新しい TLV(Type Lengths Values)メッセージが含まれています。
- 各優先順位(0 ~ 7)で予約可能な帯域幅
- リンク カラーの割当
- メトリックに割り当てられたトラフィック エンジニアリング
4 番めの TLV メッセージは、DiffServ を意識したトラフィック エンジニアリングによって使用される、予約可能な帯域幅に関連します。
このような新しい、フラッディングされたアナウンスは、各 LSR で実行されるトラフィック エンジニアリングのプロビジョニングから発生します。情報の配信は定期的に(タイマー ベースで)、またはイベント ドリブン(使用可能な帯域幅やリンク構成の変更、LSP 設定の障害など)で行うことができます。
制約ベースのルーティング アルゴリズム(CBR)LSR は IGP 拡張を使用し、TE Link State database(TE-LSDB)を作成、管理します。 これは、Open Shortest Path First(OSPF)/Intermediate System to Intermediate System(IS-IS)プロトコルで使用する TE-LSDB によく似ています。 変更(新しい LSP の確立、使用可能な帯域幅の変更など)が発生する場合は必ず、IGP フラッディングにより更新される TE ネットワークトポロジが含まれています。
制約ベースのアルゴリズムを使用して LSP トンネルに最適なパスを見つけます。また、トランクのヘッド エンド(トンネルの開始点など)のターゲットになります。それは(1)新しいトンネルが要求された場合、(2)既存のトランクの最新 LSP に障害が発生した場合、(3)既存のトランクを再び最適化する場合、に限ります。
次の情報を考慮しています。
- ヘッド エンド ルータで始点となるトラフィック トランクの属性(手動で構成)
- リソースに関連付けられた属性(IS-IS/OSPF)
- トポロジ ステート情報(IS-IS/OSPF)
アルゴリズムの概要は次のとおりです。
ステップ 1. 不足なリソース(帯域幅)がなく、TE-LSDB からのポリシーの制約に違反するリンクを取り除きます。
ステップ 2. 残りのトポロジで Dijkstra を実行します(指定する場合は、IGP メトリックまたは TE メトリックを使用)
ステップ 3. 最も高い最小帯域幅、最小ホップカウントをもつパスを選択します。
結果として、制約ベースのルーティングは、[インターフェイス/IP アドレス] または [番号のないインターフェイス用のループバック] リストから構成される「制約付き最短パス」という明示のルートになります
LSP トンネルの設定方法 (適切なパスのシグナリング)ヘッド エンド ルータは、制約最短パスのシグナリング プロセスを開始します。 パス(または LSP)の確立は、RSVP-TE メッセージに基づいて行われます。
注: CR-LDP もまた実行可能なプロトコルですが、この White Paper では RSVP-TE を中心に扱います。
RSVP-TE はよく知られている RSVP プロトコル(RFC 2205 で定義)を拡張したものです。このプロトコルは複数のメッセージを定義しますが、この White Paper では LSP/パスの確立に使用されるメッセージについて説明します。RSVP-TE PATH と RSVP-TE RESV の 2 つのメッセージです。
RSVP-TE PATH メッセージ
ヘッド エンド ルータは、RSVP PATH メッセージを伝送します。PATH メッセージは制約付き最短パスにリストされたルータに従います。PATH メッセージには、各 LSR がパスに従って使用するオブジェクトが含まれています。
ラベル要求オブジェクト
- ERO(Explicit Route Object): ヘッド エンドからテール エンドまでのルートを特定します(この場合、制約付き最短パス)。
- RRO(Record Route Object): PATH メッセージが経由する LSR のリストを記録します。
- セッション属性: LSP 設定の優先順位、保留優先順位、プリエンプション、ローカル リンク保護の使用(フラグ 0x01)を制御します。
セッション オブジェクト: グローバルなラベル スイッチド パス トンネル ID を割り当てます。
Sender_: Transmission Specification(Tspec)、テール エンドに送信して適切な予約特性を指定します。
PATH メッセージは、明示経路オブジェクトにリストされたルータに従います。ホップごとに、PRO は名前(または IP アドレス)や到達した LSR で更新されます。
セッション属性には、LSP の設定とホールディング優先順位などが含まれているので、要求された帯域幅が優先順位の設定で指定された優先順位で使用できない場合に、役に立ちます。この場合、要求した帯域幅は使用できますが、より優先順位の低いセッションが使用している場合、より優先順位の低いセッションが、必要な帯域幅を先に解放します。
セッション属性には、ローカル保護フラグのサポートも含まれています。
RSVP-TE RESV メッセージ
PATH メッセージを受信すると、テール エンドが RESV メッセージを送信します。テール エンドは、ラベル ディストリビューション プロセスを開始する必要があります。次のオブジェクトが利用できます。
- ラベル オブジェクト: 使用するラベルです。
- レコード ルート オブジェクト: RESV メッセージをヘッドエンドに戻す LSR のリストです。
- スタイル オブジェクト: Shared explicit など、ラベル予約スタイルを制御します。
- セッション オブジェクト: PATH メッセージからコピーされたグローバル ラベル スイッチド パス ID。
各 LSR で、RESV メッセージはラベルの値を識別し、着信インターフェイスに割り当てます。各 LSR は、ローカル ラベル(ラベルオブジェクトによって配信)を次のダウンストリーム LSR に対して割り当てる必要があります(PRO ごとに識別)。
2 つのコントロール プレーンは、パス設定とすべての MPLS オペレーションに関連しています。トランク アドミッション制御とリンク アドミッション制御。
トランク アドミッション制御では、リソースがラベル スイッチド パスに従って使用できるかどうか確認します。また、必要な場合は、優先順位の低い既存の LSP の分割も行います。また、トランク アドミッション制御はリソースに変更があった場合、IGP 情報の配信を開始します。
リンク アドミッション制御は、PATH メッセージ内で使用します(帯域予約と比較)。帯域幅を利用できる場合は、RESV メッセージを受信するまで、この帯域幅を待機プールに移動します。その他の場合は、RESV [10] を受信すると、パス エラー メッセージが送信されます。
ここで述べたメッセージとサポート対象オブジェクトの詳細に関しては、RSVP-TE 仕様 [10] を参照してください。また、LSP の設定ステップは付録 A に記載します。
ラベル スイッチド パスが確立されると、次のステップとしてこの LSP 全体にトラフィックを転送します。Cisco IOS MPLS TE を使用すると、現状では、次の 2 つの可能性があります。
1. Policy Base Routing(テール エンドの先にある宛先に対するトンネルをポイントするスタティック ルートなど)経由
2. Cisco IOS MPLS TE AUTOROUTE Announce 使用による自動化
Cisco IOS MPLS AUTOROUTE Announce は、ヘッド エンド ルータのルーティング テーブル(フォワーディング テーブル)にテール エンド ルータとダウンストリーム ルータがアナウンスした経路を、トンネルを介して直接到達できる経路としてインストールします。
制約ベースのルーティング アルゴリズムにより、MPLS TE でヘッド エンドからテール エンド ノードまでのラベル スイッチ パスを確立できます。デフォルトでは、これらのパスは IGP ルーティング プロトコルにアナウンスされません。そのため、テール エンド ルータとダウンストリーム ルータがアナウンスしたすべてのプレフィクスやネットワークが、これらのパスからは見えません。
リンクステート IGP は、AUTOROUTE Announce を使用して設定された各 MPLS TE トンネルごとに、テール エンド ルータとダウンストリーム ルータがアナウンスした経路を RIB にインストールします。このため、トポロジ的にトンネル ヘッド エンドの先でプレフィクスに関連づけられたすべてのトラフィックは、トンネルにプッシュされます。
この機能をよりよくご理解いただくために、AUTOROUTE Announce 機能を有効にした場合と、有効にしていない場合の例を考察します。アルゴリズムの詳細についても取り上げます。
図 4 のトポロジについて考察します。わかりやすくするために、Ri のループバック アドレスを i.i.i.i とします。
図 4: トンネルのないトポロジ

通常の IGP で、MPLS TE を持たないルータ R1 のルーティング テーブルは以下のとおりです。
図 5: R1 のルーティング テーブル

図 4 と同じトポロジを検討し、トンネル T1 と T2 それぞれに MPLS トラフィック エンジニアリングを導入します。 トンネル T1(resp. T2)は R1 で始まり、テールエンドは R4(resp. R5)です。
MPLS TE AUTOROUTE Announce は、2 つのトンネルで有効になります。 同様に、R1 ルーティング テーブルのエントリを図 7 に記載します。
図 6: トンネルのあるトポロジ

図 7: AUTOROUTE Announce のある R1 ルーティング テーブル

ルーティング テーブル(図 5 と図 7)は、R4 と R5 が、MPLS TE AUTOROUTE Announce を使用してトンネル T1(resp. T2)経由で直接到達できることを表しています。同様に、R8 は「物理的」接続ではなく、R4 を介してトンネル T1 経由で到達可能になります。
Cisco MPLS TE AUTOROUTE Announce を使用しない場合、トンネル T1 が稼動する場合でも、R8 への経路は「物理的に」接続されます(図 5 参照)。
AUTOROUTE Announce アルゴリズム
ステップ 1. 通常の Dijkstra をトンネルのないトポロジで実行します。
ステップ 2. ツリーを通過し、各トンネルに対するリンクを追加します。
- 新しいリンクのメトリック = {metric(igp) +/- relative} XOR {absolute}
ここでメトリック(igp)は、トンネルのない IGP が計算した最短パスのメトリックになります。
ステップ 3. ツリーを通過し、ノードごとに、このノードへのリンクとその ノードへの最適パス上にないリンクを切り捨てます。
同じメトリックのリンクが 2 つある場合、このノードで終端しているトンネルを表しているリンクが残ります。
ステップ 4. IP- プレフィクス リーフをツリーに追加します。
ステップ 5. ツリーを通過し、リーフごとにフォワーディング テーグルのエントリを追加します。 エントリ用に使用したメトリックは、ツリーのルートからこのリーフに到達する際に使用されるリンクのメトリックの合計と等しくなります。
例外: ツリーからリーフまでのパスが、絶対的なメトリックを使用して構成されたトンネルを表しているリンクを経由している場合、このリーフのメトリック(このプレフィクス)はこの絶対的なメトリックだけです。
最新のアルゴリズムに従って、リンク ステート IGP は、テール エンド ルータとダウン ストリームルータがアナウンスしたルートを RIB にインストールします。また、任意の MPLS トラフィック エンジニアリング トンネルの変更は、IGP にアナウンスされ、その変更に関連付けられるルートへの調整を行うために完全な SPF 計算を開始します。レイヤ 3 から考えると、MPLS トンネル情報の変更の大半は、トンネルのテール エンド ルータとダウンストリーム ルータに限定されています。拡張性の点から、新しく最適化されたアルゴリズムが導入されました。テール エンドの設定に基づいて、子(ダウンストリーム ルータ)がある場合、全体または部分的 SPF 計算は、変更時に対象になります。
| 復元力、トンネルの復旧 |
ネットワークの信頼性は、高速ネットワークには不可欠です。 ネットワークの分断は、さまざまな原因で発生します。 LSP 伴って生じる輻輳、障害が発生したリンク、障害が発生したノード、LSP での管理上の変更などの原因が挙げられます。 MPLS TE の最も魅力的な機能の 1 つは、LSP 全体に、分断することのないトラフィックを提供する機能です。 停電が発生した場合、上位レベルのアプリケーションはサービスの中断に気付きません。
パスの保護は、プロトコルスタックの複数の層で実現できます。
- 物理層(自動保護切り替えのある SONET など)
- IP(トポロジが変更になった場合のルーティング プロトコル、IGP、BGP、ネクスト ホップの変更など)
- MPLS(トポロジの変更時にヘッド エンドが実行)
MPLS TE を使用した場合、パスの復元のためのオプションが複数あります。
- ヘッド エンドの再ルーティング
- 迅速な再ルーティング(リンク保護)
- 迅速な再ルーティング(ノード保護)
トランクが取得するパスは、MPLS パスの開始点(ヘッド エンド)で LSR が決定するので、パスの復旧がヘッド エンドで行われるのが自然だと考えられます。
ヘッド エンドの再ルーティングは、主に次の 2 つのイベントが対象になります。それは、RSVP-TE によるパスを維持できない(輻輳など)という通知、または IGP によるトポロジの変更通知です。(3 つめは CLI からパスを最適化するよう要求されたアクションです。)
ヘッド エンド ルータはこの 3 つのイベントのうちの 1 つを受け取ると、障害が発生したリンクや輻輳の箇所を切り離してから、新しい TE データベースを構築します。ヘッド エンドはその後、"shared-explicit" 予約スタイルを持つ新しいパスのシグナリングを再度行います。"shared-explicit" 予約スタイル [10] により、新しい LSP は、予約された帯域幅を二重にカウントせずに、前の LSP が使用したリンクの一部を使用できます。
新しい LSP が稼動すると、ヘッド エンド ルータはフォワーディング テーブルを変更し、元の LSP は切断されます。
ヘッド エンドの再ルーティングは、障害復旧に対するパスの再最適化に最も適しています。ヘッド エンドの通知は、IGP または RSVP-TE が障害の発生したリンクまたは輻輳の箇所をいかに迅速に発見し、その情報をヘッド エンドにフラッディングとして返すかによって異なります。
ガイドラインとして、IS-IS を IGP として使用することを検討する場合、ヘッド エンドの通達の最短時間は次のようになります。時間(IGP の反応) + 時間(RSVP-TE シグナリング)。時間(IGP の反応)の内訳は次のようになります。リンクの障害を検出する時間、LSDB を変更する時間、新しい LSDB をフラッディングする時間です。平均値は約 2 ~ 3 秒です(最適にチューニングされている場合)。新しいラベル スイッチ パスの計算およびシグナリング時間も考慮する必要があります。このため、トラフィックは 2 ~ 3 秒では回復しません。
残念ながら、これらのバックアップ LSP の確立時間は、MPLS TE の一部のアプリケーションにとっては長すぎる場合があります。MPLS Fast Reroute 機能は、ヘッド エンドが 置換え用の LSP を確立する間に発生するサービスの中断時間を最小限に抑えるために、検知された障害に従ってルーティングすることにより、LSP を迅速に修復する(50 ms 未満)メカニズムを提供します。
MPLS TE の Fast Reroute は障害が発生したリンクで失われるパケットの総数を大幅に削減します。FastReroute のトンネル復元機能を使用して、LSP パス内でエンドツーエンドの LSP(FRR パスの保護)、またはローカル リンク(FRR リンクの保護)およびノード(FRR ノード保護)を保護できます。
この White Paper では、FRR リンク保護について解説します。
Cisco FRR リンク保護FRR はリンク障害が発生した場合に、障害が発生したリンクの周囲の再ルーティングを実現する処理を確立します。LSP は事前に設定されたバックアップ トンネルを使用して次のホップへルーティングされます。バックアップ トンネルは、LSP が保護されたリンクを経由せずに次のホップのダウンストリーム ルータに到達できるように設定する必要があります。FRR リンク保護ではノードの復元をサポートしませんが、特定のリンクを保護します。
図 8: 次のホップへのリンクの保護、Fast Reroute のないラベル/パケット フロー

プライマリ LSP(トンネル 0)は、R1 ~ R6 に設定されます(図 8)。FRR を介した R2 と R3 の間のリンクは保護されます。 バックアップ「トンネル」は障害が発生した場合だけ使用され、R2 で R3、R4 を経由するように静的に設定されます。この特別なトンネルを設定する場合は、プライマリ トンネルで使用するリンクは使用できません。
LSP トンネル 0 のパケット フローは、図 8 に記載されています。R1 は R6 へ進む任意のパケットにラベルを付けます。R5 が Penultimate Hop Popping(PHP)を行っている間に、R2、R3 はラベル スワッピングを実行します。
R2 と R3 の間のリンクに障害が発生した場合、R2 はすぐに R6 へのトラフィックをバックアップ LSP 内でスワップするので、パケットの損失の総量を大幅に低減できます。このオペレーション全体で約 50 ミリ秒です。
図 9: Fast Reroute 使用時のラベルおよびパケット フロー

リンク障害が発生すると(図 9)、R2 はバックアップ リンクを通過するために、すべての着信ラベルの再書き込みを行います。結果として R2 は、パケットを別のダウンストリーム インターフェイスに送信することで、障害の周囲のトラフィックの再ルーティングを行います。
R6 へのパケットは、バックアップ リンクを通過する際に、2 つのレベルのラベル スタックを使用します。それは、バックアップラベルと、このリンクを通過する場合(リンク障害が発生していない場合など)に、リンク(R2、R3)で使用されるラベルです。R4 はパケットを受信すると、「バックアップ ラベル」をポップし、パケットを R3 に送信します。パケットがインターフェイス(R4、R3)を経由して R3 で受信されると、障害が発生しているリンク(R2、R3)、またはプライマリ トンネルから受信した場合と同じラベルを持っています。
このステップは、ダウンストリーム ルータが「グローバル アプリケーション プール」からラベルを提供し、R2 でグローバル ラベルも使用するインターフェイスに再ルーティングされる場合に限り実行できます。MPLS グローバル ラベルの割り当ては、ルータのすべてのインターフェイスに対して、1 つのラベル スペースがあることを意味しています。(たとえば、あるインターフェイスのラベル 15 は、別のインターフェイスのラベル 15 と同じように処理されます)。
ヘッド エンド上のコンフィグレーション コマンドを実行した結果、この機能が関連する LSP トンネルに有効になる場合に、Fast Reroute は、LSP に対して開始されます。ヘッド エンド ルータは、RSVP PATH メッセージでセッション属性フラグビットを(0x01 に)設定することにより、LSP が保護を要求している LSP のパスに従って、すべてのルータに通知する働きをします。
LSP トンネルのヘッド エンドのコントロール モジュールは、すべてのアクティブな LSP に対する Fast Reroute 属性の状態を RSVP に常に通知します。LSP のパスに沿ったラベル スイッチ ルータ(LSR) [テールエンド以外] の RSVP モジュールは LSP が保護する必要があることを学習すると、ローカルの Fast Reroute の保護ステップを開始して、迅速なダウンストリーム リンクの潜在的な障害に対して、LSP を保護します。
リンク障害の場合は、保護された LSP はすべて、バックアップ パスに切り替わります。障害がダウンストリームを検知する場合も、FRR は、ダウンストリーム ルータ(LSP が使用しているパスに従う)が、LSP を分解しないよう操作します。
新しい LSP は特定の間隔で自動的に実行される再最適化プロセスにより、またはヘッド エンドでの RSVP PathErr メッセージの受信時に、ヘッド エンドによって再度シグナリングが行われます。
次の次のホップへのバックアップ(ノード保護)図 10: 次の次のホップへのリンクの保護

このシナリオ(図 10)では、プライマリ LSP について考察します。この場合プライマリ LSP は、R1-R2-R3-R5-R6 です。ノード R3 の保護は、a)R2-R4-R5-R3 または b)R2-R4-R5 で実現されます。 a)の場合、バックアップ パスは R1-R2-R4-R5-R3-R5-R6 で、次のホップへのバックアップ トンネルと同じです。けれども、(R3、R5)リンクは、トラフィックを R6 へ 2 回伝搬する(二重予約など)ことに注目してください。これは最適なソリューションではありません。
「次の次のホップへのバックアップ」(ノード保護)である R1-R2-R4-R5-R6 のバックアップ パスのある b)の場合を考察します。
ノード保護が実際にはリンク保護よりも複雑なのは、R2 がリンク R3 ~ R5 で使用されるラベルを認識する必要があり、R5 はバックアップ リンクから正しいラベルを受け取るよう要求されるからです(図 11)。拡張されたルート レコード オブジェクトを使用すると、R2 でこのラベルを修得できます。
図 11: ノード保護、ラベル フロー

[Cisco IOS ソフトウェアでのノード保護は現在サポートされていませんが、近日中にサポートする予定です]
バックアップ方式の使用時期FRR リンク保護とノード保護では、次のホップ、または次の次のホップ(ノード保護の場合)で以前使用されたラベルを把握しておく必要があるので、グローバル ラベルの使用を想定しています。 リンクとノード保護は、主に、複数の LSP のサービスを行っている機密性の高いリンクやデバイスのバックアップを行うよう、設計しています。
また、ノード保護は、同じ宛先に複数のバックアップ トンネルを作成する機能を提供するので、トラフィックをこれらのトンネル全体に、負荷分散できます。
パスを保護する目的は、エンドツーエンドでの保護を実現することなので、グローバル ラベルは必要ありません。
| トラフィック エンジニアリングの実装 |
MPLS TE を展開する前に、ネットワークのトラフィックの負荷パターンを明確にする必要があります。
MPLS TE では遅延が改善され、使用可能な帯域幅がより広くなるパスを選択するので、ネットワークは最適化されます。 ただし、Integrated Gateway Protocol(IGP)がこれらのパスを選択しなかった可能性もあります。 通常、この操作は、サービス プロバイダーがトラフィック負荷パラメータとネットワークトポロジを入力するモデリングツールによって行われ、ツールは代替の「最適」パスを提示します。
Cisco IOS MPLS AutoBandwidth Allocator は、サービス プロバイダーが任意の帯域幅の値を使用してトンネルを設定できるようにすることで、MPLS TE トンネルのインストールを迅速化し、トラフィックを中断せずに、トラフィックのパターンに基づいて動的および自動的に帯域幅を調整します。Cisco IOS MPLS AutoBandwidth により、トンネルの初期設定と再プロビジョニングの複雑さは緩和されており、サービス プロバイダーは、MPLS TE をトラフィック管理ソリューションとして容易に採用できます。
Cisco AutoBandwidth AllocatorCisco IOS MPLS AutoBandwidth Allocator は、MPLS トラフィック エンジニアリング(TE)トンネルの帯域幅のサイズを、トンネルを移動するトラフィック量に基づいて自動的に調整します。これにより、MPLS TE トンネルに対して帯域幅のモニタリングや再設定を行う作業を自動化します。
Cisco MPLS AutoBandwidth 用に設定した MPLS TE トンネルごとに、さまざまな設定可能なパラメータに基づいて平均的な出力レートのサンプリングが行われます。トンネルの帯域幅はその後、一定のインターバル内に発見された最も高い平均出力レート、または設定された最大帯域幅の値に基づいて、自動的に再調整されます。実際には、Cisco MPLS AutoBandwidth Allocator は、X 分間(デフォルトでは、X=5 分)の平均カウンタをモニタし、設定可能なインターバル Y(デフォルトでは、Y=24 時間)で最大 X 平均を記録し、そのインターバルの最大 X 平均に基づいてトンネルの帯域幅を再調整します。
Y インターバルが終了すると、最初の最大 X 平均は、次の Y インターバルで新しい最大 X 平均を記録するためにクリアされます。
X インターバルはユーザ設定可能で、AutoBandwidth 用に設定されたすべてのトンネルに適用されるグローバル パラメータです。インターバル Y は各トンネル単位で設定でき、より長い Y インターバルは、トラフィックの帯域幅で実際のピークに非常によく似た X 平均を提供します。
新しい帯域幅の制約を使用して LSP を再調整すると、新しい Resource Reservation Protocol for Traffic Engineering(RSVP-TE)PATH 要求が生成され、新しい帯域幅を使用できない場合は、最後の優良 LSP を継続して使用します。ネットワークではトラフィックの中断はありません。
任意のトラフィック エンジニアリング トンネルで、次のトラフィック パターン(時間に対する帯域幅の使用)を考察します(図 12)。LSP のシグナリングに使用する帯域幅の値は、期間中に観察される最も高い帯域幅ピークをはるかに上回ると仮定します(オーバー プロビジョニング)。
MPLS TE AutoBandwidth Allocator により、ネットワーク オペレータは Y インターバル中に使用される最高の平均帯域幅の測定に基づいて、帯域幅のニーズを自動的に調整できます。 期間 N で、赤い点はこの期間の最大帯域幅を表しています。この値はその後、期間 N + 1 で調整済みの LSP のシグナリングに使われ、ネットワーク プロバイダーがトラフィックと帯域幅の管理を最適化できるようになります。
図 12: 時間の経過に伴う Cisco MPLS Bandwidth Allocator による帯域幅調整の実例

| MPLS と QoS の統合 |
QoS 機能を現在のネットワークに追加する 2 つのアーキテクチャがあります。Integrated Services(IntServ)と Differentiated Services(DiffServ; 差別化サービス)です。IntServ では、リソース リザベーション プロトコル(RSVP)を使用して、個別のフロー、またはフローのグループに対してエンドツーエンドの QoS を維持します。[RFC 1633 で定義された IntServ アーキテクチャ]
DiffServ は、IETF が定義した IP ネットワークの 2 つの QoS アーキテクチャの 1 つです。このモデルでは、DiffServ 対応ネットワークに入っていくパケットは、少数のクラスにグループ分けされます。各クラスには、クラスに関連付けられた色やマークがあります(DiffServ Code Point(DSCP)ビットの使用)。このため、パケットの分類は非常に拡張性のあるものとなり、ネットワーク コアでの適切な帯域幅と遅延が保証されます。コア ネットワーク内の各ノードには、パケットが伝搬するマーキングに基づいてすべてのパケットでのさまざまなキューイング ポリシーと廃棄ポリシーが適用されます(Per Hop Behavior)。
MPLS+DiffServMPLS+DiffServ アーキテクチャでは、DiffServ Code Point とマークされたパケットは、MPLS ネットワークに入り、PHB はパスに従って すべての LSR で強化されます。LSR には IP ヘッダーの認識がないので、PHB は別の情報を見て実現する必要があります。
2 つの一般的なアプローチを使用して、MPLS ネットワーク内で QoS を処理するための MPLS トラフィックをマークします。
1 つめの方法では、DiffServ のカラリング情報は MPLS シム ヘッダーの EXP(experimental)フィールドにマッピングされます。このフィールドでは、DSCP の 64 に対して、最大で 8 つの異なる QoS マーキングが可能です。各ホップの(MPLS クラウドの)パケット スケジューリング(PHB)は EXP に基づいて実行されます。このアプローチを使用するラベル スイッチド パスは、E-LSP と言い、QoS 情報は EXP ビットから類推されます。
また各 MPLS パケットに関連付けられたラベルは、パケットをキューにいれる方法を指定する DiffServ マーキングを保持します。DiffServ マーキングの廃棄の優先部分は、EXP ビット(MPLS シム ヘッダーを使用している場合)、または基礎となる技術に関して、この目的のために使用できるフィールド(ATM の CLP ビット、フレームリレーの場合は DE ビット)に保持されます。
入口の LSR は、IP ヘッダーで DSCP を検証し(ATM/フレーム リレーの CLP/DE)、その QoS レベルに対してプロビジョニングが行われている LSP を選択します。出口では、ラベルが取り除かれるので、パケットは元の DSCP を使用して次の IP ホップに送信されます。このアプローチを使用した LSP は L-LSP と言い、QoS 情報は MPLS ラベルからある程度類推されます。
マッピング(E-LSP 対 L-LSP)の最適な選択および各手法に関しては、[7] と [4] を参照してください。
表 1: E-LSP と L-LSP の比較