Network Working Group T. Takeda, Ed.
Request for Comments: 4847 NTT
Category: Informational April 2007
Framework and Requirements for Layer 1 Virtual Private Networks
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.
このメモはインターネットコミュニティのための情報を提供します。それはどんな種類のインターネット標準を指定しません。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The IETF Trust (2007).
著作権（C）IETFトラスト（2007）。
Abstract
抽象
This document provides a framework and service level requirements for Layer 1 Virtual Private Networks (L1VPNs). This framework is intended to aid in developing and standardizing protocols and mechanisms to support interoperable L1VPNs.
この文書では、レイヤ1仮想プライベートネットワーク（L1VPNs）のためのフレームワークとサービスレベルの要件を提供します。このフレームワークは、相互運用可能L1VPNsをサポートするためのプロトコルやメカニズムを開発し、標準化を支援することを意図しています。
The document examines motivations for L1VPNs, high level (service level) requirements, and outlines some of the architectural models that might be used to build L1VPNs.
文書はL1VPNs、ハイレベル（サービスレベル）の要件のための動機を調べて、L1VPNsを構築するために使用されるかもしれない建築モデルのいくつかを概説します。
Table of Contents
目次
1. Introduction ....................................................3
2. Terminology .....................................................3
3. Overview ........................................................5
3.1. Network Topology ...........................................5
3.2. Introducing Layer 1 VPNs ...................................5
3.3. Current Technologies for Dynamic Layer 1 Provisioning ......6
3.4. Relationship with ITU-T ....................................7
4. Motivations .....................................................8
4.1. Basic Layer 1 Services .....................................8
4.1.1. L1VPN for Dynamic Layer 1 Provisioning ..............9
4.2. Merits of L1VPN ............................................9
4.2.1. Customer Merits .....................................9
4.2.2. Provider Merits ....................................10
4.3. L1VPN Deployment Scenarios ................................10
4.3.1. Multi-Service Backbone .............................11
4.3.2. Carrier's Carrier ..................................11
4.3.3. Layer 1 Resource Trading ...........................12
4.3.4. Inter-AS and Inter-SP L1VPNs .......................12
4.3.5. Scheduling Service .................................13
5. Reference Model ................................................14
5.1. Management Systems ........................................15
6. Generic Service Description ....................................15
6.1. CE Construct ..............................................15
6.2. Generic Service Features ..................................16
7. Service Models .................................................16
7.1. Management-Based Service Model ............................17
7.2. Signaling-Based Service Model (Basic Mode) ................17
7.2.1. Overlay Service Model ..............................18
7.3. Signaling and Routing Service Model (Enhanced Mode) .......19
7.3.1. Overlay Extension Service Model ....................20
7.3.2. Virtual Node Service Model .........................20
7.3.3. Virtual Link Service Model .........................21
7.3.4. Per-VPN Peer Service Model .........................22
8. Service Models and Service Requirements ........................22
8.1. Detailed Service Level Requirements .......................24
9. Recovery Aspects ...............................................25
9.1. Recovery Scope ............................................25
9.2. Recovery Resource Sharing Schemes .........................26
10. Control Plane Connectivity ....................................27
10.1. Control Plane Connectivity between a CE and a PE .........27
10.2. Control Plane Connectivity between CEs ...................28
11. Manageability Considerations ..................................29
12. Security Considerations .......................................31
12.1. Types of Information .....................................32
12.2. Security Features ........................................32
12.3. Scenarios ................................................33
13. Acknowledgements ..............................................34
14. Contributors ..................................................34
15. Normative References ..........................................35
16. Informative References ........................................35
This document examines motivations for Layer 1 Virtual Private Networks (L1VPNs), provides high-level (service-level) requirements, and outlines some of the architectural models that might be used to build L1VPNs.
この文書では、レイヤ1個の仮想プライベートネットワーク（L1VPNs）のための動機を調べてハイレベル（サービスレベル）の要件を提供し、L1VPNsを構築するために使用されるかもしれない建築モデルのいくつかを概説します。
The objective of the document is mainly to present the requirements and architecture based on the work undertaken within Question 11 of Study Group 13 of the ITU-T.
文書の目的は、ITU-Tの研究グループ13の質問11内で行われ、作業に基づく要件とアーキテクチャを提示する主な理由です。
L1VPNs provide services over layer 1 networks. This document provides a framework for L1VPNs and the realization of the framework by those networks being controlled by Generalized Multi-Protocol Label Switching (GMPLS) protocols.
L1VPNsは、レイヤ1つのネットワーク上でサービスを提供しています。この文書では、一般化マルチプロトコルラベルスイッチング（GMPLS）プロトコルによって制御されているこれらのネットワークによってL1VPNsためのフレームワークとフレームワークの実現を提供します。
Use of GMPLS protocols for providing L1VPN services has several advantages, such as:
L1VPNサービスを提供するためのGMPLSプロトコルの使用は、次のようないくつかの利点があります：
- Flexible network operation.
- 柔軟なネットワーク操作。
- Use of standardized protocols.
- 標準化されたプロトコルを使用します。
- Use of common control and measurement plane protocols applicable to various layer 1 networks, including Time Division Multiplexing (TDM) networks and optical networks.
- 時分割多重（TDM）ネットワーク及び光ネットワークを含む様々な層1つのネットワークに適用共通の制御と測定プレーンプロトコルの使用。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はあります[RFC2119]に記載されているように解釈されます。
The reader is assumed to be familiar with the terminology in [RFC3031], [RFC3209], [RFC3471], [RFC3473], [RFC4202], [RFC3945], [RFC4208], and [RFC4026].
読者は、[RFC3031]、[RFC3209]、[RFC3471]、[RFC3473]、[RFC4202]、[RFC3945]、[RFC4208]及び[RFC4026]における用語に精通していると仮定されます。
In this context, a Layer 1 Network is any transport network that has connectivity and/or switching using spatial switching (e.g., incoming port or fiber to outgoing port or fiber), lambda-switching, or time-division-multiplex-switching.
この文脈では、レイヤ1のネットワークは、任意の接続性を有し、かつ/または空間スイッチング（出力ポートまたはファイバ例えば、着信ポートまたはファイバ）を用いたスイッチングトランスポートネットワーク、ラムダスイッチング、または時分割多重化スイッチングあります。
A Layer 1 VPN (L1VPN) is a service offered by a core layer 1 network to provide layer 1 connectivity between two or more customer sites, and where the customer has some control over the establishment and type of the connectivity. An alternative definition is simply to say that an L1VPN is a VPN whose data plane operates at layer 1. Further details of the essence of an L1VPN are provided in Section 3.
レイヤ1 VPN（L1VPN）は、二つ以上の顧客サイトとの間のレイヤ1接続性を提供するために、コア層1のネットワークによって提供されるサービスであり、顧客は、接続の確立および種類をある程度制御を有します。別の定義がL1VPNは、そのデータプレーン動作層でL1VPNの本質1.さらなる詳細はセクション3に設けられているVPNがあると言うことは、単純です。
In addition, the following new terms are used within this document:
また、次の新しい用語が本文書内で使用されています。
- Virtual link: A provider network Traffic Engineering (TE) link advertised to customers in routing information for purposes that include path computation. A direct data link may or may not exist between the two end points of a virtual link.
- 仮想リンク：経路計算を含める目的で情報をルーティングの顧客に宣伝プロバイダーネットワークトラフィックエンジニアリング（TE）リンク。直接データリンクまたは仮想リンクの両端点の間に存在してもしなくてもよいです。
- Virtual node: A provider network logical node advertised to customers in routing information. A virtual node may represent a single physical node, or multiple physical nodes and the links between them.
- 仮想ノード：ルーティング情報をの顧客に宣伝プロバイダーネットワークの論理ノード。仮想ノードは、単一の物理ノード、または複数の物理ノードとそれらの間のリンクを表すことができます。
- VPN end point: A Customer Edge (CE) device's data plane interface, which is connected to a Provider Edge (PE) device, and which is part of the VPN membership. Note that a data plane interface is associated with a TE link end point. For example, if a CE router's interface is a channelized interface (defined in SONET/SDH), a channel in the channelized interface can be a data plane interface.
- VPNエンドポイント：顧客エッジ（CE）デバイスのデータプレーン・プロバイダ・エッジ（PE）デバイスに接続されたインターフェイスと、VPNメンバーシップの一部です。データプレーンインターフェイスはTEリンクのエンドポイントに関連付けられていることに留意されたいです。 CEルータのインターフェイスは、（SONET / SDHで定義された）チャネル化インターフェースである場合、例えば、チャネル化インタフェースにおけるチャネルは、データ・プレーン・インタフェースであってもよいです。
- VPN connection (or connection in the L1VPN context): A connection between a pair of VPN end points. Note that in some scenarios a connection may be established between a pair of C (Customer) devices using this CE-CE VPN connection as a segment or forwarding adjacency defined in [RFC4206].
- VPN接続（又はL1VPNコンテキストの接続）：VPNエンドポイントのペア間の接続。いくつかのシナリオでは、接続が[RFC4206]で定義された隣接するセグメントとして、このCE-CE VPN接続を使用して、または転送C（顧客）デバイスの対の間に確立されてもよいことに留意されたいです。
Note that the following terms are aligned with Provider Provisioned VPN (PPVPN) terminology [RFC4026], and in this document, have a meaning in the context of L1VPNs, unless otherwise specified.
以下の用語はプロバイダプロビジョニングVPN（PPVPN）用語[RFC4026]と整列されることに注意してください、そして特に断らない限り、この文書で、L1VPNsの文脈で意味を有します。
- CE device: A CE device is a customer device that receives L1VPN service from the provider. A CE device is connected to at least one PE device. A CE device can be a variety of devices, for example, Time Division Multiplexing (TDM) switch, router, and layer 2 switch. A CE device does not have to have the capability to switch at layer 1, but it is capable of receiving a layer 1 signal and either switching it or terminating it with adaptation. A CE device may be attached to one or more C devices on the customer site, and it may be a host using a layer 1 connection directly.
- CEデバイス：CEデバイスは、プロバイダーからL1VPNサービスを受ける顧客のデバイスです。 CEデバイスは、少なくとも1つのPEデバイスに接続されています。 CEデバイスは、デバイスの様々な、例えば、時分割多重（TDM）スイッチ、ルータ、およびレイヤ2スイッチであることができます。 CEデバイスは、層1でスイッチングする能力を有する必要はないが、それは、レイヤ1信号を受信し、それを切り替えたり適応とそれを終端のいずれかが可能です。 CEデバイスは、顧客サイト上の1つのまたはそれ以上のCデバイスに取り付けることができる、それが直接レイヤ1接続を使用してホストであってもよいです。
- PE device: A PE device is a provider device that provides L1VPN service to the customer. A PE device is connected to at least one CE device. A layer 1 PE device is a TDM switch, an Optical Cross-Connect (OXC) (see [RFC3945]), or a Photonic Cross-Connect (PXC) (see [RFC3945]). Alternatively, a PE device 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.).
- PE装置：PE装置が顧客にL1VPNサービスを提供する提供装置です。 PEデバイスは、少なくとも1つのCEデバイスに接続されています。層1 PEデバイスは、TDMスイッチ、光クロスコネクト（OXC）（[RFC3945]を参照）、またはフォトニッククロスコネクト（PXC）（[RFC3945]を参照します）。代替的に、PEデバイスは、イーサネット（等TDMオーバーイーサネット（登録商標）を用いて）レイヤ1つの接続にフレームマッピングデバイスのイーサネット専用回線（EPL）タイプであってもよいです。
- P (Provider) device: A P device is a provider device that is connected only to other provider devices (P or PE devices). A layer 1 P is a TDM switch, OXC, or PXC.
- P（プロバイダ）デバイス：P装置は、他のプロバイダ・デバイス（PまたはPE装置）に接続されている提供装置です。層1 Pは、TDMスイッチ、OXC、又はPXCあります。
- Customer: A customer has authority over a set of CE devices within the same VPN (e.g., the owner of CE devices). Note that a customer may outsource the management of CE devices to other organizations, including to the provider itself.
- 顧客：顧客が同じVPN（例えば、CE機器の所有者）内のCEデバイスのセットに対する権限を有しています。顧客は、プロバイダ自体に含め、他の組織にCEデバイスの管理を外部委託することがあります。
- Provider: A provider has authority over the management of the provider network.
- プロバイダ：プロバイダはプロバイダ・ネットワークの管理の権限を持っています。
- Membership information: A list of CE-PE TE link addresses belonging to the same VPN. Membership information contains the association of a CE, a PE, and a VPN.
- 会員情報：同じVPNに属するCE-PE TEリンクアドレスのリスト。会員情報は、CE、PE、およびVPNの会合を含んでいます。
The layer 1 network, made of OXCs, TDM switches, or PXCs may be seen as consisting of PE devices that give access from outside of the network, and P devices that operate only within the core of the network. Similarly, outside the layer 1 network is the customer network consisting of C devices with access to the layer 1 network made through CE devices.
OXC、TDMスイッチ、またはPXCsからなる層1のネットワークは、ネットワークの外部からのアクセスを与えるPEデバイス、およびのみネットワークのコア内で動作するPデバイスからなるものとして見ることができます。同様に、レイヤ1ネットワーク外のCE機器を介して行わ層1ネットワークへのアクセスをC素子からなる顧客ネットワークです。
A CE and 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.
CEおよびPEは、一つ以上のリンクにより接続されています。 CEは、複数のPEに接続することができ、そしてPEは、それに接続された複数のCEを有していてもよいです。
A layer 1 connection is provided between a pair of CEs. Such a connection follows the hierarchy defined in [RFC4206]. That is, a CE-CE connection may be nested in a lower layer connection (e.g., VC3 connection over STM1 connection). Likewise, the switching capabilities of the interfaces of the CEs, PEs, and Ps on which a connection is routed, follow the hierarchy defined in [RFC4206].
層1の接続がCEの対の間に設けられています。そのような接続は、[RFC4206]で定義された階層に従います。すなわち、CE-CE接続が下層接続にネストすることができる、（例えば、STM1接続を介しVC3接続）。同様に、接続がルーティングされるのCE、のPE、およびPSのインターフェイスのスイッチング機能は、[RFC4206]で定義された階層を辿ります。
The concept of a PPVPN has been established through many previous documents such as [RFC4664] and [RFC4110]. Terminology for PPVPNs is set out in [RFC4026] with special reference to layer 2 and layer 3 VPNs.
PPVPNの概念は、このような[RFC4664]と[RFC4110]など、多くの以前の文書を介して確立されています。 PPVPNsための用語は2およびレイヤ3 VPNを層に特別な参照して、[RFC4026]に記載されています。
The realization of L1VPNs can be based on extensions of the concepts of the PPVPN to the layer 1 network. It must be understood that meeting the requirements set out in this document may necessitate extensions to the existing mechanisms both for the control plane within the layer 1 network and for service provisioning at the edge of the network (CE and PE devices). It is at the interface between CE and PE devices that the L1VPN service is provided.
L1VPNsの実現は、レイヤ1ネットワークへのPPVPNの概念の拡張に基づくことができます。なお、この文書に記載された要件を満たすことは、ネットワーク（CEおよびPEデバイス）の縁部にレイヤ1のネットワーク内およびサービスプロビジョニングのための両方の制御プレーンのための既存のメカニズムへの拡張を必要とすることができることを理解しなければなりません。これはL1VPNサービスが提供されるCEおよびPEデバイスとの間のインタフェースです。
Note that the fundamental difference between L1VPNs and L2/L3 VPNs is that in L1VPNs, data plane connectivity does not guarantee control plane connectivity (and vice versa). But CE-PE control plane connectivity is required for L1VPN services provisioned through the control plane, and CE-CE data plane connectivity is maintained by signaling mechanisms based on this control plane connectivity. Furthermore, the provision of CE-CE control plane connectivity over the provider network is also required for certain levels of L1VPN service, and this can be achieved by the exchange of control packets between CEs over the control plane of the provider network. This aspect is discussed further in Section 10.2.
L1VPNs及びL2 / L3 VPN間の基本的な違いはL1VPNsに、データプレーン接続が制御プレーン接続（およびその逆）を保証しないことであることに留意されたいです。しかし、CE-PE制御プレーンの接続は、制御プレーンを介してプロビジョニングL1VPNサービスのために必要とされる、及びCE-CEデータプレーンの接続は、この制御プレーン接続に基づくメカニズムをシグナリングすることによって維持されます。また、プロバイダネットワークを介してCE-CE制御プレーン接続の提供はまた、L1VPNサービスの特定のレベルのために必要とされ、これはプロバイダネットワークの制御プレーン上のCE間の制御パケットの交換により達成することができます。この態様は、セクション10.2で詳しく説明されています。
Pre-existing efforts at standardization have focused on the provision of dynamic connections within the layer 1 network (signaling and routing) and the definition of interfaces for requesting services between the user and the layer 1 network over the User-Network Interface (UNI), and between networks across the External Network-Network Interface (E-NNI) (see [RFC3945], [RFC4208], [RFC4139], and [RFC4258]).
標準化における既存の努力は、（シグナリングおよびルーティング）層1のネットワーク内の動的接続の提供とユーザネットワークインタフェース（UNI）を介してユーザとレイヤ1ネットワークとの間のサービスを要求するためのインターフェイスの定義に焦点を当てています外部ネットワーク、ネットワークインターフェイス（E-NNI）の両端のネットワーク間（[RFC3945]、[RFC4208]、[RFC4139]及び[RFC4258]を参照）。
Current UNIs include features to facilitate requests for end-to-end (that is, CE to CE) services that include the specification of constraints such as explicit paths, bandwidth requirements, protection needs, and (of course) destinations.
現在のUNIは、エンドツーエンドの要求（つまり、CE CEに）明示的なパス、帯域幅要件、保護の必要性、および（もちろん）宛先として制約の仕様を含むサービスを容易にするための機能が含まれています。
Current E-NNIs include features to exchange routing information, as well as to facilitate requests for end-to-end services.
現在のE-NNIにルーティング情報を交換するだけでなく、エンドツーエンドのサービスに対する要求を容易にするための機能が含まれています。
The UNIs and E-NNIs may be applied in the context of L1VPNs. For example, the UNI may be applied between the CE and the PE, and the E-NNI may be applied between PEs (inter-AS/SP L1VPNs), or between the CE and the PE.
UNIおよびE-NNIはL1VPNsの文脈で適用されてもよいです。例えば、UNIは、CEとPEとの間に印加されてもよく、E-NNIは、（インターAS / SP L1VPNs）のPEとの間に印加される、またはCEとPEの間であってもよいです。
However, the existing UNI and E-NNI specifications do not provide sufficient parameters to support VPNs without some additions. For example, there is no way to distinguish between control messages received over a shared control link (i.e., a control link shared by multiple VPNs) at a UNI/E-NNI, and these messages must be disambiguated to determine the L1VPN to which they apply. A control link is an IP link used for establishing a control channel between nodes.
しかし、既存のUNIおよびE-NNI仕様は、いくつかの追加なしでVPNをサポートするのに十分なパラメータを提供していません。例えば、共有制御リンクを介して受信した制御メッセージを区別する方法がない（すなわち、複数のVPNによって共有コントロールリンク）UNI / E-NNIで、これらのメッセージは、L1VPNにを決定するために明確化されなければならない彼ら適用されます。制御リンクは、ノード間の制御チャネルを確立するために使用されるIPリンクです。
Another example is that there is no clearly defined way of distributing membership information to be used in combination with UNI/E-NNI. This function is necessary in order to discover the existence and location of the CEs to be connected by L1 connections. Distribution of membership information is typically done by the provider, and may be realized by mechanisms such as static provisioning, or by piggybacking on routing protocols (e.g., see Section 4.2.1 of [RFC4110]). Note that the method chosen for distribution of membership information depends on the solution used for supporting L1VPNs, which is outside of the scope of this document.
別の例は、UNI / E-NNIと組み合わせて使用することが会員情報の配信のない明確に定義された方法がないことです。この関数は、L1の接続によって接続されるCEの存在及び位置を検出するために必要です。会員情報の分布は、典型的には、プロバイダによって行われ、このような静的プロビジョニングなどのメカニズムによって実現されてもよい、または（例えば、[RFC4110]のセクション4.2.1を参照）ルーティングプロトコルにピギーバックすることによって。会員情報の配信のために選択された方法は、この文書の範囲外であるL1VPNsを支持するために使用される溶液、に依存することに留意されたいです。
Furthermore, customer addressing realms may overlap with each other, and may also overlap with the service provider addressing realm. This requires address mapping mechanisms, but such mechanisms are not well defined in existing UNI/E-NNI specifications.
さらに、顧客アドレス範囲が互いに重複してもよいし、またサービスプロバイダアドレッシング領域と重なっていてもよいです。これは、アドレスマッピングメカニズムが必要ですが、そのようなメカニズムはよく既存のUNI / E-NNI仕様で定義されていません。
Lastly, there is no clearly defined way to restrict connectivity among CEs (or over a UNI/E-NNI). In addition, E-NNIs allow routing information exchange, but there is no clearly defined way to allow limited routing information exchange (i.e., a specific set of routing information is distributed to a specific set of CEs).
最後に、（またはUNI / E-NNI上）のCE間の接続を制限するいかなる明確に定義された方法はありません。また、E-NNIは情報交換をルーティングできるようにしないが、（即ち、ルーティング情報の特定のセットは、CEの特定のセットに分配される）限られたルーティング情報の交換を可能にする明確に定義された方法にはあります。
In order for L1VPNs to be supported in a fully functional manner, these additional capabilities and other requirements set out later in this document must be addressed.
完全に機能的にサポートすることがL1VPNsためには、このドキュメントの後半で定めるこれらの追加機能およびその他の要件に対処しなければなりません。
Note that inter-AS/SP L1VPNs require additional analysis beyond the focus of this document.
インターAS / SPのL1VPNsは、このドキュメントの焦点を超えた追加的な分析を必要とすることに注意してください。
The foundation of this document is based on the work of the ITU-T Study Group 13, Question 11, such as [Y.1312] and [Y.1313]. This group has been researching and specifying both the requirements and the architecture of L1VPNs for some time. In this context, the foundation of this document is a representation of the findings of the ITU-T, and a presentation of those findings in terms and format that are familiar to the IETF.
この文書の基礎は、[Y.1312]及び[Y.1313]のように、質問11、ITU-T研究グループ13の作業に基づいています。このグループには、いくつかの時間のための要件とL1VPNsのアーキテクチャの両方を研究し、指定されています。この文脈において、本文書の基礎は、ITU-Tの所見の表現であり、IETFによく知られている用語およびフォーマットにおけるそれらの知見の提示。
In particular, this document is limited to the areas of concern of the IETF. That is, it is limited to layer 1 networks that utilize IP as the underlying support for their control plane.
特に、この文書はIETFの気になる部分に限定されています。すなわち、それらの制御プレーンのための基礎となる支持体としてIPを利用1つのネットワーク層のものです。
The foundation of this document presents the requirements and architectures developed within the ITU-T for better understanding within the IETF and to further cooperation between the two bodies.
このドキュメントの基盤は、IETF内のよりよい理解のためにと二つの物体間の更なる協力をITU-T内で開発要件とアーキテクチャを提示します。
Some work related to the L1VPN solution space has already been done within the IETF.
L1VPNの解空間に関連するいくつかの作業はすでにIETF内で行われました。
The general benefits and desirability of VPNs have been described many times and in many places ([RFC4110] and [RFC4664]). This document does not dwell on the merits of VPNs as such, but focuses entirely on the applicability of the VPN concept to layer 1 networks.
VPNの一般的なメリットと望ましは何度も説明し、多くの場所（[RFC4110]と[RFC4664]）でされています。このドキュメントは、次のようなVPNのメリットに住むが、1つのネットワーク層へのVPNの概念の適用可能性に完全に焦点を当てていません。
Similarly, the utility and value of a control plane for the configuration, management, and operation of a layer 1 network is well-rehearsed [RFC3945].
同様に、レイヤ1ネットワークの構成、管理、および操作のための制御プレーンの有用性と価値がよく練習は[RFC3945]。
Basic layer 1 services may be characterized in terms that include:
基本的なレイヤ1のサービスが含ま的に特徴付けることができます。
- Connectivity: Between a pair of CEs.
- 接続：CEのペア間。
- Capacity: For example, the bit rate for a TDM service or the capacity of a lambda.
- 容量：例えば、TDMサービスのビットレートまたはラムダの能力。
- Transparency: For example, for an SDH network, overhead transparency.
- 透明性：例えば、SDH網、オーバーヘッド透明性。
- Availability: The percentage of time that the offered service meets the criteria that the provider defines, possibly agreed with each customer. To achieve the required level of availability for the customer connections the service provider's network may use restoration or protected resources [RFC4427].
- 可用性：提供するサービスは、プロバイダが定義した基準を満たしている時間の割合は、おそらく各顧客と合意しました。顧客の接続のための可用性の必要なレベルを達成するために、サービスプロバイダーのネットワークは、修復または保護されたリソース[RFC4427]を使用することができます。
- Performance: The quality of the service delivered to customers, e.g., the number of error-seconds per month.
- パフォーマンス：サービスの品質を顧客に提供、例えば、月ごとのエラー秒数。
The layer 1 services may be categorized based on the combination of connectivity features (data plane) and service control capability features (control plane) available to the customer. A CE is associated with the service interface between a customer site and the provider network, and the categorization can be seen in the context of this service interface as follows.
レイヤ1つのサービスは、接続機能（データプレーン）と、顧客が利用可能なサービスの制御能力機能（制御プレーン）の組み合わせに基づいて分類することができます。 CEは、顧客サイトとプロバイダネットワーク間のサービス・インターフェースに関連付けられ、以下のように分類は、このサービス・インタフェースのコンテキストで見ることができます。
- Static Service: The classic private line service achieved through a permanent connection.
- 静的サービス：永久的な接続を介して達成古典的な専用線サービス。
- Dynamic Service: Either a switched connection service, or a customer-controlled soft permanent connection service (i.e., the customer is in control of when the signaled part is established).
- 動的サービス：交換接続サービス、または顧客制御ソフト常時接続サービス（すなわち、顧客がシグナリング部分が確立されたときの制御である）のいずれか。
- Static Service: A private network service consisting of a mesh of permanent connections.
- 静的サービス：常時接続のメッシュからなるプライベートネットワークサービス。
- Dynamic Service: A dynamic private network service consisting of any combination of switched connection services and customer-controlled soft permanent connection services.
- 動的サービス：交換接続サービスおよび顧客制御ソフト常時接続サービスの任意の組み合わせからなるダイナミックなプライベートネットワークサービス。
For service types 1 and 2, connections are point-to-point, and can be permanent, soft-permanent, or switched. For a static service, the management plane of the provider network is responsible for the management of both the network infrastructure and the end-user connections. For dynamic services, the management plane of the provider network is only responsible for the configuration of the infrastructure; end-user connections are established dynamically via the control plane of the provider network upon customer request.
サービスタイプ1および2のため、接続がポイント・ツー・ポイントであり、そして、永久的なソフト永久、または切り替えることができます。静的なサービスのために、プロバイダネットワークの管理プレーンは、ネットワークインフラストラクチャとエンドユーザの両方の接続を管理する責任があります。ダイナミックサービスのために、プロバイダネットワークの管理プレーンは、インフラストラクチャの構成のための唯一の原因です。エンドユーザの接続は、顧客の要求に応じてプロバイダネットワークの制御プレーンを介して動的に確立されます。
This document does not preclude other advanced services and topology support, such as point-to-multipoint (P2MP) services, as part of the layer 1 services, but these are for further study.
この文書では、レイヤ1つのサービスの一環として、そのようなポイント・ツー・マルチポイント（P2MP）サービスなど、他の高度なサービスとトポロジをサポートし、排除するものではありませんが、これらは、今後の検討課題です。
Private network services in the second category in Section 4.1 can be enhanced so that multiple private networks are supported across the layer 1 network as virtual private networks. These are Layer 1 Virtual Private Networks (L1VPNs). Note that the first category in Section 4.1 would include L1VPNs with only two CEs as a special case.
複数のプライベートネットワークを仮想プライベートネットワークとしてレイヤ1のネットワーク全体でサポートされるように、4.1節での第二のカテゴリー内のプライベートネットワークサービスを向上させることができます。これらは、レイヤ1個の仮想プライベートネットワーク（L1VPNs）です。 4.1節で最初のカテゴリは、特殊なケースとして、2つだけのCEとL1VPNsが含まれることに注意してください。
Compared to the first category of service, the L1VPN service has features such as connectivity restriction, a separate policy, and distribution of membership information applied to a specific group.
サービスの第一のカテゴリーに比べ、L1VPNサービスは、接続制限、別のポリシー、および特定のグループに適用される会員情報の配信などの機能を有しています。
From the customer's perspective, there are two main benefits to a L1VPN. These benefits apply over and above the advantages of access to a dynamically provisioned network.
顧客の視点から、L1VPNには2つの主な利点があります。これらの利点は、動的にプロビジョニングされたネットワークへのアクセスを超えると、上記の利点を適用します。
- The customer can outsource the direct management of a layer 1 network by placing the VPN management in the control of a third party. This frees the customer from the need to configure and manage the connectivity information for the CEs that participate in the VPN.
- お客様は、第三者の制御にVPN管理を配置することによって、レイヤ1ネットワークの直接の管理を外部委託することができます。これは、VPNに参加したCEの接続情報を設定し、管理する必要性からお客様を解放します。
- The customer can make small-scale use of a layer 1 network. So, for example, by sharing the layer 1 network infrastructure with many other users, the customer sites can be connected together across the layer 1 network without bearing the full cost of deploying and managing the layer 1 network.
- 顧客はレイヤ1ネットワークの小規模利用することができます。したがって、たとえば、多くの他のユーザーとレイヤ1のネットワーク・インフラストラクチャを共有することにより、顧客サイトは、レイヤ1のネットワークを展開し、管理の完全なコストを保有することなく、レイヤ1ネットワークを介して相互に接続することができます。
To some extent, the customer may also gain from the provider's benefits (see below). That is, if the provider is able to extract more value from the layer 1 network, the customer will benefit from lower priced services that are better tailored to the customer's needs.
ある程度までは、顧客はまた、プロバイダのメリット（下記参照）から得てもよいです。これは、プロバイダがレイヤ1ネットワークからより多くの価値を抽出することができるならば、顧客は、顧客のニーズに、より良い仕立てている低価格のサービスの恩恵を受けるだろう、です。
The provider benefits from the customer's perception of benefits.
メリットの顧客の認識からプロバイダの利点。
In particular, the provider can build on dynamic, on-demand services by offering new VPN services and off-loading the CE-to-CE configuration requirements from the customers.
具体的には、プロバイダは、新たなVPNサービスを提供することにより、オフロード顧客からのCE-に-CE構成要件のダイナミックなオンデマンドサービスを構築することができます。
Additionally, a more flexible VPN structure applied to the layer 1 network allows the provider to make more comprehensive use of the spare (that is, previously unused) resources within the network. This could be achieved by applying a network model where the provider is responsible for deciding how resources are used and for provisioning of the connection through the layer 1 network.
加えて、より柔軟なVPN構造が層に印加される1ネットワークは、ネットワーク内のリソース（すなわち、以前に使用されていない）プロバイダは、スペアのより包括的な利用することを可能にします。これは、プロバイダはリソースが使用されている方法を決めるため、レイヤ1のネットワークを介した接続のプロビジョニングのために責任があるネットワークモデルを適用することによって、達成することができました。
In large carrier networks providing various kinds of service, it is often the case that multiple service networks are supported over a shared transport network. By applying L1VPNs, multiple internal service networks (which may be managed and operated separately) can be supported over a shared layer 1 transport network controlled and managed using GMPLS. In addition, L1VPNs can support capabilities to offer innovative services to external clients.
サービスの様々な種類を提供する大規模なキャリアネットワークでは、複数のサービスネットワークを共有トランスポートネットワークを介して支持されていることがよくあります。 L1VPNsを適用することにより、（管理対象と別々に動作することができる）、複数の内部サービスネットワークは、制御された共有レイヤ1トランスポートネットワークを介して支持され、GMPLSを使用して管理することができます。また、L1VPNsは、外部クライアントに革新的なサービスを提供するための機能をサポートすることができます。
Some more specific deployment scenarios are as follows.
次のようにいくつかのより具体的な展開シナリオがあります。
A multi-service backbone is characterized such that each service department of a carrier that receives the carrier's L1VPN service provides a different kind of higher-layer service. The customer receiving the L1VPN service (i.e., each service department) can offer its own services, whose payloads can be any layer (e.g., ATM, IP, TDM). The layer 1 transport network and each service network belong to the same organization, but may be managed separately. From the L1VPN service provider's point of view, these services are not visible and are not part of the L1VPN service. That is, the type of service being carried within the layer 1 payload is not known by the service provider.
キャリアのL1VPNサービスを受けるキャリアの各サービス部門は上位層サービスの異なる種類を提供することマルチサービスバックボーンは、そのような特徴があります。 L1VPNサービス（すなわち、各サービス部門）を受信する顧客は、そのペイロード任意の層（例えば、ATM、IP、TDM）することができる独自のサービスを提供することができます。レイヤ1トランスポートネットワークと各サービスネットワークは、同じ組織に属しているが、別々に管理することができます。ビューのL1VPNサービスプロバイダの観点から、これらのサービスが表示されていないとL1VPNサービスの一部ではありません。つまり、サービスのタイプは、レイヤ1ペイロードが、サービスプロバイダによって知られていない内に担持されています。
The benefit is that the same layer 1 transport network resources are shared by multiple services. A large capacity backbone network (data plane) can be built economically by having the resources shared by multiple services usually with flexibility to modify topologies, while separating the control functions for each service department. Thus, each customer can select a specific set of features that are needed to provide their own service.
利点は、同じレイヤ1トランスポートネットワークリソースは、複数のサービスで共有されることです。各サービス部門のための制御機能を分離しながら、大容量のバックボーンネットワーク（データプレーン）は、トポロジを変更するために、通常、柔軟性を複数のサービスで共有リソースを有することによって、経済的に構築することができます。このように、各顧客は独自のサービスを提供するために必要とされる機能の特定のセットを選択することができます。
Note that it is also possible to control and manage these service networks and the layer 1 transport network by using GMPLS in the integrated model [RFC3945] instead of using L1VPNs. However, using L1VPNs is beneficial in the following points:
制御し、統合モデル[RFC3945]にGMPLSを使用して代わりにL1VPNsを使用して、これらのサービスネットワークとレイヤー1トランスポートネットワークを管理することも可能であることに留意されたいです。しかし、L1VPNsを使用すると、以下の点で有益です：
- Independent address space for each of the service networks.
- サービス・ネットワークのそれぞれの独立したアドレス空間。
- Network isolation (topology information isolation, fault isolation among service networks).
- ネットワークの分離（トポロジー情報の分離、サービスネットワーク間の障害分離）。
- Independent layer 1 resource view for each of the service networks.
- サービス・ネットワークのそれぞれについて独立レイヤ1リソースビュー。
- Independent policies that could be applied for each of the service networks.
- サービスネットワークごとに適用されることができる独立した政策。
These points may apply to the management plane functionalities as well as to the control plane functionalities.
これらの点は、制御プレーンの機能に、ならびに管理プレーンの機能に適用することができます。
A carrier's carrier is characterized such that one carrier that receives another carrier's L1VPN service provides its own services. In this scenario, two carriers are in different organizations. It is, therefore, expected that the information provided at the service demarcation points is more limited than in the multi-service backbone case. Similarly, less control of the L1VPN service is given at the service demarcation points. For example, customers of an L1VPN service receive:
キャリアのキャリアは、他のキャリアのL1VPNサービスを受ける一つのキャリアは、独自のサービスを提供するように特徴があります。このシナリオでは、2つのキャリアは、異なる組織です。従って、サービス境界点で提供される情報は、マルチサービスバックボーンの場合よりも制限されることが予想されます。同様に、L1VPNサービスの少ない制御は、サービス境界点で与えられます。例えば、L1VPNサービスの顧客が受け取ります：
- A more limited view of the L1VPN service provider network.
- L1VPNサービス・プロバイダ・ネットワークのより限定されたビュー。
- More limited control over the L1VPN service provider network.
- L1VPNサービスプロバイダーのネットワーク上でより多くの制限された制御。
One of the merits is that each carrier can concentrate on a specific service. For example, the customer of the L1VPN service may focus on L3 services, e.g., providing secure access to the Internet, leaving the L1VPN provider to focus on the layer 1 service, e.g., providing a long-haul bandwidth between cities. The L1VPN customer can construct its own network using layer 1 resources supplied by the L1VPN provider, usually with flexibility to modify topologies, while separating the control functions for each customer carrier.
メリットの一つは、各キャリアが特定のサービスに集中できるということです。例えば、L1VPNサービスの顧客は、例えば、レイヤ1のサービスに注力してL1VPNプロバイダを残して、インターネットへの安全なアクセスを提供する都市間の長距離帯域幅を提供し、例えば、L3サービスに焦点を合わせることができます。 L1VPN顧客は、通常、各顧客のキャリアのための制御機能を分離しながら、トポロジを変更する柔軟性を、L1VPNプロバイダによって供給された層1のリソースを使用して独自のネットワークを構築することができます。
In addition to the scenarios where the second tier service provider is using a single core service provider as mentioned in Section 4.3.2, it is possible for the second tier provider to receive services from more than one core service provider. In this scenario, there are some benefits for the second tier service provider such as route redundancy and dynamic carrier selection based on the price.
第二層のプロバイダが複数のコア・サービス・プロバイダからサービスを受けるためには、セクション4.3.2で述べたように、第2層のサービスプロバイダは、単一のコア・サービス・プロバイダを使用しているシナリオに加えて、それが可能です。このシナリオでは、このような経路の冗長性と価格に基づいて動的なキャリア選択として、第2階層のサービスプロバイダのためのいくつかの利点があります。
The second tier service provider can support a function that enables a layer 1 resource trading service. Using resource information published by its core service providers, a second tier service provider can decide how to best use the core providers. For example, if one core service provider is no longer able to satisfy requests for service, an alternate service provider can be used. Or the second tier service provider could choose to respond to price changes of service over time.
第二階層のサービスプロバイダは、レイヤ1の資源取引サービスを可能とする機能をサポートすることができます。そのコア・サービス・プロバイダによって公開されたリソース情報を使用して、二層サービスプロバイダは、最高のコア・プロバイダーを使用する方法を決定することができます。例えば、一つのコア・サービス・プロバイダは、もはやサービスに対する要求を満たすことができない場合、代替サービス・プロバイダを使用することができます。または第二階層のサービスプロバイダは、時間の経過とともに、サービスの価格変化に対応することを選択することができます。
Another example of second tier service provider use is to reduce exposure to failures in each provider (i.e., to improve availability).
第二層のサービスプロバイダ使用の別の例は、各プロバイダ（すなわち、可用性を向上させる）の障害への曝露を減少させることです。
In addition to the scenarios where a single connection between two CEs is routed over a single service provider as mentioned in Section 4.3.2, it is possible that a connection is routed over multiple ASes within a service provider (called inter-AS L1VPN) or over multiple service providers (called inter-SP L1VPN).
4.3.2項で述べたように、2つのCEの間の単一の接続を単一のサービスプロバイダを介してルーティングされたシナリオに加えて、接続がサービス・プロバイダ内の複数のASを介してルーティングされることが可能である（インターAS L1VPNとも呼ばれる）、または複数のサービスプロバイダ（SP間L1VPNと呼ばれる）を超えます。
The inter-AS L1VPN scenario can be used to construct a single L1VPN from network resources administered by different domains of a single service provider. These administrative domains might not usually have a collaborative relationship at layer 1, and so the inter-AS L1VPN offers a new business model for joint delivery of services to a customer. Consideration of inter-AS L1VPNs requires further analysis beyond the scope of this document.
インターAS L1VPNシナリオは、単一のサービスプロバイダの異なるドメインによって投与ネットワーク資源から単L1VPNを構築するために使用することができます。これらの管理ドメインは、通常、層1での協力関係を持っていない可能性があり、そのため相互AS L1VPNは、顧客へのサービスの共同配送のための新たなビジネスモデルを提供しています。 AS間L1VPNsの検討は、このドキュメントの範囲を超えてさらなる分析が必要です。
The inter-SP scenario can be used to construct a single L1VPN from services provided by multiple regional providers. There could be a variety of business relationships among providers and customers, and this scenario contains many more manageability, security, privacy, policy, and commercial issues than the more simple inter-AS L1VPN case. Consideration of inter-SP L1VPN requires further analysis beyond the scope of this document.
インターSPのシナリオは、複数の地域のプロバイダーが提供するサービスから単一L1VPNを構築するために使用することができます。そこプロバイダと顧客の間のビジネス関係の様々なこと、そしてこのシナリオは、より多くの管理性、セキュリティ、プライバシー、ポリシー、およびより簡単な相互AS L1VPNの場合よりも、市販の問題を含んでいる可能性があります。インターSP L1VPNの検討は、このドキュメントの範囲を超えてさらなる分析が必要です。
In some deployment scenarios, customers of L1VPN services may wish to set up layer 1 connections not on-demand, but at a planned time in the future. Or, even though customers of L1VPN services may wish to use layer 1 connections on-demand, they can tolerate some delay, for example, due to lack of resources at that moment.
いくつかの展開シナリオでは、L1VPNサービスの顧客は、オンデマンドではなく、将来的に計画された時点でない層1の接続を設定することもできます。または、L1VPNサービスの顧客は、オンデマンド層1つの接続を使用したい場合でも、彼らはその時点でリソースが不足しているため例えば、いくつかの遅延を、耐えることができます。
In those scenarios, the provider can reserve bandwidth at a specified time in the future, and can establish the VPN connections according to a schedule. This makes it possible to use bandwidth more efficiently over time (i.e., support more demand). This service, the scheduling service, may be used to support customers who use layer 1 connections for data backup applications, content delivery applications, and some other applications.
これらのシナリオでは、プロバイダは、将来の指定時刻に帯域幅を確保することができ、およびスケジュールに従ってVPN接続を確立することができます。これは（すなわち、より多くの需要をサポートする）時間をかけて、より効率的に帯域幅を使用することが可能になります。このサービスは、スケジューリングサービスは、データのバックアップ・アプリケーション、コンテンツ配信アプリケーション、および他のいくつかのアプリケーションのためのレイヤ1つの接続を使用する顧客をサポートするために使用することができます。
Furthermore, customers may be able to specify when to release layer 1 connections in advance. By considering this information, the provider may be able to further engineer scheduling, which leads to still more efficient bandwidth usage.
さらに、顧客は事前にレイヤ1つの接続を解放するタイミングを指定することができてもよいです。この情報を考慮することにより、プロバイダは、より一層効率的な帯域幅の使用につながる、さらにエンジニアのスケジュールにできる可能性があります。
Note that scheduling of L1VPN services requires time-scoped resource management, which is not well considered in current GMPLS protocols and requires the support of the management plane. In addition, offering scheduling service and on-demand service on the same infrastructure needs careful consideration.
L1VPNサービスのスケジューリングが良く、現在のGMPLSプロトコルで考慮し、管理面のサポートを必要とされていない時間スコープのリソース管理を、必要なことに注意してください。また、同じインフラストラクチャ上でスケジューリングサービスとオンデマンドサービスを提供することは慎重に検討する必要があります。
Figure 5.1 describes the L1VPN reference model.
図5.1は、L1VPN参照モデルを記載しています。
: +--------------------+ :
: | +------------+ | :
: | | Management | | :
+------+ : | | system(s) | | : +------+
| C | : | +------------+ | : | CE | +------+
|device| : | | : |device|--| C |
+------+ : | +------+ : | of | |device|
| : | | |=:=|VPN A| +------+
| : | | | : +------+
+------+ : | | PE | : +------+
+------+ | CE | : | |device| : | CE | +------+
| C | |device| : +------+ +------+ | | : |device| | C |
|device|--| of |=:=| |==| |==| |-:-| of |--|device|
+------+ |VPN A| : | | | | +------+ : |VPN B| +------+
+------+ : | PE | | P | | : +------+
+------+ : |device| |device| | : +------+
+------+ | CE | : | | | | +------+ : | CE | +------+
| C |--|device|=:=| |==| |==| |-:-|device|--| C |
|device| | of | : +------+ +------+ | | : | of | |device|
+------+ |VPN B| : | | PE | : |VPN A| +------+
+------+ : | |device| : +------+
| : | | | : +------+
| : | | |=:=| CE | +------+
+------+ : | +------+ : |device| | C |
| C | : | | : | of |--|device|
|device| : | | : |VPN B| +------+
+------+ : | | : +------+
: | | :
Customer | | Customer
interface | | interface
+--------------------+
|<---- Provider ---->|
| network |
Key: ==== Layer 1 Connection -- link
キー：====レイヤ1つの接続 - リンク
Figure 5.1: L1VPN Reference Model
図5.1：L1VPN参照モデル
In an L1VPN, layer 1 connections are provided between CEs' data plane interfaces within the same VPN. In Figure 5.1, a connection is provided between the left-hand CE of VPN A and the upper right-hand CE of VPN A, and another connection is provided between the left-hand CE of VPN B and lower right-hand CE of VPN B (shown as "=" mark). These layer 1 connections are called VPN connections.
L1VPNでは、層1つの接続は、同じVPN内のCEのデータプレーンインターフェイスとの間に設けられています。図5.1において、接続は、VPN Aの左CEとVPN Aの右上CEとの間に設けられ、別の接続がVPN Bの左側CEとVPNの右下CEとの間に設けられていますB（ "=" のマークとして示されています）。これらの層1つの接続はVPN接続と呼ばれています。
Note that as mentioned in Section 3.1, these VPN connections follow the hierarchy defined in [RFC4206].
セクション3.1で述べたように、これらのVPN接続は、[RFC4206]で定義された階層を辿ることに留意されたいです。
As shown in the reference model, a provider network may contain one or more management systems. A management system may support functions including provisioning, monitoring, billing, and recording. Provider management systems may also communicate with customer management systems in order to provide services. Sections 7 and 11 provide more detail.
参照モデルに示されているように、プロバイダ・ネットワークは、1つまたは複数の管理システムを含むことができます。管理システムは、プロビジョニング、監視、課金、および記録などの機能をサポートすることができます。プロバイダー管理システムはまた、サービスを提供するために、顧客管理システムと通信することができます。セクション7および11は、より詳細な情報を提供しています。
This section describes generic L1VPN services. Detailed descriptions are provided through specific service models in Section 7.
このセクションでは、一般的なL1VPNのサービスについて説明します。詳細な説明は、第7節では、特定のサービスモデルを通じて提供されます。
- The CE device may support more than one customer VPN.
- CEデバイスは、複数の顧客のVPNをサポートすることができます。
- CE-PE data plane links (between data plane interfaces) may be shared by multiple VPNs.
- （データプレーンインタフェース間）CE-PEデータプレーンリンクは複数のVPNによって共有されてもよいです。
Note that it is necessary to disambiguate control plane messages exchanged between CE and PE if the CE-PE relationship is applicable to more than one VPN. This makes it possible to determine to which VPN such control plane messages apply. Such disambiguation might be achieved by allocating a separate control channel to each VPN (either using a separate physical channel, a separate logical channel such as IP tunnel, or using separate addressing).
CE-PEの関係が複数のVPNにも適用可能である場合、制御プレーンメッセージを明確にする必要があることに注意してくださいは、CEとPE間で交換されます。これは、VPNなどの制御プレーンメッセージが適用されるかを決定することが可能になります。そのような曖昧性除去は、（別々の物理チャネル、例えばIPトンネルのような別個の論理チャネルを使用して、またはアドレッシング別のいずれかを使用して）各VPNに対して別個の制御チャネルを割り当てることによって達成され得ます。
A customer addressing realm consists of CE-PE TE link addresses and CE-PE control channel addresses as well as customer site addresses (C and CE addresses). Customer addressing realms may overlap, and may also overlap with the service provider addressing realm.
顧客アドレッシング領域は、CE-PE TEリンクアドレス及びCE-PE制御チャネルアドレス、ならびに顧客サイトのアドレス（CおよびCEアドレス）から成ります。顧客アドレス範囲は重複してもよいし、またサービスプロバイダアドレッシング領域と重なっていてもよいです。
NATs or firewalls might reasonably be placed at customer interfaces, or between administrative domains within the core network. Addressing in the L1VPN model must handle such eventualities. Traversal of NATs and firewalls within the customer network might have implications for L1VPN services that connect C devices, and is for further study.
NATまたはファイアウォールは合理的顧客インターフェイスで、またはコアネットワーク内の管理ドメインとの間に配置されるかもしれません。 L1VPNモデルに取り組むことは、このような事態を処理する必要があります。顧客のネットワーク内のNATやファイアウォールのトラバーサルは、Cのデバイスを接続L1VPNサービスに影響を持っており、今後の検討課題であるかもしれません。
L1VPN has the following two generic service features.
L1VPNは、次の2つの一般的なサービス機能を持っています。
- Connectivity restriction: Layer 1 connectivity is provided to a limited set of CEs' data plane interfaces, called VPN end points. (This set forms the L1VPN membership.)
- 接続の制限：レイヤ1接続はVPNエンドポイントと呼ばれるCEのデータプレーンインターフェイスの限られたセットに提供されます。 （このセットはL1VPNのメンバーシップを形成します。）
- Per VPN control and management: Some level of control and management capability is provided to the customer. Details differ depending on service models described in Section 7.
- パーVPN制御と管理：制御および管理機能のいくつかのレベルが顧客に提供されます。詳細は、第7節で説明したサービスモデルによって異なります。
This section describes Layer 1 VPN service models that can be supported by GMPLS protocols enabled networks. These models are derived from the generic service description presented above.
このセクションでは、ネットワークを有効にGMPLSプロトコルによってサポートできる1つのVPNサービスモデルレイヤについて説明します。これらのモデルは、上記の一般的なサービス記述に由来しています。
Such layer 1 networks are managed and controlled using GMPLS signaling as described in [RFC3471] and [RFC3473], and GMPLS routing as described in [RFC4202]. It must be understood that meeting the requirements set out in this document may necessitate extensions to the existing GMPLS protocols both for the control plane within the layer 1 network and for service provisioning at the edge of the network (CE and PE devices). A CE and a PE are connected by one or more data links. The ends of each link are usually represented as GMPLS-capable interfaces.
そのような層1つのネットワークは、[RFC4202]に記載されているように[RFC3471]及び[RFC3473]、およびGMPLSルーティングに記載されているようにGMPLSシグナリングを使用して管理され制御されます。なお、この文書に記載された要件を満たすことは、ネットワーク（CEおよびPEデバイス）の縁部にレイヤ1のネットワーク内およびサービスプロビジョニングのための両方の制御プレーンのための既存のGMPLSプロトコルへの拡張を必要とすることができることを理解しなければなりません。 CEおよびPEは、1つまたは複数のデータリンクによって接続されています。各リンクの端部は、通常、GMPLS対応のインターフェースとして表されています。
Note that in this document, service models are classified by the semantics of information exchanged over the customer interface. The customer interface may be instantiated by the CE-PE control plane communication and/or the management plane communication between the customer management systems(s) and the provider management system(s). Note that how to realize a CE-PE control channel is discussed in Section 10.1. Customer management system(s) and provider management systems(s) may communicate by utilizing the CE-PE control channel(s).
このドキュメントでは、サービスモデルは、顧客インターフェースを介して交換される情報の意味によって分類されていることに注意してください。顧客インターフェースは、CE-PE制御プレーン通信及び/又は顧客管理システムとの間の管理プレーン通信（S）及びプロバイダ管理システム（複数可）によってインスタンス化されてもよいです。 CE-PE制御チャネルは、セクション10.1で説明されて実現する方法のことに注意してください。顧客管理システム（S）及びプロバイダ管理システム（S）は、CE-PE制御チャネル（複数可）を利用して通信することができます。
Figure 7.1 describes the Management-based service model.
図7.1は、管理ベースのサービスモデルについて説明します。
+--------------------+
: | |
+----------+ : | +----------+ |
| Customer | : | | Provider | |
|Management| : | |Management| |
| system(s)|-:-----+----| system(s)| |
+----------+ : | +----------+ |
: | | :
: | | :
+----+ : +----+ +----+ +----+ : +----+
| CE |----:---| PE |----| P |----| PE |---:---| CE |
+----+ : +----+ +----+ +----+ : +----+
: | | :
: | | :
: +--------------------+ :
: | | :
: |<-Provider network->| :
Customer Customer
interface interface
Figure 7.1: Management-Based Service Model
図7.1：管理ベースのサービスモデル
In this service model, customer management systems and provider management systems communicate with each other. Customer management systems access provider management systems to request layer 1 connection setup/deletion between a pair of CEs. Customer management systems may obtain additional information, such as resource availability information and monitoring information, from provider management systems. There is no control message exchange between a CE and PE.
このサービスモデルでは、顧客管理システムとプロバイダーの管理システムは、互いに通信します。顧客管理システムアクセスプロバイダ管理システムをCEのペア間のレイヤ1接続設定/削除を要求します。顧客管理システムは、プロバイダの管理システムから、そのようなリソースの可用性情報および監視情報として、付加的な情報を得ることができます。 CEとPEとの間に制御メッセージ交換は存在しません。
The provider network may be based on GMPLS. In this case, mechanisms to support soft permanent connections can be applied. However, interfaces between management systems are not within the scope of this document.
プロバイダ・ネットワークは、GMPLSに基づくことができます。この場合、ソフト固定接続をサポートするためのメカニズムを適用することができます。しかし、管理システムとの間のインターフェイスは、この文書の範囲外です。
In this service model, the CE-PE interface's functional repertoire is limited to path setup signaling only. The provider's network is not involved in distribution of customer network's routing information.
このサービスモデルでは、CE-PEインターフェイスの機能性レパートリーは、シグナリングパス設定に制限されています。プロバイダのネットワークは、顧客のネットワークのルーティング情報の流通に関与していません。
Note in addition that there may be communication between customer management system(s) and provider management system(s) in order to provide customers with detailed monitoring, fault information, etc.
詳細監視、障害情報などを顧客に提供するために顧客管理システム（S）及びプロバイダ管理システム（複数可）との間の通信が存在し得ることに加えて注意してください
Figure 7.2 describes the Overlay service model.
図7.2は、オーバーレイサービスモデルについて説明します。
+--------------------+
: | | :
: | | :
+----+ : +----+ +----+ : +----+
| CE |---:---| PE | | PE |---:---| CE |
+----+ : +----+ +----+ : +----+
: | | :
: | | :
: +--------------------+ :
: | | :
: |<-Provider network->| :
Customer Customer
interface interface
Figure 7.2: Overlay Service Model
図7.2：オーバーレイサービスモデル
In this service model, the customer interface is based on the GMPLS UNI Overlay [RFC4208]. The CE requests layer 1 connection setup/deletion to a remote CE. There is no routing protocol running (i.e., no routing neighbor/peering relationship) between a CE and a PE. The CE does not receive routing information from remote customer sites, nor routing information about the provider network.
このサービスモデルでは、顧客インタフェースはGMPLS UNIオーバーレイ[RFC4208]に基づいています。 CEは、リモートCEへのレイヤ1接続設定/削除を要求します。 CEとPEの間に実行中のルーティングプロトコル（すなわち、無ルーティングネイバー/ピアリング関係）が存在しません。 CEは、リモートの顧客サイトからのルーティング情報を、また、プロバイダのネットワークに関するルーティング情報を受信しません。
The CE's interface may be assigned a public or private address, that designates VPN end points.
CEのインターフェイスは、VPNエンドポイントを指定し、パブリックまたはプライベートアドレスを割り当ててもよいです。
In this model, membership information needs to be configured on PEs, so that the PE that receives a Path message from the ingress CE can identify the remote PE connected to the egress CE. Distribution of membership information between PEs is typically done by the provider, and may be realized by mechanisms such as static provisioning, or by piggybacking on routing protocols (auto-discovery).
入口CEからPathメッセージを受信したPEが出力CEに接続されたリモートPEを識別できるように、このモデルでは、会員情報は、PEの上に構成する必要があります。 PE間の会員情報の分布は、典型的には、プロバイダによって行われ、このような静的プロビジョニングなど、またはルーティングプロトコル（自動検出）にピギーバックメカニズムによって実現されてもよいです。
There are various ways that customers perceive the provider network. In one example, the whole provider network may be considered as one node -- the path specified and recorded in signaling messages reflects this. Note that this is distinct from the Virtual Node service model described in Section 7.3.2 because such a model requires that the network is represented to the VPN sites as a virtual node -- that is, some form of routing advertisement is implied, and this is not in scope for the Signaling-based service model.
顧客は、プロバイダのネットワークを認識する様々な方法があります。一例では、全体プロバイダネットワークは、一つのノードとして考えることができる - シグナリングメッセージで指定されたと記録されたパスはこれを反映しています。このようなモデルは、ネットワークを仮想ノードとしてVPNサイトに表現されていることを必要とするので、これは、セクション7.3.2で説明した仮想ノードのサービスモデルとは異なることに注意してください - は、広告をルーティングする何らかの形態を暗示し、これはシグナリング・ベースのサービスモデルのスコープではありません。
In this service model, the CE-PE interface provides the signaling capabilities as in the Basic Mode, plus permits limited exchange of information between the control planes of the provider and the customer to help such functions as discovery of customer network routing information (i.e., reachability or TE information in remote customer sites), or parameters of the part of the provider's network dedicated to the customer.
このサービスモデルでは、CE-PEインターフェイスは、基本モードのようにシグナリング機能を提供し、プラス情報（ルーティング顧客ネットワークの発見などの機能を助けるために、プロバイダと顧客の制御プレーンとの間の情報の限られた交換を可能にします到達可能性またはリモートの顧客サイトでのTE情報）、または顧客に専用のプロバイダのネットワークの一部のパラメータを設定します。
By allowing CEs to obtain customer network routing information, a so-called N-square routing problem could be solved.
CEが顧客ネットワークのルーティング情報を取得できるようにすることで、いわゆるN-正方形ルーティングの問題は解決することができます。
In addition, by using the received traffic engineering-based routing information, a customer can use traffic engineering capabilities. For example, a customer can set up two disjoint connections between a pair of CEs. Another example is that a customer can request a connection between a pair of devices within customer sites, and not necessarily between CEs, with more effective traffic engineering.
また、受信トラフィックエンジニアリングベースのルーティング情報を使用することにより、顧客は、トラフィックエンジニアリング機能を使用することができます。例えば、顧客は、CEのペアの間に2つの互いに素な接続を設定することができます。別の例では、顧客がより効果的なトラフィックエンジニアリングで、顧客サイト内のデバイスのペアの間の接続を要求し、必ずしもCE間ことができるということです。
As such, the customer interface is based on GMPLS signaling and mechanisms to exchange reachability/TE information. Typically, a routing protocol is used between a CE and PE, or more precisely between a CE and the VPN routing context instantiated on the PE. Link state routing information would be needed to implement the above two example scenarios. Some scenarios may be satisfied with reachability routing information only.
このように、顧客インタフェースは、到達可能性/ TE情報を交換するためにシグナリングGMPLSとメカニズムに基づいています。典型的には、ルーティングプロトコルは、CEおよびPE、またはより正確にCEおよびPEでインスタンスVPNルーティングコンテキストの間に使用されます。ルーティング情報をリンク状態は、上記の二つの例のシナリオを実装するために必要とされるであろう。いくつかのシナリオでは、到達可能性が唯一のルーティング情報を持つ満たすことができます。
Note that this service model does not preclude the use of mechanisms other than routing protocols to exchange reachability/TE information.
このサービスモデルは、到達可能性/ TEの情報を交換するために、ルーティングプロトコル以外のメカニズムの使用を排除するものではないことに留意されたいです。
As with the Signaling-based service model, there may be communication between customer management system(s) and provider management system(s) in order to provide detailed monitoring, fault information etc. to customers.
シグナリング・ベースのサービスモデルと同様に、顧客に詳細監視、障害情報などを提供するために顧客管理システム（S）及びプロバイダ管理システム（複数可）との間の通信が存在してもよいです。
Four specific types of the Signaling and Routing service model are the Overlay Extension service model, the Virtual Node service model, the Virtual Link service model and the Per-VPN Peer service model, depending on how customers perceive the provider network in routing and signaling (i.e., the level of information details that a customer is allowed to receive in routing and signaling).
シグナリングとルーティングサービスモデルの4つの特定の種類は（顧客がルーティングおよびシグナリングにおけるプロバイダ・ネットワークを知覚する方法に応じて、オーバーレイ拡張機能のサービスモデル、仮想ノードのサービスモデル、仮想リンクサービスモデルごとのVPNピアサービスモデルですすなわち、情報のレベルは、顧客）は、ルーティングおよびシグナリングで受信するように許可されている詳細。
This service model complements the Overlay service model. In this service model, a CE receives a list of CE-PE TE link addresses to which it can request a VPN connection (i.e., membership information). This may include additional information concerning these TE links (e.g., switching type). Mechanisms other than routing could be used to exchange reachability/TE information between the CE and the PE.
このサービスモデルは、オーバーレイサービスモデルを補完します。このサービスモデルでは、CEは、VPN接続（即ち、会員情報）を要求することができたCE-PE TEリンク・アドレスのリストを受信します。これは、これらのTEリンク（例えば、スイッチング方式）に関する追加情報を含むことができます。ルーティング以外のメカニズムは、CEとPEの間で到達可能性/ TE情報を交換するために使用することができます。
Figure 7.3 describes the Virtual Node service model.
図7.3は、仮想ノードのサービスモデルについて説明します。
+--------------------+
: | | :
+----+ : | | : +----+
| CE |---:---| Virtual Node |---:---| CE |
+----+ : | | : +----+
: | | :
: +--------------------+ :
: | | :
: |<-Provider network->| :
Customer Customer
interface interface
Figure 7.3: Virtual Node Service Model
図7.3：仮想ノードサービスモデル
In this type of service model, the whole provider network is represented as a virtual node (defined in Section 2). The customer perceives the provider network as one single node. The CE receives routing information about CE-PE links and the customer network (i.e., remote customer sites).
サービスモデルのこのタイプでは、全体プロバイダネットワークは、（セクション2で定義された）仮想ノードとして表されます。顧客は、1つのノードとしてプロバイダ・ネットワークを知覚します。 CEは、CE-PEリンクと顧客ネットワーク（すなわち、遠隔の顧客サイト）に関するルーティング情報を受信します。
Note that in this service model, there must be one single virtual node, and this virtual node must be connected with every CE in the VPN.
このサービスモデルでは、1つの仮想ノードが存在しなければならないことに注意してください、そして、この仮想ノードは、VPN内のすべてのCEに接続する必要があります。
Figure 7.4 describes the Virtual Link service model.
図7.4は、仮想リンクサービスモデルについて説明します。
+--------------------+
: | | :
: | Virtual | :
+----+ : +----+ link +----+ : +----+
| CE |---:---| PE |**************| PE |---:---| CE |
+----+ : +----+ +----+ : +----+
: | | :
: +--------------------+ :
: | | :
: |<-Provider network->| :
Customer Customer
interface interface
Figure 7.4: Virtual Link Service Model
図7.4：仮想リンクサービスモデル
In this service model, a virtual link is constructed between PEs. For the definition of a virtual link, please refer to terminology in Section 2. A virtual link is assigned to each VPN and disclosed to the corresponding CEs. As such, the CE receives routing information about CE-PE links, customer network (i.e., remote customer sites), as well as virtual links assigned to each VPN. A special property of the virtual links used in this service model is that the provider network allocates data plane link resources for the exclusive use of each virtual link. The TE attributes of a virtual link are determined according to data plane link resources allocated to this virtual link. Virtual links are an abstraction of the provider network to customers for administrative purposes as well as to exclude "unnecessary information".
このサービスモデルでは、仮想リンクは、PE間で構築されます。仮想リンクの定義については、仮想リンクは、各VPNに割り当てられ、対応するCEに開示されている第2の用語を参照してください。このように、CEは、CE-PEリンク、顧客ネットワーク（すなわち、遠隔の顧客サイト）、並びに各VPNに割り当てられた仮想リンクに関するルーティング情報を受信します。このサービスモデルで使用される仮想リンクの特別なプロパティは、プロバイダのネットワークは、各仮想リンク専用のデータプレーンのリンクリソースの割り当てを行うことです。仮想リンクのTE属性は、この仮想リンクに割り当てられたデータ・プレーン・リンク・リソースに応じて決定されます。仮想リンクは、管理目的のために顧客へのプロバイダ・ネットワークの抽象化だけでなく、「不必要な情報を」除外することです。
Note that in this service model, both end points of each virtual link must be a PE device.
このサービス・モデルでは、各仮想リンクの両端点は、PEデバイスでなければならないことに留意されたいです。
Figure 7.5 describes the Per-VPN Peer service model.
図7.5は、パー-VPNピアサービスモデルについて説明します。
+--------------------+
: | | :
+----+ : +----+ +----+ +----+ : +----+
| CE |---:---| PE |----| P |----| PE |---:---| CE |
+----+ : +----+ +----+ +----+ : +----+
: | | :
: +--------------------+ :
: | | :
: |<-Provider network->| :
Customer Customer
interface interface
Figure 7.5: Per-VPN Peer Service Model
図7.5：パー-VPNピアサービスモデル
This service model is a generalization and combination of the Virtual Link service model and the Virtual Node service model mentioned in Sections 7.3.2 and 7.3.3 respectively.
このサービスモデルは、仮想リンクのサービスモデルと、それぞれのセクション7.3.2と7.3.3で述べた仮想ノードのサービスモデルの一般化と組み合わせたものです。
In this service model, the provider partitions the TE links within the provider network per VPN, and discloses per-VPN TE link information to corresponding CEs. As such, a CE receives routing information about CE-PE links, customer network (i.e., remote customer sites), as well as partitioned portions of the provider network.
このサービスモデルでは、プロバイダはVPNあたりプロバイダーネットワーク内のTEリンクを仕切る、とCE対応にあたり-VPN TEリンク情報を開示しています。このように、CEは、CE-PEリンク、顧客ネットワーク（すなわち、遠隔の顧客サイト）、並びにプロバイダ網の分配部分に関するルーティング情報を受信します。
Note that PEs may advertise abstracted routing information about the provider network to CEs for administrative purpose as well as to exclude "unnecessary information". In other words, virtual links may be constructed between two nodes where direct data links do not exist, or virtual nodes may be constructed to represent multiple physical nodes and links between them.
PEは、管理目的のためにCEにプロバイダーネットワークについての抽象化されたルーティング情報を宣伝するだけでなく、「不必要な情報」を除外することに注意してください。換言すれば、仮想リンクは、直接データリンクが存在しない、または仮想ノードは、それらの間の複数の物理ノードおよびリンクを表すように構成することができる2つのノード間で構築されてもよいです。
In the Per-VPN Peer service model, at least one virtual node corresponding to P devices (one single P or a set of Ps) must be visible to customers.
単位のVPNピアサービスモデルでは、Pデバイス（単一のPまたはPSのセット）に対応する少なくとも1つの仮想ノードは、顧客に表示されなければなりません。
The service models mentioned in Section 7 are related to what information is exchanged between CE and PE. In addition, service models differ in how data plane resources are allocated for each VPN.
第7節で述べたサービスモデルは、CEとPEの間で交換される情報に関連しています。加えて、サービスモデルは、データプレーンリソースが各VPNに割り当てられる方法が異なります。
Note that in the ITU-T documents, the term "U-Plane" is used instead of "data plane".
ITU-T文書では、用語「Uプレーン」が代わりに「データプレーン」を用いていることに留意されたいです。
o Data plane resource allocation
Oデータプレーンリソースの割り当て
- Shared or dedicated:
- 共有または専用：
Shared means that provider network data plane links are shared by multiple (i.e., any or a specific set of) VPNs. (Data plane links are dynamically allocated to a VPN when a VPN connection is requested, and data plane links allocated to one VPN at one time can be allocated to another VPN at another time.)
共有は、プロバイダネットワークデータプレーンリンクが複数（すなわち、任意又は特定のセット）のVPNによって共有されることを意味します。 （データプレーンリンクを動的VPN接続が要求されたときにVPNに割り当てられ、一度に一つのVPNに割り当てられたデータ・プレーン・リンクが別の時間に別のVPNに割り当てることができます。）
Dedicated means that provider network data plane links are partitioned per VPN. (Data plane links are statically allocated to one VPN and can not be used by other VPNs.)
専用のは、プロバイダのネットワークデータプレーンのリンクはVPNごとに分割されていることを意味します。 （データプレーンリンクは静的1つのVPNに割り当てられ、他のVPNによって使用することができません。）
o Information exchanged between CE and PE
O情報は、CEとPEの間で交換しました
- Signaling
- シグナリング
- Membership information (optionally includes TE information of the associated CE-PE TE links)
- メンバーシップ情報（必要に応じて関連するCE-PE TEリンクのTE情報を含みます）
- Customer network routing information (reachability only, or may include TE information)
- 顧客ネットワークルーティング情報（のみ到達可能性、またはTEの情報を含んでいてもよいです）
- Provider network routing information (TE information)
- プロバイダーネットワークルーティング情報（TE情報）
Note that link management information (e.g., LMP [RFC4204]) may be exchanged between a CE and a PE, but this is orthogonal to the definition of the service models.
そのリンクの管理情報をメモ（例えば、LMP [RFC4204]）は、CEとPEの間で交換されてもよいが、これはサービスモデルの定義と直交しています。
Table 1 shows combination of service requirements and service models.
表1は、サービス要件とサービスモデルの組み合わせを示しています。
| Data plane | Data plane
| shared | dedicated
---------------------------+------------------+-------------------
Signaling | Overlay | Overlay
---------------------------+------------------+-------------------
Signaling + | Overlay | Overlay
Membership information | Extension | Extension
---------------------------+------------------+-------------------
Signaling + | |
Membership information + | Virtual Node | Virtual Node
Customer network routing | |
information | |
---------------------------+------------------+-------------------
Signaling + | |
Membership information + | | Virtual Link
Customer network routing | Not applicable |
information + | | Per-VPN Peer
Provider network routing | |
information | |
Table 1: Combination of service requirements and service models
表1：サービス要件とサービスモデルの組み合わせ
As described in previous sections, the difference between the Virtual Link service model and the Per-VPN Peer service model is whether customers have visibility of P devices. In the Virtual Link service model, the end points of virtual links must be PE devices, thus P devices are not visible to customers. In the Per-VPN Peer service model, at least one virtual node corresponding to P devices (one single P, or a set of Ps) is visible to customers.
前のセクションで説明したように、仮想リンクサービスモデルごとのVPNピアサービスモデルとの違いは、お客様がP・デバイスの可視性を持っているかどうかです。仮想リンクサービスモデルでは、仮想リンクのエンドポイントは、このようにPデバイスは、顧客には見えない、PEデバイスでなければなりません。単位のVPNピアサービスモデルでは、Pデバイス（単一P、またはPSのセット）に対応する少なくとも1つの仮想ノードは、顧客に表示されています。
Note that when customers receive provider network routing information in the form of virtual link, customers must be able to specify such links for a VPN connection over the provider network in signaling.
顧客は、仮想リンクの形式で情報をルーティングプロバイダーネットワークを受信したとき、顧客はシグナル伝達におけるプロバイダ・ネットワーク上のVPN接続のためにそのようなリンクを指定することができなければならないことに留意されたいです。
In addition to the requirements set out in table 1, more detailed service requirements are provided below. They are generally common to the various service models, except where indicated.
表1に記載の要件に加えて、より詳細なサービス要件を以下に提供します。彼らは、示された場合を除いて、一般的に様々なサービスモデルに共通しています。
- Selection of layer 1 service class: Customers MAY be allowed to specify a layer 1 service class (e.g., availability level) for a VPN connection. Further details are described in Section 9.
- レイヤ1サービスクラスの選択：顧客は、VPN接続用レイヤ1サービスクラス（例えば、可用性のレベル）を指定できるようにしてもよいです。更なる詳細は、第9章で説明されています。
- Reception of performance information: Customers MAY be allowed to receive performance information for their VPN connections (e.g., performance monitoring data). When data plane links are dedicated, customers MAY be allowed to receive performance information for links dedicated to them.
- パフォーマンス情報の受付：お客様が自分のVPN接続（例えば、パフォーマンス監視データ）のパフォーマンス情報を受信できるようにしてもよいです。データプレーンのリンクが専用されている場合、顧客は彼らに捧げリンクのパフォーマンス情報を受信できるようにしてもよいです。
- Reception of fault information: Customers MAY be allowed to receive fault information for their VPN connections (e.g., failure notification by RSVP-TE, data plane alarm notification through the management plane, notification of connection setup rejection causes). Note that this does not prevent customers from using Operations and Management (OAM) mechanisms for, or on, their VPN connections. When data plane links are dedicated, customers MAY be allowed to receive fault information for links dedicated to them.
- 障害情報の受信：お客様が自分のVPN接続に障害情報を受信できるようにしてもよい（RSVP-TE、管理プレーンを介したデータプレーンのアラーム通知することにより、例えば、障害通知、接続設定拒絶の通知が原因）。これは、彼らのVPN接続をするために運用および管理（OAM）メカニズムを使用して、または上から顧客を妨げるものではないことに注意してください。データプレーンのリンクが専用されている場合、顧客は彼らに捧げリンクの障害情報を受信できるようにしてもよいです。
- Reception of connection information: Customers MAY be allowed to receive information for current VPN connections (through the management plane).
- 接続情報の受付：お客様は、（管理面から）現在のVPN接続のための情報を受信できるようにしてもよいです。
- Reception of accounting information: Customers MUST be able to receive accounting information for each VPN.
- 会計情報の受付：お客様は、各VPNのための会計情報を受け取ることができなければなりません。
- Specification of policy: Customers MAY be allowed to specify policies (e.g., path computation policies, recovery policies including parameters) for each VPN.
- ポリシーの仕様：顧客は、ポリシーを指定させてもよい（例えば、経路計算ポリシーパラメータを含む回復ポリシー）各VPNのため。
- Security: The communication between the customer and the provider MUST be secure. Further details are described in Section 12.
- セキュリティ：顧客とプロバイダ間の通信は安全でなければなりません。更なる詳細は、12章で説明されています。
- Filtering: Unnecessary information (e.g., information concerning other VPNs) MUST NOT be provided to each customer. This applies particularly to the Signaling and Routing service model, but is also relevant to the Signaling-based service model and to the Management-based service model. Further details are described in Section 12.
- フィルタ：不要な情報（例えば、情報の他のVPNに関する）は、各顧客に提供してはいけません。これは特に、シグナリングとルーティングサービスモデルに適用されますが、また、シグナリング・ベースのサービスモデルへと管理ベースのサービスモデルに関連しています。更なる詳細は、12章で説明されています。
GMPLS provides various recovery techniques for use in different recovery scenarios [RFC4427]. The provider network may apply these recovery techniques to protect VPN connections as part of the L1VPN service, for example as follows: o PE-PE recovery
GMPLSは、さまざまな回復シナリオ[RFC4427]で使用するための様々な復旧技術を提供します。次のようにプロバイダ・ネットワークは、例えば、L1VPNサービスの一部として、VPN接続を保護するために、これらの回復技術を適用することができる：PE-PE回復O
The provider network constitutes a recovery domain, and the recovery scope is the PE-PE part of the CE-CE VPN connection.
プロバイダネットワークは、回復ドメインを構成し、回復範囲はCE-CE VPN接続のPE-PEの一部です。
It should be possible for the provider network to hide the provider network recovery operation from the customer. Namely, it should be possible to configure the provider network to not notify the customer when a failure occurs and a PE-PE recovery operation successfully repairs the failure. Further, when PE-PE recovery fails and the failure should be notified to the customer, it should be possible for the provider network to hide its internal topology.
プロバイダーのネットワークは、顧客からプロバイダーネットワークの復旧操作を非表示にすることが可能でなければなりません。すなわち、障害が発生し、PE-PE回復操作が正常に修理故障したときに、顧客に通知していないために、プロバイダのネットワークを設定することが可能です。 PE-PEの回復が失敗し、障害が顧客に通知しなければならないとき、プロバイダのネットワークが内部トポロジを非表示にするためにさらに、それは可能なはずです。
o CE-PE recovery
EC-回復
The recovery scope is either or both of the ingress and egress CE-PE links of the CE-CE VPN connection.
回復範囲はCE-CE VPN接続の入力および出力CE-PEリンクのいずれかまたは両方です。
o CE-CE recovery
どのような回復
The recovery scope is the entire CE-CE VPN connection.
回復範囲は全体のCE-CEのVPN接続です。
When a failure needs to be notified to a customer so that the customer can initiate recovery operation, it should be possible for the provider network to hide its internal topology.
障害は、顧客がリカバリ操作を開始することができるように顧客に通知する必要がある場合には、プロバイダのネットワークは、その内部のトポロジーを非表示にするために、それは可能なはずです。
These recovery schemes may be applied in combination.
これらの回復方式は組み合わせて適用することができます。
Customers may be allowed to specify the desired recovery level in a connection setup request. Furthermore, the customer may be allowed to specify the desired recovery level in a way that is agnostic of the recovery technique (e.g., when the recovery operation does not require cooperation between the provider network and the customer network). In such cases, the provider network must translate the specified recovery level into specific recovery techniques, based on operational policies. This allows enhanced recovery techniques above and beyond the GMPLS specifications to be used in the provider network.
お客様は、接続セットアップ要求中の所望の回復レベルを指定できるようにしてもよいです。さらに、顧客が回収技術のとらわれない方法で、所望の回復レベルを指定させてもよい（例えば、回復動作は、プロバイダのネットワークと顧客ネットワークとの間の協力を必要としない場合）。このような場合には、プロバイダのネットワークが運用ポリシーに基づいて、特定の回復技術に指定された回復レベルを変換する必要があります。これは、強化された回復技術プロバイダーネットワークで使用するGMPLSの仕様上とを超えてことができます。
The provider network may support various recovery resource sharing schemes, such as the following:
プロバイダ・ネットワークは、次のようなさまざまな回復リソース共有スキームをサポートすることができます。
o Shared recovery
O共有回復
When the provider network supports shared recovery (e.g., shared mesh restoration [RFC4427]), the provider network may provide
プロバイダネットワーク共有回復（例えば、共有メッシュ回復[RFC4427]）をサポートしている場合、プロバイダ・ネットワークが提供することができます
sharing recovery resources between VPN connections that serve with only the same VPN, a specific set of VPNs, or any VPN. The default mode is sharing recovery resources with any VPN.
唯一、同じVPN、VPNの特定のセット、または任意のVPNに仕えるVPN接続間回復リソースを共有します。デフォルトモードは、どのVPNで回復リソースを共有しています。
o Extra traffic
お えｘｔら ｔらっふぃｃ
GMPLS recovery mechanisms support extra traffic. Extra traffic allows the transfer of preemptable traffic on the recovery resources when these resources are not being used for the recovery of protected normal traffic [RFC4427].
GMPLS回復メカニズムは、余分なトラフィックをサポート。余分なトラフィックは、これらのリソースを保護し、通常のトラフィック[RFC4427]の回復のために使用されていない回復リソースの優先使用可能トラフィックの転送を可能にします。
In the context of L1VPNs, extra traffic is applied for CE-CE VPN connections, or PE-PE part of CE-CE VPN connections. The latter case may be applied only when there is hierarchy (i.e., CE-CE VPN connection is nested on top of PE-PE connection). In this section, the latter aspect is analyzed.
L1VPNsの文脈では、余分なトラフィックがCE-CE VPN接続、またはCE-CEのVPN接続のPE-PE部分に適用されます。階層がある場合にのみ、後者の場合（すなわち、CE-CE VPN接続はPE-PE接続の上にネストされている）を適用することができます。このセクションでは、後者の態様は、分析されます。
When the provider network allows a CE-CE VPN connection to be set up as "extra traffic", it means that the VPN connection may use a PE-PE connection that protects some other CE-CE VPN connection. In such a case the provider network may restrict extra traffic CE-CE VPN connection to use resources (i.e., the PE-PE connections) that:
プロバイダネットワークは、CE-CE VPN接続が「余分トラフィック」として設定されることを可能にする場合には、VPN接続がいくつかの他のCE-CE VPN接続を保護するPE-PE接続を使用してもよいことを意味します。このような場合に、プロバイダネットワークリソース（すなわち、PE-PE接続）それを使用するために余分なトラフィックCE-CE VPN接続を制限することができます。
- protect VPN connections from the same VPN as the extra traffic connection.
- 余分なトラフィックの接続と同じVPNからVPN接続を保護します。
- are used for a specific set of VPNs.
- VPNの特定のセットのために使用されています。
- are available for any VPN.
- すべてのVPNのために用意されています。
The default mode is to support preemptable traffic on recovery resources reserved for any VPN.
デフォルトモードは、どのVPNのために確保回復リソースの優先使用可能トラフィックをサポートすることです。
In the Signaling-based service model and the Signaling and Routing service model, there must be a control channel (IP-level connectivity) between a CE and its PE. The instantiation of the control channel may differ depending on addressing and security.
シグナリング・ベースのサービス・モデルとシグナリングおよびルーティングサービスモデルでは、CEとPE間の制御チャネル（IPレベルの接続）が存在しなければなりません。制御チャネルのインスタンス化は、アドレッシング及びセキュリティに応じて異なっていてもよいです。
As stated in Section 6.1, it is necessary to disambiguate control plane messages exchanged between the CE and PE if the CE-PE relationship is applicable to more than one VPN. Furthermore, private addresses may be assigned to CE-PE control channels.
セクション6.1で述べたように、制御プレーンメッセージを明確にするために必要であるCE-PEの関係が複数のVPNにも適用可能である場合CEとPE間で交換。また、プライベートアドレスは、CE-PE制御チャネルに割り当てられてもよいです。
Security aspects of the CE-PE control channel are discussed in Section 12.
CE-PE制御チャネルのセキュリティの側面は、第12章に記載されています。
A customer network connected by VPN connections may be controlled by MPLS or GMPLS, and the VPN connections may be treated as TE links within the customer network. In such cases, there must be control plane (IP-level) connectivity between the CEs, so that control messages, such as signaling and routing messages, can be exchanged between the CEs. Furthermore, in some recovery techniques, Notify message exchange is needed between the ingress and egress of the VPN connection, which requires control plane connectivity between the CEs. There are several potential ways to achieve this.
VPN接続によって接続された顧客ネットワークは、MPLS又はGMPLSによって制御することができる、及びVPN接続は、顧客ネットワーク内のTEリンクとして処理することができます。そのようなシグナリングメッセージおよびルーティングなどの制御メッセージは、CEの間で交換することができるように、そのような場合には、CE間の制御プレーン（IPレベル）接続が存在しなければなりません。さらに、一部の回復技術では、通知メッセージ交換は、CE間の制御プレーンの接続を必要とするVPN接続の入口と出口との間に必要とされます。これを達成するには、いくつかの潜在的な方法があります。
o Use of VPN connections as in-band control channels
インバンド制御チャネルのようなVPN接続の使用O
If the CEs have the ability to inject control messages into the VPN connections and to extract the messages at the far end of the VPN connections, then control messages can be exchanged in-band. For example, when a VPN connection is a Packet Switch Capable (PSC) TE link in the customer network, this operation is transparent to the L1VPN service provider.
CEがVPN接続に制御メッセージを注入すると、VPN接続の遠端でメッセージを抽出する能力を持っている場合、制御メッセージは、帯域内で交換することができます。 VPN接続は、顧客のネットワークに対応（PSC）TEリンクをパケットスイッチされたときに、例えば、この操作はL1VPNサービスプロバイダに対して透過的です。
o Use of overhead associated with the VPN connections
Oのオーバーヘッドを使用すると、VPN接続に関連付けられています
If the VPN connection provides connectivity in the customer network at a different switching capability (implying network technology layer) from that used by the provider network to support the CE-PE and PE-PE connectivity, then the customer network can utilize any overhead available within the VPN connection as a control channel to connect the CEs. For example, if a VPN connection provides a TDM TE link in the customer network but is supported by a technology such as lambda or fiber, then the CEs may utilize the overhead (DCC) as a control channel, if the network supports transparent transfer of such overhead. This operation is transparent to the L1VPN service provider.
VPN接続は、CE-PEおよびPE-PEの接続をサポートするために、プロバイダーネットワークで使用されているから（ネットワーク技術の層を意味する）は、異なるスイッチング能力で顧客ネットワークに接続を提供する場合、顧客ネットワークは内で利用可能な任意のオーバーヘッドを利用することができます。 CEを接続するための制御チャネルとしてVPN接続。 VPN接続は、顧客のネットワーク内のTDM TEリンクを提供するが、このようなラムダ又は繊維などの技術によってサポートされている場合、ネットワークはの透過転送をサポートしている場合、例えば、その後のCEは、制御チャネルとしてオーバーヘッド（DCC）を利用することができますそのようなオーバーヘッド。この操作は、L1VPNサービスプロバイダに対して透過的です。
o Use of control-channel-specific VPN connections
制御チャネルの固有のVPN接続のOを使用
A customer establishes VPN connections dedicated as control channels. This operation is transparent to the L1VPN service provider, but since control plane traffic is likely to be relatively low compared with the capacity of VPN connections, this may be an expensive solution for the customer.
顧客は、制御チャネルとして専用のVPN接続を確立します。この操作は、L1VPNサービスプロバイダに対して透過的ですが、コントロールプレーントラフィックは、VPN接続の容量と比較して相対的に低くなる可能性があることから、これは顧客のために高価な解決策かもしれません。
o Use of separate network
別のネットワークのOを使用
A customer may utilize another network and network service, such as private line service, L3VPN service, L2VPN service, or Internet access service, to establish CE-CE control channel connectivity. This operation is transparent to the L1VPN service provider.
顧客は、CE-CE制御チャネル接続を確立するために、専用線サービス、L3VPNサービス、L2VPNサービス、またはインターネット接続サービスとして、他のネットワークおよびネットワーク・サービスを利用することができます。この操作は、L1VPNサービスプロバイダに対して透過的です。
o Use of CE-PE control channels
CE-PE制御チャネルのOを使用
In the Signaling-based service model, and the Signaling and Routing service model, there must be control plane (IP-level) connectivity between the CE and PE, as described in Section 10.1.
10.1節に記載したようにシグナリング・ベースのサービスモデル、及びシグナリングおよびルーティングサービスモデルでは、CEおよびPE間の制御プレーン（IPレベル）接続が存在しなければなりません。
By utilizing this, CE-CE control message exchange could be realized as part of the service provided by the L1VPN service provider. Namely, the provider network transfers control messages received over the CE-PE control channel to the other side of the provider network and delivers them through the PE-CE control channel. The realization of this within the provider network is up to the operator, but where the provider network uses a GMPLS control plane, the customer control plane messages could be forwarded through the provider control plane, perhaps using IP tunnels.
これを利用することによって、CE-CE制御メッセージ交換はL1VPNサービスプロバイダによって提供されるサービスの一部として実現することができます。すなわち、プロバイダネットワーク転送制御メッセージは、プロバイダネットワークの反対側にCE-PEの制御チャネルを介して受信され、PE-CE制御チャネルを介してそれらを配信します。プロバイダーネットワーク内でこれを実現するには、オペレータ次第ですが、プロバイダーのネットワークはGMPLS制御プレーンを使用する場合には、顧客のコントロールプレーンメッセージは、おそらくIPトンネルを使用して、プロバイダの制御プレーンを介して転送することができます。
Care must be taken to protect the provider network and other customers from Denial of Service (DoS) attack. Traffic saturation over the control plane network needs to be carefully managed as well. Note that if private addresses are assigned to the CE-PE control channels, the provider network must support VPN-scoped routing and forwarding for control messages.
ケアは、サービス拒否（DoS）攻撃からプロバイダーネットワークや他の顧客を保護するために注意する必要があります。コントロール・プレーン・ネットワーク上のトラフィックの飽和は慎重に、同様に管理する必要があります。プライベートアドレスは、CE-PE制御チャネルに割り当てられている場合、プロバイダネットワークは、VPN-スコープルーティングおよび制御メッセージのための転送をサポートしなければならないことに注意してください。
Manageability considerations for GMPLS are described in existing documents, such as [RFC3945]. Also, manageability considerations for L3VPN are described in existing documents, such as [RFC4176]. These manageability considerations should also be applied in L1VPNs, and these aspects are described in this section. In addition, there are some specific manageability considerations for L1VPNs, such as configuration and accounting.
GMPLSのための管理性の考慮事項は、[RFC3945]などの既存の文書に記載されています。また、L3VPNのための管理上の考慮事項は、[RFC4176]などの既存の文書に記載されています。これらの管理性の考慮もL1VPNsに適用されるべきであり、これらの側面は、このセクションで説明されています。また、このような構成や経理などL1VPNs、のためのいくつかの具体的な管理性の考慮事項があります。
o Fault management
O障害管理
The provider network MUST support fault management. It MUST support liveness detection, and monitoring and verification of correct operation.
プロバイダーネットワークは、障害管理をサポートしなければなりません。それは生存性の検出、および正しい操作の監視と検証をサポートしなければなりません。
When a failure occurs, the provider network SHOULD correlate the failure. Also, it SHOULD be able to detect which customer is affected by the failure.
障害が発生した場合、プロバイダ・ネットワークは失敗を関連付けるべきです。また、障害の影響を受けている顧客検出することができるはずです。
If the provider network can resolve failures without intervention from the customer network, it MUST be possible to configure the provider network to not report failures to the customers. However, it MAY be part of an agreement between a customer and provider that failures are reported to the customer, regardless.
プロバイダーのネットワークは、顧客のネットワークからの介入なしに障害を解決することができれば、顧客への障害を報告しないために、プロバイダのネットワークを構成することが可能でなければなりません。しかし、それは失敗にかかわらず、顧客に報告され、顧客とプロバイダとの間の合意の一部であってもよいです。
o Configuration management
O構成管理
The provider network MUST support configuration management, such as the following.
プロバイダーネットワークは、次のような、構成管理をサポートしなければなりません。
- Service mode/model configuration.
- サービスモード/モデル構成。
- Network representation configuration: Configuration of virtual node and virtual link.
- ネットワーク表現の設定：仮想ノードと仮想リンクの設定。
- Resource allocation configuration: Dedicated, shared. See Section 8 for more detail.
- 資源配分の設定：専用、共有。詳細については、セクション8を参照してください。
- Recovery policy configuration: For example, recovery resource sharing schemes, such as shared recovery, extra traffic. See Section 9 for more detail.
- 回復のポリシー設定：たとえば、回復リソース共有、共有の回復などのスキーム、余分なトラフィック。詳細については、セクション9を参照してください。
- Membership configuration.
- メンバー構成。
- Network/Element level configuration: For example, TE link configuration.
- ネットワーク/エレメントレベルの設定：例えば、TEリンク構成。
It SHOULD be possible for the provider network to verify that configuration is correctly made.
プロバイダのネットワークは、その構成が正しく行われていることを確認することが可能なはずです。
o Accounting management
O会計管理
The provider network MUST support accounting management. It MUST be able to record usage of VPN connections for each customer.
プロバイダーネットワークは、会計管理をサポートしなければなりません。顧客ごとにVPN接続の利用状況を記録することができなければなりません。
o Performance management
Oパフォーマンス管理
The provider network MUST support performance management.
プロバイダーネットワークは、パフォーマンス管理をサポートしなければなりません。
In particular, it MUST support performance monitoring of parameters associated with the Service Level Agreement (SLA), such as bit error rate per VPN connection, and SLA verification.
特に、このようなVPN接続ごとにビットエラーレート、及びSLA検証ようサービスレベル契約（SLA）に関連付けられたパラメータのパフォーマンス監視をサポートしなければなりません。
In addition, it MUST support performance monitoring and analysis of parameters related to the network and equipment not directly associated with the SLA, such as network resource utilization.
また、直接ではなく、ネットワークリソースの利用として、SLAに関連付けられたネットワーク・設備に関連するパラメータのパフォーマンスの監視と分析をサポートしなければなりません。
o Security management
Oセキュリティ管理
The provider network MUST support security management. See Section 12 for details.
プロバイダーネットワークは、セキュリティ管理をサポートしなければなりません。詳細については、セクション12を参照してください。
o Management systems
O管理システム
In order to support various management functionalities, the provider network relies on management systems and related tools. GMPLS protocols and potential extensions of GMPLS MUST be able to work with management systems and related tools to provide such functionalities.
様々な管理機能をサポートするために、プロバイダのネットワーク管理システムおよび関連ツールに依存しています。 GMPLSプロトコルおよびGMPLSの潜在的な拡張は、このような機能を提供するための管理システムおよび関連ツールで動作する必要があります。
In particular, MIB modules for GMPLS protocols and potential extensions MUST be supported.
特に、GMPLSプロトコルと潜在的な拡張のためのMIBモジュールをサポートしなければなりません。
o Management of customer networks
顧客ネットワークのO管理
Customers MAY outsource management of their network (especially CEs and CE-CE links) to the provider network. In such case, the provider MUST be able to manage the customer network, as well as the provider network.
お客様は、プロバイダのネットワークへのネットワーク（特にCEとCE-CEリンク）の管理を外部委託すること。このような場合には、プロバイダは、顧客ネットワーク、並びにプロバイダネットワークを管理できなければなりません。
Security is clearly one of the essential requirements in L1VPNs. In this section, key security requirements are highlighted. Security considerations for L3VPNs and L2VPNs are described in existing documents, such as [RFC4110], [RFC4111], and [RFC4664]. These security considerations should also be applied in L1VPNs, and these aspects are described in this section. In addition, there are some specific security considerations for L1VPNs, such as connectivity restriction and shared control links.
セキュリティは明らかにL1VPNsに不可欠な要件の一つです。このセクションでは、主要なセキュリティ要件が強調表示されます。 L3VPNsとのL2VPNのためのセキュリティー上の考慮事項は、[RFC4110]、[RFC4111]、および[RFC4664]のように、既存の文書に記載されています。これらのセキュリティの考慮もL1VPNsに適用されるべきであり、これらの側面は、このセクションで説明されています。また、このような接続の制限および共有制御リンクとしてL1VPNs、のためのいくつかの特定のセキュリティの考慮事項があります。
This section first describes types of information to be secured. Then, security features or aspects are described. Finally, some considerations concerning scenarios where security mechanisms are applied is described.
このセクションでは、最初に確保されるべき情報の種類について説明します。次に、セキュリティ機能や側面が説明されています。最後に、セキュリティメカニズムが適用されているシナリオに関するいくつかの注意事項が記載されています。
It MUST be possible to secure the information exchanged between the customer and the provider. This includes data plane information, control plane information, and management plane information.
顧客とプロバイダとの間で交換される情報を確保することが可能でなければなりません。これは、データプレーン情報、制御プレーン情報、および管理プレーン情報を含みます。
At layer 1, data plane information is normally assumed to be secured once connections are established, since those connections are dedicated to each VPN. That is, it is not possible to communicate unless there is a connection. Therefore, in L1VPNs, the main concern of data plane security is restricting VPN connections to be used only within the same VPN, as described in Section 6.2. Note that a customer may wish to assure data plane information security against not only other customers, but also the provider. In such case, the customer may wish to apply their own security mechanisms for data plane information (CE-CE security), as later described.
接続が確立されると、それらの接続は、各VPNに専用されているので、層1に、データプレーン情報は、通常、固定されているものとします。つまり、接続が存在しない限り、通信することはできません。したがって、L1VPNsに、データプレーンセキュリティの主な関心事は、VPN接続を制限されたセクション6.2で説明したように、唯一同じVPN内で使用されます。また、プロバイダの顧客だけでなく、他の顧客に対して、データプレーンの情報セキュリティを確保したい場合がありますが、。このような場合、顧客は、後述するようにデータプレーン情報（CE-CEセキュリティ）、ための独自のセキュリティメカニズムを適用することを望むかもしれません。
In addition, information contained in the provider network MUST be secured. This includes VPN service contract information, current VPN connection information, VPN membership information, and system information. Note these types of information MAY be accessible to authorized entities.
また、プロバイダネットワークに含まれる情報を確保しなければなりません。これは、VPNサービスの契約情報、現在のVPN接続情報、VPNメンバーシップ情報、およびシステム情報が含まれています。これらの情報は、許可のエンティティにアクセスできる場合があります。
Security features include the following:
セキュリティ機能は、次のものがあります。
o Data integrity
Oデータの整合性
The information exchanged between the customer and the provider MUST be delivered unchanged.
顧客とプロバイダとの間で交換される情報は変更されずに送達されなければなりません。
o Confidentiality
Oの機密性
The information exchanged between the customer and the provider MUST NOT be disclosed to a third party.
顧客とプロバイダとの間で交換される情報は第三者に開示してはなりません。
o Authentication
認証O
The entity requesting the service to the provider MUST be identified and have its identity authenticated, and the provider providing the service MUST also be identified and have its identify authenticated.
プロバイダーにサービスを要求するエンティティが識別されなければならないし、そのアイデンティティが認証されていて、サービスを提供するプロバイダも特定されなければならないし、その識別を認証しました。
o Access control
Oアクセス制御
Access to the information contained in the provider network, which may be information about the customer networks or the existence of customers, as well as about the provider network, MUST be restricted to the authorized entity.
プロバイダーネットワークに関する顧客のネットワークや顧客の存在についての情報だけでなく、かもしれプロバイダーネットワークに含まれる情報へのアクセスは、権限のある機関に限定する必要があります。
o DoS attack detection and protection
O DoS攻撃の検出と保護
The provider network MUST have mechanisms to detect DoS attack and to protect against it reactively and proactively.
プロバイダーネットワークは、DoS攻撃を検出すると、反応性と積極的にそれから保護するためのメカニズムを持っていなければなりません。
There are two scenarios (or occasions) in which security mechanisms are applied. One is the service contract phase, where security mechanisms are applied once. The other is the service access phase, where security mechanisms are applied every time the service is requested.
セキュリティメカニズムが適用される2つのシナリオ（または機会）があります。一つは、セキュリティメカニズムが一度に適用されるサービス契約の段階、です。他には、セキュリティメカニズムは、サービスが要求されるたびに適用されているサービスアクセス相、です。
o Service contract scenario (static)
Oサービス契約のシナリオ（静的）
This scenario includes the addition of new physical devices, such as CE devices, data links and control links. It MUST be guaranteed that these physical devices are connected to the right entity. In addition, authority to access specific information MAY be given to each customer as a part of service contract.
このシナリオでは、CEデバイス、データリンク及びコントロールリンクのような新しい物理デバイスの添加を含みます。これらの物理デバイスは、右のエンティティに接続されていることが保証されなければなりません。また、特定の情報にアクセスするための権限は、サービス契約の一環として、各顧客に与えてもよいです。
o Service access scenario (dynamic)
Oサービスアクセスシナリオ（動的）
This scenario includes the reception of connection requests, routing information exchange requests (e.g., attempts to establish a neighbor relationship in routing protocols, or command request via the management plane interface), and management information retrieval requests. If a communication channel between the customer and the provider (control channel, management interface) is physically separate per customer, and the entity connected over this communication channel is identified in the service contract phase, the provider can ensure who is requesting the service. Also, the communication channel could be considered as secure. However, when communication channel is physically shared among customers, security mechanisms MUST be available and SHOULD be enforced. Examples of such security mechanisms include IPsec [RFC4302] and [RFC4303]. Note that even in the case of physically separate communication channels, customers may wish to apply security mechanisms to assure higher security, and such mechanisms MUST be available.
このシナリオでは、情報交換要求（例えば、管理プレーンインターフェイスを介してルーティングプロトコルで隣接関係、またはコマンド要求を確立しようと）、及び管理情報取得要求をルーティング、接続要求の受信を含みます。顧客とプロバイダ（制御チャネル、管理インターフェース）との間の通信チャネルは、顧客ごとに物理的に分離され、この通信チャネルを介して接続されたエンティティがサービス契約段階で同定されている場合、プロバイダはサービスを要求しているユーザーを確保することができます。また、通信チャネルは、安全とみなすことができます。通信チャネルは、物理的に顧客間で共有されている場合しかし、セキュリティ・メカニズムが利用可能でなければならないと適用されるべきです。このようなセキュリティ機構の例は、IPsec [RFC4302]及び[RFC4303]を含みます。あっても、物理的に別個の通信チャネルの場合には、顧客は、より高いセキュリティを確保するためのセキュリティメカニズムを適用したい場合があり、そのようなメカニズムが利用可能でなければならないことに留意されたいです。
When the entity requesting the service is identified, the provider MUST ensure that the request is authorized for that entity. This includes assuring that connection request is between VPN end points belonging to the same VPN.
サービスを要求するエンティティが特定された場合、プロバイダは、リクエストがそのエンティティのために認可されていることを確認しなければなりません。これは、接続要求が同じVPNに属するVPNエンドポイント間にあることを保証含みます。
Also note that customers may wish to apply their own security mechanisms for data plane information (CE-CE security). This includes IPsec [RFC4302] and [RFC4303] for IP traffic.
また、顧客がデータプレーン情報（CE-CEセキュリティ）のために、独自のセキュリティメカニズムを適用したい場合があることに注意。これは、IPトラフィックのIPsec [RFC4302]と[RFC4303]を含んでいます。
The material in this document is based on the work of the ITU-T Study Group 13.
この文書に記載されている材料は、ITU-T研究グループ13の作業に基づいています。
We would like to thank Dimitri Papadimitriou, Deborah Brungard, Yakov Rekhter, Alex Zinin, Igor Bryskin, Adrian Farrel, and Ross Callon for their useful comments and suggestions.
私たちは、彼らの役に立つコメントと提案のためのディミトリPapadimitriou、デボラBrungard、ヤコフ・レックター、アレックスジニン、イゴールBryskin、エードリアンファレル、およびロスCallonに感謝したいと思います。
Thanks to Mark Townsley, Dan Romascanu, and Cullen Jennings for helpful input during IESG review.
IESGレビュー中の有用入力用のマークTownsley、ダンRomascanu、およびカレンジェニングスに感謝します。
The foundation of this document is based heavily on the work of ITU-T Study Group 13, Question 11. SG13/Q11 has been investigating the service requirements and architecture for Layer 1 VPNs for some time, and the foundation of this document is a summary and development of the conclusions they have reached. Based on such material, the IETF and the L1VPN WG in particular have developed this framework and requirements for the support of L1VPNs by use of GMPLS protocols.
このドキュメントの基礎はITU-T研究グループ13、質問の仕事に大きく基づいて11 SG13 / Q11は、いくつかの時間のために、レイヤ1つのVPNのサービス要件とアーキテクチャを調査してきた、そしてこの文書の基礎は要約ですそして、彼らが達した結論の開発。このような材料をもとに、IETF特にL1VPN WGは、GMPLSプロトコルの使用により、このフレームワークとL1VPNsをサポートするための要件を開発しました。
The details of this document are the result of contributions from several authors who are listed here in alphabetic order. Contact details for these authors can be found in a separate section near the end of this document.
このドキュメントの内容は、アルファベット順にここにリストされている数人の著者からの貢献の結果です。これらの著者のための連絡先の詳細は、この文書の終わり近くに別のセクションに記載されています。
Raymond Aubin (Nortel) Marco Carugi (Nortel) Ichiro Inoue (NTT) Hamid Ould-Brahim (Nortel) Tomonori Takeda (NTT)
レイモンドAubinの（ノーテル）マルコCarugi（ノーテル）井上一郎（NTT）ハミドウルド-Brahimの（ノーテル）智則武田（NTT）
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。
[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月。
[RFC3945] Mannie, E., Ed., "Generalized Multi-Protocol Label Switching (GMPLS) Architecture", RFC 3945, October 2004.
[RFC3945]マニー、E.、エド。、 "一般化マルチプロトコルラベルスイッチング（GMPLS）アーキテクチャ"、RFC 3945、2004年10月。
[RFC4026] Andersson, L. and T. Madsen, "Provider Provisioned Virtual Private Network (VPN) Terminology", RFC 4026, March 2005.
[RFC4026]アンデションと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月。
[Y.1312] Y.1312 - Layer 1 Virtual Private Network Generic requirements and architecture elements, ITU-T Recommendation, September 2003, available from <http://www.itu.int>.
[Y.1312] Y.1312 - から入手レイヤ1仮想プライベートネットワーク一般的な要件とアーキテクチャの要素、ITU-T勧告、2003年9月、<http://www.itu.int>。
[Y.1313] Y.1313 - Layer 1 Virtual Private Network service and network architectures, ITU-T Recommendation, July 2004, available from <http://www.itu.int>.
[Y.1313] Y.1313 - から入手レイヤ1つの仮想プライベートネットワークサービスとネットワークアーキテクチャ、ITU-T勧告、2004年7月、<http://www.itu.int>。
[RFC4110] Callon, R. and M. Suzuki, "A Framework for Layer 3 Provider-Provisioned Virtual Private Networks (PPVPNs)", RFC 4110, July 2005.
[RFC4110] Callon、R.とM.鈴木、 "レイヤのためのフレームワーク3プロバイダ・プロビジョニングされた仮想プライベートネットワーク（PPVPNs）"、RFC 4110、2005年7月。
[RFC4111] Fang, L., Ed., "Security Framework for Provider-Provisioned Virtual Private Networks (PPVPNs)", RFC 4111, July 2005.
[RFC4111]牙、L.、エド。、 "セキュリティフレームワークプロバイダ・プロビジョニングされた仮想プライベートネットワーク（PPVPNs）について"、RFC 4111、2005年7月。
[RFC4139] Papadimitriou, D., Drake, J., Ash, J., Farrel, A., and L. Ong, "Requirements for Generalized MPLS (GMPLS) Signaling Usage and Extensions for Automatically Switched Optical Network (ASON)", RFC 4139, July 2005.
[RFC4139] Papadimitriou、D.、ドレイク、J.、灰、J.、ファレル、A.、およびL.オング、 "自動交換光ネットワーク（ASON）のための一般化MPLS（GMPLS）使用をシグナリングおよび拡張のための要件"、 RFC 4139、2005年7月。
[RFC4176] El Mghazli, Y., Ed., Nadeau, T., Boucadair, M., Chan, K., and A. Gonguet, "Framework for Layer 3 Virtual Private Networks (L3VPN) Operations and Management", RFC 4176, October 2005.
[RFC4176]エルMghazli、Y.、エド。、ナドー、T.、Boucadair、M.、チャン、K.、およびA. Gonguet、 "レイヤ3のためのフレームワークは、仮想プライベートネットワーク（L3VPN）運用・管理"、RFC 4176 、2005年10月。
[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）との交換しました"。
[RFC4258] Brungard, D., Ed., "Requirements for Generalized Multi-Protocol Label Switching (GMPLS) Routing for the Automatically Switched Optical Network (ASON)", RFC 4258, November 2005.
[RFC4258] Brungard、D.、エド。、RFC 4258、2005年11月 "一般化マルチプロトコルラベルのための要件は、自動的に交換光ネットワーク（ASON）のためのルーティング（GMPLS）の切り替え"。
[RFC4302] Kent, S., "IP Authentication Header", RFC 4302, December 2005
[RFC4302]ケント、S.、 "IP認証ヘッダー"、RFC 4302、2005年12月
[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303, December 2005.
[RFC4303]ケント、S.、 "IPカプセル化セキュリティペイロード（ESP）"、RFC 4303、2005年12月。
[RFC4427] Mannie, E., Ed., and D. Papadimitriou, Ed., "Recovery (Protection and Restoration) Terminology for Generalized Multi-Protocol Label Switching (GMPLS)", RFC 4427, March 2006.
[RFC4427]マニー、E.、エド。、およびD. Papadimitriou、エド。、 "リカバリ（保護と回復）一般化マルチプロトコルラベルスイッチング（GMPLS）のための用語"、RFC 4427、2006月。
[RFC4664] Andersson, L., Ed., and E. Rosen, Ed., "Framework for Layer 2 Virtual Private Networks (L2VPNs)", RFC 4664, September 2006.
[RFC4664]アンデション、L.、エド。、およびE.ローゼン、エド。、RFC 4664 "レイヤ2個の仮想プライベートネットワーク（のL2VPN）のためのフレームワーク"、2006年9月。
Authors' Addresses
著者のアドレス
Raymond Aubin Nortel Networks P O Box 3511 Station C Ottawa, ON K1Y 4H7 Canada Phone: +1 (613) 763 2208 EMail: aubin@nortel.com
K1Y 4H7カナダ電話ONレイモンドAubinのNortel NetworksのP Oボックス3511駅のCオタワ、：+1（613）763 2208 Eメール：aubin@nortel.com
Marco Carugi Nortel Networks S.A. Parc d'activites de Magny-Chateaufort Les Jeunes Bois - MS CTF 32B5 - Chateaufort 78928 YVELINES Cedex 9 - FRANCE Phone: +33 1 6955 7027 EMail: marco.carugi@nortel.com
マルコCarugi Nortel NetworksのS.A.社パーク活動マニChateaufortヤングウッド - MS CTF 32B5 - Chateaufort 78928イヴリーヌCedexの9 - FRANCE電話：+33 1 6955 7027 Eメール：marco.carugi@nortel.com
Ichiro Inoue NTT Network Service Systems Laboratories, NTT Corporation 3-9-11, Midori-Cho Musashino-Shi, Tokyo 180-8585 Japan Phone: +81 422 59 6076 EMail: inoue.ichiro@lab.ntt.co.jp
Ichiro Inoue NTT Network Service Systems Laboratories, NTT Corporation 3-9-11, Midori-Cho Musashino-Shi, Tokyo 180-8585 Japan Phone: +81 422 59 6076 EMail: inoue.ichiro@lab.ntt.co.jp
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
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
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2007).
著作権（C）IETFトラスト（2007）。
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に情報を記述してください。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。