[要約] RFC 5824は、BGP/MPLS IP-VPN上でCustomer Resource Reservation Protocol (RSVP)とRSVP Traffic Engineering (RSVP-TE)をサポートするための要件を定義しています。このRFCの目的は、BGP/MPLS IP-VPN環境でのRSVPとRSVP-TEの効果的な運用を可能にするためのガイドラインを提供することです。
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
BGP/MPLS IP-VPNを介した顧客リソース予約プロトコル（RSVP）およびRSVPトラフィックエンジニアリング（RSVP-TE）をサポートするための要件
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によって承認されたすべてのドキュメントが、あらゆるレベルのインターネット標準の候補者ではありません。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.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、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.
Copyright（c）2010 IETF Trustおよび文書著者として特定された人。全著作権所有。
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 Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション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.
このドキュメントには、2008年11月10日までに公開または公開されたIETFドキュメントまたはIETFの寄付からの資料が含まれている場合があります。IETF標準プロセスの外。そのような資料の著作権を制御する人から適切なライセンスを取得せずに、このドキュメントはIETF標準プロセスの外側に変更されない場合があり、その派生作業は、ITF標準プロセスの外側で作成されない場合があります。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.
一部のサービスプロバイダーは、ネットワークを介して地元の顧客エッジ（CE）からリモートCEまでのサービス品質（QOS）と帯域幅を保証するサービスを構築したいと考えています。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-VPNS [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）ラベルスイッチドパスを使用したネイティブIP（LSP））必要になる場合があります。RSVPパスは、QoS保証を提供し、データに適切な帯域幅を予約するために使用できます。エンドツーエンドのMPLS-TE LSPを使用して帯域幅を保証し、MPLS Fast Reroute（FRR）[RFC4090]のような拡張機能を提供して、CE-PEリンクを含むノードとリンクの周りのサービスの連続性を維持するために提供することもできます。失敗。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.
前述のモデルを展開するための多くの利点があります。1つ目は、顧客がこれらのネットワークサービスを使用しながら、プライベートアドレスとグローバルアドレスの両方を使用できることです。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].
「必須」、「そうしない」、「必須」、「必要」、「しない」、「そうしない」、「そうではない」、「そうでない」、「推奨」、「5月」、および「オプション」は、[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つのプロバイダーエッジ（PES）間の輸送TE LSP
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保証を顧客に保証するトリプルプレイサービスを提供したいと考えています。これを達成するために、さまざまな手法が利用できます。一部のサービスプロバイダーは、BGP/MPLS IP-VPNSを介して、ネイティブIPフロー（C-RSVP）のRSVPシグナリングまたは顧客TE LSP（C-TE LSP）のRSVP-TEシグナリングを使用して、高度なサービスを提供したいと考えています。
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-VPNSを介してホストまたはCES間のC-RSVPパスを提供する場合、CE/ホストは、Xの帯域幅をリモートCE/ホストに予約してエンドツーエンドのC-RSVPパスを要求します。ただし、C-RSVPシグナリングがVPN内で送信する場合、ルーターは顧客ごとにRSVP状態を保持する必要があるため、サービスプロバイダーネットワークはスケーラビリティの問題に直面します。したがって、スケーラビリティの問題を解決するために、PEで複数のC-RSVP予約を集約できます。PEでは、P-TE LSPヘッドエンドが集約されたC-RSVP予約を使用して入場制御を実行できます。[RFC4804]で説明されている方法は、有用なアプローチと見なすことができます。この場合、仮想ルーティングと転送（VRF）インスタンスのコンテキスト内からの予約要求は、P-TE LSPに集約されます。P-TE LSPは、事前に確立されたり、リクエストに基づいてサイズ変更されたり、リクエストによってトリガーされたりできます。ただし、[RFC4364]で定義されているように、サービスプロバイダーはVRFインスタンスでC-RSVPパスを提供することはできません。現在のBGP/MPLS IP-VPNアーキテクチャは、RSVPメッセージと統合サービス（INT-SERV）を処理するためにVRFのコンテキストで実行されているRSVPインスタンスもサポートしていません（[RFC1633]、[RFC2210]）。[RSVP-L3VPN]で1つのソリューションが説明されています。
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は、非TET LSP（つまり、LDP）によって集約できます。この場合、PEのみが顧客RSVP-TEセッションの状態を維持しています。Service-Provider Core Networkには常に十分な帯域幅があると想定されていることに注意してください。
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.
さらに、サービスプロバイダーがBGP/MPLS IP-VPNよりもC-TE LSPを提供する場合、[RFC4364]で定義されているように、VRFインスタンスでそれを提供できません。具体的には、現在のBGP/MPLS IP-VPNアーキテクチャは、VRFのコンテキストで実行されているRSVP-TEインスタンスをサポートして、RSVPメッセージを処理し、サービスプロバイダーコアネットワーク上のC-TE LSPの確立をトリガーします。すべての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パスモデル：CES間のデータパケットは、「ネイティブIPパケット」（つまり、ラベル付きパケットではない）によって転送されます。
- C-TE LSP model: data packets among CEs are forwarded by "labeled IP packets".
- C-TE LSPモデル：CES間のデータパケットは、「ラベル付き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または非TELSPを選択できる必要があります。選択は、サービスプロバイダーのポリシーと、説明されているメカニズムをサポートするノードの機能に依存する場合があります。
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-VPNSを介した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.
- BGP/MPLS IP-VPNを介した高速回復CE-PEリンク障害およびPEノード障害に対するC-TE LSPのトラフィックを保護します。
- 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に示すように、顧客はサイト間のVOIPアプリケーションを使用しています（つまり、CE1とCE2の間）。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は、音声トラフィックの先制優先度0および100-Mbps帯域幅を備えたC-TE LSP1、およびユニキャストビデオトラフィックのプリエンプション優先度1および200 Mbps帯域幅を持つC-TE LSP2を確立します。一方、サービスプロバイダーA（SP A）は、音声トラフィックの先行優先度0および1-gbps帯域幅を持つP-TE LSP1、およびプリエンプション優先度1および2 gbpsの帯域幅を持つP-TE LSP2を事前に確立します。ビデオトラフィック。このシナリオでは、P-TE LSP1およびP-TE LSP2は、DiffServ-Aware 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, 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].
このシナリオでは、図3に示すように、サービスプロバイダーC（SP C）は、サイト間の音声トラフィックとビデオトラフィックを使用します（つまり、CE0とCE5/CE7の間、CE2とCE5/CE7の間、CE5とCE0/CE2の間、およびCE0/CE2の間、およびCE7とCE0/CE2の間）。H0とH1は音声機器とビデオ機器を表します。この場合、サービスプロバイダーCは、音声トラフィックの先制優先0および100-Mbps帯域幅を備えたC-TE LSP1、C-TE LSP3、C-TE LSP5、およびC-TE LSP7を確立し、C-TE LSP2、Cを確立します。-TE LSP4、C-TE LSP6、およびC-TE LSP8は、ビデオトラフィックの先制優先度1および200 mbps帯域幅を備えた帯域幅を備えています。一方、サービスプロバイダーAは、音声トラフィックの先制優先度0および1-gbps帯域幅を持つP-TE LSP1およびP-TE LSP3、およびPreemption Priority 1およびP-TE LSP4のP-TE LSP2およびP-TE LSP4を備えたP-TE LSP1およびP-TE LSP3を事前に確立します。ビデオトラフィック用の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（すなわち、0帯域幅を持つC-TE LSPS/P-TE LSP）[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）は、Xの帯域幅の予約を伴うRSVPパスをH2から要求することができます。VRFのコンテキスト内からのこの予約要求は、事前に確立されたP-TE/DS-TE LSPに類似の手順に基づいて集約されます。[RFC4804]。[RFC4804]の場合のように、異なるDS-TEクラスタイプに属する複数のP-TE LSPがある可能性があります。ローカルポリシーを実装して、適切なクラスタイプで、H1からP-TE LSPへの着信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に接続されています。リクエストホスト（H1）は、Xの帯域幅の予約を伴うRSVPパスをH2から要求することができます。この場合、PESとLDPの間に非TELSP（つまり、LDPなど）が提供されます。RFC3270]。
Note that this only provides Diffserv, and not the bandwidth reservation as is done with RSVP-TE.
これはDiffServのみを提供し、RSVP-TEで行われる帯域幅予約ではないことに注意してください。
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に示すように、顧客はサイト間のVOIPアプリケーションを使用しています（つまり、CE1とCE2の間）。H0とH1は音声機器を表します。この場合、非TELSPは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:
このソリューションは、C-RSVPパスとC-TE LSPにPEが使用するP-TE LSPSを決定する機能を提供する必要があります。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 Graceful Restartの間に転送され続ける優雅な再起動機能をサポートする必要があります。このアーキテクチャに関連する優雅な再起動メカニズムは、[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障害に対して再ルーティングを実行する機能を提供する必要があります。-te lsp。
The solution MUST support FRR [RFC4090] features for a C-TE LSP over a VRF instance.
このソリューションは、VRFインスタンスでC-TE LSPのFRR [RFC4090]機能をサポートする必要があります。
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環境では、P-TE LSPでトンネル化されているにもかかわらず、CEのC-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. CEリンク保護2. PEノード保護3. CEノード保護
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によって予約できる帯域幅の量については、2つの状況がある可能性があります。
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を拒否します
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の入場制御をサポートする必要があります。具体的には、PESには、特定の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. リンクごとの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が提供されると、CES、PES、および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ルーターはパス計算クライアント（PCCS）であり、PEルーターおよび/またはPルーターがPCESである場合があります。さらに、このソリューションは、動的な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は、サービスプロバイダーネットワーク内で完全にばらばらである2つの異なるP-TE LSPを通過している可能性があります。単一のCEに異なるPESに接続する複数のアップリンクがある場合、VRFインスタンスの複数のC-TE LSPをLSRのペア間で確立することが望ましいです。2つのCEが異なるPESに接続する複数のアップリンクを持っている場合、VRFインスタンスで複数のC-TE LSPを2つの異なる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)
1. 単一のネットワーク要素障害の場合にトラフィックの破壊を最小限に抑えるために、多様なC-TE LSPを横切るCE-CEからCE-CEからCE-CEのトラフィックの負荷バランス2.パス保護（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を使用した非TET 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は、「make-be-bebree-break」[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での入場制御をサポートする必要があります。PESは、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.
このソリューションは、非TTE LSP（つまり、LDPベースのLSPなど）をサポートする必要があります。非TTE LSPは、PESとサポート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からリモートCE（パス、RESV、パスエラー、RESVエラーなど）に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: 1. static routing 2. BGP routing 3. OSPF 4. OSPF-TE (RSVP-TE case only)
ソリューションは、CE-PEリンクのRSVPまたはRSVP-TEを使用したCE-PEリンクで次のルーティング構成をサポートする必要があります。1。静的ルーティング2. BGPルーティング3. OSPF 4. OSPF-TE（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.
このソリューションは、VRFインスタンスでのC-RSVPパスと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.
1. C-TE LSPのパス最適性の程度。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).
1. コントロールプレーン（P-TE LSPおよびC-TE LSPのマッピングを含む）および帯域幅モニタリングのMIBモジュールが必要です。2.診断ツールの必要性（これにはTracerouteと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.
C-TE LSPのMPLS操作、管理、およびメンテナンス（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）攻撃に対するService-Providerネットワークの脆弱性を最小限に抑える必要があります。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] Braden、R.、Clark、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] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[RFC2210] Wroclawski, J., "The Use of RSVP with IETF Integrated Services", RFC 2210, September 1997.
[RFC2210] Wroclawski、J。、「IETF統合サービスでのRSVPの使用」、RFC 2210、1997年9月。
[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.、Berger、L.、Gan、D.、Li、T.、Srinivasan、V。、およびG. Swallow、 "RSVP-TE：LSP Tunnelsの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] Le Faucheur、F.、Wu、L.、Davie、B.、Davari、S.、Vaananen、P.、Krishnan、R.、Cheval、P。、およびJ. Heinanen、「Multi-Protocol Label Switching」（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] Berger、L.、ed。、「一般化されたマルチプロトコルラベルスイッチング（GMPLS）シグナリングリソース予約プロトコルトラフィックエンジニアリング（RSVP-TE）拡張」、RFC 3473、2003年1月。
[RFC3623] Moy, J., Pillay-Esnault, P., and A. Lindem, "Graceful OSPF Restart", RFC 3623, November 2003.
[RFC3623] Moy、J.、Pillay-Esnault、P。、およびA. Lindem、「Graceful OSPF Restart」、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] Pan、P.、Ed。、Ed。、Swallow、G.、ed。、およびA. Atlas、ed。、「LSP TunnelsのRSVP-TEへの高速リルート拡張」、RFC 4090、2005年5月。
[RFC4124] Le Faucheur, F., Ed., "Protocol Extensions for Support of Diffserv-aware MPLS Traffic Engineering", RFC 4124, June 2005.
[RFC4124] Le Faucheur、F.、ed。、「Diffserv-Aware MPLS Traffic Engineeringのサポートのためのプロトコル拡張」、RFC 4124、2005年6月。
[RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private Networks (VPNs)", RFC 4364, February 2006.
[RFC4364] Rosen、E。およびY. Rekhter、「BGP/MPLS IP仮想ネットワーク（VPNS）」、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. Swallow、「Multi-Protocol Label Switched（MPLS）データプレーン障害の検出」、RFC 4379、2006年2月。
[RFC4655] Farrel, A., Vasseur, J.-P., and J. Ash, "A Path Computation Element (PCE)-Based Architecture", RFC 4655, August 2006.
[RFC4655] Farrel、A.、Vasseur、J.-P。、およびJ. Ash、「パス計算要素（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. Aggarwal、「MPLSによるBGPの優雅な再起動メカニズム」、RFC 4781、2007年1月。
[RFC5036] Andersson, L., Ed., Minei, I., Ed., and B. Thomas, Ed., "LDP Specification", RFC 5036, October 2007.
[RFC5036] Andersson、L.、ed。、Minei、I.、ed。、およびB. Thomas、ed。、「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] Andersson、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] Davie、B.、Le Faucheur、F。、およびA. Narayanan、「レイヤー3 VPNSのRSVPのサポート」、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] Le Faucheur、F.、ed。、「MPLS TE/DS-TEトンネル上のリソース予約プロトコル（RSVP）予約の集約」、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。、ed。、Meyer、M.、Kumaki、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。、ed。、およびJl。Le Roux、ed。、「パス計算要素（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.
著者は、ナビル・ビタール、デビッド・マクディサン、ダニエル・キングの有益で有用なコメントとフィードバックに感謝します。
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は、VRFインスタンスによって使用され、BGP/MPLS IP-VPN内の顧客パケットを転送します。
- The service provider has ensured that enough bandwidth is available to meet the service requirements.
- サービスプロバイダーは、サービス要件を満たすのに十分な帯域幅を利用できるようにしました。
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.
BGP/MPLS IP-VPNのコンテキストで、C-RSVPパスとP-TE LSPを図7に示します。P-TE LSPは、場合によっては非TTE 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は、Xの帯域幅予約によりCE3/CE2へのE2E C-RSVPパスを要求します。PE1で、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.
CES間で交換されたRSVP制御メッセージ（たとえば、RSVPパスメッセージとRSVP RESVメッセージ）は、BGP/MPLS IP-VPNを介してIPパケットによって転送されます。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 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.
BGP/MPLS IP-VPNのコンテキストで、C-TE LSPとP-TE LSPを図8に示します。P-TE LSPは、場合によっては非TTE LSP（つまり、LDP）である場合があります。前のサブセクションで説明されているように、場合によってはエンドツーエンドのQOを保証することは困難な場合があります。
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は、Xの帯域幅予約によりCE3/CE2へのE2E TE LSPパスを要求します。PE1で、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.
CES間で交換されたRSVP-TEコントロールメッセージ（たとえば、RSVPパスメッセージとRSVP RESVメッセージ）は、BGP/MPLS IP-VPNを介してラベル付きパケットによって転送されます。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は、VRFインスタンスによって使用され、BGP/MPLS IP-VPN内の顧客パケットを転送します。
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. E2E C-TE LSPモデル
Authors' Addresses
著者のアドレス
Kenji Kumaki (Editor) KDDI Corporation Garden Air Tower Iidabashi, Chiyoda-ku Tokyo 102-8460, JAPAN EMail: ke-kumaki@kddi.com
Kenji Kumaki（編集者）Kddi Corporation Garden Air Tower Iidabashi、Chiyoda-Ku Tokyo 102-8460、日本メール：ke-kumaki@kddi.com
Raymond Zhang BT Farady Building, PP1.21 1 Knightrider Street London EC4V 5BT UK EMail: raymond.zhang@bt.com
Raymond Zhang BT Farady Building、pp1.21 1 Knightrider Street London EC4V 5BT UKメール：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
Yuji Kamite NTT Communications Corporation Granpark Tower 3-4-1 Shibaura、Minato-Ku Tokyo 108-8118日本メール：y.kamite@ntt.com