RFC4664 日本語訳
4664 Framework for Layer 2 Virtual Private Networks (L2VPNs). L.Andersson, Ed., E. Rosen, Ed.. September 2006. (Format: TXT=97768 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
英語原文
Network Working Group L. Andersson, Ed.
Request for Comments: 4664 Acreo AB
Category: Informational E. Rosen, Ed.
Cisco Systems, Inc.
September 2006
ワーキンググループのL.アンデション、エドをネットワークでつないでください。コメントのために以下を要求してください。 4664Acreo ABカテゴリ: エド情報のE.ローゼン、シスコシステムズInc.2006年9月
Framework for Layer 2 Virtual Private Networks (L2VPNs)
層2の仮想私設網のための枠組み(L2VPNs)
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 a framework for Layer 2 Provider Provisioned Virtual Private Networks (L2VPNs). This framework is intended to aid in standardizing protocols and mechanisms to support interoperable L2VPNs.
このドキュメントはLayer2Provider Provisioned Virtual兵士のNetworks(L2VPNs)に枠組みを供給します。 この枠組みが共同利用できるL2VPNsを支持するためにプロトコルとメカニズムを標準化する際に支援することを意図します。
Andersson & Rosen Informational [Page 1] RFC 4664 Framework for Layer 2 VPNs September 2006
層2のVPNs2006年9月のためのアンデションとローゼン情報[1ページ]のRFC4664Framework
Table of Contents
目次
1. Introduction ....................................................3
1.1. Conventions Used in This Document ..........................3
1.2. Objectives and Scope of the Document .......................3
1.3. Layer 2 Virtual Private Networks ...........................3
1.4. Terminology ................................................4
2. Models ..........................................................5
2.1. Reference Model for VPWS ...................................5
2.1.1. Entities in the VPWS Reference Model ................5
2.2. Reference Model for VPLS ...................................6
2.2.1. Entities in the VPLS Reference Model ................8
2.3. Reference Model for Distributed VPLS-PE or VPWS-PE .........9
2.3.1. Entities in the Distributed PE Reference Models .....9
2.4. VPWS-PE and VPLS-PE ........................................9
3. Functional Components of L2 VPN .................................9
3.1. Types of L2VPN ............................................10
3.1.1. Virtual Private Wire Service (VPWS) ................10
3.1.2. Virtual Private LAN Service (VPLS) .................10
3.1.3. IP-Only LAN-Like Service (IPLS) ....................11
3.2. Generic L2VPN Transport Functional Components .............11
3.2.1. Attachment Circuits ................................11
3.2.2. Pseudowires ........................................12
3.2.3. Forwarders .........................................14
3.2.4. Tunnels ............................................15
3.2.5. Encapsulation ......................................16
3.2.6. Pseudowire Signaling ...............................16
3.2.6.1. Point-to-Point Signaling ..................18
3.2.6.2. Point-to-Multipoint Signaling .............18
3.2.6.3. Inter-AS Considerations ...................19
3.2.7. Service Quality ....................................20
3.2.7.1. Quality of Service (QoS) ..................20
3.2.7.2. Resiliency ................................21
3.2.8. Management .........................................22
3.3. VPWS ......................................................22
3.3.1. Provisioning and Auto-Discovery ....................23
3.3.1.1. Attachment Circuit Provisioning ...........23
3.3.1.2. PW Provisioning for Arbitrary
Overlay Topologies ........................23
3.3.1.3. Colored Pools PW Provisioning Model .......25
3.3.2. Requirements on Auto-Discovery Procedures ..........27
3.3.3. Heterogeneous Pseudowires ..........................28
3.4. VPLS Emulated LANs ........................................29
3.4.1. VPLS Overlay Topologies and Forwarding .............31
3.4.2. Provisioning and Auto-Discovery ....................33
3.4.3. Distributed PE .....................................33
3.4.4. Scaling Issues in VPLS Deployment ..................36
3.5. IP-Only LAN-Like Service (IPLS) ...........................36
1. 序論…3 1.1. このドキュメントで中古のコンベンション…3 1.2. ドキュメントの目的と範囲…3 1.3. 2つの仮想私設網を層にしてください…3 1.4. 用語…4 2. モデル…5 2.1. VPWSの参照モデル…5 2.1.1. VPWS参照における実体はモデル化されます…5 2.2. VPLSの参照モデル…6 2.2.1. VPLS参照における実体はモデル化されます…8 2.3. 分配されたVPLS-PEかVPWS-PEの参照モデル…9 2.3.1. 分配されたPE規範モデルの実体…9 2.4. VPWS-PEとVPLS-PE…9 3. L2 VPNの機能部品…9 3.1. L2VPNのタイプ…10 3.1.1. 仮想の個人専用電線サービス(VPWS)…10 3.1.2. 仮想の個人的なLANサービス(VPLS)…10 3.1.3. IPだけのLANのようなサービス(IPLS)…11 3.2. 一般的なL2VPNは機能部品を輸送します…11 3.2.1. 付属サーキット…11 3.2.2. Pseudowires…12 3.2.3. 混載業者…14 3.2.4. Tunnels…15 3.2.5. カプセル化…16 3.2.6. Pseudowireシグナリング…16 3.2.6.1. 二地点間シグナリング…18 3.2.6.2. ポイントツーマルチポイントシグナリング…18 3.2.6.3. 相互、問題…19 3.2.7. 品質を修理してください…20 3.2.7.1. サービスの質(QoS)…20 3.2.7.2. 弾性…21 3.2.8. 管理…22 3.3. VPWS…22 3.3.1. 食糧を供給するのと自動発見…23 3.3.1.1. 付属サーキットの食糧を供給すること…23 3.3.1.2. 任意のオーバレイTopologiesのためのPWの食糧を供給すること…23 3.3.1.3. モデルに食糧を供給するPWにプールを着色します…25 3.3.2. 自動発見手順に関する要件…27 3.3.3. 異種のPseudowires…28 3.4. VPLSはLANを見習いました…29 3.4.1. VPLSはTopologiesと推進をかぶせました…31 3.4.2. 食糧を供給するのと自動発見…33 3.4.3. PEを分配します…33 3.4.4. スケーリングはVPLSで展開を発行します…36 3.5. IPだけのLANのようなサービス(IPLS)…36
Andersson & Rosen Informational [Page 2] RFC 4664 Framework for Layer 2 VPNs September 2006
層2のVPNs2006年9月のためのアンデションとローゼン情報[2ページ]のRFC4664Framework
4. Security Considerations ........................................37
4.1. Provider Network Security Issues ..........................37
4.2. Provider-Customer Network Security Issues .................39
4.3. Customer Network Security Issues ..........................39
5. Acknowledgements ...............................................40
6. Normative References ...........................................41
7. Informative References .........................................41
4. セキュリティ問題…37 4.1. プロバイダーネットワーク安全保障問題…37 4.2. プロバイダー顧客ネットワーク安全保障問題…39 4.3. 顧客ネットワーク安全保障問題…39 5. 承認…40 6. 標準の参照…41 7. 有益な参照…41
1. Introduction
1. 序論
1.1. Conventions Used in This Document
1.1. 本書では使用されるコンベンション
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119].
キーワード“MUST"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTはRFC2119[RFC2119]で説明されるように本書では解釈されることであるべきですか?
1.2. Objectives and Scope of the Document
1.2. ドキュメントの目的と範囲
This document provides a framework for Layer 2 Provider Provisioned Virtual Private Networks (L2VPNs). This framework is intended to aid in standardizing protocols and mechanisms to support interoperable L2VPNs.
このドキュメントはLayer2Provider Provisioned Virtual兵士のNetworks(L2VPNs)に枠組みを供給します。 この枠組みが共同利用できるL2VPNsを支持するためにプロトコルとメカニズムを標準化する際に支援することを意図します。
The term "provider provisioned VPNs" refers to Virtual Private Networks (VPNs) for which the Service Provider (SP) participates in management and provisioning of the VPN.
「プロバイダーはVPNsに食糧を供給した」用語がService Provider(SP)がVPNの管理と食糧を供給することに参加するVirtual兵士のNetworks(VPNs)について言及します。
Requirements for L2VPNs can be found in [RFC4665].
[RFC4665]でL2VPNsのための要件を見つけることができます。
This document provides reference models for L2VPNs and discusses the functional components of L2VPNs. Specifically, this includes discussion of the technical issues that are important in the design of standards and mechanisms for L2VPNs, including those standards and mechanisms needed for interworking and security.
このドキュメントは、規範モデルをL2VPNsに供給して、L2VPNsの機能部品について議論します。 明確に、これはL2VPNsに、規格とメカニズムのデザインで重要な専門的な問題の議論を含んでいます、織り込むのとセキュリティに必要であるそれらの規格とメカニズムを含んでいて。
This document discusses a number of different technical approaches to L2VPNs. It tries to show how the different approaches are related, and to clarify the issues that may lead one to select one approach instead of another. However, this document does not attempt to select any particular approach.
このドキュメントはL2VPNsへの多くの異なった技術的なアプローチについて議論します。 それは、異なるアプローチがどう関係づけられるかを示していて、人が別のものの代わりに1つのアプローチを選択するように導くかもしれない問題をはっきりさせようとします。 しかしながら、このドキュメントは、どんな特定のアプローチも選択するのを試みません。
1.3. Layer 2 Virtual Private Networks
1.3. 層2の仮想私設網
There are two fundamentally different kinds of Layer 2 VPN service that a service provider could offer to a customer: Virtual Private Wire Service (VPWS) and Virtual Private LAN Service (VPLS). There is also the possibility of an IP-only LAN-like Service (IPLS).
サービスプロバイダーが顧客に提供できた基本的に異なった2種類のLayer2VPNサービスがあります: 仮想の個人専用電線サービス(VPWS)と仮想の個人的なLANサービス(VPLS)。 また、IPだけのLANのようなService(IPLS)の可能性があります。
Andersson & Rosen Informational [Page 3] RFC 4664 Framework for Layer 2 VPNs September 2006
層2のVPNs2006年9月のためのアンデションとローゼン情報[3ページ]のRFC4664Framework
A VPWS is a VPN service that supplies an L2 point-to-point service. As this is a point-to-point service, there are very few scaling issues with the service as such. Scaling issues might arise from the number of end-points that can be supported on a particular PE.
VPWSはL2二点間輸送を供給するVPNサービスです。 これが二点間輸送であるので、そういうもののサービスにはほんのわずかなスケーリング問題があります。 スケーリング問題は特定のPEで支持できるエンドポイントの数から起こるかもしれません。
A VPLS is an L2 service that emulates LAN service across a Wide Area Network (WAN). With regard to the amount of state information that must be kept at the edges in order to support the forwarding function, it has the scaling characteristics of a LAN. Other scaling issues might arise from the number of end-points that can be supported on a particular PE. (See Section 3.4.4.)
VPLSはワイドエリアネットワーク(WAN)の向こう側にLANサービスを見習うL2サービスです。 推進機能をサポートするために縁に保たなければならない州の情報の量に関して、それには、LANのスケーリングの特性があります。 他のスケーリング問題は特定のPEで支持できるエンドポイントの数から起こるかもしれません。 (セクション3.4.4を見てください。)
Note that VPLS uses a service that does not have native multicast capability to emulate a service that does have native multicast capability. As a result, there will be scalability issues with regard to the handling of multicast traffic in VPLS.
VPLSがネイティブのマルチキャスト能力を持っているサービスを見習うネイティブのマルチキャスト能力を持っていないサービスを利用することに注意してください。 その結果、マルチキャスト交通の取り扱いに関してスケーラビリティ問題がVPLSにあるでしょう。
A VPLS service may also impose longer delays and provide less reliable transport than would a native LAN service. The standard LAN control protocols may not have been designed for such an environment and may experience scaling problems when run in that environment.
VPLSサービスは、LANがサービスを提供するネイティブを提供するだろうよりまた、より長い遅れを課して、それほど信頼できない輸送を提供するかもしれません。 標準のLAN制御プロトコルは、そのような環境のために設計されていなくて、いつがその環境に立候補するかにおける問題をスケーリングするのを経験するかもしれません。
1.4. Terminology
1.4. 用語
The list of the technical terms used when discussing L2VPNs may be found in the companion document [RFC4026].
L2VPNsについて議論するとき使用される専門用語のリストは仲間ドキュメント[RFC4026]で見つけられるかもしれません。
Andersson & Rosen Informational [Page 4] RFC 4664 Framework for Layer 2 VPNs September 2006
層2のVPNs2006年9月のためのアンデションとローゼン情報[4ページ]のRFC4664Framework
2. Models
2. モデル
2.1. Reference Model for VPWS
2.1. VPWSの規範モデル
The VPWS reference model is shown in Figure 1.
VPWS規範モデルは図1で見せられます。
Attachment PSN Attachment
Circuits tunnel Circuits
+
+-----+ pseudo +-----+
| | wire | |
| CE1 |--+ +--| CE2 |
| | | +-----+ +-----+ +-----+ | | |
+-----+ +----|---- | | P | | ----+----+ +-----+
|VPWS\---|-----|-----|/VPWS|
| PE1 |===|=====|=====| PE2 |
| /|---|-----|-----|\\ |
+-----+ +----|---- | | | | ----|----+ +-----+
| | | +-----+ +-----+ +-----+ | | |
| CE3 |--+ +--| CE4 |
| | | |
+-----+ +-----+
付属PSN Attachment CircuitsトンネルCircuits++-----+ 疑似+-----+ | | ワイヤ| | | CE1|--+ +--| CE2| | | | +-----+ +-----+ +-----+ | | | +-----+ +----|---- | | P| | ----+----+ +-----+ |VPWS\---|-----|-----|/VPWS| | PE1|===|=====|=====| PE2| | /|---|-----|-----|\\ | +-----+ +----|---- | | | | ----|----+ +-----+ | | | +-----+ +-----+ +-----+ | | | | CE3|--+ +--| CE4| | | | | +-----+ +-----+
Figure 1
図1
2.1.1. Entities in the VPWS Reference Model
2.1.1. VPWS規範モデルの実体
The P, PE (VPWS-PE), and CE devices and the PSN tunnel are defined in [RFC4026]. The attachment circuit and pseudowire are discussed in Section 3. The PE does a simple mapping between the PW and attachment circuit based on local information; i.e., the PW demultiplexor and incoming/outgoing logical/physical port.
P、PE(VPWS-PE)、CE装置、およびPSNトンネルは[RFC4026]で定義されます。 セクション3で付属のサーキットとpseudowireについて議論します。 PEはローカルの情報に基づくPWと付属サーキットの間の簡単なマッピングをします。 すなわち、PW demultiplexorと入って来るか出発している論理的であるか物理的なポート。
Andersson & Rosen Informational [Page 5] RFC 4664 Framework for Layer 2 VPNs September 2006
層2のVPNs2006年9月のためのアンデションとローゼン情報[5ページ]のRFC4664Framework
2.2. Reference Model for VPLS
2.2. VPLSの規範モデル
The following diagram shows a VPLS reference model where PE devices that are VPLS-capable provide a logical interconnect such that CE devices belonging to a specific VPLS appear to be on a single bridged Ethernet. A VPLS can contain a single VLAN or multiple tagged VLANs.
以下のダイヤグラムは、VPLSできるPE装置が論理的な内部連絡を提供するので特定のVPLSに属すCE装置がシングルにあるのを現れる規範モデルがイーサネットに橋を架けたのをVPLSに示します。 VPLSは独身のVLANか複数のタグ付けをされたVLANsを含むことができます。
The VPLS reference model is shown in Figures 2 and 3.
VPLS規範モデルは図2と3で見せられます。
+-----+ +-----+
+ CE1 +--+ +---| CE2 |
+-----+ | ................... | +-----+
VPLS A | +----+ +----+ | VPLS A
| |VPLS| |VPLS| |
+--| PE |--Routed---| PE |-+
+----+ Backbone +----+
/ . | . \ _ /\_
+-----+ / . | . \ / \ / \ +-----+
+ CE +--+ . | . +--\ Access \----| CE |
+-----+ . +----+ . | Network | +-----+
VPLS B .....|VPLS|........ \ / VPLS B
| PE | ^ -------
+----+ |
| |
| |
+-----+ |
| CE3 | +-- Emulated LAN
+-----+
VPLS A
+-----+ +-----+ + CE1+--、+ +---| CE2| +-----+ | ................... | +-----+ VPLS A| +----+ +----+ | VPLS A| |VPLS| |VPLS| | +--| PE|--掘ります。---| PE|-+ +----+ 背骨+----+ / . | . \ _ /\_ +-----+ / . | . \ / \ / \ +-----+ +、Ce+--+。| . +--\アクセス\----| Ce| +-----+ . +----+ . | ネットワーク| +-----+ VPLS B…|VPLS|........ \/VPLS B| PE| ^ ------- +----+ | | | | | +-----+ | | CE3| +--見習われたLAN+-----+ VPLS A
Figure 2
図2
Andersson & Rosen Informational [Page 6] RFC 4664 Framework for Layer 2 VPNs September 2006
層2のVPNs2006年9月のためのアンデションとローゼン情報[6ページ]のRFC4664Framework
|-----Routed Backbone-----|
| (P Routers) |PSN Tunnels,
Emulated LAN | |Pseudowires
.......................................................................
. | | .
. |---------------------|----| |--------|-----------------| .
. | --------------------|--- | | -------|---------------- | .
. | VPLS Forwarder | | VPLS Forwarder | .
. | ----------|------------- | | ----------|------------- | .
..|.................................................................|..
| | Emulated LAN | | | Emulated LAN |
| | Interface | VPLS-PEs | | Interface |
| | | <----> | | |
| ----------|------------ | | ----------|------------ |
| | Bridge | | | | Bridge | |
| -|--------|---------|-- | | ---|-------|---------|- |
|--|--------|---------|----| |----|-------|---------|---|
| | | | | |
| | Access | | | Access |
| | Networks| | | Networks|
| | | | | |
| | | | | |
CE devices CE devices
|-----発送された背骨-----| | (Pルータ) |PSNトンネル、見習われたLAN| |Pseudowires… . | | . . |---------------------|----| |--------|-----------------| . . | --------------------|--- | | -------|---------------- | . . | VPLS混載業者| | VPLS混載業者| . . | ----------|------------- | | ----------|------------- | . ..|.................................................................|.. | | 見習われたLAN| | | 見習われたLAN| | | インタフェース| VPLS-PEs| | インタフェース| | | | <、-、-、--、>|、|、|、| ----------|------------ | | ----------|------------ | | | 橋| | | | 橋| | | -|--------|---------|-- | | ---|-------|---------|- | |--|--------|---------|----| |----|-------|---------|---| | | | | | | | | アクセス| | | アクセス| | | ネットワーク| | | ネットワーク| | | | | | | | | | | | | CE装置CE装置
Figure 3
図3
From Figure 3, we see that in VPLS, a CE device attaches, possibly through an access network, to a "bridge" module of a VPLS-PE. Within the VPLS-PE, the bridge module attaches, through an "Emulated LAN Interface", to an Emulated LAN. For each VPLS, there is an Emulated LAN instance. Figure 3 shows some internal structure to the Emulated LAN: it consists of "VPLS Forwarder" modules connected by pseudowires, where the pseudowires may be traveling through PSN tunnels over a routed backbone.
図3から、私たちは、VPLSでは、CE装置が付くのがわかります、ことによるとアクセスネットワークを通して、VPLS-PEの「橋」モジュールに。 VPLS-PEの中では、橋のモジュールは「見習われたLANインタフェース」を通してEmulated LANに付きます。 各VPLSのために、Emulated LAN例があります。 図3は何らかの内部の構造をEmulated LANに示しています: それはpseudowiresによって接続された「VPLS混載業者」モジュールから成ります。そこでは、pseudowiresが発送された背骨の上のPSNトンネルを通って移動しているかもしれません。
A "VPLS instance" consists of a set of VPLS Forwarders (no more than one per PE) connected by pseudowires.
「VPLS例」はpseudowiresによって接続されたVPLS Forwarders(1PEあたり1つ未満)の1セットから成ります。
The functionality that the bridge module must support depends on the service that is being offered by the SP to its customers, as well as on various details of the SP's network. At a minimum, the bridge module must be able to learn MAC addresses, and to "age them out", in the standard manner. However, if the PE devices have backdoor connections with each other via a Layer 2 network, they may need to be full IEEE bridges ([IEEE8021D]), running a spanning tree with each other. Specification of the precise functionality that the bridge
橋のモジュールが支持しなければならない機能性はSPによって顧客に提供されているサービスと、そして、SPのネットワークの様々な細部に依存します。 最小限では、MACアドレスを学んで、橋のモジュールは「外でそれらの年をとることができなければなりません」、標準の方法で。 しかしながら、Layer2ネットワークを通してPE装置に互いとの裏口の接続があるなら、彼らは、完全なIEEE橋([IEEE8021D])である必要があるかもしれません、互いと共にスパニングツリーを走らせて。 正確な機能性の仕様、それ、橋
Andersson & Rosen Informational [Page 7] RFC 4664 Framework for Layer 2 VPNs September 2006
層2のVPNs2006年9月のためのアンデションとローゼン情報[7ページ]のRFC4664Framework
modules must have in particular circumstances is, however, out of scope of the current document.
しかしながら、現在のドキュメントの範囲の外に必須が特定の事情に持っているモジュールがあります。
This framework specifies that each "bridge module" have a single "Emulated LAN interface". It does not specify the number of bridge modules that a VPLS-PE may contain, nor does it specify the number of VPLS instances that may attach to a bridge module over a single "Emulated LAN interface".
この枠組みは、各「橋のモジュール」には単一の「見習われたLANインタフェース」があると指定します。 それはVPLS-PEが含むかもしれない橋のモジュールの数を指定しません、そして、単一の「見習われたLANインタフェース」の上の橋のモジュールに付くかもしれないVPLS例の数を指定しません。
Thus the framework is compatible with at least the following three models:
したがって、枠組みは少なくとも3がモデル化する以下と互換性があります:
- Model 1
- モデル1
A VPLS-PE contains a single bridge module and supports a single
VPLS instance. The VPLS instance is an Emulated LAN; if that
Emulated LAN contains VLANs, 802.1Q [IEEE8021Q] tagging must be
used to indicate which packets are in which VLANs.
VPLS-PEはただ一つの橋のモジュールを含んでいて、ただ一つのVPLS例を支持します。 VPLS例はEmulated LANです。 そのEmulated LANがVLANsを含んでいるなら、どのパケットがどのVLANsであるかを示すのに802.1Q[IEEE8021Q]タグ付けを使用しなければなりません。
- Model 2
- モデル2
A VPLS-PE contains a single bridge module, but supports multiple
VPLS instances. Each VPLS instance is thought of as a VLAN (in
effect, an "Emulated VLAN"), and the set of VPLS instances are
treated as a set of VLANs on a common LAN. Since each VLAN uses
a separate set of PWs, there is no need for 802.1Q tagging.
VPLS-PEはただ一つの橋のモジュールを含んでいますが、複数のVPLS例を支持します。 それぞれのVPLS例はVLAN(事実上、「見習われたVLAN」)、およびVPLS例のセットとして一般的なLANでVLANsの1セットとして扱われた状態で考えられます。 各VLANがPWsの別々のセットを使用するので、802.1Qタグ付けの必要は全くありません。
- Model 3
- モデル3
A VPLS-PE contains an arbitrary number of bridge modules, each
of which attaches to a single VPLS instance.
VPLS-PEは橋のモジュールの特殊活字の数字を含んでいます。それはそれぞれただ一つのVPLS例に付きます。
There may be other models as well, some of which are
combinations of the 3 models above. Different models may have
different characteristics, and different scopes of
applicability.
健康な他の同じくらいモデルが上にあるかもしれません。その何かが3つのモデルの組み合わせです。 異なったモデルは異なった特性、および適用性の異なった範囲を持っているかもしれません。
Each VPLS solution should specify the model or models that it is
supporting. Each solution should also specify the necessary
bridge functionality that its bridge modules must support.
それぞれのVPLS解決策はそれがサポートしているモデルかモデルを指定するべきです。 また、各解決策は橋のモジュールが支持しなければならない必要な橋の機能性を指定するべきです。
This framework does not specify the way in which bridge control
protocols are used on the Emulated LANs.
この枠組みは橋の制御プロトコルがEmulated LANで使用される方法を指定しません。
2.2.1. Entities in the VPLS Reference Model
2.2.1. VPLS規範モデルの実体
The PE (VPLS-PE) and CE devices are defined in [RFC4026].
PE(VPLS-PE)とCE装置は[RFC4026]で定義されます。
Andersson & Rosen Informational [Page 8] RFC 4664 Framework for Layer 2 VPNs September 2006
層2のVPNs2006年9月のためのアンデションとローゼン情報[8ページ]のRFC4664Framework
2.3. Reference Model for Distributed VPLS-PE or VPWS-PE
2.3. 分配されたVPLS-PEかVPWS-PEの規範モデル
VPLS-PE/VPWS-PE
Functionality . . . . . . .
. . . . . . . . . . . . .
. . . .
+----+ . +----+ +----+ . . Service .
| CE |--.--|U-PE|----|N-PE|-.---. Provider .
+----+ . +----+ +----+ . . Backbone .
. . . . . . . . . . . . .
VPLS-PE/VPWS-PEの機能性… +----+ . +----+ +----+ サービス。| Ce|--.--|U-PE|----|N-PE|-.---. プロバイダー+----+ . +----+ +----+ 背骨…………。
2.3.1. Entities in the Distributed PE Reference Models
2.3.1. 分配されたPE規範モデルの実体
A VPLS-PE or a VPWS-PE functionality may be distributed to more than one device. The device closer to the customer/user is called the User-facing PE (U-PE), and the device closer to the core network is called Network-facing PE (N-PE).
VPLS-PEかVPWS-PEの機能性が1台以上の装置に分配されるかもしれません。 装置、顧客/ユーザにより近いのは、コアネットワークの、より近くにUserに面しているPE(U-PE)、および装置と呼ばれているのが、呼ばれたNetworkに面しているPE(N-PE)であるということです。
For further discussion, see Section 3.4.3.
さらなる議論に関しては、セクション3.4.3を見てください。
The terms "U-PE" and "N-PE" are defined in [RFC4026].
用語の"U-PE"と"N-PE"は[RFC4026]で定義されます。
2.4. VPWS-PE and VPLS-PE
2.4. VPWS-PEとVPLS-PE
The VPWS-PE and VPLS-PE are functionally very similar, in that they both use forwarders to map attachment circuits to pseudowires. The only difference is that while the forwarder in a VPWS-PE does a one- to-one mapping between the attachment circuit and pseudowire, the forwarder in a VPLS-PE is a Virtual Switching Instance (VSI) that maps multiple attachment circuits to multiple pseudowires (for further discussion, see Section 3).
VPWS-PEとVPLS-PEはそれらの両方が付属サーキットをpseudowiresに写像するのに混載業者を使用するという点において非常に機能上同様です。 唯一の違いはVPWS-PEの混載業者が-1つへの付属のサーキットとpseudowireの間の1つのマッピングをしますが、VPLS-PEの混載業者が複数の付属サーキットを複数のpseudowiresに写像するVirtual Switching Instance(VSI)(さらなる議論に関して、セクション3を見る)であるということです。
3. Functional Components of L2 VPN
3. L2 VPNの機能部品
This section specifies a functional model for L2VPN, which allows one to break an L2VPN architecture down into its functional components. This exhibits the roles played by the various protocols and mechanisms, and thus makes it easier to understand the differences and similarities between various proposed L2VPN architectures.
このセクションはL2VPNに機能論的モデルを指定します。(L2VPNは、L2VPN構造に機能部品に分解するために1つを許容します)。 これで、様々なプロトコルとメカニズムによって果たされた役割を示して、その結果、違いと類似性を理解しているのは様々な提案されたL2VPN構造の間で、より簡単になります。
Section 3.1 contains an overview of some different types of L2VPNs. In Section 3.2, functional components that are common to the different types are discussed. Then, there is a section for each of the L2VPN service types being considered. The latter sections discuss functional components, which may be specific to particular L2VPN types, and type-specific features of the generic components.
セクション3.1はL2VPNsの何人かの異なったタイプの概観を含みます。 セクション3.2では、異なったタイプに、一般的な機能部品について議論します。 そして、考えられて、L2VPNサービスタイプ各人のためのセクションがあります。 後者のセクションは機能部品、および一般的なコンポーネントのタイプ特有の特徴について論じます。(特定のL2VPNタイプに、機能部品は特定であるかもしれません)。
Andersson & Rosen Informational [Page 9] RFC 4664 Framework for Layer 2 VPNs September 2006
層2のVPNs2006年9月のためのアンデションとローゼン情報[9ページ]のRFC4664Framework
3.1. Types of L2VPN
3.1. L2VPNのタイプ
The types of L2VPN are distinguished by the characteristics of the service that they offer to the customers of the Service Provider (SP).
L2VPNのタイプはそれらがService Provider(SP)の顧客に提供するサービスの特性によって区別されます。
3.1.1. Virtual Private Wire Service (VPWS)
3.1.1. 仮想の個人専用電線サービス(VPWS)
In a VPWS, each CE device is presented with a set of point-to-point virtual circuits.
VPWSでは、1セットの二地点間仮想のサーキットをそれぞれのCE装置に与えます。
The other end of each virtual circuit is another CE device. Frames transmitted by a CE on such a virtual circuit are received by the CE device at the other end-point of the virtual circuit. Forwarding from one CE device to another is not affected by the content of the frame, but is fully determined by the virtual circuit on which the frame is transmitted. The PE thus acts as a virtual circuit switch.
それぞれの仮想のサーキットのもう一方の端は別のCE装置です。 CE装置は仮想のサーキットのもう片方のエンドポイントでそのような仮想のサーキットの上のCEによって伝えられたフレームを受け取ります。 1台のCE装置から別の装置までの推進は、フレームの内容で影響を受けませんが、フレームが伝えられる仮想のサーキットのそばで完全に決定しています。 その結果、PEは仮想の回線交換機として機能します。
This type of L2VPN has long been available over ATM and Frame Relay backbones. Providing this type of L2VPN over MPLS and/or IP backbones is the current topic.
L2VPNのこのタイプは長い間、ATMとFrame Relay背骨の上に手があいています。 MPLS、そして/または、IP背骨の上にL2VPNのこのタイプを提供するのは、現在の話題です。
Requirements for this type of L2VPN are specified in [RFC4665].
L2VPNのこのタイプのための要件は[RFC4665]で指定されます。
3.1.2. Virtual Private LAN Service (VPLS)
3.1.2. 仮想の個人的なLANサービス(VPLS)
In a VPLS, each CE device has one or more LAN interfaces that lead to a "virtual backbone".
VPLSでは、それぞれのCE装置は「仮想の背骨」に通じる1つ以上のLANインタフェースを持っています。
Two CEs are connected to the same virtual backbone if and only if they are members of the same VPLS instance (i.e., same VPN). When a CE transmits a frame, the PE that receives it examines the MAC Destination Address field in order to determine how to forward the frame. Thus, the PE functions as a bridge. As Figure 3 indicates, if a set of PEs support a common VPLS instance, then there is an Emulated LAN, corresponding to that VPLS instance, to which each of those PE bridges attaches (via an emulated interface). From the perspective of a CE device, the virtual backbone is the set of PE bridges and the Emulated LAN on which they reside. Thus to a CE device, the LAN that attaches it to the PE is extended transparently over the routed MPLS and/or IP backbone.
2CEsが同じ仮想の背骨に接続される、彼らである場合にだけ、同じVPLS例(すなわち、同じVPN)のメンバーはそうです。 CEがフレームを伝えるとき、それを受けるPEは、フレームを進める方法を決定するためにMAC Destination Address分野を調べます。 したがって、PEは橋として機能します。 図3が、PEsの1セットであるなら一般的なVPLS例を支持するように示すとき、次に、Emulated LANがあります、そのVPLS例に対応しています。(それぞれのそれらのPE橋はそれに付きます(見習われたインタフェースを通して))。 CE装置の見解から、仮想の背骨はそれらが住んでいるPE橋とEmulated LANのセットです。 したがって、CE装置に、それをPEに付けるLANは発送されたMPLS、そして/または、IP背骨の上で透明に広げられます。
The PE bridge function treats the Emulated LAN as it would any other LAN to which it has an interface. Forwarding decisions are made in the manner that is normal for bridges, which is based on MAC Source Address learning.
インタフェースを持っているいかなる他のLANも扱うようにPE架橋機能はEmulated LANを扱います。 橋へのMAC Source Address学習に基づいている標準である方法で推進決定をします。
Andersson & Rosen Informational [Page 10] RFC 4664 Framework for Layer 2 VPNs September 2006
層2のVPNs2006年9月のためのアンデションとローゼン情報[10ページ]のRFC4664Framework
VPLS is like VPWS in that forwarding is done without any consideration of the Layer3 header. VPLS is unlike VPWS in that:
VPLSは、Layer3ヘッダーの少しも考慮なしで推進するので、VPWSに似ています。 VPLSはそれのVPWSと異なっています:
- VPLS allows the PE to use addressing information in a frame's L2
header to determine how to forward the frame; and
- VPLSはPEにフレームを進める方法を決定するのにフレームのL2ヘッダーでアドレス指定情報を使用させます。 そして
- VPLS allows a single CE/PE connection to be used for
transmitting frames to multiple remote CEs; in this particular
respect, VPLS resembles L3VPN more than VPWS.
- VPLSは、単独のCE/PE接続が複数のリモートCEsにフレームを伝えるのに使用されるのを許容します。 この特別の点で、VPLSはVPWSよりL3VPNに類似しています。
Requirements for this type of L2VPN are specified in [RFC4665].
L2VPNのこのタイプのための要件は[RFC4665]で指定されます。
3.1.3. IP-Only LAN-Like Service (IPLS)
3.1.3. IPだけのLANのようなサービス(IPLS)
An IPLS is very like a VPLS, except that:
IPLSはそれを除いたVPLSのようにまさしくそのです:
- it is assumed that the CE devices are hosts or routers, not
switches; and
- CE装置が切り替わるのではなく、ホストかルータであると思われます。 そして
- it is assumed that the service will only carry IP packets and
supporting packets such as ICMP and ARP (in the case of IPv4) or
Neighbor Discovery (in the case of IPv6); Layer 2 packets that
do not contain IP are not supported.
- サービスがIPパケットとICMPやARPなどのパケットを支持するか(IPv4の場合で)、Neighborディスカバリー(IPv6の場合における)を運ぶだけであると思われます。 IPを含まない層2のパケットが支持されません。
While this service is a functional subset of the VPLS service, it is considered separately because it may be possible to provide it using different mechanisms, which may allow it to run on certain hardware platforms that cannot support the full VPLS functionality.
このサービスが機能的なVPLSサービスの部分集合である間、それを提供するのが可能であるかもしれないので、それは別々に異なったメカニズム(それは完全なVPLSの機能性を支持できないある一定のハードウェアプラットホームで走ることができるかもしれない)を使用することで考えられます。
3.2. Generic L2VPN Transport Functional Components
3.2. 一般的なL2VPN輸送機能部品
All L2VPN types must transport "frames" across the core network connecting the PEs. In all L2VPN types, a PE (PE1) receives a frame from a CE (CE1), and then transports the frame to a PE (PE2), which then transports the frame to a CE (CE2). In this section, we discuss the functional components that are necessary to transport L2 frames in any type of L2VPN service.
すべてのL2VPNタイプがPEsを接続するコアネットワークの向こう側に「フレーム」を輸送しなければなりません。 全部で、L2VPNがタイプして、PE(PE1)はCE(CE1)からフレームを受けて、次に、PE(PE2)にフレームを輸送します。(次に、PEはCE(CE2)にフレームを輸送します)。 このセクションで、私たちはどんなタイプのL2VPNサービスでもL2フレームを輸送するのに必要な機能部品について議論します。
3.2.1. Attachment Circuits
3.2.1. 付属サーキット
In any type of L2VPN, a CE device attaches to a PE device via some sort of circuit or virtual circuit. We will call this an "Attachment Circuit" (AC). We use this term very generally; an Attachment Circuit may be a Frame Relay DLCI, an ATM VPI/VCI, an Ethernet port, a VLAN, a PPP connection on a physical interface, a PPP session from
L2VPNのどんなタイプでも、CE装置はある種のサーキットか仮想のサーキットを通してPE装置に付きます。 私たちは、この「付属サーキット」を(西暦)と呼ぶつもりです。 非常に一般に、私たちは今期を使用します。 Attachment CircuitはFrame Relay DLCIであるかもしれません、ATM VPI/VCI、イーサネットポート、VLAN、物理インターフェースにおけるPPP接続、PPPセッション
Andersson & Rosen Informational [Page 11] RFC 4664 Framework for Layer 2 VPNs September 2006
層2のVPNs2006年9月のためのアンデションとローゼン情報[11ページ]のRFC4664Framework
an L2TP tunnel, an MPLS LSP, etc. The CE device may be a router, a switch, a host, or just about anything, which the customer needs hooked up to the VPN. An AC carries a frame between CE and PE, or vice versa.
L2TPトンネル、MPLS LSPなど CE装置は、ルータ、スイッチ、ホスト、またはほとんど何かであるかもしれません(顧客の要望がVPNに接続したもの)。 西暦はCEとPEの間までフレームを運ぶか、逆もまた同様です。
Procedures for setting up and maintaining the ACs are out of scope of this architecture.
この構造の範囲の外にACsをセットアップして、維持するための手順があります。
These procedures are generally specified as part of the specification of the particular Attachment Circuit technology.
一般に、これらの手順は特定のAttachment Circuit技術の仕様の一部として指定されます。
Any given frame will traverse an AC from a CE to a PE, and then on another AC from a PE to a CE.
どんな与えられたフレームもCEからPEまでそして、別のPEからCEまでの西暦の上で西暦を横断するでしょう。
We refer to the former AC as the frame's "ingress AC" and to the latter AC as the frame's "egress AC". Note that this notion of "ingress AC" and "egress AC" is relative to a specific frame and denotes nothing more than the frame's direction of travel while it is on that AC.
私たちはフレームの「出口西暦」としてフレームの「イングレス西暦」と、そして、後者の西暦に前の西暦について言及します。 「イングレス西暦」と「出口西暦」のこの概念が特定のフレームに比例していて、それがその西暦にありますが、ただフレームの進む方向を指示することに注意してください。
3.2.2. Pseudowires
3.2.2. Pseudowires
A "Pseudowire" (PW) is a relation between two PE devices. Whereas an AC is used to carry a frame from CE to PE, a PW is used to carry a frame between two PEs. We use the term "pseudowire" in the sense of [RFC3985].
"Pseudowire"(PW)は2台のPE装置の関係です。 西暦はCEからPEまでフレームを運ぶのに使用されますが、PWは、2PEsの間までフレームを運ぶのに使用されます。 私たちは[RFC3985]の意味で"pseudowire"という用語を使用します。
Setting up and maintaining the PWs is the job of the PEs. State information for a particular PW is maintained at the two PEs that are its endpoints, but not at other PEs, and not in the backbone routers (P routers).
PWsをセットアップして、維持するのは、PEsの仕事です。 特定のPWのための州の情報は終点ですが、背骨ルータ(Pルータ)が終点であるというわけではないのではなく他のPEsで終点であるというわけではない2PEsで保守されます。
Pseudowires may be point-to-point, multipoint-to-point, or point-to- multipoint. In this framework, point-to-point PWs are always considered bidirectional; multipoint-to-point and point-to-multipoint PWs are always considered unidirectional. Multipoint-to-point PWs can be used only when the PE receiving a frame does not need to infer, from the PW on which the frame was received, the identity of the frame's ingress AC. Point-to-multipoint PWs may be useful when frames need to be multicast.
Pseudowiresはポイントツーポイント、多点からポイント、またはポイントから多点であるかもしれません。 この枠組みでは、ポイントツーポイントPWsは双方向であるといつも考えられます。 多点からポイントとポイントツーマルチポイントPWsはいつも考えられた単方向です。 フレームを受けるPEがフレームが受け取られたPWからフレームのイングレス西暦のアイデンティティを推論する必要はないときだけ、多点からポイントへのPWsを使用できます。 フレームが、マルチキャストである必要があるとき、ポイントツーマルチポイントPWsは役に立つかもしれません。
Procedures for setting up and maintaining point-to-multipoint PWs are not considered in this version of this framework.
ポイントツーマルチポイントPWsをセットアップして、維持するための手順はこの枠組みのこのバージョンで考えられません。
Any given frame travels first on its ingress AC, then on a PW, and then on its egress AC.
どんな与えられたフレームも最初に、イングレス西暦の上と、そして、そして、PWの上と、そして、そして、その出口西暦の上を移動します。
Andersson & Rosen Informational [Page 12] RFC 4664 Framework for Layer 2 VPNs September 2006
層2のVPNs2006年9月のためのアンデションとローゼン情報[12ページ]のRFC4664Framework
Multicast frames may be replicated by a PE, so of course the information carried in multicast frames may travel on more than one PW and more than one egress AC.
マルチキャストフレームはPE、それほどもちろんマルチキャストフレームで運ばれた情報が1以上を移動できるようにPW、および出口西暦1以上年模写されるかもしれません。
Thus with respect to a given frame, a PW may be said to associate a number of ACs. If these ACs are of the same technology (e.g., both ATM, both Ethernet, both Frame Relay), the PW is said to provide "homogeneous transport"; otherwise it is said to provide "heterogeneous transport". Heterogeneous transport requires that some sort of interworking function be applied. There are at least three different approaches to interworking:
したがって、与えられたフレームに関して、PWは多くのACsを関連づけると言われているかもしれません。 これらのACsが同じ技術のものである、(例えば、ATM、両方のイーサネットの両方、両方、Frame Relay)、PWは「均質の輸送」を提供すると言われています。 そうでなく、それは「異種の輸送」を提供すると言われています。 異種の輸送は、機能をある種織り込むのが適用されるのを必要とします。 以下を織り込むことへの少なくとも3つの異なるアプローチがあります。
1. One of the CEs may perform the interworking locally. For
example, if CE1 attaches to PE1 via ATM, but CE2 attaches to
PE2 via Ethernet, then CE1 may decide to send/receive
Ethernet frames over ATM, using the RFC 2684, "LLC
Encapsulation for Bridged Protocols". In such a case, PE1
would need to know that it is to terminate the ATM VC
locally, and only to send/receive Ethernet frames over the
PW.
1. CEsの1つは局所的に織り込むことを実行するかもしれません。 例えば、CE1がATMを通してPE1に付きますが、CE2がイーサネットでPE2に付くなら、CE1は、イーサネットフレームをATMの上に送るか、または受け取ると決めるかもしれません、RFC2684、「橋を架けられたプロトコルのためのLLCカプセル化」を使用して。 このような場合には、PE1は単にイーサネットフレームをPWの上に局所的にATM VCを終えることになっているのを知って、送るか、または受け取る必要があるでしょう。
2. One of the PEs may perform the interworking. For example, if
CE1 attaches to PE1 via ATM, but CE2 attaches to PE2 via
Frame Relay, PE1 may provide the "ATM/FR Service
Interworking" function. This would be transparent to the
CEs, and the PW would carry only Frame Relay frames.
2. PEsの1つは織り込むことを実行するかもしれません。 例えば、CE1がATMを通してPE1に付きますが、CE2がFrame Relayを通してPE2に付くなら、PE1は「気圧/FRサービスの織り込む」機能を提供するかもしれません。 これはCEsに透明でしょう、そして、PWはFrame Relayフレームだけを運ぶでしょう。
3. IPLS could be used. In this case, the "frames" carried by
the PW are IP datagrams, and the two PEs need to cooperate in
order to spoof various L2-specific procedures used by IP (see
Section 3.5).
3. IPLSを使用できました。 この場合、PWによって運ばれた「フレーム」はIPデータグラムです、そして、2PEsがIPによって用いられた様々なL2特有の手順をだますために協力する必要があります(セクション3.5を見てください)。
If heterogeneous PWs are used, the setup protocol must ensure that each endpoint knows the MTU of the remote AC. If the two ACs do not have the same MTU, one of the following three procedures must be carried out:
異種のPWsが使用されているなら、セットアッププロトコルは、各終点がリモート西暦についてMTUを知っているのを確実にしなければなりません。 2ACsに同じMTUがないなら、以下の3つの手順の1つを行わなければなりません:
- The PW is not allowed to come up.
- PWは来ることができません。
- The endpoint at the AC with the larger MTU must reduce the AC's
MTU so that it is the same as the MTU of the remote AC.
- より大きいMTUがある西暦の終点が西暦のMTUを減少させなければならないので、それはリモート西暦のMTUと同じです。
- The two endpoints must agree to use a specified
fragmentation/reassembly procedure.
- 2つの終点が、指定された断片化/再アセンブリ手順を用いるのに同意しなければなりません。
Andersson & Rosen Informational [Page 13] RFC 4664 Framework for Layer 2 VPNs September 2006
層2のVPNs2006年9月のためのアンデションとローゼン情報[13ページ]のRFC4664Framework
3.2.3. Forwarders
3.2.3. 混載業者
In all types of L2VPN, a PE (say, PE1) receives a frame over an AC and forwards it over a PW to another PE (say, PE2). PE2 then forwards the frame out on another AC.
L2VPNのすべてのタイプで、PE(たとえば、PE1)は西暦の上にフレームを受けて、別のPE(たとえば、PE2)へのPWの上にそれを送ります。 そして、PE2は別の西暦の外にフレームを送ります。
The case in which PE1 and PE2 are the same device is an important case to handle correctly, in order to provide the L2VPN service properly. However, as this case does not require any protocol, we do not address it further in this document.
PE1とPE2が同じ装置である場合は正しく扱う重要な例です、適切にL2VPNサービスを提供するために。 しかしながら、本件がどんなプロトコルも必要としないとき、私たちはさらに本書ではそれを記述しません。
When PE1 receives a frame on a particular AC, it must determine the PW on which the frame must be forwarded. In general, this is done by considering:
PE1が特定の西暦でフレームを受けるとき、それはフレームを進めなければならないPWを決定しなければなりません。 一般に、考えることによって、これをします:
- the incoming AC;
- 入って来る西暦。
- possibly the contents of the frame's Layer2 header; and
- ことによるとフレームのLayer2ヘッダーのコンテンツ。 そして
- possibly some forwarding information that may be statically or
dynamically maintained.
- 静的かダイナミックに保守されるかもしれないことによると何らかの推進情報。
If dynamic or static forwarding information is considered, the information is specific to a particular L2VPN instance (i.e., to a particular VPN).
ダイナミックであるか静的な推進情報が考えられるなら、情報は特定のL2VPN例(すなわち、特定のVPNへの)に特定です。
Similarly, when PE2 receives a frame on a particular PW, it must determine the AC on which the frame must be forwarded. This is done by considering:
PE2が特定のPWでフレームを受けるとき、同様に、それはフレームを進めなければならない西暦を決定しなければなりません。 考えることによって、これをします:
- the incoming PW;
- 入って来るPW。
- possibly the contents of the frame's Layer2 header; and
- ことによるとフレームのLayer2ヘッダーのコンテンツ。 そして
- possibly some forwarding information that may be statically or
dynamically maintained.
- 静的かダイナミックに保守されるかもしれないことによると何らかの推進情報。
If dynamic or static forwarding information is considered, the information is specific to a particular L2VPN instance (i.e., to a particular VPN).
ダイナミックであるか静的な推進情報が考えられるなら、情報は特定のL2VPN例(すなわち、特定のVPNへの)に特定です。
The procedures used to make the forwarding decision are known as a "forwarder". We may think of a PW as being "bound", at each of its endpoints, to a forwarder. The forwarder in turn "binds" the PWs to ACs. Different types of L2VPN have different types of forwarders.
推進決定をするのに用いられた手順は「混載業者」として知られています。 私たちはそれぞれの終点で「制限される」であるとして混載業者にPWを考えるかもしれません。 混載業者は順番にACsにPWsを「縛ります」。 L2VPNの異なったタイプには、異なったタイプの混載業者がいます。
Andersson & Rosen Informational [Page 14] RFC 4664 Framework for Layer 2 VPNs September 2006
層2のVPNs2006年9月のためのアンデションとローゼン情報[14ページ]のRFC4664Framework
For instance, a forwarder may bind a single AC to a single PW, ignoring all frame contents and using no other forwarding information. Or a forwarder may bind an AC to a set of PWs and ACs, moving individual frames from AC to PW, from a PW to an AC or from AC to AC by comparing information from the frame's Layer2 header to information in a forwarding database. This is discussed in more detail below, as we consider the different L2VPN types.
例えば、混載業者は独身のPWに単一の西暦を縛るかもしれません、すべてのフレームコンテンツを無視して、他の推進情報を全く使用しないで。 または、混載業者は西暦をPWsとACsの1セットまで縛るかもしれません、個々のフレームを西暦からPWへ移して、推進データベースでフレームのLayer2ヘッダーから情報に情報をたとえるのによる西暦か西暦から西暦までのPWから。 私たちが、異なったL2VPNがタイプすると考えるとき、さらに詳細に以下でこれについて議論します。
3.2.4. Tunnels
3.2.4. Tunnels
A PW is carried in a "tunnel" from PE1 to PE2. We assume that an arbitrary number of PWs may be carried in a single tunnel; the only requirement is that the PWs all terminate at PE2.
PWは「トンネル」でPE1からPE2まで運ばれます。 私たちは、PWsの特殊活字の数字が単一のトンネルで運ばれるかもしれないと思います。 唯一の要件はPWsがすべて、PE2で終わるということです。
We do not even require that all the PWs in the tunnel originate at PE1; the tunnels may be multipoint-to-point tunnels. Nor do we require that all PWs between the same pair of PEs travel in the same tunnel. All we require is that when a frame traveling through such a tunnel arrives at PE2, PE2 will be able to associate it with a particular PW.
私たちは、トンネルのすべてのPWsがPE1で由来するのを必要とさえしません。 トンネルは多点からポイントへのトンネルであるかもしれません。 また、私たちは、同じ組のPEsの間のすべてのPWsが同じトンネルを旅行するのを必要としません。 私たちが必要とするすべてはそのようなトンネルを通って移動するフレームがPE2に届くとき、PE2が特定のPWにそれを関連づけることができるということです。
(While one can imagine tunneling techniques that only allow one PW per tunnel, they have evident scalability problems, and we do not consider them further.)
(それらには、人が、1トンネルあたり1PWしか許容しないテクニックにトンネルを堀ると想像できる間、明白なスケーラビリティ問題があって、私たちはさらにそれらを考えません。)
A variety of different tunneling technologies may be used for the PE-PE tunnels. All that is really required is that the tunneling technologies allow the proper demultiplexing of the contained PWs. The tunnels might be MPLS LSPs, L2TP tunnels, IPsec tunnels, MPLS- in-IP tunnels, etc. Generally the tunneling technology will require the use of an encapsulation that contains a demultiplexor field, where the demultiplexor field is used to identify a particular PW. Procedures for setting up and maintaining the tunnels are not within the scope of this framework. (But see Section 3.2.6, "Pseudowire Signaling".)
さまざまな異なったトンネリング技術がPE-PEトンネルに使用されるかもしれません。 本当に必要であるすべてはトンネリング技術が含まれたPWsの適切な逆多重化を許容するということです。 トンネルはMPLS LSPs、L2TPトンネル、IPsecトンネル、IPでMPLSトンネルであるかもしれませんなど。 一般にトンネリング技術は「反-マルチプレクサー」分野が特定のPWを特定するのに使用される「反-マルチプレクサー」分野を含むカプセル化の使用を必要とするでしょう。 この枠組みの範囲の中にトンネルを設立して、維持するための手順がありません。 (しかし、「Pseudowireは合図し」て、セクション3.2.6を見てください。)
If there are multiple tunnels from PE1 to PE2, it may be desirable to assign a particular PE1-PE2 PW to a particular tunnel based on some particular characteristics of the PW and/or the tunnel. For example, perhaps different tunnels are associated with different QoS characteristics, and different PWs require different QoS. Procedures for specifying how to assign PWs to tunnels are out of scope of the current framework.
PE1からPE2まで複数のトンネルがあれば、PW、そして/または、トンネルのいくつかの特定の特性に基づく特定のトンネルに特定のPE1-PE2 PWを割り当てるのは望ましいかもしれません。 例えば、恐らく、異なったトンネルは異なったQoSの特性に関連しています、そして、異なったPWsは異なったQoSを必要とします。 現在の枠組みの範囲の外にPWsをトンネルに割り当てる方法を指定するための手順があります。
Though point-to-point PWs are bidirectional, the tunnels in which they travel need not be either bidirectional or point-to-point. For example, a point-to-point PW may travel within a unidirectional multipoint-to-point MPLS LSP.
ポイントツーポイントPWsは双方向ですが、それらが旅行するトンネルは、双方向である、または二地点間である必要はありません。 例えば、二地点間PWは示す単方向の多点MPLS LSPの中を旅行するかもしれません。
Andersson & Rosen Informational [Page 15] RFC 4664 Framework for Layer 2 VPNs September 2006
層2のVPNs2006年9月のためのアンデションとローゼン情報[15ページ]のRFC4664Framework
3.2.5. Encapsulation
3.2.5. カプセル化
As L2VPN packets are carried in pseudowires, standard pseudowire encapsulation formats and techniques (as specified by the IETF's PWE3 WG) should be used wherever applicable.
L2VPNパケットがpseudowiresで運ばれるとき、標準のpseudowireカプセル化形式とテクニック(IETFのPWE3 WGによって指定されるように)はどこでも、適切であるところで使用されるべきです。
Generally the PW encapsulations will themselves be encapsulated within a tunnel encapsulation, as determined by the specification of the tunneling protocol.
一般にPWカプセル化はトンネルカプセル化の中で同じくらい要約されていて、トンネリングプロトコルの仕様で同じくらい断固とするために自分たちで望んでいます。
It may be necessary to define additional PW encapsulations to cover areas that are of importance for L2VPN, but that may not be within the scope of PWE3. Heterogeneous transport may be an instance of this.
L2VPNのために重要な領域をカバーするために追加PWカプセル化を定義するのが必要であるかもしれませんが、PWE3の範囲の中にそれはいないかもしれません。 異種の輸送はこの例であるかもしれません。
3.2.6. Pseudowire Signaling
3.2.6. Pseudowireシグナリング
Procedures for setting up and maintaining the PWs themselves are within the scope of this framework. This includes procedures for distributing demultiplexor field values, even though the demultiplexor field, strictly speaking, belongs to the tunneling protocol and not to the PW.
この枠組みの範囲の中にPWs自身をセットアップして、維持するための手順があります。 これは「反-マルチプレクサー」分野が厳密に言うとトンネリングプロトコルに属しますが、PWではなく、「反-マルチプレクサー」分野値を分配するための手順を含んでいます。
The signaling for a point-to-point pseudowire must perform the following functions:
二地点間pseudowireのためのシグナリングは以下の機能を実行しなければなりません:
- Distribution of the demultiplexor.
- 「反-マルチプレクサー」の分配。
Since many PWs may be carried in a single tunnel, the tunneling
protocol must assign a demultiplexor value to each PW. These
demultiplexors must be unique with respect to a given tunnel
(or, with some tunneling technologies, unique at the egress PE).
Generally, the PE that is the egress of the tunnel will select
the demultiplexor values and will distribute them to the PE(s)
which is (are) the ingress(es) of the tunnel. This is the
essential part of the PW setup procedure.
多くのPWsが単一のトンネルで運ばれるかもしれないので、トンネリングプロトコルは「反-マルチプレクサー」値を各PWに割り当てなければなりません。 これらの「反-マルチプレクサー」は、与えられたトンネルに関してユニーク、そして、(いくつかのトンネリング技術に出口PEでユニーク。)でなければなりません。 一般に、トンネルの出口であるPEは「反-マルチプレクサー」値を選択して、トンネルの(あります)イングレス(es)であるPE(s)にそれらを分配するでしょう。 これはPWセットアップ手順の不可欠の部分です。
Note that, as is usually the case in tunneling architectures,
the demultiplexor field belongs to the tunneling protocol, not
to the protocol being tunneled. For this reason, the PW setup
protocols may be extensions of the control protocols for setting
up the tunnels.
「反-マルチプレクサー」分野が通常トンネリング構造におけるケースのようにトンネルを堀られるプロトコルではなく、トンネリングプロトコルに属することに注意してください。 この理由で、PWセットアッププロトコルはトンネルを設立するための制御プロトコルの拡大であるかもしれません。
- Selection of the Forwarder at the remote PE.
- リモートPEのForwarderの選択。
The signaling protocol must contain enough information to enable
the remote PE to select the proper forwarder to which the PW is
to be bound. We can call this information the "Remote Forwarder
シグナリングプロトコルはリモートPEがPWが制限されていることになっている適切な混載業者を選ぶのを可能にすることができるくらいの情報を含まなければなりません。 私たちは、この情報を「リモート混載業者」と呼ぶことができます。
Andersson & Rosen Informational [Page 16] RFC 4664 Framework for Layer 2 VPNs September 2006
層2のVPNs2006年9月のためのアンデションとローゼン情報[16ページ]のRFC4664Framework
Selector". The information that is required will depend on the
type of L2VPN being provided and on the provisioning model being
used (see Sections 3.3.1 and 3.4.2). The Remote Forwarder
Selector may uniquely identify a particular Forwarder, or it may
identify an attribute of Forwarders. In the latter case, it
would select whichever Forwarder has been provisioned with that
attribute.
「セレクタ。」 セクション3.3.1と3.4を見てください。必要である情報が提供されるL2VPNのタイプに頼っていて、使用されているので食糧を供給するときにモデル化される、(.2)。 Remote Forwarder Selectorが唯一特定のForwarderを特定するかもしれませんか、またはそれはForwardersの属性を特定するかもしれません。 後者の場合では、それはその属性で食糧を供給されたForwarderを選択するでしょう。
- Supporting pseudowire emulations.
- pseudowire模倣を支持します。
To the extent that a particular PW must emulate the signaling of
a particular Layer2 technology, the PW signaling must provide
the necessary functions.
特定のPWが特定のLayer2技術のシグナリングを見習わなければならないという範囲に、PWシグナリングは必要な機能を提供しなければなりません。
- Distribution of state changes.
- 状態の分配は変化します。
Changes in the state of an AC may need to be reflected in
changes to the state of the PW to which the AC is bound, and
vice versa. The specification as to which changes need to be
reflected in what way would generally be within the province of
the PWE3 WG.
西暦の状態の変化は、西暦が制限されているPWの州への変化に反映される必要があるかもしれません、逆もまた同様に。 一般に、PWE3 WGの州の中に変化がどんな風に反映される必要がある仕様があるでしょう。
- Establishing pseudowire characteristics.
- pseudowireの特性を確立します。
To the extent that one or more characteristics of a PW must be
known to and/or agreed upon by both endpoints, the signaling
must allow for the necessary interaction.
PWの1つ以上の特性は終点に知られている、そして/または、両方が同意していなければならないという範囲まで、シグナリングが必要な相互作用を考慮しなければなりません。
As specified above, signaling for point-to-point PWs must pass enough information to allow a remote PE to properly bind a PW to a Forwarder, and to associate a particular demultiplexor value with that PW. Once the two PEs have done the proper PW/Forwarder bindings, and have agreed on the demultiplexor values, the PW may be considered set up. If it is necessary to negotiate further characteristics or parameters of a particular PW, or to pass status information for a particular PW, the PW may be identified by the demultiplexor value.
上で指定されるように、ポイントツーポイントPWsのために合図するのはリモートPEが適切にForwarderにPWを縛って、特定の「反-マルチプレクサー」値をそのPWに関連づけるのを許容できるくらいの情報を通過しなければなりません。 2PEsがいったん適切なPW/混載業者結合をして、「反-マルチプレクサー」値に同意すると、PWはセットアップされていると考えられるかもしれません。 特定のPWのさらなる特性かパラメタを交渉するか、または特定のPWのための状態情報を通過するのが必要であるなら、PWは「反-マルチプレクサー」値によって特定されるかもしれません。
Signaling procedures for point-to-point pseudowires are most commonly point-to-point procedures that are executed by the two PW endpoints. There are, however, proposals to use point-to-multipoint signaling for setting up point-to-point pseudowires, so this is included in the framework. When PWs are themselves point-to-multipoint, it is also possible to use either point-to-point signaling or point-to- multipoint signaling to set them up. This is discussed in the remainder of this section.
ポイントツーポイントpseudowiresのためのシグナリング手順は最も一般的に2つのPW終点によって実行される二地点間手順です。 しかしながら、ポイントツーポイントpseudowiresをセットアップするのにポイントツーマルチポイントシグナリングを使用するという提案があるので、これは枠組みに含まれています。 また、PWsが自分たちでポイントツーマルチポイントであるときに、それらをセットアップするのに二地点間シグナリングかポイントから多点へのシグナリングのどちらかを使用するのも可能です。 このセクションの残りでこれについて議論します。
Andersson & Rosen Informational [Page 17] RFC 4664 Framework for Layer 2 VPNs September 2006
層2のVPNs2006年9月のためのアンデションとローゼン情報[17ページ]のRFC4664Framework
3.2.6.1. Point-to-Point Signaling
3.2.6.1. 二地点間シグナリング
There are several ways to do the necessary point-to-point signaling. Among them are:
必要な二地点間シグナリングをするいくつかの方法があります。 それらの中に、以下があります。
- LDP
- 自由民主党
LDP [RFC3036] extensions can be defined for pseudowire
signaling. This form of signaling can be used for pseudowires
that are to be carried in MPLS "tunnels", or in MPLS-in-
something-else tunnels.
pseudowireシグナリングのために自由民主党[RFC3036]の拡大を定義できます。 このフォームのシグナリングは-pseudowiresに使用されて、MPLS「トンネル」、または中のMPLSで運ばれるために、他の何かがトンネルを堀るということであるかもしれません。
- L2TP
- L2TP
L2TP [RFC2661] can be used for pseudowire signaling, resulting
in pseudowires that are carried as "sessions" within L2TP
tunnels. Pseudowire-specific extensions to L2TP may also be
needed.
L2TPの中の「セッション」がトンネルを堀るとき運ばれるpseudowiresをもたらして、pseudowireシグナリングに、L2TP[RFC2661]を使用できます。 また、L2TPへのPseudowire特有の拡大が必要であるかもしれません。
Other methods may be possible as well.
また、他の方法は可能であるかもしれません。
It is possible to have one control connection between a pair of PEs, which is used to control many PWs.
1組のPEsの間の1つのコントロール接続があるのは、可能です。PEsは、多くのPWsを制御するのに使用されます。
The use of point-to-point signaling for setting up point-to-point PWs is straightforward. Multipoint-to-point PWs can also be set up by point-to-point signaling, as the remote PEs do not necessarily need to know whether the PWs are multipoint-to-point or point-to-point. In some signaling procedures, the same demultiplexor value may be assigned to all the remote PEs.
ポイントツーポイントPWsをセットアップするために合図するポイントツーポイントの使用は簡単です。 また、二地点間シグナリングで多点からポイントへのPWsをセットアップできます、リモートPEsが、必ずPWsが多点からポイントかそれともポイントツーポイントであるかを知る必要があるというわけではないとき。 いくつかのシグナリング手順で、同じ「反-マルチプレクサー」値はすべてのリモートPEsに割り当てられるかもしれません。
3.2.6.2. Point-to-Multipoint Signaling
3.2.6.2. ポイントツーマルチポイントシグナリング
Consider the following conditions:
以下の条件を考えてください:
- It is necessary to set up a set of PWs, all of which have the
same characteristics.
- それのすべてには同じ特性があるPWsの1セットを設立するのが必要です。
- It is not necessary to use the PW signaling protocol to pass PW
state changes.
- 州の変化をPWに通過するのにPWシグナリングプロトコルを使用するのは必要ではありません。
- For each PW in the set, the same value of the Remote Forwarder
Selector can be used.
- セットにおける各PWのために、Remote Forwarder Selectorの同じ値を使用できます。
Call these the "Environmental Conditions".
「環境条件」にこれらに電話をしてください。
Suppose also that there is some mechanism by which, given a range of demultiplexor values, each of a set of PEs can make a unique and
そしてまた、それぞれのさまざまな「反-マルチプレクサー」値を考えて、PEsの1セットがaをユニークにすることができる何らかのメカニズムがあると仮定してください。
Andersson & Rosen Informational [Page 18] RFC 4664 Framework for Layer 2 VPNs September 2006
層2のVPNs2006年9月のためのアンデションとローゼン情報[18ページ]のRFC4664Framework
deterministic selection of a single value from within that range. Call this the "Demultiplexor Condition". Alternatively, suppose that one is trying to set up a multipoint-to-point PW rather than to set up a point-to-point PW. Call this the "Multipoint Condition".
その範囲からのただ一つの価値の決定論的な選択。 この「Demultiplexor状態」に電話をしてください。 あるいはまた、二地点間PWをセットアップするというよりむしろものが多点からポイントへのPWをセットアップしようとしていると仮定してください。 この「多点状態」に電話をしてください。
If:
:
- The Environmental Conditions hold; and
- Environmental Conditionsは成立します。 そして
- Either
- どちらか
* the Demultiplexor Condition holds, or
* またはDemultiplexor Conditionが成立する。
* the Multipoint Condition holds,
* Multipoint Conditionは成立します。
then for a given set of PWs that terminate at egress PE1, the information that PE1 needs to send to the ingress PE(s) of each pseudowire in the set is exactly the same. All the ingress PE(s) receive the same Forwarder Selector value. They all receive the same set of PW parameters (if any). And either they all receive the same demultiplexor value (if the PW is multipoint-to-point) or they all receive a range of demultiplexor values from which each can choose a unique demultiplexor value for itself.
そして、出口PE1で終わるPWsの与えられたセットにおいて、PE1が、セットにおけるそれぞれのpseudowireのイングレスPE(s)に発信する必要があるという情報はまさに同じです。 すべてのイングレスPE(s)は同じForwarder Selector値を受けます。 彼らは皆、同じセットのPWパラメタ(もしあれば)を受け取ります。 そして、彼らが皆、同じ「反-マルチプレクサー」値を受けるか(PWが多点からポイントであるなら)、または彼らは皆、それ自体のために、それぞれがユニークな「反-マルチプレクサー」値を選ぶことができるさまざまな「反-マルチプレクサー」値を受けます。
Rather than connect to each ingress PE and replicate the same information, it may make sense either to multicast the information, or to send the information once to a "reflector", which will then take responsibility for distributing the information to the other PEs.
むしろ、各イングレスPEに接続して、同じ情報を模写するより情報をマルチキャストに理解できるかもしれませんか、そして、一度「反射鏡」に情報を送るために、どれが他のPEsに情報を分配することへの責任を取るでしょうか?
We refer to this sort of technique as "point-to-multipoint" signaling. It would, for example, be possible to use BGP [RFC1771] to do the signaling, with PEs that are BGP peers not of each other, but of one or more BGP route reflectors [RFC2796].
私たちは「ポイントツーマルチポイント」シグナリングとこの種類のテクニックを呼びます。 例えば、シグナリングをするのに、BGP[RFC1771]を使用するのは可能でしょう、互いではなく、1個以上のBGPルート反射鏡[RFC2796]のBGP同輩であるPEsと共に。
3.2.6.3. Inter-AS Considerations
3.2.6.3. 相互、問題
Pseudowires may need to run from a PE in one Service Provider's network to a PE in another Service Provider's network. This has the following implications:
Pseudowiresは、別のService Providerのネットワークで1Service ProviderのネットワークにおけるPEからPEまで走る必要があるかもしれません。 これには、以下の意味があります:
- The signaling protocol that sets up the PWs must be able to
cross network boundaries. Of course, all IP-based protocols
have this capability.
- PWsをセットアップするシグナリングプロトコルはネットワーク限界に交差できなければなりません。 もちろん、すべてのIPベースのプロトコルには、この能力があります。
- The two PEs at the PW endpoints must be addressable and routable
from each other.
- PW終点の2PEsがアドレス可能であり、互いから発送可能しなければなりません。
Andersson & Rosen Informational [Page 19] RFC 4664 Framework for Layer 2 VPNs September 2006
層2のVPNs2006年9月のためのアンデションとローゼン情報[19ページ]のRFC4664Framework
- The signaling protocol needs to allow each PW endpoint to
authenticate the other. To make use of the authentication
capability, there would also need to be some method of key
distribution that is acceptable to both administrations.
- シグナリングプロトコルは、それぞれのPW終点がもう片方を認証するのを許容する必要があります。 また、認証能力を利用するために、そこでは、両方の政権に許容できる主要な分配の何らかの方法であることが必要でしょう。
3.2.7. Service Quality
3.2.7. サービス品質
Service Quality refers to the ability for the network to deliver a Service level Specification (SLS) for service attributes such as protection, security, and Quality of Service (QoS). The service quality provided depends on the subscriber's requirements and can be characterized by a number of performance metrics.
サービスQualityはネットワークがService(QoS)の保護や、セキュリティや、Qualityなどのサービス属性のために、Serviceの平らなSpecification(SLS)を届ける能力について言及します。 品質が提供したサービスは、加入者の要件によって、多くの性能測定基準で特徴付けることができます。
The necessary Service Quality must be provided on the ACs, as well as on the PWs. Mechanisms for providing Service Quality on the PWs may be PW-specific or tunnel-specific; in the latter case, the assignment of a PW to a tunnel may depend on the Service Quality.
ACsの上と、そして、PWsの上で必要なService Qualityを提供しなければなりません。 PWsの上のService Qualityを提供するためのメカニズムは、PW特有であるか、またはトンネル特有であるかもしれません。 後者の場合では、トンネルへのPWの課題はService Qualityによるかもしれません。
3.2.7.1. Quality of Service (QoS)
3.2.7.1. サービスの質(QoS)
QoS describes the queuing behavior applied to a particular "flow", in order to achieve particular goals of precedence, throughput, delay, jitter, etc.
QoSは特定の「流れ」に適用された列を作りの振舞いについて説明します、先行、スループット、遅れ、ジターなどの特定の目標を達成するために
Based on the customer Service Level Agreement (SLA), traffic from a customer can be prioritized, policed, and shaped for QoS requirements. The queuing and forwarding policies can preserve the packet order and QoS parameters of customer traffic. The class of services can be mapped from information in the customer frames, or it can be independent of the frame content.
顧客サービス・レベル・アグリーメント(SLA)に基づいて、QoS要件のために顧客からの交通を最優先して、取り締まられて、形成できます。 列を作りと推進方針は顧客交通のパケット注文とQoSパラメタを保存できます。 顧客フレームの情報からサービスのクラスを写像できますか、またはそれはフレーム内容から独立している場合があります。
QoS functions can be listed as follows:
以下の通りQoS機能を記載できます:
- Customer Traffic Prioritization: L2VPN services could be best
effort or QoS guaranteed. Traffic from one customer might need
to be prioritized over others when sharing same network
resources. This requires capabilities within the L2VPN solution
to classify and mark priority to QoS guaranteed customer
traffic.
- 顧客交通優先順位づけ: L2VPNサービスがベストエフォート型であるかもしれません、またはQoSは保証されています。 1人の顧客からの交通は、同じネットワーク資源を共有するとき、他のものの上で最優先する必要があるかもしれません。 これは分類するL2VPN解決策の中の能力と顧客交通が保証されたQoSのマーク優先権を必要とします。
- Proper queuing behavior would be needed at the egress AC, and
possibly within the backbone network as well. If queuing
behavior must be controlled within the backbone network, the
control might be based on CoS information in the MPLS or IP
header, or it might be achieved by nesting particular tunnels
within particular traffic engineering tunnels.
- また、適切な列を作りの振舞いが出口西暦においてことによると背骨ネットワークの中で必要でしょう。 列を作るなら背骨ネットワークの中で振舞いを制御しなければならない、コントロールがMPLSかIPヘッダーでCoS情報に基づくかもしれませんか、またはさもなければ、それは、特定の交通工学トンネルの中で特定のトンネルを入れ子にすることによって、達成されるかもしれません。
Andersson & Rosen Informational [Page 20] RFC 4664 Framework for Layer 2 VPNs September 2006
層2のVPNs2006年9月のためのアンデションとローゼン情報[20ページ]のRFC4664Framework
- Policing: This ensures that a user of L2VPN services uses
network resources within the limits of the agreed SLA. Any
excess L2VPN traffic can be rejected or handled differently
based on provider policy.
- 取り締まります: これは、L2VPNサービスのユーザが同意されたSLAの限界の中でネットワーク資源を使用するのを確実にします。 プロバイダー方針に基づいてどんな余分なL2VPN交通も異なって拒絶するか、または扱うことができます。
- Policing would generally be applied at the ingress AC.
- 一般に、取り締まりはイングレス西暦で適用されるでしょう。
- Shaping: Under some cases, the random nature of L2VPN traffic
might lead to sub-optimal utilization of network resources.
Through queuing and forwarding mechanisms, the traffic can be
shaped without altering the packet order.
- 形成します: いくつかの場合の下では、L2VPN交通のランダム性はネットワーク資源のサブ最適の利用につながるかもしれません。 メカニズムを列に並ばせて、進めることで、パケットオーダーを変更しないで、交通を形成できます。
- Shaping would generally be applied at the ingress AC.
- 一般に、形成はイングレス西暦で適用されるでしょう。
3.2.7.2. Resiliency
3.2.7.2. 弾性
Resiliency describes the ability of the L2VPN infrastructure to protect a flow from network outage, so that service remains available in the presence of failures.
弾性はL2VPNインフラストラクチャがネットワーク供給停止からの流れを保護する能力について説明します、サービスが失敗があるとき利用可能なままで残るように。
L2VPN, like any other service, is subject to failures such as link, trunk, and node failures, both in the SP's core network infrastructure and on the ACs.
いかなる他のサービスのようにも、L2VPNはリンクや、トランクや、ノード障害など(SPのコアネットワークインフラとACsの上の両方)の失敗を被りやすいです。
It is desirable that the failure be detected "immediately" and that protection mechanisms allow fast restoration times to make L2VPN service almost transparent to these failures to the extent possible, based on the level of resiliency. Restoration should take place before the CEs can react to the failure. Essential aspects of providing resiliency are:
失敗が「すぐに、」検出されて、保護メカニズムが、回復時間でL2VPNサービスが可能な範囲内でこれらの失敗にほとんど透明になるのを速く許容するのは、望ましいです、弾性のレベルに基づいて。 CEsが失敗に反応できる前に王政復古は行われるべきです。 弾性を提供する不可欠の局面は以下の通りです。
- Link/Node failure detection: Mechanisms within the L2VPN service
should allow for link or node failures that impact the service,
and that should be detected immediately.
- リンク/ノード障害検出: L2VPNサービスの中のメカニズムは、リンクかノード障害によってサービスに影響を与えてください。そうすれば、それがすぐに検出されるべきであるのを許容するはずです。
- Resiliency policy: The way in which a detected failure is
handled will depend on the restoration policy of the SLA
associated with the L2VPN service specification. It may need to
be handled immediately, or it may need to be handled only if no
other critical failure needs protection resources, or it may be
completely ignored if it is within the bounds of the "acceptable
downtime" allowed by the L2VPN service.
- 弾性方針: 検出された失敗が扱われる方法はL2VPNサービス仕様に関連しているSLAの回復方針によるでしょう。 それが、すぐに扱われる必要があるかもしれませんか、他のどんな批判的な失敗も保護リソースを必要としない場合にだけ、扱われるのが必要であるかもしれません、またはL2VPNサービスで許容された「許容できる休止時間」の領域の中にあるなら、それは完全に無視されるかもしれません。
- Restoration Mechanisms: The L2VPN solutions could allow for
physical level protection, logical level protection, or both.
For example, by connecting customers over redundant and
- 王政復古メカニズム: L2VPN解決策は物理的な平らな保護、論理レベル保護、または両方を考慮するかもしれません。 そして例えば余分な上に顧客に接する。
Andersson & Rosen Informational [Page 21] RFC 4664 Framework for Layer 2 VPNs September 2006
層2のVPNs2006年9月のためのアンデションとローゼン情報[21ページ]のRFC4664Framework
physically separate ACs to different provider customer-facing
devices, one AC can be maintained as active, and the other could
be marked as a backup; upon the failure detection across the
primary AC, the backup could become active.
顧客に面する異なったプロバイダー装置への肉体的に別々のACs、アクティブであるとして西暦1年を維持できました、そして、バックアップとしてもう片方をマークできました。 第一の西暦の向こう側の失敗検出のときに、バックアップはアクティブになることができました。
To a great extent, resiliency is a matter of having appropriate failure and recovery mechanisms in the network core, including "ordinary" adaptive routing as well as "fast reroute" capabilities. The ability to support redundant ACs between CEs and PEs also plays a role.
大いに、弾性はネットワークコアに適切な失敗と回収機構を持つ問題です、「普通」の最適経路指定を含んでいて「速くコースを変更してください」は能力です。 また、CEsとPEsの間の余分なACsを支持する能力は役割を果たします。
3.2.8. Management
3.2.8. 管理
An L2VPN solution can provide mechanisms to manage and monitor different L2VPN components. From a Service Level Agreement (SLA) perspective, L2VPN solutions could allow monitoring of L2VPN service characteristics and offer mechanisms used by Service Providers to report such monitored statistical data. Trouble-shooting and verification of operational and maintenance activities of L2VPN services are essential requirements for Service Providers.
L2VPN解決策は、異なったL2VPNの部品を管理して、モニターするためにメカニズムを提供できます。 サービス・レベル・アグリーメント(SLA)見解から、L2VPN解決策で、L2VPNサービスの特性とService Providersによって使用された申し出メカニズムのモニターは、そのようなものが統計データをモニターしたと報告できるかもしれません。 L2VPNサービスの操作上と維持の活動のトラブルシューティングと検証はService Providersのための必須の条件です。
3.3. VPWS
3.3. VPWS
A VPWS is an L2VPN service in which each forwarder binds exactly one AC to exactly one PW. Frames received on the AC are transmitted on the PW; frames received on the PW are transmitted on the AC. The content of a frame's Layer2 header plays no role in the forwarding decision, except insofar as the Layer2 header contents are used to associate the frame with a particular AC (e.g., the DLCI field of a Frame Relay frame identifies the AC).
VPWSは各混載業者がちょうど西暦1年をちょうど1PWまで縛るL2VPNサービスです。 西暦に受け取られたフレームはPWで伝えられます。 PWに受け取られたフレームは西暦で伝えられます。 フレームのLayer2ヘッダーの内容は推進決定における役割を全く果たしません、Layer2ヘッダー含有量が特定の西暦にフレームを関連づけるのに使用される(例えば、Frame RelayフレームのDLCI分野は西暦を特定します)限り。
A particular combination of <AC, PW, AC> forms a "virtual circuit" between two CE devices.
<西暦、PWの特定の組み合わせであり、交流>は2台のCE装置の間の「仮想のサーキット」を形成します。
A particular VPN (VPWS instance) may be thought of as a collection of such virtual circuits, or as an "overlay" of PWs on the MPLS or IP backbone. This creates an overlay topology that is in effect the "virtual backbone" of a particular VPN.
特定のVPN(VPWS例)はそのような仮想のサーキットの収集として、または、MPLSかIP背骨の上のPWsの「オーバレイ」として考えられるかもしれません。 これは事実上特定のVPNの「仮想の背骨」であるオーバレイトポロジーを作成します。
Whether two virtual circuits are said to belong to the same VPN or not is an administrative matter based on the agreements between the SPs and their customers. This may impact the provisioning model (discussed below). It may also affect how particular PWs are assigned to tunnels, the way QoS is assigned to particular ACs and PWs, etc.
2個の仮想のサーキットが同じVPNに属すと言われているかどうかが、SPsと彼らの顧客との協定に基づく管理問題です。 これは食糧を供給しているモデル(以下では、議論する)に影響を与えるかもしれません。 また、それは特定のPWsがどうトンネルに割り当てられるか、そして、QoSが特定のACsに割り当てられる方法とPWsなどに影響するかもしれません。
Note that VPWS makes use of point-to-point PWs exclusively.
VPWSが排他的にポイントツーポイントPWsを利用することに注意してください。
Andersson & Rosen Informational [Page 22] RFC 4664 Framework for Layer 2 VPNs September 2006
層2のVPNs2006年9月のためのアンデションとローゼン情報[22ページ]のRFC4664Framework
3.3.1. Provisioning and Auto-Discovery
3.3.1. 食糧を供給するのと自動発見
Provisioning a VPWS is a matter of:
VPWSに食糧を供給するのは、以下の問題です。
1. Provisioning the ACs;
1. ACsに食糧を供給します。
2. Providing the PEs with the necessary information to enable
them to set up PWs between ACs to result in the desired
overlay topology; and
2. 彼らが必要なオーバレイトポロジーをもたらすためにACsの間のPWsをセットアップするのを可能にするために必要事項をPEsに提供します。 そして
3. Configuring the PWs with any necessary characteristics.
3. どんな必要な特性があるPWsも構成します。
3.3.1.1. Attachment Circuit Provisioning
3.3.1.1. 付属サーキットの食糧を供給すること
In many cases, the ACs must be individually provisioned on the PE and/or CE. This will certainly be the case if the CE/PE attachment technology is a switched network, such as ATM or FR, and the VCs are PVCs rather than SVCs. It is also the case whenever the individual Attachment Circuits need to be given specific parameters (e.g., QoS parameters, guaranteed bandwidth parameters) that differ from circuit to circuit.
多くの場合、PE、そして/または、CEで個別にACsに食糧を供給しなければなりません。 確かに、これはCE/PE付属技術がATMかFRなどの交換網であるならそうになるでしょう、そして、VCsはSVCsよりむしろPVCsです。 また、個々のAttachment Circuitsが、特定のパラメタ(例えば、QoSパラメタ、保証された帯域幅パラメタ)が与えられている必要があるときはいつも、サーキットからサーキットまで異なるのは、ケースです。
There are also cases in which ACs might not have to be individually provisioned. For example, if an AC is just an MPLS LSP running between a CE and a PE, it could be set up as the RESULT of setting up a PW rather than having to be provisioned BEFORE the PW can be set up. The same may apply whenever the AC is a Switched Virtual Circuit of any sort, though in this case, various policy controls might need to be provisioned; e.g., limiting the number of ACs that can be set up between a given CE and a given PE.
個別にACsに食糧を供給する必要はないかもしれない場合もあります。 例えば、西暦がただCEとPEの間を走るMPLS LSPであるなら、それは食糧を供給されるために持っているよりむしろBEFORE PWをPWに設定するRESULTをセットアップできるようにセットアップされるかもしれません。 同じくらいは西暦がどんな種類のSwitched Virtual Circuitであるときはいつも、適用されるかもしれません、様々な方針コントロールが、この場合食糧を供給される必要があるかもしれませんが。 例えば、ACsの数を制限して、与えられたCEと与えられたPEの間でそれをセットアップできます。
Issues such as whether the Attachment Circuits need to be individually provisioned or not, whether they are Switched VCs or Permanent VCs, and what sorts of policy controls may be applied are implementation and deployment issues and are considered to be out of scope of this framework.
Attachment Circuitsが、個別に食糧を供給される必要があるかどうかなどの問題であり、彼らがSwitched VCsかPermanent VCsであり、どんな種類の方針コントロールが適用されるかもしれないかは、実現と展開問題であり、この枠組みの範囲の外にあると考えられます。
3.3.1.2. PW Provisioning for Arbitrary Overlay Topologies
3.3.1.2. 任意のオーバレイのためにTopologiesに食糧を供給するPW
In order to support arbitrary overlay topologies, it is necessary to allow the provisioning of individual PWs. In this model, when a PW is provisioned on a PE device, it is locally bound to a specific AC. It is also provisioned with information that identifies a specific AC at a remote PE.
任意のオーバレイtopologiesを支持するために、個々のPWsの食糧を供給することを許すのが必要です。 PWがPE装置で食糧を供給されるとき、このモデルでは、それは局所的に特定の西暦に縛られます。 また、それはリモートPEで特定の西暦を特定する情報で食糧を供給されます。
Andersson & Rosen Informational [Page 23] RFC 4664 Framework for Layer 2 VPNs September 2006
層2のVPNs2006年9月のためのアンデションとローゼン情報[23ページ]のRFC4664Framework
There are basically two variations of this provisioning model:
基本的に、モデルに食糧を供給するこの2回の変化があります:
- Two-sided provisioning
- 二面の食糧を供給すること
With two-sided provisioning, each PE that is at the end of a PW
is provisioned with the following information:
二面の食糧を供給するaの終わりにある各PEと共にPWは以下の情報で食糧を供給されます:
* Identifier of the Local AC to which the PW is to be bound
* PWによって制限されていることになっているLocal西暦に関する識別子
* PW type and parameters
* PWタイプとパラメタ
* IP address of the remote PE (i.e., the PE that is to be at
the remote end of the PW)
* リモートPEのIPアドレス(すなわち、PWのリモートエンドにはあることになっているPE)
* Identifier that is meaningful to the remote PE, and that can
be passed in the PW signaling protocol to enable the remote
PE to bind the PW to the proper AC. This can be an
identifier of the PW or an identifier of the remote AC. If
a PW identifier is used, it must be unique at each of the
two PEs. If an AC identifier is used, it need only be
unique at the remote PE.
* リモートPEに重要であり、リモートPEが適切な西暦にPWを縛るのを可能にするためにPWシグナリングプロトコルで通過できる識別子。 これは、PWに関する識別子かリモート西暦に関する識別子であるかもしれません。 PW識別子が使用されているなら、それぞれの2PEsでユニークであるに違いありません。 交流識別子が使用されているなら、リモートPEでユニークであるだけでよいです。
This identifier is then used as the Remote Forwarder Selector
when signaling is done (see 3.2.6.1).
見てください。次に、この識別子が合図するとき、Remote Forwarder Selectorをするように使用される、(3.2 .6 .1)。
- Single-sided provisioning
- 片面単密度の食糧を供給すること
With single-sided provisioning, a PE at one end of a PW is
provisioned with the following information:
片面単密度に食糧を供給していて、PWの片端のPEは以下の情報で食糧を供給されます:
* Identifier of the Local AC to which the PW is to be bound
* PWによって制限されていることになっているLocal西暦に関する識別子
* PW type and parameters
* PWタイプとパラメタ
* Globally unique identifier of remote AC
* リモート西暦のグローバルにユニークな識別子
This identifier is then used as the Forwarder Selector when
signaling is done (see section 3.2.6.1).
セクション3.2を見てください。次に、この識別子が合図するとき、Forwarder Selectorをするように使用される、(.6 .1)。
In this provisioning model, the IP address of the remote PE is
not provisioned. Rather, the assumption is that an auto-
discovery scheme will be used to map the globally unique
identifier to the IP address of the remote PE, along with an
identifier (perhaps unique only at the latter PE) for an AC at
that PE. The PW signaling protocol can then make a connection
to the remote PE, passing the AC identifier, so that the remote
PE binds the PW to the proper AC.
この食糧を供給することでは、モデル化してください、そして、リモートPEのIPアドレスは食糧を供給されません。 むしろ、仮定は自動発見計画がリモートPEのIPアドレスにグローバルにユニークな識別子を写像するのに使用されるということです、そのPEの西暦の識別子(後者のPEだけで恐らくユニークな)と共に。 次に、PWシグナリングプロトコルはリモートPEに接続を作ることができます、交流識別子を通過して、リモートPEが適切な西暦にPWを縛るように。
Andersson & Rosen Informational [Page 24] RFC 4664 Framework for Layer 2 VPNs September 2006
層2のVPNs2006年9月のためのアンデションとローゼン情報[24ページ]のRFC4664Framework
This scheme requires provisioning of the PW at only one PE, but
it does not eliminate the need (if there is a need) to provision
the ACs at both PEs.
この計画は、PWに、あるPEだけで食糧を供給するのを必要としますが、それは両方のPEsでACsに食糧を供給する必要性(必要があれば)を排除しません。
These provisioning models fit well with the use of point-to-point signaling. When each PW is individually provisioned, as the conditions necessary for the use of point-to-multipoint signaling do not hold.
モデルに食糧を供給するこれらが二地点間シグナリングの使用をよく与えます。 各PWが個別に食糧を供給されたら、ポイントツーマルチポイントシグナリングの使用に必要な状態として、成立しないでください。
3.3.1.3. Colored Pools PW Provisioning Model
3.3.1.3. モデルに食糧を供給するプールPWに着色されます。
Suppose that at each PE, sets of ACs are gathered together into "pools", and that each such pool is assigned a "color". (For example, a pool might contain all and only the ACs from this PE to a particular CE.) Now suppose that we impose the following rule: whenever PE1 and PE2 have a pool of the same color, there will be a PW between PE1 and PE2 that is bound at PE1 to an arbitrarily chosen AC from that pool, and at PE2 to an arbitrarily chosen AC from that pool. (We do not rule out the case where a single PE has multiple pools of a given color.)
各PEでは、ACsのセットが「プール」に集められて、「色」がそのような各プールに割り当てられると仮定してください。 (例えば、プールはこのPEから特定のCEまでのACsだけを含むかもしれません。) 今度は、私たちが以下の規則を課すと仮定してください: PE1とPE2に同じ色のプールがあるときはいつも、PE1とそのプールからの任意に選ばれた西暦へのPE1においてそのプールからの任意に選ばれた西暦へのPE2で制限されたPE2の間には、PWがあるでしょう。 (私たちは独身のPEが与えられた色の複数のプールを持っているケースを除外しません。)
For example, each pool in a particular PE might represent a particular CE device, for which the ACs in the pool are the ACs connecting that CE to that PE. The color might be a VPN-id. Application of this provisioning model would then lead to a full CE- to-CE mesh within the VPN, where every CE in the VPN has a virtual circuit to every other CE within the VPN.
例えば、特定のPEの各プールは特定のCE装置を表すかもしれません。(プールの中のACsはそのCEをそのPEに接続するそれに関するACsです)。 色はVPN-イドであるかもしれません。 そして、モデルに食糧を供給するこのアプリケーションがVPNで中VPNのあらゆるCEがVPNの中に他のあらゆるCEに仮想のサーキットを持っているCEへの完全なCEメッシュに通じるでしょう。
More specifically, to provision VPWS according to this model, one provisions a set of pools and configures each pool with the following information:
より明確に、1つは、このモデルに従った支給VPWSに、1セットのプールに食糧を供給して、以下の情報で各プールを構成します:
- The set of ACs that belong to the pool (with no AC belonging to
more than one pool)
- プールに属すACsのセット(西暦が1つ以上のプールに属すことのない)
- The color
- 色
- A pool identifier that is unique at least relative to the color.
- 少なくとも色に比例してユニークなプール識別子。
An auto-discovery procedure is then used to map each color into
a list of ordered pairs <IP address of PE, pool id>. The
occurrence of a pair <X, Y> on this list means that the PE at IP
address X has a pool with pool id Y, which is of the specified
color.
次に、自動発見手順はPEの順序対<IPアドレスのリストの中に各色を写像するのに用いられます、プールイド>。 組<Xの発生、このリストの上のY>はIPアドレスXのPEには指定された色のものであるプールイドYがあるプールがあることを意味します。
Andersson & Rosen Informational [Page 25] RFC 4664 Framework for Layer 2 VPNs September 2006
層2のVPNs2006年9月のためのアンデションとローゼン情報[25ページ]のRFC4664Framework
This information can be used to support several different
signaling techniques. One possible technique proceeds as
follows:
いくつかの異なったシグナリングのテクニックをサポートするのにこの情報を使用できます。 1つの可能なテクニックが以下の通り続きます:
- A PE finds that it has a pool of color C.
- PEは、それが色Cのプールを持っているのがわかります。
- Using auto-discovery, it obtains the set of ordered pairs <X,Y>
for color C.
- 自動発見を使用して、それは順序対<X、Y>のセットを色Cに入手します。
- For each such pair <X,Y>, it:
- 組<X、そのようなそれぞれのY>のためにそれ:
* removes an AC from the pool;
* プールから西暦を取り除きます。
* binds the AC to a particular PW; and
* 特定のPWに西暦を縛ります。 そして
* signals PE X via point-to-point signaling that the PW is to be
bound to an AC from pool Y.
* PWがプールYから西暦に縛られることになっているのを示すポイントツーポイントを通した信号PE X。
Another possible signaling technique is the following:
別の可能なシグナリングのテクニックは以下です:
- A PE finds that it has a pool of color C, containing n ACs.
- n ACsを含んでいて、PEは、それが色Cのプールを持っているのがわかります。
- It binds each AC to a PW, creating a set of PWs. This set of
PWs is then organized into a sequence. (For instance, each PW
may be associated with a demultiplexor field value, and the PWs
may then be sequenced according to the numerical value of their
respective demultiplexors.)
- PWsの1セットを創設して、それは各西暦をPWに縛ります。 そして、PWsのこのセットは系列に組織化されます。 (例えば、それぞれのPWは「反-マルチプレクサー」分野価値に関連しているかもしれなくて、次に、彼らのそれぞれの「反-マルチプレクサー」の数値によると、PWsは配列されるかもしれません。)
- Using auto-discovery, it obtains the list of PE routers that
have one or more pools of color C.
- 自動発見を使用して、それは色Cの1つ以上のプールを持っているPEルータのリストを得ます。
- It signals each such PE router, specifying the sequence Q of
PWs.
- PWsの系列Qを指定して、それはそのようなそれぞれのPEルータに合図します。
- If PE X receives such a signal and PE X has a pool Y of the
specified color, it:
- PE Xがそのような信号とPEを受信するならXには指定された色のプールYがある、それ:
* removes an AC from the pool; and
* プールから西暦を取り除きます。 そして
* binds the AC to the PW that is the "Yth" PW in the sequence Q.
* 系列Qの"Yth"PWであるPWに西暦を縛ります。
This presumes, of course, that the pool identifiers are or can be uniquely mapped into small ordinal numbers; assigning the pool identifiers in this way becomes a requirement of the provisioning system.
これは、もちろんプール識別子がそうであると推定するか、または唯一小さい序数詞に写像できます。 このようにプール識別子を割り当てるのは食糧を供給するシステムの要件になります。
Andersson & Rosen Informational [Page 26] RFC 4664 Framework for Layer 2 VPNs September 2006
層2のVPNs2006年9月のためのアンデションとローゼン情報[26ページ]のRFC4664Framework
Note that since this technique signals the same information to all the remote PEs, it can be supported via point-to-multipoint signaling.
このテクニックがすべてのリモートPEsに同じ情報を示すのでポイントツーマルチポイントシグナリングでそれを支持できることに注意してください。
This provisioning model can be applied as long as the following conditions hold:
以下の条件が成立する限り、この食糧を供給しているモデルを適用できます:
- There is no need to provision different characteristics for the
different PWs;
- 支給の異なった特性への異なったPWsの必要は全くありません。
- It makes no difference which pairs of ACs are bound together by
PWs, as long as both ACs in the pair come from like-colored
pools; and
- どの組のACsがPWsによって一緒に制限されているかは重要ではありません、組における両方のACsが同様に有色のプールから来る限り。 そして
- It is possible to construct the desired overlay topology simply
by assigning colors to the pools. (This is certainly simple if
a full mesh is desired, or if a hub and spoke configuration is
desired; creating arbitrary topologies is less simple, and is
perhaps not always possible.)
- 単に色をプールに割り当てることによって必要なオーバレイトポロジーを組み立てるのは可能です。 (スポーク構成は望まれています; 確かに、これが完全なメッシュが望まれているか、またはハブであるなら簡単であり、任意のtopologiesを作成するのは、それほど簡単でなく、恐らくいつも可能であるというわけではありません。)
3.3.2. Requirements on Auto-Discovery Procedures
3.3.2. 自動発見手順に関する要件
Some of the requirements for auto-discovery procedures can be deduced from the above.
上記で自動発見手順のための要件のいくつかを推論できます。
To support the single-sided provisioning model, auto-discovery must be able to map a globally unique identifier (of a PW or of an Attachment Circuit) to an IP address of a PE.
モデルに食糧を供給する片面単密度を支持するために、自動発見はグローバルにユニークな識別子(PWかAttachment Circuitの)をPEのIPアドレスに写像できなければなりません。
To support the colored pools provisioning model, auto-discovery must enable a PE to determine the set of other PEs that contain pools of the same color.
モデルに食糧を供給する有色のプールを支えるために、自動発見は、PEが同じ色のプールを含む他のPEsのセットを決定するのを可能にしなければなりません。
These requirements enable the auto-discovery scheme to provide the information, which the PEs need to set up the PWs.
これらの要件は、自動発見計画が情報を提供するのを可能にします。(PEsは、PWsをセットアップするために情報を必要とします)。
There are additional requirements on the auto-discovery procedures that cannot simply be deduced from the provisioning model:
食糧を供給しているモデルから絶対に推論できない自動発見手順に関する追加要件があります:
- Particular signaling schemes may require additional information
before they can proceed and hence may impose additional
requirements on the auto-discovery procedures.
- 特定のシグナリング計画は、続くことができる前に追加情報を必要として、したがって、自動発見手順に追加要件を課すかもしれません。
- A given Service Provider may support several different types of
signaling procedures, and thus the PEs may need to learn, via
auto-discovery, which signaling procedures to use.
- 与えられたService Providerはいくつかの異なったタイプのシグナリング手順を支持するかもしれません、そして、その結果、PEsはどのシグナリング手順を用いたらよいかを自動発見で学ぶ必要があるかもしれません。
Andersson & Rosen Informational [Page 27] RFC 4664 Framework for Layer 2 VPNs September 2006
層2のVPNs2006年9月のためのアンデションとローゼン情報[27ページ]のRFC4664Framework
- Changes in the configuration of a PE should be reflected by the
auto-discovery procedures, within a timely manner, and without
the need to explicitly reconfigure any other PE.
- PEの構成における変化はタイムリーな方法以内と自動発見手順と、明らかにいかなる他のPEも再構成する必要性なしで反映されるべきです。
- The auto-configuration procedures must work across service
provider boundaries. This rules out, e.g., use of schemes that
piggyback the auto-discovery information on the backbone's IGP.
- 自動構成手順はサービスプロバイダー限界の向こう側に利かなければなりません。 これはアウト、例えば背骨のIGPの自動発見情報を背負う計画の使用を統治します。
3.3.3. Heterogeneous Pseudowires
3.3.3. 異種のPseudowires
Under certain circumstances, it may be desirable to have a PW that binds two ACs that use different technologies (e.g., one is ATM, one is Ethernet). There are a number of different ways, depending on the AC types, in which this can be done. For example:
ある状況で、異なった技術を使用する2ACsを縛るPWを持っているのは望ましいかもしれません(例えば、1つがATMである、1つはイーサネットです)。 交流タイプ(これができる)に頼っていて、多くの異なった道があります。 例えば:
- If one AC is ATM and one is FR, then standard ATM/FR Network
Interworking can be used. In this case, the PW might be
signaled for ATM, where the Interworking function occurs between
the PW and the FR AC.
- 西暦1年がATMであり、1つがFRであるなら、標準のATM/FR Network Interworkingを使用できます。 この場合、PWはATMのために合図されるかもしれません。そこでは、Interworking機能がPWとFR ACの間に起こります。
- A common encapsulation can be used on both ACs, if for example,
one AC is Ethernet and one is FR, an "Ethernet over FR"
encapsulation can be used on the latter. In this case, the PW
could be signaled for Ethernet, with processing of the Ethernet
over FR encapsulation local to the PE with the FR AC.
- 両方のACsで一般的なカプセル化を使用できます、例えば、西暦1年がイーサネットであり、1つがFRであるなら後者で「FRの上のイーサネット」カプセル化は使用できます。 この場合、イーサネットのためにPWに合図できました、FR ACとPEへの地方のFRカプセル化の上のイーサネットの処理で。
- If it is known that the two ACs attach to IP routers or hosts
and carry only IP traffic, then one could use a PW that carries
the IP packets, and the respective Layer2 encapsulations would
be local matters for the two PEs. However, if one of the ACs is
a LAN and one is a point-to-point link, care would have to be
taken to ensure that procedures such as ARP and Inverse ARP are
properly handled; this might require some signaling, and some
proxy functions. Further, if the CEs use a routing algorithm
that has different procedures for LAN interfaces than those for
point-to-point interfaces, additional mechanisms may be required
to ensure proper interworking.
- 2ACsがIPルータかホストに付いて、IP交通だけを運ぶのが知られているなら、1つはIPパケットを運ぶPWを使用するかもしれません、そして、それぞれのLayer2カプセル化は2PEsのための地域にかかわる事柄でしょう。 しかしながら、ACsの1つがLANであり、1つがポイントツーポイント接続であるなら、ARPやInverse ARPなどの手順が適切に扱われるのを保証するために注意しなければならないでしょう。 これはいくつかのシグナリング、およびいくつかのプロキシ機能を必要とするかもしれません。 さらに、CEsがLANインタフェースに二地点間インタフェースへのそれらより異なった手順を持っているルーティング・アルゴリズムを使用するなら、追加メカニズムは適切な織り込むことを確実にしなければならないかもしれません。
Andersson & Rosen Informational [Page 28] RFC 4664 Framework for Layer 2 VPNs September 2006
層2のVPNs2006年9月のためのアンデションとローゼン情報[28ページ]のRFC4664Framework
3.4. VPLS Emulated LANs
3.4. VPLSはLANを見習いました。
A VPLS is an L2VPN service in which:
VPLSによるL2VPNが中でどれを修理するかということです:
- the ACs attach CE devices to PE bridge modules; and
- ACsはPE橋のモジュールにCE装置を取り付けます。 そして
- each PE bridge module is attached via an "emulated LAN
interface" to an "emulated LAN".
- それぞれのPE橋のモジュールは「見習われたLAN」への「見習われたLANインタフェース」を通して付けられています。
This is shown in Figure 3.
これは図3に示されます。
In this section, we examine the functional decomposition of the VPLS Emulated LAN. An Emulated LAN's ACs are the "emulated LAN interfaces" attaching PE bridge modules to the "VPLS Forwarder" modules (see Figure 3). The payload on the ACs consists of ethernet frames, with or without VLAN headers.
このセクションで、私たちはVPLS Emulated LANの機能的な分解を調べます。 Emulated LANのACsは「VPLS混載業者」モジュールにPE橋のモジュールを付ける「見習われたLANインタフェース」(図3を見る)です。 ACsのペイロードはVLANヘッダーのあるなしにかかわらずイーサネットフレームから成ります。
A given VPLS Forwarder in a given PE will have multiple ACs only if there are multiple bridge modules in that PE that attach to that Forwarder. This scenario is included in the Framework, though discussion of its utility is out of scope.
与えられたPEの与えられたVPLS Forwarderには、複数の橋のモジュールがそのForwarderに付くそのPEにある場合にだけ、複数のACsがあるでしょう。 範囲の外にユーティリティの議論がありますが、このシナリオはFrameworkに含まれています。
The set of VPLS Forwarders within a single VPLS are connected via PWs. Two VPLS Forwarders will have a PW between them only if those two Forwarders are part of the same VPLS. (There may be a further restriction that two VPLS Forwarders have a PW between them only if those two Forwarders belong to the same VLAN in the same VPN.) A particular set of interconnected VPLS Forwarders is what constitutes a VPLS Emulated LAN.
独身のVPLSの中のVPLS ForwardersのセットはPWsを通して接続されます。 2VPLS Forwardersの間には、PWがそれらの2Forwardersが同じVPLSの一部である場合にだけあるでしょう。 (それらの2Forwardersが同じVPNで同じVLANに属す場合にだけ2VPLS Forwardersの間には、PWがあるというさらなる制限があるかもしれません。) インタコネクトされたVPLS Forwardersの特定のセットはVPLS Emulated LANを構成するものです。
On a real LAN, any frame transmitted by one entity is received by all the others. A VPLS Emulated LAN, however, behaves somewhat differently. When a VPLS Forwarder receives a unicast frame over one of its Emulated LAN interfaces, the Forwarder does not necessarily send the frame to all the other Forwarders on that Emulated LAN. A unicast frame needs to be sent to only one other Forwarder in order to be properly delivered to its destination MAC address. If the transmitting Forwarder knows which other Forwarder needs to receive a particular unicast frame, it will send the frame to just that one Forwarder. This forwarding optimization is an important part of any attempt to provide a VPLS service over a wide-area or metropolitan area network.
本当のLANでは、1つの実体によって伝えられたどんなフレームもすべての他のものによって受け取られます。 しかしながら、VPLS Emulated LANはいくらか異なって振る舞います。 VPLS ForwarderがEmulated LANインタフェースのユニキャストフレーム1以上を受けるとき、Forwarderは必ずそのEmulated LANで他のすべてのForwardersにフレームを送るというわけではありません。 ユニキャストフレームは、適切に送付先MACアドレスに渡すために他の1Forwarderだけに送られる必要があります。 伝わっているForwarderが、どの他のForwarderが、特定のユニキャストフレームを受け取る必要であるかを知っていると、それは正当へのその1Forwarderをフレームに送るでしょう。 この推進最適化は広い領域かメトロポリタンエリアネットワークをVPLSサービスオーバーに提供するどんな試みの重要な部分です。
In effect, then, each Forwarder behaves as a "Virtual Switch Instance" (VSI), maintaining a forwarding table that maps MAC addresses to PWs. The VSI is populated in much the same way that a standard bridge populates its forwarding table. The VPLS Forwarders do MAC Source Address (SA) learning on frames received on PWs from
事実上、次に、各Forwarderは「仮想のスイッチ例」(VSI)として振る舞います、MACアドレスをPWsに写像する推進テーブルを維持して。 VSIによる標準の橋が居住する似たり寄ったりの方法で居住されて、テーブルを進めているということです。 VPLS Forwardersはフレームにおける学習がPWsで受信したMAC Source Address(SA)をします。
Andersson & Rosen Informational [Page 29] RFC 4664 Framework for Layer 2 VPNs September 2006
層2のVPNs2006年9月のためのアンデションとローゼン情報[29ページ]のRFC4664Framework
other Forwarders and must also do the related set of procedures, such as aging out address entries. Frames with unknown DAs or multicast DAs must be "broadcast" by one Forwarder to all the others (on the same emulated LAN). There are, however, a few important differences between the VPLS Forwarder VSI and the standard bridge forwarding function:
また、他のForwardersと必須は関連するセットの古い出かけているアドレスエントリーなどの手順をします。 未知のDAsかマルチキャストDAsがあるフレームは1Forwarderによってすべての他のもの(同じ見習われたLANの)に「放送されなければなりません」。 しかしながら、VPLS Forwarder VSIと標準の橋の推進機能の間には、いくつかの重要な違いがあります:
- A VPLS Forwarder never learns the MAC SAs of frames that it
receives on its ACs; it only learns the MAC SAs of frames that
are received on PWs from other VPLS Forwarders; and
- VPLS ForwarderはそれがACsで受けるフレームのMAC SAsを決して学びません。 それはPWsに他のVPLS Forwardersから受け取られるフレームのMAC SAsを学ぶだけです。 そして
- The VPLS Forwarders of a particular emulated LAN do not
participate in a spanning tree protocol with each other. A
"split horizon" technique is used to prevent forwarding loops.
- 特定の見習われたLANのVPLS Forwardersは互いと共にスパニングツリープロトコルに参加しません。 「分裂地平線」のテクニックは、輪を進めるのを防ぐのに使用されます。
These points are discussed further in the next section.
次のセクションで、より詳しくこれらのポイントについて議論します。
Note that the PE bridge modules that are on a given Emulated LAN may or may not run a spanning tree protocol with each other over the Emulated LAN; whether they do so or not is outside the scope of the VPLS specifications. The PE bridge modules will do MAC address learning on the ACs. The PE bridge modules also do MAC address learning on the Emulated LAN interfaces, but do not do MAC address learning on the PWs, as the PWs are "hidden" behind the Emulated LAN interface. Conceptually, the PE bridge module's forwarding table and the VPLS Forwarder's VSI are distinct entities. (Of course, particular implementations might combine these into a single table, but that is beyond the scope of this document.)
与えられたEmulated LANにあるPE橋のモジュールが互いと共にEmulated LANの上でスパニングツリープロトコルを走らせるかもしれないことに注意してください。 VPLS仕様の範囲の外に彼らがそうするかどうかがあります。 PE橋のモジュールはACsでアドレス学習をMACにするでしょう。 PE橋のモジュールも、Emulated LANインタフェースでアドレス学習をMACにしますが、PWsでアドレス学習はMACにしません、PWsがEmulated LANインタフェースの後ろに「隠される」とき。 概念的に、PE橋のモジュールの推進テーブルとVPLS ForwarderのVSIは別個の物です。 (もちろん、特定の実現は単一のテーブルにこれらを結合するかもしれませんが、それはこのドキュメントの範囲を超えています。)
A further issue arises if the PE bridges run bridge control protocols with each other over the Emulated LAN. Bridge control protocols are generally designed to run in over a real LAN and may presume, for their proper functioning, certain characteristics of the LAN, such as low latency and sequential delivery. If the Emulated LAN does not provide these characteristics, the control protocols may not perform as expected unless special mechanisms are provided for carrying the control frames.
PE橋が互いと共にEmulated LANの上で橋の制御プロトコルを走らせるなら、さらなる問題は起こります。 プロトコルが一般に、本当のLANの上で立候補するように設計されていて、それらの適切な機能のために推定するかもしれないコントロールに橋を架けてください、LANのある特性、低遅延や連続した配送のように。 Emulated LANがこれらの特性を提供しないなら、制御プロトコルは特別なメカニズムが制御フレームを運びながら備えられない場合予想されるように働かないかもしれません。
It should be noted that changes in the spanning tree (if any) of a customer network, or in the spanning tree (if any) of the PE bridges, may cause certain MAC addresses to change their location from one PE to another. These changes may not be visible to the VPLS Forwarders, which means that those MAC addresses might become unreachable until they are aged out of the first PE's VSI. If this is not acceptable, some mechanism for communicating such changes to the VPLS Forwarders must be provided.
あるMACアドレスが顧客ネットワークのスパニングツリー(もしあれば)、またはPE橋のスパニングツリー(もしあれば)における変化でそれらの位置を1PEから別のものに変えるかもしれないことに注意されるべきです。 これらの変化はVPLS Forwardersに目に見えないかもしれません。(VPLS Forwardersはそれらが最初のPEのVSIから熟成するまでそれらのMACアドレスが手が届かなくなるかもしれないことを意味します)。 これが許容できないなら、VPLS Forwardersへのそのような変化を伝えるための何らかのメカニズムを提供しなければなりません。
Andersson & Rosen Informational [Page 30] RFC 4664 Framework for Layer 2 VPNs September 2006
層2のVPNs2006年9月のためのアンデションとローゼン情報[30ページ]のRFC4664Framework
3.4.1. VPLS Overlay Topologies and Forwarding
3.4.1. VPLSはTopologiesと推進をかぶせました。
Within a single VPLS, the VPLS Forwarders are interconnected by PWs. The set of PWs thus forms an "overlay topology".
独身のVPLSの中では、VPLS ForwardersはPWsによってインタコネクトされます。 その結果、PWsのセットは「オーバレイトポロジー」を形成します。
The VPLS Forwarder VSIs are populated by means of MAC address learning. That is, the VSI keeps track of which MAC SAs have been received over which PWs. The presumption, of course, is that if a particular MAC address appears as the SA of a frame received over a particular PW, then frames that carry that MAC address in the DA field should be sent to the VSI that is at the remote end of the PW. In order for this presumption to be true, there must be a unique VSI at the remote end of the PW, which means that VSIs cannot be interconnected by means of multipoint-to-point PWs. The PWs are necessarily either point-to-point or, possibly, point-to-multipoint.
VPLS Forwarder VSIsはMACアドレス学習によって居住されます。 すなわち、MAC SAsがどのPWsの上に受け取られたVSIは動向をおさえます。 推定はもちろんフレームのSAが特定のPWの上で受信したので特定のMACアドレスが現れるならDA分野でそのMACアドレスを運ぶフレームをPWのリモートエンドにはあるVSIに送るべきであるということです。 この推定が本当であるように、PWのリモートエンドにはユニークなVSIがあるに違いありません。(PWは、VSIsが多点からポイントへのPWsによってインタコネクトされることができないことを意味します)。 PWsは必ずポイントツーポイントかことによるとポイントツーマルチポイントです。
MAC learning over a point-to-point PW is done via the standard techniques as specified by IEEE, where the PW is treated by the VPLS Forwarder as a "bridge port". Of course, if a MAC address is learned from a point-to-multipoint PW, the VSI must indicate that packets to that address are to be sent over a point-to-point PW that leads to the root of that point-to-multipoint PW.
IEEEによる指定されるとしての標準のテクニックで二地点間PWの上で学ぶMACをします。(そこでは、PWが「橋の港」としてVPLS Forwarderによって扱われます)。 もちろん、PW、MACアドレスがポイントツーマルチポイントから学習されるなら、VSIはそのアドレスへのパケットがそのポイントツーマルチポイントPWの根に通じる二地点間PWの上に送られることになっているのを示さなければなりません。
The VSI forwarding decisions must be coordinated so that loop-free forwarding over the overlay topology is ensured.
VSI推進決定を調整しなければならないので、オーバレイトポロジーの上の無輪の推進は確実にされます。
There are several possible types of overlay topologies:
オーバレイtopologiesのいくつかの可能なタイプがあります:
- Full mesh
- 完全なメッシュ
In a full mesh, every VSI in a given VPLS has exactly one
point-to-point PW to every other VSI in that same VPLS.
完全なメッシュでは、与えられたVPLSのあらゆるVSIがその同じVPLSにちょうど他の各VSIあたり1二地点間PWを持っています。
In this topology, loop free forwarding of frames is ensured by
the following rule: if a VSI receives a frame, over a PW, from
another VSI, it MUST NOT forward that frame over ANY other PW to
any other VSI. This ensures that once a frame traverses the
Emulated LAN, it must be sent off the Emulated LAN.
このトポロジー、フレームの無料の推進が以下によって確実にされる輪では、統治してください: VSIがPWの上にフレームを受けるなら、別のVSIから、それはそのフレームをいかなる他のVSIへの他のどんなPWの上にも送ってはいけません。 これは、フレームがいったんEmulated LANを横断すると、Emulated LANからそれを送らなければならないのを確実にします。
If a VSI receives, on one of its Emulated LAN interfaces, a
unicast frame with a known DA, the frame is sent on exactly one
point-to-point PW.
VSIが受信するなら、Emulated LANインタフェースの1つ、知られているDAがあるユニキャストフレームでは、ちょうど1二地点間PWにフレームを送ります。
If a VSI receives, on one of its Emulated LAN interfaces, a
multicast frame or a unicast frame with an unknown DA, it sends
a copy of the frame to each other VSI in the same Emulated LAN.
This can be done by replicating the frame and sending a copy
over each point-to-point PW. Alternatively, the full mesh of
VSIが受信するなら、未知のDAがあるEmulated LANインタフェースの1つ、マルチキャストフレームまたはユニキャストフレームに、それは同じEmulated LANで互いにフレームVSIのコピーを送ります。 それぞれの二地点間PWの上にフレームを模写して、コピーを送ることによって、これができます。 あるいはまた、満はかみ合います。
Andersson & Rosen Informational [Page 31] RFC 4664 Framework for Layer 2 VPNs September 2006
層2のVPNs2006年9月のためのアンデションとローゼン情報[31ページ]のRFC4664Framework
point-to-point PWs may be augmented with point-to-multipoint
PWs, where each VSI in a VPLS is the transmitter on a single
point-to-multipoint PW, and the receivers on that PW are all the
other VSIs in that VPLS.
ポイントツーポイントPWsはポイントツーマルチポイントPWsと共に増大するかもしれません、そして、そのPWの上の受信機はすべて、そのVPLSの他のVSIsです。(そこでは、VPLSの各VSIがただ一つのポイントツーマルチポイントPWの上の送信機です)。
- Tree structured
- 構造化された木
In a tree structured topology, every VSI in a particular VPLS is
provisioned to be at a particular level in the tree. A given
VSI has at most one pseudowire leading to a higher level. The
root of the tree is considered the highest level.
木の構造化されたトポロジーでは、特定のVPLSのあらゆるVSIが、木に特定のレベルにあるように食糧を供給されます。 与えられたVSIはpseudowireに最も1つで、より高いレベルに通じさせます。 木の根は最高水準であると考えられます。
In this topology, loop free forwarding of frames is ensured by
the following rule: if a frame is received over a pseudowire
from a higher level, it may not be sent over a pseudowire that
leads to a higher level.
このトポロジー、フレームの無料の推進が以下によって確実にされる輪では、統治してください: より高いレベルからフレームをpseudowireの上に受け取るなら、より高いレベルに通じるpseudowireの上にそれを送らないかもしれません。
- Tree with Meshed Highest Level
- かみ合っている最高水準がある木
In this variant of the tree-structured topology, there may be
more than one VSI at the highest level, but the set of VSIs that
are at the highest level must be fully meshed. To ensure loop
free forwarding, we need to impose the rule that a frame can be
sent on a pseudowire to the same or higher level only if it
arrived over a pseudowire from a lower level, and that frames
arriving over PWs from the same level cannot be sent on PWs to
the same level.
木で構造化されたトポロジーのこの異形に、1VSIが上層部によってあるかもしれませんが、最高水準にあるVSIsのセットを完全に網の目にかけなければなりません。 無料の推進を輪に確実にするために、私たちは、pseudowireの上で下のレベルから到着した場合にだけ同じであるか、より高いレベルへのpseudowireにフレームを送ることができて、PWsの上で同じレベルから届くフレームは同じレベルへのPWsに送ることができないという規則を課す必要があります。
Other overlay topologies are also possible; e.g., an arbitrary partial mesh of PWs among the VSIs of a VPLS. Loop-freedom could then be assured by, for example, running a spanning tree on the overlay. These topologies are not further considered in this framework.
また、他のオーバレイtopologiesも可能です。 例えば、VPLSのVSIsの中のPWsの任意の部分的なメッシュ。 そして、例えば、オーバレイでスパニングツリーを走らせることによって、輪自由を保証できるでしょう。 これらのtopologiesはこの枠組みでさらに考えられません。
Note that loop freedom in the overlay topology does not necessarily ensure loop freedom in the overall customer LAN that contains the VPLS. It does not even ensure loop freedom among the PE bridge modules. It ensures only that when a frame is sent on the Emulated LAN, the frame will not loop endlessly before (or instead of) leaving the Emulated LAN.
オーバレイトポロジーの輪の自由が必ずVPLSを含む総合的な顧客LANにおける輪の自由を確実にするというわけではないことに注意してください。 それはPE橋のモジュールの中で輪の自由を確実にさえしません。 の代わりにする、または、以前Emulated LANでフレームを送るとき、フレームが際限なく輪にされるだけではないのを確実にする、()、Emulated LANを残します。
Improper configuration of the customer LAN or PE bridge modules may cause frames to loop, and frames that fall into such loops may transit the overlay topology multiple times. Procedures that enable the PE to detect and/or prevent such loops may be advisable.
フレームは顧客LANかPE橋のモジュールの不適当な構成によって輪にされるかもしれません、そして、そのような輪になるフレームはオーバレイトポロジー倍数回数を通過するかもしれません。 PEがそのような輪を検出する、そして/または、防ぐのを可能にする手順は賢明であるかもしれません。
Andersson & Rosen Informational [Page 32] RFC 4664 Framework for Layer 2 VPNs September 2006
層2のVPNs2006年9月のためのアンデションとローゼン情報[32ページ]のRFC4664Framework
3.4.2. Provisioning and Auto-Discovery
3.4.2. 食糧を供給するのと自動発見
Each VPLS must be assigned a globally unique identifier. This can be thought of as a VPN-id.
グローバルにユニークな識別子を各VPLSに割り当てなければなりません。 VPN-イドとしてこれを考えることができます。
The ACs attaching the CEs to the PEs must be provisioned on both the PEs and the CEs. A VSI for that VPLS must be provisioned on the PE, and the local ACs of that VPLS must be associated with that VSI. The VSI must be provisioned with the identifier of the VPLS to which it belongs.
PEsとCEsの両方でCEsをPEsに取り付けるACsに食糧を供給しなければなりません。 PEでそのVPLSのためのVSIに食糧を供給しなければなりません、そして、そのVPLSの地方のACsはそのVSIに関連しているに違いありません。 それが属するVPLSに関する識別子でVSIに食糧を供給しなければなりません。
An auto-discovery scheme may be used by a PE to map a VPLS identifier into the set of remote PEs that have VSIs in that VPLS. Once this set is determined, the PE can use pseudowire signaling to set up a PW to each of those VSIs. The VPLS identifier would serve as the signaling protocol's Forwarder Selector. This would result in a full mesh of PWs among the VSIs in a particular VPLS.
自動発見計画は、そのVPLSにVSIsを持っているリモートPEsのセットにVPLS識別子を写像するのにPEによって使用されるかもしれません。 このセットがいったん決定するようになると、PEはそれぞれのそれらのVSIsにPWをセットアップすると合図するpseudowireを使用できます。 VPLS識別子はシグナリングプロトコルのForwarder Selectorとして機能するでしょう。 これは特定のVPLSのVSIsの中でPWsの完全なメッシュをもたらすでしょう。
If a single VPLS contains multiple VLANs, then it may be desirable to limit connectivity so that two VSIs are connected only if they have a VLAN in common.
独身のVPLSが複数のVLANsを含んでいるなら接続性を制限するのが望ましいかもしれないので、彼らがVLANが共通である場合にだけ、2VSIsが接続されています。
In this case, each VSI would need to be provisioned with one or more VLAN ids, and the auto-discovery scheme would need to map a VPLS identifier into pairs of <PE, VLAN id>.
この場合、各VSIは、1つ以上のVLANイドで食糧を供給される必要があるでしょう、そして、自動発見計画は組の<PE(VLANイド>)にVPLS識別子を写像する必要があるでしょう。
If a fully meshed topology of VSIs is not desired, then each VSI needs to be provisioned with additional information specifying its placement in the topology. This information would also need to be provided by the auto-discovery scheme.
VSIsの完全にかみ合っているトポロジーが望まれていないなら、各VSIは、追加情報がトポロジーでプレースメントを指定していて食糧を供給される必要があります。 また、この情報は、自動発見計画によって提供される必要があるでしょう。
Alternatively, the single-sided provisioning method discussed in Section 3.3.1.2 could be used. As this is more complicated, it would only be used if it were necessary to associate individual PWs with individual characteristics. For example, if different guaranteed bandwidths were needed between different pairs of sites within a VPLS, the PWs would have to be provisioned individually.
あるいはまた、メソッド議論されたコネセクション3.3.1.2に食糧を供給する片面単密度は使用できました。 これが、より複雑であるので、それが個々のPWsを個々の特性に関連づけるのに必要である場合にだけ、使用されるでしょうに。 例えば、異なった保証された帯域幅がVPLSの中の異なった組のサイトの間で必要であるなら、PWsに個別に食糧を供給されなければならないでしょうに。
3.4.3. Distributed PE
3.4.3. 分配されたPE
Often, when a VPLS type of service is provided, the CE devices attach to a provider-managed CPE device. This provider-managed CPE device may attach to CEs of multiple customers, especially if, for example, there are multiple customers occupying the same building. However, this device is really part of the SP's network, hence may be considered a PE device.
サービスのVPLSタイプを提供するとき、しばしば、CEデバイスはプロバイダーで管理されたCPEデバイスに付きます。 このプロバイダーで管理されたCPEデバイスは複数の顧客のCEsに付くかもしれません、特に例えば、同じビルを占領する複数の顧客がいれば。 しかしながら、このデバイスは、本当にSPのネットワークの一部であり、したがって、PEデバイスであると考えられるかもしれません。
Andersson & Rosen Informational [Page 33] RFC 4664 Framework for Layer 2 VPNs September 2006
層2のVPNs2006年9月のためのアンデションとローゼン情報[33ページ]のRFC4664Framework
In some scenarios in which a VPLS type of service is provided, the CE devices attach to a provider-managed intermediary device. This provider-managed device may attach to CEs of multiple customers. This may arise if there are multiple customers occupying the same building. This device is really part of the SP's network and may for that reason be considered to be a PE device; however, in the simplest case, it is performing only aggregation and none of the function associated with a VPLS.
サービスのVPLSタイプが提供されるいくつかのシナリオでは、CEデバイスはプロバイダーで管理された媒介装置に付きます。 このプロバイダーで管理されたデバイスは複数の顧客のCEsに付くかもしれません。 同じビルを占領する複数の顧客がいれば、これは起こるかもしれません。 このデバイスは、本当にSPのネットワークの一部であり、PEデバイスになるように考えられて、その理由で一部であるかもしれません。 しかしながら、最も簡単な場合では、それは集合だけとVPLSに関連している機能のいずれも実行していません。
Relative to the VPLS there are three different possibilities for allocate functions to a device in such a position in the provider network:
VPLSに比例して3つの異なった可能性がいる、プロバイダーネットワークでそのような位置のデバイスに機能を割り当ててください:
- it can perform aggregation and pure Layer2 service only, in
which case it does not really play the role of a PE device in a
VPLS service. In this case the intermediary system must connect
to devices that perform VPLS PE functionality; the intermediary
device itself is not part of the VPLS architecture and has hence
not been named in this architecture.
- それは集合と純粋なLayer2サービスしか実行できません、その場合、本当に、VPLSサービスでPEデバイスの役割を果たしません。 この場合、仲介者システムはVPLS PEの機能性を実行するデバイスに接続しなければなりません。 媒介装置自体は、VPLSアーキテクチャの一部でなく、またしたがって、このアーキテクチャで命名されていません。
- it can perform all the PE functions relevant for a VPLS. In
such a case, the device is called VPLS-PE, see [RFC4026]. This
type of device will be connected to the core (P) routers.
- それはVPLSにおいて、関連しているすべてのPE機能を実行できます。 [RFC4026]は、このような場合には、デバイスがVPLS-PEと呼ばれるのを見ます。 このタイプのデバイスはコア(P)ルータに接続されるでしょう。
The PE functionality for a VPLS may be distributed between two
devices, one "low-end" closer to the customer that performs, for
example, the MAC-address learning and forwarding decisions, and
one "high-end" that performs the control functions; e.g.,
establishing tunnels, PWs, and VCs. We call the low-end device
the User-Facing PE (U-PE) and the high-end device the Network-
Facing PE (N-PE).
VPLSのためのPEの機能性は働く顧客の、より近くで2台のデバイス、1「ローエンド」の間に分配されるかもしれません、例えば、学んで、決定、および1「ハイエンド」にそれを送るMAC-アドレスはコントロール機能を実行します。 例えば、トンネル、PWs、およびVCsを確立すること。 私たちは、Userに面しているPE(U-PE)にローエンドデバイスを呼んで、ハイエンドデバイスをNetworkの面しているPE(N-PE)と呼びます。
It is conceivable that the U-PE may be placed very close to the
customer; e.g., in a building with more than one customer. The
N-PE will presumably be placed on the SP's premises.
U-PEが顧客の非常に近くに置かれるのが想像できます。 例えば、1人以上の顧客がいるビルで。 おそらく、N-PEはSPの構内に置かれるでしょう。
The distributed case is potentially of interest for a number of
possible reasons:
分配されたケースは多くの可能な理由で潜在的に興味があります:
- The N-PE may be a device that cannot easily implement the VSI
functionality described above. For example, perhaps the N-PE is
a router that cannot perform the high speed MAC learning that is
needed in order to implement a VSI forwarder. At the same time,
the U-PE may need to be a low-cost device that also cannot
implement the full set of VPLS functions.
- N-PEはVSIが上で説明された機能性であると容易に実装することができないデバイスであるかもしれません。 例えば、恐らく、N-PEはVSI混載業者を実装するのに必要である高速MAC学習を実行できないルータです。 同時に、U-PEは、また、VPLS機能のフルセットを実装することができない安価のデバイスである必要があるかもしれません。
Andersson & Rosen Informational [Page 34] RFC 4664 Framework for Layer 2 VPNs September 2006
層2のVPNs2006年9月のためのアンデションとローゼン情報[34ページ]のRFC4664Framework
This leads one to investigate further if there are sensible ways
to split the VPLS PE functionality between the U-PE and the N-
PE.
これは、1つが、U-PEとN PEの間には、VPLS PEの機能性を分ける賢明な方法があるかをさらに調査するように導きます。
- Generally, in the L2VPN architecture, the PEs are expected to
participate as peers in the backbone routing protocol. Since
the number of U-PEs is potentially very large relative to the
number of N-PEs, this may be undesirable as a matter of scaling
the backbone routing protocol.
- 一般に、L2VPNアーキテクチャでは、バックボーンルーティングによる同輩が議定書を作るときPEsが参加すると予想されます。 U-PEsの数が潜在的にN-PEsの数に比例して非常に大きいので、これはバックボーンルーティング・プロトコルをスケーリングする問題として望ましくないかもしれません。
- The U-PE may be a relatively inexpensive device that is unable
to participate in the full range of signaling and/or auto-
discovery procedures that are needed in order to provide the
VPLS service.
- U-PEは最大限の範囲のシグナリングに参加できない比較的安価なデバイス、そして/または、VPLSサービスを提供するのに必要である自動発見手順であるかもしれません。
The VPLS functionality can be distributed between U-PE and N-PE in a number of different ways, and a number of different proposals have been made. They all presume that the U-PE will maintain a VSI forwarder, connected by PWs to the remote VSIs; the N-PE thus does not need to perform the VSI forwarding function. The proposals tend to differ with respect to the following questions:
多くの異なった方法でU-PEとN-PEの間にVPLSの機能性を分配できます、そして、多くの異なった提案をしました。 彼らは皆、U-PEがPWsによってリモートVSIsに接続されたVSI混載業者を維持すると推定します。 その結果、N-PEはVSI推進機能を実行する必要はありません。 提案は、以下の質問に関して異なる傾向があります:
- Should the U-PEs perform full PW signaling to set up the PWs to
remote VSIs, or should the N-PEs do this signaling?
- U-PEsがリモートVSIsにPWsをセットアップすると合図する完全なPWを実行するはずですか、またはN-PEsはこのシグナリングをするはずですか?
Since the U-PEs need to be able to send packets on PWs to remote
VSIs and receive packets on PWs from remote VSIs, if the PW
signaling is done by the N-PE, there would have to be some form
of "lightweight" (presumably) signaling between N-PE and U-PE
that allows the PWs to be extended from N-PE to U-PE.
N-PEがPWシグナリングを完了しているならU-PEsがPWsの上のパケットをリモートVSIsに送って、PWsでリモートVSIsからパケットを受けることができる必要があるのでN-PEとU-PEの間のそこでは、PWsがN-PEからU-PEまで広げられるのを許容する何らかのフォームの「軽量」(おそらく)のシグナリングでなければならないでしょう。
- Should the U-PEs do their own auto-discovery, or should this be
done by the N-PEs?
- U-PEsがそれら自身の自動発見をするはずですか、またはN-PEsはこれをするはずですか?
In the latter case, the U-PEs may need to have some means of
telling the N-PEs which VPLSes they are interested in, and the
N-PEs must have some means of passing the results of the auto-
discovery process to the U-PE.
後者の場合では、U-PEsは彼らがどのVPLSesに興味を持っているかをN-PEsに言ういくつかの手段を必要とするかもしれません、そして、N-PEsには、自動発見プロセスの結果をU-PEに通過するいくつかの手段がなければなりません。
Whether it makes sense to split auto-discovery in this manner
may depend on the particular auto-discovery protocol used. One
would not expect the U-PEs to participate in, if for example, a
BGP-based auto-discovery scheme, but perhaps they would be
expected to participate in a RADIUS-based auto-discovery scheme.
分裂自動発見に理解できるかどうかがこの様に使用される特定の自動発見プロトコルによるかもしれません。 人は、例えばならU-PEsがBGPベースの自動発見体系に参加すると予想しないでしょうが、恐らく、彼らがRADIUSベースの自動発見体系に参加すると予想されるでしょう。
- If a U-PE does not participate in routing but is redundantly
connected to two different N-PEs, can the U-PE still make an
intelligent choice of the best N-PE to use as the "next hop" for
- aであるなら、U-PEはルーティングに参加しませんが、冗長に2異なったN-PEsに接続されます、U-PEがまだ最も良いN-PEの「次のホップ」として使用する利口な選択をしている缶
Andersson & Rosen Informational [Page 35] RFC 4664 Framework for Layer 2 VPNs September 2006
層2のVPNs2006年9月のためのアンデションとローゼン情報[35ページ]のRFC4664Framework
traffic destined to a particular remote VSI? If not, can this
choice be made as the result of some other sort of interaction
between N-PE and U-PE, or does this choice need to be
established by provisioning?
特定のリモートVSIに運命づけられたトラフィック? そうでなければ、N-PEとU-PEとのある他の種類の相互作用の結果としてこの選択をすることができますか、またはこの選択は、食糧を供給することによって設立される必要がありますか?
- If a U-PE does not participate in routing but does participate
in full PW signaling, and if MPLS is being used, how can an N-PE
send a U-PE the labels that the U-PE needs in order to be able
to send traffic to its signaling peers? (If the U-PE did
participate in routing, this would happen automatically.)
- U-PEがルーティングに参加しませんが、完全なPWシグナリングに参加して、MPLSが使用されているなら、N-PEはどのように、U-PEがシグナリング同輩にトラフィックを送ることができるように必要とするラベルをU-PEに送ることができますか? (U-PEがルーティングに参加するなら、これは自動的に起こるでしょうに。)
- When a frame must be multicast, should the replication be done
by the N-PE or the U-PE?
- フレームがマルチキャストであるに違いないときに、N-PEかU-PEが模写をするはずですか?
These questions are not all independent; the way one answers
some of them may influence the way one answers others.
これらの質問はすべて独自ではありません。 人がそれらのいくつかに答える方法は人が他のものに答える方法に影響を及ぼすかもしれません。
3.4.4. Scaling Issues in VPLS Deployment
3.4.4. VPLS展開におけるスケーリング問題
In general, the PSN supports a VPLS solution with a tunnel from each VPLS-PE to every other VPLS-PE participating in the same VPLS instance. Strictly, VPLS-PEs with more than one VPLS instance in common only need one tunnel, but for resource allocation reasons it might be necessary to establish several tunnels. For each VPLS service on a given VPLS-PE, it needs to establish one pseudowire to every other VPLS-PE participating in that VPLS service. In total n*(n-1) pseudowires must be setup between the VPLS-PE routers. In large scale deployment this obviously creates scaling problems. One way to address the scaling problems is to use hierarchy.
一般に、PSNは各VPLS-PEから他のあらゆるVPLS-PEまでのトンネルが同じVPLSインスタンスに参加しているVPLSソリューションをサポートします。 厳密に、1つ以上のVPLSインスタンスが一般的にあるVPLS-PEsは1つのトンネルしか必要としませんが、資源配分理由に、いくつかのトンネルを確立するのが必要であるかもしれません。 与えられたVPLS-PEにおけるそれぞれのVPLSサービスのために、それは、そのVPLSサービスに参加する他の各VPLS-PEあたり1pseudowireを設立する必要があります。 n*(n-1)pseudowiresは合計で、VPLS-PEルータの間のセットアップであるに違いありません。 大規模展開では、これは明らかにスケーリング問題を生じさせます。そのスケーリング問題を訴えるOne方法は階層構造を使用することです。
3.5. IP-Only LAN-Like Service (IPLS)
3.5. IPだけのLANのようなサービス(IPLS)
If, instead of providing a general VPLS service, one wishes to provide a VPLS that is used only to connect IP routers or hosts (i.e., the CE devices are all assumed to be IP routers or hosts), then it is possible to make certain simplifications.
一般的なVPLSサービスを提供することの代わりに人が使用されるIPルータかホストに接するVPLSを提供したいなら(すなわち、CEデバイスはIPルータかホストであるとすべて思われます)、ある簡素化をするのは可能です。
In this environment, all Ethernet frames sent from a particular CE to a particular PE on a particular Attachment Circuit will have the same MAC Source Address. Thus, rather than use address learning in the data plane to learn the MAC addresses, the PE can use the control plane to learn the MAC address. This allows the PE to be implemented on devices that are not capable of doing MAC address learning in the data plane.
この環境で、特定のAttachment Circuitで特定のCEから特定のPEに送られたすべてのイーサネットフレームが同じMAC Source Addressを持つでしょう。 このようにして、むしろ、PEは、MACアドレスを学ぶのにデータ飛行機でMACアドレスを学ぶことを学ぶアドレスを使用するより制御飛行機を使用できます。 これで、PEはデータ飛行機でアドレス学習がMACにできないデバイスで実装します。
To eliminate the need for MAC address learning on the PWs as well as on the ACs, the pseudowire signaling protocol would have to carry the MAC address from one pseudowire endpoint to the other. In the case
PWsの上と、そして、ACsの上でMACアドレス学習の必要性を排除するために、pseudowireシグナリングプロトコルは1つのpseudowire終点からもう片方までMACアドレスを運ばなければならないでしょう。 場合で
Andersson & Rosen Informational [Page 36] RFC 4664 Framework for Layer 2 VPNs September 2006
層2のVPNs2006年9月のためのアンデションとローゼン情報[36ページ]のRFC4664Framework
of IPv4, Each PE would perform proxy ARP to its directly attached CEs. In the case of IPv6, each PE would send proxy Neighbor and/or Router Advertisements.
IPv4では、Each PEは直接付属しているCEsのプロキシARPを実行するでしょう。 IPv6の場合では、各PEはプロキシNeighbor、そして/または、Router Advertisementsを送るでしょう。
Eliminating the need to do MAC address learning on the PWs eliminates the need for the PWs to be point-to-point. Multipoint-to-point PWs could be used instead.
PWsでアドレス学習をMACにする必要性を排除すると、PWsが二地点間になる必要性は排除されます。 代わりに多点からポイントへのPWsを使用できました。
Unlike a VPLS, all the ACs in an IPLS would not necessarily have to carry Ethernet frames; only the IP packets would need to be passed across the network, not their Layer 2 wrappers. However, if there are protocols that are specific to the Layer 2, but that provide, for example, address resolution services for Layer 3, it may then be necessary to "translate" (or otherwise interwork) one of these Layer 2 protocols to the other. For example, if an IPLS instance has an ethernet AC and a Frame Relay AC, and IPv4 is running on both, interworking between ARP and Inverse ARP might be required.
VPLSと異なって、IPLSのすべてのACsは必ずイーサネットフレームを運ぶ必要はないでしょう。 IPパケットだけが、それらのLayer2ラッパーではなく、ネットワークの向こう側に通過される必要があるでしょう。 しかしながら、Layer2に特定ですが、例えばアドレス解決サービスをLayer3に供給するプロトコルがあれば、「翻訳」であることがその時必要であるかもしれない、(織り込む、そうでなければ、)、もう片方へのこれらのLayer2プロトコルの1つ。 例えば、IPLSインスタンスにはイーサネット西暦、Frame Relay西暦があって、IPv4が両方で走っているなら、ARPとInverse ARPの間の織り込むことが必要であるかもしれません。
The set of routing protocols that could be carried across the IPLS might also be restricted.
また、IPLSの向こう側に運ぶことができたルーティング・プロトコルのセットは制限されるかもしれません。
An IPLS instance must have a particular IPLS-wide MTU; if there are different kinds of AC in an IPLS instance, and those different kinds of AC support different MTUs, all ACS must enforce the IPLS-wide MTU; an AC that cannot do this must not be allowed to join the IPLS instance.
IPLSインスタンスには、特定のIPLS全体のMTUがなければなりません。 IPLSインスタンスにおける、異種の西暦、および交流サポートの異なったMTUsのそれらの異種があれば、すべてのACSがIPLS全体のMTUを実施しなければなりません。 これができない西暦にIPLSインスタンスを接合させてはいけません。
4. Security Considerations
4. セキュリティ問題
The security considerations section of the L2VPN requirements document [RFC4665] addresses a number of areas that are potentially insecure aspects of the L2VPN. These relate to both control plane and data plane security issues that may arise in the following areas:
L2VPN要件ドキュメント[RFC4665]のセキュリティ問題部は多くの潜在的に不安定な領域にL2VPNの局面を扱います。 これらは以下の領域に起こるかもしれない制御飛行機とデータ飛行機安全保障問題の両方に関連します:
- issues fully contained in the provider network
- プロバイダーネットワークに完全に含まれた問題
- issues fully contained in the customer network
- 顧客ネットワークに完全に含まれた問題
- issues in the customer-provider interface network
- 顧客プロバイダーインタフェースネットワークにおける問題
These three areas are addressed below.
これらの3つの領域が以下で扱われます。
4.1. Provider Network Security Issues
4.1. プロバイダーネットワーク安全保障問題
This section discusses security issues that only impact the SP's equipment.
このセクションはSPの設備に影響を与えるだけである安全保障問題について論じます。
Andersson & Rosen Informational [Page 37] RFC 4664 Framework for Layer 2 VPNs September 2006
層2のVPNs2006年9月のためのアンデションとローゼン情報[37ページ]のRFC4664Framework
There are security issues having to do with the control connections that are used on a PE-PE basis for setting up and maintaining the pseudowires.
pseudowiresをセットアップして、維持するPE-PEベースで使用されるコントロール接続と関係がある安全保障問題があります。
A PE should not engage with another PE in a control connection unless it has some confidence that the peer is really a PE to which it should be setting up PWs. Otherwise, L2PVN traffic may go to the wrong place. If control packets are maliciously and undetectably altered while in flight, denial of service, or alteration of the expected quality of service, may result.
それに同輩が本当にそれがPWsをセットアップするべきであるPEであるという何らかの信用がない場合、PEはコントロール接続で別のPEに噛み合うはずがありません。 さもなければ、L2PVNトラフィックは間違った場所に行くかもしれません。 サービスの否定、または予想されたサービスの質の変更が飛行で結果として生じているかもしれない間、コントロールパケットが陰湿にundetectablyに変更されるなら。
If peers discover each other dynamically (via some auto-discovery procedure), this presupposes that the auto-discovery procedures are themselves adequately trusted.
同輩がダイナミック(何らかの自動発見手順で)に互いを発見するなら、これは、自動発見手順が適切に信じられるのを予想します。
PEs should not accept control connections from arbitrary entities; a PE either should be configured with its peers or should learn them from a trusted auto-configuration procedure. If the peer is required to be within the same SP's network, then access control filters at the borders of that network can be used to prevent spoofing of the peer's source address. If the peer is from another SP's network, then setting up such filters may be difficult or even impossible, depending on the way in which the two SPs are connected. Even if the access filters can be set up, the level of assurance that they provide will be lower.
PEsは任意の実体からコントロール接続を受け入れるはずがありません。 PEは同輩に構成されるはずであるべきであるか、または信じられた自動構成手順から彼らを学ぶはずです。 同輩が同じSPのネットワークの中にいなければならないなら、同輩のソースアドレスをだますのを防ぐのにそのネットワークの境界のアクセスコントロール・フィルタを使用できます。 同輩が別のSPのネットワークから来ているなら、そのようなフィルタをセットアップするのは、難しいか、または不可能でさえあるかもしれません、2SPsが接続されている方法によって。 アクセスフィルタをセットアップできても、提供するという保証のレベルは低いでしょう。
Thus, for inter-SP control connections, it is advisable to use some sort of cryptographic authentication procedure. Control protocols which used TCP may use the TCP MD5 option to provide a measure of PE-PE authentication; this requires at least one shared secret between SPs. The use of IPsec between PEs is also possible and provides a greater degree of assurance, though at a greater cost.
したがって、相互SPコントロール接続に、ある種の暗号の認証手順を用いるのは賢明です。 TCPを使用した制御プロトコルはPE-PE認証の手段を提供するのにTCP MD5オプションを使用するかもしれません。 これはSPsの間の少なくとも1つの共有秘密キーを必要とします。 PEsの間のIPsecの使用は、また、可能であり、より大きい度合いを保証を提供します、より大きい費用で。
Any other security considerations that apply to the control protocol in general will also apply when the control protocol is used for setting up PWs. If the control protocol uses UDP messages, it may be advisable to have some protection against spoofed UDP messages that appear to be from a valid peer; this requires further study.
また、制御プロトコルがPWsをセットアップするのに使用されるとき、一般に、制御プロトコルに適用されるいかなる他のセキュリティ問題も適用されるでしょう。 制御プロトコルがUDPメッセージを使用するなら、有効な同輩からあるように見える偽造しているUDPメッセージに何らかの保護を抱くのは賢明であるかもしれません。 これはさらなる研究を必要とします。
To limit the effect of Denial of Service attacks on a PE, some means of limiting the rate of processing of control plane traffic may be desirable.
PEへのサービス妨害攻撃の効果を制限するために、コントロール飛行機通行の処理の速度を制限するいくつかの手段が望ましいかもしれません。
Unlike authentication and integrity, privacy of the signaling messages is not usually considered very important. If it is needed, the signaling messages can be sent through an IPsec connection.
認証と保全と異なって、通常、シグナリングメッセージのプライバシーは非常に重要であると考えられません。 それを必要とするなら、IPsec接続でシグナリングメッセージを送ることができます。
Andersson & Rosen Informational [Page 38] RFC 4664 Framework for Layer 2 VPNs September 2006
層2のVPNs2006年9月のためのアンデションとローゼン情報[38ページ]のRFC4664Framework
If the PE cannot efficiently handle high volumes of multicast traffic for sustained periods, then it may be possible to launch a denial of service attack on a VPLS service by sending a PE a large number of frames that have either a multicast address or an unknown MAC address in their MAC Destination Address fields. A similar denial of service attack can be mounted by sending a PE a large number of frames with bogus MAC Source Address fields. The bogus addresses can fill the MAC address tables in the PEs, with the result that frames destined to the real MAC addresses always get flooded (i.e., multicast). Note that this flooding can remove the (weak) confidentiality property of this or any other bridged network.
PEが持続している期間、効率的にマルチキャストトラフィックの高いボリュームを扱うことができないなら、それらのMAC Destination Address分野にマルチキャストアドレスか未知のMACアドレスのどちらかを持っている多くのフレームをPEに送ることによってVPLSサービスにサービス不能攻撃に着手するのは可能であるかもしれません。 にせのMAC Source Address分野がある多くのフレームをPEに送ることによって、サービス攻撃の同様の否定を仕掛けることができます。 にせのアドレスはPEsにMACアドレス・テーブルをいっぱいにすることができます、その結果、本当のMACアドレスに運命づけられたフレームがいつも水につかります(すなわち、マルチキャスト)。 この氾濫がこれかいかなる他のブリッジしているネットワークの(弱い)の秘密性資産も取り外すことができることに注意してください。
4.2. Provider-Customer Network Security Issues
4.2. プロバイダー顧客ネットワーク安全保障問題
There are a number of security issues related to the access network between the provider and the customer. This is also traditionally a network that is hard to protect physically.
プロバイダーと顧客の間には、アクセスネットワークに関連する多くの安全保障問題があります。 これは伝統的にも物理的に保護しにくいネットワークです。
Typical security issues on the provider-customer interface include the following:
プロバイダー顧客インタフェースの典型的な安全保障問題は以下を含んでいます:
- Ensuring that the correct customer interface is configured
- 正しい顧客インタフェースが構成されるのを確実にします。
- Preventing unauthorized access to the PE
- PEへの不正アクセスを防ぎます。
- Preventing unauthorized access to a specific PE port
- 特定のPEポートへの不正アクセスを防ぎます。
- Ensuring correct service delimiting fields (VLAN, DLCI, etc.)
- 分野を区切る正しいサービスを確実にします。(VLAN、DLCIなど)
As the access network for an L2VPN service is necessarily a Layer 2 network, it is preferable to use authentication mechanisms that do not presuppose any IP capabilities on the CE device.
L2VPNサービスのためのアクセスネットワークが必ずLayer2ネットワークであるので、CEデバイスの上の少しのIP能力も予想しない認証機構を使用するのは望ましいです。
There are existing Layer 2 protocols and best current practices to guard against these security issues. For example, IEEE 802.1x defines authentication at the link level for access through an ethernet bridge; the Frame Relay Forum defines LMI extensions for authentication (FRF.17).
これらの安全保障問題に用心するために、既存のLayer2プロトコルと最も良い現在の実務があります。 例えば、IEEE 802.1xはアクセスのためにイーサネットブリッジを通してリンク・レベルで認証を定義します。 Frame Relay Forumは認証(FRF.17)のためのLMI拡張子を定義します。
4.3. Customer Network Security Issues
4.3. 顧客ネットワーク安全保障問題
Even if all CE devices are properly authorized to attach to their PE devices, misconfiguration of the PE may interconnect CEs that are not supposed to be in the same L2VPN.
すべてのCEデバイスがそれらのPEデバイスに付くのが適切に認可されても、PEのmisconfigurationは同じL2VPNにあるべきでないCEsとインタコネクトするかもしれません。
In a VPWS, the CEs may run IPsec to authenticate each other. Other Layer 3 or Layer 4 protocols may have their own authentication methods.
VPWSでは、CEsは、互いを認証するためにIPsecを実行するかもしれません。 他のLayer3かLayer4プロトコルには、それら自身の認証方法があるかもしれません。
Andersson & Rosen Informational [Page 39] RFC 4664 Framework for Layer 2 VPNs September 2006
層2のVPNs2006年9月のためのアンデションとローゼン情報[39ページ]のRFC4664Framework
In a VPLS, CE-to-CE IPsec is even more problematic, as IPsec does not well support the multipoint configuration that is provided by the VPLS service.
VPLSでは、CEからCE IPsecはさらに問題が多いです、IPsecがVPLSサービスで提供される多点構成をよくサポートしないとき。
There may be alternative methods for achieving a degree of CE-to-CE authentication, if the L2VPN signaling protocol can carry opaque objects between the CEs, either inband (over the L2VPN) or out-of- band, through the participation of the signaling protocol. This is for further study.
CEからCEへの認証の度合いを達成するための別法があるかもしれません、L2VPNシグナリングプロトコルがinband(L2VPNの上で)か外のCEsの間まで不透明なオブジェクトを運ぶことができるなら。-バンドでは、シグナリングの参加で、議定書を作ってください。 さらなる研究にはこれがあります。
The L2VPN procedures do not provide authentication, integrity, or privacy for the customer's traffic; if this is needed, it becomes the responsibility of the customer. For customers who really need these features or who do not trust their service providers to provide the level of security that they need, the L2VPN framework discussed in this document may not be satisfactory. Such customers may consider alternative L2VPN schemes that are based not on an overlay of PWs, but on an overlay of IPsec tunnels whose endpoints are at the customer sites; however, such alternatives are not discussed in this document.
L2VPN手順は認証、保全、またはプライバシーを顧客のトラフィックに提供しません。 これが必要であるなら、それは顧客の責任になります。 それらのサービスプロバイダーが彼らが必要とするセキュリティのレベルを提供すると信じない本当にこれらの特徴が必要があるか、顧客にとって、本書では議論したL2VPNフレームワークは満足できないかもしれません。 そのような顧客はPWsのオーバレイではなく、終点が顧客サイトにあるIPsecトンネルのオーバレイに基づいている代替のL2VPN体系を考えるかもしれません。 しかしながら、本書ではそのような代替手段について議論しません。
If there is CE-to-CE control traffic (e.g., BPDUs) on whose integrity the customer's own Layer 2 network depends, it may be advisable to send the control traffic using some more secure mechanism than is used for the data traffic.
顧客の自身のLayer2がネットワークでつなぐだれの保全がよるかに関してCEからCEへのコントロールトラフィック(例えば、BPDUs)があれば、コントロールトラフィックを送るのはデータ通信量に使用されるよりそれ以上の安全なメカニズムを使用するのにおいて賢明であるかもしれません。
In general, any means of mounting a denial of service attack on bridged networks generally can also be used to mount a denial of service attack on the VPLS service for a particular customer. We have discussed here only those attacks that rely on features of the VPLS service that are not shared by bridged networks in general.
一般に、一般に、また、VPLSサービスのときにうるさい顧客のためにサービス不能攻撃を仕掛けるのにブリッジしているネットワークにサービス不能攻撃を仕掛けるどんな手段も使用できます。 私たちはここで一般に、ブリッジしているネットワークによって共有されないVPLSサービスの特徴を当てにするそれらの攻撃だけについて議論しました。
5. Acknowledgements
5. 承認
This document is the outcome of discussions within a Layer 2 VPN design team, all of whose members could be considered co-authors. Specifically, the co-authors are Loa Andersson, Waldemar Augustyn, Marty Borden, Hamid Ould-Brahim, Juha Heinanen, Kireeti Kompella, Vach Kompella, Marc Lasserre, Pascal Menezes, Vasile Radoaca, Eric Rosen, and Tissa Senevirathne.
このドキュメントはLayer2VPNデザインチーム(共著者であるとだれのメンバーを考えることができたかに関するすべて)の中の議論の結果です。 明確に、共著者は、Loaアンデションと、Waldemar Augustynと、マーティボーデンと、ハミドオールド-Brahimと、ユハHeinanenと、Kireeti Kompellaと、Vach Kompellaと、マーク・ラセールと、Pascalメネゼスと、バシレRadoacaと、エリック・ローゼンと、Tissa Senevirathneです。
The authors would like to thank Marco Carugi for cooperation in setting up context, working directions, and taking time for discussions in this space; Tove Madsen and Pekka Savola for valuable input and reviews; and Norm Finn, Matt Squires, and Ali Sajassi for valuable discussion of the VPLS issues.
作者は文脈をセットアップすることへの協力についてマルコCarugiに感謝したがっています、このスペースでの議論に方向を扱って、時間をかけて。 貴重な入力とレビューのためのトーヴマドセンとペッカSavola。 VPLS問題の貴重な議論のためのNormフィンランド人、マットSquires、およびアリSajassi。
Andersson & Rosen Informational [Page 40] RFC 4664 Framework for Layer 2 VPNs September 2006
層2のVPNs2006年9月のためのアンデションとローゼン情報[40ページ]のRFC4664Framework
6. Normative References
6. 引用規格
[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月。
[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月。
[RFC4026] Andersson, L. and T. Madsen, "Provider Provisioned
Virtual Private Network (VPN) Terminology", RFC 4026,
March 2005.
[RFC4026] アンデションとL.とT.マドセン、「プロバイダーの食糧を供給された仮想私設網(VPN)用語」、RFC4026、2005年3月。
[RFC4665] Augustyn, W., Ed. and Y. Serbest, Ed., "Service
Requirements for Layer 2 Provider-Provisioned Virtual
Private Networks (L2VPNs)", RFC 4665, September 2006.
エド[RFC4665]Augustyn、W.、Y.Serbest、エド、「層2のプロバイダーで食糧を供給された仮想私設網(L2VPNs)のための要件を修理してください」、RFC4665、9月2006
7. Informative References
7. 有益な参照
[IEEE8021D] IEEE 802.1D-2003, "IEEE Standard for Local and
Metropolitan Area Networks: Media Access Control (MAC)
Bridges"
[IEEE8021D]IEEE 802.1D-2003、「地方とメトロポリタンエリアネットワークのIEEE規格:」 「メディアアクセス制御(MAC)ブリッジ」
[IEEE8021Q] IEEE 802.1Q-1998, "IEEE Standards for Local and
Metropolitan Area Networks: Virtual Bridged Local Area
Networks"
[IEEE8021Q]IEEE 802.1Q-1998、「地方とメトロポリタンエリアネットワークのIEEE規格:」 「仮想のブリッジしているローカル・エリア・ネットワーク」
[RFC1771] Rekhter, Y. and T. Li, "A Border Gateway Protocol 4
(BGP-4)", RFC 1771, March 1995.
1995年の[RFC1771]RekhterとY.とT.李、「ボーダ・ゲイトウェイ・プロトコル4(BGP-4)」、RFC1771行進。
[RFC2661] Townsley, W., Valencia, A., Rubens, A., Pall, G., Zorn,
G., and B. Palter, "Layer Two Tunneling Protocol
"L2TP"", RFC 2661, August 1999.
[RFC2661]Townsley、W.、バレンシア、A.、ルーベン、A.、祭服、G.、ゾルン、G.、およびB.はあしらいます、「層Twoはプロトコル"L2TP"にトンネルを堀っ」て、RFC2661、1999年8月。
[RFC2796] Bates, T., Chandra, R., and E. Chen, "BGP Route
Reflection - An Alternative to Full Mesh IBGP", RFC
2796, April 2000.
[RFC2796] ベイツ、T.、チャンドラ、R.、およびE.チェン、「BGPは反射を発送します--完全なメッシュIBGPへの代替手段」、RFC2796、2000年4月。
[RFC3036] Andersson, L., Doolan, P., Feldman, N., Fredette, A.,
and B. Thomas, "LDP Specification", RFC 3036, January
2001.
[RFC3036] アンデションとL.とDoolanとP.とフェルドマンとN.とFredette、A.とB.トーマス、「自由民主党仕様」、RFC3036、2001年1月。
Andersson & Rosen Informational [Page 41] RFC 4664 Framework for Layer 2 VPNs September 2006
層2のVPNs2006年9月のためのアンデションとローゼン情報[41ページ]のRFC4664Framework
Authors' Addresses
作者のアドレス
Loa Andersson Acreo AB
LoaアンデションAcreo AB
EMail: loa@pi.se
メール: loa@pi.se
Eric C. Rosen Cisco Systems, Inc. 1414 Massachusetts Avenue Boxborough, MA 01719
マサチューセッツ通りBoxborough、エリックC.ローゼンシスコシステムズInc.1414MA 01719
EMail: erosen@cisco.com
メール: erosen@cisco.com
Waldemar Augustyn
Waldemar Augustyn
EMail: waldemar@wdmsys.com
メール: waldemar@wdmsys.com
Marty Borden
マーティボーデン
EMail: mborden@acm.org
メール: mborden@acm.org
Juha Heinanen Song Networks, Inc. Hallituskatu 16 33200 Tampere, Finland
ユハHeinanen SongはInc.Hallituskatu16 33200タンペレ(フィンランド)をネットワークでつなぎます。
EMail: jh@song.fi
メール: jh@song.fi
Kireeti Kompella Juniper Networks, Inc. 1194 N. Mathilda Ave Sunnyvale, CA 94089
Kireeti Kompella杜松はInc.1194N.マチルダ・Aveサニーベル、カリフォルニア 94089をネットワークでつなぎます。
EMail: kireeti@juniper.net
メール: kireeti@juniper.net
Vach Kompella TiMetra Networks 274 Ferguson Dr. Mountain View, CA 94043
Vach Kompella TiMetraはマウンテンビュー、274ファーガソンカリフォルニア博士 94043をネットワークでつなぎます。
EMail: vach.kompella@alcatel.com
メール: vach.kompella@alcatel.com
Andersson & Rosen Informational [Page 42] RFC 4664 Framework for Layer 2 VPNs September 2006
層2のVPNs2006年9月のためのアンデションとローゼン情報[42ページ]のRFC4664Framework
Marc Lasserre Riverstone Networks 5200 Great America Pkwy Santa Clara, CA 95054
マーク・ラセール・リバーストンはPkwyサンタクララ、5200Great Americaカリフォルニア 95054をネットワークでつなぎます。
EMail: mlasserre@lucent.com
メール: mlasserre@lucent.com
Pascal Menezies
パスカルMenezies
EMail: pascalm1@yahoo.com
メール: pascalm1@yahoo.com
Hamid Ould-Brahim Nortel Networks P O Box 3511 Station C Ottawa, ON K1Y 4H7, Canada
ハミドオールド-Brahimノーテルは私書箱3511駅のCオタワをK1Y 4H7、カナダにネットワークでつなぎます。
EMail: hbrahim@nortelnetworks.com
メール: hbrahim@nortelnetworks.com
Vasile Radoaca Nortel Networks 600 Technology Park Billerica, MA 01821
Parkビルリカ、バシレRadoacaノーテルネットワーク600Technology MA 01821
EMail: radoaca@hotmail.com
メール: radoaca@hotmail.com
Tissa Senevirathne 1567 Belleville Way Sunnyvale CA 94087
Tissa Senevirathne1567ベルビル道サニーベルカリフォルニア94087
EMail: tsenevir@hotmail.com
メール: tsenevir@hotmail.com
Andersson & Rosen Informational [Page 43] RFC 4664 Framework for Layer 2 VPNs September 2006
層2のVPNs2006年9月のためのアンデションとローゼン情報[43ページ]のRFC4664Framework
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)によって提供されます。
Andersson & Rosen Informational [Page 44]
アンデションとローゼンInformationalです。[44ページ]
一覧
スポンサーリンク
