[要約] RFC 4847は、レイヤー1仮想プライベートネットワーク（VPN）のフレームワークと要件に関するものです。このRFCの目的は、レイヤー1 VPNの設計と実装に関するガイドラインを提供することです。
Network Working Group T. Takeda, Ed.
Request for Comments: 4847 NTT
Category: Informational April 2007
Framework and Requirements for Layer 1 Virtual Private Networks
レイヤー1仮想プライベートネットワークのフレームワークと要件
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）The IETF Trust（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）のフレームワークとサービスレベルの要件を提供します。このフレームワークは、相互運用可能なL1VPNをサポートするためのプロトコルとメカニズムの開発と標準化を支援することを目的としています。
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、高レベル（サービスレベル）要件の動機を調べ、L1VPNを構築するために使用される可能性のあるアーキテクチャモデルのいくつかを概説しています。
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）の動機を調べ、高レベル（サービスレベル）要件を提供し、L1VPNを構築するために使用される可能性のあるアーキテクチャモデルのいくつかを概説します。
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ネットワークを介してサービスを提供します。このドキュメントは、L1VPNSのフレームワークと、一般化されたマルチプロトコルラベルスイッチング（GMPLS）プロトコルによって制御されるネットワークによるフレームワークの実現を提供します。
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].
「必須」、「そうしない」、「必須」、「shall」、「shall "、" ingle "、" should "、" not "、" becommended "、" bay "、および「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]、[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ネットワークが提供するサービスであり、2つ以上の顧客サイト間のレイヤー1接続を提供し、顧客が接続の確立とタイプをある程度制御できる場所です。別の定義は、L1VPNがレイヤー1で動作するVPNであると言うことです。L1VPNの本質の詳細については、セクション3に記載されています。
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）リンク。直接データリンクは、仮想リンクの2つのエンドポイント間に存在する場合と存在しない場合があります。
- 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エンドポイント：プロバイダーエッジ（PE）デバイスに接続されており、VPNメンバーシップの一部であるカスタマーエッジ（CE）デバイスのデータプレーンインターフェイス。データプレーンインターフェイスは、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接続を使用して、またはこの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デバイスは、イーサネットフレームをレイヤー1接続にマッピングするデバイスのイーサネットプライベートライン（EPL）タイプのデバイスである場合があります（TDMなどのイーサネットなど）。
- 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スイッチ、またはPXCで作られたレイヤー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は、1つ以上のリンクで接続されています。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].
CESのペア間にレイヤー1接続が提供されます。このような接続は、[RFC4206]で定義されている階層に従います。つまり、CE-CEの接続は、下層接続（たとえば、STM1接続に対するVC3接続）にネストされる場合があります。同様に、接続がルーティングされているCES、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の概念の拡張に基づいています。このドキュメントに記載されている要件を満たすことで、レイヤー1ネットワーク内の制御プレーンとネットワークのエッジ（CEおよびPEデバイス）でのサービスプロビジョニングの両方の既存のメカニズムの拡張が必要になる場合があることを理解する必要があります。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 VPNSの根本的な違いは、L1VPNSでは、データプレーンの接続が制御プレーンの接続性を保証しないことです（逆も同様です）。ただし、コントロールプレーンを介してプロビジョニングされたL1VPNサービスには、CE-PE制御プレーンの接続が必要であり、CE-CEデータプレーンの接続は、このコントロールプレーンの接続に基づくシグナリングメカニズムによって維持されます。さらに、プロバイダーネットワーク上のCE-CEコントロールプレーン接続の提供も、L1VPNサービスの特定のレベルに必要であり、これはプロバイダーネットワークの制御プレーン上のCES間の制御パケットの交換によって達成できます。この側面については、セクション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から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.
UNISおよびE-NNISは、L1VPNSのコンテキストで適用できます。たとえば、UNIはCEとPEの間に適用される場合があり、E-NNIはPES（AS/SP L1VPNS）、または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をサポートするのに十分なパラメーターを提供しません。たとえば、UNI/E-NNIで共有コントロールリンク（つまり、複数のVPNで共有されるコントロールリンク）を介して受信した制御メッセージを区別する方法はありません。申し込み。コントロールリンクは、ノード間のコントロールチャネルを確立するために使用される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接続で接続されるCESの存在と位置を発見するために必要です。メンバーシップ情報の配布は通常、プロバイダーによって行われ、静的プロビジョニングなどのメカニズム、またはルーティングプロトコルのピギーバックによって実現される場合があります（たとえば、[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).
最後に、CES間の接続性を制限する明確な定義の方法はありません（またはUNI/E-NNI）。さらに、ENNIはルーティング情報交換を許可しますが、限られたルーティング情報交換を許可する明確に定義された方法はありません（つまり、特定のルーティング情報セットが特定のCESに配布されます）。
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.
L1VPNを完全に機能的にサポートするには、これらの追加の機能やこのドキュメントで説明されている他の要件に対処する必要があります。
Note that inter-AS/SP L1VPNs require additional analysis beyond the focus of this document.
AS/SP L1VPNは、このドキュメントの焦点を超えて追加の分析が必要であることに注意してください。
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]などのITU-T研究グループ13、質問11の研究に基づいています。このグループは、L1VPNの要件とアーキテクチャの両方をしばらくの間調査および指定してきました。これに関連して、このドキュメントの基盤は、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内でよりよく理解し、2つの機関間のさらなる協力のために、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のメリットをそのようにしているわけではありませんが、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.
- 接続性：CESのペア間。
- 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は、顧客サイトとプロバイダーネットワークの間のサービスインターフェイスに関連付けられており、このサービスインターフェイスのコンテキストでは、次のように分類が確認できます。
1. A single connection between a pair of CEs.
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).
- ダイナミックサービス：スイッチされた接続サービス、または顧客制御されたソフトパーマネント接続サービスのいずれか（つまり、顧客が信号部分が確立される時期を制御しています）。
2. Multiple connections among a set of CEs.
2. CESのセット間の複数の接続。
- 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.
セクション4.1の2番目のカテゴリのプライベートネットワークサービスを強化することができるため、仮想プライベートネットワークとしてレイヤー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に参加するCESの接続情報を構成および管理する必要性から顧客が解放されます。
- 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-CE-CEMSFORCURATION要件をオフロードすることにより、ダイナミックでオンデマンドサービスを構築できます。
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.
さらに、レイヤー1ネットワークに適用されるより柔軟なVPN構造により、プロバイダーはネットワーク内のスペア（以前に使用されていない）リソースをより包括的に使用することができます。これは、プロバイダーがリソースの使用方法を決定し、レイヤー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:
L1VPNSを使用する代わりに、統合モデル[RFC3945]でGMPLを使用して、これらのサービスネットワークとレイヤー1トランスポートネットワークを制御および管理することも可能であることに注意してください。ただし、L1VPNを使用することは、次のポイントで有益です。
- 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サービスを受け取る1つのキャリアが独自のサービスを提供するように特徴付けられます。このシナリオでは、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.
メリットの1つは、各キャリアが特定のサービスに集中できることです。たとえば、L1VPNサービスの顧客はL3サービスに焦点を当てることができます。たとえば、インターネットへの安全なアクセスを提供し、L1VPNプロバイダーがレイヤー1サービスに焦点を当てることができます。たとえば、都市間の長距離帯域幅を提供します。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番目のティアプロバイダーが複数のコアサービスプロバイダーからサービスを受信することができます。このシナリオでは、価格に基づいたルート冗長性や動的キャリアの選択など、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.
2番目のティアサービスプロバイダーは、レイヤー1リソース取引サービスを有効にする機能をサポートできます。コアサービスプロバイダーによって公開されたリソース情報を使用して、2番目のティアサービスプロバイダーは、コアプロバイダーを最適に使用する方法を決定できます。たとえば、1つのコアサービスプロバイダーがサービスのリクエストを満たすことができなくなった場合、代替サービスプロバイダーを使用できます。または、2番目のティアサービスプロバイダーは、時間の経過とともにサービスの価格変更に対応することを選択できます。
Another example of second tier service provider use is to reduce exposure to failures in each provider (i.e., to improve availability).
2番目のティアサービスプロバイダーの使用のもう1つの例は、各プロバイダーの障害への暴露を減らすことです（つまり、可用性を改善する）。
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つのCES間の単一の接続が単一のサービスプロバイダーでルーティングされるシナリオに加えて、サービスプロバイダー内の複数のASE（L1VPNと呼ばれる）または複数のASESに接続がルーティングされる可能性があります。複数のサービスプロバイダー（Inter-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.
L1VPN間シナリオを使用して、単一のサービスプロバイダーの異なるドメインによって管理されたネットワークリソースから単一のL1VPNを構築できます。これらの管理ドメインは通常、レイヤー1で共同関係を持たない可能性があるため、L1VPN間は顧客にサービスを共同で配信するための新しいビジネスモデルを提供します。L1VPNとAS間の検討には、このドキュメントの範囲を超えてさらに分析する必要があります。
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を構築できます。プロバイダーと顧客の間にはさまざまなビジネス関係がある可能性があり、このシナリオには、より単純なL1VPNケースよりも多くのより多くの管理可能性、セキュリティ、プライバシー、ポリシー、および商業的な問題が含まれています。Inter-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
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では、同じVPN内のCESのデータプレーンインターフェイス間にレイヤー1接続が提供されます。図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を適用するかを判断できます。このような曖昧性は、各VPNに個別の制御チャネルを割り当てることで達成される場合があります（IPトンネルなどの個別の物理チャネル、IPトンネルなどの個別の論理チャネルを使用するか、個別のアドレス指定を使用します）。
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エンドポイントと呼ばれるCESのデータプレーンインターフェイスの限られたセットに提供されます。（このセットは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ネットワークは、[RFC3471]および[RFC3473]で説明されているGMPLSシグナル伝達を使用して管理および制御され、[RFC4202]で説明されているようにGMPLSルーティングがあります。このドキュメントに記載されている要件を満たすことで、レイヤー1ネットワーク内の制御プレーンとネットワークの端（CEおよびPEデバイス）でのサービスプロビジョニングの両方について、既存の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コントロールプレーンの通信および/または顧客管理システムとプロバイダー管理システム間の管理プレーン通信によってインスタンス化される場合があります。CE-PE制御チャネルを実現する方法については、セクション10.1で説明していることに注意してください。顧客管理システムとプロバイダー管理システムは、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.
このサービスモデルでは、顧客管理システムとプロバイダー管理システムが互いに通信します。顧客管理システムアクセスプロバイダー管理システムは、レイヤー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.
さらに、顧客に詳細な監視、障害情報などを提供するために、顧客管理システムとプロバイダー管理システムの間に通信があるかもしれません。
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は、レイヤー1接続のセットアップ/削除をリモートCEに要求します。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).
このモデルでは、メンバーシップ情報をPESで構成する必要があります。これにより、Ingress CEからパスメッセージを受信するPEが出口CEに接続されたリモートPEを識別できるようにします。PES間のメンバーシップ情報の配布は通常、プロバイダーによって行われ、静的プロビジョニングなどのメカニズム、またはルーティングプロトコルのピギーバック（自動配置）によって実現される場合があります。
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.
顧客がプロバイダーネットワークを知覚するさまざまな方法があります。一例では、プロバイダーネットワーク全体が1つのノードと見なされる場合があります。信号メッセージで指定および記録されたパスはこれを反映しています。これは、セクション7.3.2で説明されている仮想ノードサービスモデルとは異なることに注意してください。このようなモデルでは、ネットワークが仮想ノードとしてVPNサイトに表される必要があるため、つまり、何らかの形のルーティング広告が暗示されています。シグナリングベースのサービスモデルの範囲はありません。
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.
CESがカスタマーネットワークルーティング情報を取得できるようにすることにより、いわゆるN 2乗ルーティングの問題を解決できます。
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.
さらに、受信したトラフィックエンジニアリングベースのルーティング情報を使用することにより、顧客はトラフィックエンジニアリング機能を使用できます。たとえば、顧客は、CESのペア間に2つのばらばらの接続を設定できます。別の例は、顧客がより効果的なトラフィックエンジニアリングで、顧客サイト内のペアのデバイス間の接続を要求できることです。
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とVPNルーティングコンテキストの間で使用されます。上記の2つの例のシナリオを実装するには、リンク状態ルーティング情報が必要です。いくつかのシナリオは、到達可能性のルーティング情報のみで満たされる場合があります。
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.
シグナリングベースのサービスモデルと同様に、顧客に詳細な監視、障害情報などを提供するために、顧客管理システムとプロバイダー管理システムの間に通信がある場合があります。
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で定義）。顧客は、プロバイダーネットワークを単一のノードとして認識します。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つの仮想ノードが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".
このサービスモデルでは、PES間に仮想リンクが構築されます。仮想リンクの定義については、セクション2の用語を参照してください。仮想リンクは各VPNに割り当てられ、対応するCESに開示されています。そのため、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リンクを分割し、VPNごとのTEリンク情報を対応するCESに開示します。そのため、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.
PESは、プロバイダーネットワークに関する抽象化されたルーティング情報を管理目的のためにCESに宣伝し、「不要な情報」を除外する場合があることに注意してください。言い換えれば、直接データリンクが存在しない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デバイス（1つの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に別の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デバイスの可視性を持っているかどうかです。仮想リンクサービスモデルでは、仮想リンクのエンドポイントはPEデバイスである必要があるため、Pデバイスは顧客には見えません。VPNごとのピアサービスモデルでは、Pデバイス（1つの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接続を保護するためにこれらの回復手法を適用する場合があります。たとえば、次のように：o PE-PE Recovery
The provider network constitutes a recovery domain, and the recovery scope is the PE-PE part of the CE-CE VPN connection.
プロバイダーネットワークは回復ドメインを構成し、回復範囲はCE-CE-CE-CE-PE 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
o CE-PE回復
The recovery scope is either or both of the ingress and egress CE-PE links of the CE-CE VPN connection.
回復範囲は、CE-CE-CE-PE VPN接続の侵入と出力のCE-PEリンクのいずれかまたは両方です。
o CE-CE recovery
o CE-CE Recovery
The recovery scope is the entire CE-CE VPN connection.
回復範囲は、CE-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 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.
プロバイダーネットワークが共有リカバリをサポートする場合（たとえば、共有メッシュ修復[RFC4427]）、プロバイダーネットワークは、同じVPN、特定のVPN、またはVPNのみで機能するVPN接続間で共有回復リソースを提供する場合があります。デフォルトモードは、任意のVPNと回復リソースを共有することです。
o Extra traffic
o 余分なトラフィック
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-CE-CE-CE-CE-CE-CE-CE-CE-VPN接続のPE-PE部分に追加のトラフィックが適用されます。後者の場合は、階層がある場合にのみ適用できます（つまり、CE-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-CE-CE-CE-CE-CE-CE-VPN接続を保護するPE-PE接続を使用できることを意味します。そのような場合、プロバイダーネットワークは、追加のトラフィックCE-CE-CE-CE-CE-CE-CENCENCENTを制限してリソース（つまり、PE-PE接続）を使用する場合があります。
- 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リンクとして扱われます。そのような場合、CES間にコントロールプレーン（IPレベル）接続が必要であり、シグナリングやルーティングメッセージなどのコントロールメッセージをCES間で交換できるようにする必要があります。さらに、いくつかの回復手法では、VPN接続の侵入と出口の間にメッセージ交換が必要であり、CES間の制御プレーンの接続が必要です。これを達成するには、いくつかの潜在的な方法があります。
o Use of VPN connections as in-band control channels
o インバンド制御チャネルとしてのVPN接続の使用
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.
CESが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接続をサポートするために使用したものとは、異なるスイッチング機能（ネットワークテクノロジーレイヤーを暗示する）でカスタマーネットワーク内の接続を提供する場合、カスタマーネットワークは内部で利用可能な任意のオーバーヘッドを利用できます。CESを接続するための制御チャネルとしてのVPN接続。たとえば、VPN接続が顧客ネットワークでTDM TEリンクを提供しているが、Lambdaやファイバーなどのテクノロジーによってサポートされている場合、CESは、ネットワークが透明転送をサポートする場合、コントロールチャネルとしてオーバーヘッド（DCC）を利用することができます。そのようなオーバーヘッド。この操作は、L1VPNサービスプロバイダーに対して透明です。
o Use of control-channel-specific VPN connections
o コントロールチャネル固有のVPN接続の使用
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.
顧客は、プライベートラインサービス、L3VPNサービス、L2VPNサービス、インターネットアクセスサービスなど、別のネットワークおよびネットワークサービスを利用して、CE-CEコントロールチャネル接続を確立することができます。この操作は、L1VPNサービスプロバイダーに対して透明です。
o Use of CE-PE control channels
o CE-PE制御チャネルの使用
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.
GMPLの管理可能性の考慮事項は、[RFC3945]などの既存のドキュメントで説明されています。また、L3VPNの管理可能性に関する考慮事項は、[RFC4176]などの既存のドキュメントで説明されています。これらの管理可能性の考慮事項もL1VPNSに適用する必要があり、これらの側面についてはこのセクションで説明します。さらに、構成や会計など、L1VPNにはいくつかの特定の管理可能性に関する考慮事項があります。
o Fault management
o 障害管理
The provider network MUST support fault management. It MUST support liveness detection, and monitoring and verification of correct operation.
プロバイダーネットワークは、障害管理をサポートする必要があります。livense livenessの検出、および正しい操作の監視と検証をサポートする必要があります。
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.
顧客は、ネットワークの管理（特にCESおよび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.
セキュリティは、明らかにL1VPNの重要な要件の1つです。このセクションでは、主要なセキュリティ要件を強調します。L3VPNおよびL2VPNのセキュリティ上の考慮事項は、[RFC4110]、[RFC4111]、[RFC4664]などの既存のドキュメントで説明されています。これらのセキュリティ上の考慮事項もL1VPNSに適用する必要があり、これらの側面についてはこのセクションで説明します。さらに、接続制限や共有制御リンクなど、L1VPNには特定のセキュリティ上の考慮事項があります。
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.
レイヤー1では、これらの接続が各VPN専用であるため、接続が確立されるとデータプレーン情報が確保されると想定されます。つまり、接続がない限り通信することはできません。したがって、L1VPNSでは、データプレーンのセキュリティの主な関心事は、セクション6.2で説明されているように、VPN接続を同じ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つのシナリオ（または機会）があります。1つは、セキュリティメカニズムが一度適用されるサービス契約段階です。もう1つは、サービスが要求されるたびにセキュリティメカニズムが適用されるサービスアクセスフェーズです。
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.
Dimitri Papadimitriou、Deborah Brungard、Yakov Rekhter、Alex Zinin、Igor Bryskin、Adrian Farrel、およびRoss Callonの有用なコメントと提案に感謝します。
Thanks to Mark Townsley, Dan Romascanu, and Cullen Jennings for helpful input during IESG review.
IESGレビュー中に有益な入力をしてくれたマークタウンズリー、ダンロマスカヌ、およびカレンジェニングスに感謝します。
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プロトコルを使用してL1VPNのサポートのためのこのフレームワークと要件を開発しました。
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)
レイモンド・オービン（ノルテル）マルコ・カルギ（ノルテル）一井上（NTT）ハミド・オールド・ブラヒム（ノルテル）トモノリ・タケダ（NTT）
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol Label Switching Architecture", RFC 3031, January 2001.
[RFC3031] Rosen、E.、Viswanathan、A。、およびR. Callon、「Multiprotocolラベルスイッチングアーキテクチャ」、RFC 3031、2001年1月。
[RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP Tunnels", RFC 3209, December 2001.
[RFC3209] Awduche、D.、Berger、L.、Gan、D.、Li、T.、Srinivasan、V。、およびG. Swallow、「RSVP-TE：LSPトンネルのRSVPへの拡張」、RFC 3209、12月2001年。
[RFC3471] Berger, L., Ed., "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Functional Description", RFC 3471, January 2003.
[RFC3471] Berger、L.、ed。、「一般化されたマルチプロトコルラベルスイッチング（GMPLS）シグナル伝達機能説明」、RFC 3471、2003年1月。
[RFC3473] Berger, L., Ed., "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Extensions", RFC 3473, January 2003.
[RFC3473] Berger、L.、ed。、「一般化されたマルチプロトコルラベルスイッチング（GMPLS）シグナリングリソース予約プロトコルトラフィックエンジニアリング（RSVP-TE）拡張」、RFC 3473、2003年1月。
[RFC3945] Mannie, E., Ed., "Generalized Multi-Protocol Label Switching (GMPLS) Architecture", RFC 3945, October 2004.
[RFC3945] Mannie、E.、ed。、「一般化されたマルチプロトコルラベルスイッチング（GMPLS）アーキテクチャ」、RFC 3945、2004年10月。
[RFC4026] Andersson, L. and T. Madsen, "Provider Provisioned Virtual Private Network (VPN) Terminology", RFC 4026, March 2005.
[RFC4026] Andersson、L。およびT. Madsen、「プロバイダープロビジョニング仮想プライベートネットワーク（VPN）用語」、RFC 4026、2005年3月。
[RFC4202] Kompella, K., Ed., and Y. Rekhter, Ed., "Routing Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS)", RFC 4202, October 2005.
[RFC4202] Kompella、K.、ed。、およびY. Rekhter、ed。、「一般化されたマルチプロトコルラベルスイッチング（GMPLS）をサポートするルーティング拡張機能」、RFC 4202、2005年10月。
[RFC4208] Swallow, G., Drake, J., Ishimatsu, H., and Y. Rekhter, "Generalized Multiprotocol Label Switching (GMPLS) User-Network Interface (UNI): Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Support for the Overlay Model", RFC 4208, October 2005.
[RFC4208] Swallow、G.、Drake、J.、Ishimatsu、H。、およびY. Rekhter、「一般化されたマルチプロトコルラベルスイッチング（GMPLS）ユーザーネットワークインターフェイス（UNI）：リソース予約プロトコルトラフィックエンジニアリング（RSVP-TE）オーバーレイモデルのサポート」、RFC 4208、2005年10月。
[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. Suzuki、「レイヤー3プロバイダーがプロビジョニングした仮想プライベートネットワーク（PPVPNS）のフレームワーク」、RFC 4110、2005年7月。
[RFC4111] Fang, L., Ed., "Security Framework for Provider-Provisioned Virtual Private Networks (PPVPNs)", RFC 4111, July 2005.
[RFC4111] Fang、L.、ed。、「プロバイダーが提供する仮想プライベートネットワーク（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.、Drake、J.、Ash、J.、Farrel、A。、およびL. Ong、「一般化されたMPLS（GMPLS）シグナリングの使用法および自動スイッチされた光ネットワーク（ASON）の拡張機能の要件」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] El Mghazli、Y.、ed。、Nadeau、T.、Boucadair、M.、Chan、K.、およびA. Gonguet、「レイヤー3仮想プライベートネットワーク（L3VPN）運用と管理のフレームワーク」、RFC 4176、2005年10月。
[RFC4204] Lang, J., Ed., "Link Management Protocol (LMP)", RFC 4204, October 2005.
[RFC4204] Lang、J.、ed。、「Link Management Protocol（LMP）」、RFC 4204、2005年10月。
[RFC4206] Kompella, K. and Y. Rekhter, "Label Switched Paths (LSP) Hierarchy with Generalized Multi-Protocol Label Switching (GMPLS) Traffic Engineering (TE)", RFC 4206, October 2005.
[RFC4206] Kompella、K。およびY. Rekhter、「一般化されたマルチプロトコルラベルスイッチング（GMPLS）トラフィックエンジニアリング（TE）を備えたラベルスイッチ付きパス（LSP）階層」、2005年10月。
[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.、ed。、「自動化された光ネットワーク（ASON）の一般化されたマルチプロトコルラベルスイッチング（GMPLS）ルーティングの要件」、RFC 4258、2005年11月。
[RFC4302] Kent, S., "IP Authentication Header", RFC 4302, December 2005
[RFC4302] Kent、S。、「IP認証ヘッダー」、RFC 4302、2005年12月
[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303, December 2005.
[RFC4303] Kent、S。、「セキュリティペイロード（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] Mannie、E.、ed。、およびD. Papadimitriou、ed。、「一般化されたマルチプロトコルラベルスイッチング（GMPLS）の回復（保護および回復）用語」、RFC 4427、2006年3月。
[RFC4664] Andersson, L., Ed., and E. Rosen, Ed., "Framework for Layer 2 Virtual Private Networks (L2VPNs)", RFC 4664, September 2006.
[RFC4664] Andersson、L.、ed。、およびE. Rosen、ed。、「レイヤー2仮想プライベートネットワーク（L2VPNS）のフレームワーク」、RFC 4664、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
Raymond Aubin Nortel Networks P O Box 3511 Station C Ottawa、on K1y 4H7カナダ電話：1（613）763 2208メール：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
Marco Carugi Nortel Networks S.A. Parc D'Magny -Chateaufort Les Jeunes Bois -MS CTF 32B5 -Chateaufort 78928 Yvelines Cedex 9-フランス電話：33 1 6955 7027メール：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ネットワークサービスシステムラボラトリーズ、NTTコーポレーション3-9-11、Midori-Cho Musashino-Shi、Tokyo 180-8585日本電話：81 422 59 6076電子メール：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
Hamid Old-Brahim Nortel Networks P O Box 3511 Station C Ottawa、on K1y 4H7カナダ電話：1（613）765 3418メール：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、編集者NTTネットワークサービスシステムラボラトリーズ、NTTコーポレーション3-9-11、Midori-Cho Musashino-Shi、Tokyo 180-8585日本電話：81 422 59 7434メール：Takeda.tomonori@lab.ntt.co.jp
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2007).
著作権（c）The IETF Trust（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.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供され、貢献者、彼/彼女が代表する組織（もしあれば）、インターネット協会、IETFトラスト、インターネットエンジニアリングタスクフォースがすべてを否認します。明示的または黙示的な保証。ここでの情報の使用は、特定の目的に対する商品性または適合性の権利または暗黙の保証を侵害しないという保証を含むがこれらに限定されない。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、知的財産権またはその他の権利の有効性または範囲に関して、本書に記載されている技術の実装または使用、またはそのような権利に基づくライセンスに基づくライセンスの範囲に関連すると主張される可能性のある他の権利に関しては、立場を取得しません。利用可能になります。また、そのような権利を特定するために独立した努力をしたことも表明していません。RFCドキュメントの権利に関する手順に関する情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得するための試みの結果を取得できます。http://www.ietf.org/iprのIETFオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、関心のある当事者に、著作権、特許、または特許出願、またはこの基準を実装するために必要なテクノロジーをカバーする可能性のあるその他の独自の権利を注意深く招待します。ietf-ipr@ietf.orgのIETFへの情報をお問い合わせください。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFCエディター機能の資金は現在、インターネット協会によって提供されています。