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
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).
著作権（C）インターネット協会（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のプロバイダ・プロビジョニングされた仮想プライベートネットワーク（のL2VPN）の要件を提供します。これは、最初の分類と用語を提供し、汎用的で一般的なサービス要件を述べています。それは、ポイント・ツー・ポイントのVPNをカバーして仮想専用線サービス（VPWS）と呼ばれるだけでなく、また、仮想プライベートLANサービス（VPLS）として知られているマルチポイント・ツー・マルチポイントVPNを、。詳細な要件は、顧客だけでなく、サービスプロバイダーの両方の視点から表現されています。
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）の要件を提供します。これは、サービスプロバイダ（SP）は、レイヤ2 VPNサービスのプロビジョニングに使用することができる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]としてL2VPNサービスを提供する技術的なアプローチを説明するいくつかの他の文書、[VPLS_BGP]、および[IPLS]は、この態様をカバーするために利用可能です。
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].
この文書はのL2VPNの2種類の要件を説明します（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.
それは顧客エッジ（CE）とプロバイダエッジ（PE）との間の適切な分離のための手段を提供することでSLSesののL2VPN助剤配合物の適切な設計は、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
ヴァルデマーアウグスティンマルコCarugiジャイルズヘロンVACH Kompellaマルク・Lasserreパスカル・メネゼスハミドウルド-Brahimのティッサ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ネットワーク内のトンネルにマッピングされます。これらのトンネルは、いずれかの特定のVPWSに特定することができ、あるいは複数のサービス間で共有します。 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デバイスは、適切なVPWSに顧客レイヤ2つのフレームを割り当てるため、目的の宛先への適切な転送を担当します。
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（[IEEE_802.1Q]）を含むことができます。このサービスの変化は、顧客のIPトラフィックをサポートすることに限定されてIPLS（[RFC4664]）、です。
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は、一の以上のCEへのアクセス接続を介して取り付けられています。 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]で見つけることができます。 VPLSにおいて、PEは、それが機能することを各L2VPNのための仮想スイッチングインスタンス（VSI）を含むと見なすことができます。 CEデバイスは、PEのブリッジモジュールに、おそらくはアクセスネットワークを介して、取り付けます。 PE内で、ブリッジ・モジュールは、エミュレートされたLANにエミュレートされたLANインタフェースを介して、取り付けます。各VPLSのために、エミュレートLANインスタンスが存在します。エミュレートLANは、PWSはパケットを通って移動することができる疑似ワイヤ（PW）によって接続されたVPLSフォワーダモジュール（VPLSサービスインスタンスごとにPEに1つ）で構成さをルーティングバックボーンを介してネットワーク（PSN）トンネルをスイッチ。 VSIは、VPLS混載モジュールおよびVPLSサービスインスタンスに関連するブリッジモジュール[RFC4664]の一部を含む論理エンティティです。したがって、VSIでのCEを収容する（定義については[RFC3985]を参照）、他のVSIとの相互接続のためのPWを終了しても、接続回線（ACS）を終了します。 VSIは、2つのフレームが同じL2VPNサービス（および/または他のACSにをサポートする他のPEでのVSIにCEからACを介して受信したレイヤを転送する方法に関する情報の集合であるL2VPN [RFC4664]の転送情報ベースを含みます）、そしてそれはPWをから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にわたってブロードキャストメッセージがPEを、ブリッジモジュールのいずれかで見られない確率は、真のイーサネット（登録商標）よりも高いです。
- 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フレームが重複して取得することができます。 PWの上のデータフレームは、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.
- パケットの遅延配信は（例えば、複数の第二の半分以上）、むしろそれらをドロップするよりも、サービスのパフォーマンスに悪影響を及ぼす可能性があります。
- 802.3x Pause frames will not be transported over a VPLS, as the bridge module ([RFC4664]) in the PE terminates them.
- それらを終了PEにおけるブリッジモジュール（[RFC4664]）のように、フレームはVPLS上で輸送されない802.3xポーズ。
- 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ソリューションは、CEからCEに透過的に、レイヤ2ヘッダを維持する必要はありません。例えば、送信元MACアドレスは、おそらくIPLSソリューションによって保存されることはありません。
A VPLS MUST support unicast, multicast, and broadcast traffic. Support for efficient replication of broadcast and multicast traffic is highly desirable.
VPLSは、ユニキャスト、マルチキャスト、およびブロードキャストトラフィックをサポートしなければなりません。ブロードキャストおよびマルチキャストトラフィックの効率的な複製のためのサポートは非常に望ましいです。
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ネットワークは、単純なポイント・ツー・ポイントから分散階層構成に至るまで、のPEを相互接続するために1つまたは複数のネットワーク・トンネル・トポロジを使用して実現することができます。典型的なトポロジは、次のとおりです。
- 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
- ポイントツーポイント - ポイントツーマルチポイント、別称、ハブとスポーク - どれ-to-anyの、別称、フルメッシュ - ミックス、別称、部分的にメッシュ - 階層
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のタイプによって暗黙接続タイプを保有しなければなりません。例えば、VPLSは、それがポイントツーポイント回路を用いて実装されていても多対多の接続を可能にしなければなりません。この要件は、（等帯域幅、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でのCEを防ぐ手段を定義しなければなりません。
L2VPN solutions SHALL avoid introducing undesired forwarding information that could corrupt the L2VPN forwarding information base.
L2VPNソリューションは、導入望ましくない転送情報が破壊されることがありL2VPN転送情報ベースを避けるSHALL。
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で起動することができ、そのようなメモリ空間などのネットワークリソースに負担することができ、情報ベーステーブル、帯域幅、およびCPUの処理を転送攻撃に至るまで、L2VPNのセットアップと操作で発生します。
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過度のプロトコルの隣接関係のセットアップ/ティアダウンOプロトコル攻撃
- Resource Utilization o Forwarding plane replication (VPLS) o Looping (VPLS primarily) o MAC learning table size limit (VPLS)
- リソース利用O平面の複製を転送（VPLS）Oルーピング（VPLS主に）MAC学習テーブルサイズ制限O（VPLS）
- Unauthorized access o Unauthorized member of VPN o Incorrect customer interface o Incorrect service delimiting VLAN tag o Unauthorized access to PE
- 誤ったサービスO不正顧客インターフェースO VPNの不正部材O不正アクセスは、PEへの不正アクセスoをVLANタグを区切ります
- Tampering with signaling o Incorrect FEC signaling o Incorrect PW label assignment o Incorrect signaled VPN parameters (e.g., QoS, MTU, etc.)
- 誤ったシグナリングVPNパラメータ（例えば、QoSの、MTUなど）O不正PWラベル割り当てoを不正FECシグナリングoをシグナリングが改ざん
- 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間違ったトンネルを使用して、ハイジャックのPW O不正PWカプセル化O不正顧客対向封入O不正PWラベルO不正AC識別子O不正MAC学習エントリOデータ転送が改ざん
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.
マッピング又は翻訳レイヤ2つのQoSパラメータのPSNのQoS（例えば、のDSCPまたはMPLS EXPフィールド）に、ならびにVC（例えば、FR / ATMまたはVLAN）に基づいて、QoSマッピングは、QoSの透明性を提供するために実行されてもよいです。これらのマッピングや翻訳のための実際のメカニズムはこの文書の範囲外です。また、下層のトンネリング技術（例えば、[RFC3270]または[RFC3308]）とのIntServモデルのDiffservのサポートは、（[RFC2205]）が使用されるかもしれません。このように、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サービスでは、サービス・レベル仕様（SLS）の監視および[RFC3809]に記載された報告のための機能が提供されるべきです。
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つのフレームは、トンネリング技術の種々のいずれかを使用して、PEからPEへのレイヤ3バックボーンを介してトンネリングされてもよい（例えば、IPインIP、GRE、MPLS、L2TP、等）。
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].
次のようにサービス管理は、TMN「FCAPS」機能を含んでもよい（MAY）：障害、設定、アカウンティング、パフォーマンス、セキュリティ、[ITU_Y.1311.1]で詳述するように。
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サービスへの顧客アクセス接続が（例えば、フレームリレー、ATM、802.1D、MPLS）異なるCE装置でも異なっていてもよいです。
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で始まるが、その後、複数のASおよび/または複数のSPにまたがるサービスの拡充を求めるかもしれません。この場合は、だけでなく、マルチASと複数-SPのL2VPNのすべての種類の、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サービスは、顧客のレイヤ3トラフィックにとらわれないであるべきである（例えば、IP、IPX、AppleTalkが）、レイヤ2つのフレーム内にカプセル化されました。
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.
IPLSは、顧客のIPv4およびIPv6トラフィックのトランスポートは、レイヤ2つのフレームの中にカプセル化できるようにしなければなりません。 IPLSはまた、これらのIPと組み合わせて使用する場合のCEはその中で透過的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サービスは、インタラクティブビデオ、およびマルチメディア・アプリケーションをボイスのPW（例えば、SONETエミュレーション）の範囲であることができる自分のアプリケーションに適用可能なQoSを提供する必要があります。したがって、ベストエフォート型だけでなく、遅延と損失敏感なトラフィックは、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（S）からの施策へのアクセスが必要です。
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を使用するかもしれません。その場合には、彼らは尊重されなければならず（MUST）、およびトラフィック分離を提供しなければなりません。
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ソリューションは、顧客の要求に応じて、適切なフィルタリング機能を有効にするメカニズムを持っているかもしれません。例えば、MAC及び/又はVLANフィルタリングは、VPLSのためのCEおよびPE間と考えることができます。
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および上位層で使用セキュリティ機構を妨害してはなりません。 VLAN IDを区切るサービスが暗号化されている場合、このような802.10bなどのレイヤ2のセキュリティメカニズムは、（[IEEE_802.10]）と802.1AE（[IEEE_802.1AE]）、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.
すべてのパケットは、それがプライベートネットワーク上のL2VPNによって提供されるものと同等のサービスを提供すると同じように現れなければならないアクセス接続を介して顧客とSPの間で交換さ。
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リンクアグリゲーションがサポートされるべきです。 （図1に示す場合に加えて）4 - L2VPNソリューションは、図2に示した物理またはリンク層の接続構成の少なくとも種類をサポートしなければなりません。図2のように、CEは、SPまたは多様なアクセスネットワークを介して、二つの異なるSPにデュアルホーミングすることができます。
+---------------- +---------------
| |
+------+ +------+
+---------| 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
CEデバイスの図2.デュアルホームアクセス
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.
CEのは、「バックドア」接続を介して接続され、図3に示すように、L2VPNサービスの弾力性をさらに向上させることができ、同じ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
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.
VPLSは、入力ポリシング及びセキュリティポリシーの対象、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.
VPLSは、提供するサービスの理論上の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がサービスデリミタとして使用されている場合は、与えられたVPLS内のすべての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タグ変換がマルチプルスパニングツリーのサポートに影響を与える（すなわち、[IEEE_802.1s] 802.1）と適切な動作を破ることができることに留意すべきです。
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ソリューションは、例えば、STP BPDUは、VPLSの動作を改善するために、スヌーピング、顧客のレイヤ2制御プロトコルから指摘を使用するかもしれません。
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にまたがるL2VPNをサポートする場合SPドメインを一意に少なくとも全ての相互接続された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が複数のSPにまたがる場合をサポートするために、グローバルに一意である必要があり（例えば、[RFC2685]）。グローバルに一意の識別子は、相互AS / SPのL2VPNの支援を促進します。
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のための重要な課題です。ソリューションは、動的にL2VPN情報は設定手順を最小限に抑えるためのPEによって発見することを可能にする方法を提供する必要があります。
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ソリューションは、互いを認証し、SP L2VPNが正しく接続されていることを確認するために取り付けられたCEのための手段をサポートしなければなりません。
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ソリューションで対処しなければならない会員のもう一つの側面です。
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デバイスのリソースおよび構成のプロビジョニングを制御しています。 [RFC4031]で定義されるようしたがって、SPは、管理対象の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要件を満たすための手段を提供する必要があります。 1 L2VPNの一環として、サイトによって生成渋滞が別の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]で提供されるセキュリティ要件が満たされなければなりません。セキュリティ要件は、レイヤ3および[RFC4031]で指定された上位層に依存するものを除き、満たされるべきです。
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方法の一つ以上をサポートするための設定可能なオプションをサポートする必要があります：
- 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.
上記の機能は、トラフィックがサイト間で交換が含まお客様の「データトラフィック」、に適用可能であるべきです。また、それは必ずしも顧客によって知覚が、彼または彼女の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 [RFC4023]を介して搬送された場合には、そのようなPE-PEおよびPE-MTUなどの異なるエンドポイント間の設定でなければなりません。データを保護する方法は、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、および3DESを含む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.
このような交通情報の分離を転送し、SLSes、管理、セキュリティ、プロビジョニング、等のすべての適用可能なSP要件は、隣接のASを横切って保存されなければなりません。溶液は、インターSPネットワークインタフェース、カプセル化方法（複数可）、ルーティングプロトコル（単数または複数）、および該当するすべてのパラメータを記述しなければなりません。
An L2VPN solution MUST provide the specifics of offering L2VPN services spanning multiple ASes and/or SPs.
L2VPNソリューションは、複数のASおよび/またはのSPにまたがる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ソリューションは、複数のASおよび/またはのSPの存在下でのL2VPNサービスのすべての要素に動作パラメータの適切な普及をサポートしなければなりません。 L2VPNソリューションは、異なるAS間の動作パラメータを共有するためのメカニズムを採用しなければなりません。
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ソリューションは、異なるのASからの動作パラメータを適切に選択するためのポリシーをサポートする必要があります。同様に、L2VPNソリューションは、別のASに配布する情報を選択するためのポリシーをサポートしなければなりません。
The general requirements for managing a single AS apply to a concatenation of ASes. A minimum subset of such capabilities is the following:
単一ASを管理するための一般的な要件は、のASの連結に適用されます。そのような機能の最小サブセットは以下の通りであります：
- Diagnostic tools
- 診断ツール
- Secured access to one AS management system by another
- 他による管理システムAS 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は、複数のASにまたがる場合には、様々なサイトへのトラフィックの転送に関与する他のドメイン及び/又はネットワークから、例えば帯域幅およびQoSなどの特定のSLSパラメータを、要求仲介機構が必要とされています。必須要件は、ソリューションは、のASのセットが確立し、プロバイダープロビジョニングVPNのサポートに均一なQoSを保証することができるかどうかを判断できなければならないということです。
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への1つの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イン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タグ値の割り当てを制御することになると厳密のCEによってコンプライアンスを強制だろう。
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サービスの提供のためのSLSesの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サービスインスタンスが消費するリソースを制限することができるべきです。解決策は、コミットSLSesの義務を履行するために必要なリソースの可用性を保証すべきです。
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
- 二つ以上の相互接続された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ソリューションは、顧客のVLANがサービスデリミタとして使用されている場合は、VLAN単位で、VPLSの場合には、テストし、L2VPNサービスごとに運用・保守の活動を確認し、能力を提供する必要があります。
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サービス（S）を提供する装置に関連する他のパラメータを表示するための手段を必要とします。どこ可能したがって、デバイスは、標準ベースのインターフェース（例えば、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サービスは、ステップの最小数でプロビジョニングされるべきである（SHOULD）。したがって、制御プロトコルは、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.
別々のブロードキャストドメインは、各VPLSのために維持しなければなりません。
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.
カスタマーVLANがサービスデリミタとして使用されている場合はVPLSブロードキャストドメインに加えて、L2VPNサービスは、顧客の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デバイスは、VPLSごとに別々の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.
VPLSは、顧客サイトで発生するパケットからのすべてのトポロジとフォワーディング情報を得るべきです。一般的に、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.
セキュリティの考慮事項は、この文書の中に詳細に説明するように、のL2VPN内のいくつかのレベルと寸法で起こります。
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で顧客とサービス・プロバイダの観点から与えられます。 CPU、メモリ、および帯域幅などのネットワークリソースを保護するためのセーフガードは、セクション7.12で必要とされています。
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.
著者はロア・アンダーソン、ジョエル・ハルパーン、エリック・ローゼン、アリSajassi、宗悦鈴木、Ananth Nagarajan、ディネッシュモハン、ヤコフ・レックター、マット・スクワイア、ノーム・フィン、スコット・ブラッドナー、そしてフランソワ・ル・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]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。
[RFC4026] Andersson, L. and T. Madsen, "Provider Provisioned Virtual Private Network (VPN) Terminology", RFC 4026, March 2005.
[RFC4026]アンデションとL.とT.マドセン、 "プロバイダーのプロビジョニングされた仮想プライベートネットワーク（VPN）用語"、RFC 4026、2005月。
[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】シャー、H.、ら。 "IP-のみのLANサービス（IPLS）" が進行中で働いています。
[IEEE_802.1Q] IEEE Std 802.1Q-1998, "Virtual Bridged Local Area Networks", 1998
[IEEE_802.1Q] IEEE 802.1Q STD-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]ブレーデン、R.、チャン、L.、Berson氏、S.、ハーツォグ、S.、およびS.ヤミン、 "リソース予約プロトコル（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]ニコルズ、K.、ブレイク、S.、ベイカー、F.、およびD.黒、 "IPv4とIPv6ヘッダーとの差別化されたサービス分野（DS分野）の定義"、RFC 2474、1998年12月。
[RFC2685] Fox, B. and B. Gleeson, "Virtual Private Networks Identifier", RFC 2685, September 1999.
[RFC2685]フォックス、B.及びB.グリーソン、 "仮想プライベートネットワーク識別子"、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]ルFaucheur、F.、ウー、L.、デイビー、B.、Davari、S.、Vaananen、P.、クリシュナン、R.、シュヴァル、P.、およびJ. Heinanen、「マルチプロトコルラベルスイッチング（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]カルフーン、P.、羅、W.、マクファーソン、D.、およびK.パース、 "レイヤ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]ブライアント、S.とP.パテ、 "疑似ワイヤーエミュレーション端から端まで（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.ローゼン、 "IP又は総称ルーティングカプセル化（GRE）でMPLSカプセル化"、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]アンデション、L.およびE.ローゼン、 "レイヤのためのフレームワーク2個の仮想プライベートネットワーク（のL2VPN）"、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規格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.（編集者）、 "MPLSアーキテクチャを超えるネットワークベースのIP VPN"、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.10b-1992、802.10e-1993、802.10f-1993、802.10グラム-1995、および802.10h-1997を組み込むリビジョンIEEE規格802.10から1992）[IEEE_802.10] IEEE標準802.10から1998版相互運用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.1-2002、 "仮想ブリッジローカルエリアネットワーク - 修正3：複数のスパニングツリー"、2002年。
Editors' Addresses
エディタのアドレス
Waldemar Augustyn
ヴァルデマーオーガスティン
EMail: waldemar@wdmsys.com
メールアドレス：waldemar@wdmsys.com
Yetik Serbest AT&T Labs 9505 Arboretum Blvd. Austin, TX 78759
Yetik Serbest AT＆T Labsの9505植物園ブルバードオースティン、TX 78759
EMail: yetik_serbest@labs.att.com
メールアドレス：yetik_serbest@labs.att.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2006).
著作権（C）インターネット協会（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.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットソサエティおよびインターネット・エンジニアリング・タスク・フォース放棄すべての保証、明示または、（もしあれば）後援ISに設けられています。黙示、情報の利用は、特定の目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証含むがこれらに限定されません。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、本書またはそのような権限下で、ライセンスがたりないかもしれない程度に記載された技術の実装や使用に関係すると主張される可能性があります任意の知的財産権やその他の権利の有効性または範囲に関していかなる位置を取りません利用可能です。またそれは、それがどのような権利を確認する独自の取り組みを行ったことを示すものでもありません。 RFC文書の権利に関する手続きの情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができますhttp://www.ietf.org/iprのIETFのオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、その注意にこの標準を実装するために必要とされる技術をカバーすることができる任意の著作権、特許または特許出願、またはその他の所有権を持ってすべての利害関係者を招待します。 ietf-ipr@ietf.orgのIETFに情報を記述してください。
Acknowledgement
謝辞
Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).
RFCエディタ機能のための資金は、IETF管理サポート活動（IASA）によって提供されます。