RFC4665 日本語訳
4665 Service Requirements for Layer 2 Provider-Provisioned VirtualPrivate Networks. W. Augustyn, Ed., Y. Serbest, Ed.. September 2006. (Format: TXT=68972 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
英語原文
Network Working Group W. Augustyn, Ed.
Request for Comments: 4665 Y. Serbest, Ed.
Category: Informational AT&T
September 2006
ワーキンググループW.Augustyn、エドをネットワークでつないでください。コメントのために以下を要求してください。 4665 Y. 最もSerbest、エドカテゴリ: 情報のAT&T2006年9月
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)インターネット協会(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.
このドキュメントはLayer2のProviderによって食糧を供給されたVirtual兵士のNetworks(L2VPNs)のための要件を提供します。 それは、最初に、分類学と用語を提供して、ジェネリックと一般的なサービス要件を述べます。 それは多点から多点へのまた、Virtual兵士のLAN Service(VPLS)として知られているVPNsと同様にVirtual兵士のWire Service(VPWS)と呼ばれたポイントツーポイントVPNsをカバーしています。 詳細な要件は顧客とサービスプロバイダー見解の両方から言い表されます。
Augustyn & Serbest Informational [Page 1] RFC 4665 Service Requirements for L2VPNs September 2006
Augustyn&Serbestの情報[1ページ]のRFC4665は2006年9月にL2VPNsのための要件を修理します。
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
1. 序論…4 1.1. このドキュメントの範囲…4 1.2. 概説します。5 2. このドキュメントで中古のコンベンション…5 3. 作者を寄付します…5 4. 定義と分類学…5 4.1. 定義…5 4.2. L2VPNタイプの分類学…6 4.3. VPWS…6 4.4. VPLS…7 5. 顧客とサービスプロバイダーに共通の要件を修理してください。7 5.1. エミュレーションの範囲…8 5.2. トラフィックタイプ…8 5.3. トポロジー…8 5.4. データと推進情報の孤立交換…9 5.5. セキュリティ…9 5.5.1. 利用者データセキュリティ…10 5.5.2. コントロールにアクセスしてください…10 5.6. 扱います。11 5.7. サービスの品質…11 5.7.1. QoS規格…11 5.7.2. サービスはモデル化されます…11 5.8. レベル指定を修理してください…12 5.9. 保護と王政復古…12 5.10. PEへのCeとPEへのPEは要件をリンクします…12 5.11. 管理…12 5.12. 相互運用性…12 5.13. 織り込みます。13 6. 顧客要件…13 6.1. サービスプロバイダー独立…13 6.2. 3サポートを層にしてください…13 6.3. サービスの質とトラフィックパラメタ…14 6.4. レベル指定を修理してください…14 6.5. セキュリティ…14 6.5.1. 分離…14 6.5.2. コントロールにアクセスしてください…14 6.5.3. 付加価値が付いたセキュリティー・サービス…15 6.6. アクセスをネットワークでつないでください…15 6.6.1. 物理的な/リンクレイヤ技術…15 6.6.2. 接続性にアクセスしてください…15 6.7. 顧客トラフィック…17 6.7.1. ユニキャスト、Unknown Unicast、Multicast、およびBroadcast推進…17 6.7.2. パケット再注文…17 6.7.3. 最小のMTU…17 6.7.4. エンドポイントVLANは翻訳にタグ付けをします…18
Augustyn & Serbest Informational [Page 2] RFC 4665 Service Requirements for L2VPNs September 2006
Augustyn&Serbestの情報[2ページ]のRFC4665は2006年9月にL2VPNsのための要件を修理します。
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
6.7.5. 透明…18 6.8. 層2のために、コントロールがプロトコルであるとサポートしてください…18 6.9. Ceの食糧を供給すること…19 7. サービスプロバイダーネットワーク要件…19 7.1. スケーラビリティ…19 7.1.1. 映像を大きさで分けるサービスプロバイダー容量…19 7.1.2. ソリューション特有の測定基準…19 7.2. 識別子…19 7.3. L2VPNを発見すると、情報は話されました…19 7.4. サービスの質(QoS)…20 7.5. トラフィックと推進情報の分離…20 7.6. セキュリティ…21 7.7. 相互、/SP L2VPNs…22 7.7.1. 管理…22 7.7.2. 帯域幅とQoS仲介…22 7.8. L2VPNは卸売りします…23 7.9. トンネリング要件…23 7.10. アクセスには、技術をサポートしてください…23 7.11. バックボーンネットワーク…24 7.12. ネットワーク資源仕切りとL2VPNsを平等に割り当てます…24 7.13. 相互運用性…24 7.14. テストします…25 7.15. 存在するとき、PEsをサポートしてください…25 8. サービスプロバイダー管理要件…26 9. 工学要件…26 9.1. 飛行機要件を制御してください…26 9.2. データ飛行機要件…27 9.2.1. カプセル化…27 9.2.2. 混雑への反応性…27 9.2.3. ドメインを放送してください…27 9.2.4. 仮想の切り換えインスタンス…27 9.2.5. マックーアドレス学習…27 10. セキュリティ問題…28 11. 承認…28 12. 参照…29 12.1. 標準の参照…29 12.2. 有益な参照…29
Augustyn & Serbest Informational [Page 3] RFC 4665 Service Requirements for L2VPNs September 2006
Augustyn&Serbestの情報[3ページ]のRFC4665は2006年9月にL2VPNsのための要件を修理します。
1. Introduction
1. 序論
This section describes the scope and outline of the document.
このセクションはドキュメントの範囲とアウトラインについて説明します。
1.1. Scope of This Document
1.1. このドキュメントの範囲
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].
このドキュメントはプロバイダーで食糧を供給されたLayer2Virtual兵士のNetworks(L2VPN)のための要件を提供します。 それはService Provider(SP)がLayer2VPNサービスの食糧を供給するのに使用するかもしれない1つ以上の個別的アプローチに適用されるかもしれない要件を特定します。 このドキュメントの中身は[RFC4664]で説明されたL2VPNsを配布するために[RFC4026]と共通成分で定義された用語を利用します。
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_自由民主党]や、[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].
このドキュメントはL2VPNsの2つのタイプのための要件について説明します: (1) 仮想の個人専用電線サービス(VPWS)、および(2)の仮想の個人的なLANサービス(VPLS)。 本書では続かれるアプローチはどう接続性を提供するかに関して(ポイント-ポイントか多点多点)L2VPNタイプを区別します、[RFC4664]で詳しく述べられるように。
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.
プロバイダーで食糧を供給されたVPNsの文脈には、そのようなサービス、Provider、およびCustomerの操作にかかわる2つの実体があります。 Providerは正常な状況と例外的な状況におけるサービスの振舞いに関してCustomerとの拘束力のある協定に従事しています。 そのような協定はService Level Specification(SLS)として知られています。(Service Level SpecificationはProviderとCustomerの間で確立されたサービス・レベル・アグリーメント(SLA)の一部です)。
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の適切なデザインは、Customer Edge(CE)とProvider Edge(PE)の間の適切な分離のための手段を提供するのでSLSesの定式化を支援して、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
このドキュメントはProviderとCustomerの観点の両方から要件を提供します。 それは顧客のものによって従われた一般的な顧客のものとサービスプロバイダーの観点で始まります。
Augustyn & Serbest Informational [Page 4] RFC 4665 Service Requirements for L2VPNs September 2006
Augustyn&Serbestの情報[4ページ]のRFC4665は2006年9月にL2VPNsのための要件を修理します。
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要件を含んでいるL2VPNsに食糧を供給する際にSPによって予想されたハイレベルのL2VPNの特徴を提供します。
1.2. Outline
1.2. アウトライン
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はここに引用された参考文献一覧を提供します。
2. Conventions used in this document
2. 本書では使用されるコンベンション
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"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTはRFC2119[RFC2119]で説明されるように本書では解釈されることであるべきですか?
3. Contributing Authors
3. 作者を寄付します。
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マルコCarugiジャイルスサギのVach Kompellaマークラセールパスカルメネゼスハミドオールド-Brahim Tissa Senevirathne Yetik Serbest
4. Definitions and Taxonomy
4. 定義と分類学
4.1. Definitions
4.1. 定義
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つ以上のレベルのトンネルでさらにこれらの概念について説明します。
Augustyn & Serbest Informational [Page 5] RFC 4665 Service Requirements for L2VPNs September 2006
Augustyn&Serbestの情報[5ページ]のRFC4665は2006年9月にL2VPNsのための要件を修理します。
4.2. Taxonomy of L2VPN Types
4.2. L2VPNタイプの分類学
The requirements distinguish two major L2VPN models, a Virtual Private Wire Service (VPWS), and a Virtual Private LAN Service (VPLS).
要件は2つの一流のL2VPNモデル(Virtual兵士のWire Service(VPWS))とVirtual兵士のLAN Service(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
+-----+ +-----+ + CE1+--、+ +---| CE2| +-----+ | ........................ | +-----+ L2VPN A| +----+ +----+ | L2VPN A+--| PE|--- サービス---| PE|--+ +----+ プロバイダー+----+ /バックボーン\--、/\-_ +-----+ / . | . \ / \ / \ +-----+ +、CE4+--+。| . +--\アクセス\----| CE5| +-----+ . +----+ . | ネットワーク| +-----+ L2VPN B…| PE|......... \/L2VPN B+----+ ^ ------- | | | | +-----+ | | CE3| +--論理的な切り換えインスタンス+-----+ L2VPN A
Figure 1. L2VPN Reference Model
図1。 L2VPN規範モデル
4.3. VPWS
4.3. VPWS
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デバイスが論理的な内部連絡を提供するので、1組のCEデバイスはただ一つの論理的なLayer2回路によって接続されるように見えます。 Layer2回路が切り替わっている間、PEデバイスは作動します。 そして、層2の回路はSPネットワークでトンネルに写像されます。 これらのトンネルは、特定のVPWSに特定であるか、またはいくつかのサービスの中で共有できます。 イーサネット、ATM、Frame Relayなどを含んでいて、VPWSはすべてのサービスに申し込みます。 図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へのフレームを顧客Layer2に割り当てて、意図している目的地への適切な推進に原因となります。
Augustyn & Serbest Informational [Page 6] RFC 4665 Service Requirements for L2VPNs September 2006
Augustyn&Serbestの情報[6ページ]のRFC4665は2006年9月にL2VPNsのための要件を修理します。
4.4. VPLS
4.4. VPLS
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か複数のVLANs([IEEE_802.1Q])を含むことができます。 このサービスの変化はIPLS([RFC4664])です。(そのIPLSは顧客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からLayer2サービスを受けます。 PEは1CEsとのアクセス接続で取り付けられます。 PEはLayer2ヘッダーで情報に基づくユーザデータ・パケットの推進を実行します、MAC送付先アドレスのように。 図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.
[RFC4664]でVPLS規範モデルの細部を見つけることができます。(私たちはその規範モデルをここへまとめます)。 VPLSでは、Virtual Switching Instance(VSI)を含むとそれが役立つ各L2VPNに関してPEを見なすことができます。 CEデバイスはことによるとアクセスネットワークを通してPEのブリッジモジュールに付きます。 PEの中では、ブリッジモジュールはEmulated LAN Interfaceを通してEmulated LANに付きます。 各VPLSのために、Emulated LANインスタンスがあります。 Emulated LANは疑似ワイヤ(PW)によって接続されたVPLS Forwarderモジュール(VPLSサービスインスタンスあたりのPEあたり1つ)から成ります。そこでは、PWsが発送されたバックボーンの上をPacket Switched Network(PSN)トンネルを通って旅行しているかもしれません。 VSIはVPLSサービスインスタンス[RFC4664]に関連しているブリッジモジュールのVPLS混載業者モジュールと一部を含む論理的な実体です。 したがって、VSIは他のVSIsと共にインタコネクトのためのPWsを終えて、また、CEsを収容するためのAttachment Circuits(ACs)(定義に関して[RFC3985]を見る)を終えます。 VSIは同じL2VPNがサービス(そして/または他のACsに)であるとサポートしながら他のPEsでどうCEからVSIsまで西暦の上に受け取られたLayer2フレームを進めるかの情報のセットであるL2VPN[RFC4664]のための推進情報ベースを含んでいます、そして、それはどうPWsからACsまで受け取られたフレームをLayer2に送るかの情報を含んでいます。 静的(例えば、構成で)に、ダイナミックにベースに居住できるという情報(ソースMACアドレス学習などの)を転送します。 それぞれのPEデバイスは対応するVSIの推進情報ベースに基づく適切な目的地への顧客トラフィックの適切な推進に原因となります。
5. Service Requirements Common to Customers and Service Providers
5. 顧客とサービスプロバイダーに共通のサービス要件
This section contains requirements that apply to both the customer and the provider, or that are of an otherwise general nature.
このセクションは顧客とプロバイダーの両方に適用しているか、またはそうでなければ、一般的に自然な要件を含みます。
Augustyn & Serbest Informational [Page 7] RFC 4665 Service Requirements for L2VPNs September 2006
Augustyn&Serbestの情報[7ページ]のRFC4665は2006年9月にL2VPNsのための要件を修理します。
5.1. Scope of emulation
5.1. エミュレーションの範囲
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プロトコルSHOULD NOTは顧客が経営しているLayer2ネットワークの既存のLayer2プロトコルと規格を妨げます。 彼らがVPLSの上に送られる顧客Layer2プロトコルに影響を与えるなら、これらの影響を記録しなければなりません。
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フレームをコピーできます。 IPデータグラムでPWsの上のデータフレームを送ります、そして、ある失敗シナリオの下では、IPネットワークはパケットをコピーできます。 PWデータ伝送プロトコルがデータ・パケットの系列を確実にしないなら、順序が狂ってフレームをコピーするか、または受け取ることができます。 データ・パケットとして顧客のBridgeプロトコルData Unit(BPDU)フレームを送るなら、BPDUフレームは、コピーされるか誤配列できます、これがレアル-時間Streamingプロトコル(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.
- パケット(例えば、半数以上1秒)の遅延分娩はそれらを下げるよりむしろサービスの性能に悪影響を及ぼすかもしれません。
- 802.3x Pause frames will not be transported over a VPLS, as the
bridge module ([RFC4664]) in the PE terminates them.
- 802.3 xくぎりのフレームはVPLSの上で輸送されないでしょう、PEのブリッジモジュール([RFC4664])が彼らを終えるとき。
- 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ソリューション目的がトラフィック(Layer2フレーム自体よりむしろ)をカプセル化したので、IPLSソリューションは透過的にCEからCEまでLayer2Headerを保存するNOT REQUIREDです。 例えば、Source MACアドレスはたぶんIPLSソリューションによって保存されないでしょう。
5.2. Traffic Types
5.2. トラフィックタイプ
A VPLS MUST support unicast, multicast, and broadcast traffic. Support for efficient replication of broadcast and multicast traffic is highly desirable.
VPLS MUSTサポートユニキャスト、マルチキャスト、および放送トラフィック。 放送とマルチキャストトラフィックの効率的な模写のサポートは非常に望ましいです。
5.3. Topology
5.3. トポロジー
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ネットワークはPEsとインタコネクトするのに1ネットワークトンネルtopologiesを使用することで実現されるかもしれません、簡単なポイントツーポイントから分配された階層的配列まで及んで。 典型的なtopologiesは:
Augustyn & Serbest Informational [Page 8] RFC 4665 Service Requirements for L2VPNs September 2006
Augustyn&Serbestの情報[8ページ]のRFC4665は2006年9月にL2VPNsのための要件を修理します。
- 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
- ポイントツーポイント--ポイントツーマルチポイント、通称ハブ、およびスポーク--いずれへのどんな、通称満も階層的にかみ合います(Mixed、通称部分的なメッシュ)。
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 MUSTは多点から多点への接続性を許容します。 この要件は、すべてのトラフィックの特性(帯域幅、QoS、遅れなどの)が必ずL2VPNのどんな2つのエンドポイントの間でも同じであることを含意しません。 サービスのSLS要件が使用できるトポロジーのタイプに関係を持っていることに注意するのは重要です。
To the extent possible, an L2VPN service SHOULD be capable of crossing multiple administrative boundaries.
可能であることで、L2VPNがSHOULDを調整するという範囲と、複数の管理境界に交差できてください。
To the extent possible, the L2VPN services SHOULD be independent of access network technology.
可能な範囲内で、L2VPNサービスSHOULDはアクセスネットワーク技術の如何にかかわらずそうです。
5.4. Isolated Exchange of Data and Forwarding Information
5.4. データと推進情報の孤立交換
L2VPN solutions SHALL define means that prevent CEs in an L2VPN from interaction with unauthorized entities.
L2VPNソリューションSHALLはL2VPNで権限のない実体との相互作用からCEsを防ぐ手段を定義します。
L2VPN solutions SHALL avoid introducing undesired forwarding information that could corrupt the L2VPN forwarding information base.
L2VPNソリューションSHALLは、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 SHOULDでは、広告を出さないでください。内部の構造、そのL2VPNの外から発見可能です。
5.5. Security
5.5. セキュリティ
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ソリューションはどのセキュリティ機能をサポートするか、そして、1顧客あたり1個のベースでどうしたらそのような特徴は構成できるかを述べなければなりません。
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のセットアップと操作で起こります、misconfigurationsからL2VPNで発射できて、メモリスペースなどのネットワーク資源を張ることができる攻撃まで及んで、情報ベーステーブル、帯域幅、およびCPU処理を進めて。
Augustyn & Serbest Informational [Page 9] RFC 4665 Service Requirements for L2VPNs September 2006
Augustyn&Serbestの情報[9ページ]のRFC4665は2006年9月にL2VPNsのための要件を修理します。
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 Excessiveプロトコル隣接番組セットアップ/分解o Excessiveプロトコルシグナリング/退出を攻撃します。
- Resource Utilization
o Forwarding plane replication (VPLS)
o Looping (VPLS primarily)
o MAC learning table size limit (VPLS)
- リソースUtilization o Forwarding飛行機模写(VPLS)o Looping、(VPLS、主として)、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
- PEへのVLANタグo Unauthorizedアクセスを区切るVPN o Incorrect顧客インタフェースo Incorrectサービスの不正アクセスo Unauthorizedメンバー
- Tampering with signaling
o Incorrect FEC signaling
o Incorrect PW label assignment
o Incorrect signaled VPN parameters (e.g., QoS, MTU, etc.)
- シグナリングo Incorrect FECシグナリングo Incorrect PWラベル課題o Incorrectをいじると、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 Incorrectトンネルカプセル化を使用することでo Incorrect MAC学習エントリーo Incorrect PWラベルo Incorrect交流識別子o Incorrectの顧客の面しているカプセル化o Incorrect PWカプセル化o Hijacking PWsを進めながら、データをいじります。
5.5.1. User Data Security
5.5.1. 利用者データセキュリティ
An L2VPN solution MUST provide traffic separation between different L2VPNs.
L2VPNソリューションは異なったL2VPNsの間にトラフィック分離を供給しなければなりません。
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 Idsはサービスデリミタとして使用されるかもしれません。 この様に使用されると、それらは光栄に思うに違いありません、そして、トラフィック分離を提供しなければなりません。
5.5.2. Access Control
5.5.2. アクセス制御
An L2VPN solution MAY also have the ability to activate the appropriate filtering capabilities upon request of a customer.
また、L2VPNソリューションには、顧客の要求のときに適切なフィルタリング能力を活性化する能力があるかもしれません。
Augustyn & Serbest Informational [Page 10] RFC 4665 Service Requirements for L2VPNs September 2006
Augustyn&Serbestの情報[10ページ]のRFC4665は2006年9月にL2VPNsのための要件を修理します。
5.6. Addressing
5.6. アドレシング
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ソリューションは異なったL2VPNsのアドレスを重なるのにサポートしなければなりません。 例えば、異なったL2VPNsと共に同じMACアドレスを使用するのを顧客を防いではいけません。 サービスプロバイダーがサービスデリミタとしてVLANsを使用するなら、L2VPNソリューションは、VLAN Idsが重なることができないのを確実にしなければなりません。 VLANsがサービスデリミタとして使用されないなら、L2VPNソリューションで、VLAN Idsは重なることができるかもしれません。
5.7. Quality of Service
5.7. サービスの質
To the extent possible, L2VPN QoS SHOULD be independent of the access network technology.
可能な範囲内で、L2VPN QoS SHOULDはアクセスネットワーク技術の如何にかかわらずそうです。
5.7.1. QoS Standards
5.7.1. 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 SHALLができるなら以下が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.
VCに基づいて(例えば、FR/ATMかVLAN)を写像するQoSと同様にPSN QoS(例えば、DSCPsかMPLS EXP分野)へのLayer2QoSパラメタに関するマッピングか翻訳が、透明をQoSに供給するために実行されるかもしれません。 このドキュメントの範囲の外にこれらのマッピングか翻訳のための実際のメカニズムがあります。 さらに、基本的なトンネリング技術(例えば、[RFC3270]か[RFC3308])とIntservモデル([RFC2205])のDiffservサポートは使用されるかもしれません。 そういうものとしてL2VPN SLS要件SHOULD、適切なコアメカニズムで、サポートされてください。
5.7.2. Service Models
5.7.2. サービスモデル
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])分野の両方がこのために使用されるかもしれません。
Augustyn & Serbest Informational [Page 11] RFC 4665 Service Requirements for L2VPNs September 2006
Augustyn&Serbestの情報[11ページ]のRFC4665は2006年9月にL2VPNsのための要件を修理します。
5.8. Service Level Specifications
5.8. サービスレベル仕様
For an L2VPN service, the capabilities for Service Level Specification (SLS) monitoring and reporting stated in [RFC3809] SHOULD be provided.
L2VPNサービスのために、Service Level Specification(SLS)モニターと報告のための能力は、[RFC3809]SHOULDに提供されるように述べました。
5.9. Protection and Restoration
5.9. 保護と王政復古
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サービスインフラストラクチャSHOULDは、高い有用性を確実にするために冗長パスを提供します。 迂回経路を使用することでサービスを復元する試みにおける失敗SHOULD結果への反応。
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.
意志は回復時間を小さく保つことです。 回復時間はそれがCEデバイスを取る時以下であるに違いありませんか顧客Layer2は、L2VPNに失敗を検出するためにLayer3ルーティング・プロトコルと同様にプロトコルを制御します。
5.10. CE-to-PE and PE-to-PE Link Requirements
5.10. PEへのCeとPEへのPEリンク要件
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、および1T1/EのTDM)を指示してください--論理的なリンク(例えば、ATM PVC、およびRFC2427によってカプセル化されたリンク)--イーサネットを運ぶ転送ネットワーク--Layer3ネットワーク(例えば、L2TPセッション)に直面しているLayer2トンネル。
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のフレームはLayer3バックボーンを通してPEからPEまでトンネルを堀られるかもしれません、さまざまなトンネリング技術(例えば、中のIP IP、GRE、MPLS、L2TPなど)の1つを使用して。
5.11. Management
5.11. 管理
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.
(例えば、標準のSNMP MIB Modules)をL2VPNサービスを管理する標準インターフェースに提供しなければなりません。 SHOULDが提供するこれらのインタフェースは構成、検証、およびランタイムまでモニターしているプロトコルにアクセスします。
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'の機能性を含むかもしれません: 欠点、Configuration、Accounting、パフォーマンス、および詳細なコネとしてのSecurity[ITU_Y.1311.1]。
5.12. Interoperability
5.12. 相互運用性
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.
保証されていて、マルチベンダ相互運用性、どれが同様のネットワークに対応しているか、そして、およびサービスはネットワーク要素SHOULDの異なった実装の中で平らにします。 これはおそらく対応する規格の完全性を当てにするでしょう。
Augustyn & Serbest Informational [Page 12] RFC 4665 Service Requirements for L2VPNs September 2006
Augustyn&Serbestの情報[12ページ]のRFC4665は2006年9月にL2VPNsのための要件を修理します。
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ソリューションSHOULD NOTは異なったアクセス技術を排除します。 例えば、L2VPNサービスとの顧客アクセス接続は異なったCEデバイス(例えば、Frame Relay、ATM、802.1D、MPLS)で異なっているかもしれません。
5.13. Inter-working
5.13. 織り込むこと
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ソリューションか異なった実装でネットワークドメインにかかります。 SHOULDを織り込んで、スケーラブルな方法でサポートされてください。
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と、アクセスと、管理局面であると考えなければなりません。 この要件は、ネットワークの異なった部分に属しながらサイトの中でサービスの連続を確実にするのにネットワーク移行の場合で不可欠です。
6. Customer Requirements
6. 顧客の要求
This section captures requirements from a customer perspective.
このセクションは顧客見解からの要件を得ます。
6.1. Service Provider Independence
6.1. サービスプロバイダー独立
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と共に独身のASに提供されたL2VPNから始まりますが、複数のASes、そして/または、複数のSPsにかかるサービスの拡張を求めるかもしれません。 それが家へ帰るAS/SPにかかわらずVPNのすべてのサイトに同じSLSを同じくらいこの場合、すべての種類のマルチASと複数のSP L2VPNs、L2VPNサービスSHOULDと同じくらいよく提供できてください。
6.2. Layer 3 Support
6.2. 層3のサポート
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はLayerの中でカプセル化された顧客のLayer3トラフィック(例えば、IP、IPX、Appletalk)への不可知論者が2個のフレームであったならSHOULDを調整します。
Augustyn & Serbest Informational [Page 13] RFC 4665 Service Requirements for L2VPNs September 2006
Augustyn&Serbestの情報[13ページ]のRFC4665は2006年9月にL2VPNsのための要件を修理します。
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 MUSTはトラフィックがLayer2フレームの中にカプセル化した顧客のIPv4とIPv6の輸送を許容します。 また、ものがIPに関連して使用されるとき、IPLS SHOULDはCEsに透過的にそれらの中でイシスとMPLSプロトコルを車で送らせます。
6.3. Quality of Service and Traffic Parameters
6.3. サービスの質とトラフィックパラメタ
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サービスが声、双方向テレビ、およびPWs(例えば、Sonetエミュレーション)からマルチメディア応用まで及ぶことができるその人のアプリケーションに適切なQoSを提供するのを必要とします。 したがって、L2VPNサービスの上でベストエフォート型の、そして、遅れと損失敏感なトラフィックをサポートしなければなりません。 アクセスネットワーク技術の如何にかかわらず一貫したQoSが異なったサイトで使用した顧客アプリケーションSHOULD経験は同じL2VPNに接続しました。
6.4. Service Level Specification
6.4. サービスレベル仕様
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の使用法をモニターする標準インターフェースはSHOULDを調整します。(例えば、標準のSNMP MIB Modules)を提供してください。
6.5. Security
6.5. セキュリティ
6.5.1. Isolation
6.5.1. 分離
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 Idsを使用するかもしれません。 その場合、それらは光栄に思わなければなりません、そして、トラフィック分離を提供しなければなりません。
6.5.2. Access Control
6.5.2. アクセス制御
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の間で考えられるかもしれません。
Augustyn & Serbest Informational [Page 14] RFC 4665 Service Requirements for L2VPNs September 2006
Augustyn&Serbestの情報[14ページ]のRFC4665は2006年9月にL2VPNsのための要件を修理します。
6.5.3. Value-Added Security Services
6.5.3. 付加価値が付いたセキュリティー・サービス
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サービスはLayer3と、より高い層で顧客によって使われたセキュリティー対策を妨げてはいけません。 802.10b([IEEE_802.10])や802.1AEなどの層の2セキュリティー対策([IEEE_802.1AE])はL2VPNサービスを抑制するかもしれません、VLAN Idsを区切るサービスが暗号化されているとき。
6.6. Network Access
6.6. ネットワークアクセス
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によって提供されたそれに対する同等なサービスを提供する私設のネットワークで見えるように見えなければなりません。
6.6.1. Physical/Link Layer Technology
6.6.1. 物理的な/リンクレイヤ技術
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ソリューションSHOULDは、広範囲な物理的、そして、リンク層がアクセス技術であるとサポートします、PSTN、ISDN、xDSL、ケーブルモデム、専用線、イーサネット、イーサネットVLAN、ATM、Frame Relay、Wireless回線折返し、移動無線アクセスなどのように 容量と達成可能なQoSは使用中の特定のアクセス技術に依存しているかもしれません。
6.6.2. Access Connectivity
6.6.2. アクセスの接続性
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は集合SHOULDをリンクします。サポートされます。 L2VPNソリューションSHOULDは少なくとも図2に示された物理的であるかリンクレイヤ接続性アレンジメントのタイプをサポートします--4(図1で見せられたケースに加えた)。 CEが図2のように図であることができる、二元的である、-、家へ帰り、SP、または、さまざまを通した2異なったSPsに、ネットワークにアクセスしてください。
Augustyn & Serbest Informational [Page 15] RFC 4665 Service Requirements for L2VPNs September 2006
Augustyn&Serbestの情報[15ページ]のRFC4665は2006年9月にL2VPNsのための要件を修理します。
+---------------- +---------------
| |
+------+ +------+
+---------| PE | +---------| PE |
| |device| | |device| SP network
| +------+ | +------+
+------+ | +------+ |
| CE | | | CE | +---------------
|device| | SP network |device| +---------------
+------+ | +------+ |
| +------+ | +------+
| | PE | | | PE |
+---------|device| +---------|device| SP network
+------+ +------+
| |
+---------------- +---------------
(a) (b)
+---------------- +--------------- | | +------+ +------+ +---------| PE| +---------| PE| | |デバイス| | |デバイス| SPネットワーク| +------+ | +------+ +------+ | +------+ | | Ce| | | Ce| +--------------- |デバイス| | SPネットワーク|デバイス| +--------------- +------+ | +------+ | | +------+ | +------+ | | PE| | | PE| +---------|デバイス| +---------|デバイス| SPネットワーク+------+ +------+ | | +---------------- +--------------- (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.
図3にCEが「裏口」接続で接続されたところで同じSP、または、異なったSPsに接続するように示すとき、さらにL2VPNサービスの弾性を高めることができます。
+---------------- +---------------
| |
+------+ +------+ +------+ +------+
| 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)
+---------------- +--------------- | | +------+ +------+ +------+ +------+ | Ce|-----| PE| | Ce|-----| PE| |デバイス| |デバイス| |デバイス| |デバイス| SPネットワーク+------+ +------+ +------+ +------+ | | | | | 裏口| | 裏口+--------------- | リンク| SPネットワーク| リンク+--------------- | | | | +------+ +------+ +------+ +------+ | Ce| | PE| | Ce| | PE| |デバイス|-----|デバイス| |デバイス|-----|デバイス| SPネットワーク+------+ +------+ +------+ +------+ | | +---------------- +--------------- (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、SHOULDに示されたいくつかの例がある上のメソッドでは、あらゆるL2VPNソリューションで、サポートされてください。
Augustyn & Serbest Informational [Page 16] RFC 4665 Service Requirements for L2VPNs September 2006
Augustyn&Serbestの情報[16ページ]のRFC4665は2006年9月にL2VPNsのための要件を修理します。
+---------------- +---------------
| |
+------+ +------+ +------+ +------+
| 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)
+---------------- +--------------- | | +------+ +------+ +------+ +------+ | Ce|-----| PE| | Ce|-----| PE| |デバイス| |デバイス| |デバイス| |デバイス| SPネットワーク+------+\ +------+ +------+\ +------+ | \ | | \ | |逆\| |逆\+------------- |ドア、\| SPネットワーク|ドア\+------------- |リンク\| |リンク\| +------+ +------+ +------+ +------+ | Ce| | PE| | Ce| | PE| |デバイス|-----|デバイス| |デバイス|-----|デバイス| SPネットワーク+------+ +------+ +------+ +------+ | | +---------------- +--------------- (a) (b)
Figure 4. Combination of Dual-Homing and
Backdoor Links for CE Devices
図4。 Ceデバイスのためのデュアルホーミングと裏口のリンクの組み合わせ
6.7. Customer Traffic
6.7. 顧客トラフィック
6.7.1. Unicast, Unknown Unicast, Multicast, and Broadcast forwarding
6.7.1. ユニキャスト、Unknown Unicast、Multicast、およびBroadcast推進
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 MUSTはイングレスの取り締まりと安全保障政策を条件として少なくともVPLSの範囲の中の意図している送付先にあらゆるパケットを提供します。
6.7.2. Packet Re-ordering
6.7.2. パケット再注文
During normal operation, the queuing and forwarding policies SHOULD preserve packet order for packets with the same QoS parameters.
通常の操作の間、列を作りと推進方針SHOULDは同じQoSパラメタでパケットのパケット注文を保存します。
6.7.3. Minimum MTU
6.7.3. 最小のMTU
A VPLS MUST support the theoretical MTU of the offered service.
VPLS MUSTは提供サービスの理論上の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.
与えられたVPLSインスタンスに、遂行された最小のMTUサイズは同じであるに違いありません。 異なったL2VPNサービスには、異なった遂行されたMTUサイズがあるかもしれません。 顧客VLANsがサービスデリミタとして使用されるなら、与えられたVPLS MUSTの中のすべてのVLANsが同じMTUサイズを引き継ぎます。
A VPLS MAY use IP fragmentation if it presents reassembled packets at VPLS customer edge devices.
VPLS顧客エッジデバイスに組み立て直されたパケットを提示するなら、VPLS MAYはIP断片化を使用します。
Augustyn & Serbest Informational [Page 17] RFC 4665 Service Requirements for L2VPNs September 2006
Augustyn&Serbestの情報[17ページ]のRFC4665は2006年9月にL2VPNsのための要件を修理します。
6.7.4. End-point VLAN Tag Translation
6.7.4. エンドポイントVLANタグ翻訳
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サービスは顧客の交流識別子に関する翻訳をサポートするかもしれません(例えば、VLANタグ、顧客であるなら、VLANsはサービスデリミタとして使用されます)。 そのようなサービスはそれらの西暦が課題であることを保ちたがっているサイトか異なった管理ドメインに属すサイトの接続性を簡素化します。 後者の場合では、接続性はLayer2エクストラネットと時々呼ばれます。 他方では、VLANタグ翻訳が複数のスパニングツリー(すなわち、802.1[IEEE_802.1])のサポートに影響して、適切な操作を壊すことができることに注意されるべきです。
6.7.5. Transparency
6.7.5. 透明
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サービスがLayer2顧客ネットワークに透明であることを意図します。 SHOULD NOTがプロバイダーのネットワークにパケットを送りながらエンドユーザによる特別なパケット処理を必要とする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 IdsがSPによって割り当てられるなら、VLANsは透明ではありません。 それが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ソリューション目的がトラフィック(Layer2フレーム自体よりむしろ)をカプセル化したので、IPLSソリューションはIPLSによって輸送されるLayer2フレームの中にカプセルに入れられたパケットを変更してはいけません。 しかしながら、IPLSソリューションは透過的にCEからCEまでLayer2ヘッダーを保存するNOT REQUIREDです。 例えば、Source MACアドレスはIPLSソリューションによって保存されないかもしれません。 IPLSソリューションはLayerを取り外すかもしれません。出口でカプセル化されたトラフィックの輸送に感染しないでものを再建できるバックボーンの上の輸送のための2個のヘッダー。
6.8. Support for Layer 2 Control Protocols
6.8. 層2のために、コントロールがプロトコルであるとサポートしてください。
The L2VPN solution SHOULD allow transparent operation of Layer 2 control protocols employed by customers.
L2VPNソリューションSHOULDは顧客によって使われたLayer2制御プロトコルのわかりやすい操作を許します。
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サービスは、輪が防がれるのを確実にしなければなりません。 無輪のトポロジーか適切な推進規則でこれを達成できます。 Spanning Treeなどの制御プロトコル(STP)か同様のプロトコルを使うことができました。 L2VPNソリューションは顧客Layer2制御プロトコル、例えば、VPLSの操作を改良するために詮索するSTP BPDUから指摘を使用するかもしれません。
Augustyn & Serbest Informational [Page 18] RFC 4665 Service Requirements for L2VPNs September 2006
Augustyn&Serbestの情報[18ページ]のRFC4665は2006年9月にL2VPNsのための要件を修理します。
6.9. CE Provisioning
6.9. Ceの食糧を供給すること
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デバイスのタイプに頼っていて。
7. Service Provider Network Requirements
7. サービスプロバイダーネットワーク要件
This section describes requirements from an SP perspective.
このセクションはSP見解からの要件について説明します。
7.1. Scalability
7.1. スケーラビリティ
This section contains projections regarding L2VPN sizing and scalability requirements and metrics specific to particular solutions.
このセクションは特殊解に特定のL2VPNサイズ処理に関する映像、スケーラビリティ要件、および測定基準を含みます。
7.1.1. Service Provider Capacity Sizing Projections
7.1.1. 映像を大きさで分けるサービスプロバイダー容量
[RFC3809] lists projections regarding L2VPN sizing and scalability requirements and metrics. The examples are provided in [RFC3809].
[RFC3809]はL2VPNサイズ処理に関する映像、スケーラビリティ要件、および測定基準をリストアップします。 [RFC3809]に例を提供します。
7.1.2. Solution-Specific Metrics
7.1.2. ソリューション特有の測定基準
Each L2VPN solution SHALL document its scalability characteristics in quantitative terms.
それぞれのL2VPNソリューションSHALLは量的な用語でスケーラビリティの特性を記録します。
7.2. Identifiers
7.2. 識別子
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).
複数のSPsにかかるL2VPNをサポートするとき、少なくともすべてのインタコネクトされたSPネットワークのセットの中で唯一SPドメインを特定しなければなりません。 理想的に、この識別子SHOULDはグローバルにそうです。ユニークです(例えば、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 SHOULDのための識別子は、ユニークであり、それとして少なくともSPの各ところの中で5月をネットワークでつなぎます。自動発見、管理(例えば、相関関係を驚かせて、修理してください、障害調査しています、性能統計収集)、およびシグナリングでは、使用されてください。 理想的に、L2VPN識別子SHOULDはグローバルにそうです。ケースを支えるために、ユニークです。(そこでは、L2VPNが複数のSPs(例えば、[RFC2685])にかかります)。 グローバルにユニークな識別子は相互AS/SP L2VPNsのサポートを容易にします。
7.3. Discovering L2VPN Related Information
7.3. 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に、重要なタスクです。 ソリューションSHOULDはL2VPN情報が構成ステップを最小にするとPEsによって発見されるのをダイナミックに許容するメソッドを提供します。
Augustyn & Serbest Informational [Page 19] RFC 4665 Service Requirements for L2VPNs September 2006
Augustyn&Serbestの情報[19ページ]のRFC4665は2006年9月にL2VPNsのための要件を修理します。
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 SHOULDでは、どの対向機器が同じ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情報SHOULDでは、そのL2VPNにかかわるそれらのデバイスに制限されてください。 SPsによって維持された運用情報の量を最小にするL2VPNソリューションSHOULD雇用発見メカニズム。 例えば、SPが与えられたPEの上の顧客ポートを加えるか、または取り外すなら、残っているPEs SHOULDは、必要な行動が明らかにそれらのPEsを再構成するためにSPの有なしで取ることを決定します。
A L2VPN solution SHOULD support the means for attached CEs to authenticate each other and to verify that the SP L2VPN is correctly connected.
SHOULDが手段をサポートするL2VPNソリューションは、互いを認証して、SP L2VPNが正しく接続されることを確かめるためにCEsを取り付けました。
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.
メカニズムSHOULDは直ちに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ソリューションで扱わなければならない会員資格のもう一つの側面です。
7.4. Quality of Service (QoS)
7.4. サービスの質(QoS)
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サービスのどちらかを提供することになっています。
7.5. Isolation of Traffic and Forwarding Information
7.5. トラフィックと推進情報の分離
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 MUSTは認証されるそれらのサイトだけへのトラフィックと推進情報の交換と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.
SHOULDがプロバイダーの食糧を供給されたVPN QoS SLS必要条件を満たすためのトラフィックの感情からL2VPNトラフィックを隔離する手段を提供するL2VPNソリューションは非VPN顧客を提供しました。 また、L2VPNソリューションSHOULDが手段を提供するので、1L2VPNの一部が別のL2VPNに影響しないので、その交通渋滞はサイトのそばで生産されました。
Augustyn & Serbest Informational [Page 20] RFC 4665 Service Requirements for L2VPNs September 2006
Augustyn&Serbestの情報[20ページ]のRFC4665は2006年9月にL2VPNsのための要件を修理します。
7.6. Security
7.6. セキュリティ
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]SHOULDに供給されました。満たされます。 SHOULD、Layer3以外のセキュリティ要件と、より高い層の依存するものは[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ネットワークを保護しなければなりません。 写しか無効のLayer2つのアドレスに含んでいますが、これが限られていない、顧客サイド輪(管理パケットであると偽造された短いか長いパケット)はタグ(高いボリュームトラフィック)を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ネットワークSHOULDのデバイスは侵入試みを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.
機能SHOULDを超えて、顧客について「データは取引すること」に適切にしてください。(その顧客は、サイトの間で交換されたトラフィックを含んでいます)。 それ、SHOULDも、ルーティングやシグナリングプロトコル交換などの「コントロールトラフィック」にこれらの機能を適用するのにおいて可能で、すなわち、必ず顧客によって知覚されているというわけではありませんが、それにもかかわらず、その人の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.
その上、そのようなセキュリティメソッドは異なったエンドポイントの間で構成可能であるに違いありません、PE-PEやPE-MTUのように、L2VPNデータ通信量がIP[RFC4023]の上まで運ばれる場合だけで。 このドキュメントの範囲の外に自然なサービス層(層-2)でCE-CEからデータフローを保証するメソッド(CE-MTUとCE-PE)は、あります。 また、1VPNあたり1個のベースでセキュリティを構成するのも望ましいです。
Augustyn & Serbest Informational [Page 21] RFC 4665 Service Requirements for L2VPNs September 2006
Augustyn&Serbestの情報[21ページ]のRFC4665は2006年9月にL2VPNsのための要件を修理します。
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ソリューションは、1つ以上の暗号化がAES、および3DESを含む体系であるとサポートするかもしれません。 暗号化、復号化、含まれているコネがセキュリティマネージメントシステムの一部としてプロフィールであったなら管理SHOULDを合わせてください。
7.7. Inter-AS/SP L2VPNs
7.7. 相互、/SP L2VPNs
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.
トラフィックや推進情報分離などのすべての適切なSP要件、SLSes、管理、セキュリティ、食糧を供給すること 隣接している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ソリューションは複数のASes、そして/または、SPsの面前ですべてのL2VPNサービスの要素に操作上のパラメタの適切な普及をサポートしなければなりません。 L2VPNソリューションは、異なったASesの間の操作上のパラメタを共有するのにメカニズムを使わなければなりません。
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.
SHOULDが異なったASesから来る操作上のパラメタの適切な品揃えのための方針をサポートするL2VPNソリューション。 同様に、L2VPNソリューションSHOULDは情報が異なったASesに広められるのを選択するための方針をサポートします。
7.7.1. Management
7.7.1. 管理
The general requirements for managing a single AS apply to a concatenation of ASes. A minimum subset of such capabilities is the following:
独身のASを管理するための一般的な要件はASesの連結に適用されます。 そのような能力の最小の部分集合は以下です:
- Diagnostic tools
- 診断用道具
- Secured access to one AS management system by another
- 1台のASマネージメントシステムへのアクセスであると別のものによって機密保護されます。
- Configuration request and status query tools
- 構成要求と状態質問ツール
- Fault notification and trouble tracking tools
- 欠点通知とツールを追跡することにおける苦労
7.7.2. Bandwidth and QoS Brokering
7.7.2. 帯域幅とQoS仲介
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が複数のASesにかかるとき、あるSLSパラメタを要求する仲介メカニズムの必要があります、帯域幅やQoSのように、トラフィックを移すのにかかわる他のドメイン、そして/または、ネットワークから様々なサイトまで。 必須の条件はソリューションが、ASesの1セットがプロバイダーを支持して一定のQoSを設立して、保証できるかどうかがVPNに食糧を供給したことを決定できなければならないということです。
Augustyn & Serbest Informational [Page 22] RFC 4665 Service Requirements for L2VPNs September 2006
Augustyn&Serbestの情報[22ページ]のRFC4665は2006年9月にL2VPNsのための要件を修理します。
7.8. L2VPN Wholesale
7.8. L2VPN卸売り
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.
アーキテクチャは1SPが別のSPに対するサービスをL2VPNに提供する可能性をサポートしなければなりません。 1つの例が1SPが次にその人の顧客に対するそのL2VPNサービスを転売する別のSPへの卸売りでサービスをL2VPNに販売する時です。
7.9. Tunneling Requirements
7.9. トンネリング要件
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.
接続性、バックボーンSHOULDの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 MUSTがトンネルセットアッププロトコルをサポートします。 PE MAYは静的な構成をサポートします。 採用しているaトンネル設立がSHOULDについて議定書の中で述べるなら、以下などのように情報を伝達できてください:
- 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.
トンネリング選択にかかわらず、顧客にとって、トンネルと彼らの操作の存在は透明であるに違いありません。
7.10. Support for Access Technologies
7.10. アクセス技術のサポート
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デバイスの間の接続性は西暦と呼ばれます。 ACsは他のプロバイダーか公衆通信回線のネットワークにかかるかもしれません。
Augustyn & Serbest Informational [Page 23] RFC 4665 Service Requirements for L2VPNs September 2006
Augustyn&Serbestの情報[23ページ]のRFC4665は2006年9月にL2VPNsのための要件を修理します。
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ベースの仮想のFrame Relayなどを含んでいます。
In case of VPLS, the AC MUST use Ethernet frames as the Service Protocol Data Unit (SPDU).
VPLSの場合には、西暦はServiceプロトコルData Unit(SPDU)としてイーサネットフレームを使用しなければなりません。
A CE access connection over an AC MUST be bi-directional.
西暦の上の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.
ダイレクトであるか、または仮想であることにかかわらず西暦は、すべてがプライオリティQoSなどの顧客トラフィックの特性を遂行したと主張しなければなりません。 西暦の特性は単にその接続に適切です。
7.11. Backbone Networks
7.11. バックボーンネットワーク
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デバイスSHOULDは物理的であるのから独立していて、技術をリンクで層にします。 VPNサービス提供にSLSesのQoS局面を指定するとき、それにもかかわらず、バックボーン技術の特性を考慮に入れなければなりません。
7.12. Network Resource Partitioning and Sharing Between L2VPNs
7.12. ネットワーク資源仕切りとL2VPNsを平等に割り当てること。
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処理はL2VPNs(どんな特定のL2VPNサービスインスタンスも利用可能なネットワーク資源を取って、他のものが失敗されるのを防ぐのに必要なリソースのソリューションSHOULD保証の有用性)の間で共有されます。 ソリューションSHOULD、L2VPNサービスインスタンスによって消費されたリソースは制限できてください。 ソリューションSHOULDは遂行されたSLSesの義務を果たすのに必要なリソースの有用性を保証します。
7.13. Interoperability
7.13. 相互運用性
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デバイスの使用を容易にするために
Augustyn & Serbest Informational [Page 24] RFC 4665 Service Requirements for L2VPNs September 2006
Augustyn&Serbestの情報[24ページ]のRFC4665は2006年9月にL2VPNsのための要件を修理します。
- 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.
各アプローチは、上の目的のどれかを満たすことができるかどうか説明しなければなりません。 目的を満たすことができるなら、アプローチはどうそのような相互運用性を達成できたかを説明しなければなりません。
7.14. Testing
7.14. テスト
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.
顧客VLANsがサービスデリミタとして使用されるなら、L2VPNソリューションSHOULDはそしてVPLSの場合に1VLANあたり1個のベースでL2VPN調査基準価格あたりのaで操作上とメインテナンス活動をテストして、確かめる能力を提供します。
The L2VPN solution SHOULD provide mechanisms for connectivity verification, and for detecting and locating faults.
L2VPNソリューションSHOULDは欠点を接続性検証と、検出して、場所を見つけるのにメカニズムを提供します。
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ネットワークの限界を超えて伝播されてはいけません。
7.15. Support on Existing PEs
7.15. 存在するとき、PEsをサポートしてください。
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ソリューションSHOULDはSPによって既に配布されるかもしれなくて、主としてLayer3サービスのために設計されるかもしれない既存のPEデバイスにおけるIPLSのサポートを容易にします。
Augustyn & Serbest Informational [Page 25] RFC 4665 Service Requirements for L2VPNs September 2006
Augustyn&Serbestの情報[25ページ]のRFC4665は2006年9月にL2VPNsのための要件を修理します。
8. Service Provider Management Requirements
8. サービスプロバイダー管理要件
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サービスを提供する設備に関連している状態、および他のパラメタに食糧を供給して。 したがって、SHOULDがどこでも、可能であるところの規格ベースのインタフェース(例えば、L2VPN MIB Modules)を供給するデバイス。
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].
伝統的な欠点における、Network Management Systemのためのサービスプロバイダー管理要件(NMS)の詳細、[ITU_Y.1311.1]で構成、会計、性能、およびセキュリティ(FCAPS)管理カテゴリを見つけることができます。
9. Engineering Requirements
9. 工学要件
These requirements are driven by implementation characteristics that make service and SP requirements achievable.
これらの要件はサービスとSP要件を達成可能にする実装の特性によって動かされます。
9.1. Control Plane Requirements
9.1. コントロール飛行機要件
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を調整します。最小の数のステップで、食糧を供給されます。 したがって、コントロールプロトコルSHOULDはPEsの間で合図するためのメソッドを提供します。 情報、および他の関連パラメタにトンネルを堀って、シグナリングSHOULDは会員資格について知らせます。
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.
インフラストラクチャSHOULDは特定のL2VPNのための会員資格と可到達性広告が調整する範囲に方針を使用します。 提供するL2VPN MUSTに関連しているそれらのサイトだけに可到達性情報の分配を隔離するためのメカニズム。
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.
SHOULDがコントロール飛行機通行と消費を最小にするL2VPNソリューションは飛行機リソースを制御します。 制御飛行機は、限界にL2VPNサービスに付けられた顧客ホストの数に押しつけるために手段を提供するかもしれません。
Augustyn & Serbest Informational [Page 26] RFC 4665 Service Requirements for L2VPNs September 2006
Augustyn&Serbestの情報[26ページ]のRFC4665は2006年9月にL2VPNsのための要件を修理します。
9.2. Data Plane Requirements
9.2. データ飛行機要件
9.2.1. Encapsulation
9.2.1. カプセル化
An L2VPN solution SHOULD utilize the encapsulation techniques defined by PWE3 ([RFC3985]), and SHOULD not impose any new requirements on these techniques.
L2VPNソリューションSHOULDはPWE3([RFC3985])によって定義されたカプセル化技術を利用します、そして、SHOULDはどんな新しい要件もこれらのテクニックに課しません。
9.2.2. Responsiveness to Congestion
9.2.2. 混雑への反応性
An L2VPN solution SHOULD utilize the congestion avoidance techniques defined by PWE3 ([RFC3985]).
L2VPNソリューションSHOULDはPWE3([RFC3985])によって定義された輻輳回避のテクニックを利用します。
9.2.3. Broadcast Domain
9.2.3. 放送ドメイン
A separate Broadcast Domain MUST be maintained for each VPLS.
各VPLSのために別々のBroadcast Domainを維持しなければなりません。
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 Broadcast Domainsに加えて、L2VPNサービスは顧客VLAN Broadcast Domainsを尊敬するかもしれません、顧客VLANsがサービスデリミタとして使用されるなら。 その場合、L2VPNソリューションSHOULDはそれぞれの顧客VLANのために別々のVLAN Broadcast Domainを維持します。
9.2.4. Virtual Switching Instance
9.2.4. 仮想の切り換えインスタンス
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デバイスは1VPLSあたり1別々のVSIを維持しなければなりません。 各VSI MUSTには、顧客のトラフィックパラメタに基づくトラフィックを進める能力があります、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 MUSTには、Broadcast DomainがBroadcast、Multicast、およびUnknown Unicast顧客トラフィックの適切な推進を容易にする氾濫能力があります。
9.2.5. MAC Address Learning
9.2.5. マックーアドレス学習
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 SHOULDがすべてのトポロジーと推進情報に顧客サイトで起因するパケットに由来しています。 通常、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基礎あたりのaで行われなければなりません。 すなわち、a VPLSとサポートされるときのコネの文脈、そこにVLANsの文脈。
Augustyn & Serbest Informational [Page 27] RFC 4665 Service Requirements for L2VPNs September 2006
Augustyn&Serbestの情報[27ページ]のRFC4665は2006年9月にL2VPNsのための要件を修理します。
10. Security Considerations
10. セキュリティ問題
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の顧客とサービスプロバイダー見解からトラフィックに関する詳細とルーティング分離要件をそれぞれ与えます。 CPUや、メモリや、帯域幅などのネットワーク資源を保護する安全装置がセクション7.12で必要です。
IPsec can also be applied after tunneling Layer 2 traffic to provide additional security.
また、追加担保を提供するためにLayer2トラフィックにトンネルを堀った後に、IPsecを適用できます。
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ネットワークを横断して、unsecured SP、POP、NAP、またはIXを通り抜ける場合では、セキュリティー対策を使わなければなりません。 これらのセキュリティー対策はセクション5.5で説明されるように暗号化、認証、およびリソース保護を含んでいます。 例えば、プロバイダーは、別のサービスプロバイダーのネットワークを横断するL2VPNの一部として使用されるトンネルに認証と暗号化の両方を使用すると考えるべきです。
11. Acknowledgements
11. 承認
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アンデション、ジョエル・アルペルン、エリック・ローゼン、アリSajassi、Muneyoshi鈴木、Ananth Nagarajan、Dineshモハン、ヤコフRekhter、マットSquire、Normフィンランド人、スコット・ブラドナー、およびフランソアLe Faucheurによって提供された大規模なコメントと貢献を承諾したがっています。 また、作者はこの仕事を見直すのを買って出て、フィードバックを前提とした彼らのそれぞれの雇い主と他の様々な人々に彼らの感謝を与えたがっています。 全体のLayer2PPVPNデザインチームとの相談でこの仕事をしました。 多くのテキストがVPN要件デザインが組にするLayer3によって製作されたLayer3VPN要件ドキュメントから翻案されました。
Augustyn & Serbest Informational [Page 28] RFC 4665 Service Requirements for L2VPNs September 2006
Augustyn&Serbestの情報[28ページ]のRFC4665は2006年9月にL2VPNsのための要件を修理します。
12. References
12. 参照
12.1. Normative References
12.1. 引用規格
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。
[RFC4026] Andersson, L. and T. Madsen, "Provider Provisioned
Virtual Private Network (VPN) Terminology", RFC 4026,
March 2005.
[RFC4026] アンデションとL.とT.マドセン、「プロバイダーの食糧を供給された仮想私設網(VPN)用語」、RFC4026、2005年3月。
12.2. Informative References
12.2. 有益な参照
[VPLS_LDP] Lasserre, M., Kompella, V. "Virtual Private LAN
Services over MPLS", Work in Progress.
[VPLS_自由民主党]ラセール、M.、Kompella対「MPLSの上の仮想の個人的なLANサービス」は進行中で働いています。
[VPLS_BGP] Kompella, K., Rekhter, Y. "Virtual Private LAN
Service", Work in Progress.
K.、Rekhter、Y.「仮想の個人的なLANサービス」という[VPLS_BGP]Kompellaは進行中で働いています。
[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 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] ブレーデン、R.、チャン、L.、Berson、S.、ハーツォグ、S.、およびS.ジャマン、「資源予約は(RSVP)について議定書の中で述べます--バージョン1の機能的な仕様」、RFC2205、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分野)の定義」、RFC2474(1998年12月)。
[RFC2685] Fox, B. and B. Gleeson, "Virtual Private Networks
Identifier", RFC 2685, September 1999.
[RFC2685] フォックスとB.とB.グリーソン、「仮想私設網識別子」、RFC2685、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.、ウー、L.、デイビー、B.、Davari、S.、バーナネン、P.、クリシュナン、R.、シェヴァル、P.、およびJ.Heinanen、「差別化されたサービスのマルチプロトコルラベルスイッチング(MPLS)サポート」、RFC3270)は2002がそうするかもしれません。
[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.ピアス、「層Twoのトンネリングプロトコル(L2TP)はサービス拡大を差別化しました」、RFC3308、2002年11月。
Augustyn & Serbest Informational [Page 29] RFC 4665 Service Requirements for L2VPNs September 2006
Augustyn&Serbestの情報[29ページ]のRFC4665は2006年9月にL2VPNsのための要件を修理します。
[RFC3809] Nagarajan, A., "Generic Requirements for Provider
Provisioned Virtual Private Networks (PPVPN)", RFC
3809, June 2004.
[RFC3809] Nagarajan、A.、「プロバイダーの食糧を供給された仮想私設網(PPVPN)のためのジェネリック要件」、RFC3809、2004年6月。
[RFC3985] Bryant, S. and P. Pate, "Pseudo Wire Emulation Edge-
to-Edge (PWE3) Architecture", RFC 3985, March 2005.
[RFC3985] ブライアントとS.とP.頭、「疑似ワイヤエミュレーション縁縁への(PWE3)アーキテクチャ」、RFC3985、2005年3月。
[RFC4023] Worster, T., Rekhter, Y., and E. Rosen,
"Encapsulating MPLS in IP or Generic Routing
Encapsulation (GRE)", RFC 4023, March 2005.
[RFC4023] オースター、T.、Rekhter、Y.、およびE.ローゼン、「IPか一般ルーティングのカプセル化(GRE)でMPLSをカプセル化します」、RFC4023(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)のための要件を修理します」、RFC4031、2005年4月。
[RFC4664] Andersson, L. and E. Rosen, "Framework for Layer 2
Virtual Private Networks (L2VPNs)", RFC 4664,
September 2006.
[RFC4664] アンデションとL.とE.ローゼン、「層2の仮想私設網(L2VPNs)のためのフレームワーク」、RFC4664、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/IEC15802-3: 1998ANSI/IEEE Std 802.1D、1998Edition、(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.1ITU-T推薦)は2001がそうするかもしれません。
[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 Std802.10-1998Edition(改正IEEE Std802.10-1992、IEEE Std 802.10b-1992、802.10e-1993、802.10f-1993、802.10g1995を取り入れて、および802.10h-1997)、「共同利用できるLAN/男性セキュリティの規格(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.1]IEEE Std 802.1s-2002、「仮想、ローカル・エリア・ネットワーク修正3であるとブリッジされます:、」 「複数のスパニングツリー」、2002。
Augustyn & Serbest Informational [Page 30] RFC 4665 Service Requirements for L2VPNs September 2006
Augustyn&Serbestの情報[30ページ]のRFC4665は2006年9月にL2VPNsのための要件を修理します。
Editors' Addresses
エディタのアドレス
Waldemar Augustyn
Waldemar Augustyn
EMail: waldemar@wdmsys.com
メール: waldemar@wdmsys.com
Yetik Serbest AT&T Labs 9505 Arboretum Blvd. Austin, TX 78759
Yetik Serbest AT&T研究室9505植物園Blvd. オースチン、テキサス 78759
EMail: yetik_serbest@labs.att.com
メール: yetik_serbest@labs.att.com
Augustyn & Serbest Informational [Page 31] RFC 4665 Service Requirements for L2VPNs September 2006
Augustyn&Serbestの情報[31ページ]のRFC4665は2006年9月にL2VPNsのための要件を修理します。
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (2006).
Copyright(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.
このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。
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.
このドキュメントと「そのままで」という基礎と貢献者、その人が代表する組織で提供するか、または後援されて、インターネット協会とインターネット・エンジニアリング・タスク・フォースはすべての保証を放棄します、と急行ORが含意したということであり、他を含んでいて、ここに含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
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はどんなIntellectual Property Rightsの正当性か範囲、実装に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するどんな独立している取り組みも作りました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。
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倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。
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 Editor機能のための基金はIETF Administrative Support Activity(IASA)によって提供されます。
Augustyn & Serbest Informational [Page 32]
Augustyn&Serbest情報です。[32ページ]
一覧
スポンサーリンク
