[要約] RFC 5253は、L1VPN Basic Modeの適用性を説明するものであり、物理的なレイヤー1ネットワーク上での仮想プライベートネットワーク（L1VPN）の基本的な機能を提供します。このRFCの目的は、L1VPNの基本モードの使用に関するガイドラインを提供し、ネットワークエンジニアやプロバイダに役立つ情報を提供することです。
Network Working Group T. Takeda, Ed.
Request for Comments: 5253 NTT
Category: Informational July 2008
Applicability Statement for Layer 1 Virtual Private Network (L1VPN) Basic Mode
レイヤー1仮想プライベートネットワーク（L1VPN）基本モードの適用性ステートメント
Status of This Memo
本文書の位置付け
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモは、インターネットコミュニティに情報を提供します。いかなる種類のインターネット標準を指定しません。このメモの配布は無制限です。
Abstract
概要
This document provides an applicability statement on the use of Generalized Multiprotocol Label Switching (GMPLS) protocols and mechanisms to support Basic Mode Layer 1 Virtual Private Networks (L1VPNs).
このドキュメントは、一般化されたマルチプロトコルラベルスイッチング（GMPLS）プロトコルの使用に関する適用性ステートメントと、基本モードレイヤー1仮想プライベートネットワーク（L1VPNS）をサポートするメカニズムを提供します。
L1VPNs provide customer services and connectivity at Layer 1 over Layer 1 networks. The operation of L1VPNs is divided into the Basic Mode and the Enhanced Mode, where the Basic Mode of operation does not feature any exchange of routing information between the Layer 1 network and the customer domain. This document examines how GMPLS protocols can be used to satisfy the requirements of a Basic Mode L1VPN.
L1VPNは、レイヤー1ネットワークのレイヤー1でカスタマーサービスと接続性を提供します。L1VPNSの操作は、基本モードと拡張モードに分割されます。操作の基本モードでは、レイヤー1ネットワークと顧客ドメインの間のルーティング情報の交換がありません。このドキュメントでは、GMPLSプロトコルを使用して基本モードL1VPNの要件を満たす方法を調べます。
Table of Contents
目次
1. Introduction ....................................................3
1.1. Terminology ................................................3
2. Basic Mode Overview .............................................3
3. Supported Network Types .........................................4
3.1. Data Plane .................................................4
3.2. Control Plane ..............................................4
4. Addressing ......................................................5
5. Provider Control of Its Infrastructure ..........................5
5.1. Provisioning Model .........................................5
5.2. PE-to-PE Segment Control ...................................6
5.2.1. Path Computation and Establishment ..................6
5.2.2. Resource Management .................................7
5.2.3. Consideration of CE-to-PE Traffic Engineering
Information .........................................8
5.3. Connectivity Restriction ...................................8
6. Customer Control of Its L1VPN ...................................8
6.1. Topology Control ...........................................8
6.2. Note on Routing ............................................9
7. Scalability and Resiliency .....................................10
7.1. Scalability ...............................................10
7.2. Data Plane Resiliency .....................................11
7.3. Control Plane Resiliency ..................................12
8. Security Considerations ........................................12
8.1. Topology Confidentiality ..................................12
8.2. External Control of the Provider Network ..................13
8.3. Data Plane Security .......................................13
8.4. Control Plane Security ....................................14
9. Manageability Considerations ...................................15
10. References ....................................................15
10.1. Normative References .....................................15
10.2. Informative References ...................................16
11. Acknowledgments ...............................................17
This document provides an applicability statement on the use of Generalized Multiprotocol Label Switching (GMPLS) protocols and mechanisms to Basic Mode Layer 1 Virtual Private Networks (L1VPNs) as specified in [RFC4847].
このドキュメントは、[RFC4847]で指定されているように、一般化されたマルチプロトコルラベルスイッチング（GMPLS）プロトコルと基本モードレイヤー1仮想プライベートネットワーク（L1VPN）のメカニズムの使用に関する適用性ステートメントを提供します。
The operation of L1VPNs is divided into the Basic Mode and the Enhanced Mode. The Basic Mode of operation does not feature any exchange of routing information between the Layer 1 network and the customer domain, while the Enhanced Mode of operation features exchange of routing information between the Layer 1 network and the customer domain.
L1VPNSの動作は、基本モードと拡張モードに分割されます。基本的な操作モードは、レイヤー1ネットワークと顧客ドメイン間のルーティング情報の交換を特徴としていませんが、拡張された操作モードは、レイヤー1ネットワークと顧客ドメイン間のルーティング情報の交換を機能させます。
The main GMPLS protocols and mechanisms applicable to the L1VPN Basic Mode are described in [RFC5251], [RFC5195], and [RFC5252], along with several other documents referenced within this document.
L1VPN基本モードに適用される主なGMPLSプロトコルとメカニズムは、[RFC5251]、[RFC5195]、および[RFC5252]で説明されています。
Note that discussion in this document is focused on areas where GMPLS protocols and mechanisms are relevant.
このドキュメントでの議論は、GMPLSプロトコルとメカニズムが関連する分野に焦点を当てていることに注意してください。
The reader is assumed to be familiar with the terminology in [RFC3031], [RFC3209], [RFC3471], [RFC3473], [RFC4202], [RFC4026], and [RFC4847].
読者は、[RFC3031]、[RFC3209]、[RFC3471]、[RFC3473]、[RFC4202]、[RFC4026]、および[RFC4847]の用語に精通していると想定されています。
As described in [RFC4847], in the Basic Mode service model, there is no routing exchange between the Customer Edge (CE) and the Provider Edge (PE). CE-to-CE L1VPN connections (i.e., the CE-to-CE VPN connection in RFC 4847) are set up by GMPLS signaling between the CE and the PE, and then across the provider network. A L1VPN connection is limited to the connection between CEs belonging to the same L1VPN.
[RFC4847]で説明されているように、基本モードサービスモデルでは、顧客エッジ（CE）とプロバイダーエッジ（PE）の間にルーティング交換はありません。CEからCE-CE-L1VPN接続（つまり、RFC 4847のCE-CE-CE-CE-CE-CE-CE-CE-CE-CE-CE-CE-CE-CE-CE-CE-CE-CE-CE-CE-CE-CE-CE-CE-CE-CE-CE-CE-CE-CE-CE-CE-CE-CE-CE-CE-CE-CE-CE-CE-CE-CE-CE-CE-CE-CE-CE-CE-CE-CE-CE-CE-CE-CE-CE-CE-CE-CE-CE-CE-CE-CE-CE-CE-CE-VPN接続は、CEとPEの間で、次にプロバイダーネットワーク全体で設定されます。L1VPN接続は、同じL1VPNに属するCES間の接続に制限されています。
Note that in L1VPNs, routing operates within the provider network. Also note that routing may be used by PEs to exchange information specific to the L1VPNs supported by the provider network (e.g., membership information).
L1VPNSでは、ルーティングがプロバイダーネットワーク内で動作することに注意してください。また、Routingは、プロバイダーネットワーク（メンバーシップ情報など）でサポートされているL1VPNSに固有の情報を交換するためにPESによって使用される場合があることに注意してください。
In the L1VPN Basic Mode, the provider network is completely under the control of the provider. This includes the PE-to-PE segment of the CE-to-CE L1VPN connection that is controlled and computed by the provider (PE-to-PE segment control). On the other hand, the L1VPN itself, constructed from a set of CEs and the L1VPN connections provided by the provider, is under the control of each customer. This control includes that a customer can request between which CEs a connection is to be established (topology control). Note that a customer may outsource the management of its L1VPN to a third party, including to the provider itself. There is a confidentiality requirement between the provider and each customer.
L1VPN基本モードでは、プロバイダーネットワークは完全にプロバイダーの制御下にあります。これには、プロバイダーによって制御および計算されるCE-T-CE-CE-CE-CE-CE-CE-CE-CE-CE-CE-CE-CE-CE-L1VPN接続のPE-ToPEセグメントが含まれます（PE-To-PEセグメント制御）。一方、CESのセットとプロバイダーが提供するL1VPN接続から構築されたL1VPN自体は、各顧客の管理下にあります。このコントロールには、顧客がCESの接続が確立される（トポロジコントロール）の間に要求できることが含まれます。顧客は、プロバイダー自体を含むL1VPNの管理を第三者に外注する場合があることに注意してください。プロバイダーと各顧客の間には機密性の要件があります。
[RFC5251], which extends [RFC4208], specifies GMPLS signaling to establish CE-to-CE L1VPN connections.
[RFC5251]は、[RFC4208]を拡張し、CE-CE-CE-CE-L1VPN接続を確立するためのGMPLSシグナリングを指定します。
[RFC5195] and [RFC5252] specify alternative mechanisms to exchange L1VPN membership information between PEs, based on BGP and OSPF, respectively.
[RFC5195]および[RFC5252]は、それぞれBGPとOSPFに基づいて、PES間でL1VPNメンバーシップ情報を交換するための代替メカニズムを指定します。
The provider network can be constructed from any type of Layer 1 switches, such as Time Division Multiplexing (TDM) switches, Optical Cross-Connects (OXCs), or Photonic Cross-Connects (PXCs). Furthermore, a PE may be an Ethernet Private Line (EPL) type of device, that maps Ethernet frames onto Layer 1 connections (by means of Ethernet over TDM, etc.). The provider network may be constructed from switches providing a single switching granularity (e.g., only VC3 switches), or from switches providing multiple switching granularities (e.g., from VC3/VC4 switches, or from VC3 switches and OXCs). The provider network may provide a single type of L1VPN connection (e.g., VC3 connections only), or multiple types of connection (e.g., VC3/VC4 connections, or VC3 connections and wavelength connections).
プロバイダーネットワークは、時間分割多重化（TDM）スイッチ、光学クロスコネクト（OXC）、またはフォトニッククロスコネクト（PXC）など、あらゆるタイプのレイヤー1スイッチから構築できます。さらに、PEは、イーサネットフレームをレイヤー1接続にマッピングするイーサネットプライベートライン（EPL）タイプのデバイスである場合があります（TDMなどのイーサネットなど）。プロバイダーネットワークは、単一のスイッチング粒度（例えば、VC3スイッチのみ）を提供するスイッチから構築され、複数のスイッチング粒度（VC3/VC4スイッチ、またはVC3スイッチとOXCから）を提供するスイッチから構築できます。プロバイダーネットワークは、単一のタイプのL1VPN接続（例：VC3接続のみ）、または複数のタイプの接続（VC3/VC4接続、VC3接続と波長接続）を提供する場合があります。
A CE does not have to have the capability to switch at Layer 1, but it must be capable of receiving a Layer 1 signal and either switching it or terminating it with adaptation.
CEには、レイヤー1に切り替える機能が必要ですが、レイヤー1信号を受信し、それを切り替えるか、適応で終了することができなければなりません。
As described in [RFC4847] and [RFC5251], a CE and a PE are connected by one or more links. A CE may also be connected to more than one PE, and a PE may have more than one CE connected to it.
[RFC4847]および[RFC5251]で説明されているように、CEとPEは1つ以上のリンクで接続されています。CEは複数のPEに接続されている場合があり、PEには複数のCEが接続されている場合があります。
A CE may belong to a single L1VPN, or to multiple L1VPNs, and a PE may support one or more L1VPNs through a single CE or through multiple CEs.
CEは、単一のL1VPN、または複数のL1VPNに属し、PEは単一のCEまたは複数のCEを介して1つ以上のL1VPNをサポートする場合があります。
The provider network is controlled by GMPLS. L1VPN Basic Mode provider networks are limited to a single AS within the scope of this document. Multi-AS Basic Mode L1VPNs are for future study.
プロバイダーネットワークはGMPLSによって制御されます。L1VPN基本モードプロバイダーネットワークは、このドキュメントの範囲内で単一に制限されています。Multi-As Basic Mode L1VPNは、将来の研究のためです。
As described in [RFC4847] and [RFC5251], a CE and a PE need to be connected by at least one control channel. It is necessary to disambiguate control plane messages exchanged between a CE and a PE if the CE-to-PE relationship is applicable to more than one L1VPN. This makes it possible to determine to which L1VPN such control plane messages apply. Such disambiguation can be achieved by allocating a separate control channel to each L1VPN (either using a separate physical channel, a separate logical channel such as an IP tunnel, or using separate addressing).
[RFC4847]および[RFC5251]で説明されているように、CEとPEを少なくとも1つの制御チャネルで接続する必要があります。CEとPEの関係が複数のL1VPNに適用できる場合、CEとPEの間で交換されるコントロールプレーンのメッセージを非表示にする必要があります。これにより、そのような制御面のメッセージが適用されるL1VPNを決定することが可能になります。このような曖昧性は、各L1VPNに個別の制御チャネルを割り当てることで実現できます（個別の物理チャネル、IPトンネルなどの個別の論理チャネルを使用するか、個別のアドレス指定を使用します）。
GMPLS allows any type of control channel to be used, as long as there is IP level reachability. In the L1VPN context, instantiation of a control channel between a CE and a PE may differ depending on security requirements, etc. This is discussed in Section 8.
GMPLSを使用すると、IPレベルの到達可能性がある限り、あらゆる種類の制御チャネルを使用できます。L1VPNコンテキストでは、CEとPEの間の制御チャネルのインスタンス化は、セキュリティ要件などによって異なる場合があります。これについては、セクション8で説明します。
As described in [RFC5251], the L1VPN Basic Mode allows that customer addressing realms overlap with each other, and also overlap with the service provider addressing realm. That is, a customer network may reuse addresses used by the provider network, and may reuse addresses used in another customer network supported by the same provider network. This is the same as in any other VPN model.
[RFC5251]で説明されているように、L1VPN基本モードにより、顧客が領域に互いに重複していることが可能になり、サービスプロバイダーが領域に対処すると重複しています。つまり、顧客ネットワークは、プロバイダーネットワークで使用されるアドレスを再利用する場合があり、同じプロバイダーネットワークでサポートされている別の顧客ネットワークで使用されるアドレスを再利用する場合があります。これは、他のVPNモデルと同じです。
In addition, the L1VPN Basic Mode allows CE-to-PE control channel addressing realms to overlap. That is, a CE-to-PE control channel address (CE's address of this control channel and PE's address of this control channel) is unique within the L1VPN that the CE-to-PE control channel belongs to, but not necessarily unique across multiple L1VPNs.
さらに、L1VPN BASICモードにより、CE-To-PEコントロールチャネルアドレス指定レルムがオーバーラップできます。つまり、CE-to-PEコントロールチャネルアドレス（この制御チャネルのCEのアドレスとこの制御チャネルのPEのアドレス）は、CE-to-PEコントロールチャネルが属するL1VPN内で一意ですが、複数で必ずしも一意ではありませんL1VPNS。
Furthermore, once a L1VPN connection has been established, the L1VPN Basic Mode does not enforce any restriction on address assignment for this L1VPN connection (treated as a link) for customer network operation (e.g., IP network, MPLS network).
さらに、L1VPN接続が確立されると、L1VPN基本モードは、顧客ネットワーク操作（IPネットワーク、MPLSネットワークなど）のこのL1VPN接続（リンクとして扱われる）のアドレス割り当ての制限を強制しません。
As described in [RFC5251], for each L1VPN that has at least one customer-facing port on a given PE, the PE maintains a Port Information Table (PIT) associated with that L1VPN. A PIT provides a cross-reference between Customer Port Indices (CPIs) and Provider Port Indices (PPIs) and contains a list of <CPI, PPI> tuples for all the ports within the L1VPN. In addition, for local PE ports of a given L1VPN, the PE retains an identifier known as the VPN-PPI, and this is stored in the PIT with the <CPI, PPI> tuples.
[RFC5251]で説明されているように、特定のPEに少なくとも1つの顧客向けポートを持つ各L1VPNについて、PEはそのL1VPNに関連付けられたポート情報テーブル（PIT）を維持します。PITは、顧客ポートインデックス（CPI）とプロバイダーポートインデックス（PPI）の相互参照を提供し、L1VPN内のすべてのポートの<CPI、PPI> TUPPLEのリストが含まれています。さらに、特定のL1VPNのローカルPEポートの場合、PEはVPN-PPIとして知られる識別子を保持し、これは<CPI、PPI>タプルでピットに保存されます。
When a new CE belonging to one or more L1VPNs is added to a PE, PIT entries associated to those L1VPNs need to be configured on the PE. Section 4 of [RFC5251] specifies such procedures:
1つ以上のL1VPNに属する新しいCEがPEに追加される場合、これらのL1VPNに関連付けられたPITエントリをPEで構成する必要があります。[RFC5251]のセクション4は、そのような手順を指定します。
- If no PIT exists for the L1VPN on the PE, a new PIT is created by the provider and associated with the VPN identifier.
- PEのL1VPNにピットが存在しない場合、プロバイダーによって新しいピットが作成され、VPN識別子に関連付けられます。
- The PIT (new or pre-existing) is updated to include information related to the newly added CE. The VPN-PPI, PPI, and CPI are installed in the PIT. Note that the PPI is well-known by the PE, but the CPI must be discovered either through manual configuration or automatically by mechanisms such as the Link Management Protocol (LMP) [RFC4204]. In addition, a CE-to-PE control channel needs to be configured.
- ピット（新規または既存の存在）は、新しく追加されたCEに関連する情報を含めるように更新されます。VPN-PPI、PPI、およびCPIがPITにインストールされています。PPIはPEでよく知られていますが、CPIは手動構成を通じて、またはリンク管理プロトコル（LMP）[RFC4204]などのメカニズムによって自動的に発見する必要があります。さらに、CEからPEへの制御チャネルを構成する必要があります。
- The updated PIT information needs to be configured in the PITs on the remote PE associated with the L1VPN. For such purposes, manual configuration or some sort of auto-discovery mechanisms can be used. [RFC5195] and [RFC5252] specify alternative auto-discovery mechanisms.
- 更新されたピット情報は、L1VPNに関連付けられたリモートPEのピットで構成する必要があります。このような目的のために、手動構成またはある種の自動発見メカニズムを使用できます。[RFC5195]および[RFC5252]は、代替の自動配信メカニズムを指定します。
- In addition, remote PIT information associated with the L1VPN needs to be configured on this PE if the PIT has been newly created. Again, this can be achieved through manual configuration or through auto-discovery; see [RFC5195] and [RFC5252].
- さらに、L1VPNに関連付けられたリモートピット情報は、ピットが新しく作成されている場合は、このPEで構成する必要があります。繰り返しますが、これは手動構成または自動発見を通じて達成できます。[RFC5195]および[RFC5252]を参照してください。
When L1VPN membership of an existing CE changes, or when a CE is removed from a PE, similar procedures need to be applied to update the local and remote PITs.
既存のCEのL1VPNメンバーシップが変更された場合、またはCEがPEから削除された場合、ローカルおよびリモートピットを更新するために同様の手順を適用する必要があります。
In the L1VPN Basic Mode, a PE-to-PE segment of a CE-to-CE L1VPN connection is completely under the control of the provider network.
L1VPN基本モードでは、CE-To-CE-CE-CE-CE-CE-CE-L1VPN接続のPE-PEセグメントは、プロバイダーネットワークの制御下にあります。
A PE-to-PE segment of a CE-to-CE L1VPN connection may be established based on various policies. Those policies can be applied per L1VPN or per L1VPN connection. The policy is configured by the provider, possibly based on the contracts with each customer.
CE-T-CE-CE-CE-CE-L1VPN接続のPE-PEセグメントは、さまざまなポリシーに基づいて確立される場合があります。これらのポリシーは、L1VPNまたはL1VPN接続ごとに適用できます。ポリシーは、おそらく各顧客との契約に基づいて、プロバイダーによって構成されています。
Examples of PE-to-PE segment connection establishment polices supported in the L1VPN Basic Mode are as follows.
L1VPN基本モードでサポートされているPE-To-PEセグメント接続の確立ポリシーの例は次のとおりです。
- Policy 1: On-demand establishment, on-demand path computation - Policy 2: On-demand establishment, pre-computed path - Policy 3: Pre-establishment, pre-computed path In each policy, the PE-to-PE path may be computed by the local PE or by a path computation entity outside of the local PE (e.g., a Path Computation Element (PCE) [RFC4655] or a management system).
- ポリシー1：オンデマンドの確立、オンデマンドパス計算 - ポリシー2：オンデマンド設立、事前計算パス - ポリシー3：事前設立、各ポリシーの事前計算パス、PE-ToPEパスはローカルPEまたはローカルPEの外側のパス計算エンティティ（たとえば、パス計算要素（PCE）[RFC4655]または管理システム）によって計算されます。
In policies 2 and 3, pre-computation of paths (and pre-establishment if applicable) can be done at the network planning phase, or just before signaling (e.g., triggered by an off-line customer request). As the result of pre-computation (and pre-establishment), there could be multiple PE-to-PE segments for a specific pair of PEs. When a PE receives a Path message from a CE for a L1VPN connection, a PE needs to determine which PE-to-PE segment to use. In such cases, the provider may want to control:
ポリシー2および3では、パスの事前計算（および該当する場合は事前に確立されている場合）をネットワーク計画段階で行うことができます。事前計算（および事前確立）の結果として、特定のPEのペアには複数のPE-PEセグメントがある可能性があります。PEがL1VPN接続に対してCEからパスメッセージを受信する場合、PEはどのPE-ToPEセグメントを使用するかを決定する必要があります。そのような場合、プロバイダーは次のように制御したい場合があります。
- Which L1VPN uses which PE-to-PE L1VPN segment. - Which CE-to-CE L1VPN connection uses which PE-to-PE L1VPN segment.
- どのL1VPNがどのPE-PE L1VPNセグメントを使用しているか。 - どのCE-T-CE-CE-CE-CE-CE-PE L1VPNセグメントを使用します。
The former requires mapping between the PIT and the PE-to-PE segment. The latter requires some more sophisticated mapping method, for example:
前者は、ピットとPE-ToPEセグメントの間のマッピングが必要です。後者には、より洗練されたマッピング方法、たとえば：
- Mapping between individual PIT entries and PE-to-PE segments. - Use of a Path Key ID [CONF-SEG] supplied by the provider to the CE, and signaled by the CE as part of the L1VPN connection request.
- 個々のピットエントリとPE-ToPEセグメント間のマッピング。 - プロバイダーからCEに提供され、L1VPN接続要求の一部としてCEによって合図されたパスキーID [conf-seg]の使用。
The L1VPN Basic Mode does not preclude usage of other methods, if applicable.
L1VPN基本モードは、該当する場合、他の方法の使用を排除しません。
In policy 3, stitching or nesting is necessary in order to map the CE-to-CE L1VPN connection to a pre-established PE-to-PE segment.
ポリシー3では、CEからCE-CE-CE-CE-CE-PEへの接続を事前に確立したPE-To-PEセグメントにマッピングするために、ステッチまたはネストが必要です。
The provider network may operate resource management based on various policies. These policies can be applied per L1VPN or per L1VPN connection. The policy is configured by the provider, possibly based on the contracts with each customer.
プロバイダーネットワークは、さまざまなポリシーに基づいてリソース管理を運用する場合があります。これらのポリシーは、L1VPNまたはL1VPN接続ごとに適用できます。ポリシーは、おそらく各顧客との契約に基づいて、プロバイダーによって構成されています。
For example, a provider may choose to partition the resources of the provider network for limited use by different L1VPNs or customers. Such a function might be achieved within the scope of the Basic Mode using resource affinities [RFC3209], but the details of per-L1VPN resource models (especially in terms of CE-to-PE routing) are considered as part of the Enhanced Mode.
たとえば、プロバイダーは、さまざまなL1VPNまたは顧客によって制限された使用のためにプロバイダーネットワークのリソースを分割することを選択できます。このような関数は、リソースアフィニティ[RFC3209]を使用して基本モードの範囲内で達成される可能性がありますが、L1VPNごとのリソースモデルの詳細（特にCE-PEルーティングの観点から）は、強化モードの一部と見なされます。
[RFC5252] and [BGP-TE] allow CE-to-PE Traffic Engineering (TE) link information to be injected into the provider network, and in particular to be exchanged between PEs. This may be helpful for the ingress PE to prevent connection setup failure due to lack of resources or incompatible switching capabilities on remote CE-to-PE TE links.
[RFC5252]および[BGP-TE]により、CE-To-PEトラフィックエンジニアリング（TE）リンク情報がプロバイダーネットワークに注入され、特にPES間で交換されるようになります。これは、リソースの不足やリモートCEからPEへのリンクの互換性のないスイッチング機能のために、接続セットアップの障害を防ぐために、Ingress PEにとって役立つ場合があります。
Furthermore, the L1VPN Basic Mode allows a remote CE to be reached through more than one TE link connected to the same PE (single-homed) or to different PEs (dual-homed). In such cases, to facilitate route choice, the ingress CE needs to initiate signaling by specifying the egress CE's router ID, not the egress CPI, in the Session Object and the Explicit Route Object (ERO), if present, so as to not constrain the choice of route within the provider network. Therefore, the CE's router ID needs to be configured in the PITs.
さらに、L1VPN基本モードにより、同じPE（単一給）または異なるPE（デュアルホーム）に接続された複数のTEリンクを介して、リモートCEに到達できます。そのような場合、ルートの選択を容易にするために、侵入CEは、存在する場合は、セッションオブジェクトと明示的なルートオブジェクト（ERO）で、出口CEのルーターID（出口CPI）を指定することにより、シグナリングを開始する必要があります。プロバイダーネットワーク内のルートの選択。したがって、CEのルーターIDはピットで構成する必要があります。
Note that, as described in Section 7.2, consideration of the full feature set enabled by dual-homing (such as resiliency) is out of scope of the L1VPN Basic Mode.
セクション7.2で説明されているように、デュアルホーミング（弾力性など）によって有効になっている完全な機能セットの考慮は、L1VPN基本モードの範囲外であることに注意してください。
The L1VPN Basic Mode allows restricting connection establishment between CEs belonging to the same L1VPN for policy reasons (including L1VPN security). Since the PIT at each PE is associated with a L1VPN, this function can be easily supported. The restriction can be applied at the ingress PE or at the egress PE according to the applicable restriction policy, but note that applying the policy at the egress may waste signaling effort within the network as L1VPN connections are pointlessly attempted.
L1VPN基本モードにより、政策上の理由（L1VPNセキュリティを含む）のために、同じL1VPNに属するCE間の接続確立を制限できます。各PEのピットはL1VPNに関連付けられているため、この関数は簡単にサポートできます。制限は、該当する制限ポリシーに従って、イングレスPEまたは出口PEで適用できますが、脱出するポリシーを適用すると、L1VPN接続が無意味に試行されるため、ネットワーク内のシグナルの努力を無駄にする場合があることに注意してください。
In addition, the L1VPN Basic Mode does not restrict use of any advanced admission control based on various policies.
さらに、L1VPN基本モードは、さまざまなポリシーに基づいて高度な入場制御の使用を制限しません。
In the L1VPN Basic Mode, L1VPN connection topology is controlled by the customer. That is, a customer can request setup/deletion/modification of L1VPN connections using signaling mechanisms specified in [RFC5251].
L1VPN基本モードでは、L1VPN接続トポロジは顧客によって制御されます。つまり、顧客は[RFC5251]で指定されたシグナル伝達メカニズムを使用して、L1VPN接続のセットアップ/削除/変更を要求できます。
Also note that if there are multiple CE-to-PE TE links (single-homed or multi-homed), a customer can specify which CE-to-PE TE link to use to support any L1VPN connection. Alternatively, a customer may let the provider choose the CE-to-PE TE link at the egress side, as described in Section 5.2.3.
また、複数のCE-TE-TEリンク（シングルホームまたはマルチホーム）がある場合、顧客は任意のL1VPN接続をサポートするために使用するCE-PE-TEリンクを指定できることに注意してください。または、セクション5.2.3で説明されているように、顧客はプロバイダーに出口側のCE-TE-TEリンクを選択させることができます。
A CE needs to obtain the remote CPI to which it wishes to request a connection. Since, in the L1VPN Basic Mode, there is no routing information exchange between a CE and a PE, there is no dynamic mechanism supported as part of the Basic Mode L1VPN service, and the knowledge of remote CPIs must be acquired in a L1VPN-specific way, perhaps through configuration or through a directory server.
CEは、接続を要求したいリモートCPIを取得する必要があります。L1VPN基本モードでは、CEとPEの間にルーティング情報交換はないため、基本モードL1VPNサービスの一部としてサポートされる動的メカニズムはなく、リモートCPIの知識はL1VPN固有の知識を取得する必要があります。方法、おそらく構成を介して、またはディレクトリサーバーを介して。
If an L1VPN is used by a customer to operate a private IP network, the customer may wish to form routing adjacencies over the CE-to-CE L1VPN connections. The L1VPN Basic Mode does not enforce any restriction on such operation by a customer, and the use made of the L1VPN connections is transparent to the provider network.
L1VPNが顧客がプライベートIPネットワークを操作するために使用する場合、顧客はCE-CE-CE-CE-CE-CE-CE-CE-L1VPN接続を介してルーティング隣接を形成することを望む場合があります。L1VPN基本モードは、顧客によるそのような操作の制限を強制せず、L1VPN接続で作られた使用はプロバイダーネットワークに対して透明です。
Furthermore, if an L1VPN is used by a customer to operate a private Multiprotocol Label Switching (MPLS) or GMPLS network, the customer may wish to treat a L1VPN connection as a TE link, and this requires a CE-to-CE control channel. Note that a Forwarding Adjacency [RFC4206] cannot be formed from the CE-to-CE L1VPN connection in the Basic Mode because there is no routing exchange between CE and PE. That is, the customer network and the provider network do not share a routing instance, and the customer control channel cannot be carried within the provider control plane. But where the CE provides suitable adaptation (for example, where the customer network is a packet- switched MPLS or GMPLS network), the customer control channel may be in-band and a routing adjacency may be formed between the CEs using the L1VPN connection. Otherwise, CE-to-CE control plane connectivity may form part of the L1VPN service provided to the customer by the provider and may be achieved within the L1VPN connection (for example, through the use of overhead bytes) or through a dedicated control channel connection or tunnel. The options available are discussed further in Section 10.2 of [RFC4847].
さらに、顧客がL1VPNを使用してプライベートマルチプロトコルラベルスイッチング（MPLS）またはGMPLSネットワークを操作する場合、顧客はL1VPN接続をTEリンクとして扱うことを希望する場合があります。CEとPEの間にルーティング交換がないため、基本モードのCE-CE-CE-CE-CE-CE-CE-CE-CE-CE-CE-CE-CE-CE-CE-CE-CE-CE-CE-CE-CE-L1VPN接続からフォワーディング隣接性[RFC4206]を形成できないことに注意してください。つまり、顧客ネットワークとプロバイダーネットワークはルーティングインスタンスを共有しておらず、カスタマーコントロールチャネルをプロバイダーコントロールプレーン内で運ぶことはできません。しかし、CEが適切な適応を提供する場合（たとえば、顧客ネットワークがパケットスイッチされたMPLSまたはGMPLSネットワークである場合）、顧客制御チャネルは帯域内にあり、L1VPN接続を使用してCES間にルーティング隣接を形成することができます。それ以外の場合、CE-CE-CE-CENCEの制御プレーン接続は、プロバイダーが顧客に提供するL1VPNサービスの一部を形成し、L1VPN接続内（たとえば、オーバーヘッドバイトの使用）または専用の制御チャネル接続を介して達成される場合があります。またはトンネル。利用可能なオプションについては、[RFC4847]のセクション10.2でさらに説明します。
There are several factors that impact scalability.
スケーラビリティに影響を与えるいくつかの要因があります。
o Number of L1VPNs (PITs) configured on each PE
o 各PEで構成されたL1VPNS（ピット）の数
With the increase of this number, information to be maintained on the PE increases. Theoretically, the upper limit of the number of L1VPNs supported in a provider network is governed by how the ID associated with a L1VPN is allocated, and the number of PITs configured on each PE is limited by this number. However, implementations may impose arbitrary limits on the number of PITs supported by any one PE.
この数の増加に伴い、PEで維持される情報が増加します。理論的には、プロバイダーネットワークでサポートされているL1VPNの数の上限は、L1VPNに関連付けられたIDの割り当て方法によって支配され、各PEで構成されたピットの数はこの数によって制限されます。ただし、実装により、PEがサポートするピットの数に任意の制限が課される場合があります。
o Number of CE-to-PE TE links for each L1VPN
o 各L1VPNのCE-TE-TE-TEリンクの数
With the increase of this number, information to be maintained in each PIT increases. When auto-discovery mechanisms are used, the amount of information that an auto-discovery mechanism can support may restrict this number.
この数の増加に伴い、各ピットで維持される情報が増加します。自動発見メカニズムを使用すると、自動発見メカニズムがサポートできる情報の量がこの数を制限する可能性があります。
Note that [RFC5252] floods membership information not only among PEs, but also to all P nodes. This may lead to scalability concerns, compared to [RFC5195], which distributes membership information only among PEs. Alternatively, a separate instance of the OSPF protocol can be used just between PEs for distributing membership information. In such a case, Ps do not participate in flooding.
[RFC5252]は、PESだけでなく、すべてのPノードにもメンバーシップ情報をあふれさせることに注意してください。これは、[RFC5195]と比較してスケーラビリティの懸念につながる可能性があります。[RFC5195]は、PESのみでメンバーシップ情報を配布します。または、OSPFプロトコルの個別のインスタンスをPEの間だけで使用するために、メンバーシップ情報を配布することができます。そのような場合、PSは洪水に参加しません。
Note that in the L1VPN Basic Mode, a PE needs to obtain only CE-to-PE TE link information, and not customer routing information, which is quite different from the mode of operation of an L3VPN. Therefore, the scalability concern is considered to be less problematic.
L1VPN基本モードでは、PEはL3VPNの動作モードとはまったく異なる顧客ルーティング情報ではなく、CE-TE-TEリンク情報のみを取得する必要があることに注意してください。したがって、スケーラビリティの懸念は、問題が少ないと考えられています。
o Number of L1VPN connections
o L1VPN接続の数
With the increase of this number, information to be maintained on each PE/P increases. When stitching or nesting is used, the state to be maintained at each PE increases compared to when connectivity is achieved without stitching or nesting.
この数の増加に伴い、各PE/Pで維持される情報が増加します。ステッチまたはネストが使用される場合、各PEで維持される状態は、接続性が縫合またはネストなしで達成される場合と比較して増加します。
However, in a Layer 1 core, this number is always bounded by the available physical resource because each LSP uses a separate label which is directly bound to a physical, switchable resource (timeslot, lambda, or fiber). Thus, it can be safely assumed that the PEs/Ps can comfortably handle the number of LSPs that they may be called on to switch for a L1VPN.
ただし、レイヤー1コアでは、各LSPは物理的で切り替え可能なリソース（タイムスロット、ラムダ、またはファイバー）に直接結合した別のラベルを使用するため、この数値は常に利用可能な物理リソースに囲まれています。したがって、PES/PSは、L1VPNに切り替えるために呼び出される可能性のあるLSPの数を快適に処理できると安全に想定できます。
The L1VPN Basic Mode supports the following data plane recovery techniques [RFC5251].
L1VPN基本モードは、次のデータプレーン回復手法[RFC5251]をサポートしています。
o PE-to-PE segment recovery
o PE-ToPEセグメントの回復
The CE indicates to protect the PE-to-PE segment by including Protection Object specified in [RFC4873] in the Path message and setting Segment Recovery Flags. The CE may also indicate the branch and merge nodes by including a Secondary Explicit Route Object.
CEは、パスメッセージに[RFC4873]で指定された保護オブジェクトとセグメントセグメントリカバリフラグを設定することにより、PE-ToPEセグメントを保護することを示しています。CEは、二次的な明示的なルートオブジェクトを含めることにより、分岐を示し、ノードをマージする場合もあります。
Depending on the signaling mechanisms used within the provider network, details on how to protect the PE-to-PE segment may differ as follows.
プロバイダーネットワーク内で使用されるシグナルメカニズムに応じて、PE-ToPEセグメントを保護する方法の詳細は次のように異なる場合があります。
- If LSP stitching or LSP hierarchy are used to provision the PE-to-PE segment, then the PE-to-PE LSP may be protected using end-to-end recovery within the provider network.
- LSPステッチまたはLSP階層を使用してPE-ToPEセグメントのプロビジョニングを使用する場合、PE-To-PE LSPはプロバイダーネットワーク内のエンドツーエンドの回復を使用して保護されます。
- If the CE-to-CE L1VPN connection is a single end-to-end LSP (including if session shuffling is used), then the PE-to-PE LSP segment may be protected using segment protection [RFC4873].
- CEからCE-CE-CE-L1VPN接続が単一のエンドツーエンドLSP（セッションシャッフルが使用される場合を含む）である場合、PE-PE LSPセグメントはセグメント保護を使用して保護されます[RFC4873]。
o CE-to-PE recovery and PE-to-PE recovery via link protection
o Link Protectionを介したCE-To-PE回復とPE-PE回復
The CE indicates to protect ingress and egress CE-to-PE links as well as links within the provider network by including the Protection Object specified in [RFC3473] and setting Link Flags in the Path message.
CEは、[RFC3473]で指定された保護オブジェクトを含めて、パスメッセージにリンクフラグを設定することにより、PROVIDERネットワーク内のリンクと同様に、CE-To-PEリンクを保護することを示しています。
- The ingress and egress CE-to-PE link may be protected at a lower layer.
- 侵入および出口のCE-PEリンクは、下層で保護できます。
Depending on the signaling mechanisms used within the provider network, details on how to protect links within the provider network may differ as follows.
プロバイダーネットワーク内で使用されるシグナルメカニズムに応じて、プロバイダーネットワーク内のリンクを保護する方法の詳細は、次のように異なる場合があります。
- If the PE-to-PE segment is provided as a single TE link (stitching or hierarchy) so that the provider network can perform simple PE-to-PE routing, then the TE link may offer link-level protection through the instantiation of multiple PE-to-PE LSPs.
- PE-ToPEセグメントが単一のTEリンク（ステッチまたは階層）として提供され、プロバイダーネットワークが単純なPE-ToPEルーティングを実行できるようにする場合、TEリンクは複数のインスタンス化によりリンクレベルの保護を提供する場合があります。PE-TOPE LSP。
- The PE-to-PE segment may be provisioned using only link-protected links within the core network.
- PE-ToPEセグメントは、コアネットワーク内のリンクで保護されたリンクのみを使用してプロビジョニングできます。
Note that it is not possible to protect only the CE-to-PE portion or the PE-to-PE portion by link protection because the CE-to-CE signaling request asks for a certain level of link protection on all links used by the LSP. Also, it is not possible to protect the CE-to-PE portion by link recovery and the PE-to-PE portion by segment recovery at the same time.
CE-CE-CEシグナリング要求は、使用するすべてのリンクで特定のレベルのリンク保護を要求するため、リンク保護によってCE-PEまたはPE-ToPE部分のみを保護することはできないことに注意してください。lsp。また、Link RecoveryおよびPE-To-PE部分によって同時にCE-PEへの部分を保護することはできません。
CE-to-CE recovery through the use of connections from one CE to diverse PEs (i.e., dual-homing) is not supported in the L1VPN Basic Mode.
1つのCEから多様なPES（つまり、デュアルホミング）への接続を使用することによるCEからCEから回復は、L1VPN基本モードではサポートされていません。
The L1VPN Basic Mode allows use of GMPLS control plane resiliency mechanisms. This includes, but is not limited to, control channel management in LMP [RFC4204] and fault handling in RSVP-TE ([RFC3473] and [RFC5063]) between a CE and a PE, as well as within the provider network.
L1VPN基本モードにより、GMPLSコントロールプレーンの回復力メカニズムを使用できます。これには、LMP [RFC4204]の制御チャネル管理と、CEとPE、およびPE、およびプロバイダーネットワーク内のRSVP-TE（[RFC3473]および[RFC5063]）の障害処理が含まれますが、これらに限定されません。
Security considerations are described in [RFC4847], and this section describes how these considerations are addressed in the L1VPN Basic Mode.
セキュリティ上の考慮事項は[RFC4847]で説明されており、このセクションでは、これらの考慮事項がL1VPN基本モードでどのように対処されるかについて説明します。
Additional discussion of GMPLS security can be found in [GMPLS-SEC].
GMPLSセキュリティの追加の議論は、[GMPLS-SEC]にあります。
As specified in [RFC5251], a provider's topology confidentiality is preserved by the Basic Mode. Since there is no routing exchange between PE and CE, the customer network can gather no information about the provider network. Further, as described in Section 4 of [RFC4208], a PE may filter the information present in a Record Route Object (RRO) that is signaled from the provider network to the customer network. In addition, as described in Section 5 of [RFC4208] and Section 4.4 of [RFC5251], when a Notify message is sent to a CE, it is possible to hide the provider internal address. This is accomplished by a PE updating the Notify Node Address with its own address when the PE receives a NOTIFY_REQUEST object from the CE.
[RFC5251]で指定されているように、プロバイダーのトポロジの機密性は基本モードによって保存されます。PEとCEの間にルーティング交換がないため、カスタマーネットワークはプロバイダーネットワークに関する情報を収集できません。さらに、[RFC4208]のセクション4で説明されているように、PEは、プロバイダーネットワークからカスタマーネットワークに合図されるレコードルートオブジェクト（RRO）に存在する情報をフィルタリングする場合があります。さらに、[RFC4208]のセクション5および[RFC5251]のセクション4.4で説明されているように、通知メッセージがCEに送信されると、プロバイダーの内部アドレスを非表示にすることができます。これは、PEがCEからnotify_requestオブジェクトを受信したときに、独自のアドレスでNotifyノードアドレスを更新するPEによって達成されます。
Even in the case of pre-computed and/or pre-signaled PE-to-PE segments, provider topology confidentiality may be preserved through the use of path key IDs [CONF-SEG].
事前に計算されたPE-To-PEセグメントおよび/または事前にシグナルのPE-To-PEセグメントの場合でも、PATHキーID [conf-seg]を使用することでプロバイダートポロジの機密性が保存される場合があります。
The customer's topology confidentiality cannot be completely hidden from the provider network. At the least, the provider network will know about the addresses and locations of CEs. Other customer topology information will remain hidden from the provider in the Basic Mode, although care may be needed to protect the customer control channel as described in Section 8.4.
顧客のトポロジの機密性は、プロバイダーネットワークから完全に隠すことはできません。少なくとも、プロバイダーネットワークは、CESのアドレスと場所について知っています。セクション8.4で説明されているように、顧客制御チャネルを保護するためには注意が必要になる場合がありますが、他の顧客トポロジ情報はプロバイダーから隠されたままです。
The provider network is responsible for maintaining confidentiality of topology information between customers and across L1VPNs. Since there is no distribution of routing information from PE to CE in the Basic Mode, there is no mechanism by which the provider could accidentally, or deliberately but automatically, distribute this information.
プロバイダーネットワークは、顧客間とL1VPN全体のトポロジー情報の機密性を維持する責任があります。基本モードでは、PEからCEへのルーティング情報の配布がないため、プロバイダーが誤って、または意図的に、しかし自動的にこの情報を配布できるメカニズムはありません。
The provider network is protected from direct control from within customer networks through policy and through filtering of signaling messages.
プロバイダーネットワークは、ポリシーとシグナリングメッセージのフィルタリングを通じて、顧客ネットワーク内からの直接制御から保護されています。
There is a service-based policy installed at each PE that directs how a PE should react to a L1VPN connection request received from any CE. Each CE is configured at the PE (or through a policy server) for its membership of a L1VPN, and so CEs cannot dynamically bind to a PE or join a L1VPN. With this configuration comes the policy that tells the PE how to react to a L1VPN connection request (for example, whether to allow dynamic establishment of PE-to-PE connections). Thus, the provider network is protected against spurious L1VPN connection requests and can charge for all L1VPN connections according to the service agreement with the customers. Hence, the provider network is substantially protected against denial-of-service (DoS) attacks.
PEがCEから受信したL1VPN接続要求にPEがどのように反応するかを指示する各PEにインストールされているサービスベースのポリシーがあります。各CEは、L1VPNのメンバーシップのためにPE（またはポリシーサーバーを介して）で構成されているため、CESはPEに動的にバインドしたり、L1VPNに参加したりすることはできません。この構成には、L1VPN接続要求に反応する方法をPEに伝えるポリシーがあります（たとえば、PE-PE接続の動的確立を許可するかどうか）。したがって、プロバイダーネットワークは、偽のL1VPN接続要求に対して保護されており、顧客とのサービス契約に従ってすべてのL1VPN接続に対して請求できます。したがって、プロバイダーネットワークは、サービス拒否（DOS）攻撃から実質的に保護されています。
At the same time, if a Path message from a CE contains an Explicit Route Object (ERO) specifying the route within provider network, it is rejected by the PE. Thus, the customer network has no control over the resources in the provider network.
同時に、CEからのパスメッセージに、プロバイダーネットワーク内のルートを指定する明示的なルートオブジェクト（ERO）が含まれている場合、PEによって拒否されます。したがって、顧客ネットワークは、プロバイダーネットワークのリソースを制御できません。
As described in [RFC4847], at Layer 1, data plane information is normally assumed to be secure once connections are established since the optical signals themselves are normally considered to be hard to intercept or modify, and it is considered difficult to insert data into an optical stream. The very use of an optical signal may be considered to provide confidentiality and integrity to the payload data. Furthermore, as indicated in [RFC4847], L1VPN connections are each dedicated to a specific L1VPN by which an additional element of security for the payload data is provided.
[RFC4847]で説明されているように、レイヤー1では、光信号自体は通常傍受または変更が難しく、データを挿入するのが難しいと考えられているため、接続が確立されると、データプレーン情報が確実に保護されると想定されています。光ストリーム。光信号のまさに使用は、ペイロードデータに機密性と完全性を提供するために考慮される場合があります。さらに、[RFC4847]に示されているように、L1VPN接続はそれぞれ、ペイロードデータのセキュリティの追加要素が提供される特定のL1VPN専用です。
Misconnection remains a security vulnerability for user data. If a L1VPN connection were to be misconnected to the wrong destination, user data would be delivered to the wrong consumers. In order to protect against mis-delivery, each L1VPN connection is restricted to use only within a single L1VPN. That is, a L1VPN connection does not connect CEs that are in different L1VPNs. In order to realize this, the identity of CEs is assured as part of the service contract. And upon receipt of a request for connection setup, the provider network assures that the connection is requested between CEs belonging to the same L1VPN. This is achieved as described in Section 5.3.
誤解は、ユーザーデータのセキュリティの脆弱性のままです。L1VPN接続が間違った宛先と間違えられている場合、ユーザーデータは間違った消費者に配信されます。誤配信から保護するために、各L1VPN接続は、単一のL1VPN内でのみ使用するように制限されています。つまり、L1VPN接続は、異なるL1VPNにあるCESを接続しません。これを実現するために、CESの身元はサービス契約の一部として保証されます。また、接続セットアップのリクエストを受信すると、プロバイダーネットワークは、同じL1VPNに属するCES間で接続が要求されることを保証します。これは、セクション5.3で説明されているように達成されます。
Furthermore, users with greater sensitivity to the security of their payload data should apply appropriate security measures within their own network layer. For example, a customer exchanging IP traffic over a L1VPN connection may choose to use IPsec to secure that traffic (i.e., to operate IPsec on the CE-to-CE exchange of IP traffic).
さらに、ペイロードデータのセキュリティに対して感度が高いユーザーは、独自のネットワークレイヤー内に適切なセキュリティ対策を適用する必要があります。たとえば、L1VPN接続でIPトラフィックを交換する顧客は、IPSECを使用してそのトラフィックを保護することを選択できます（つまり、IPトラフィックのCE-CEとCEとの交換でIPSECを操作する）。
There are two aspects for control plane security.
コントロールプレーンのセキュリティには2つの側面があります。
First, the entity connected over a CE-to-PE control channel must be identified. This is done when a new CE is added as part of the service contract and the necessary control channel is established. This identification can use authentication procedures available in RSVP-TE [RFC3209]. That is, control plane entities are identified within the core protocols used for signaling, but are not authenticated unless the authentication procedures of [RFC3209] are used.
まず、CE-To-PE制御チャネルに接続されているエンティティを特定する必要があります。これは、サービス契約の一部として新しいCEが追加され、必要な制御チャネルが確立されたときに行われます。この識別は、RSVP-TE [RFC3209]で利用可能な認証手順を使用できます。つまり、[RFC3209]の認証手順が使用されない限り、コントロールプレーンエンティティはシグナリングに使用されるコアプロトコル内で識別されますが、認証されません。
Second, it must be possible to secure communication over a CE-to-PE control channel. If a communication channel between the customer and the provider (control channel, management interface) is physically separate per customer, the communication channel could be considered as secure. However, when the communication channel is physically shared among customers, security mechanisms need to be available and should be enforced. RSVP-TE [RFC3209] provides for tamper-protection of signaling message exchanges through the optional Integrity object. IPsec tunnels can be used to carry the control plane messages to further ensure the integrity of the signaling messages.
第二に、CE-To-PEコントロールチャネルで通信を保護することが可能である必要があります。顧客とプロバイダー（コントロールチャネル、管理インターフェイス）の間の通信チャネルが顧客ごとに物理的に分離されている場合、通信チャネルは安全であると見なすことができます。ただし、通信チャネルが顧客間で物理的に共有されている場合、セキュリティメカニズムを利用できる必要があり、実施する必要があります。RSVP-TE [RFC3209]は、オプションの整合性オブジェクトを介したシグナリングメッセージ交換の改ざん防止を提供します。IPSECトンネルを使用して、制御プレーンメッセージを運ぶことができ、信号メッセージの完全性をさらに確保できます。
Note that even in the case of physically separate communication channels, customers may wish to apply security mechanisms, such as IPsec, to assure higher security, and such mechanisms must be available.
物理的に個別の通信チャネルの場合でも、顧客はIPSECなどのセキュリティメカニズムを適用して、より高いセキュリティを保証したい場合があり、そのようなメカニズムが利用可能でなければならないことに注意してください。
Furthermore, the provider network needs mechanisms to detect DoS attacks and to protect against them reactively and proactively. In the Basic Mode, this relies on management systems. For example, management systems collect and analyze statistics on signaling requests from CEs, and protect against malicious behaviors where necessary.
さらに、プロバイダーネットワークには、DOS攻撃を検出し、それらを反応的かつ積極的に保護するためのメカニズムが必要です。基本モードでは、これは管理システムに依存しています。たとえば、管理システムは、CESからのシグナリング要求に関する統計を収集および分析し、必要に応じて悪意のある行動から保護します。
Lastly, it should be noted that customer control plane traffic carried over the provider network between CEs needs to be protected. Such protection is normally the responsibility of the customer network and can use the security mechanisms of the customer signaling and routing protocols (for example, RSVP-TE [RFC3209]) or may use IPsec tunnels between CEs. CE-to-CE control plane security may form part of the data plane protection where the control plane traffic is carried in-band in the L1VPN connection. Where the CE-to-CE control plane connectivity is provided as an explicit part of the L1VPN service by the provider, control plane security should form part of the service agreement between the provider and customer.
最後に、CES間のプロバイダーネットワークを介して顧客制御飛行機のトラフィックを保護する必要があることに注意する必要があります。このような保護は通常、顧客ネットワークの責任であり、顧客のシグナリングおよびルーティングプロトコルのセキュリティメカニズム（たとえば、RSVP-TE [RFC3209]）を使用するか、CE間のIPSECトンネルを使用する場合があります。CE-CE-CE-CELYコントロールプレーンのセキュリティは、L1VPN接続で帯域内に制御プレーンのトラフィックが運ばれるデータプレーン保護の一部を形成する場合があります。プロバイダーによるL1VPNサービスの明示的な部分としてCE-CE-CE-CELY制御プレーンの接続が提供されている場合、コントロールプレーンのセキュリティは、プロバイダーと顧客の間のサービス契約の一部を形成する必要があります。
Manageability considerations are described in [RFC4847]. In the L1VPN Basic Mode, we rely on management systems for various aspects of the different service functions, such as fault management, configuration and policy management, accounting management, performance management, and security management (as described in Section 8).
管理可能性の考慮事項は[RFC4847]で説明されています。L1VPN基本モードでは、障害管理、構成とポリシー管理、会計管理、パフォーマンス管理、セキュリティ管理など、さまざまなサービス機能のさまざまな側面について、管理システムに依存しています（セクション8で説明）。
In order to support various management functionalities, MIB modules need to be supported. In particular, the GMPLS TE MIB (GMPLS-TE-STD-MIB) [RFC4802] can be used for GMPLS-based traffic engineering configuration and management, while the TE Link MIB (TE-LINK-STD-MIB) [RFC4220] can be used for configuration and management of TE links.
さまざまな管理機能をサポートするには、MIBモジュールをサポートする必要があります。特に、GMPLS TE MIB（GMPLS-TE-STD-MIB）[RFC4802]はGMPLSベースのトラフィックエンジニアリングの構成と管理に使用できますが、TE Link MIB（TE-Link-STD-MIB）[RFC4220]はできます。TEリンクの構成と管理に使用します。
[RFC3031] Rosen, E., Viswanathan, A. and R. Callon, "Multiprotocol label switching Architecture", RFC 3031, January 2001.
[RFC3031] Rosen、E.、Viswanathan、A。、およびR. Callon、「Multiprotocolラベルスイッチングアーキテクチャ」、RFC 3031、2001年1月。
[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トンネルのRSVPへの拡張」、RFC 3209、12月2001年。
[RFC3471] Berger, L., Ed., "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Functional Description", RFC 3471, January 2003.
[RFC3471] Berger、L.、ed。、「一般化されたマルチプロトコルラベルスイッチング（GMPLS）シグナル伝達機能説明」、RFC 3471、2003年1月。
[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月。
[RFC4026] Anderssion, L. and Madsen, T., "Provider Provisioned Virtual Private Network (VPN) Terminology", RFC 4026, March 2005.
[RFC4026] Anderssion、L。and Madsen、T。、「プロバイダープロビジョニング仮想プライベートネットワーク（VPN）用語」、RFC 4026、2005年3月。
[RFC4202] Kompella, K., Ed., and Y. Rekhter, Ed., "Routing Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS)", RFC 4202, October 2005.
[RFC4202] Kompella、K.、ed。、およびY. Rekhter、ed。、「一般化されたマルチプロトコルラベルスイッチング（GMPLS）をサポートするルーティング拡張機能」、RFC 4202、2005年10月。
[RFC4208] Swallow, G., Drake, J., Ishimatsu, H., and Y. Rekhter, "Generalized Multiprotocol Label Switching (GMPLS) User-Network Interface (UNI): Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Support for the Overlay Model", RFC 4208, October 2005.
[RFC4208] Swallow、G.、Drake、J.、Ishimatsu、H。、およびY. Rekhter、「一般化されたマルチプロトコルラベルスイッチング（GMPLS）ユーザーネットワークインターフェイス（UNI）：リソース予約プロトコルトラフィックエンジニアリング（RSVP-TE）オーバーレイモデルのサポート」、RFC 4208、2005年10月。
[RFC4847] Takeda, T., Ed., "Framework and Requirements for Layer 1 Virtual Private Networks", RFC 4847, April 2007.
[RFC4847] Takeda、T.、ed。、「レイヤー1仮想プライベートネットワークのフレームワークと要件」、RFC 4847、2007年4月。
[RFC4873] Berger, L., Bryskin, I., Papadimitriou, D., and A. Farrel, "GMPLS Segment Recovery", RFC 4873, May 2007.
[RFC4873] Berger、L.、Bryskin、I.、Papadimitriou、D。、およびA. Farrel、「Gmplsセグメントリカバリー」、RFC 4873、2007年5月。
[RFC5195] Ould-Brahim, H., Fedyk, D., and Y. Rekhter, "BGP-Based Auto-Discovery for Layer-1 VPNs", RFC 5195, June 2008.
[RFC5195] Oould-Brahim、H.、Fedyk、D。、およびY. Rekhter、「Layer-1 VPNSのBGPベースの自動分類」、RFC 5195、2008年6月。
[RFC5251] Fedyk, D., Ed., Rekhter, Y., Ed., Papadimitriou, D., Rabbat, R., and L. Berger, "Layer 1 VPN Basic Mode", RFC 5251, July 2008.
[RFC5251] Fedyk、D.、ed。、Rekhter、Y.、ed。、Papadimitriou、D.、Rabbat、R。、およびL. Berger、「レイヤー1 VPN基本モード」、RFC 5251、2008年7月。
[RFC5252] Bryskin, I. and Berger, L., "OSPF-Based Layer 1 VPN Auto-Discovery", RFC 5252, July 2008.
[RFC5252] Bryskin、I。およびBerger、L。、「OSPFベースのレイヤー1 VPN自動発見」、RFC 5252、2008年7月。
[RFC4204] Lang, J., Ed., "Link Management Protocol (LMP)", RFC 4204, October 2005.
[RFC4204] Lang、J.、ed。、「Link Management Protocol（LMP）」、RFC 4204、2005年10月。
[RFC4206] Kompella, K. and Y. Rekhter, "Label Switched Paths (LSP) Hierarchy with Generalized Multi-Protocol Label Switching (GMPLS) Traffic Engineering (TE)", RFC 4206, October 2005.
[RFC4206] Kompella、K。およびY. Rekhter、「一般化されたマルチプロトコルラベルスイッチング（GMPLS）トラフィックエンジニアリング（TE）を備えたラベルスイッチ付きパス（LSP）階層」、2005年10月。
[RFC4220] Dubuc, M., Nadeau, T., and J. Lang, "Traffic Engineering Link Management Information Base", RFC 4220, November 2005.
[RFC4220] Dubuc、M.、Nadeau、T。、およびJ. Lang、「トラフィックエンジニアリングリンク管理情報ベース」、RFC 4220、2005年11月。
[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月。
[RFC4802] Nadeau, T., Ed., and A. Farrel, Ed., "Generalized Multiprotocol Label Switching (GMPLS) Traffic Engineering Management Information Base", RFC 4802, February 2007.
[RFC4802] Nadeau、T.、ed。、およびA. Farrel、ed。、「一般化されたマルチプロトコルラベルスイッチング（GMPLS）トラフィックエンジニアリング管理情報ベース」、RFC 4802、2007年2月。
[RFC5063] Satyanarayana, A., Ed., and R. Rahman, Ed., "Extensions to GMPLS Resource Reservation Protocol (RSVP) Graceful Restart", RFC 5063, October 2007.
[RFC5063] Satyanarayana、A.、ed。、およびR. Rahman、ed。、「GMPLSリソース予約プロトコル（RSVP）Graceful Restartへの拡張」、RFC 5063、2007年10月。
[BGP-TE] Ould-Brahim, H., Fedyk, D., and Y. Rekhter, "Traffic Engineering Attribute", Work in Progress, January 2008.
[BGP-TE] Oould-Brahim、H.、Fedyk、D。、およびY. Rekhter、「Traffic Engineering属性」、2008年1月、進行中の作業。
[CONF-SEG] Bradford, R., Ed., Vasseur, JP., and A. Farrel, "Preserving Topology Confidentiality in Inter-Domain Path Computation Using a Key-Based Mechanism", Work in Progress, May 2008.
[conf-seg] Bradford、R.、ed。、vasseur、JP。、およびA. Farrel、「キーベースのメカニズムを使用したドメイン間パス計算におけるトポロジの機密性の保存」、2008年5月の作業。
[GMPLS-SEC] Fang, L., Ed., " Security Framework for MPLS and GMPLS Networks", Work in Progress, February 2008.
[GMPLS-SEC] Fang、L.、ed。、「MPLSおよびGMPLSネットワークのセキュリティフレームワーク」、2008年2月、Work in Progress。
The authors would like to thank Ichiro Inoue for valuable comments. In addition, the authors would like to thank Marco Carugi and Takumi Ohba for valuable comments in the early development of this document.
著者は、貴重なコメントをしてくれた井上に感謝したいと思います。さらに、著者は、この文書の初期の開発における貴重なコメントについて、Marco CarugiとTakumi Ohbaに感謝したいと思います。
Thanks to Tim Polk and Mark Townsley for comments during IESG review.
IESGレビュー中のコメントについては、Tim PolkとMark Townsleyに感謝します。
Authors' Addresses
著者のアドレス
Tomonori Takeda (editor) NTT Network Service Systems Laboratories, NTT Corporation 3-9-11, Midori-Cho Musashino-Shi, Tokyo 180-8585 Japan Phone: +81 422 59 7434 EMail: takeda.tomonori@lab.ntt.co.jp
Tomonori Takeda（編集者）NTTネットワークサービスシステムLaboratories、NTT Corporation 3-9-11、Midori-Cho Musashino-Shi、Tokyo 180-8585日本電話：81 422 59 7434電子メール：Takeda.tomonori@lab.ntt.co.jp
Deborah Brungard AT&T Rm. D1-3C22 - 200 S. Laurel Ave. Middletown, NJ 07748, USA Phone: +1 732 4201573 EMail: dbrungard@att.com
デボラ・ブランガードAT＆T RM。D1-3C22-200 S.ローレルアベニューミドルタウン、ニュージャージー州07748、米国電話：1 732 4201573メール：dbrungard@att.com
Adrian Farrel Old Dog Consulting Phone: +44 (0) 1978 860944 EMail: adrian@olddog.co.uk
Adrian Farrel Old Dog Consulting電話：44（0）1978 860944メール：adrian@olddog.co.uk
Hamid Ould-Brahim Nortel Networks P O Box 3511 Station C Ottawa, ON K1Y 4H7 Canada Phone: +1 (613) 765 3418 EMail: hbrahim@nortel.com
Hamid Old-Brahim Nortel Networks P O Box 3511 Station C Ottawa、on K1y 4H7カナダ電話：1（613）765 3418メール：hbrahim@nortel.com
Dimitri Papadimitriou Alcatel-Lucent Francis Wellensplein 1, B-2018 Antwerpen, Belgium Phone: +32 3 2408491 EMail: dimitri.papadimitriou@alcatel-lucent.be
Dimitri Papadimitriou Alcatel-Lucent Francis Wellensplein 1、B-2018 Antwerpen、Belgium電話：32 3 2408491メール：dimitri.papadimitriou@alcatel-lucent.be
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2008).
著作権（c）The IETF Trust（2008）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
この文書は、BCP 78に含まれる権利、ライセンス、および制限の対象となり、そこに記載されている場合を除き、著者はすべての権利を保持しています。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供され、貢献者、彼/彼女が代表する組織（もしあれば）、インターネット協会、IETFトラスト、インターネットエンジニアリングタスクフォースがすべてを否認します。明示的または黙示的な保証。ここでの情報の使用は、特定の目的に対する商品性または適合性の権利または暗黙の保証を侵害しないという保証を含むがこれらに限定されない。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、知的財産権またはその他の権利の有効性または範囲に関して、本書に記載されている技術の実装または使用、またはそのような権利に基づくライセンスに基づくライセンスの範囲に関連すると主張される可能性のある他の権利に関しては、立場を取得しません。利用可能になります。また、そのような権利を特定するために独立した努力をしたことも表明していません。RFCドキュメントの権利に関する手順に関する情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得しようとする試みの結果を取得できます。http://www.ietf.org/iprのIETFオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、関心のある当事者に、著作権、特許、または特許出願、またはこの基準を実装するために必要な技術をカバーする可能性のあるその他の独自の権利を注意深く招待するよう招待しています。ietf-ipr@ietf.orgのIETFへの情報をお問い合わせください。