Internet Engineering Task Force (IETF) K. Kumaki, Ed.
Request for Comments: 5824 KDDI Corporation
Category: Informational R. Zhang
ISSN: 2070-1721 BT
Y. Kamite
NTT Communications Corporation
April 2010
Requirements for Supporting
Customer Resource ReSerVation Protocol (RSVP)
and RSVP Traffic Engineering (RSVP-TE) over a BGP/MPLS IP-VPN
Abstract
抽象
Today, customers expect to run triple-play services through BGP/MPLS IP-VPNs. Some service providers will deploy services that request Quality of Service (QoS) guarantees from a local Customer Edge (CE) to a remote CE across the network. As a result, the application (e.g., voice, video, bandwidth-guaranteed data pipe, etc.) requirements for an end-to-end QoS and reserving an adequate bandwidth continue to increase.
今日では、顧客は、BGP / MPLS IP-VPNを経由トリプルプレイサービスを実行するように期待しています。一部のサービスプロバイダは、ネットワークを介してリモートCEへのローカルのカスタマーエッジ（CE）からのサービス品質（QoS）の保証を要求するサービスを展開します。結果として、アプリケーション（例えば、音声、ビデオ、帯域保証型データパイプ、等）のエンドツーエンドのQoSの要件と十分な帯域幅を確保増加し続けます。
Service providers can use both an MPLS and an MPLS Traffic Engineering (MPLS-TE) Label Switched Path (LSP) to meet their service objectives. This document describes service-provider requirements for supporting a customer Resource ReSerVation Protocol (RSVP) and RSVP-TE over a BGP/MPLS IP-VPN.
サービスプロバイダは、そのサービスの目標を達成するためにMPLSおよびMPLSトラフィックエンジニアリング（MPLS-TE）ラベルスイッチパス（LSP）の両方を使用することができます。この文書は、BGP / MPLS IP-VPNを介して顧客のリソース予約プロトコル（RSVP）とRSVP-TEをサポートするためのサービス・プロバイダーの要件について説明します。
Status of This Memo
このメモのステータス
This document is not an Internet Standards Track specification; it is published for informational purposes.
このドキュメントはインターネット標準化過程仕様ではありません。それは、情報提供の目的のために公開されています。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
このドキュメントはインターネットエンジニアリングタスクフォース（IETF）の製品です。これは、IETFコミュニティの総意を表しています。これは、公開レビューを受けており、インターネットエンジニアリング運営グループ（IESG）によって公表のために承認されています。 IESGによって承認されていないすべての文書がインターネットStandardのどんなレベルの候補です。 RFC 5741のセクション2を参照してください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc5824.
このドキュメントの現在の状態、任意の正誤表、そしてどのようにフィードバックを提供するための情報がhttp://www.rfc-editor.org/info/rfc5824で取得することができます。
Copyright Notice
著作権表示
Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（C）2010 IETF信託とドキュメントの作成者として特定の人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
この文書では、BCP 78と、この文書の発行日に有効なIETFドキュメント（http://trustee.ietf.org/license-info）に関連IETFトラストの法律の規定に従うものとします。彼らは、この文書に関してあなたの権利と制限を説明するように、慎重にこれらの文書を確認してください。コードコンポーネントは、トラスト法規定のセクションで説明4.eおよび簡体BSDライセンスで説明したように、保証なしで提供されているよう簡体BSDライセンスのテキストを含める必要があり、この文書から抽出されました。
This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.
この材料の一部がIETFトラストにこのような材料の変更を許可する権利を与えられていない可能性がありますにこの文書は、2008年、IETFドキュメントまたは11月10日以前に発行または公開さIETF貢献から著作権を支配する者（複数可）材料を含んでいてもよいですIETF標準化プロセスの外。そのような材料の著作権を管理者（単数または複数）から適切なライセンスを取得することなく、この文書は、IETF標準化過程の外側修正されないかもしれません、そして、それの派生物は、IETF標準化過程の外側に作成されない場合があり、それをフォーマットする以外出版RFCとして、英語以外の言語に翻訳します。
Table of Contents
目次
1. Introduction ....................................................4
2. Requirements Language ...........................................4
3. Terminology .....................................................5
4. Problem Statement ...............................................5
5. Application Scenarios ...........................................7
5.1. Scenario I: Fast Recovery over BGP/MPLS IP-VPNs ............8
5.2. Scenario II: Strict C-TE LSP QoS Guarantees ................8
5.3. Scenario III: Load Balance of CE-to-CE Traffic .............9
5.4. Scenario IV: RSVP Aggregation over MPLS-TE Tunnels ........11
5.5. Scenario V: RSVP over Non-TE LSPs .........................12
5.6. Scenario VI: RSVP-TE over Non-TE LSPs .....................13
6. Detailed Requirements for C-TE LSP Model .......................14
6.1. Selective P-TE LSPs .......................................14
6.2. Graceful Restart Support for C-TE LSPs ....................14
6.3. Rerouting Support for C-TE LSPs ...........................15
6.4. FRR Support for C-TE LSPs .................................15
6.5. Admission Control Support on P-TE LSP Head-Ends ...........15
6.6. Admission Control Support for C-TE LSPs in
LDP-Based Core Networks ...................................16
6.7. Policy Control Support for C-TE LSPs ......................16
6.8. PCE Features Support for C-TE LSPs ........................16
6.9. Diversely Routed C-TE LSP Support .........................16
6.10. Optimal Path Support for C-TE LSPs .......................17
6.11. Reoptimization Support for C-TE LSPs .....................17
6.12. DS-TE Support for C-TE LSPs ..............................17
7. Detailed Requirements for C-RSVP Path Model ....................18
7.1. Admission Control between PE-CE for C-RSVP Paths ..........18
7.2. Aggregation of C-RSVP Paths by P-TE LSPs ..................18
7.3. Non-TE LSP Support for C-RSVP Paths .......................18
7.4. Transparency of C-RSVP Paths ..............................18
8. Commonly Detailed Requirements for Two Models ..................18
8.1. CE-PE Routing .............................................18
8.2. Complexity and Risks ......................................19
8.3. Backward Compatibility ....................................19
8.4. Scalability Considerations ................................19
8.5. Performance Considerations ................................19
8.6. Management Considerations .................................20
9. Security Considerations ........................................20
10. References ....................................................21
10.1. Normative References .....................................21
10.2. Informative References ...................................22
Acknowledgments....................................................23
Appendix A. Reference Model........................................24
A.1 End-to-End C-RSVP Path Model................................24
A.2 End-to-End C-TE LSP Model...................................25
Some service providers want to build a service that guarantees Quality of Service (QoS) and a bandwidth from a local Customer Edge (CE) to a remote CE through the network. A CE includes the network client equipment owned and operated by the service provider. However, the CE may not be part of the MPLS provider network.
一部のサービスプロバイダは、サービスの品質（QoS）とネットワークを介してリモートCEへのローカルカスタマーエッジ（CE）からの帯域幅を保証したサービスを構築したいです。 CEは、サービスプロバイダが運営するネットワーククライアント機器が含まれています。しかし、CEはMPLSプロバイダーネットワークの一部ではないかもしれません。
Today, customers expect to run triple-play services such as Internet access, telephone, and television through BGP/MPLS IP-VPNs [RFC4364].
今日では、顧客は、BGP / MPLS IP-VPNの[RFC4364]を通じて、インターネットアクセス、電話、テレビなどのトリプルプレイサービスを実行するように期待しています。
As these services evolve, the requirements for an end-to-end QoS to meet the application requirements also continue to grow. Depending on the application (e.g., voice, video, bandwidth-guaranteed data pipe, etc.), a native IP using an RSVP and/or an end-to-end constrained MPLS Traffic Engineering (MPLS-TE) Label Switched Path (LSP) may be required. The RSVP path may be used to provide QoS guarantees and reserve an adequate bandwidth for the data. An end-to-end MPLS-TE LSP may also be used to guarantee a bandwidth, and provide extended functionality like MPLS fast reroute (FRR) [RFC4090] for maintaining the service continuity around node and link, including the CE-PE link, failures. It should be noted that an RSVP session between two CEs may also be mapped and tunneled into an MPLS-TE LSP across an MPLS provider network.
これらのサービスは進化するにつれて、アプリケーションの要件を満たすために、エンドツーエンドのQoSのための要件も成長を続けています。アプリケーション（例えば、音声、ビデオ、帯域保証型データパイプなど）、RSVPおよび/またはエンド・ツー・エンドの制約MPLSトラフィックエンジニアリング（MPLS-TE）ラベルスイッチパス（LSPを使用して、ネイティブIPに応じて、 ）必要とされ得ます。 RSVPの経路は、QoS保証を提供し、データのための十分な帯域幅を確保するために使用することができます。エンドツーエンドのMPLS-TE LSPはまた、CE-PEリンクを含む、帯域幅を保証し、ノードとリンクの周りにサービスの継続性を維持するためのMPLS高速リルート（FRR）のような拡張機能を[RFC4090]を提供するために使用され得ます、失敗。 2つのCE間のRSVPセッションもマッピングしMPLSプロバイダのネットワークを介してMPLS-TE LSPにトンネリングされてもよいことに留意すべきです。
A number of advantages exist for deploying the model previously mentioned. The first is that customers can use these network services while being able to use both private addresses and global addresses. The second advantage is that the traffic is tunneled through the service-provider backbone so that customer traffic and route confidentiality are maintained.
多くの利点は、前述のモデルを展開するために存在します。最初は、プライベートアドレスとグローバルアドレスの両方を使用することができながら、お客様がこれらのネットワークサービスを使用することができるということです。第2の利点は、顧客のトラフィックとルートの機密性が維持されるように、トラフィックはサービスプロバイダーのバックボーンを介してトンネリングされていることです。
This document defines a reference model, example application scenarios, and detailed requirements for a solution supporting a customer RSVP and RSVP-TE over a BGP/MPLS IP-VPN.
この文書は、参照モデル、例えば、アプリケーションのシナリオ、およびBGP / MPLS IP-VPN上の顧客RSVPおよびRSVP-TEをサポートするソリューションの詳細な要件を規定します。
A specification for a solution is out of scope in this document.
解決のための仕様では、この文書で範囲外です。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はあります[RFC2119]に記載されているように解釈されます。
This document uses the BGP/MPLS IP-VPN terminology defined in [RFC4364] and also uses Path Computation Element (PCE) terms defined in [RFC4655].
このドキュメントは[RFC4364]で定義されたBGP / MPLS IP-VPNの用語を使用しても、[RFC4655]で定義された経路計算エレメント（PCE）の用語を使用します。
TE LSP: Traffic Engineering Label Switched Path
TE LSP：トラフィックエンジニアリングラベルスイッチパス
MPLS-TE LSP: Multiprotocol Label Switching TE LSP
MPLS-TE LSP：マルチプロトコルラベルは、TE LSPを切り替えます
C-RSVP path: Customer RSVP path: a native RSVP path with the bandwidth reservation of X for customers
C-RSVPパス：カスタマーRSVPパス：顧客のためのXの帯域予約でネイティブRSVPパス
C-TE LSP: Customer Traffic Engineering Label Switched Path: an end-to-end MPLS-TE LSP for customers
C-TE LSP：顧客のためのエンドツーエンドのMPLS-TE LSP：カスタマートラフィックエンジニアリングラベルスイッチパス
P-TE LSP: Provider Traffic Engineering Label Switched Path: a transport TE LSP between two Provider Edges (PEs)
P-TE LSP：プロバイダトラフィックエンジニアリングラベルスイッチパス：2つのプロバイダエッジ間の輸送TE LSP（PES）
LSR: a Label Switched Router
LSR：ラベルは、ルータを交換しました
Head-end LSR: an ingress LSR
ヘッドエンドLSR：イングレスLSR
Tail-end LSR: an egress LSR
テールエンドLSR：出口LSR
Service providers want to deliver triple-play services with QoS guarantees to their customers. Various techniques are available to achieve this. Some service providers will wish to offer advanced services using an RSVP signaling for native IP flows (C-RSVP) or an RSVP-TE signaling for Customer TE LSPs (C-TE LSPs) over BGP/MPLS IP-VPNs.
サービスプロバイダは、顧客にQoS保証付きのトリプルプレイサービスをお届けしたいです。種々の技術は、これを達成するために利用可能です。いくつかのサービスプロバイダは、ネイティブIPフロー（C-RSVP）またはBGP / MPLS IP-VPNを超えるお客様TEのLSP（C-TEのLSP）のためのRSVP-TEシグナリングのためのシグナリングRSVPを使用して高度なサービスを提供したいでしょう。
The following examples outline each method:
次の例では、それぞれの方法の概要を説明します。
A C-RSVP path with the bandwidth reservation of X can be used to transport voice traffic. In order to achieve recovery in under 50 ms during link, node, and Shared Risk Link Group (SRLG) failures, and to provide strict QoS guarantees, a C-TE LSP with bandwidth X between data centers or customer sites can be used to carry voice and video traffic. Thus, service providers or customers can choose a C-RSVP path or a C-TE LSP to meet their requirements.
Xの帯域予約を有するC-RSVP経路音声トラフィックを転送するために使用することができます。リンク、ノード、および共有リスクリンクグループ（SRLG）障害時の50アンダーミリ秒の回復を達成するために、厳格なQoS保証を提供するためには、データセンターや顧客サイト間の帯域幅XとC-TE LSPを運ぶために使用することができます音声およびビデオトラフィック。このように、サービスプロバイダや顧客が自分の要件を満たすためにC-RSVPパスまたはC-TE LSPを選択することができます。
When service providers offer a C-RSVP path between hosts or CEs over BGP/MPLS IP-VPNs, the CE/host requests an end-to-end C-RSVP path with the bandwidth reservation of X to the remote CE/host. However, if a C-RSVP signaling is to send within a VPN, the service-provider network will face scalability issues because routers need to retain the RSVP state per a customer. Therefore, in order to solve scalability issues, multiple C-RSVP reservations can be aggregated at a PE, where a P-TE LSP head-end can perform admission control using the aggregated C-RSVP reservations. The method that is described in [RFC4804] can be considered as a useful approach. In this case, a reservation request from within the context of a Virtual Routing and Forwarding (VRF) instance can get aggregated onto a P-TE LSP. The P-TE LSP can be pre-established, resized based on the request, or triggered by the request. Service providers, however, cannot provide a C-RSVP path over the VRF instance as defined in [RFC4364]. The current BGP/MPLS IP-VPN architecture also does not support an RSVP instance running in the context of a VRF to process RSVP messages and integrated services (int-serv) ([RFC1633], [RFC2210]). One solution is described in [RSVP-L3VPN].
サービスプロバイダは、BGP / MPLS IP-VPNの上のホストまたはCEの間のC-RSVPの経路を提供するとき、CE /ホストは、リモートCE /ホストへのXの帯域予約とエンド・ツー・エンドのC-RSVPの経路を要求します。 C-RSVPシグナリングは、VPN内に送信する場合、ルータは、顧客ごとにRSVP状態を保持する必要があるためただし、サービスプロバイダーネットワークは、スケーラビリティの問題に直面するだろう。したがって、スケーラビリティの問題を解決するために、複数のC-RSVP予約は、P-TE LSPのヘッドエンドは凝集C-RSVP予約を用いて受付制御を行うことができるPE、に集約することができます。 [RFC4804]に記載されている方法は、有用なアプローチとみなすことができます。この場合、仮想ルーティング及び転送（VRF）インスタンスのコンテキスト内からの予約要求はP-TE LSPに集約得ることができます。 P-TE LSPは、事前に確立された要求に基づいて、サイズ変更、または要求によってトリガーすることができます。 [RFC4364]で定義されるように、サービスプロバイダは、しかし、VRFインスタンス上でC-RSVPの経路を提供することができません。現在のBGP / MPLS IP-VPNアーキテクチャはまた、RSVPメッセージ及びサービス統合（INT-SERV）（[RFC1633]、[RFC2210]）を処理するためのVRFのコンテキストで実行RSVPインスタンスをサポートしていません。一つの解決策は、[RSVP-L3VPN]に記載されています。
If service providers offer a C-TE LSP from a CE to a CE over the BGP/MPLS IP-VPN, they require that an MPLS-TE LSP from a local CE to a remote CE be established. However, if a C-TE LSP signaling is to send within the VPN, the service-provider network may face the following scalability issues:
サービスプロバイダーは、BGP / MPLS IP-VPN経由CEにCEからC-TE LSPを提供する場合は、リモートCEへのローカルCEからMPLS-TE LSPを確立する必要があります。 C-TE LSPシグナリングがVPN内で送信する場合は、サービスプロバイダーネットワークは、次のスケーラビリティの問題に直面する可能性があります。
- A C-TE LSP can be aggregated by a P-TE LSP at a PE (i.e., hierarchical LSPs). In this case, only a PE maintains the state of customer RSVP sessions.
- C-TE LSPは、PE（すなわち、階層のLSP）にP-TE LSPによって集約することができます。この場合、唯一のPEは、顧客RSVPセッションの状態を維持します。
- A C-TE LSP cannot be aggregated by a P-TE LSP at a PE, depending on some policies (i.e., continuous LSPs). In this case, both Ps and PEs maintain the state of customer RSVP sessions.
- C-TE LSPは、いくつかの方針（すなわち、連続のLSP）に応じて、PEにP-TE LSPによって集約することができません。この場合、PsとのPEの両方が顧客のRSVPセッションの状態を維持します。
- A C-TE LSP can be aggregated by the non-TE LSP (i.e., LDP). In this case, only a PE maintains the state of customer RSVP-TE sessions. Note that it is assumed that there is always enough bandwidth available in the service-provider core network.
- C-TE LSPは、非TE LSP（即ち、LDP）によって集約することができます。この場合、唯一のPEは、顧客RSVP-TEセッションの状態を維持します。サービスプロバイダーコアネットワークで利用可能な十分な帯域幅が常に存在することを想定していることに注意してください。
Furthermore, if service providers provide the C-TE LSP over the BGP/MPLS IP-VPN, they currently cannot provide it over the VRF instance as defined in [RFC4364]. Specifically, the current BGP/MPLS IP-VPN architecture does not support the RSVP-TE instance running in the context of a VRF to process RSVP messages and trigger the establishment of the C-TE LSP over the service-provider core network. If every C-TE LSP is to trigger the establishment or resizing of a P-TE LSP, the service-provider network will also face scalability issues that arise from maintaining a large number of P-TE LSPs and/or the dynamic signaling of these P-TE LSPs. Section 8.4 of this document, "Scalability Considerations", provides detailed scalability requirements.
[RFC4364]で定義されるようにさらに、サービスプロバイダは、BGP / MPLS IP-VPNオーバーC-TE LSPを提供する場合、それらは現在VRFインスタンスの上に提供することができません。具体的には、現在のBGP / MPLS IP-VPNアーキテクチャは、RSVPメッセージを処理し、サービスプロバイダーのコアネットワークを介してC-TE LSPの確立をトリガするVRFのコンテキストで実行RSVP-TEのインスタンスをサポートしていません。すべてのC-TE LSPは、P-TE LSPの確立またはサイズ変更をトリガする場合は、サービスプロバイダーネットワークはまた、P-TEのLSPの多数及び/又はこれらの動的シグナリングを維持するから生じるスケーラビリティの問題に直面するだろうP-TEのLSPを。このドキュメントのセクション8.4、「スケーラビリティに関する考慮事項」には、詳細なスケーラビリティ要件を提供します。
Two different models have been described above. The differences between C-RSVP paths and C-TE LSPs are as follows:
2つの異なるモデルは、上記に記載されています。次のようにC-RSVPパス及びC-TE用のLSPの違いは次のとおりです。
- C-RSVP path model: data packets among CEs are forwarded by "native IP packets" (i.e., not labeled packets).
- C-RSVPパスモデル：CEの間のデータパケットは、「ネイティブIPパケット」（すなわち、標識されていないパケット）で転送されます。
- C-TE LSP model: data packets among CEs are forwarded by "labeled IP packets".
- C-TE LSPモデル：CEの間のデータパケットは、「標識されたIPパケット」によって転送されます。
Depending on the service level and the need to meet specific requirements, service providers should be able to choose P-TE LSPs or non-TE LSPs in the backbone network. The selection may be dependent on the service provider's policy and the node's capability to support the mechanisms described.
サービスレベルおよび特定の要件を満たすために必要に応じて、サービスプロバイダーは、バックボーンネットワークにおけるP-TEのLSPを、非TE LSPを選択することができるはずです。選択は、サービスプロバイダのポリシーと説明されたメカニズムをサポートするノードの能力に依存してもよいです。
The items listed below are selectively required to support C-RSVP paths and C-TE LSPs over BGP/MPLS IP-VPNs based on the service level. For example, some service providers need all of the following items to provide a service, and some service providers need only some of them to provide the service. It depends on the service level and policy of service providers. Detailed requirements are described in Sections 6, 7, and 8.
下記の項目は、選択サービスレベルに基づいて、BGP / MPLS IP-VPNのオーバーC-RSVPパス及びC-TEのLSPをサポートするために必要とされます。例えば、いくつかのサービスプロバイダがサービスを提供するために、以下の項目のすべてを必要とし、いくつかのサービスプロバイダがサービスを提供するためにのみそれらのいくつかを必要とします。これは、サービス・レベルとサービス・プロバイダーのポリシーに依存します。詳細な要件は、セクション6,7、及び8に記載されています。
- C-RSVP path QoS guarantees.
- C-RSVPパスQoS保証。
- Fast recovery over the BGP/MPLS IP-VPN to protect traffic for the C-TE LSP against CE-PE link failure and PE node failure.
- CE-PEリンク障害およびPEノード障害に対してC-TE LSPのトラフィックを保護するために、BGP / MPLS IP-VPN経由の高速回復。
- Strict C-TE LSP bandwidth and QoS guarantees.
- 厳密なC-TE LSPの帯域幅とQoS保証。
- Resource optimization for C-RSVP paths and C-TE LSPs.
- C-RSVPパスとC-TEのLSPのリソースの最適化。
- Scalability for C-RSVP paths and C-TE LSPs.
- C-RSVPパス及びC-TE LSPのためのスケーラビリティ。
The following sections present a few application scenarios for C-RSVP paths and C-TE LSPs in BGP/MPLS IP-VPN environments. Appendix A, "Reference Model", describes a C-RSVP path, a C-TE LSP, and a P-TE LSP.
以下のセクションでは、BGP / MPLS IP-VPN環境でのC-RSVPパス及びC-TE LSPのためのいくつかのアプリケーションシナリオを提示します。付録Aは、 "参照モデル" は、C-RSVPの経路、C-TE LSP、およびP-TE LSPを記載しています。
In all scenarios, it is the responsibility of the service provider to ensure that enough bandwidth is available to meet the customers' application requirements.
すべてのシナリオでは、十分な帯域幅は、顧客のアプリケーション要件を満たすために利用可能であることを確認するために、サービス提供者の責任です。
In this scenario, as shown in Figure 1, a customer uses a VoIP application between its sites (i.e., between CE1 and CE2). H0 and H1 represent voice equipment.
図1に示すように、このシナリオでは、顧客は、その部位（すなわち、CE1とCE2の間）の間のVoIPアプリケーションを使用します。 H0とH1は、音声機器を表します。
In this case, the customer establishes C-TE LSP1 as a primary path and C-TE LSP2 as a backup path. If the link between PE1 and CE1 or the node of PE1 fails, C-TE LSP1 needs C-TE LSP2 as a path protection.
この場合、顧客は、バックアップパスとしてプライマリパスとしてC-TE LSP1及びC-TE LSP2を確立します。 PE1とCE1又はPE1のノード間のリンクに障害が発生した場合、C-TE LSP1は、パスプロテクションとしてC-TE LSP2を必要とします。
Generally speaking, C-RSVP paths are used by customers, and P-TE LSPs are used by service providers.
一般的に言えば、C-RSVPパスが顧客によって使用され、P-TEのLSPは、サービスプロバイダによって使用されています。
C-TE LSP1
<---------------------------------------------->
P-TE LSP1
<--------------------------->
............. .............
. --- --- . --- --- --- --- . --- --- .
.|H0 | |CE1|-----|PE1|----|P1 |-----|P2 |----|PE2|-----|CE2| |H1 |.
. --- --- . --- --- --- --- . --- --- .
.........|... --- --- --- --- ...|.........
+-------|PE3|----|P3 |-----|P4 |----|PE4|-------+
--- --- --- ---
<--------------------------->
P-TE LSP2
<---------------------------------------------->
C-TE LSP2
<--customer--> <--------BGP/MPLS IP-VPN-------> <--customer->
network network
Figure 1. Scenario I
図1.シナリオI
In this scenario, as shown in Figure 2, service provider B (SP B) transports voice and video traffic between its sites (i.e., between CE1 and CE2). In this case, service provider B establishes C-TE LSP1 with preemption priority 0 and 100-Mbps bandwidth for the voice traffic, and C-TE LSP2 with preemption priority 1 and 200-Mbps bandwidth for the unicast video traffic. On the other hand, service provider A (SP A) also pre-establishes P-TE LSP1 with preemption priority 0 and 1-Gbps bandwidth for the voice traffic, and P-TE LSP2 with preemption priority 1 and 2-Gbps bandwidth for the video traffic. In this scenario, P-TE LSP1 and P-TE LSP2 should support Diffserv-aware MPLS Traffic Engineering (DS-TE) [RFC4124].
図2に示すように、このシナリオでは、サービスプロバイダB（SP B）はその部位（すなわち、CE1とCE2間）間の音声およびビデオのトラフィックを搬送します。この場合、サービスプロバイダBは、ユニキャストビデオトラフィックのための先取り優先順位1と200 Mbpsの帯域幅を有する先取り優先順位0と音声トラフィックのために100 Mbpsの帯域幅、及びC-TE LSP2とC-TE LSP1を確立します。先取り優先順位1および2 Gbpsの帯域幅を有する音声トラフィックの先取り優先順位0と1 Gbpsの帯域幅、及びP-TE LSP2を有する一方、サービスプロバイダA（SP A）も予め確立P-TE LSP1ビデオトラフィック。このシナリオでは、P-TE LSP1とP-TE LSP2は、Diffservの対応のMPLSトラフィックエンジニアリング（DS-TE）[RFC4124]をサポートする必要があります。
PE1 and PE3 should choose an appropriate P-TE LSP based on the preemption priority. In this case, C-TE LSP1 must be associated with P-TE LSP1 at PE1, and C-TE LSP2 must be associated with P-TE LSP2 at PE3.
PE1及びPE3が先取り優先順位に基づいて、適切なP-TE LSPを選択しなければなりません。この場合、C-TE LSP1は、PE1におけるP-TE LSP1と関連付けられている必要があり、そしてC-TE LSP2は、PE3でP-TE LSP2に関連付けされなければなりません。
Furthermore, PE1 and PE3 head-ends should control the bandwidth of C-TE LSPs. In this case, PE1 and PE3 can choose C-TE LSPs by the amount of maximum available bandwidth for each P-TE LSP, respectively.
また、PE1及びPE3ヘッドエンドはC-TEのLSPの帯域幅を制御しなければなりません。この場合、PE1及びPE3は、それぞれ、各P-TE LSPのための最大使用可能な帯域幅の量によってC-TEのLSPを選択することができます。
C-TE LSP1
<---------------------------------------------->
P-TE LSP1
<--------------------------->
............. .............
. --- --- . --- --- --- --- . --- --- .
.|CE0| |CE1|-----|PE1|----|P1 |-----|P2 |----|PE2|-----|CE2| |CE3|.
. --- --- . --- --- --- --- . --- --- .
.........|... --- --- --- --- ...|.........
+-------|PE3|----|P3 |-----|P4 |----|PE4|-------+
--- --- --- ---
<--------------------------->
P-TE LSP2
<---------------------------------------------->
C-TE LSP2
<---SP B----> <--------BGP/MPLS IP-VPN-------> <---SP B--->
network SP A network network
Figure 2. Scenario II
図2.シナリオII
It's possible that the customer and the service provider have differing preemption priorities. In this case, the PE policy will override the customers. In the case where the service provider does not support preemption priorities, then such priorities should be ignored.
これは、顧客とサービスプロバイダーが異なる先取優先順位を持っている可能性があります。この場合、PEポリシーは、お客様が優先されます。サービスプロバイダは、プリエンプションの優先順位をサポートしていない場合には、そのような優先順位は無視されるべきです。
In this scenario, as shown in Figure 3, service provider C (SP C) uses voice and video traffic between its sites (i.e., between CE0 and CE5/CE7, between CE2 and CE5/CE7, between CE5 and CE0/CE2, and between CE7 and CE0/CE2). H0 and H1 represent voice and video equipment. In this case, service provider C establishes C-TE LSP1,
図3に示すように、このシナリオでは、サービス・プロバイダC（SP C）は、（すなわち、CE0およびCE5 / CE7間、CE2およびCE5 / CE7間、CE5及びCE0 / CE2の間の部位の間に音声およびビデオのトラフィックを使用してCE7及びCE0 / CE2間）。 H0とH1は、音声およびビデオ機器を表します。この場合、サービス・プロバイダCは、C-TE LSP1を確立します
C-TE LSP3, C-TE LSP5, and C-TE LSP7 with preemption priority 0 and 100-Mbps bandwidth for the voice traffic, and establishes C-TE LSP2, C-TE LSP4, C-TE LSP6, and C-TE LSP8 with preemption priority 1 and 200-Mbps bandwidth for the video traffic. On the other hand, service provider A also pre-establishes P-TE LSP1 and P-TE LSP3 with preemption priority 0 and 1-Gbps bandwidth for the voice traffic, and P-TE LSP2 and P-TE LSP4 with preemption priority 1 and 2-Gbps bandwidth for the video traffic. In this scenario, P-TE LSP1, P-TE LSP2, P-TE LSP3, and P-TE LSP4 should support DS-TE [RFC4124].
先取り優先順位0と音声トラフィックのために100 Mbpsの帯域幅を有するC-TE LSP3、C-TE LSP5、及びC-TE LSP7、及びC-TE LSP2、C-TE LSP4、C-TE LSP6、及びC-TEを確立しますビデオトラフィックのプリエンプションの優先度1と200 Mbpsの帯域幅を持つLSP8。一方、サービス提供者Aはまた、先取り優先順位1とでP-TE LSP1及びP-TE LSP3音声トラフィックのために先取り優先順位0と1 Gbpsの帯域幅、及びP-TE LSP2及びP-TE LSP4を予め確立しますビデオトラフィックの2 Gbpsの帯域幅。このシナリオでは、P-TE LSP1、P-TE LSP2、P-TE LSP3、及びP-TE LSP4はDS-TE [RFC4124]をサポートしなければなりません。
All PEs should choose an appropriate P-TE LSP based on the preemption priority. To minimize the traffic disruption due to a single network failure, diversely routed C-TE LSPs are established. In this case, the FRR [RFC4090] is not necessarily required.
すべてのPEは、先取優先順位に基づいて、適切なP-TE LSPを選択する必要があります。単一のネットワーク障害へのトラフィックの中断を最小限にするために、多様にルーティングされたC-TEのLSPが確立されています。この場合、FRR [RFC4090]は必ずしも必要ではありません。
Also, unconstrained TE LSPs (i.e., C-TE LSPs/P-TE LSPs with 0 bandwidth) [RFC5330] are applicable to this scenario.
また、非拘束TEのLSP（すなわち、C-TEのLSP / P-TEのLSPを0帯域幅を有する）[RFC5330]は、このシナリオに適用可能です。
Furthermore, the load balancing for any communication between H0 and H1 can be done by setting up full-mesh C-TE LSPs between CE0/CE2 and CE5/CE7.
さらに、H0及びH1の間の任意の通信のための負荷分散は、CE0 / CE2およびCE5 / CE7の間にフルメッシュC-TE LSPを設定することによって行うことができます。
C-TE LSP1(P=0),2(P=1) (CE0->CE1->...->CE4->CE5)
(CE0<-CE1<-...<-CE4<-CE5)
<---------------------------------------------->
C-TE LSP3(P=0),4(P=1) (CE2->CE1->...->CE4->CE7)
(CE2<-CE1<-...<-CE4<-CE7)
<---------------------------------------------->
P-TE LSP1 (p=0)
<-------------------->
P-TE LSP2 (p=1)
<-------------------->
.................. ..................
. --- --- . --- --- --- --- . --- --- .
. |CE0|-|CE1|--|PE1|--|P1 |---|P2 |--|PE2|--|CE4|-|CE5| .
. --- /--- --- . --- --- --- --- . --- ---\ --- .
.|H0 | + . + . + |H1 |.
. --- \--- --- . --- --- --- --- . --- ---/ --- .
. |CE2|-|CE3|--|PE3|--|P3 |---|P4 |--|PE4|--|CE6|-|CE7| .
. --- --- . --- --- --- --- . --- --- .
.................. ..................
<-------------------->
P-TE LSP3 (p=0)
<-------------------->
P-TE LSP4 (p=1)
<---------------------------------------------->
C-TE LSP5(P=0),6(P=1) (CE0->CE3->...->CE6->CE5)
(CE0<-CE3<-...<-CE6<-CE5)
<---------------------------------------------->
C-TE LSP7(P=0),8(P=1) (CE2->CE3->...->CE6->CE7)
(CE2<-CE3<-...<-CE6<-CE7)
<-----SP C-----> <----BGP/MPLS IP-VPN----> <-----SP C----->
network SP A network network
Figure 3. Scenario III
図3.シナリオIII
In this scenario, as shown in Figure 4, the customer has two hosts connecting to CE1 and CE2, respectively. CE1 and CE2 are connected to PE1 and PE2, respectively, within a VRF instance belonging to the same VPN. The requesting host (H1) may request from H2 an RSVP path with the bandwidth reservation of X. This reservation request from within the context of VRF will get aggregated onto a pre-established P-TE/DS-TE LSP based upon procedures similar to [RFC4804]. As in the case of [RFC4804], there may be multiple P-TE LSPs belonging to different DS-TE class-types. Local policies can be implemented to map the incoming RSVP path request from H1 to the P-TE LSP with the appropriate class-type. Please note that the end-to-end (e2e) RSVP path request may also be initiated by the CE devices themselves.
図4に示すように、このシナリオでは、顧客は、それぞれ、CE1及びCE2に接続する2つのホストを有します。 CE1とCE2は、同じVPNに属するVRFインスタンス内で、それぞれ、PE1とPE2に接続されています。要求しているホスト（H1）H2からXの帯域予約VRFのコンテキスト内からこの予約要求にRSVPの経路を要求してもよいがと同様の手順に基づいて、予め確立P-TE / DS-TE LSPに集約れます[RFC4804]。 [RFC4804]の場合のように、異なるDS-TEのクラスタイプに属する複数のP-TEとのLSPが存在してもよいです。ローカルポリシーは、適切なクラス型とP-TE LSPにH1からの着信RSVPの経路要求をマッピングするために実装することができます。エンド・ツー・エンド（E2E）RSVPパス要求はまた、CEデバイス自身によって開始されてもよいことに注意してください。
C-RSVP path
<----------------------------------------------------->
P-TE LSP
<--------------------------->
............. .............
. --- --- . --- --- --- --- . --- --- .
.|H1 | |CE1|---|PE1|----|P1 |-----|P2 |----|PE2|---|CE2| |H2 |.
. --- --- . --- --- --- --- . --- --- .
............. .............
^ ^
| |
VRF instance VRF instance
<-customer-> <--------BGP/MPLS IP-VPN-------> <-customer->
network network
Figure 4. Scenario IV
図4.シナリオIV
In this scenario, as shown in Figure 5, a customer has two hosts connecting to CE1 and CE2, respectively. CE1 and CE2 are connected to PE1 and PE2, respectively, within a VRF instance belonging to the same VPN. The requesting host (H1) may request from H2 an RSVP path with the bandwidth reservation of X. In this case, a non-TE LSP (i.e., LDP, etc.) is provided between PEs and has LDP, which supports MPLS Diffserv [RFC3270].
図5に示すように、このシナリオでは、顧客は、それぞれ、CE1及びCE2に接続する2つのホストを有します。 CE1とCE2は、同じVPNに属するVRFインスタンス内で、それぞれ、PE1とPE2に接続されています。 MPLSのDiffservをサポート要求しているホスト（H1）、H2から、この場合にはXの帯域予約とRSVPの経路を要求することができる、非TE LSP（すなわち、LDPなど）のPEとの間に設けられ、LDPを有しています、[ RFC3270]。
Note that this only provides Diffserv, and not the bandwidth reservation as is done with RSVP-TE.
RSVP-TEで行われているように、これが唯一の帯域予約をDiffservのを提供し、ないことに注意してください。
Local policies can be implemented to map the customer's reserved flow to the LSP with the appropriate Traffic Class [RFC5462] at PE1.
ローカルポリシーはPE1で適切なトラフィッククラス[RFC5462]とLSPへの顧客の予約された流れをマッピングするために実装することができます。
C-RSVP path
<------------------------------------------>
Non-TE LSP
<--------------------------->
............. .............
. --- --- . --- --- --- --- . --- --- .
.|H1 | |CE1|---|PE1|----|P1 |-----|P2 |----|PE2|---|CE2| |H2 |.
. --- --- . --- --- --- --- . --- --- .
............. .............
^ ^
| |
VRF instance VRF instance
<-customer-> <-------BGP/MPLS IP-VPN-------> <-customer->
network network
Figure 5. Scenario V
図5.シナリオV
In this scenario, as shown in Figure 6, a customer uses a VoIP application between its sites (i.e., between CE1 and CE2). H0 and H1 represent voice equipment. In this case, a non-TE LSP means LDP, and the customer establishes C-TE LSP1 as a primary path and C-TE LSP2 as a backup path. If the link between PE1 and CE1 or the node of PE1 fails, C-TE LSP1 needs C-TE LSP2 as a path protection.
図6に示すように、このシナリオでは、顧客は、その部位（すなわち、CE1とCE2の間）の間のVoIPアプリケーションを使用します。 H0とH1は、音声機器を表します。この場合、非TE LSPは、LDPを意味し、顧客は、バックアップパスとしてプライマリパスとしてC-TE LSP1及びC-TE LSP2を確立します。 PE1とCE1又はPE1のノード間のリンクに障害が発生した場合、C-TE LSP1は、パスプロテクションとしてC-TE LSP2を必要とします。
C-TE LSP1
<----------------------------------------->
Non-TE LSP
<-------------------------->
............. .............
. --- --- . --- --- --- --- . --- --- .
.|H0 | |CE1|---|PE1|----|P1 |-----|P2 |----|PE2|---|CE2| |H1 |.
. --- --- . --- --- --- --- . --- --- .
.........|... --- --- --- --- ...|.........
+-----|PE3|----|P3 |-----|P4 |----|PE4|-----+
--- --- --- ---
<-------------------------->
Non-TE LSP
<----------------------------------------->
C-TE LSP2
<-customer-> <------BGP/MPLS IP-VPN------> <-customer->
network network
Figure 6. Scenario VI
図6.シナリオVI
This section describes detailed requirements for C-TE LSPs in BGP/MPLS IP-VPN environments.
このセクションでは、BGP / MPLS IP-VPN環境でのC-TE LSPのための詳細な要件について説明します。
The solution MUST provide the ability to decide which P-TE LSPs a PE uses for a C-RSVP path and a C-TE LSP. When a PE receives a native RSVP and/or a path message from a CE, it MUST be able to decide which P-TE LSPs it uses. In this case, various kinds of P-TE LSPs exist in the service-provider network. For example, the PE MUST choose an appropriate P-TE LSP based on local policies such as:
溶液は、P-TE LSPをPEを決定する能力を提供しなければならないC-RSVPの経路及びC-TE LSPに使用します。 PEは、ネイティブRSVPおよび/またはCEからパスメッセージを受信すると、使用するP-TEのLSPを決定できなければなりません。この場合、P-TE LSPの各種サービスプロバイダーネットワーク内に存在します。例えば、PEのようなローカルポリシーに基づいて、適切なP-TE LSPを選択する必要があります。
1. preemption priority 2. affinity 3. class-type 4. on the data plane: (Differentiated Services Code Point (DSCP) or Traffic Class bits)
1.先取り優先順位2データプレーン上の親和性3級型4：（差別化サービスコードポイント（DSCP）またはトラフィッククラスビット）
The solution SHOULD support the graceful restart capability, where the C-TE LSP traffic continues to be forwarded during a PE graceful restart. Graceful restart mechanisms related to this architecture are described in [RFC3473], [RFC3623], and [RFC4781].
この溶液をC-TE LSPトラフィックはPEグレースフルリスタート中に転送され続けるグレースフルリスタート機能をサポートすべきです。このアーキテクチャに関するグレースフルリスタートメカニズムは、[RFC3473]、[RFC3623]及び[RFC4781]に記載されています。
The solution MUST provide the rerouting of a C-TE LSP in case of link, node, and SRLG failures, or in case of preemption. Such rerouting may be controlled by a CE or by a PE, depending on the failure. In a dual-homed environment, the ability to perform rerouting MUST be provided against a CE-PE link failure or a PE failure, if another CE-PE link or PE is available between the head-end and the tail-end of the C-TE LSP.
溶液は、リンク、ノード、及びSRLGの障害の場合、またはプリエンプションの場合にC-TE LSPの再ルーティングを提供しなければなりません。そのような再ルーティングは、障害に応じて、CEによって、またはPEによって制御することができます。デュアルホーム環境では、再ルーティングを実行する能力は、別のCE-PEリンクまたはPEは、ヘッドエンドとCのテール端部との間の利用可能な場合、CE-PEリンク障害またはPE障害に対して提供しなければなりません-TE LSP。
The solution MUST support FRR [RFC4090] features for a C-TE LSP over a VRF instance.
溶液はFRR [RFC4090]をサポートしなければならないVRFインスタンス上でC-TE LSPのための機能。
In BGP/MPLS IP-VPN environments, a C-TE LSP from a CE traverses multiple PEs and Ps, albeit tunneled over a P-TE LSP. In order to avoid PE-CE link/PE node/SRLG failures, a CE (a customer's head-end router) needs to support link protection or node protection.
BGP / MPLS IP-VPN環境では、CEからC-TE LSPは、P-TE LSP上トンネリングはいえ、複数のPEとPSを通過します。 PE-CEリンク/ PEノード/ SRLGの障害を避けるために、CE（カスタマのヘッドエンドルータ）は、リンク保護またはノードの保護をサポートする必要があります。
The following protection MUST be supported:
次の保護をサポートしなければなりません。
1. CE link protection 2. PE node protection 3. CE node protection
1. WHATリンク保護2. 3. WHATノードノード保護保護
The solution MUST support admission control on a P-TE LSP tunnel head-end for C-TE LSPs. C-TE LSPs may potentially try to reserve the bandwidth that exceeds the bandwidth of the P-TE LSP. The P-TE LSP tunnel head-end SHOULD control the number of C-TE LSPs and/or the bandwidth of C-TE LSPs. For example, the transport TE LSP head-end SHOULD have a configurable limit on the maximum number of C-TE LSPs that it can admit from a CE. As for the amount of bandwidth that can be reserved by C-TE LSPs, there could be two situations:
この溶液をC-TE LSPのためのP-TE LSPトンネルのヘッドエンドにアドミッション制御をサポートしなければなりません。 C-TE LSPは、潜在的にP-TE LSPの帯域幅を超える帯域幅を予約しようとすることができます。 P-TE LSPトンネルのヘッドエンドは、C-TEのLSPの数及び/又はC-TE LSPの帯域幅を制御すべきです。例えば、輸送TE LSPのヘッドエンドは、CEから認めることができるC-TE LSPの最大数に設定可能な限界を有しているべきです。 C-TE用のLSPによって確保することができる帯域幅の量については、二つの状況が存在し得ます。
1. Let the P-TE LSP do its natural bandwidth admission 2. Set a cap on the amount of bandwidth, and have the configuration option to:
1. P-TE LSPは、帯域幅の量に上限を設定してその自然帯域幅入場2.を行う、との設定オプションを持ってみましょう：
a. Reserve the minimum cap bandwidth or the C-TE LSP bandwidth on the P-TE LSP if the required bandwidth is available b. Reject the C-TE LSP if the required bandwidth by the C-TE LSP is not available
A。リザーブ最小キャップ帯域幅またはP-TE LSP上のC-TE LSP帯域幅要求される帯域幅が利用可能である場合、B。 C-TE LSPによって必要な帯域幅が利用できない場合C-TE LSPを拒否
6.6. Admission Control Support for C-TE LSPs in LDP-Based Core Networks
6.6. LDPベースのコアネットワークにおけるC-TE LSPのためのアドミッション制御のサポート
The solution MUST support admission control for a C-TE LSP at a PE in the LDP-based core network. Specifically, PEs MUST have a configurable limit on the maximum amount of bandwidth that can be reserved by C-TE LSPs for a given VRF instance (i.e., for a given customer). Also, a PE SHOULD have a configurable limit on the total amount of bandwidth that can be reserved by C-TE LSPs between PEs.
溶液は、LDPベースのコアネットワーク内のPEにC-TE LSPのためのアドミッション制御をサポートしなければなりません。具体的には、PEは（すなわち、所与の顧客のために）指定されたVRFインスタンスのC-TEのLSPによって確保できる帯域幅の最大量に設定可能な制限がなければなりません。また、PEは、PE間のC-TE用のLSPによって確保できる帯域幅の総量に設定可能な制限を有するべきです。
The solution MUST support the policy control for a C-TE LSP at a PE.
溶液をPEでC-TE LSPのためのポリシー制御をサポートしなければなりません。
The PE MUST be able to perform the following:
PEは、以下を実行することができなければなりません。
1. Limit the rate of RSVP messages per CE link. 2. Accept and map, or reject, requests for a given affinity. 3. Accept and map, or reject, requests with a specified setup and/or preemption priorities. 4. Accept or reject requests for fast reroutes. 5. Ignore the requested setup and/or preemption priorities, and select a P-TE LSP based on a local policy that applies to the CE-PE link or the VRF. 6. Ignore the requested affinity, and select a P-TE LSP based on a local policy that applies to the CE-PE link or the VRF. 7. Perform mapping in the data plane between customer Traffic Class bits and transport P-TE LSP Traffic Class bits, as signaled per [RFC3270].
1. CEリンクあたりのRSVPメッセージのレートを制限します。 2.特定の親和性の要求を受け入れ、マップ、または拒否します。 3.指定されたセットアップおよび/またはプリエンプションの優先順位を持つ要求を受け入れ、マップ、または拒否します。 4.受け入れるか、高速再ルーティングのための要求を拒否。 5.要求されたセットアップ及び/又は先取り優先順位を無視し、そしてCE-PEリンクまたはVRFに適用されるローカルポリシーに基づいてP-TE LSPを選択します。 6.要求された親和性を無視して、CE-PEリンクまたはVRFに適用されるローカルポリシーに基づいてP-TE LSPを選択します。 7. [RFC3270]あたりの合図として、顧客のトラフィッククラスビットとトランスポートP-TE LSPトラフィッククラスビット間のデータプレーンにマッピングを行います。
The solution SHOULD support the PCE architecture for a C-TE LSP establishment in the context of a VRF instance. When a C-TE LSP is provided, CEs, PEs, and Ps may support PCE features ([RFC4655], [RFC5440]).
溶液は、VRFインスタンスの文脈におけるC-TE LSPの確立のためのPCEアーキテクチャをサポートしなければなりません。 C-TE LSPが設けられている場合、CEは、のPE、およびPSは、PCE機能（[RFC4655]、[RFC5440]）をサポートすることができます。
In this case, CE routers or PE routers may be Path Computation Clients (PCCs), and PE routers and/or P routers may be PCEs. Furthermore, the solution SHOULD support a mechanism for dynamic PCE discovery. Specifically, all PCEs are not necessarily discovered automatically, and only specific PCEs that know VPN routes should be discovered automatically.
この場合、CEルータまたはPEルータは、パス計算クライアント（のPCC）、およびPEルータであってもよく、および/またはPルータはのPCEであってもよいです。さらに、溶液は、動的PCE発見のための機構をサポートしなければなりません。具体的には、すべてのPCEは必ずしも自動的に発見されていない、とVPNルートを知っているだけで、特定のPCEは自動的に検出されなければなりません。
The solution MUST provide for setting up diversely routed C-TE LSPs over the VRF instance. These diverse C-TE LSPs MAY be traversing over two different P-TE LSPs that are fully disjoint within a service-provider network. When a single CE has multiple uplinks that connect to different PEs, it is desirable that multiple C-TE LSPs over the VRF instance be established between a pair of LSRs. When two CEs have multiple uplinks that connect to different PEs, it is desirable that multiple C-TE LSPs over the VRF instance be established between two different pairs of LSRs. In these cases, for example, the following points will be beneficial to customers.
ソリューションは、VRFインスタンス上で多様にルーティングされたC-TEのLSPを設定するために提供しなければなりません。これらの多様なC-TE LSPは、サービスプロバイダーネットワーク内で完全に互いに素である二つの異なるP-TEのLSPをかけて通過されるかもしれません。単一のCEは、異なるPEに接続する複数のアップリンクを有する場合、VRFインスタンス上で複数のC-TE用のLSPがLSRの対の間で確立されることが望ましいです。 2つのCEが異なるPEに接続する複数のアップリンクを有する場合、VRFインスタンス上で複数のC-TE用のLSPがLSRの二つの異なる対の間に確立されることが望ましいです。これらのケースでは、例えば、以下の点には、お客様に有益となります。
1. load balance of the CE-to-CE traffic across diverse C-TE LSPs so as to minimize the traffic disruption in case of a single network element failure 2. path protection (e.g., 1:1, 1:N)
単一のネットワーク構成要素の故障2パスプロテクションの場合にトラフィックの中断を最小限に抑えるように、多様なC-TEのLSPを横切ってCE-に-CEトラフィックの1負荷バランス（例えば、1：1、1：N）
The solution MUST support the optimal path for a C-TE LSP over the VRF instance. Depending on an application (e.g., voice and video), an optimal path is needed for a C-TE LSP over the VRF instance. In the case of a TE LSP, an optimal route may be the shortest path based on the TE metric applied. For a non-TE LSP using LDP, the IGP metric may be used to compute optimal paths.
溶液は、VRFインスタンスオーバーC-TE LSPのための最適なパスをサポートしなければなりません。アプリケーション（例えば、音声およびビデオ）に応じて、最適な経路は、VRFインスタンス上でC-TE LSPのために必要とされます。 TE LSPの場合には、最適経路が適用TEメトリックに基づいて、最短経路であってもよいです。 LDPを使用して、非TE LSPのために、IGPメトリックは、最適な経路を計算するために使用することができます。
The solution MUST support the reoptimization of a C-TE LSP over the VRF instance. These LSPs MUST be reoptimized using "make-before-break" [RFC3209].
溶液は、VRFインスタンスオーバーC-TE LSPの再最適化をサポートしなければなりません。これらのLSPは、「メイクの前にブレイク」[RFC3209]を使用して再最適化されなければなりません。
In this case, it is desirable for a CE to be configured with regard to the timer-based or event-driven reoptimization. Furthermore, customers SHOULD be able to reoptimize a C-TE LSP manually. To provide for delay-sensitive or jitter-sensitive traffic (i.e., voice traffic), C-TE LSP path computation and route selection are expected to be optimal for the specific application.
この場合には、タイマーベースまたはイベント駆動型の再最適化を考慮して設定されるCEのために望ましいです。さらに、顧客が手動でC-TE LSPを再最適化することができるべきです。遅延に敏感やジッタに敏感なトラフィック（すなわち、音声トラフィック）を提供するために、C-TE LSPの経路計算及び経路選択は、特定のアプリケーションのために最適であることが期待されます。
The solution MUST support DS-TE [RFC4124] for a C-TE LSP over the VRF instance. In the event that the service provider and the customer have differing bandwidth constraint models, then only the service-provider bandwidth model should be supported.
溶液は、VRFインスタンス上でC-TE LSPのためにDS-TE [RFC4124]をサポートしなければなりません。サービスプロバイダと顧客が異なる帯域幅の制約モデルを持っている場合には、その後、唯一のサービスプロバイダーの帯域幅のモデルがサポートされる必要があります。
Applications, which have different traffic characteristics, are used in BGP/MPLS IP-VPN environments. Service providers try to achieve the fine-grained optimization of transmission resources, efficiency, and further-enhanced network performance. It may be desirable to perform TE at a per-class level.
異なるトラフィック特性を持っているアプリケーションは、BGP / MPLS IP-VPN環境で使用されています。サービスプロバイダは、きめ細かな送信リソースの最適化、効率化、さらに強化、ネットワークのパフォーマンスを達成してみてください。クラスごとのレベルでTEを実行することが望ましい場合があります。
By mapping the traffic from a given Diffserv class of service on a separate C-TE LSP, DS-TE allows this traffic to utilize resources available to the given class on both shortest paths and non-shortest paths, and also to follow paths that meet TE constraints that are specific to the given class.
別個C-TE LSP上のサービスの所与のDiffServクラスからのトラフィックをマッピングすることにより、DS-TEは、このトラフィックを満たす経路をたどることも最短経路と非最短経路の両方で指定されたクラスに利用可能な資源を利用し、することができ与えられたクラスに固有のTEの制約。
This section describes detailed requirements for C-RSVP paths in BGP/MPLS IP-VPN environments.
このセクションでは、BGP / MPLS IP-VPN環境でのC-RSVPパスの詳細な要件を記載しています。
The solution MUST support admission control at the ingress PE. PEs MUST control RSVP messages per a VRF instance.
溶液は、入口PEにアドミッション制御をサポートしなければなりません。 PEはVRFインスタンスごとにRSVPメッセージを制御する必要があります。
The solution SHOULD support C-RSVP paths aggregated by P-TE LSPs. P-TE LSPs SHOULD be pre-established manually or dynamically by operators and MAY be established if triggered by C-RSVP messages. Also, the P-TE LSP SHOULD support DS-TE.
溶液は、P-TE用のLSPによって集約C-RSVPパスをサポートしなければなりません。 P-TE LSPは、オペレータによって手動でまたは動的に事前に確立されるべきであり、C-RSVPメッセージによってトリガ場合に確立されてもよいです。また、P-TE LSPは、DS-TEをサポートする必要があります。
The solution SHOULD support non-TE LSPs (i.e., LDP-based LSP, etc.). Non-TE LSPs are established by LDP [RFC5036] between PEs and support MPLS Diffserv [RFC3270]. The solution MAY support local policies to map the customer's reserved flow to the LSP with the appropriate Traffic Class at the PE.
溶液は、非TEのLSP（即ち、LDPベースLSP、等）をサポートすべきです。非TE LSPはPEと支持MPLS Diffservの[RFC3270]の間でLDP [RFC5036]によって確立されます。ソリューションは、PEの適切なトラフィッククラスとLSPへの顧客の予約された流れをマッピングするためにローカルポリシーをサポートするかもしれません。
The solution SHOULD NOT change RSVP messages from the local CE to the remote CE (Path, Resv, Path Error, Resv Error, etc.). The solution SHOULD allow customers to receive RSVP messages transparently between CE sites.
ソリューションは、リモートCE（パス、のResv、パスのエラー、エラーのResv、など）にローカルCEからRSVPメッセージを変更しないでください。ソリューションは、顧客はCEサイト間で透過的にRSVPメッセージを受信できるようにする必要があります。
This section describes commonly detailed requirements for C-TE LSPs and C-RSVP paths in BGP/MPLS IP-VPN environments.
このセクションでは、BGP / MPLS IP-VPN環境でのC-TEのLSPをとC-RSVPの経路のために一般的に詳細な要件を記載しています。
The solution SHOULD support the following routing configuration on the CE-PE links with either RSVP or RSVP-TE on the CE-PE link:
溶液は、CE-PEリンク上RSVPまたはRSVP-TEのいずれかでのCE-PEリンク上の次のルーティング設定をサポートする必要があります。
1. static routing 2. BGP routing 3. OSPF 4. OSPF-TE (RSVP-TE case only)
1. 3. OSPF 4. OSPF-TEルーティング2. BGPルーティング静的（RSVP-TEの場合のみ）
The solution SHOULD avoid introducing unnecessary complexity to the current operating network to such a degree that it would affect the stability and diminish the benefits of deploying such a solution over SP networks.
解決策は、それが安定性に影響し、SPネットワーク上でこのようなソリューションを展開する利点を減少させるだろう程度に、現在のオペレーティング・ネットワークへの不必要な複雑さを導入することは避けてください。
The deployment of C-RSVP paths and C-TE LSPs SHOULD avoid impacting existing RSVP and MPLS-TE mechanisms, respectively, but should allow for a smooth migration or co-existence.
C-RSVPパス及びC-TE LSPの配置は、それぞれ、既存のRSVPとMPLS-TEメカニズムに影響を与える避けるべきであるが、スムーズな移行または共存を可能にすべきです。
The solution SHOULD minimize the impact on network scalability from a C-RSVP path and a C-TE LSP over the VRF instance. As identified in earlier sections, PCE provides a method for offloading computation of C-TE LSPs and helps with the solution scalability.
この溶液をC-RSVPの経路とVRFインスタンスオーバーC-TE LSPからネットワークのスケーラビリティへの影響を最小限に抑えるべきです。以前のセクションで特定されるように、PCEは、C-TEのLSPの計算をオフロードするための方法を提供し、溶液のスケーラビリティに役立ちます。
The solution MUST address the scalability of C-RSVP paths and C-TE LSPs for the following protocols.
溶液は、次のプロトコルのためにC-RSVPパス及びC-TEのLSPのスケーラビリティに対処しなければなりません。
1. RSVP (e.g., number of RSVP messages, retained state, etc.). 2. RSVP-TE (e.g., number of RSVP control messages, retained state, message size, etc.). 3. BGP (e.g., number of routes, flaps, overload events, etc.).
1. RSVP（例えば、RSVPメッセージ、保持状態、等の数）。 2. RSVP-TE（例えば、RSVP制御メッセージの数は、状態、メッセージサイズなどを保持しました）。 3. BGP（例えば、ルート、フラップ、過負荷イベント、等の数）。
The solution SHOULD be evaluated with regard to the following criteria.
解決策は、以下の基準に関して評価されるべきです。
1. Degree of path optimality of the C-TE LSP. 2. TE LSP setup time. 3. Failure and restoration time. 4. Impact and scalability of the control plane due to added overhead. 5. Impact and scalability of the data/forwarding plane due to added overhead.
C-TE LSPの経路の最適の1程度。 2. TE LSP設定時間。 3.障害と復旧時間。 4.影響起因追加オーバーヘッドに制御プレーンのスケーラビリティ。 5.影響起因追加オーバーヘッドにデータ/転送プレーンのスケーラビリティ。
The solution MUST address the manageability of C-RSVP paths and C-TE LSPs for the following considerations.
溶液は、以下の考慮事項C-RSVPパス及びC-TEのLSPの管理に対処しなければなりません。
1. Need for a MIB module for the control plane (including mapping of P-TE LSPs and C-TE LSPs) and bandwidth monitoring. 2. Need for diagnostic tools (this includes traceroute and Ping).
および帯域監視（P-TEのLSP及びC-TE LSPのマッピングを含む）は、制御プレーンのためのMIBモジュール1.必要があります。診断ツールのための2.の必要性（これはトレースルートとPingを含みます）。
The solution MUST allow routers to support the MIB module for C-RSVP paths and C-TE LSPs per a VRF instance. If a CE is managed by service providers, the solution MUST allow service providers to collect MIB information for C-RSVP paths and C-TE LSPs from the CE per a customer.
溶液は、ルータがVRFインスタンスごとにC-RSVPパス及びC-TEのLSPのためのMIBモジュールをサポートすることを可能にしなければなりません。 CEは、サービスプロバイダによって管理されている場合、ソリューションは、サービスプロバイダーは顧客ごとCEからC-RSVPパスとC-TEのLSPのためのMIB情報を収集するために許容しなければなりません。
Diagnostic tools can detect failures of the control plane and data plane for general MPLS-TE LSPs [RFC4379]. The solution MUST allow routers to be able to detect failures of the control plane and the data plane for C-TE LSPs over a VRF instance.
診断ツールは、一般的なMPLS-TEのLSP [RFC4379]のための制御プレーンとデータプレーンの障害を検出することができます。溶液は、ルータがVRFインスタンスを介して制御プレーンとC-TEのLSPのためのデータプレーンの障害を検出できるようにすることができなければなりません。
MPLS Operations, Administration, and Maintenance (OAM) for C-TE LSPs MUST be supported within the context of VRF, except for the above.
MPLS操作は、C-TEのLSPの管理、および保守（OAM）は、上記を除いて、VRFのコンテキスト内でサポートしなければなりません。
Any solution should consider the following general security requirements:
すべてのソリューションは、以下の一般的なセキュリティ要件を考慮する必要があります。
1. The solution SHOULD NOT divulge the service-provider topology information to the customer network. 2. The solution SHOULD minimize the service-provider network's vulnerability to Denial of Service (DoS) attacks. 3. The solution SHOULD minimize the misconfiguration of DSCP marking, preemption, and holding priorities of the customer traffic.
1.ソリューションは、顧客のネットワークにサービスプロバイダーのトポロジー情報を漏らすべきではありません。 2.ソリューションは、サービス拒否（DoS）攻撃へのサービスプロバイダーネットワークの脆弱性を最小限に抑える必要があります。 3.ソリューションは、マーキングプリエンプション、および顧客のトラフィックの優先順位を保持するDSCPの設定ミスを最小限に抑える必要があります。
The following additional security issues for C-TE LSPs relate to both the control plane and the data plane.
C-TE LSPのための以下の追加のセキュリティ問題は、コントロールプレーンとデータプレーンの両方に関係します。
In terms of the control plane, in both the C-RSVP path and C-TE LSP models, a PE receives IPv4 or IPv6 RSVP control packets from a CE. If the CE is a router that is not trusted by service providers, the PE MUST be able to limit the rate and number of IPv4 or IPv6 RSVP control packets.
制御プレーンの観点から、C-RSVPの経路及びC-TE LSPモデルの両方において、PEがCEからIPv4またはIPv6 RSVP制御パケットを受信します。 CEは、サービスプロバイダによって信頼されていないルータである場合、PEは、IPv4またはIPv6 RSVP制御パケットの速度と数を制限することができなければなりません。
In terms of the data plane, in the C-TE LSP model, a PE receives labeled IPv4 or IPv6 data packets from a CE. If the CE is a router that is not trusted by service providers, the PE MUST be able to limit the rate of labeled IPv4 or IPv6 data packets. If the CE is a trusted router for service providers, the PE MAY be able to limit the rate of labeled IPv4 or IPv6 data packets. Specifically, the PE must drop MPLS-labeled packets if the MPLS label was not assigned over the PE-CE link on which the packet was received. The PE must also be able to police traffic to the traffic profile associated with the LSP on which traffic is received on the PE-CE link.
データプレーンの観点から、C-TE LSPモデルでは、PEは、CEからの標識されたIPv4またはIPv6データパケットを受信します。 CEは、サービスプロバイダによって信頼されていないルータである場合、PEはラベルされたIPv4またはIPv6データパケットのレートを制限することができなければなりません。 CEは、サービスプロバイダのための信頼できるルータがある場合は、PEは、標識されたIPv4またはIPv6データパケットのレートを制限することができるかもしれません。 MPLSラベルがパケットを受信したPE-CEリンク上で割り当てられていなかった場合、具体的に、PEは、MPLS標識したパケットを廃棄しなければなりません。 PEはまた、トラフィックはPE-CEリンク上で受信されたLSPに関連するトラフィックプロファイルにトラフィックをポリシングすることができなければなりません。
Moreover, flooding RSVP/RSVP-TE control packets from malicious customers must be avoided. Therefore, a PE MUST isolate the impact of such customers' RSVP/RSVP-TE packets from other customers.
また、悪質な顧客からの洪水のRSVP / RSVP-TE制御パケットは避けなければなりません。したがって、PEは、他の顧客から、このような顧客のRSVP / RSVP-TEパケットの影響を分離しなければなりません。
In the event that C-TE LSPs are diversely routed over VRF instances, the VRF should indicate to the CE how such diversity was provided.
C-TEのLSPのは、多様VRFインスタンスを介してルーティングされた場合には、VRFは、このような多様性が提供された方法をCEに示すべきです。
[RFC1633] Braden, R., Clark, D., and S. Shenker, "Integrated Services in the Internet Architecture: an Overview", RFC 1633, June 1994.
[RFC1633]ブレーデン、R.、クラーク、D.、およびS. Shenker、 "インターネットアーキテクチャにおける統合サービス：概要"、RFC 1633、1994年6月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。
[RFC2210] Wroclawski, J., "The Use of RSVP with IETF Integrated Services", RFC 2210, September 1997.
[RFC2210] Wroclawski、J.、RFC 2210、1997年9月 "IETF統合サービスとRSVPの使用"。
[RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP Tunnels", RFC 3209, December 2001.
[RFC3209] Awduche、D.、バーガー、L.、ガン、D.、李、T.、スリニヴァサン、V.、およびG.ツバメ、 "RSVP-TE：LSPトンネルのためのRSVPの拡張"、RFC 3209年12月2001。
[RFC3270] Le Faucheur, F., Wu, L., Davie, B., Davari, S., Vaananen, P., Krishnan, R., Cheval, P., and J. Heinanen, "Multi-Protocol Label Switching (MPLS) Support of Differentiated Services", RFC 3270, May 2002.
[RFC3270]ルFaucheur、F.、ウー、L.、デイビー、B.、Davari、S.、Vaananen、P.、クリシュナン、R.、シュヴァル、P.、およびJ. Heinanen、「マルチプロトコルラベルスイッチング（MPLS）差別化サービスのサポート」、RFC 3270、2002年5月。
[RFC3473] Berger, L., Ed., "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Extensions", RFC 3473, January 2003.
[RFC3473]バーガー、L.、エド。、 "一般化されたマルチプロトコルラベルスイッチング（GMPLS）シグナリング資源予約プロトコル - トラフィックエンジニアリング（RSVP-TE）を拡張"、RFC 3473、2003年1月。
[RFC3623] Moy, J., Pillay-Esnault, P., and A. Lindem, "Graceful OSPF Restart", RFC 3623, November 2003.
[RFC3623]モイ、J.、Pillay-Esnault、P.、およびA. Lindem、 "優雅なOSPF再起動"、RFC 3623、2003年11月。
[RFC4090] Pan, P., Ed., Swallow, G., Ed., and A. Atlas, Ed., "Fast Reroute Extensions to RSVP-TE for LSP Tunnels", RFC 4090, May 2005.
[RFC4090]パン、P.、エド。、ツバメ、G.、エド。、およびA.アトラス編、 "高速リルート機能拡張LSPトンネルのための-TEをRSVPする"、RFC 4090、2005年5月。
[RFC4124] Le Faucheur, F., Ed., "Protocol Extensions for Support of Diffserv-aware MPLS Traffic Engineering", RFC 4124, June 2005.
[RFC4124]ルFaucheur、F.、エド。、 "Diffservの認識MPLSトラフィックエンジニアリングのサポートのためのプロトコル拡張機能"、RFC 4124、2005年6月。
[RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private Networks (VPNs)", RFC 4364, February 2006.
[RFC4364]ローゼン、E.およびY. Rekhter、 "BGP / MPLS IP仮想プライベートネットワーク（VPN）"、RFC 4364、2006年2月。
[RFC4379] Kompella, K. and G. Swallow, "Detecting Multi-Protocol Label Switched (MPLS) Data Plane Failures", RFC 4379, February 2006.
[RFC4379] Kompella、K.とG.ツバメ、2006年2月、RFC 4379 "を検出マルチプロトコルラベルは（MPLS）データプレーン障害をスイッチ"。
[RFC4655] Farrel, A., Vasseur, J.-P., and J. Ash, "A Path Computation Element (PCE)-Based Architecture", RFC 4655, August 2006.
[RFC4655]ファレル、A.、Vasseur、J.-P.、およびJ.アッシュ、 "パス計算要素（PCE）ベースのアーキテクチャ"、RFC 4655、2006年8月。
[RFC4781] Rekhter, Y. and R. Aggarwal, "Graceful Restart Mechanism for BGP with MPLS", RFC 4781, January 2007.
[RFC4781] Rekhter、Y.、およびR.アガルワル、 "MPLSとBGPのためのグレースフルリスタートメカニズム"、RFC 4781、2007年1月。
[RFC5036] Andersson, L., Ed., Minei, I., Ed., and B. Thomas, Ed., "LDP Specification", RFC 5036, October 2007.
[RFC5036]アンデション、L.、エド。、Minei、I.、エド。、およびB.トーマス、エド。、 "LDP仕様"、RFC 5036、2007年10月。
[RFC5462] Andersson, L. and R. Asati, "Multiprotocol Label Switching (MPLS) Label Stack Entry: "EXP" Field Renamed to "Traffic Class" Field", RFC 5462, February 2009.
[RFC5462]アンデション、L.およびR. Asatiは、 "マルチプロトコルラベルスイッチング（MPLS）ラベルスタックエントリ： "EXPトラフィッククラス "フィールド"、RFC 5462、2009年2月" フィールドに改名します"。
[RSVP-L3VPN] Davie, B., Le Faucheur, F., and A. Narayanan, "Support for RSVP in Layer 3 VPNs", Work in Progress, November 2009.
[RSVP-L3VPN]デイビー、B.、ルFaucheur、F.、およびA.ナラヤナン、 "レイヤ3でのRSVPのサポートVPN" を、進歩、2009年11月の作業。
[RFC4804] Le Faucheur, F., Ed., "Aggregation of Resource ReSerVation Protocol (RSVP) Reservations over MPLS TE/DS-TE Tunnels", RFC 4804, February 2007.
[RFC4804]ルFaucheur、F.、エド。、 "集計資源の予約プロトコル（RSVP）MPLS TE / DS-TEトンネル経由予約"、RFC 4804、2007年2月。
[RFC5330] Vasseur, JP., Ed., Meyer, M., Kumaki, K., and A. Bonda, "A Link-Type sub-TLV to Convey the Number of Traffic Engineering Label Switched Paths Signalled with Zero Reserved Bandwidth across a Link", RFC 5330, October 2008.
[RFC5330] Vasseur、JP。、編、マイヤー、M.、熊木、K.、およびA. Bonda、「リンクタイプのサブTLVが横切るゼロ予約された帯域幅と合図トラフィックエンジニアリングラベルスイッチパスの数を伝えるためリンク」、RFC 5330、2008年10月。
[RFC5440] Vasseur, JP., Ed., and JL. Le Roux, Ed., "Path Computation Element (PCE) Communication Protocol (PCEP)", RFC 5440, March 2009.
[RFC5440] Vasseur、JP。、編、およびJL。ル・ルー、エド。、 "パス計算要素（PCE）通信プロトコル（PCEP）"、RFC 5440、2009年3月。
The authors would like to express thanks to Nabil Bitar, David McDysan, and Daniel King for their helpful and useful comments and feedback.
作者は彼らの役に立つと有益なコメントやフィードバックのためのナビル・ビタール、デビッドMcDysan、そしてダニエル王に感謝の意を表したいと思います。
Appendix A. Reference Model
付録A.リファレンスモデル
In this appendix, a C-RSVP path, a C-TE LSP, and a P-TE LSP are explained.
この付録では、C-RSVPの経路、C-TE LSP、およびP-TE LSPについて説明します。
All scenarios in this appendix assume the following:
この付録のすべてのシナリオは、次のことを前提としています。
- A P-TE LSP is established between PE1 and PE2. This LSP is used by the VRF instance to forward customer packets within a BGP/MPLS IP-VPN.
- P-TE LSPは、PE1とPE2の間で確立されます。このLSPは、BGP / MPLS IP-VPN内の顧客のパケットを転送するためにVRFインスタンスによって使用されています。
- The service provider has ensured that enough bandwidth is available to meet the service requirements.
- サービスプロバイダは、十分な帯域幅がサービス要件を満たすために利用可能であることを確実にしました。
A.1. End-to-End C-RSVP Path Model
A.1。エンドツーエンドのC-RSVPパスモデル
A C-RSVP path and a P-TE LSP are shown in Figure 7, in the context of a BGP/MPLS IP-VPN. A P-TE LSP may be a non-TE LSP (i.e., LDP) in some cases. In the case of a non-TE mechanism, however, it may be difficult to guarantee an end-to-end bandwidth, as resources are shared.
C-RSVPパスとP-TE LSPは、BGP / MPLS IP-VPNとの関連で、図7に示されています。 P-TE LSPは、いくつかのケースでは、非TE LSP（即ち、LDP）であってもよいです。非TE機構の場合には、しかし、リソースが共有されるように、エンド・ツー・エンドの帯域幅を保証することは困難です。
CE0/CE1 requests an e2e C-RSVP path to CE3/CE2 with the bandwidth reservation of X. At PE1, this reservation request received in the context of a VRF will get aggregated onto a pre-established P-TE LSP, or trigger the establishment of a new P-TE LSP. It should be noted that C-RSVP sessions across different BGP/MPLS IP-VPNs can be aggregated onto the same P-TE LSP between the same PE pair, achieving further scalability. [RFC4804] defines this scenario in more detail.
CE0 / CE1はPE1でXの帯域予約とCE3 / CE2にE2E C-RSVPの経路を要求し、この予約要求は、VRFのコンテキストで受信予め確立P-TE LSPに集約れます、またはトリガ新しいP-TE LSPの確立。異なるBGP / MPLS IP-VPNの両端のC-RSVPセッションはさらにスケーラビリティを達成する、同じPEの対の間に同一のP-TE LSPに集約することができることに留意すべきです。 [RFC4804]は、より詳細には、このシナリオを定義します。
The RSVP control messages (e.g., an RSVP PATH message and an RSVP RESV message) exchanged among CEs are forwarded by IP packets through the BGP/MPLS IP-VPN. After CE0 and/or CE1 receive a reservation message from CE2 and/or CE3, CE0/CE1 establishes a C-RSVP path through the BGP/MPLS IP-VPN.
RSVP制御メッセージ（例えば、RSVP PATHメッセージ及びRSVP RESVメッセージ）は、BGP / MPLS IP-VPNを介してIPパケットによって転送されたCEの間で交換しました。 CE0および/またはCE1は、CE2及び/又はCE3から予約メッセージを受信した後、CE0 / CE1は、BGP / MPLS IP-VPNを介してC-RSVPの経路を確立します。
C-RSVP path
<------------------------------------------>
P-TE LSP
<--------------------------->
............. .............
. --- --- . --- --- --- --- . --- --- .
.|CE0| |CE1|---|PE1|----|P1 |-----|P2 |----|PE2|---|CE2| |CE3|.
. --- --- . --- --- --- --- . --- --- .
............. .............
^ ^
| |
VRF instance VRF instance
<-customer-> <------BGP/MPLS IP-VPN------> <-customer->
network network
or or
another another
service-provider service-provider
network network
Figure 7. e2e C-RSVP Path Model
図7. E2E C-RSVPパスモデル
A.2. End-to-End C-TE LSP Model
A.2。エンドツーエンドC-TE LSPモデル
A C-TE LSP and a P-TE LSP are shown in Figure 8, in the context of a BGP/MPLS IP-VPN. A P-TE LSP may be a non-TE LSP (i.e., LDP) in some cases. As described in the previous sub-section, it may be difficult to guarantee an end-to-end QoS in some cases.
C-TE LSPとP-TE LSPは、BGP / MPLS IP-VPNとの関連で、図8に示されています。 P-TE LSPは、いくつかのケースでは、非TE LSP（即ち、LDP）であってもよいです。前のサブセクションで説明したように、いくつかのケースでは、エンドツーエンドのQoSを保証することは困難です。
CE0/CE1 requests an e2e TE LSP path to CE3/CE2 with the bandwidth reservation of X. At PE1, this reservation request received in the context of a VRF will get aggregated onto a pre-established P-TE LSP, or trigger the establishment of a new P-TE LSP. It should be noted that C-TE LSPs across different BGP/MPLS IP-VPNs can be aggregated onto the same P-TE LSP between the same PE pair, achieving further scalability.
CE0 / CE1はPE1でXの帯域予約とCE3 / CE2にE2E TE LSPパスを要求する、VRFのコンテキストで受信し、この予約要求は、事前に確立されたP-TE LSPに凝集、又は確立をトリガしてしまいます新しいP-TE LSPの。異なるBGP / MPLS IP-VPNの両端のC-TE用のLSPは、さらにスケーラビリティを達成する、同じPEの対の間に同一のP-TE LSPに集約することができることに留意すべきです。
The RSVP-TE control messages (e.g., an RSVP PATH message and an RSVP RESV message) exchanged among CEs are forwarded by a labeled packet through the BGP/MPLS IP-VPN. After CE0 and/or CE1 receive a reservation message from CE2 and/or CE3, CE0/CE1 establishes a C-TE LSP through the BGP/MPLS IP-VPN.
RSVP-TE制御メッセージ（例えば、RSVP PATHメッセージ及びRSVP RESVメッセージ）は、BGP / MPLS IP-VPNを介して標識されたパケットによって転送されたCEの間で交換しました。 CE0および/またはCE1は、CE2及び/又はCE3から予約メッセージを受信した後、CE0 / CE1は、BGP / MPLS IP-VPNを介してC-TE LSPを確立します。
A P-TE LSP is established between PE1 and PE2. This LSP is used by the VRF instance to forward customer packets within the BGP/MPLS IP-VPN.
P-TE LSPは、PE1とPE2の間で確立されます。このLSPは、BGP / MPLS IP-VPN内の顧客のパケットを転送するためにVRFインスタンスによって使用されています。
C-TE LSP
<------------------------------------------------------->
or
または
C-TE LSP
<----------------------------------------->
P-TE LSP
<--------------------------->
............. .............
. --- --- . --- --- --- --- . --- --- .
.|CE0| |CE1|---|PE1|----|P1 |-----|P2 |----|PE2|---|CE2| |CE3|.
. --- --- . --- --- --- --- . --- --- .
............. .............
^ ^
| |
VRF instance VRF instance
<-customer-> <-------BGP/MPLS IP-VPN-------> <-customer->
network network
or or
another another
service-provider service-provider
network network
Figure 8. e2e C-TE LSP Model
図8のC-E2E LSP TEモデル
Authors' Addresses
著者のアドレス
Kenji Kumaki (Editor) KDDI Corporation Garden Air Tower Iidabashi, Chiyoda-ku Tokyo 102-8460, JAPAN EMail: ke-kumaki@kddi.com
けんじ くまき （えぢとｒ） Ｋっぢ こｒぽらちおん がｒでん あいｒ とうぇｒ いいだばし、 ちよだーく ときょ １０２ー８４６０、 じゃぱん えまいｌ： けーくまき＠ｋっぢ。こｍ
Raymond Zhang BT Farady Building, PP1.21 1 Knightrider Street London EC4V 5BT UK EMail: raymond.zhang@bt.com
レイモンド・チャンBTファラデービル、PP1.21 1ナイトライダーストリートロンドンEC4V 5BT英国Eメール：raymond.zhang@bt.com
Yuji Kamite NTT Communications Corporation Granpark Tower 3-4-1 Shibaura, Minato-ku Tokyo 108-8118 Japan EMail: y.kamite@ntt.com
ゆじ かみて んっｔ こっむにかちおんｓ こｒぽらちおん Ｇらんぱｒｋ とうぇｒ ３ー４ー１ しばうら、 みなとーく ときょ １０８ー８１１８ じゃぱん えまいｌ： ｙ。かみて＠んっｔ。こｍ