[要約] RFC 4665は、レイヤ2プロバイダ提供仮想プライベートネットワーク（VPN）のサービス要件に関するガイドラインです。このRFCの目的は、異なるネットワーク間での仮想プライベートネットワークの提供に関する一貫性と品質を確保することです。
Network Working Group W. Augustyn, Ed.
Request for Comments: 4665 Y. Serbest, Ed.
Category: Informational AT&T
September 2006
Service Requirements for Layer 2 Provider-Provisioned Virtual Private Networks
レイヤー2プロバイダーがプロビジョニングした仮想プライベートネットワークのサービス要件
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 Internet Society (2006).
Copyright（c）The Internet Society（2006）。
Abstract
概要
This document provides requirements for Layer 2 Provider-Provisioned Virtual Private Networks (L2VPNs). It first provides taxonomy and terminology and states generic and general service requirements. It covers point-to-point VPNs, referred to as Virtual Private Wire Service (VPWS), as well as multipoint-to-multipoint VPNs, also known as Virtual Private LAN Service (VPLS). Detailed requirements are expressed from both a customer as well as a service provider perspectives.
このドキュメントには、レイヤー2プロバイダーがプロビジョニングされた仮想プライベートネットワーク（L2VPNS）の要件を提供します。最初に分類法と用語を提供し、一般的なサービス要件と一般的なサービス要件を述べます。仮想プライベートワイヤサービス（VPWS）と呼ばれるポイントツーポイントVPNと、仮想プライベートLANサービス（VPLS）としても知られるマルチポイントツーマルチポイントVPNSをカバーしています。詳細な要件は、顧客とサービスプロバイダーの視点の両方から表明されます。
Table of Contents
目次
1. Introduction ....................................................4
1.1. Scope of This Document .....................................4
1.2. Outline ....................................................5
2. Conventions used in this document ...............................5
3. Contributing Authors ............................................5
4. Definitions and Taxonomy ........................................5
4.1. Definitions ................................................5
4.2. Taxonomy of L2VPN Types ....................................6
4.3. VPWS .......................................................6
4.4. VPLS .......................................................7
5. Service Requirements Common to Customers and Service Providers ..7
5.1. Scope of emulation .........................................8
5.2. Traffic Types ..............................................8
5.3. Topology ...................................................8
5.4. Isolated Exchange of Data and Forwarding Information .......9
5.5. Security ...................................................9
5.5.1. User Data Security .................................10
5.5.2. Access Control .....................................10
5.6. Addressing ................................................11
5.7. Quality of Service ........................................11
5.7.1. QoS Standards ......................................11
5.7.2. Service Models .....................................11
5.8. Service Level Specifications ..............................12
5.9. Protection and Restoration ................................12
5.10. CE-to-PE and PE-to-PE Link Requirements ..................12
5.11. Management ...............................................12
5.12. Interoperability .........................................12
5.13. Inter-working ............................................13
6. Customer Requirements ..........................................13
6.1. Service Provider Independence .............................13
6.2. Layer 3 Support ...........................................13
6.3. Quality of Service and Traffic Parameters .................14
6.4. Service Level Specification ...............................14
6.5. Security ..................................................14
6.5.1. Isolation ..........................................14
6.5.2. Access Control .....................................14
6.5.3. Value-Added Security Services ......................15
6.6. Network Access ............................................15
6.6.1. Physical/Link Layer Technology .....................15
6.6.2. Access Connectivity ................................15
6.7. Customer Traffic ..........................................17
6.7.1. Unicast, Unknown Unicast, Multicast, and
Broadcast forwarding ...............................17
6.7.2. Packet Re-ordering .................................17
6.7.3. Minimum MTU ........................................17
6.7.4. End-point VLAN Tag Translation .....................18
6.7.5. Transparency .......................................18
6.8. Support for Layer 2 Control Protocols .....................18
6.9. CE Provisioning ...........................................19
7. Service Provider Network Requirements ..........................19
7.1. Scalability ...............................................19
7.1.1. Service Provider Capacity Sizing Projections .......19
7.1.2. Solution-Specific Metrics ..........................19
7.2. Identifiers ...............................................19
7.3. Discovering L2VPN Related Information .....................19
7.4. Quality of Service (QoS) ..................................20
7.5. Isolation of Traffic and Forwarding Information ...........20
7.6. Security ..................................................21
7.7. Inter-AS/SP L2VPNs ........................................22
7.7.1. Management .........................................22
7.7.2. Bandwidth and QoS Brokering ........................22
7.8. L2VPN Wholesale ...........................................23
7.9. Tunneling Requirements ....................................23
7.10. Support for Access Technologies ..........................23
7.11. Backbone Networks ........................................24
7.12. Network Resource Partitioning and Sharing Between
L2VPNs ...................................................24
7.13. Interoperability .........................................24
7.14. Testing ..................................................25
7.15. Support on Existing PEs ..................................25
8. Service Provider Management Requirements .......................26
9. Engineering Requirements .......................................26
9.1. Control Plane Requirements ................................26
9.2. Data Plane Requirements ...................................27
9.2.1. Encapsulation ......................................27
9.2.2. Responsiveness to Congestion .......................27
9.2.3. Broadcast Domain ...................................27
9.2.4. Virtual Switching Instance .........................27
9.2.5. MAC Address Learning ...............................27
10. Security Considerations .......................................28
11. Acknowledgements ..............................................28
12. References ....................................................29
12.1. Normative References .....................................29
12.2. Informative References ...................................29
This section describes the scope and outline of the document.
このセクションでは、ドキュメントの範囲と概要について説明します。
This document provides requirements for provider-provisioned Layer 2 Virtual Private Networks (L2VPN). It identifies requirements that MAY apply to one or more individual approaches that a Service Provider (SP) may use for the provisioning of a Layer 2 VPN service. The content of this document makes use of the terminology defined in [RFC4026] and common components for deploying L2VPNs described in [RFC4664].
このドキュメントには、プロバイダーがプロビジョニングされたレイヤー2仮想プライベートネットワーク（L2VPN）の要件を提供します。レイヤー2 VPNサービスのプロビジョニングに使用できるサービスプロバイダー（SP）が使用できる1つまたは複数の個別のアプローチに適用される要件を特定します。このドキュメントの内容は、[RFC4026]で定義されている用語と[RFC4664]で説明されているL2VPNを展開するための一般的なコンポーネントを使用します。
The technical specifications to provide L2VPN services are outside the scope of this document. The framework document [RFC4664] and several other documents, which explain technical approaches providing L2VPN services, such as [VPLS_LDP], [VPLS_BGP], and [IPLS], are available to cover this aspect.
L2VPNサービスを提供する技術仕様は、このドキュメントの範囲外です。フレームワークドキュメント[RFC4664]および[VPLS_LDP]、[VPLS_BGP]、[IPLS]などのL2VPNサービスを提供する技術的アプローチを説明する他のいくつかのドキュメントは、この側面をカバーするために利用できます。
This document describes requirements for two types of L2VPNs: (1) Virtual Private Wire Service (VPWS), and (2) Virtual Private LAN Service (VPLS). The approach followed in this document distinguishes L2VPN types as to how the connectivity is provided (point-point or multipoint-multipoint), as detailed in [RFC4664].
このドキュメントでは、2種類のL2VPNの要件について説明します。（1）仮想プライベートワイヤサービス（VPWS）、および（2）仮想プライベートLANサービス（VPLS）。このドキュメントで続いたアプローチは、[RFC4664]で詳述されているように、接続性の提供方法（ポイントポイントまたはマルチポイントマルチポイント）についてL2VPNタイプを区別します。
This document is intended as a "checklist" of requirements that will provide a consistent way to evaluate and document how well each individual approach satisfies specific requirements. The applicability statement document for each individual approach should document the results of this evaluation.
このドキュメントは、個々のアプローチが特定の要件をどのように満たすかを評価および文書化する一貫した方法を提供する要件の「チェックリスト」として意図されています。個々のアプローチごとのアプリケーションステートメントドキュメントは、この評価の結果を文書化する必要があります。
In the context of provider-provisioned VPNs, there are two entities involved in operation of such services, the Provider and the Customer. The Provider engages in a binding agreement with the Customer as to the behavior of the service in a normal situation as well as in exceptional situations. Such agreement is known as Service Level Specification (SLS), which is part of the Service Level Agreement (SLA) established between the Provider and the Customer.
プロバイダーが提供するVPNのコンテキストでは、そのようなサービスの運用に関与する2つのエンティティ、プロバイダーと顧客があります。プロバイダーは、通常の状況と例外的な状況でのサービスの行動に関して、顧客との拘束力のある契約を結びます。このような契約は、プロバイダーと顧客の間で確立されたサービスレベル契約（SLA）の一部であるサービスレベル仕様（SLS）として知られています。
A proper design of L2VPNs aids formulation of SLSes in that it provides means for proper separation between Customer Edge (CE) and Provider Edge (PE), allows proper execution of the SLS offer, and supports a flexible and rich set of capabilities.
L2VPNS AIDSの適切な設計SLSの定式化は、顧客エッジ（CE）とプロバイダーエッジ（PE）を適切に分離する手段を提供し、SLSオファーの適切な実行を可能にし、柔軟で豊富な機能セットをサポートします。
This document provides requirements from both the Provider's and the Customer's point of view. It begins with common customer's and service provider's point of view, followed by a customer's perspective, and concludes with specific needs of an SP. These requirements provide high-level L2VPN features expected by an SP in provisioning L2VPNs, which include SP requirements for security, privacy, manageability, interoperability, and scalability.
このドキュメントは、プロバイダーと顧客の両方の観点からの要件を提供します。それは、一般的な顧客とサービスプロバイダーの視点から始まり、顧客の視点が続き、SPの特定のニーズで締めくくります。これらの要件は、セキュリティ、プライバシー、管理性、相互運用性、スケーラビリティのSP要件を含むL2VPNのプロビジョニングでSPが期待する高レベルのL2VPN機能を提供します。
The outline of the rest of this document is as follows. Section 4 provides definitions and taxonomy. Section 5 provides common requirements that apply to both customer and SP, respectively. Section 6 states requirements from a customer perspective. Section 7 states network requirements from an SP perspective. Section 8 states SP management requirements. Section 9 describes the engineering requirements, particularly control and data plane requirements. Section 10 provides security considerations. Section 11 lists acknowledgements. Section 12 provides a list of references cited herein.
このドキュメントの残りの部分の概要は次のとおりです。セクション4では、定義と分類法を説明します。セクション5では、それぞれ顧客とSPの両方に適用される一般的な要件を提供します。セクション6には、顧客の観点から要件があります。セクション7では、SPの観点からネットワーク要件を記載しています。セクション8には、SP管理の要件が記載されています。セクション9では、エンジニアリングの要件、特に制御およびデータプレーンの要件について説明します。セクション10では、セキュリティ上の考慮事項を示しています。セクション11に謝辞を示します。セクション12では、ここで引用した参照のリストを示します。
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 RFC 2119 [RFC2119].
この文書のキーワード "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", および "OPTIONAL" はRFC 2119 [RFC2119]で説明されているように解釈されます。
This document was the combined effort of several individuals. The following are the authors that contributed to this document:
このドキュメントは、複数の個人の組み合わせの努力でした。以下は、この文書に貢献した著者です。
Waldemar Augustyn Marco Carugi Giles Heron Vach Kompella Marc Lasserre Pascal Menezes Hamid Ould-Brahim Tissa Senevirathne Yetik Serbest
Waldemar Augustyn Marco Carugi Giles Heron Vach Kompella Marc Lasserre Pascal Pascal Menezes Hamid Oould-Brahim Tissa Senevirathne Yetik Serbest
The terminology used in this document is defined in [RFC4026]. The L2VPN framework document [RFC4664] further describes these concepts in the context of a reference model that defines layered service relationships between devices and one or more levels of tunnels.
このドキュメントで使用される用語は、[RFC4026]で定義されています。L2VPNフレームワークドキュメント[RFC4664]は、デバイスと1つ以上のトンネル間の層状サービス関係を定義する参照モデルのコンテキストで、これらの概念をさらに説明します。
The requirements distinguish two major L2VPN models, a Virtual Private Wire Service (VPWS), and a Virtual Private LAN Service (VPLS).
この要件は、2つの主要なL2VPNモデル、仮想プライベートワイヤサービス（VPWS）と仮想プライベートLANサービス（VPLS）を区別しています。
The following diagram shows an L2VPN reference model.
次の図は、L2VPN参照モデルを示しています。
+-----+ +-----+
+ CE1 +--+ +---| CE2 |
+-----+ | ........................ | +-----+
L2VPN A | +----+ +----+ | L2VPN A
+--| PE |--- Service ---| PE |--+
+----+ Provider +----+
/ . Backbone . \ - /\-_
+-----+ / . | . \ / \ / \ +-----+
+ CE4 +--+ . | . +--\ Access \----| CE5 |
+-----+ . +----+ . | Network | +-----+
L2VPN B .........| PE |......... \ / L2VPN B
+----+ ^ -------
| |
| |
+-----+ |
| CE3 | +-- Logical switching instance
+-----+
L2VPN A
Figure 1. L2VPN Reference Model
図1. L2VPN参照モデル
The PE devices provide a logical interconnect such that a pair of CE devices appears to be connected by a single logical Layer 2 circuit. PE devices act as Layer 2 circuit switches. Layer 2 circuits are then mapped onto tunnels in the SP network. These tunnels can either be specific to a particular VPWS, or be shared among several services. VPWS applies for all services, including Ethernet, ATM, Frame Relay, etc. In Figure 1, L2VPN B represents a VPWS case.
PEデバイスは、CEデバイスのペアが単一の論理レイヤー2回路で接続されているように見えるように、論理的な相互接続を提供します。PEデバイスは、レイヤー2回路スイッチとして機能します。次に、レイヤー2回路がSPネットワークのトンネルにマッピングされます。これらのトンネルは、特定のVPWに固有のものであるか、いくつかのサービス間で共有できます。VPWSは、イーサネット、ATM、フレームリレーなどを含むすべてのサービスに適用されます。図1のL2VPN BはVPWSケースを表しています。
Each PE device is responsible for allocating customer Layer 2 frames to the appropriate VPWS and for proper forwarding to the intended destinations.
各PEデバイスは、顧客レイヤー2フレームを適切なVPWに割り当て、意図した目的地への適切な転送を担当します。
In case of VPLS, the PE devices provide a logical interconnect such that CE devices belonging to a specific VPLS appear to be connected by a single LAN. End-to-end VPLS consists of a bridge module and a LAN emulation module ([RFC4664]). A VPLS can contain a single VLAN or multiple VLANs ([IEEE_802.1Q]). A variation of this service is IPLS ([RFC4664]), which is limited to supporting only customer IP traffic.
VPLSの場合、PEデバイスは、特定のVPLSに属するCEデバイスが単一のLANで接続されているように見えるように論理的な相互接続を提供します。エンドツーエンドのVPLSは、ブリッジモジュールとLANエミュレーションモジュール（[RFC4664]）で構成されています。VPLSには、単一のVLANまたは複数のVLAN（[IEEE_802.1Q]）を含めることができます。このサービスのバリエーションはIPLS（[RFC4664]）であり、これは顧客IPトラフィックのみをサポートすることに限定されています。
In a VPLS, a customer site receives Layer 2 service from the SP. The PE is attached via an access connection to one or more CEs. The PE performs forwarding of user data packets based on information in the Layer 2 header, such as a MAC destination address. In Figure 1, L2VPN A represents a VPLS case.
VPLSでは、カスタマーサイトはSPからレイヤー2サービスを受信します。PEは、1つ以上のCESへのアクセス接続を介して接続されます。PEは、MAC宛先アドレスなど、レイヤー2ヘッダーの情報に基づいてユーザーデータパケットの転送を実行します。図1では、L2VPN AはVPLSケースを表します。
The details of VPLS reference model, which we summarize here, can be found in [RFC4664]. In VPLS, the PE can be viewed as containing a Virtual Switching Instance (VSI) for each L2VPN that it serves. A CE device attaches, possibly through an access network, to a bridge module of a PE. Within the PE, the bridge module attaches, through an Emulated LAN Interface to an Emulated LAN. For each VPLS, there is an Emulated LAN instance. The Emulated LAN consists of VPLS Forwarder module (one per PE per VPLS service instance) connected by pseudo wires (PW), where the PWs may be traveling through Packet Switched Network (PSN) tunnels over a routed backbone. VSI is a logical entity that contains a VPLS forwarder module and part of the bridge module relevant to the VPLS service instance [RFC4664]. Hence, the VSI terminates PWs for interconnection with other VSIs and also terminates Attachment Circuits (ACs) (see [RFC3985] for definition) for accommodating CEs. A VSI includes the forwarding information base for an L2VPN [RFC4664] which is the set of information regarding how to forward Layer 2 frames received over the AC from the CE to VSIs in other PEs supporting the same L2VPN service (and/or to other ACs), and it contains information regarding how to forward Layer 2 frames received from PWs to ACs. Forwarding information bases can be populated dynamically (such as by source MAC address learning) or statically (e.g., by configuration). Each PE device is responsible for proper forwarding of the customer traffic to the appropriate destination(s) based on the forwarding information base of the corresponding VSI.
ここで要約するVPLS参照モデルの詳細は、[RFC4664]に記載されています。VPLでは、PEは、サービスを提供する各L2VPNの仮想スイッチングインスタンス（VSI）を含むと見なすことができます。CEデバイスは、おそらくアクセスネットワークを介して、PEのブリッジモジュールに取り付けられます。PE内では、エミュレートされたLANインターフェイスを介してエミュレートされたLANへのブリッジモジュールが取り付けられます。各VPLについて、エミュレートされたLANインスタンスがあります。エミュレートされたLANは、擬似ワイヤ（PW）で接続されたVPLSフォワードモジュール（VPLSサービスインスタンスごとに1つ）で構成されています。PWは、ルーティングされたバックボーンを越えてパケットスイッチ付きネットワーク（PSN）トンネルを走行している可能性があります。VSIは、VPLSフォワードモジュールとVPLSサービスインスタンス[RFC4664]に関連するブリッジモジュールの一部を含む論理エンティティです。したがって、VSIは他のVSIとの相互接続のためにPWSを終了し、CESに対応するためのアタッチメントサーキット（ACS）（[RFC3985]を参照）（[RFC3985]を参照）も終了します。VSIには、L2VPN [RFC4664]の転送情報ベースが含まれています。これは、同じL2VPNサービス（および/または他のACSに支持する他のPESで、CEからVSIにACを介して受信したレイヤー2フレームを転送する方法に関する情報セットです。）、およびPWSからACSに受信したレイヤー2フレームを転送する方法に関する情報が含まれています。情報ベースは、動的に（ソースMACアドレス学習など）または静的（たとえば、構成による）に入力できます。各PEデバイスは、対応するVSIの転送情報ベースに基づいて、適切な宛先への顧客トラフィックの適切な転送を担当します。
This section contains requirements that apply to both the customer and the provider, or that are of an otherwise general nature.
このセクションには、顧客とプロバイダーの両方に適用される要件、またはそうでなければ一般的な性質の要件が含まれています。
L2VPN protocols SHOULD NOT interfere with existing Layer 2 protocols and standards of the Layer 2 network the customer is managing. If they impact customer Layer 2 protocols that are sent over the VPLS, then these impacts MUST be documented.
L2VPNプロトコルは、既存のレイヤー2プロトコルと顧客が管理しているレイヤー2ネットワークの標準に干渉しないでください。VPLSを介して送信される2つのプロトコルに影響を与える場合、これらの影響を文書化する必要があります。
Some possibly salient differences between VPLS and a real LAN are:
VPLSと実際のLANの間の顕著な違いは次のとおりです。
- The reliability may likely be less, i.e., the probability that a message broadcast over the VPLS is not seen by one of the bridge modules in PEs is higher than in a true Ethernet.
- 信頼性は低い可能性があります。つまり、VPLS上でブロードキャストされるメッセージがPESのブリッジモジュールの1つによって見られない確率は、真のイーサネットよりも高くなります。
- VPLS frames can get duplicated if the PW sequencing option isn't turned on. The data frames on the PWs are sent in IP datagrams, and under certain failure scenarios, IP networks can duplicate packets. If the PW data transmission protocol does not ensure sequence of data packets, frames can be duplicated or received out of sequence. If the customer's Bridge Protocol Data Unit (BPDU) frames are sent as data packets, then BPDU frames can be duplicated or mis-sequenced, although this may not create any problems for Real-Time Streaming Protocol (RSTP).
- PWシーケンスオプションがオンになっていない場合、VPLSフレームは複製される可能性があります。PWSのデータフレームはIPデータグラムで送信され、特定の障害シナリオでは、IPネットワークがパケットを複製できます。PWデータ送信プロトコルがデータパケットのシーケンスを保証しない場合、フレームを複製またはシーケンスから受信することができます。顧客のブリッジプロトコルデータユニット（BPDU）フレームがデータパケットとして送信される場合、BPDUフレームを複製または誤って並べ替えることができますが、リアルタイムストリーミングプロトコル（RSTP）に問題が発生しない場合があります。
- Delayed delivery of packets (e.g., more than half a second), rather than dropping them, could have adverse effect on the performance of the service.
- パケットの配送の遅延（たとえば、0.5秒以上）をドロップするのではなく、サービスのパフォーマンスに悪影響を与える可能性があります。
- 802.3x Pause frames will not be transported over a VPLS, as the bridge module ([RFC4664]) in the PE terminates them.
- PEのブリッジモジュール（[RFC4664]）がそれらを終了するため、802.3xの一時型フレームはVPLSに輸送されません。
- Since the IPLS solution aims at transporting encapsulated traffic (rather than Layer 2 frames themselves), the IPLS solution is NOT REQUIRED to preserve the Layer 2 Header transparently from CE to CE. For example, Source MAC address will probably not be preserved by the IPLS solution.
- IPLSソリューションは、カプセル化されたトラフィックを輸送することを目的としているため（レイヤー2フレーム自体ではなく）、IPLSソリューションは、レイヤー2ヘッダーをCEからCEに透過的に保存する必要はありません。たとえば、ソースMACアドレスはおそらくIPLSソリューションによって保存されないでしょう。
A VPLS MUST support unicast, multicast, and broadcast traffic. Support for efficient replication of broadcast and multicast traffic is highly desirable.
VPLは、ユニキャスト、マルチキャスト、ブロードキャストトラフィックをサポートする必要があります。ブロードキャストとマルチキャストトラフィックの効率的な複製のサポートが非常に望ましいです。
A SP network may be realized using one or more network tunnel topologies to interconnect PEs, ranging from simple point-to-point to distributed hierarchical arrangements. The typical topologies include:
SPネットワークは、1つ以上のネットワークトンネルトポロジーを使用して、単純なポイントツーポイントから分散階層配置に至るまで、PESを相互接続することができます。典型的なトポロジには次のものがあります。
- Point-to-point - Point-to-multipoint, a.k.a. hub and spoke - Any-to-any, a.k.a. full mesh - Mixed, a.k.a. partial mesh - Hierarchical
- ポイントツーポイント - ポイントツーマルチポイント、a.k.a。huband spoke- any-to-any、a.k.a。full mesh- mixed、a.k.a。partial mesh-階層
Regardless of the SP topology employed, the service to the customers MUST retain the connectivity type implied by the type of L2VPN. For example, a VPLS MUST allow multipoint-to-multipoint connectivity even if it is implemented with point-to-point circuits. This requirement does not imply that all traffic characteristics (such as bandwidth, QoS, delay, etc.) necessarily be the same between any two end points of an L2VPN. It is important to note that SLS requirements of a service have a bearing on the type of topology that can be used.
採用されているSPトポロジに関係なく、顧客へのサービスは、L2VPNのタイプによって暗示される接続タイプを保持する必要があります。たとえば、VPLは、ポイントツーポイント回路で実装されていても、マルチポイント間接続を許可する必要があります。この要件は、すべてのトラフィック特性（帯域幅、QoS、遅延など）がL2VPNの任意の2つのエンドポイント間で必然的に同じであることを意味するものではありません。サービスのSLS要件は、使用できるトポロジの種類に関係していることに注意することが重要です。
To the extent possible, an L2VPN service SHOULD be capable of crossing multiple administrative boundaries.
可能な限り、L2VPNサービスは複数の管理境界を越えることができる必要があります。
To the extent possible, the L2VPN services SHOULD be independent of access network technology.
可能な限り、L2VPNサービスはアクセスネットワークテクノロジーとは独立している必要があります。
L2VPN solutions SHALL define means that prevent CEs in an L2VPN from interaction with unauthorized entities.
L2VPNソリューションは、L2VPN内のCESが不正なエンティティとの相互作用を防ぐ手段を定義するものとします。
L2VPN solutions SHALL avoid introducing undesired forwarding information that could corrupt the L2VPN forwarding information base.
L2VPNソリューションは、L2VPN転送情報ベースを破損する可能性のある望ましくない転送情報の導入を避けなければなりません。
A means to constrain or isolate the distribution of addressed data to only those VPLS sites determined either by MAC learning and/or configuration MUST be provided.
アドレス指定されたデータの分布を、MAC学習および/または構成によって決定されるVPLSサイトのみに制約または分離する手段を提供する必要があります。
The internal structure of an L2VPN SHOULD not be advertised or discoverable from outside that L2VPN.
L2VPNの内部構造は、そのL2VPNの外部から宣伝または発見しないでください。
A range of security features MUST be supported by the suite of L2VPN solutions. Each L2VPN solution MUST state which security features it supports and how such features can be configured on a per-customer basis.
さまざまなセキュリティ機能を、L2VPNソリューションのスイートでサポートする必要があります。各L2VPNソリューションは、どのセキュリティ機能がサポートするか、およびそのような機能を顧客ごとに構成する方法を述べる必要があります。
A number of security concerns arise in the setup and operation of an L2VPN, ranging from misconfigurations to attacks that can be launched on an L2VPN and can strain network resources such as memory space, forwarding information base table, bandwidth, and CPU processing.
L2VPNのセットアップと操作では、誤った採掘からL2VPNで起動し、メモリスペース、情報ベーステーブル、帯域幅、CPU処理などのネットワークリソースを引き受けることができる攻撃に至るまで、多くのセキュリティ上の懸念が生じます。
This section lists some potential security hazards that can result due to mis-configurations and/or malicious attacks. There MUST be methods available to protect against the following situations.
このセクションには、間違っている攻撃や悪意のある攻撃が原因で発生する可能性のあるセキュリティの危険性がいくつかリストされています。次の状況から保護する方法が必要です。
- Protocol attacks o Excessive protocol adjacency setup/teardown o Excessive protocol signaling/withdrawal
- プロトコル攻撃過剰なプロトコル隣接隣接セットアップ/分解o過剰なプロトコルシグナル/撤退
- Resource Utilization o Forwarding plane replication (VPLS) o Looping (VPLS primarily) o MAC learning table size limit (VPLS)
- リソース利用o転送面レプリケーション（VPLS）oループ（主にVPL）o Mac学習テーブルサイズ制限（VPLS）
- Unauthorized access o Unauthorized member of VPN o Incorrect customer interface o Incorrect service delimiting VLAN tag o Unauthorized access to PE
- 不正アクセスo VPNの不正なメンバーo誤った顧客インターフェイスo誤ったサービスVLANタグo PEへの不正アクセスを区切る
- Tampering with signaling o Incorrect FEC signaling o Incorrect PW label assignment o Incorrect signaled VPN parameters (e.g., QoS, MTU, etc.)
- シグナリングの改ざんo誤ったFECシグナル伝達o誤ったPWラベル割り当てo誤ったシグナル付きVPNパラメーター（QoS、MTUなど）
- Tampering with data forwarding o Incorrect MAC learning entry o Incorrect PW label o Incorrect AC identifier o Incorrect customer facing encapsulation o Incorrect PW encapsulation o Hijacking PWs using the wrong tunnel o Incorrect tunnel encapsulation
- データ転送の改ざんo誤ったMac学習エントリo誤ったPWラベルo誤ったAC識別子oカプセル化に直面する誤った顧客o誤ったPWカプセル化o間違ったトンネルを使用してPWSをハイジャックする誤ったトンネルカプセル化
An L2VPN solution MUST provide traffic separation between different L2VPNs.
L2VPNソリューションは、異なるL2VPN間の交通分離を提供する必要があります。
In case of VPLS, VLAN Ids MAY be used as service delimiters. When used in this manner, they MUST be honored and traffic separation MUST be provided.
VPLSの場合、VLAN IDはサービスデリミターとして使用できます。この方法で使用する場合、それらは尊重され、交通分離を提供する必要があります。
An L2VPN solution MAY also have the ability to activate the appropriate filtering capabilities upon request of a customer.
L2VPNソリューションは、顧客の要求に応じて適切なフィルタリング機能をアクティブにする機能を備えている場合があります。
An L2VPN solution MUST support overlapping addresses of different L2VPNs. For instance, customers MUST NOT be prevented from using the same MAC addresses with different L2VPNs. If a service provider uses VLANs as service delimiters, the L2VPN solution MUST ensure that VLAN Ids cannot overlap. If VLANs are not used as service delimiters, L2VPN solutions MAY allow VLAN Ids to overlap.
L2VPNソリューションは、異なるL2VPNの重複アドレスをサポートする必要があります。たとえば、顧客が異なるL2VPNを持つ同じMacアドレスを使用することを妨げられてはなりません。サービスプロバイダーがVLANをサービスデリミターとして使用する場合、L2VPNソリューションはVLAN IDが重複しないことを確認する必要があります。VLANがサービスデリミターとして使用されていない場合、L2VPNソリューションによりVLAN IDが重複する場合があります。
To the extent possible, L2VPN QoS SHOULD be independent of the access network technology.
可能な限り、L2VPN QOSはアクセスネットワークテクノロジーとは無関係である必要があります。
As provided in [RFC3809], an L2VPN SHALL be able to support QoS in one or more of the following already standardized modes:
[RFC3809]に規定されているように、L2VPNは、既に標準化されたモードの1つ以上でQoSをサポートできるものとします。
- Best Effort (support mandatory for all provider-provisioned VPN types)
- 最善の努力（すべてのプロバイダーが提供するVPNタイプに必須のサポート）
- Aggregate CE Interface Level QoS (i.e., 'hose' level)
- CEインターフェイスレベルQOS（つまり、「ホース」レベル）を集約する
- Site-to-site, or 'pipe' level QoS
- サイトからサイトへ、または「パイプ」レベルQos
Note that all cases involving QoS MAY require that the CE and/or PE perform shaping and/or policing.
QoSを含むすべてのケースでは、CEおよび/またはPEがシェーピングおよび/またはポリシングを実行する必要がある場合があることに注意してください。
Mappings or translations of Layer 2 QoS parameters into PSN QoS (e.g., DSCPs or MPLS EXP field) as well as QoS mapping based on VC (e.g., FR/ATM or VLAN) MAY be performed in order to provide QoS transparency. The actual mechanisms for these mappings or translations are outside the scope of this document. In addition, the Diffserv support of underlying tunneling technologies (e.g., [RFC3270] or [RFC3308]) and the Intserv model ([RFC2205]) MAY be used. As such, the L2VPN SLS requirements SHOULD be supported by appropriate core mechanisms.
QOS透明性を提供するために、VC（FR/ATMまたはVLANなど）に基づくQOSマッピングと同様に、QOSマッピングと同様に、QoS QOSマッピングと同様に、QOSマッピングをPSN QOS（例：DSCPSまたはMPLS EXPフィールド）にマッピングまたは翻訳するマッピングまたは翻訳が実行されます。これらのマッピングまたは翻訳の実際のメカニズムは、このドキュメントの範囲外です。さらに、基礎となるトンネル技術（例：[RFC3270]または[RFC3308]）およびINTSERVモデル（[RFC2205]）のDiffServサポートが使用される場合があります。そのため、L2VPN SLS要件は、適切なコアメカニズムによってサポートされる必要があります。
A service provider may desire to offer QoS service to a customer for at least the following generic service types: managed access VPN service or an edge-to-edge QoS service. The details of the service models can be found in [RFC3809] and in [RFC4031].
サービスプロバイダーは、少なくとも次の汎用サービスタイプのQOSサービスを顧客に提供することを望む場合があります：マネージドアクセスVPNサービスまたはエッジツーエッジQOSサービス。サービスモデルの詳細は、[RFC3809]および[RFC4031]にあります。
In L2VPN service, both DSCP ([RFC2474]) and 802.1p ([IEEE_802.1D]) fields may be used for this purpose.
L2VPNサービスでは、DSCP（[RFC2474]）と802.1P（[IEEE_802.1D]）の両方のフィールドをこの目的に使用できます。
For an L2VPN service, the capabilities for Service Level Specification (SLS) monitoring and reporting stated in [RFC3809] SHOULD be provided.
L2VPNサービスの場合、[RFC3809]に記載されているサービスレベル仕様（SLS）の監視とレポートの機能を提供する必要があります。
The L2VPN service infrastructure SHOULD provide redundant paths to ensure high availability. The reaction to failures SHOULD result in an attempt to restore the service using alternative paths.
L2VPNサービスインフラストラクチャは、高可用性を確保するために冗長なパスを提供する必要があります。障害に対する反応は、代替パスを使用してサービスを復元しようとすることになるはずです。
The intention is to keep the restoration time small. The restoration time MUST be less than the time it takes the CE devices, or customer Layer 2 control protocols as well as Layer 3 routing protocols, to detect a failure in the L2VPN.
意図は、修復時間を小さく保つことです。復元時間は、L2VPNの障害を検出するために、CEデバイスまたは顧客レイヤー2制御プロトコルとレイヤー3ルーティングプロトコルの時間よりも短くする必要があります。
The CE-to-PE links MAY be
CEからPEへのリンクはそうかもしれません
- direct physical links (e.g., 100BaseTX, and T1/E1 TDM), - logical links (e.g., ATM PVC, and RFC2427-encapsulated link), - transport networks carrying Ethernet, - a Layer 2 tunnel that goes through a Layer 3 network (e.g., L2TP sessions).
- 直接物理リンク（例：100Basetx、およびT1/E1 TDM）、 - 論理リンク（例：ATM PVC、およびRFC2427がカプセル化されたリンクなど）、 - イーサネットを運ぶトランスポートネットワーク、レイヤー3ネットワークを通過するレイヤー2トンネル（たとえば、L2TPセッション）。
Layer 2 frames MAY be tunneled through a Layer 3 backbone from PE to PE, using one of a variety of tunneling technologies (e.g., IP-in-IP, GRE, MPLS, L2TP, etc.).
レイヤー2フレームは、さまざまなトンネリング技術（IP-in-IP、GRE、MPLS、L2TPなど）のいずれかを使用して、PEからPEまでのレイヤー3バックボーンを通してトンネル化できます。
Standard interfaces to manage L2VPN services MUST be provided (e.g., standard SNMP MIB Modules). These interfaces SHOULD provide access to configuration, verification and runtime monitoring protocols.
L2VPNサービスを管理するための標準インターフェイスを提供する必要があります（標準のSNMP MIBモジュールなど）。これらのインターフェイスは、構成、検証、ランタイム監視プロトコルへのアクセスを提供する必要があります。
Service management MAY include the TMN 'FCAPS' functionalities, as follows: Fault, Configuration, Accounting, Performance, and Security, as detailed in [ITU_Y.1311.1].
サービス管理には、[ITU_Y.1311.1]で詳述されているように、次のように、TMN 'FCAPS'機能を含む場合があります。
Multi-vendor interoperability, which corresponds to similar network and service levels among different implementations, at the network element SHOULD be guaranteed. This will likely rely on the completeness of the corresponding standard.
ネットワーク要素での異なる実装間で同様のネットワークおよびサービスレベルに対応するマルチベンダーの相互運用性を保証する必要があります。これは、対応する標準の完全性に依存する可能性があります。
The technical solution MUST be multi-vendor interoperable, not only within the SP network infrastructure, but also with the customer's network equipment and services making use of the L2VPN service.
技術的なソリューションは、SPネットワークインフラストラクチャ内だけでなく、L2VPNサービスを利用している顧客のネットワーク機器とサービスを使用して、マルチベンダーの相互運用可能でなければなりません。
A L2VPN solution SHOULD NOT preclude different access technologies. For instance, customer access connections to an L2VPN service MAY be different at different CE devices (e.g., Frame Relay, ATM, 802.1D, MPLS).
L2VPNソリューションは、さまざまなアクセステクノロジーを排除してはなりません。たとえば、L2VPNサービスへの顧客アクセス接続は、CEデバイスが異なる場合があります（Frame Relay、ATM、802.1D、MPLSなど）。
Inter-working scenarios among different solutions providing L2VPN services are highly desirable. It is possible to have cases that require inter-working or interconnection between customer sites, which span network domains with different L2VPN solutions or different implementations of the same approach. Inter-working SHOULD be supported in a scalable manner.
L2VPNサービスを提供するさまざまなソリューション間のワーキング間シナリオは非常に望ましいです。さまざまなL2VPNソリューションまたは同じアプローチの異なる実装でネットワークドメインをスパン化する顧客サイト間の相互作用または相互接続を必要とするケースを持つことができます。作業間は、スケーラブルな方法でサポートする必要があります。
Inter-working scenarios MUST consider at least traffic isolation, security, QoS, access, and management aspects. This requirement is essential in the case of network migration, to ensure service continuity among sites belonging to different portions of the network.
労働間シナリオは、少なくともトラフィックの分離、セキュリティ、QoS、アクセス、および管理の側面を考慮する必要があります。この要件は、ネットワークのさまざまな部分に属するサイト間のサービスの継続性を確保するために、ネットワーク移行の場合に不可欠です。
This section captures requirements from a customer perspective.
このセクションでは、顧客の観点から要件をキャプチャします。
Customers MAY require L2VPN service that spans multiple administrative domains or SP networks. Therefore, an L2VPN service MUST be able to span multiple AS and SP networks but still to act and to appear as a single, homogeneous L2VPN from a customer point of view.
顧客は、複数の管理ドメインまたはSPネットワークにまたがるL2VPNサービスを必要とする場合があります。したがって、L2VPNサービスは、複数のASとSPネットワークに及ぶことができる必要がありますが、それでも行動し、顧客の観点から単一の均質なL2VPNとして表示される必要があります。
A customer might also start with an L2VPN provided in a single AS with a certain SLS but then ask for an expansion of the service spanning multiple ASes and/or multiple-SPs. In this case, as well as for all kinds of multi-AS and multiple-SP L2VPNs, L2VPN service SHOULD be able to deliver the same SLS to all sites in a VPN regardless of the AS/SP to which it homes.
また、顧客は、特定のSLSと同様に、単一で提供されるL2VPNから始めることもできますが、複数のASEおよび/または複数SPSにまたがるサービスの拡張を求めます。この場合、あらゆる種類のマルチASおよび複数SP L2VPNSの場合、L2VPNサービスは、家庭のAS/SPに関係なく、VPNのすべてのサイトに同じSLSを配信できるはずです。
With the exception of IPLS, an L2VPN service SHOULD be agnostic to customer's Layer 3 traffic (e.g., IP, IPX, Appletalk) encapsulated within Layer 2 frames.
IPLSを除き、L2VPNサービスは、レイヤー2フレーム内にカプセル化された顧客のレイヤー3トラフィック（IP、IPX、AppleTalkなど）に不可知論される必要があります。
IPLS MUST allow transport of customer's IPv4 and IPv6 traffic encapsulated within Layer 2 frames. IPLS SHOULD also allow CEs to run ISIS and MPLS protocols transparently among them when those are used in conjunction with IP.
IPLは、レイヤー2フレーム内でカプセル化された顧客のIPv4およびIPv6トラフィックの輸送を許可する必要があります。また、IPLは、CESがIPと組み合わせて使用される場合、ISISおよびMPLSプロトコルを透過的に実行できるようにする必要があります。
QoS is expected to be an important aspect of an L2VPN service for some customers.
QoSは、一部の顧客にとってL2VPNサービスの重要な側面になると予想されます。
A customer requires that the L2VPN service provide the QoS applicable to his or her application, which can range from PWs (e.g., SONET emulation) to voice, interactive video, and multimedia applications. Hence, best-effort as well as delay and loss sensitive traffic MUST be supported over an L2VPN service. A customer application SHOULD experience consistent QoS independent of the access network technology used at different sites connected to the same L2VPN.
顧客は、L2VPNサービスが自分のアプリケーションに適用可能なQOを提供することを要求します。これは、PWS（SONETエミュレーションなど）から音声、インタラクティブビデオ、マルチメディアアプリケーションまでの範囲です。したがって、L2VPNサービスでは、ベストエフォルトと遅延および損失に敏感なトラフィックをサポートする必要があります。顧客アプリケーションは、同じL2VPNに接続されたさまざまなサイトで使用されるアクセスネットワークテクノロジーとは無関係に、一貫したQoSを経験する必要があります。
Most customers simply want their applications to perform well. A SLS is a vehicle for a customer to measure the quality of the service that SP(s) provide. Therefore, when purchasing a service, a customer requires access to the measures from the SP(s) that support the SLS.
ほとんどの顧客は、単にアプリケーションをうまく機能させることを望んでいます。SLSは、顧客がSP（S）が提供するサービスの品質を測定する手段です。したがって、サービスを購入する場合、顧客はSLSをサポートするSPからの測定値へのアクセスを必要とします。
Standard interfaces to monitor usage of L2VPN services SHOULD be provided (e.g., standard SNMP MIB Modules).
L2VPNサービスの使用を監視するための標準インターフェイスを提供する必要があります（標準のSNMP MIBモジュールなど）。
An L2VPN solution MUST provide traffic as well as forwarding information base isolation for customers similar to that obtained in private lines, FR, or ATM services.
L2VPNソリューションは、プライベートライン、FR、またはATMサービスで得られたものと同様の顧客に、トラフィックと転送情報ベースの分離を提供する必要があります。
An L2VPN service MAY use customer VLAN Ids as service delimiters. In that case, they MUST be honored, and traffic separation MUST be provided.
L2VPNサービスは、顧客VLAN IDをサービスデリミターとして使用する場合があります。その場合、それらは尊重されなければならず、交通分離を提供する必要があります。
An L2VPN solution MAY have the mechanisms to activate the appropriate filtering capabilities upon request of a customer. For instance, MAC and/or VLAN filtering MAY be considered between CE and PE for a VPLS.
L2VPNソリューションには、顧客の要求に応じて適切なフィルタリング機能をアクティブにするメカニズムがあります。たとえば、VPLSのCEとPEの間でMACおよび/またはVLANフィルタリングを考慮することができます。
An L2VPN solution MAY provide value-added security services such as encryption and/or authentication of customer packets, certificate management, and similar services.
L2VPNソリューションは、顧客パケットの暗号化や認証、証明書管理、および同様のサービスなどの付加価値のあるセキュリティサービスを提供する場合があります。
L2VPN services MUST NOT interfere with the security mechanisms employed at Layer 3 and higher layers by customers. Layer 2 security mechanisms, such as 802.10b ([IEEE_802.10]) and 802.1AE ([IEEE_802.1AE]), MAY inhibit L2VPN services, when the service delimiting VLAN Ids are encrypted.
L2VPNサービスは、レイヤー3および高レイヤーで採用されているセキュリティメカニズムを顧客によって干渉してはなりません。802.10B（[IEEE_802.10]）や802.1AE（[IEEE_802.1AE]）などのレイヤー2セキュリティメカニズムは、VLAN IDを削除するサービスが暗号化される場合、L2VPNサービスを阻害する場合があります。
Every packet exchanged between the customer and the SP over the access connection MUST appear as it would on a private network providing an equivalent service to that offered by the L2VPN.
顧客とSPの間でアクセス接続を介して交換されるすべてのパケットは、L2VPNが提供するものと同等のサービスを提供するプライベートネットワーク上に表示される必要があります。
L2VPN solutions SHOULD support a broad range of physical and link-layer access technologies, such as PSTN, ISDN, xDSL, cable modem, leased line, Ethernet, Ethernet VLAN, ATM, Frame Relay, Wireless local loop, mobile radio access, etc. The capacity and QoS achievable MAY be dependent on the specific access technology in use.
L2VPNソリューションは、PSTN、ISDN、XDSL、ケーブルモデム、リースライン、イーサネット、イーサネットVLAN、ATM、フレームリレー、ワイヤレスローカルループ、モバイルラジオアクセスなど、幅広い物理的およびリンクレイヤーアクセス技術をサポートする必要があります。達成可能な容量とQoSは、使用中の特定のアクセステクノロジーに依存する場合があります。
Various types of physical connectivity scenarios MUST be supported, such as multi-homed sites, backdoor links between customer sites, and devices homed to two or more SP networks. In case of VPLS, IEEE 802.3ad-2000 link aggregation SHOULD be supported. L2VPN solutions SHOULD support at least the types of physical or link-layer connectivity arrangements shown in Figures 2 - 4 (in addition to the case shown in Figure 1). As in Figure 2, a CE can be dual-homed to an SP or to two different SPs via diverse access networks.
マルチホームのサイト、顧客サイト間のバックドアリンク、2つ以上のSPネットワークに拠点を置くデバイスなど、さまざまな種類の物理的な接続シナリオをサポートする必要があります。VPLSの場合、IEEE 802.3AD-2000リンク集約をサポートする必要があります。L2VPNソリューションは、図2-4に示すように、少なくとも図2-4に示す種類の物理的またはリンク層接続の配置をサポートする必要があります（図1に示すケースに加えて）。図2のように、CEは、多様なアクセスネットワークを介してSPまたは2つの異なるSPSにデュアルホームすることができます。
+---------------- +---------------
| |
+------+ +------+
+---------| PE | +---------| PE |
| |device| | |device| SP network
| +------+ | +------+
+------+ | +------+ |
| CE | | | CE | +---------------
|device| | SP network |device| +---------------
+------+ | +------+ |
| +------+ | +------+
| | PE | | | PE |
+---------|device| +---------|device| SP network
+------+ +------+
| |
+---------------- +---------------
(a) (b)
Figure 2. Dual-Homed Access of CE Devices
図2. CEデバイスのデュアルホームアクセス
Resiliency of the L2VPN service can be further enhanced as shown in Figure 3, where CE's connected via a "back door" connection, connect to the same SP or to different SPs.
L2VPNサービスの弾力性は、図3に示すようにさらに強化できます。CEは「バックドア」接続を介して接続され、同じSPまたは異なるSPに接続します。
+---------------- +---------------
| |
+------+ +------+ +------+ +------+
| CE |-----| PE | | CE |-----| PE |
|device| |device| |device| |device| SP network
+------+ +------+ +------+ +------+
| | | |
| Backdoor | | Backdoor +---------------
| link | SP network | link +---------------
| | | |
+------+ +------+ +------+ +------+
| CE | | PE | | CE | | PE |
|device|-----|device| |device|-----|device| SP network
+------+ +------+ +------+ +------+
| |
+---------------- +---------------
(a) (b)
Figure 3. Backdoor Links Between CE Devices
図3. CEデバイス間のバックドアリンク
Arbitrary combinations of the above methods, with a few examples shown in Figure 4, SHOULD be supported by any L2VPN solution.
上記の方法の任意の組み合わせは、図4にいくつかの例を示し、任意のL2VPNソリューションでサポートする必要があります。
+---------------- +---------------
| |
+------+ +------+ +------+ +------+
| CE |-----| PE | | CE |-----| PE |
|device| |device| |device| |device| SP network
+------+\ +------+ +------+\ +------+
| \ | | \ |
|Back \ | |Back \ +-------------
|door \ | SP network |door \ +-------------
|link \ | |link \ |
+------+ +------+ +------+ +------+
| CE | | PE | | CE | | PE |
|device|-----|device| |device|-----|device| SP network
+------+ +------+ +------+ +------+
| |
+---------------- +---------------
(a) (b)
Figure 4. Combination of Dual-Homing and Backdoor Links for CE Devices
図4. CEデバイスのデュアルホーミングリンクとバックドアリンクの組み合わせ
A VPLS MUST deliver every packet at least to its intended destination(s) within the scope of the VPLS, subject to the ingress policing and security policies.
VPLは、少なくともすべてのパケットをVPLSの範囲内で意図した目的地に配信する必要があり、イングレスポリシングおよびセキュリティポリシーの対象となります。
During normal operation, the queuing and forwarding policies SHOULD preserve packet order for packets with the same QoS parameters.
通常の操作中、キューイングと転送ポリシーは、同じQoSパラメーターを使用してパケットのパケット注文を保持する必要があります。
A VPLS MUST support the theoretical MTU of the offered service.
VPLは、提供されたサービスの理論的MTUをサポートする必要があります。
The committed minimum MTU size MUST be the same for a given VPLS instance. Different L2VPN services MAY have different committed MTU sizes. If the customer VLANs are used as service delimiters, all VLANs within a given VPLS MUST inherit the same MTU size.
コミットされた最小MTUサイズは、特定のVPLSインスタンスで同じでなければなりません。L2VPNサービスが異なると、MTUサイズが異なる場合があります。顧客VLANがサービスデリミターとして使用される場合、特定のVPL内のすべてのVLANが同じMTUサイズを継承する必要があります。
A VPLS MAY use IP fragmentation if it presents reassembled packets at VPLS customer edge devices.
VPLSは、VPLSカスタマーエッジデバイスで再構築されたパケットを提示する場合、IPフラグメンテーションを使用する場合があります。
The L2VPN service MAY support translation of customers' AC identifiers (e.g., VLAN tags, if the customer VLANs are used as service delimiters). Such service simplifies connectivity of sites that want to keep their AC assignments or sites that belong to different administrative domains. In the latter case, the connectivity is sometimes referred to as Layer 2 extranet. On the other hand, it should be noted that VLAN tag translation affects the support for multiple spanning trees (i.e., 802.1s [IEEE_802.1s]) and can break the proper operation.
L2VPNサービスは、顧客のAC識別子の翻訳をサポートする場合があります（顧客VLANがサービスデリミターとして使用される場合、VLANタグなど）。このようなサービスは、さまざまな管理ドメインに属するAC割り当てまたはサイトを保持したいサイトの接続性を簡素化します。後者の場合、接続性はレイヤー2エクストラネットと呼ばれることがあります。一方、VLANタグの翻訳は、複数のスパンニングツリー（つまり、802.1S [IEEE_802.1S]）のサポートに影響し、適切な動作を破ることができることに注意する必要があります。
The L2VPN service is intended to be transparent to Layer 2 customer networks. An L2VPN solution SHOULD NOT require any special packet processing by the end users before sending packets to the provider's network.
L2VPNサービスは、レイヤー2の顧客ネットワークに対して透過的であることを目的としています。L2VPNソリューションは、プロバイダーのネットワークにパケットを送信する前に、エンドユーザーによる特別なパケット処理を必要としないはずです。
If VLAN Ids are assigned by the SP, then VLANs are not transparent. Transparency does not apply in this case, as it is the same as FR/ATM service model.
VLAN IDがSPによって割り当てられている場合、VLANは透過的ではありません。この場合、FR/ATMサービスモデルと同じであるため、透明性は適用されません。
Since the IPLS solution aims at transporting encapsulated traffic (rather than Layer 2 frames themselves), the IPLS solution MUST not alter the packets encapsulated inside Layer 2 frames that are transported by the IPLS. However, the IPLS solution is NOT REQUIRED to preserve the Layer 2 header transparently from CE to CE. For example, Source MAC address might not be preserved by the IPLS solution. The IPLS solution MAY remove Layer 2 headers for transport over the backbone when those can be reconstructed on egress without compromising transport of encapsulated traffic.
IPLSソリューションは、カプセル化されたトラフィックを輸送することを目的としているため（レイヤー2フレーム自体ではなく）、IPLSソリューションは、IPLSによって輸送されるレイヤー2フレーム内にカプセル化されたパケットを変更してはなりません。ただし、IPLSソリューションは、CEからCEへのレイヤー2ヘッダーを透過的に保存するために必要ありません。たとえば、ソースMACアドレスは、IPLSソリューションによって保存されない場合があります。IPLSソリューションは、カプセル化されたトラフィックの輸送を損なうことなく、脱出時に再構築できる場合、バックボーン上の輸送用のレイヤー2ヘッダーを除去する場合があります。
The L2VPN solution SHOULD allow transparent operation of Layer 2 control protocols employed by customers.
L2VPNソリューションは、顧客が採用したレイヤー2コントロールプロトコルの透明な動作を可能にする必要があります。
In case of VPLS, the L2VPN service MUST ensure that loops be prevented. This can be accomplished with a loop-free topology or appropriate forwarding rules. Control protocols such as Spanning Tree (STP) or similar protocols could be employed. The L2VPN solution MAY use indications from customer Layer 2 control protocols, e.g., STP BPDU snooping, to improve the operation of a VPLS.
VPLSの場合、L2VPNサービスはループを防ぐことを確認する必要があります。これは、ループフリートポロジまたは適切な転送ルールで実現できます。スパニングツリー（STP）などのコントロールプロトコルを使用することができます。L2VPNソリューションは、VPLSの動作を改善するために、顧客レイヤー2コントロールプロトコル、たとえばSTP BPDUスヌーピングからの適応症を使用する場合があります。
The L2VPN solution MUST require only minimal or no configuration on the CE devices, depending on the type of CE device that connects into the infrastructure.
L2VPNソリューションは、インフラストラクチャに接続するCEデバイスのタイプに応じて、CEデバイスの最小または構成のみを必要とする必要があります。
This section describes requirements from an SP perspective.
このセクションでは、SPの観点からの要件について説明します。
This section contains projections regarding L2VPN sizing and scalability requirements and metrics specific to particular solutions.
このセクションには、L2VPNサイジングとスケーラビリティ要件、および特定のソリューションに固有のメトリックに関する予測が含まれています。
[RFC3809] lists projections regarding L2VPN sizing and scalability requirements and metrics. The examples are provided in [RFC3809].
[RFC3809]は、L2VPNサイジングとスケーラビリティの要件とメトリックに関する予測をリストしています。例は[RFC3809]に記載されています。
Each L2VPN solution SHALL document its scalability characteristics in quantitative terms.
各L2VPNソリューションは、そのスケーラビリティ特性を定量的に文書化するものとします。
An SP domain MUST be uniquely identified at least within the set of all interconnected SP networks when supporting an L2VPN that spans multiple SPs. Ideally, this identifier SHOULD be globally unique (e.g., an AS number).
SPドメインは、複数のSPSにまたがるL2VPNをサポートする場合、少なくともすべての相互接続されたSPネットワークのセット内で一意に識別する必要があります。理想的には、この識別子はグローバルに一意でなければなりません（例：AS数）。
An identifier for each L2VPN SHOULD be unique, at least within each SP's network, as it MAY be used in auto-discovery, management (e.g., alarm and service correlation, troubleshooting, performance statistics collection), and signaling. Ideally, the L2VPN identifier SHOULD be globally unique to support the case, where an L2VPN spans multiple SPs (e.g., [RFC2685]). Globally unique identifiers facilitate the support of inter-AS/SP L2VPNs.
各L2VPNの識別子は、少なくとも各SPのネットワーク内で一意である必要があります。これは、自動発見、管理（アラームとサービスの相関、トラブルシューティング、パフォーマンス統計コレクションなど）、シグナリングで使用される可能性があるためです。理想的には、L2VPN識別子は、L2VPNが複数のSPSにまたがるケースをサポートするためにグローバルに一意である必要があります（例：[RFC2685]）。グローバルに一意の識別子は、AS/SP L2VPNSのサポートを促進します。
Configuration of PE devices (i.e., U-PE and N-PE [RFC4664]) is a significant task for an SP. Solutions SHOULD provide methods that dynamically allow L2VPN information to be discovered by the PEs to minimize the configuration steps.
PEデバイスの構成（つまり、U-PEおよびN-PE [RFC4664]）は、SP。ソリューションは、構成手順を最小化するために、PESによってL2VPN情報を動的に検出できるようにする方法を提供する必要があります。
Each device in an L2VPN SHOULD be able to determine which other devices belong to the same L2VPN. Such a membership discovery scheme MUST prevent unauthorized access, and it allows authentication of the source.
L2VPNの各デバイスは、同じL2VPNに属する他のデバイスを決定できる必要があります。このようなメンバーシップ発見スキームは、不正アクセスを防ぐ必要があり、ソースの認証を可能にします。
Distribution of L2VPN information SHOULD be limited to those devices involved in that L2VPN. An L2VPN solution SHOULD employ discovery mechanisms to minimize the amount of operational information maintained by the SPs. For example, if an SP adds or removes a customer port on a given PE, the remaining PEs SHOULD determine the necessary actions to take without the SP's having to explicitly reconfigure those PEs.
L2VPN情報の分布は、そのL2VPNに関与するデバイスに限定する必要があります。L2VPNソリューションは、発見メカニズムを使用して、SPSが維持する運用情報の量を最小限に抑える必要があります。たとえば、SPが特定のPEに顧客ポートを追加または削除する場合、残りのPEは、SPがそれらのPEを明示的に再構成する必要なく、必要なアクションを決定する必要があります。
A L2VPN solution SHOULD support the means for attached CEs to authenticate each other and to verify that the SP L2VPN is correctly connected.
L2VPNソリューションは、接続されたCESが相互に認証する手段をサポートし、SP L2VPNが正しく接続されていることを確認する必要があります。
The mechanism SHOULD respond to L2VPN membership changes in a timely manner. A "timely manner" is no longer than the provisioning timeframe, typically on the order of minutes, and MAY be as short as the timeframe required for "rerouting," typically on the order of seconds.
メカニズムは、タイムリーにL2VPNメンバーシップの変更に応答する必要があります。「タイムリーな方法」は、通常は数分の順序でプロビジョニングの時間枠にすぎません。また、通常は秒程度の「再ルーティング」に必要な時間枠と同じくらい短い場合があります。
Dynamically creating, changing, and managing multiple L2VPN assignments to sites and/or customers is another aspect of membership that MUST be addressed in an L2VPN solution.
複数のL2VPN割り当てをサイトおよび/または顧客に動的に作成、変更、および管理することは、L2VPNソリューションで対処する必要があるメンバーシップのもう1つの側面です。
A significant aspect of a provider-provisioned VPN is support for QoS. An SP has control over the provisioning of resources and configuration of parameters in at least the PE and P devices, and in some cases the CE devices as well. Therefore, the SP is to provide either managed QoS access service, or edge-to-edge QoS service, as defined in [RFC4031].
プロバイダーが提供するVPNの重要な側面は、QoSのサポートです。SPは、少なくともPEおよびPデバイス、場合によってはCEデバイスでも、リソースのプロビジョニングとパラメーターの構成を制御します。したがって、SPは、[RFC4031]で定義されているように、管理されたQoSアクセスサービス、またはエッジツーエッジQoSサービスを提供することです。
From a high level SP perspective, an L2VPN MUST isolate the exchange of traffic and forwarding information to only those sites that are authenticated and authorized members of an L2VPN.
高レベルのSPの観点からは、L2VPNは、トラフィックと転送情報の交換を、L2VPNの認証および承認されたメンバーのサイトのみに分離する必要があります。
An L2VPN solution SHOULD provide a means for meeting provider-provisioned VPN QoS SLS requirements that isolates L2VPN traffic from the affects of traffic offered by non-VPN customers. Also, L2VPN solutions SHOULD provide a means so that traffic congestion produced by sites as part of one L2VPN does not affect another L2VPN.
L2VPNソリューションは、非VPN顧客が提供するトラフィックの影響からL2VPNトラフィックを分離するプロバイダーが提供するVPN QOS SLS要件を満たすための手段を提供する必要があります。また、L2VPNソリューションは、1つのL2VPNの一部としてサイトによって生成されるトラフィック渋滞が別のL2VPNに影響しないように手段を提供する必要があります。
The security requirements are stated in Section 6.5. The security requirements provided in [RFC3809] SHOULD be met. The security requirements, except Layer 3 and higher-layer dependent ones, specified in [RFC4031], SHOULD be met.
セキュリティ要件は、セクション6.5に記載されています。[RFC3809]で提供されるセキュリティ要件を満たす必要があります。[RFC4031]で指定されているレイヤー3および高層層に依存するものを除くセキュリティ要件を満たす必要があります。
In addition, an SP network MUST be protected against malformed or maliciously constructed customer traffic. This includes but is not limited to duplicate or invalid Layer 2 addresses, customer side loops, short/long packets, spoofed management packets, spoofed VLAN tags, high volume traffic.
さらに、SPネットワークは、奇形または悪意のある構築された顧客トラフィックから保護する必要があります。これには、レイヤー2の重複または無効なアドレス、顧客サイドループ、短/長いパケット、スプーフィングされた管理パケット、スプーフィングされたVLANタグ、大量のトラフィックが含まれますが、これらに限定されません。
The SP network devices MUST NOT be accessible from any L2VPN, unless specifically authorized. The devices in the SP network SHOULD provide some means of reporting intrusion attempts to the SP, if the intrusion is detected.
SPネットワークデバイスは、具体的に許可されていない限り、任意のL2VPNからアクセスできないでください。SPネットワークのデバイスは、侵入が検出された場合、SPに侵入の試みを報告する手段を提供する必要があります。
When an L2VPN solution operates over a part of the Internet, it should support a configurable option to support one or more of the following standard IPsec methods for securing a customer's VPN traffic:
L2VPNソリューションがインターネットの一部で動作する場合、顧客のVPNトラフィックを保護するための次の標準IPSECメソッドの1つ以上をサポートする構成可能なオプションをサポートする必要があります。
- Confidentiality, so that only authorized devices can decrypt it
- 機密性、承認されたデバイスのみがそれを復号化できるように
- Integrity, to ensure that the data has not been altered
- 整合性、データが変更されていないことを確認する
- Authentication, to ensure that the sender is indeed who he or she claims to be
- 認証、送信者が実際に彼または彼女が誰であると主張するかを確実にするために
- Replay attack prevention.
- リプレイ攻撃防止。
The above functions SHOULD be applicable to "data traffic" of the customer, which includes the traffic exchanged between sites. It SHOULD also be possible to apply these functions to "control traffic", such as routing or signaling protocol exchanges, that is not necessarily perceived by the customer but is nevertheless essential to maintain his or her VPN.
上記の機能は、サイト間で交換されるトラフィックを含む顧客の「データトラフィック」に適用する必要があります。また、これらの機能を、ルーティングやシグナリングプロトコル交換などの「トラフィックの制御」に適用することも可能です。
Furthermore, such security methods MUST be configurable between different end-points, such as PE-PE and PE-MTU, only in the case where L2VPN data traffic is carried over IP [RFC4023]. Methods to secure data flows at the native service layer (Layer-2), from CE-CE, CE-MTU and CE-PE, are outside the scope of this document. It is also desirable to configure security on a per-VPN basis.
さらに、このようなセキュリティ方法は、L2VPNデータトラフィックがIPに搭載されている場合にのみ、PE-PEやPe-MTUなどの異なるエンドポイント間で構成可能でなければなりません[RFC4023]。CE-CE、CE-MTU、CE-PEのネイティブサービスレイヤー（レイヤー2）でデータフローを保護する方法は、このドキュメントの範囲外です。また、VPNごとにセキュリティを構成することも望ましいです。
A VPN solution MAY support one or more encryption schemes, including AES, and 3DES. Encryption, decryption, and key management SHOULD be included in profiles as part of the security management system.
VPNソリューションは、AESおよび3DEを含む1つ以上の暗号化スキームをサポートする場合があります。暗号化、復号化、および主要な管理は、セキュリティ管理システムの一部としてプロファイルに含める必要があります。
All applicable SP requirements, such as traffic and forwarding information isolation, SLSes, management, security, provisioning, etc. MUST be preserved across adjacent ASes. The solution MUST describe the inter-SP network interface, encapsulation method(s), routing protocol(s), and all applicable parameters.
トラフィックや転送情報の分離、SLSE、管理、セキュリティ、プロビジョニングなどのすべての該当するSP要件は、隣接するASES全体で保存する必要があります。ソリューションは、SP間ネットワークインターフェイス、カプセル化方法、ルーティングプロトコル、およびすべての適用可能なパラメーターを記述する必要があります。
An L2VPN solution MUST provide the specifics of offering L2VPN services spanning multiple ASes and/or SPs.
L2VPNソリューションは、複数のASESおよび/またはSPSにまたがるL2VPNサービスを提供する詳細を提供する必要があります。
An L2VPN solution MUST support proper dissemination of operational parameters to all elements of an L2VPN service in the presence of multiple ASes and/or SPs. A L2VPN solution MUST employ mechanisms for sharing operational parameters between different ASes.
L2VPNソリューションは、複数のASEおよび/またはSPSの存在下で、L2VPNサービスのすべての要素への運用パラメーターの適切な普及をサポートする必要があります。L2VPNソリューションは、異なるASE間で運用パラメーターを共有するためのメカニズムを使用する必要があります。
An L2VPN solution SHOULD support policies for proper selection of operational parameters coming from different ASes. Similarly, an L2VPN solution SHOULD support policies for selecting information to be disseminated to different ASes.
L2VPNソリューションは、さまざまなASEから得られる運用パラメーターを適切に選択するためのポリシーをサポートする必要があります。同様に、L2VPNソリューションは、さまざまなASEに普及する情報を選択するためのポリシーをサポートする必要があります。
The general requirements for managing a single AS apply to a concatenation of ASes. A minimum subset of such capabilities is the following:
ASESの連結に適用するためのシングルを管理するための一般的な要件。このような機能の最小サブセットは次のとおりです。
- Diagnostic tools
- 診断ツール
- Secured access to one AS management system by another
- 1つの管理システムへの保護されたアクセスは、別の管理システムです
- Configuration request and status query tools
- 構成要求とステータスクエリツール
- Fault notification and trouble tracking tools
- 障害通知とトラブル追跡ツール
When an L2VPN spans multiple ASes, there is a need for a brokering mechanism that requests certain SLS parameters, such as bandwidth and QoS, from the other domains and/or networks involved in transferring traffic to various sites. The essential requirement is that a solution MUST be able to determine whether a set of ASes can establish and guarantee uniform QoS in support of a provider-provisioned VPN.
L2VPNが複数のASEに及ぶ場合、トラフィックをさまざまなサイトに転送することに関与する他のドメインやネットワークから、帯域幅やQOSなどの特定のSLSパラメーターを要求するブローカーメカニズムが必要です。本質的な要件は、ソリューションがプロバイダーがプロビジョニングされたVPNをサポートするために均一なQOを確立および保証できるかどうかを判断できる必要があることです。
The architecture MUST support the possibility of one SP's offering L2VPN service to another SP. One example is when one SP sells L2VPN service at wholesale to another SP, who then resells that L2VPN service to his or her customers.
アーキテクチャは、あるSPが別のSPにL2VPNサービスを提供する可能性をサポートする必要があります。1つの例は、あるSPが卸売でL2VPNサービスを別のSPに販売し、その後、そのL2VPNサービスを顧客に再販する場合です。
Connectivity between CE sites or PE devices in the backbone SHOULD be able to use a range of tunneling technologies, such as L2TP, GRE, IP-in-IP, MPLS, etc.
バックボーン内のCEサイトまたはPEデバイス間の接続は、L2TP、GRE、IP-in-IP、MPLSなどのさまざまなトンネル技術を使用できる必要があります。
Every PE MUST support a tunnel setup protocol, if tunneling is used. A PE MAY support static configuration. If employed, a tunnel establishment protocol SHOULD be capable of conveying information, such as the following:
すべてのPEは、トンネルが使用されている場合、トンネルセットアッププロトコルをサポートする必要があります。PEは静的構成をサポートする場合があります。雇用されている場合、トンネル設立プロトコルは、次のような情報を伝えることができる必要があります。
- Relevant identifiers
- 関連する識別子
- QoS/SLS parameters
- QOS/SLSパラメーター
- Restoration parameters
- 復元パラメーター
- Multiplexing identifiers
- 多重化識別子
- Security parameters
- セキュリティパラメーター
There MUST be a means to monitor the following aspects of tunnels:
トンネルの次の側面を監視する手段が必要です。
- Statistics, such as amount of time spent in the up and down state
- 上下状態で費やされる時間などの統計
- Count of transitions between the up and down state
- 上下状態の間の移行のカウント
- Events, such as transitions between the up and down states
- 上下の状態間の移行などのイベント
The tunneling technology used by the VPN SP and its associated mechanisms for tunnel establishment, multiplexing, and maintenance MUST meet the requirements on scaling, isolation, security, QoS, manageability, etc.
VPN SPと、トンネルの確立、多重化、およびメンテナンスに関連するメカニズムが使用するトンネル技術は、スケーリング、分離、セキュリティ、QoS、管理可能性などの要件を満たす必要があります。
Regardless of the tunneling choice, the existence of the tunnels and their operations MUST be transparent to the customers.
トンネルの選択に関係なく、トンネルの存在とその運用は顧客に対して透明でなければなりません。
The connectivity between PE and CE devices is referred to as an AC. ACs MAY span networks of other providers or public networks.
PEデバイスとCEデバイス間の接続性は、ACと呼ばれます。ACSは、他のプロバイダーまたはパブリックネットワークのネットワークにまたがる場合があります。
There are several choices for implementing ACs. Some popular choices include Ethernet, ATM (DSL), Frame Relay, MPLS-based virtual circuits etc.
ACSを実装するためのいくつかの選択肢があります。いくつかの一般的な選択肢には、イーサネット、ATM（DSL）、フレームリレー、MPLSベースの仮想回路などが含まれます。
In case of VPLS, the AC MUST use Ethernet frames as the Service Protocol Data Unit (SPDU).
VPLSの場合、ACはサービスプロトコルデータユニット（SPDU）としてイーサネットフレームを使用する必要があります。
A CE access connection over an AC MUST be bi-directional.
AC上のCEアクセス接続は、双方向でなければなりません。
PE devices MAY support multiple ACs on a single physical interface. In such cases, PE devices MUST NOT rely on customer controlled parameters for distinguishing between different access connections. For example, if VLAN tags were used for that purpose, the provider would be controlling the assignment of the VLAN tag values and would strictly enforce compliance by the CEs.
PEデバイスは、単一の物理インターフェイスで複数のACSをサポートする場合があります。そのような場合、PEデバイスは、異なるアクセス接続を区別するために顧客制御されたパラメーターに依存してはなりません。たとえば、VLANタグがその目的に使用された場合、プロバイダーはVLANタグ値の割り当てを制御し、CESによるコンプライアンスを厳密に施行します。
An AC, whether direct or virtual, MUST maintain all committed characteristics of the customer traffic, such as QoS, priorities etc. The characteristics of an AC are only applicable to that connection.
ACは、直接的であろうと仮想であろうと、QoS、優先順位など、顧客トラフィックのすべてのコミットされた特性を維持する必要があります。ACの特性は、その接続にのみ適用されます。
Ideally, the backbone interconnecting the SP's PE and P devices SHOULD be independent of physical and link-layer technology. Nevertheless, the characteristics of backbone technology MUST be taken into account when specifying the QoS aspects of SLSes for VPN service offerings.
理想的には、SPのPEデバイスとPデバイスを相互接続するバックボーンは、物理的およびリンク層技術とは無関係でなければなりません。それにもかかわらず、VPNサービス製品のSLSEのQOS側面を指定する際には、バックボーン技術の特性を考慮する必要があります。
In case network resources such as memory space, forwarding information base table, bandwidth, and CPU processing are shared between L2VPNs, the solution SHOULD guarantee availability of resources necessary to prevent any specific L2VPN service instance from taking up available network resources and causing others to fail. The solution SHOULD be able to limit the resources consumed by an L2VPN service instance. The solution SHOULD guarantee availability of resources necessary to fulfill the obligation of committed SLSes.
メモリスペース、転送情報ベーステーブル、帯域幅、CPU処理などのネットワークリソースがL2VPN間で共有される場合、ソリューションは、特定のL2VPNサービスインスタンスが利用可能なネットワークリソースを取り上げて他の人が失敗するのを防ぐために必要なリソースの可用性を保証する必要があります。ソリューションは、L2VPNサービスインスタンスによって消費されるリソースを制限できるはずです。このソリューションは、コミットされたSLSの義務を果たすために必要なリソースの可用性を保証する必要があります。
Service providers are interested in interoperability in at least the following scenarios:
サービスプロバイダーは、少なくとも次のシナリオで相互運用性に関心があります。
- To facilitate use of PE and managed CE devices within a single SP network
- 単一のSPネットワーク内でPEおよび管理されたCEデバイスの使用を容易にするため
- To implement L2VPN services across two or more interconnected SP networks
- 2つ以上の相互接続されたSPネットワークにL2VPNサービスを実装する
- To achieve inter-working or interconnection between customer sites using different L2VPN solutions or different implementations of the same approach
- 異なるL2VPNソリューションまたは同じアプローチの異なる実装を使用して、顧客サイト間の作業間または相互接続を実現する
Each approach MUST describe whether any of the above objectives can be met. If an objective can be met, the approach MUST describe how such interoperability could be achieved.
各アプローチは、上記の目的のいずれかを満たすことができるかどうかを説明する必要があります。目的を満たすことができる場合、アプローチはそのような相互運用性をどのように達成できるかを説明する必要があります。
The L2VPN solution SHOULD provide the ability to test and verify operational and maintenance activities on a per L2VPN service basis, and, in case of VPLS, on a per-VLAN basis if customer VLANs are used as service delimiters.
L2VPNソリューションは、L2VPNサービスベースごとに運用およびメンテナンスのアクティビティをテストおよび検証する機能を提供する必要があります。VPLSの場合は、顧客VLANがサービスデリミターとして使用される場合、VLANごとにベースで使用できます。
The L2VPN solution SHOULD provide mechanisms for connectivity verification, and for detecting and locating faults.
L2VPNソリューションは、接続の検証、および障害の検出と配置のメカニズムを提供する必要があります。
Examples of testing mechanisms are as follows:
テストメカニズムの例は次のとおりです。
- Checking connectivity between "service-aware" network nodes
- 「サービスアウェア」ネットワークノード間の接続を確認します
- Verifying data plane and control plane integrity
- データプレーンと制御プレーンの完全性の確認
- Verifying service membership
- サービスメンバーの確認
The provided mechanisms MUST satisfy the following: the connectivity checking for a given customer MUST enable the end-to-end testing of the data path used by that of customer's data packets, and the test packets MUST not propagate beyond the boundary of the SP network.
提供されたメカニズムは次のものを満たす必要があります。特定の顧客の接続チェックは、顧客のデータパケットのデータパスで使用されるデータパスのエンドツーエンドテストを有効にする必要があり、テストパケットはSPネットワークの境界を超えて伝播してはなりません。。
To the extent possible, the IPLS solution SHOULD facilitate support of IPLS on existing PE devices that may be already deployed by the SP and MAY have been designed primarily for Layer 3 services.
可能な限り、IPLSソリューションは、SPによってすでに展開されており、主にレイヤー3サービス向けに設計されている可能性がある既存のPEデバイスでのIPLSのサポートを促進する必要があります。
An SP desires to have a means to view the topology, operational state, and other parameters associated with each customer's L2VPN. Furthermore, the SP requires a means to view the underlying logical and physical topology, operational state, provisioning status, and other parameters associated with the equipment providing the L2VPN service(s) to its customers. Therefore, the devices SHOULD provide standards-based interfaces (e.g., L2VPN MIB Modules), wherever feasible.
SPは、各顧客のL2VPNに関連するトポロジ、運用状態、およびその他のパラメーターを表示する手段を持つことを望んでいます。さらに、SPは、顧客にL2VPNサービスを提供する機器に関連する基礎となる論理的および物理的トポロジ、運用状態、プロビジョニングステータス、およびその他のパラメーターを表示する手段を必要とします。したがって、デバイスは、実行可能な場所に標準ベースのインターフェイス（L2VPN MIBモジュールなど）を提供する必要があります。
The details of service provider management requirements for a Network Management System (NMS) in the traditional fault, configuration, accounting, performance, and security (FCAPS) management categories can be found in [ITU_Y.1311.1].
従来の障害、構成、会計、パフォーマンス、セキュリティ（FCAPS）管理カテゴリにおけるネットワーク管理システム（NMS）のサービスプロバイダー管理要件の詳細は、[ITU_Y.1311.1]にあります。
These requirements are driven by implementation characteristics that make service and SP requirements achievable.
これらの要件は、サービスとSP要件を達成可能にする実装特性によって駆動されます。
An L2VPN service SHOULD be provisioned with minimum number of steps. Therefore, the control protocols SHOULD provide methods for signaling between PEs. The signaling SHOULD inform of membership, tunneling information, and other relevant parameters.
L2VPNサービスは、最小ステップ数でプロビジョニングする必要があります。したがって、制御プロトコルは、PE間のシグナル伝達の方法を提供する必要があります。シグナリングは、メンバーシップ、トンネル情報、およびその他の関連するパラメーターを通知する必要があります。
The infrastructure MAY employ manual configuration methods to provide this type of information.
インフラストラクチャは、このタイプの情報を提供するために手動構成方法を使用する場合があります。
The infrastructure SHOULD use policies to scope the membership and reachability advertisements for a particular L2VPN service. A mechanism for isolating the distribution of reachability information to only those sites associated with an L2VPN MUST be provided.
インフラストラクチャは、ポリシーを使用して、特定のL2VPNサービスのメンバーシップおよびリーチ可能性広告を範囲する必要があります。L2VPNに関連するサイトのみに到達可能な情報の分布を分離するメカニズムを提供する必要があります。
The control plane traffic increases with the growth of L2VPN membership. Similarly, the control plane traffic increases with the number of supported L2VPN services. The use of control plane resources MAY increase as the number of hosts connected to an L2VPN service grows.
コントロールプレーンのトラフィックは、L2VPNメンバーシップの成長とともに増加します。同様に、コントロールプレーンのトラフィックは、サポートされているL2VPNサービスの数とともに増加します。L2VPNサービスに接続されたホストの数が増加するにつれて、コントロールプレーンのリソースの使用が増加する可能性があります。
An L2VPN solution SHOULD minimize control plane traffic and the consumption of control plane resources. The control plane MAY offer means for enforcing a limit on the number of customer hosts attached to an L2VPN service.
L2VPNソリューションは、コントロールプレーンのトラフィックとコントロールプレーンリソースの消費を最小限に抑える必要があります。コントロールプレーンは、L2VPNサービスに接続された顧客ホストの数に制限を実施する手段を提供する場合があります。
An L2VPN solution SHOULD utilize the encapsulation techniques defined by PWE3 ([RFC3985]), and SHOULD not impose any new requirements on these techniques.
L2VPNソリューションは、PWE3（[RFC3985]）で定義されたカプセル化技術を利用する必要があり、これらの手法に新しい要件を課すべきではありません。
An L2VPN solution SHOULD utilize the congestion avoidance techniques defined by PWE3 ([RFC3985]).
L2VPNソリューションは、PWE3（[RFC3985]）で定義された輻輳回避技術を利用する必要があります。
A separate Broadcast Domain MUST be maintained for each VPLS.
VPLごとに別のブロードキャストドメインを維持する必要があります。
In addition to VPLS Broadcast Domains, an L2VPN service MAY honor customer VLAN Broadcast Domains, if customer VLANs are used as service delimiters. In that case, the L2VPN solution SHOULD maintain a separate VLAN Broadcast Domain for each customer VLAN.
VPLSブロードキャストドメインに加えて、L2VPNサービスは、顧客VLANがサービスデリミターとして使用される場合、顧客VLANブロードキャストドメインを称える場合があります。その場合、L2VPNソリューションは、各顧客VLANの個別のVLANブロードキャストドメインを維持する必要があります。
L2VPN PE devices MUST maintain a separate VSI per VPLS. Each VSI MUST have capabilities to forward traffic based on customer's traffic parameters, such as MAC addresses, VLAN tags (if supported), etc. as well as local policies.
L2VPN PEデバイスは、VPLごとに個別のVSIを維持する必要があります。各VSIには、MACアドレス、VLANタグ（サポートされている場合）など、顧客のトラフィックパラメーターやローカルポリシーなど、顧客のトラフィックパラメーターに基づいてトラフィックを転送する機能が必要です。
L2VPN PE devices MUST have capabilities to classify incoming customer traffic into the appropriate VSI.
L2VPN PEデバイスには、着信する顧客トラフィックを適切なVSIに分類する機能が必要です。
Each VSI MUST have flooding capabilities for its Broadcast Domain to facilitate proper forwarding of Broadcast, Multicast, and Unknown Unicast customer traffic.
各VSIには、放送、マルチキャスト、不明なユニキャスト顧客トラフィックの適切な転送を促進するために、放送ドメインの洪水機能が必要です。
A VPLS SHOULD derive all topology and forwarding information from packets originating at customer sites. Typically, MAC address learning mechanisms are used for this purpose. With IPLS, snooping of particular packets originating at customer sites and signaling might also be used.
VPLは、すべてのトポロジと転送情報を顧客サイトから発信するパケットから導き出す必要があります。通常、MACアドレス学習メカニズムがこの目的に使用されます。IPLSを使用すると、顧客サイトで発生する特定のパケットのスヌーピングとシグナリングも使用される場合があります。
Dynamic population of the forwarding information base (e.g., via MAC address learning) MUST take place on a per VSI basis; i.e., in the context of a VPLS and, if supported, in the context of VLANs therein.
転送情報ベースの動的集団（たとえば、Macアドレス学習を介して）は、VSIごとに行われる必要があります。すなわち、VPLSのコンテキストで、そしてサポートされている場合、その中のVLANのコンテキストで。
Security considerations occur at several levels and dimensions within L2VPNs, as detailed within this document.
このドキュメント内で詳述されているように、セキュリティ上の考慮事項は、L2VPNS内のいくつかのレベルと寸法で発生します。
The requirements based on security concerns and potential security hazards are detailed in Section 6.5. Further details on security requirements are given from the customer and service provider perspectives in Sections 6.5 and 7.6, respectively. In an analogous manner, further detail on traffic and routing isolation requirements are given from the customer and service provider perspectives in Sections 5.4 and 7.5, respectively. Safeguards to protect network resources such as CPU, memory, and bandwidth are required in Section 7.12.
セキュリティの懸念と潜在的なセキュリティの危険に基づく要件については、セクション6.5に詳しく説明しています。セキュリティ要件の詳細については、それぞれセクション6.5と7.6の顧客とサービスプロバイダーの観点から説明します。同様に、セクション5.4および7.5の顧客およびサービスプロバイダーの観点から、トラフィックとルーティングの分離要件に関する詳細がそれぞれ与えられます。セクション7.12では、CPU、メモリ、帯域幅などのネットワークリソースを保護するための保護措置が必要です。
IPsec can also be applied after tunneling Layer 2 traffic to provide additional security.
IPSECは、レイヤー2トラフィックをトンネリングして、追加のセキュリティを提供する後も適用できます。
In the case where an L2VPN service is carried over IP [RFC4023], traverses multiple SP networks and passes through an unsecured SP, POP, NAP, or IX, then security mechanisms MUST be employed. These security mechanisms include encryption, authentication, and resource protection, as described in section 5.5. For example, a provider should consider using both authentication and encryption for a tunnel used as part of an L2VPN that traverses another service provider's network.
L2VPNサービスがIP [RFC4023]を介して運ばれる場合、複数のSPネットワークを通過し、無担保SP、POP、NAP、またはIXを通過し、セキュリティメカニズムを使用する必要があります。これらのセキュリティメカニズムには、セクション5.5で説明されているように、暗号化、認証、およびリソース保護が含まれます。たとえば、プロバイダーは、別のサービスプロバイダーのネットワークを通過するL2VPNの一部として使用されるトンネルに認証と暗号化の両方を使用することを検討する必要があります。
The authors would like to acknowledge extensive comments and contributions provided by Loa Andersson, Joel Halpern, Eric Rosen, Ali Sajassi, Muneyoshi Suzuki, Ananth Nagarajan, Dinesh Mohan, Yakov Rekhter, Matt Squire, Norm Finn, Scott Bradner, and Francois Le Faucheur. The authors also wish to extend their appreciation to their respective employers and various other people who volunteered to review this work and provided feedback. This work was done in consultation with the entire Layer 2 PPVPN design team. A lot of the text was adapted from the Layer 3 VPN requirements document produced by the Layer 3 VPN requirements design team.
著者は、Loa Andersson、Joel Halpern、Eric Rosen、Ali Sajassi、Muneyoshi Suzuki、Ananth Nagarajan、Dinesh Mohan、Yakov Rekhter、Matt Squire、Norm Finn、Scott Bradner、Francois le Faucheurによって提供された広範なコメントと貢献を認めたいと思います。著者はまた、この作業をレビューし、フィードバックを提供することを志願したそれぞれの雇用主や他のさまざまな人々に感謝を拡大したいと考えています。この作業は、レイヤー2 PPVPN設計チーム全体と相談して行われました。テキストの多くは、レイヤー3 VPN要件設計チームによって生成されたレイヤー3 VPN要件ドキュメントから採用されました。
[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月。
[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月。
[VPLS_LDP] Lasserre, M., Kompella, V. "Virtual Private LAN Services over MPLS", Work in Progress.
[VPLS_LDP] Lasserre、M.、Kompella、V。「MPLS上の仮想プライベートLANサービス」、進行中の作業。
[VPLS_BGP] Kompella, K., Rekhter, Y. "Virtual Private LAN Service", Work in Progress.
[VPLS_BGP] Kompella、K.、Rekhter、Y。「仮想プライベートLANサービス」、進行中の作業。
[IPLS] Shah, H., et al. "IP-Only LAN Service (IPLS)", Work in Progress.
[IPLS] Shah、H.、et al。「IPのみのLANサービス（IPLS）」、進行中の作業。
[IEEE_802.1Q] IEEE Std 802.1Q-1998, "Virtual Bridged Local Area Networks", 1998
[IEEE_802.1Q] IEEE STD 802.1Q-1998、「仮想ブリッジ型ローカルエリアネットワーク」、1998
[RFC2205] Braden, R., Zhang, L., Berson, S., Herzog, S., and S. Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification", RFC 2205, September 1997.
[RFC2205] Braden、R.、Zhang、L.、Berson、S.、Herzog、S。、およびS. Jamin、「リソース予約プロトコル（RSVP） - バージョン1機能仕様」、RFC 2205、1997年9月。
[RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, "Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers", RFC 2474, December 1998.
[RFC2474] Nichols、K.、Blake、S.、Baker、F。、およびD. Black、「IPv4およびIPv6ヘッダーの差別化されたサービスフィールド（DSフィールド）の定義」、RFC 2474、1998年12月。
[RFC2685] Fox, B. and B. Gleeson, "Virtual Private Networks Identifier", RFC 2685, September 1999.
[RFC2685] Fox、B。およびB. Gleeson、「仮想プライベートネットワーク識別子」、RFC 2685、1999年9月。
[RFC3270] Le Faucheur, F., Wu, L., Davie, B., Davari, S., Vaananen, P., Krishnan, R., Cheval, P., and J. Heinanen, "Multi-Protocol Label Switching (MPLS) Support of Differentiated Services", RFC 3270, May 2002.
[RFC3270] Le Faucheur、F.、Wu、L.、Davie、B.、Davari、S.、Vaananen、P.、Krishnan、R.、Cheval、P。、およびJ. Heinanen、 "Multi-protocolラベルスイッチング（MPLS）差別化されたサービスのサポート」、RFC 3270、2002年5月。
[RFC3308] Calhoun, P., Luo, W., McPherson, D., and K. Peirce, "Layer Two Tunneling Protocol (L2TP) Differentiated Services Extension", RFC 3308, November 2002.
[RFC3308] Calhoun、P.、Luo、W.、McPherson、D。、およびK. Peirce、「レイヤー2トンネリングプロトコル（L2TP）分化サービス拡張」、RFC 3308、2002年11月。
[RFC3809] Nagarajan, A., "Generic Requirements for Provider Provisioned Virtual Private Networks (PPVPN)", RFC 3809, June 2004.
[RFC3809] Nagarajan、A。、「プロバイダープロビジョニング仮想プライベートネットワーク（PPVPN）の一般的な要件」、RFC 3809、2004年6月。
[RFC3985] Bryant, S. and P. Pate, "Pseudo Wire Emulation Edge-to-Edge (PWE3) Architecture", RFC 3985, March 2005.
[RFC3985] Bryant、S。およびP. Pate、「Pseudo Wire Emulation Edge-to-Edge（PWE3）アーキテクチャ」、RFC 3985、2005年3月。
[RFC4023] Worster, T., Rekhter, Y., and E. Rosen, "Encapsulating MPLS in IP or Generic Routing Encapsulation (GRE)", RFC 4023, March 2005.
[RFC4023] Worster、T.、Rekhter、Y.、およびE. Rosen、「IPまたは汎用ルーティングカプセル化（GRE）のMPLのカプセル化」、RFC 4023、2005年3月。
[RFC4031] Carugi, M. and D. McDysan, "Service Requirements for Layer 3 Provider Provisioned Virtual Private Networks (PPVPNs)", RFC 4031, April 2005.
[RFC4031] Carugi、M。およびD. McDysan、「レイヤー3プロバイダープロビジョニング仮想プライベートネットワーク（PPVPNS）のサービス要件」、RFC 4031、2005年4月。
[RFC4664] Andersson, L. and E. Rosen, "Framework for Layer 2 Virtual Private Networks (L2VPNs)", RFC 4664, September 2006.
[RFC4664] Andersson、L。およびE. Rosen、「レイヤー2仮想プライベートネットワーク（L2VPNS）のフレームワーク」、RFC 4664、2006年9月。
[IEEE_802.1D] ISO/IEC 15802-3: 1998 ANSI/IEEE Std 802.1D, 1998 Edition (Revision and redesignation of ISO/IEC 10038:98), "Part 3: Media Access Control (MAC) Bridges", 1998.
[IEEE_802.1D] ISO/IEC 15802-3：1998 ANSI/IEEE STD 802.1d、1998エディション（ISO/IEC 10038：98の改訂と再設計）、「パート3：メディアアクセス制御（MAC）ブリッジ」、1998年。
[ITU_Y.1311.1] Carugi, M. (editor), "Network Based IP VPN over MPLS architecture",Y.1311.1 ITU-T Recommendation, May 2001.
[ITU_Y.1311.1] Carugi、M。（編集者）、「ネットワークベースのIP VPN Over MPLSアーキテクチャ」、Y.1311.1 ITU-T推奨、2001年5月。
[IEEE_802.10] IEEE Std 802.10-1998 Edition (Revision IEEE Std 802.10-1992, incorporating IEEE Std 802.10b-1992, 802.10e-1993, 802.10f-1993, 802.10g-1995, and 802.10h-1997), "Standard for Interoperable LAN/MAN Security (SILS)", 1998.
[IEEE_802.10] IEEE STD 802.10-1998エディション（改訂IEEE STD 802.10-1992、IEEE STD 802.10B-1992、802.10E-1993、802.10F-1993、802.10G-1995、および802.10H-1997）相互運用可能なLAN/MANセキュリティ（SILS）の標準」、1998年。
[IEEE_802.1AE] IEEE 802.1AE/D5.1, "Draft Standard for Local and Metropolitan Area Networks - Media Access Control (MAC) Security", P802.1AE/D5.1, January 19, 2006.
[IEEE_802.1AE] IEEE 802.1AE/D5.1、「ローカルおよびメトロポリタンエリアネットワークのドラフト標準 - メディアアクセス制御（MAC）セキュリティ」、P802.1AE/D5.1、2006年1月19日。
[IEEE_802.1s] IEEE Std 802.1s-2002, "Virtual Bridged Local Area Networks-Amendment 3: Multiple Spanning Trees", 2002.
[IEEE_802.1S] IEEE STD 802.1S-2002、「仮想ブリッジ型ローカルエリアネットワーク - 修正3：複数のスパニングツリー」、2002年。
Editors' Addresses
編集者のアドレス
Waldemar Augustyn
Waldemar Augustyn
EMail: waldemar@wdmsys.com
Yetik Serbest AT&T Labs 9505 Arboretum Blvd. Austin, TX 78759
Yetik Serbest AT＆T Labs 9505 Arboretum Blvd.テキサス州オースティン78759
EMail: yetik_serbest@labs.att.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2006).
Copyright（c）The Internet Society（2006）。
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 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.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供されています。また、貢献者、彼/彼女が代表する組織（もしあれば）が後援する組織、インターネット協会とインターネット工学タスクフォースは、すべての保証、明示的または明示的、またはすべての保証を否認します。本書の情報の使用が、商品性または特定の目的に対する適合性の権利または黙示的な保証を侵害しないという保証を含むがこれらに限定されないことを含む。
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 provided by the IETF Administrative Support Activity (IASA).
RFCエディター機能の資金は、IETF管理サポートアクティビティ（IASA）によって提供されます。