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
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).
このドキュメントでは、基本モードレイヤ1個の仮想プライベートネットワーク（L1VPNs）をサポートするために一般化マルチプロトコルラベルスイッチング（GMPLS）プロトコルとメカニズムの使用上の適用性声明を提供します。
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.
L1VPNsは、レイヤ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個の仮想プライベートネットワーク（L1VPNs）一般マルチプロトコルラベルの使用に適用可能ステートメントを提供します。
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 L1VPN接続（RFC 4847で、すなわち、CE-に-CE VPN接続）CEおよびPE間GMPLSシグナリングによって設定し、その後、プロバイダネットワークを介しています。 L1VPN接続が同じL1VPNに属するCE間の接続に制限されています。
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に、ルーティングは、プロバイダネットワーク内で動作することに留意されたいです。また、ルーティングは、プロバイダネットワーク（例えば、会員情報）によって支持L1VPNsに固有の情報を交換するためのPEによって使用されてもよいことに留意されたいです。
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基本モードでは、プロバイダネットワークは、プロバイダの制御下に完全にあります。これは、プロバイダ（PE-に-PEセグメント制御）により制御し、計算されたCE-に-CE L1VPN接続のPE対PEセグメントを含みます。一方、CEとプロバイダによって提供されるL1VPN接続のセットから構築L1VPN自体は、各顧客の制御下にあります。この制御は、顧客が接続（トポロジ制御）が確立されるべきCEの間で要求することができることを含みます。顧客は、プロバイダ自体に含め、第三者にそのL1VPNの管理を外部委託することがあります。プロバイダと各顧客の間で機密性の要件があります。
[RFC5251], which extends [RFC4208], specifies GMPLS signaling to establish CE-to-CE L1VPN connections.
[RFC4208]を延びている[RFC5251]は、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、に基づいてPE間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）、またはフォトニッククロスコネクト（PXCs）などのレイヤ1スイッチを、任意の種類から構成することができます。さらに、PEは、マップイーサネット（等、TDMオーバーイーサネット（登録商標）を用いて）層の上に1つの接続フレームいること、デバイスのイーサネット専用回線（EPL）タイプであってもよいです。プロバイダネットワークは、単一のスイッチング粒度（例えば、のみ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は、一つ以上のリンクにより接続されています。 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、または複数L1VPNsに属していてもよい、およびPEは、単一のCEを介して、または複数のCEを介して1つまたは複数のL1VPNsをサポートすることができます。
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基本モードプロバイダーのネットワークは、この文書の範囲内で、単一のASに限定されています。マルチAS基本モードL1VPNs今後の検討課題です。
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は、少なくとも一つの制御チャネルによって接続する必要があります。 CEおよびCE-に-PEの関係が複数のL1VPNにも適用可能である場合、PE間で交換される制御プレーンのメッセージを明確にする必要があります。これはL1VPNような制御プレーンメッセージが適用されるかを決定することが可能になります。そのような曖昧性除去は、（別々の物理チャネル、例えばIPトンネルのような別個の論理チャネルを使用して、またはアドレッシング別のいずれかを使用して）各L1VPNに別個の制御チャネルを割り当てることによって達成することができます。
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基本モードが重複するレルムをアドレッシングCEツーPE制御チャネルを可能にします。つまり、CEツーPE制御チャネルアドレスである（この制御チャネルと、この制御チャンネルのPEのアドレスのCEのアドレス）は、CE-に-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基本モードは、顧客のネットワーク動作のため、このL1VPN接続（リンクとして扱われる）（例えば、IPネットワーク、MPLSネットワーク）のためのアドレス割り当ての任意の制限を強制しません。
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上の少なくとも一つの顧客向けのポートを有し、各L1VPNのために、PEはそのL1VPNに関連付けられたポート情報テーブル（PIT）を維持します。 PITは、顧客ポート指数（のCPI）及びプロバイダポート指数（のPPI）との間の相互参照を提供し、L1VPN内のすべてのポートの<CPI、PPI>タプルのリストを含みます。加えて、所与L1VPNのローカルPEポートのため、PEはVPN-PPIとして知られている識別子を保持し、これは<CPI、PPI>タプルとPITに格納されています。
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:
一つ以上のL1VPNsに属する新しいCEがPEに追加されたときに、それらL1VPNsに関連する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.
- 何PITは、PE上のL1VPNために存在しない場合、新しいPITは、プロバイダによって作成され、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.
- （新規又は既存）PITは、新しく追加された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に関連付けられたリモートPIT情報ピットが新たに作成されている場合、この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.
L1VPNの既存のCEの変化のメンバーシップ、または場合は、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-に-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-に-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-に-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
- ポリシー1：オンデマンド確立、オンデマンド経路計算 - ポリシー2：オンデマンド確立、事前計算経路 - ポリシー3：事前確立、事前計算経路
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).
各ポリシーでは、PE-に-PEのパスはローカル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からPathメッセージを受信した場合、PEは、PE-TO-PEセグメントを使用するかを決定する必要があります。このような場合には、プロバイダが制御したいことがあります。
- 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ツーCE L1VPN接続たPE-に-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:
前者はPITおよびPEからPEセグメントとの間のマッピングを必要とします。後者は、例えば、いくつかのより洗練されたマッピング方法が必要です。
- 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.
- 個々PITエントリとPE-に-PEセグメントとの間のマッピング。 - パスキーID [CONF-SEG]の使用は、CEのプロバイダによって供給され、L1VPN接続要求の一部として、CEによって合図します。
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において、縫合またはネスティングは、予め確立されたPE-に-PEセグメントのCEツーCE L1VPN接続をマッピングするために必要です。
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.
たとえば、プロバイダが異なるL1VPNsまたは顧客が限定された使用のためのプロバイダーネットワークのリソースを分割することもできます。このような機能は、リソースの親和性[RFC3209]を使用して、基本モードの範囲内で達成されるかもしれないが、（特にCEツーPEルーティングに関して）ごとL1VPNリソース・モデルの詳細は、拡張モードの一部とみなされます。
[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ツーPEトラフィックエンジニアリング（TE）リンク情報は、プロバイダネットワークに注入される、特にPE間で交換されます。これは、リソースまたはリモートCEツーPE TEリンクの互換性のないスイッチング機能の欠如に接続設定の失敗を防ぐために、イングレス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基本モードは、リモートCEが同じPE（シングルホーム）または（デュアルホーム）異なるPEに接続された複数のTEリンクを介して到達することを可能にします。そのような場合には、経路選択を容易にするために、入口CEは出口CEのルータID、ない出口CPIを指定することにより、シグナル伝達を開始する必要がある、セッションオブジェクトと明示的ルート・オブジェクト（ERO）は、存在する場合、拘束しないようにプロバイダーネットワーク内の経路の選択。そのため、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でPITを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ツーPE TEリンクが（シングルホームまたはマルチホーム）がある場合、顧客は任意L1VPN接続をサポートするために使用するCEツーPE TEリンクを指定することができることに留意されたいです。あるいは、顧客は、セクション5.2.3で説明したように、プロバイダは、出口側のCEツーPE 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 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ネットワークを動作させるために顧客によって使用されている場合さらに、顧客は、TEリンクとしてL1VPN接続を処理したい場合があり、これはCE-に-CE制御チャネルを必要とします。 CEとPEの間にルーティング交換がないため、転送隣接[RFC4206]は基本モードでCE対CE L1VPN接続から形成することができないことに留意されたいです。つまり、顧客ネットワークとルーティングインスタンスを共有していないプロバイダネットワーク、および顧客制御チャネルは、プロバイダの制御プレーン内に行うことができません。しかし、CEは、（顧客ネットワークは、MPLS又はGMPLSネットワークのパケット交換切り替えられる例えば、）適切な適合を提供する場合、顧客制御チャネルは、帯域内であってもよく、ルーティング隣接はL1VPN接続を使用してCEの間に形成されてもよいです。そうでなければ、CE-に-CE制御プレーン接続は、プロバイダによって顧客に提供L1VPNサービスの一部を形成してもよいし、（例えば、オーバーヘッド・バイトの使用を介して）または専用制御チャネル接続を介してL1VPN接続内で達成することができますまたはトンネル。利用可能なオプションは、[RFC4847]のセクション10.2でさらに議論されています。
There are several factors that impact scalability.
スケーラビリティに影響を与えるいくつかの要因があります。
o Number of L1VPNs (PITs) configured on each PE
各PEに設定さL1VPNs（ピット）のO数
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増加に維持することができます。理論的には、プロバイダ・ネットワークでサポートL1VPNsの数の上限はL1VPNに関連付けられたIDが割り当てられている方法によって支配され、各PEに設定さのピットの数は、この数によって制限されます。しかし、実装は任意の1つのPEによってサポートされたピットの数の任意の制限を課すことができます。
o Number of CE-to-PE TE links for each L1VPN
各L1VPN用CEツーPE TEリンクのO数
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]はPEの間で、だけでなく、すべてのPノードにだけでなく、メンバーシップ情報をフラッディングすることに注意してください。これが唯一のPE間メンバーシップ情報を配信する[RFC5195]に比べて、スケーラビリティの問題につながる可能性があります。あるいは、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のみCEツーPE TEリンク情報を取得する必要はなく、顧客にL3VPNの動作モードとは全く異なる情報をルーティングすることに注意してください。そのため、拡張性の懸念はあまり問題があると考えられています。
o Number of L1VPN connections
L1VPN接続のO数
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.
各LSPは、直接物理的、切り替え可能なリソース（タイムスロット、ラムダ、またはファイバ）に結合された別個のラベルを使用するためしかし、レイヤ1コアで、この数は常に使用可能な物理リソースによって制限されます。したがって、安全のPE / Psが快適に彼らはL1VPNのために切り替えることで呼び出すことができLSPの数を扱うことができると想定することができます。
The L1VPN Basic Mode supports the following data plane recovery techniques [RFC5251].
L1VPN基本モードは、次のデータ・プレーン・回収技術[RFC5251]をサポートしています。
o PE-to-PE segment recovery
PE-に-PEセグメント回復
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は、Pathメッセージに[RFC4873]で指定された保護対象を含むとセグメント回復フラグを設定することにより、PE-に-PEセグメントを保護することを示しています。 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-に-PEセグメントを保護する方法の詳細は異なっていてもよいです。
- 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対PEセグメントのプロビジョニングに使用される場合、PE対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 L1VPNの接続（セッションシャフリングを使用する場合を含む）は、単一のエンドツーエンドのLSPである場合、PE対PE LSPセグメントはセグメント保護[RFC4873]を使用して保護されていてもよいです。
o CE-to-PE recovery and PE-to-PE recovery via link protection
リンク保護を介したO CEツー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]で指定された保護対象を含むとPathメッセージ内のリンクフラグを設定することにより、入力および出力CEツー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-に-PEルーティングを行うことができるように、PE-に-PEセグメントが単一のTEリンク（ステッチまたは階層）として提供される場合には、TEリンクはのインスタンスを介してリンクレベルの保護を提供することができます複数のPE-に-PEのLSP。
- The PE-to-PE segment may be provisioned using only link-protected links within the core network.
- PE-に-PEセグメントは、コアネットワーク内のリンクのみ保護リンクを使用してプロビジョニングすることができます。
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ツーPE部分又はPE-に-PE部分を保護することは不可能であることに注意してくださいLSP。また、リンクの回復と同時に、セグメントの回復によるPE-に-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.
多様のPE（すなわち、デュアルホーミング）への1つのCEからの接続を使用して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間、並びにプロバイダネットワーク内の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オブジェクトを受信したときに、自身のアドレスをノードアドレスを通知更新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対PEセグメントの場合、プロバイダ・トポロジの機密性のパス鍵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.
顧客のトポロジの機密性、完全プロバイダーネットワークから隠すことはできません。少なくとも、プロバイダーネットワークは、CEの住所や場所を知っているだろう。 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.
プロバイダーネットワークは、顧客の間でL1VPNs全体トポロジー情報の機密性を維持する責任があります。基本モードでのCEにPEからルーティング情報のない分布がないため、プロバイダが誤って、または故意なく自動的に、この情報を配布する可能性があることでメカニズムはありません。
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にインストールされたサービスベースのポリシーがあります。各CEはL1VPNのそのメンバーシップPE（またはポリシーサーバを介して）で構成され、従ってCEは動的にPEに結合するかL1VPNに参加できません。この構成ではPEがどのように（PE-に-PE接続の動的確立を許可するかどうか、など）L1VPN接続要求に反応するように指示ポリシー来ます。このように、プロバイダ・ネットワークは、スプリアス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からのPathメッセージは、プロバイダネットワーク内の経路を指定する明示的ルート・オブジェクト（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
[RFC4847]に記載されているように、光信号自体は正常に傍受または変更することは困難であると考えられ、データを挿入することが困難であると考えられるので、レイヤ1で、データプレーン情報は、通常、接続が確立されると安全であると仮定されます光学流れ。光信号の非常に使用がペイロードデータに機密性と完全性を提供すると考えることができます。さらに、[RFC4847]に示されるように、L1VPN接続があります
each dedicated to a specific L1VPN by which an additional element of security for the payload data is provided.
各ペイロードデータに対するセキュリティの付加的な要素が提供される特定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接続は異なるL1VPNsにあるのCEを接続していないされています。これを実現するためには、CEのアイデンティティは、サービス契約の一部として確保されています。そして、接続設定の要求を受けると、プロバイダのネットワーク接続が同じL1VPNに属するCEの間で要求されることを保証します。 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トラフィックを交換顧客（すなわち、IPトラフィックのCE-に-CE交換にIPsecを動作させるために）そのトラフィックを保護するために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ツー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ツー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攻撃を検出すると、反応性と積極的にそれらから保護するためのメカニズムを必要とします。基本モードでは、これは、管理システムに依存しています。例えば、管理システムが収集したCEからのシグナリング要求の統計を分析し、必要な場合には、悪質な行為から保護します。
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.
最後に、CE間プロバイダーネットワーク上で搬送される顧客のコントロールプレーントラフィックを保護する必要があることに留意すべきです。このような保護は、通常、顧客のネットワークの責任であると（例えば、RSVP-TE [RFC3209]）顧客シグナリングおよびルーティングプロトコルのセキュリティメカニズムを使用するかのCE間のIPsecトンネルを使用することができます。 CE-に-CEコントロールプレーンのセキュリティは、制御プレーントラフィックはL1VPN接続でインバンド運ばれるデータプレーン保護の一部を形成してもよいです。 CE-に-CE制御プレーン接続がプロバイダによってL1VPNサービスの明示的な一部として提供される場合、コントロールプレーンのセキュリティプロバイダと顧客との間のサービス契約の一部を形成しなければなりません。
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モジュールをサポートする必要があります。缶TEリンクMIB（TE-LINK-STD-MIB）[RFC4220]ながら具体的には、GMPLS TE MIB（GMPLS-TE-STD-MIB）[RFC4802]は、GMPLSベースのトラフィックエンジニアリングの構成および管理のために使用することができますTEリンクの設定と管理のために使用されます。
[RFC3031] Rosen, E., Viswanathan, A. and R. Callon, "Multiprotocol label switching Architecture", RFC 3031, January 2001.
[RFC3031]ローゼン、E.、Viswanathanの、A.とR. Callon、 "マルチプロトコルラベルスイッチングアーキテクチャ"、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.、バーガー、L.、ガン、D.、李、T.、スリニヴァサン、V.、およびG.ツバメ、 "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]バーガー、L.、エド。は、 "一般化マルチプロトコルラベルスイッチング（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]バーガー、L.、エド、 "一般化マルチプロトコルラベルスイッチング（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.とマドセン、T.、 "プロバイダプロビジョニングされた仮想プライベートネットワーク（VPN）用語"、RFC 4026、2005月。
[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.、エド。、およびY. Rekhter、エド。、 "ルーティング拡張一般マルチプロトコルラベルスイッチング（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]ツバメ、G.、ドレイク、J.、石松、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]武田、T.、エド。、 "フレームワークおよびレイヤ1つの仮想プライベートネットワークの要件"、RFC 4847、2007年4月。
[RFC4873] Berger, L., Bryskin, I., Papadimitriou, D., and A. Farrel, "GMPLS Segment Recovery", RFC 4873, May 2007.
[RFC4873]バーガー、L.、Bryskin、I.、Papadimitriou、D.、およびA.ファレル、 "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]ウルド - Brahimの、H.、Fedyk、D.、およびY. Rekhter、 "BGPベースの自動検出のためのレイヤ1のVPN"、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.、エド。、Rekhter、Y.、エド。、Papadimitriou、D.、Rabbat、R.、およびL.バーガー、 "レイヤ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.およびバーガー、L.、 "OSPFベースのレイヤ1 VPN自動検出"、RFC 5252、2008年7月。
[RFC4204] Lang, J., Ed., "Link Management Protocol (LMP)", RFC 4204, October 2005.
[RFC4204]ラング、J.、エド。、 "リンク管理プロトコル（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は、RFC 4206、2005年10月 "ラベル・パス（LSP）の階層は、一般マルチプロトコルラベルスイッチング（GMPLS）トラフィックエンジニアリング（TE）との交換しました"。
[RFC4220] Dubuc, M., Nadeau, T., and J. Lang, "Traffic Engineering Link Management Information Base", RFC 4220, November 2005.
[RFC4220] Dubuc、M.、ナドー、T.、およびJ.ラング、 "トラフィックエンジニアリングリンク管理情報ベース"、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]ファレル、A.、Vasseur、J.-P.、およびJ.アッシュ、 "パス計算要素（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]ナドー、T.、エド。、およびA.ファレル、エド。、 "一般化マルチプロトコルラベルスイッチング（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.編、およびR.ラーマン、エド。、RFC 5063、2007年10月、 "GMPLSリソース予約プロトコル（RSVP）グレースフルリスタートへの拡張"。
[BGP-TE] Ould-Brahim, H., Fedyk, D., and Y. Rekhter, "Traffic Engineering Attribute", Work in Progress, January 2008.
[BGP-TE]ウルド - Brahimの、H.、ルブラン、D.、およびY. Rekhterは、 "トラフィックエンジニアリング属性"、進歩、2008年3月での作業。
[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]ブラッドフォード、R.、エド。、Vasseur、JP。、およびA.ファレル、進歩、2008年5月で、ワーク "キーベースのメカニズムを使用したドメイン間の経路計算で保存トポロジ守秘義務"。
[GMPLS-SEC] Fang, L., Ed., " Security Framework for MPLS and GMPLS Networks", Work in Progress, February 2008.
[GMPLS-SEC]牙、L.、エド。、 "MPLSおよびGMPLSネットワークのセキュリティフレームワーク"、進歩、2008年2月に作業。
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.
著者は、貴重なコメントのための井上一郎に感謝したいと思います。また、作者はこのドキュメントの初期の開発における貴重なコメントのためにマルコCarugiと匠大場に感謝したいと思います。
Thanks to Tim Polk and Mark Townsley for comments during IESG review.
IESGレビュー中のコメントのためのティムポーク、マーク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 (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
Deborah Brungard AT&T Rm. D1-3C22 - 200 S. Laurel Ave. Middletown, NJ 07748, USA Phone: +1 732 4201573 EMail: dbrungard@att.com
デボラBrungard AT＆T Rmの。 D1-3C22 - 200 S.ローレルアベニュー。ミドルタウン、NJ 07748、USA電話：+1 732 4201573 Eメール：dbrungard@att.com
Adrian Farrel Old Dog Consulting Phone: +44 (0) 1978 860944 EMail: adrian@olddog.co.uk
エードリアンファレル老犬のコンサルティング電話：+44（0）1978 860944 Eメール：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
K1Y 4H7カナダの携帯電話にハミド・ウルド・BrahimのNortel NetworksのP Oボックス3511駅のCオタワ、：+1（613）765 3418 Eメール：hbrahim@nortel.com
Dimitri Papadimitriou Alcatel-Lucent Francis Wellensplein 1, B-2018 Antwerpen, Belgium Phone: +32 3 2408491 EMail: dimitri.papadimitriou@alcatel-lucent.be
ディミトリPapadimitriouアルカテルLykentフランシスVellensplein 1 B-2018アントワープ、Velgiomボイス：X2 + 3 2408491メールアドレス：δημήτρη.παπαδημητρίου@αλκατελ-λυκεντ.βε
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2008).
著作権（C）IETFトラスト（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.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットSOCIETY、（もしあれば）を後援し、IETF TRUST ANDインターネットエンジニアリングタスクフォース放棄ALLに設けられています。保証は、明示または黙示、この情報の利用および特定目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証がこれらに限定されません。
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.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができます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に情報を記述してください。