RFC5254 日本語訳
5254 Requirements for Multi-Segment Pseudowire Emulation Edge-to-Edge(PWE3). N. Bitar, Ed., M. Bocci, Ed., L. Martini, Ed.. October 2008. (Format: TXT=64584 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group N. Bitar, Ed.
Request for Comments: 5254 Verizon
Category: Informational M. Bocci, Ed.
Alcatel-Lucent
L. Martini, Ed.
Cisco Systems, Inc.
October 2008
ワーキンググループN.Bitar、エドをネットワークでつないでください。コメントのために以下を要求してください。 5254年のベライゾンカテゴリ: エド情報のM.Bocci、エドアルカテル透明なL.マティーニ、シスコシステムズInc.2008年10月
Requirements for Multi-Segment Pseudowire Emulation Edge-to-Edge (PWE3)
マルチセグメントのPseudowireのエミュレーションの縁から縁のための要件(PWE3)
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.
このメモはインターネットコミュニティのための情報を提供します。 それはどんな種類のインターネット標準も指定しません。 このメモの分配は無制限です。
Abstract
要約
This document describes the necessary requirements to allow a service provider to extend the reach of pseudowires across multiple domains. These domains can be autonomous systems under one provider administrative control, IGP areas in one autonomous system, different autonomous systems under the administrative control of two or more service providers, or administratively established pseudowire domains.
このドキュメントはサービスプロバイダーが複数のドメインの向こう側にpseudowiresの範囲を広げるのを許容するという必要な要件について説明します。 これらのドメインは自律システムの1つ未満のプロバイダーの運営管理コントロール、1つの自律システムのIGP領域、2つ以上のサービスプロバイダー、または行政上確立したpseudowireドメインの運営管理コントロールの下で異なった自律システムであるかもしれません。
Bitar, et al. Informational [Page 1] RFC 5254 Requirements for Multi-Segment PWE3 October 2008
Bitar、他 マルチセグメントPWE3 October 2008のための情報[1ページ]のRFC5254要件
Table of Contents
目次
1. Introduction ....................................................3
1.1. Scope ......................................................3
1.2. Architecture ...............................................3
2. Terminology .....................................................6
2.1. Specification of Requirements ..............................6
3. Use Cases .......................................................7
3.1. Multi-Segment Pseudowire Setup Mechanisms ..................9
4. Multi-Segment Pseudowire Requirements ..........................10
4.1. All Mechanisms ............................................10
4.1.1. Architecture .......................................10
4.1.2. Resiliency .........................................11
4.1.3. Quality of Service .................................11
4.1.4. Congestion Control .................................12
4.1.5 Generic Requirements for MS-PW Setup Mechanisms ....13
4.1.6. Routing ............................................14
4.2. Statically Configured MS-PWs ..............................15
4.2.1. Architecture .......................................15
4.2.2. MPLS-PWs ...........................................15
4.2.3. Resiliency .........................................15
4.2.4. Quality of Service .................................16
4.3. Signaled PW Segments ......................................16
4.3.1. Architecture .......................................16
4.3.2. Resiliency .........................................16
4.3.3. Quality of Service .................................17
4.3.4. Routing ............................................17
4.3.5. Additional Requirements on Signaled MS-PW Setup
Mechanisms .........................................17
4.4. Signaled PW / Dynamic Route ...............................18
4.4.1. Architecture .......................................18
4.4.2. Resiliency .........................................18
4.4.3. Quality of Service .................................18
4.4.4. Routing ............................................18
5. Operations and Maintenance (OAM) ...............................19
6. Management of Multi-Segment Pseudowires ........................20
6.1. MIB Requirements ..........................................20
6.2. Management Interface Requirements .........................21
7. Security Considerations ........................................21
7.1. Inter-Provider MS-PWs .....................................21
7.1.1. Data-Plane Security Requirements ...................21
7.1.2. Control-Plane Security Requirements ................23
7.2. Intra-Provider MS-PWs .....................................25
8. Acknowledgments ................................................25
9. References .....................................................25
9.1. Normative References ......................................25
9.2. Informative References ....................................25
1. 序論…3 1.1. 範囲…3 1.2. 構造…3 2. 用語…6 2.1. 要件の仕様…6 3. ケースを使用してください…7 3.1. マルチセグメントPseudowireはメカニズムをセットアップします…9 4. マルチセグメントPseudowire要件…10 4.1. すべてのメカニズム…10 4.1.1. 構造…10 4.1.2. 弾性…11 4.1.3. サービスの品質…11 4.1.4. 混雑コントロール…12 4.1 .5 MS-PWのための一般的な要件はメカニズムをセットアップします…13 4.1.6. ルート設定…14 4.2. 静的に、MS-PWsは構成しました…15 4.2.1. 構造…15 4.2.2. MPLS-PWs…15 4.2.3. 弾性…15 4.2.4. サービスの品質…16 4.3. PWセグメントに合図します…16 4.3.1. 構造…16 4.3.2. 弾性…16 4.3.3. サービスの品質…17 4.3.4. ルート設定…17 4.3.5. 合図されたMS-PWに関する追加要件はメカニズムをセットアップします…17 4.4. PW/ダイナミックなルートに合図します…18 4.4.1. 構造…18 4.4.2. 弾性…18 4.4.3. サービスの品質…18 4.4.4. ルート設定…18 5. 操作と維持(OAM)…19 6. マルチセグメントPseudowiresの管理…20 6.1. MIB要件…20 6.2. 経営者側は要件を連結します…21 7. セキュリティ問題…21 7.1. 相互プロバイダーMS-PWs…21 7.1.1. データ飛行機セキュリティ要件…21 7.1.2. 制御飛行機セキュリティ要件…23 7.2. イントラプロバイダーMS-PWs…25 8. 承認…25 9. 参照…25 9.1. 標準の参照…25 9.2. 有益な参照…25
Bitar, et al. Informational [Page 2] RFC 5254 Requirements for Multi-Segment PWE3 October 2008
Bitar、他 マルチセグメントPWE3 October 2008のための情報[2ページ]のRFC5254要件
1. Introduction
1. 序論
1.1. Scope
1.1. 範囲
This document specifies requirements for extending pseudowires across more than one packet switched network (PSN) domain and/or more than one PSN tunnel. These pseudowires are called multi-segment pseudowires (MS-PWs). Requirements for single-segment pseudowires (SS-PWs) that extend edge to edge across only one PSN domain are specified in [RFC3916]. This document is not intended to invalidate any part of [RFC3985].
このドキュメントは1つ以上のパケット交換網(PSN)ドメイン、そして/または、1つ以上のPSNトンネルの向こう側にpseudowiresを広げるための要件を指定します。 これらのpseudowiresはマルチセグメントpseudowires(MS-PWs)と呼ばれます。 広がるただ一つのセグメントpseudowires(SS-PWs)が1つのPSNドメインだけの向こう側に斜めに進むために斜めに進むので、要件は[RFC3916]で指定されます。 このドキュメントが[RFC3985]のどんな部分も無効にすることを意図しません。
This document specifies additional requirements that apply to MS-PWs. These requirements do not apply to PSNs that only support SS-PWs.
このドキュメントはMS-PWsに適用される追加要件を指定します。 これらの要件はSS-PWsを支持するだけであるPSNsに適用されません。
1.2. Architecture
1.2. 構造
The following three figures describe the reference models that are derived from [RFC3985] to support PW emulated services.
以下の3つの数字が[RFC3985]からサポートまで引き出されて、PWがサービスを見習ったということである規範モデルについて説明します。
|<-------------- Emulated Service ---------------->|
| |
| |<------- Pseudowire ------->| |
| | | |
| | |<-- PSN Tunnel -->| | |
| PW End V V V V PW End |
V Service +----+ +----+ Service V
+-----+ | | PE1|==================| PE2| | +-----+
| |----------|............PW1.............|----------| |
| CE1 | | | | | | | | CE2 |
| |----------|............PW2.............|----------| |
+-----+ ^ | | |==================| | | ^ +-----+
^ | +----+ +----+ | | ^
| | Provider Edge 1 Provider Edge 2 | |
| | | |
Customer | | Customer
Edge 1 | | Edge 2
| |
| |
Attachment Circuit (AC) Attachment Circuit (AC)
Native service Native service
| <。-------------- 見習われたサービス---------------->|、|、|、| | <、-、-、-、-、-、-- Pseudowire------->|、|、|、|、|、|、|、| | <-- PSNはトンネルを堀ります-->|、|、|、| PW終わりのV V V V PWエンド| Vサービス+----+ +----+ サービス対+-----+ | | PE1|==================| PE2| | +-----+ | |----------|............PW1…|----------| | | CE1| | | | | | | | CE2| | |----------|............PW2…|----------| | +-----+ ^ | | |==================| | | ^ +-----+ ^ | +----+ +----+ | | ^ | | 1つのプロバイダー縁のプロバイダー縁2| | | | | | 顧客| | 顧客縁1| | 縁2| | | | 付属のCircuit(西暦)の付属のCircuitの(西暦)ネイティブのサービスのネイティブのサービス
Figure 1: PWE3 Reference Configuration
図1: PWE3参照構成
Bitar, et al. Informational [Page 3] RFC 5254 Requirements for Multi-Segment PWE3 October 2008
Bitar、他 マルチセグメントPWE3 October 2008のための情報[3ページ]のRFC5254要件
Figure 1 shows the PWE3 reference architecture [RFC3985]. This architecture applies to the case where a PSN tunnel extends between two edges of a single PSN domain to transport a PW with endpoints at these edges.
図1はPWE3参照構造[RFC3985]を示しています。 この構造はPSNトンネルが終点がこれらの縁にある状態でPWを輸送するためにただ一つのPSNドメインの2つの縁の間で広がるケースに適用されます。
Native |<--------Multi-Segment Pseudowire----->| Native
Service | PSN PSN | Service
(AC) | |<-Tunnel->| |<-Tunnel->| | (AC)
| V V 1 V V 2 V V |
| +-----+ +-----+ +---- + |
+---+ | |T-PE1|==========|S-PE1|==========|T-PE2| | +---+
| |---------|........PW1.......... |...PW3..........|---|----| |
|CE1| | | | | | | | | |CE2|
| |---------|........PW2...........|...PW4..........|--------| |
+---+ | | |==========| |==========| | | +---+
^ +-----+ +-----+ +-----+ ^
| Provider Edge 1 ^ Provider Edge 3 |
| | |
| | |
| PW switching point |
| |
| |
|<------------------- Emulated Service ------------------->|
ネイティブ| <、-、-、-、-、-、-、--マルチセグメントPseudowire----->| ネイティブのサービス| PSN PSN| サービス(西暦)| | <、-トンネル>| | <、-トンネル>|、| (西暦) | V V1V V2V V| | +-----+ +-----+ +---- + | +---+ | |T-PE1|==========|S-PE1|==========|T-PE2| | +---+ | |---------|........PW1… |...PW3…|---|----| | |CE1| | | | | | | | | |CE2| | |---------|........PW2…|...PW4…|--------| | +---+ | | |==========| |==========| | | +---+ ^ +-----+ +-----+ +-----+ ^ | プロバイダー縁の1^プロバイダー縁3| | | | | | | | PW切り換えポイント| | | | | | <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-- 見習われたサービス------------------->|
Figure 2: PW Switching Reference Model
図2: PW切り換え規範モデル
Figure 2 extends this architecture to show a multi-segment case. Terminating PE1 (T-PE1) and Terminating PE3 (T-PE3) provide PWE3 service to CE1 and CE2. These PEs terminate different PSN tunnels, PSN Tunnel 1 and PSN Tunnel 2, and may reside in different PSN or pseudowire domains. One PSN tunnel extends from T-PE1 to S-PE1 across PSN1, and a second PSN tunnel extends from S-PE1 to T-PE2 across PSN2.
図2は、マルチセグメントケースを見せているためにこの構造を広げています。 PE1(T-PE1)を終えて、Terminating PE3(T-PE3)はCE1とCE2に対するサービスをPWE3に供給します。 これらのPEsは異なったPSNトンネル、PSN Tunnel1、およびPSN Tunnel2を終えて、異なったPSNかpseudowireドメインに住むかもしれません。 1つのPSNトンネルがPSN1の向こう側にT-PE1からS-PE1に広がっています、そして、2番目のPSNトンネルはPSN2の向こう側にS-PE1からT-PE2に広がっています。
PWs are used to connect the Attachment circuits (ACs) attached to T-PE1 to the corresponding ACs attached to T-PE2. Each PW on PSN tunnel 1 is switched to a PW in the tunnel across PSN2 at S-PE1 to complete the multi-segment PW (MS-PW) between T-PE1 and T-PE2. S-PE1 is therefore the PW switching point and will be referred to as the PW switching provider edge (S-PE). PW1 and PW3 are segments of the same MS-PW while PW2 and PW4 are segments of another pseudowire. PW segments of the same MS-PW (e.g., PW1 and PW3) MAY be of the same PW type or different types, and PSN tunnels (e.g., PSN Tunnel 1 and PSN Tunnel 2) can be the same or different technology. This document requires support for MS-PWs with segments of the same PW type only.
PWsは、T-PE1に取り付けられたAttachmentサーキット(ACs)をT-PE2に取り付けられた対応するACsにつなげるのに使用されます。 PSNトンネル1の上の各PWは、T-PE1とT-PE2の間でマルチセグメントPW(MS-PW)を完成するためにS-PE1でPSN2の向こう側にトンネルのPWに切り換えられます。 S-PE1はしたがって、PW切り換えポイントであり、PW切り換えプロバイダー縁(S-PE)と呼ばれるでしょう。 PW2とPW4は別のpseudowireのセグメントですが、PW1とPW3は同じMS-PWのセグメントです。 同じPWタイプか異なったタイプには同じMS-PW(例えば、PW1とPW3)のPWセグメントがあるかもしれません、そして、PSNトンネル(例えば、PSN Tunnel1とPSN Tunnel2)は同じであるか異なった技術であるかもしれません。 このドキュメントは同じPWタイプだけのセグメントがあるMS-PWsに支持を要します。
Bitar, et al. Informational [Page 4] RFC 5254 Requirements for Multi-Segment PWE3 October 2008
Bitar、他 マルチセグメントPWE3 October 2008のための情報[4ページ]のRFC5254要件
An S-PE switches an MS-PW from one segment to another based on the PW identifiers (e.g., PW label in case of MPLS PWs). In Figure 2, the domains that PSN Tunnel 1 and PSN Tunnel 2 traverse could be IGP areas in the same IGP network or simply PWE3 domains in a single flat IGP network, for instance.
S-PEは1つのセグメントからPW識別子(例えば、MPLS PWsの場合のPWラベル)に基づく別のものにMS-PWを切り換えます。 図2では、2が横断するドメインのそのPSN Tunnel1とPSN Tunnelは同じIGPネットワークにおけるIGP領域か例えば、ただ一つの平坦なIGPネットワークで単にPWE3ドメインであるかもしれません。
|<------Multi-Segment Pseudowire------>|
| AS AS |
AC | |<----1---->| |<----2--->| | AC
| V V V V V V |
| +----+ +-----+ +----+ +----+ |
+----+ | | |=====| |=====| |=====| | | +----+
| |-------|.....PW1..........PW2.........PW3.....|-------| |
| CE1| | | | | | | | | | | |CE2 |
+----+ | | |=====| |=====| |=====| | | +----+
^ +----+ +-----+ +----+ +----+ ^
| T-PE1 S-PE2 S-PE3 T-PE4 |
| ^ ^ |
| | | |
| PW switching points |
| |
| |
|<------------------- Emulated Service --------------->|
| <。------マルチセグメントPseudowire------>|、| as| 西暦| | <、-、-、--1---->| | <、-、-、--2--->|、| 西暦| V V V V V V| | +----+ +-----+ +----+ +----+ | +----+ | | |=====| |=====| |=====| | | +----+ | |-------|.....PW1…PW2…PW3…|-------| | | CE1| | | | | | | | | | | |CE2| +----+ | | |=====| |=====| |=====| | | +----+ ^ +----+ +-----+ +----+ +----+ ^ | T-PE1 S-PE2 S-PE3 T-PE4| | ^ ^ | | | | | | PW切り換えポイント| | | | | | <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-- 見習われたサービス--------------->|
Figure 3: PW Switching Inter-Provider Reference Model
図3: PW切り換え相互プロバイダー規範モデル
Note that although Figure 2 only shows a single S-PE, a PW may transit more than one S-PEs along its path. For instance, in the multi-AS case shown in Figure 3, there can be an S-PE (S-PE2) at the border of one AS (AS1) and another S-PE (S-PE3) at the border of the other AS (AS2). An MS-PW that extends from the edge of one AS (T- PE1) to the edge of the other AS (T-PE4) is composed of three segments: (1) PW1, a segment in AS1, (2) PW2, a segment between the two border routers (S-PE2 and S-PE3) that are switching PEs, and (3) PWE3, a segment in AS2. AS1 and AS2 could belong to the same provider (e.g., AS1 could be an access network or metro transport network, and AS2 could be an MPLS core network) or to two different providers (e.g., AS1 for Provider 1 and AS2 for Provider 2).
図2が独身のS-PEを示しているだけですが、PWは経路に沿ったトランジット1以上S-PEsを示すかもしれないことに注意してください。 例えば、図3のマルチAS場合には、S-PE(S-PE2)が他のAS(AS2)の境界に1AS(AS1)と別のS-PE(S-PE3)の境界にあることができます。 1AS(T PE1)の縁から他のAS(T-PE4)の縁に広がるMS-PWは3つのセグメントで構成されます: (1) PW1、AS1のセグメント、(2)PW2、PEsを切り換えている2つの境界ルータ(S-PE2とS-PE3)の間のセグメント、および(3)PWE3、AS2のセグメント。 AS1とAS2は同じプロバイダー(例えば、AS1はアクセスネットワークか地下鉄転送ネットワークであるかもしれません、そして、AS2はMPLSコアネットワークであるかもしれない)、または、2つの異なったプロバイダー(例えば、Provider1のためのAS1とProvider2のためのAS2)に属できました。
Bitar, et al. Informational [Page 5] RFC 5254 Requirements for Multi-Segment PWE3 October 2008
Bitar、他 マルチセグメントPWE3 October 2008のための情報[5ページ]のRFC5254要件
2. Terminology
2. 用語
RFC 3985 [RFC3985] provides terminology for PWE3. The following additional terminology is defined for multi-segment pseudowires:
RFC3985[RFC3985]は用語をPWE3に供給します。 以下の追加用語はマルチセグメントpseudowiresのために定義されます:
- PW Terminating Provider Edge (T-PE). A PE where the
customer-facing attachment circuits (ACs) are bound to a PW
forwarder. A Terminating PE is present in the first and last
segments of an MS-PW. This incorporates the functionality of a
PE as defined in RFC 3985.
- プロバイダーを終えるPWが(T-PE)を斜めに進ませます。 顧客に面する付属サーキット(ACs)がPW混載業者に縛られるPE。 Terminating PEはMS-PWの1番目で現在で最後のセグメントです。 これはRFC3985で定義されるようにPEの機能性を取り入れます。
- Single-Segment Pseudowire (SS-PW). A PW setup directly between
two PE devices. Each direction of an SS-PW traverses one PSN
tunnel that connects the two PEs.
- ただ一つのセグメントPseudowire(SS-PW)。 2台のPE装置の直接間のPWセットアップ。 SS-PWの各指示は2PEsを接続する1つのPSNトンネルを横断します。
- Multi-Segment Pseudowire (MS-PW). A static or dynamically
configured set of two or more contiguous PW segments that
behave and function as a single point-to-point PW. Each end of
an MS-PW by definition MUST terminate on a T-PE.
- マルチセグメントPseudowire(MS-PW)。 独身の二地点間PWとして振る舞って、機能する2つ以上の隣接のPWセグメントの静的であるかダイナミックに構成されたセット。 定義上MS-PWの各端はT-PEで終わらなければなりません。
- PW Segment. A single-segment or a part of a multi-segment PW,
which is set up between two PE devices, T-PEs and/or S-PEs.
- PWセグメント。 ただ一つのセグメントかマルチセグメントPWの一部。(その一部が2台のPE装置、T-PEs、そして/または、S-PEsの間でセットアップされます)。
- PW Switching Provider Edge (S-PE). A PE capable of switching
the control and data planes of the preceding and succeeding PW
segments in an MS-PW. The S-PE terminates the PSN tunnels
transporting the preceding and succeeding segments of the MS-
PW. It is therefore a PW switching point for an MS-PW. A PW
switching point is never the S-PE and the T-PE for the same
MS-PW. A PW switching point runs necessary protocols to set up
and manage PW segments with other PW switching points and
terminating PEs.
- プロバイダーを切り換えるPWが(S-PE)を斜めに進ませます。 MS-PWで先行と続くPWセグメントのコントロールとデータ飛行機を切り換えることができるPE。 S-PEはMS PWの先行と続くセグメントを輸送するPSNトンネルを終えます。 したがって、それはMS-PWのためのPW切り換えポイントです。 PW切り換えポイントは、同じMS-PWのためのS-PEと決してT-PEではありません。 PW切り換えポイントは、他のPW切り換えポイントとPEsを終えるのにPWセグメントをセットアップして、管理するために必要なプロトコルを走らせます。
2.1. Specification of Requirements
2.1. 要件の仕様
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
キーワード“MUST"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTは[RFC2119]で説明されるように本書では解釈されることであるべきですか?
Bitar, et al. Informational [Page 6] RFC 5254 Requirements for Multi-Segment PWE3 October 2008
Bitar、他 マルチセグメントPWE3 October 2008のための情報[6ページ]のRFC5254要件
3. Use Cases
3. ケースを使用してください。
PWE3 defines the signaling and encapsulation techniques for establishing SS-PWs between a pair of terminating PEs (T-PEs), and in the vast majority of cases, this will be sufficient. MS-PWs may be useful in the following situations:
PWE3は1組の終わりPEs(T-PEs)の間のSS-PWsを設立するためのシグナリングとカプセル化技術を定義します、そして、非常に多くの場合に、これは十分です。 MS-PWsは以下の状況で役に立つかもしれません:
-i. Inter-Provider PWs: An Inter-Provider PW is a PW that extends
from a T-PE in one provider domain to a T-PE in another
provider domain.
-i。 相互プロバイダーPWs: Inter-プロバイダーPWは1つのプロバイダードメインのT-PEから別のプロバイダードメインのT-PEに広がるPWです。
-ii. It may not be possible, desirable, or feasible to establish a
direct PW control channel between the T-PEs, residing in
different provider networks, to set up and maintain PWs. At a
minimum, a direct PW control channel establishment (e.g.,
targeted LDP session) requires knowledge of and reachability
to the remote T-PE IP address. The local T-PE may not have
access to this information due to operational or security
constraints. Moreover, an SS-PW would require the existence
of a PSN tunnel between the local T-PE and the remote T-PE.
It may not be feasible or desirable to extend single,
contiguous PSN tunnels between T-PEs in one domain and T-PEs
in another domain for security and/or scalability reasons or
because the two domains may be using different PSN
technologies.
-ii。 T-PEsの間のダイレクトPW制御チャンネルを確立するのは、可能であるか、望ましいか、または可能でないかもしれません、PWsをセットアップして、維持するために異なったプロバイダーネットワークで住んでいて。 最小限では、ダイレクトPWコントロールチャンネル設立(例えば、自由民主党のセッションを狙う)はリモートT-PE IPアドレスへの知識と可到達性を必要とします。 地方のT-PEは操作上かセキュリティ規制のためこの情報に近づく手段を持っていないかもしれません。 そのうえ、SS-PWは地方のT-PEとリモートT-PEの間のPSNトンネルの存在を必要とするでしょう。 セキュリティ、そして/または、スケーラビリティが推論するか、または2つのドメインが異なったPSN技術を使用しているかもしれないので、別のドメインで1つのドメインのT-PEsとT-PEsの間の単一の、そして、隣接のPSNトンネルを広げるのは、可能であるか、または望ましくないかもしれません。
-iii. MS-PW setup, maintenance, and forwarding procedures must
satisfy requirements placed by the constraints of a
multi-provider environment. An example is the inter-AS L2VPN
scenario where the T-PEs reside in different provider networks
(ASs) and it is the current practice to MD5-key all control
traffic exchanged between two networks. An MS-PW allows the
providers to confine MD5 key administration for the LDP
session to just the PW switching points connecting the two
domains.
-iii。 MS-PWセットアップ、維持、および推進手順はマルチプロバイダー環境の規制で置かれた要件を満たさなければなりません。 例はT-PEsが異なったプロバイダーネットワーク(ASs)で住んでいる相互AS L2VPNシナリオです、そして、それはすべてのコントロール交通が2つのネットワークの間で交換したMD5-キーへの現在の習慣です。 MS-PWはプロバイダーに自由民主党のセッションのためにちょうど2つのドメインをつなげるPW切り換えポイントにMD5の主要な管理を閉じ込めさせます。
-iv. PSN Interworking: PWE3 signaling protocols and PSN types may
differ in different provider networks. The terminating PEs
may be connected to networks employing different PW signaling
and/or PSN protocols. In this case, it is not possible to use
an SS-PW. An MS-PW with the appropriate interworking
performed at the PW switching points can enable PW
connectivity between the terminating PEs in this scenario.
-iv。 PSNの織り込むこと: PWE3シグナリングプロトコルとPSNタイプは異なったプロバイダーネットワークにおいて異なるかもしれません。 終わっているPEsは異なったPWシグナリング、そして/または、PSNプロトコルを使うネットワークに接続されるかもしれません。 この場合、SS-PWを使用するのは可能ではありません。 適切な織り込むことがPW切り換えポイントで実行されているMS-PWはこのシナリオの終わっているPEsの間のPWの接続性を可能にすることができます。
Bitar, et al. Informational [Page 7] RFC 5254 Requirements for Multi-Segment PWE3 October 2008
Bitar、他 マルチセグメントPWE3 October 2008のための情報[7ページ]のRFC5254要件
-v. Traffic Engineered PSN Tunnels and bandwidth-managed PWs:
There is a requirement to deploy PWs edge to edge in large
service provider networks. Such networks typically encompass
hundreds or thousands of aggregation devices at the edge, each
of which would be a PE. Furthermore, there is a requirement
that these PWs have explicit bandwidth guarantees. To satisfy
these requirements, the PWs will be tunneled over PSN
TE-tunnels with bandwidth constraints. A single-segment
pseudowire architecture would require that a full mesh of PSN
TE-tunnels be provisioned to allow PWs to be established
between all PEs. Inter-provider PWs riding traffic engineered
tunnels further add to the number of tunnels that would have
to be supported by the PEs and the core network as the total
number of PEs increases.
-v。 交通のEngineered PSN Tunnelsと帯域幅で管理されたPWs: 大きいサービスプロバイダーネットワークを差しはさむためにPWs縁を配備するという要件があります。 そのようなネットワークは数百か縁の何千台もの集合装置を通常取り囲みます。それはそれぞれPEでしょう。 その上、これらのPWsには明白な帯域幅保証があるという要件があります。 これらの要件を満たすために、PWsは帯域幅があるPSN TE-トンネルの上のトンネルを堀られた規制でしょう。 ただ一つのセグメントpseudowire構造は、PSN TE-トンネルの完全なメッシュがPWsがすべてのPEsの間に設立されるのを許容するために食糧を供給されるのを必要とするでしょう。 トンネルで、より遠くに設計された交通に乗る相互プロバイダーPWsがPEsの総数が増加するのに従ってPEsとコアネットワークによって支えられなければならないトンネルの数に加えます。
In this environment, there is a requirement either to support
a sparse mesh of PSN TE-tunnels and PW signaling adjacencies,
or to partition the network into a number of smaller PWE3
domains. In either case, a PW would have to pass through more
than one PSN tunnel hop along its path. An objective is to
reduce the number of tunnels that must be supported, and thus
the complexity and scalability problem that may arise.
この環境には、PSN TE-トンネルとPWシグナリング隣接番組のまばらなメッシュを支えるか、または多くの、より小さいPWE3ドメインにネットワークを仕切るために、要件があります。 どちらの場合ではも、PWは経路に沿った1つ以上のPSNトンネルホップを通り抜けなければならないでしょう。 目的は、支えなければならないトンネルの数を減少させて、その結果、起こるかもしれない複雑さとスケーラビリティ問題を減少させることです。
-vi. Pseudowires in access/metro networks: Service providers wish
to extend PW technology to access and metro networks in order
to reduce maintenance complexity and operational costs.
Today's access and metro networks are either legacy (Time
Division Multiplexed (TDM), Synchronous Optical
Network/Synchronous Digital Hierarchy (SONET/SDH), or Frame
Relay/Asynchronous Transfer Mode (ATM)), Ethernet, or IP
based.
-vi。 アクセス/地下鉄におけるPseudowiresは以下をネットワークでつなぎます。 サービスプロバイダーは、維持の複雑さと運用コストを下げるためにアクセスするPW技術と地下鉄ネットワークを広げたがっています。 今日のアクセスと地下鉄ネットワークは、基づく遺産(時間事業部Multiplexed(TDM)、同期式光通信網/同期デジタルハイアラーキ(Sonet/SDH)、またはFrame Relay/非同期なTransfer Mode(ATM))、イーサネットかIPのどちらかです。
Due to these architectures, circuits (e.g., Ethernet Virtual
Circuits (EVCs), ATM VCs, TDM circuits) in the access/metro
are traditionally handled as attachment circuits, in their
native format, to the edge of the IP-MPLS network where the PW
starts. This combination requires multiple separate access
networks and complicates end-to-end control, provisioning, and
maintenance. In addition, when a TDM or SONET/SDH access
network is replaced with a packet-based infrastructure,
expenses may be lowered due to moving statistical multiplexing
closer to the end-user and converging multiple services onto a
single access network.
これらの構造のため、アクセス/地下鉄のサーキット(例えば、イーサネットVirtual Circuits(EVCs)、ATM VCs、TDMサーキット)は付属サーキットとして伝統的に扱われます、それらのネイティブの形式で、PWが始まるIP-MPLSネットワークの縁に。 この組み合わせは、複数の別々のアクセスネットワークを必要として、終わりからエンドへのコントロール、食糧を供給すること、および維持を複雑にします。 TDMかSonet/SDHアクセスネットワークをパケットベースのインフラストラクチャに取り替えるとき、エンドユーザの、より近くに多重送信して、複数のサービスをシングルアクセスネットワークに一点に集めながら統計的に動くため、さらに、費用を下げるかもしれません。
Access networks have a number of properties that impact the
application of PWs. For example, there exist access
mechanisms where the PSN is not of an IETF specified type, but
uses mechanisms compatible with those of PWE3 at the PW layer.
アクセスネットワークには、PWsのアプリケーションに影響を与える多くの特性があります。 例えば、アクセス機構はPSNによる指定されたIETFではタイプしてくださいが、PWのPWE3のものがあるメカニズムコンパチブル用途が層にされるということでないところに存在しています。
Bitar, et al. Informational [Page 8] RFC 5254 Requirements for Multi-Segment PWE3 October 2008
Bitar、他 マルチセグメントPWE3 October 2008のための情報[8ページ]のRFC5254要件
Here, use case (iv) may apply. In addition, many networks
consist of hundreds or thousands of access devices. There is
therefore a desire to support a sparse mesh of PW signaling
adjacencies and PSN tunnels. Use case (v) may therefore
apply. Finally, access networks also tend to differ from core
networks in that the access PW setup and maintenance mechanism
may only be a subset of that used in the core.
ここで、(iv)が適用するかもしれないケースを使用してください。 さらに、多くのネットワークが数百か何千台ものアクセス装置から成ります。 したがって、PWシグナリング隣接番組とPSNトンネルのまばらなメッシュを支える願望があります。 したがって(v)が適用するかもしれないケースを使用してください。 また、最終的に、アクセスネットワークは、アクセスPWセットアップと維持メカニズムがコアで使用されるその部分集合であるにすぎないかもしれないという点においてコアネットワークと異なっている傾向があります。
Using the MS-PWs, access and metro network elements need only
maintain PW signaling adjacencies with the PEs to which they
directly connect. They do not need PW signaling adjacencies
with every other access and metro network device. PEs in the
PSN backbone, in turn, maintain PW signaling adjacencies among
each other. In addition, a PSN tunnel is set up between an
access element and the PE to which it connects. Another PSN
tunnel needs to be established between every PE pair in the
PSN backbone. An MS-PW may be set up from one access network
element to another access element with three segments: (1)
access-element - PSN-PE, (2) PSN-PE to PSN-PE, and (3) PSN-PE
to access element. In this MS-PW setup, access elements are
T-PEs while PSN-PEs are S-PEs. It should be noted that the
PSN backbone can be also segmented into PWE3 domains resulting
in more segments per PW.
MS-PWs、アクセス、および地下鉄ネットワーク要素を使用すると、彼らが直接接続するPEsと共に隣接番組に合図するPWは維持されるだけでよいです。 彼らはあらゆる他のアクセスと地下鉄ネットワーク装置で隣接番組に合図するPWを必要としません。 PSN背骨のPEsは互いの中で順番にPWシグナリング隣接番組を維持します。 さらに、PSNトンネルはアクセス要素とそれが接続するPEの間でセットアップされます。 別のPSNトンネルは、すべてのPE組の間にPSN背骨に設立される必要があります。 MS-PWは3つのセグメントで1つのアクセスネットワーク要素から別のアクセス要素までセットアップされるかもしれません: (1) アクセス要素--PSN-PE、PSN-PEへの(2)PSN-PE、および要素にアクセスする(3)PSN-PE。 このMS-PWセットアップで、PSN-PEsはS-PEsですが、アクセス要素はT-PEsです。 また、PSN背骨をより多くの1PWあたりのセグメントをもたらすPWE3ドメインに区分できることに注意されるべきです。
3.1. Multi-Segment Pseudowire Setup Mechanisms
3.1. マルチセグメントPseudowireセットアップメカニズム
This requirements document assumes that the above use cases are realized using one or more of the following mechanisms:
上記がケースを使用するというドキュメントが仮定するこの要件は以下のメカニズムの1つ以上を使用することで実現されます:
-i. Static Configuration: The switching points (S-PEs), in
addition to the T-PEs, are manually provisioned for each
segment.
-i。 静的な構成: T-PEsに加えて、切り換えポイント(S-PEs)は各セグメントのために手動で食糧を供給されます。
-ii. Pre-Determined Route: The PW is established along an
administratively determined route using an end-to-end
signaling protocol with automated stitching at the S-PEs.
-ii。 予定されたルート: PWは、行政上決定しているルートに沿ってS-PEsでの自動化されたステッチと共に終わりから終わりへのシグナリングプロトコルを使用することで設立されます。
-iii. Signaled Dynamic Route: The PW is established along a
dynamically determined route using an end-to-end signaling
protocol with automated stitching at the S-PEs. The route is
selected with the aid of one or more dynamic routing
protocols.
-iii。 合図されたダイナミックなルート: PWは、ダイナミックに決定しているルートに沿ってS-PEsでの自動化されたステッチと共に終わりから終わりへのシグナリングプロトコルを使用することで設立されます。 ルートは1つ以上のダイナミックルーティングプロトコルの援助で選択されます。
Note that we define the PW route to be the set of S-PEs through which an MS-PW will pass between a given pair of T-PEs. PSN tunnels along that route can be explicitly specified or locally selected at the S-PEs and T-PEs. The routing of the PSN tunnels themselves is outside the scope of the requirements specified in this document.
私たちがMS-PWが与えられた組のT-PEsの間を通るS-PEsのセットになるようにPWルートを定義することに注意してください。 そのルートに沿ったPSNトンネルを明らかに指定するか、またはS-PEsとT-PEsで局所的に選択できます。 本書では指定された要件の範囲の外にPSNトンネル自体のルーティングがあります。
Bitar, et al. Informational [Page 9] RFC 5254 Requirements for Multi-Segment PWE3 October 2008
Bitar、他 マルチセグメントPWE3 October 2008のための情報[9ページ]のRFC5254要件
4. Multi-Segment Pseudowire Requirements
4. マルチセグメントPseudowire要件
The following sections detail the requirements that the above use cases put on the MS-PW setup mechanisms.
以下のセクションは上記がMS-PWセットアップメカニズムに置かれたケースを使用するという要件を詳しく述べます。
4.1. All Mechanisms
4.1. すべてのメカニズム
The following generic requirements apply to the three MS-PW setup mechanisms defined in the previous section.
以下の一般的な要件は前項で定義された3つのMS-PWセットアップメカニズムに適用されます。
4.1.1. Architecture
4.1.1. 構造
-i. If MS-PWs are tunneled across a PSN that only supports SS-PWs,
then only the requirements of [RFC3916] apply to that PSN.
The fact that the overlay is carrying MS-PWs MUST be
transparent to the routers in the PSN.
-i。 MS-PWsがSS-PWsを支持するだけであるPSNの向こう側にトンネルを堀られるなら、[RFC3916]の要件だけがそのPSNに適用されます。 オーバレイがMS-PWsを運ぶという事実はPSNのルータに見え透いているに違いありません。
-ii. The PWs MUST remain transparent to the P-routers. A P-router
is not an S-PE or an T-PE from the MS-PW architecture
viewpoint. P-routers provide transparent PSN transport for
PWs and MUST not have any knowledge of the PWs traversing
them.
-ii。 PWsはP-ルータに透明なままで残らなければなりません。 P-ルータは、MS-PW構造観点からのS-PEでなくて、またT-PEでもありません。 P-ルータは、わかりやすいPSN輸送をPWsに供給して、彼らを横断するPWsに関する少しの知識も持ってはいけません。
-iii. The MS-PWs MUST use the same encapsulation modes specified for
SS-PWs.
-iii。 MS-PWsはSS-PWsに指定された同じカプセル化モードを使用しなければなりません。
-iv. The MS-PWs MUST be composed of SS-PWs.
-iv。 SS-PWsでMS-PWsを構成しなければなりません。
-v. An MS-PW MUST be able to pass across PSNs of all technologies
supported by PWE3 for SS-PWs. When crossing from one PSN
technology to another, an S-PE must provide the necessary PSN
interworking functions in that case.
-v。 さん-PW MUST、SS-PWsのためにPWE3によって支持されたすべての技術のPSNsの向こう側に通ることができてください。 1つのPSN技術から別の技術まで交差するとき、S-PEはその場合機能を織り込む必要なPSNを提供しなければなりません。
-vi. Both directions of a PW segment MUST terminate on the same
S-PE/T-PE.
-vi。 PWセグメントの両方の指示は同じS-PE/T-PEで終わらなければなりません。
-vii. S-PEs MAY only support switching PWs of the same PW type. In
this case, the PW type is transparent to the S-PE in the
forwarding plane, except for functions needed to provide for
interworking between different PSN technologies.
-vii。 S-PEsは、同じPWタイプのPWsを切り換えるのを支持するだけであるかもしれません。 この場合、PWタイプは推進飛行機のS-PEに見え透いています、異なったPSN技術の間の織り込むことに備えるのに必要である機能を除いて。
-viii. Solutions MAY provide a way to prioritize the setup and
maintenance process among PWs.
-viii。 ソリューションはPWsの中でセットアップと維持の過程を最優先させる方法を提供するかもしれません。
Bitar, et al. Informational [Page 10] RFC 5254 Requirements for Multi-Segment PWE3 October 2008
Bitar、他 マルチセグメントPWE3 October 2008のための情報[10ページ]のRFC5254要件
4.1.2. Resiliency
4.1.2. 弾性
Mechanisms to protect an MS-PW when an element on the existing path of an MS-PW fails MUST be provided. These mechanisms will depend on the MS-PW setup. The following are the generic resiliency requirements that apply to all MS-PW setup mechanisms:
MS-PWの既存の経路の要素が失敗すると、MS-PWを保護するメカニズムを提供しなければなりません。 これらのメカニズムはMS-PWセットアップによるでしょう。 ↓これはすべてのMS-PWセットアップメカニズムに適用される一般的な弾性要件です:
-i. Configuration and establishment of a backup PW to a primary PW
SHOULD be supported. Mechanisms to perform a switchover from
a primary PW to a backup PW upon failure detection SHOULD be
provided.
-i。 aの構成と設立は第一のPW SHOULDにPWのバックアップをとります。支持されます。 第一のPWからaまでの転換を実行するメカニズムはPWのバックアップをとります。失敗検出SHOULDのときに、提供します。
-ii. The ability to configure an end-to-end backup PW path for a
primary PW path SHOULD be supported. The primary and backup
paths may be statically configured, statically specified for
signaling, or dynamically selected via dynamic routing
depending on the MS-PW establishment mechanism. Backup and
primary paths should have the ability to traverse separate
S-PEs. The backup path MAY be signaled at configuration time
or after failure.
-ii。 終わりから端へのバックアップPW第一のPW経路SHOULDへの道が支持されるのを構成する能力。 MS-PW設立メカニズムによって、予備選挙とバックアップ道は、静的に構成されるか、静的にシグナリングに指定されるか、またはダイナミックルーティングでダイナミックに選択されるかもしれません。 バックアップと第一の経路には、別々のS-PEsを横断する能力があるべきです。 バックアップ道は構成時か失敗の後に合図されるかもしれません。
-iii. The ability to configure a primary PW and a backup PW with a
different T-PE from the primary SHOULD be supported.
-iii。 支持される第一のSHOULDと異なったT-PEで第一のPWとバックアップPWを構成する能力。
-iv. Automatic Mechanisms to perform a fast switchover from a
primary PW to a backup PW upon failure detection SHOULD be
provided.
-iv。 速い第一のPWからaまでの転換を実行する自動MechanismsはPWのバックアップをとります。失敗検出SHOULDのときに、提供します。
-v. A mechanism to automatically revert to a primary PW from a
backup PW MAY be provided. When provided, it MUST be
configurable.
-v。 aから第一のPWに自動的に戻るメカニズムはPW MAYのバックアップをとります。提供します。 提供すると、それは構成可能であるに違いありません。
4.1.3. Quality of Service
4.1.3. サービスの質
Pseudowires are intended to support emulated services (e.g., TDM and ATM) that may have strict per-connection quality-of-service (QoS) requirements. This may include either absolute or relative guarantees on packet loss, delay, and jitter. These guarantees are, in part, delivered by reserving sufficient network resources (e.g., bandwidth), and by providing appropriate per-packet treatment (e.g., scheduling priority and drop precedence) throughout the network.
Pseudowiresが1接続あたりの厳しいサービスの質(QoS)要件を持っているかもしれない見習われたサービス(例えば、TDMとATM)を支持することを意図します。 これはパケット損失、遅れ、およびジターにおける絶対の、または、相対的な保証を含むかもしれません。 これらの保証は、十分なネットワーク資源(例えば、帯域幅)を予約して、1パケットあたりの適切な処理(例えば、スケジューリング優先権と低下先行)をネットワークに提供することによって、一部渡されます。
For SS-PWs, a traffic engineered PSN tunnel (i.e., MPLS-TE) may be used to ensure that sufficient resources are reserved in the P-routers to provide QoS to PWs on the tunnel. In this case, T-PEs MUST have the ability to automatically request the PSN tunnel resources in the direction of traffic (e.g., admission control of PWs onto the PSN tunnel and accounting for reserved bandwidth and
SS-PWsに関しては、交通の設計されたPSNトンネル(すなわち、MPLS-TE)は、十分なリソースがトンネルの上のPWsにQoSを供給するためにP-ルータで予約されるのを保証するのに使用されるかもしれません。 そしてこの場合、T-PEsには交通の向きに自動的にPSNトンネルリソースを要求する能力がなければならない、(例えば、PSNトンネルへのPWsの入場コントロールと予約された帯域幅のための会計。
Bitar, et al. Informational [Page 11] RFC 5254 Requirements for Multi-Segment PWE3 October 2008
Bitar、他 マルチセグメントPWE3 October 2008のための情報[11ページ]のRFC5254要件
available bandwidth on the tunnel). In cases where the tunnel supports multiple classes of service (CoS) (e.g., E-LSP), bandwidth management is required per CoS.
トンネルにおける利用可能な帯域幅) トンネルが複数のクラスのサービス(CoS)を支持する場合で (例えば、電子LSP), 帯域幅管理がCoS単位で必要です。
For MS-PWs, each S-PE maps a PW segment to a PSN tunnel. Solutions MUST enable S-PEs and T-PEs to automatically bind a PW segment to a PSN tunnel based on CoS and bandwidth requirements when these attributes are specified for a PW. Solutions SHOULD also provide the capability of binding a PW segment to a tunnel as a matter of policy configuration. S-PEs and T-PEs must be capable of automatically requesting PSN tunnel resources per CoS.
MS-PWsに関しては、各S-PEはPWセグメントをPSNトンネルに写像します。 ソリューションは、S-PEsとT-PEsが自動的にこれらの属性がPWに指定されるときCoSと帯域幅要件に基づくPSNトンネルにPWセグメントを縛るのを可能にしなければなりません。 また、ソリューションSHOULDは方針構成の問題としてPWセグメントをトンネルに縛る能力を提供します。 S-PEsとT-PEsは自動的に1CoSあたりのPSNトンネルリソースを要求できなければなりません。
S-PEs and T-PEs MUST be able to associate a CoS marking (e.g., EXP field value for MPLS PWs) with PW PDUs. CoS marking in the PW PDUs affects packet treatment. The CoS marking depends on the PSN technology. Thus, solutions must enable the configuration of necessary mapping for CoS marking when the MS-PW crosses from one PSN technology to another. Similarly, different administrative domains may use different CoS values to imply the same CoS treatment. Solutions MUST provide the ability to define CoS marking maps on S-PEs at administrative domain boundaries to translate from one CoS value to another as a PW PDU crosses from one domain to the next.
S-PEsとT-PEsはPW PDUsと共に(例えば、MPLS PWsのためのEXP分野価値)をマークするCoSを関連づけることができなければなりません。 PW PDUsでのCoSマークはパケット処理に影響します。 CoSマークはPSN技術によります。 1つのPSN技術から別の技術までのMS-PW十字であるときに、したがって、解決策はCoSマークのために必要なマッピングの構成を可能にしなければなりません。 同様に、異なった管理ドメインは、同じCoS処理を含意するのに異なったCoS値を使用するかもしれません。 ソリューションはPW PDUが1つのドメインから次まで交差するとき1つのCoS値から別の値まで翻訳するために管理ドメイン境界のS-PEsに地図にマークするCoSを定義する能力を提供しなければなりません。
[RFC3985] requires PWs to respond to path congestion by reducing their transmission rate. Alternatively, RFC 3985 permits PWs that do not have a congestion control mechanism to transmit using explicitly reserved capacity along a provisioned path. Because MS-PWs are a type of PW, this requirement extends to them as well. RFC 3985 applied to MS-PWs consequently requires that MS-PWs employ a congestion control mechanism that is effective across an MS path, or requires an explicit provisioning action that reserves sufficient capacity in all domains along the MS path before the MS-PW begins transmission. S-PEs are therefore REQUIRED to reject attempts to establish MS-PW segments for PW types that either do not utilize an appropriate congestion control scheme or when resources that are sufficient to support the transmission rate of the PW cannot be reserved along the path.
[RFC3985]は、PWsが彼らの通信速度を減少させることによって経路混雑に応じるのを必要とします。 あるいはまた、RFC3985は、混雑制御機構を持っていないPWsが伝わるのを食糧を供給された経路に沿って明らかに予約された容量を使用することで可能にします。 MS-PWsが一種のPWであるので、また、この要件は彼らに達します。 MS-PWsに適用されたRFC3985はその結果、MS-PWsがMS経路の向こう側に有効な混雑制御機構を使うのが必要である、またはMS-PWがトランスミッションを始める前にMS経路に沿ったすべてのドメインで十分な容量を予約する明白な食糧を供給する動作を必要とします。 したがって、S-PEsは適切な混雑を利用しないPWタイプが計画を制御できないか、経路に沿ってPWの通信速度を支持するために十分なリソースを予約できないときMS-PWセグメントを確立する試みを拒絶するREQUIREDです。
4.1.4. Congestion Control
4.1.4. 輻輳制御
[RFC3985] requires all PWs to respond to congestion, in order to conform to [RFC2914]. In the absence of a well-defined congestion control mechanism, [RFC3985] permits PWs to be carried across paths that have been provisioned such that the traffic caused by PWs has no harmful effect on concurrent traffic that shares the path, even under congestion. These requirements extend to the MS-PWs defined in this document.
[RFC3985]は、[RFC2914]に従うためにすべてのPWsが混雑に応じるのを必要とします。 明確な混雑制御機構がないとき[RFC3985]が、PWsが食糧を供給された経路の向こう側に運ばれることを許可するので、PWsによって引き起こされた交通は経路を共有する同時発生の交通にどんな有害な影響も与えません、混雑でさえ。 これらの要件はこれで定義されたMS-PWsドキュメントに達します。
Bitar, et al. Informational [Page 12] RFC 5254 Requirements for Multi-Segment PWE3 October 2008
Bitar、他 マルチセグメントPWE3 October 2008のための情報[12ページ]のRFC5254要件
Path provisioning is frequently performed through QoS reservation protocols or network management protocols. In the case of SS-PWs, which remain within a single administrative domain, a number of existing protocols can provide this provisioning functionality. MS- PWs, however, may transmit across network domains that are under the control of multiple entities. QoS provisioning across such paths is inherently more difficult, due to the required inter-domain interactions. It is important to note that these difficulties do not invalidate the requirement to provision path capacity for MS-PW use. Each domain MUST individually implement a method to control congestion. This can be by QoS reservation, or other congestion control method. MS-PWs MUST NOT transmit across unprovisioned, best effort, paths in the absence of other congestion control schemes, as required by [RFC3985].
経路の食糧を供給することはQoS予約プロトコルかネットワーク管理プロトコルを通して頻繁に実行されます。 SS-PWsの場合では、多くの既存のプロトコルが、機能性に食糧を供給しながら、これを提供できます。(SS-PWsはただ一つの管理ドメインに残っています)。 しかしながら、MS PWsは複数の実体のコントロールの下にあるネットワークドメインの向こう側に伝わるかもしれません。 そのようなものの向こう側に経路に食糧を供給するQoSは本来必要な相互ドメイン相互作用のために、より難しいです。 これらの困難がMS-PW使用のために支給経路容量に要件を無効にしないことに注意するのは重要です。 各ドメインは個別に混雑を制御する方法を実行しなければなりません。 これはQoSの予約、または他の輻輳制御方法であることができます。 MS-PWsはコントロールが必要に応じて[RFC3985]で計画する他の混雑がないとき非食糧を供給されて、ベストエフォート型の経路の向こう側に伝わってはいけません。
Solutions MUST enable S-PEs and T-PEs on the path of an MS-PW to notify other S-PEs and T-PEs on that path of congestion, when it occurs. Congestion may be indicated by queue length, packet loss rate, or bandwidth measurement (among others) crossing a respective threshold. The action taken by a T-PE that receives a notification of congestion along the path of one of its PWs could be to re-route the MS-PW to an alternative path, including an alternative T-PE if available. If a PE, or an S-PE has knowledge that a particular link or tunnel is experiencing congestion, it MUST not set up any new MS-PW that utilize that link or tunnel. Some PW types, such as TDM PWs, are more sensitive to congestion than others. The reaction to a congestion notification MAY vary per PW type.
ソリューションは、MS-PWの経路のS-PEsとT-PEsが混雑のその経路の他のS-PEsとT-PEsに通知するのを可能にしなければなりません、起こると。 混雑は、それぞれの敷居に交差しながら、待ち行列の長さ、パケット損失率、または(特に)の帯域幅測定で示されるかもしれません。 PWsの1つの経路に沿って混雑の通知を受け取るT-PEによって取られた行動はMS-PWを迂回経路に別ルートで送ることであることができました、利用可能であるなら代替のT-PEを含んでいて。 PE、またはS-PEがそうしたなら、事項がリンクするか、またはトンネルを堀るという知識は混雑になっていて、それはそのリンクかトンネルを利用する少しの新しいMS-PWもセットアップしてはいけません。 TDM PWsなどのPWタイプの中には他のものより混雑に敏感な人もいます。 混雑通知への反応はPWタイプ単位で異なるかもしれません。
4.1.5. Additional Generic Requirements for MS-PW Setup Mechanisms
4.1.5. MS-PWセットアップメカニズムのための追加一般的な要件
The MS-PW setup mechanisms MUST accommodate the service provider's practices, especially in relation to security, confidentiality of SP information, and traffic engineering. Security and confidentiality are especially important when the MS-PWs are set up across autonomous systems in different administrative domains. The following are generic requirements that apply to the three MS-PW setup mechanisms defined earlier:
MS-PWセットアップメカニズムはサービスプロバイダーの習慣を収容しなければなりません、特にセキュリティ、SP情報の秘密性、および交通工学と関連して。 MS-PWsが異なった管理ドメインの自律システムの向こう側に用意ができているとき、セキュリティと秘密性は特に重要です。 ↓これは、より早く定義された3つのMS-PWセットアップメカニズムに適用される一般的な要件です:
-i. The ability to statically select S-PEs and PSN tunnels on a PW
path MUST be provided. Static selection of S-PEs is by
definition a requirement for the static configuration and
signaled/static route setup mechanisms. This requirement
satisfies the need for forcing an MS-PW to traverse specific
S-PEs to enforce service provider security and administrative
policies.
-i。 静的にPW経路のS-PEsとPSNトンネルを選択する能力を提供しなければなりません。 S-PEsの静的な品揃えは定義上静的な構成と合図された/スタティックルートセットアップメカニズムのための要件です。この要件はサービスプロバイダーセキュリティと施政方針を実施するMS-PWに特定のS-PEsを横断させる需要を満たします。
-ii. Solutions SHOULD minimize the amount of configuration needed
to set up an MS-PW.
-ii。 ソリューションSHOULDはMS-PWをセットアップするのに必要である構成の量を最小にします。
Bitar, et al. Informational [Page 13] RFC 5254 Requirements for Multi-Segment PWE3 October 2008
Bitar、他 マルチセグメントPWE3 October 2008のための情報[13ページ]のRFC5254要件
-iii. Solutions should support different PW setup mechanisms on the
same T-PE, S-PE, and PSN network.
-iii。 ソリューションは同じT-PE、S-PE、およびPSNの上のメカニズムがネットワークでつなぐ異なったPWセットアップを支持するべきです。
-iv. Solutions MUST allow T-PEs to simultaneously support use of
SS-PW signaling mechanisms as specified in [RFC4447], as well
as MS-PW signaling mechanisms.
-iv。 T-PEsは同時にソリューションで[RFC4447]の指定されるとしてのSS-PWシグナル伝達機構の使用を支持できなければなりません、MS-PWシグナル伝達機構と同様に。
-v. Solutions MUST ensure that an MS-PW will be set up when a path
that satisfies the PW constraints for bandwidth, CoS, and
other possible attributes does exist in the network.
-v。 ソリューションは、帯域幅、CoS、および他の可能な属性のPW規制を満たす経路がネットワークで存在するとき、MS-PWがセットアップされるのを確実にしなければなりません。
-vi. Solutions must clearly define the setup procedures for each
mechanism so that an MS-PW setup on T-PEs can be interpreted
as successful only when all PW segments are successfully set
up.
-vi。 すべてのPWセグメントが首尾よくセットアップされるときだけ、うまくいくとT-PEsにおけるMS-PWセットアップを解釈できて、ソリューションは各メカニズムのために明確にセットアップ手順を定義しなければなりません。
-vii. Admission control to the PSN tunnel needs to be performed
against available resources, when applicable. This process
MUST be performed at each PW segment comprising the MS-PW. PW
admission control into a PSN tunnel MUST be configurable.
-vii。 適切であるときに、PSNトンネルへの入場コントロールは、利用可能資源に対して実行される必要があります。 MS-PWを包括するそれぞれのPWセグメントでこの過程を実行しなければなりません。 PSNトンネルへのPW入場コントロールは構成可能であるに違いありません。
-viii. In case the PSN tunnel lacks the resources necessary to
accommodate the new PW, an attempt to signal a new PSN tunnel,
or increase the capacity of the existing PSN tunnel MAY be
made. If the expanded PSN tunnel fails to set up, the PW MUST
fail to set up.
-viii。 PSNトンネルが欠けているといけないので、新しいPW、新しいPSNトンネルに合図する試み、または既存のPSNトンネルの容量の増加に対応するのに必要なリソースは作られているかもしれません。 拡張PSNトンネルがセットアップしないなら、PW MUSTはセットアップしません。
-ix. The setup mechanisms must allow the setup of a PW segment
between two directly connected S-PEs without the existence of
a PSN tunnel. This requirement allows a PW segment to be set
up between two (Autonomous System Border Routers (ASBRs) when
the MS-PW crosses AS boundaries without the need for
configuring and setting up a PSN tunnel. In this case,
admission control must be done, when enabled, on the link
between the S-PEs.
-ix。 セットアップメカニズムはPSNトンネルの存在なしで2直接接続されたS-PEsの間のPWセグメントのセットアップを許さなければなりません。 (この場合入場コントロールをしなければなりません、可能にされると、S-PEsの間のリンクの上に。この要件は、PWセグメントが2の間でセットアップされるのを許容します。MS-PWであるときに、自治のSystem Border Routers(ASBRs)はPSNトンネルを構成して、設立する必要性なしでAS境界に交差しています。
4.1.6. Routing
4.1.6. ルート設定
An objective of MS-PWs is to provide support for the following connectivity:
MS-PWsの目的は以下の接続性のサポートを提供することです:
-i. MS-PWs MUST be able to traverse multiple service provider
administrative domains.
-i。 MS-PWsは複数のサービスプロバイダーの管理ドメインを横断できなければなりません。
-ii. MS-PWs MUST be able to traverse multiple autonomous systems
within the same administrative domain.
-ii。 MS-PWsは同じ管理ドメインの中の複数の自律システムを横断できなければなりません。
Bitar, et al. Informational [Page 14] RFC 5254 Requirements for Multi-Segment PWE3 October 2008
Bitar、他 マルチセグメントPWE3 October 2008のための情報[14ページ]のRFC5254要件
-iii. MS-PWs MUST be able to traverse multiple autonomous systems
belonging to different administrative domains.
-iii。 MS-PWsは異なった管理ドメインに属す複数の自律システムを横断できなければなりません。
-iv. MS-PWs MUST be able to support any hybrid combination of the
aforementioned connectivity scenarios, including both PW
transit and termination in a domain.
-iv。 MS-PWsは前述の接続性シナリオのどんなハイブリッド組み合わせもサポートできなければなりません、ドメインにPWトランジットと終了の両方を含んでいて。
4.2. Statically Configured MS-PWs
4.2. 静的に構成されたMS-PWs
When the MS-PW segments are statically configured, the following requirements apply in addition to the generic requirements previously defined.
MS-PWセグメントが静的に構成されるとき、以下の要件は以前に定義された一般的な要件に加えて適用されます。
4.2.1. Architecture
4.2.1. 構造
There are no additional requirements on the architecture.
構造に関するどんな追加要件もありません。
4.2.2. MPLS-PWs
4.2.2. MPLS-PWs
Solutions should allow for the static configuration of MPLS labels for MPLS-PW segments and the cross-connection of these labels to preceding and succeeding segments. This is especially useful when an MS-PW crosses provider boundaries and two providers do not want to run any PW signaling protocol between them. A T-PE or S-PE that allows the configuration of static labels for MS-PW segments should also simultaneously allow for dynamic label assignments for other MS-PW segments. It should be noted that when two interconnected S-PEs do not have signaling peering for the purpose of setting up MS-PW segments, they should have in-band PW Operations and Maintenance (OAM) capabilities that relay PW or attachment circuit defect notifications between the adjacent S-PEs.
ソリューションはMPLS-PWセグメントのためのMPLSラベルの静的な構成と先行と続くセグメントへのこれらのラベルの交差接続を考慮するべきです。 MS-PWがプロバイダー限界に交差して、2つのプロバイダーがそれらの間のどんなPWシグナリングプロトコルも走らせたがっていないとき、これは特に役に立ちます。 また、MS-PWセグメントのための静的なラベルの構成を許すT-PEかS-PEが同時に、他のMS-PWセグメントのためのダイナミックなラベル課題を考慮するはずです。 2インタコネクトされたS-PEsにMS-PWセグメントをセットアップする目的のためにじっと見るシグナリングがないとき、隣接しているS-PEsの間にPWをリレーするバンドにおけるPW OperationsとMaintenance(OAM)能力か付属サーキット欠陥通知を持つべきであることに注意されるべきです。
4.2.3. Resiliency
4.2.3. 弾性
The solution should allow for the protection of a PW segment, a contiguous set of PW segments, as well as the end-to-end path. The primary and protection segments must share the same segment endpoints. Solutions should allow for having the backup paths set up prior to the failure or as a result of failure. The choice should be made by configuration. When resources are limited and cannot satisfy all PWs, the PWs with the higher setup priorities should be given preference when compared with the setup priorities of other PWs being set up or the holding priorities of existing PWs.
解決策はPWセグメントの保護を考慮するべきです、隣接のセットのPW区分、終わりから端への経路と同様に。 予備選挙と保護セグメントは同じセグメント終点を共有しなければなりません。 ソリューションは、失敗の前か失敗の結果、バックアップ道をセットアップさせると考慮するべきです。 構成で選択をするべきです。 リソースが限られていて、すべてのPWs(プライオリティが与えられた好みかセットアップされる他のPWsのセットアッププライオリティと比べると存在する把持プライオリティがPWsであるならそうするより高いセットアップがあるPWs)を満たすことができるというわけではないなら
Solutions should strive to minimize traffic loss between T-PEs.
ソリューションは、T-PEsの間の交通の損失を最小にするように努力するべきです。
Bitar, et al. Informational [Page 15] RFC 5254 Requirements for Multi-Segment PWE3 October 2008
Bitar、他 マルチセグメントPWE3 October 2008のための情報[15ページ]のRFC5254要件
4.2.4. Quality of Service
4.2.4. サービスの質
The CoS and bandwidth of the MS-PW must be configurable at T-PEs and S-PEs.
MS-PWのCoSと帯域幅はT-PEsとS-PEsで構成可能であるに違いありません。
4.3. Signaled PW Segments
4.3. 合図されたPWセグメント
When the MS-PW segments are dynamically signaled, the following requirements apply in addition to the generic requirements previously defined. The signaled MS-PW segments can be on the path of a statically configured MS-PW, signaled/statically routed MS-PW, or signaled/dynamically routed MS-PW.
MS-PWセグメントがダイナミックに合図されるとき、以下の要件は以前に定義された一般的な要件に加えて適用されます。 合図されたMS-PWセグメントが静的に構成されたMS-PWの経路にあることができます、と静的に発送された/MS-PWは合図したか、または合図されて、/がダイナミックにMS-PWを発送しました。
There are four different mechanisms that are defined to setup SS-PWs:
SS-PWsをセットアップするために定義される4つの異なったメカニズムがあります:
-i. Static set up of the SS-PW (MPLS or L2TPv3 forwarding)
-i。 SS-PWについてセットアップされた静電気(MPLSかL2TPv3推進)
-ii. LDP using PWid Forwarding Equivalence Class (FEC) 128
-ii。 同値類(FEC)128を進めながらPWidを使用する自由民主党
-iii. LDP using the generalized PW FEC 129
-iii。 一般化されたPW FEC129を使用する自由民主党
-iv. L2TPv3
-iv。 L2TPv3
The MS-PW setup mechanism MUST be able to support PW segments signaled with any of the above protocols; however, the specification of which combinations of SS-PW signaling protocols are supported by a specific implementation is outside the scope of this document.
MS-PWセットアップメカニズムは上のプロトコルのいずれでも合図されたPWセグメントを支持できなければなりません。 しかしながら、このドキュメントの範囲の外にSS-PWシグナリングプロトコルの組み合わせが特定の実現でサポートされる仕様があります。
For the signaled/statically routed and signaled/dynamically routed MS-PW setup mechanisms, the following requirements apply in addition to the generic requirements previously defined.
/が静的に発送して、合図した合図に関しては、/はダイナミックにMS-PWセットアップメカニズムを発送して、以下の要件は以前に定義された一般的な要件に加えて適用されます。
4.3.1. Architecture
4.3.1. 構造
There are no additional requirements on the architecture.
構造に関するどんな追加要件もありません。
4.3.2. Resiliency
4.3.2. 弾性
Solutions should allow for the signaling of a protection path for a PW segment, sequence of segments, or end-to-end path. The protection and primary paths for the protected segment(s) share the same respective segments endpoints. When admission control is enabled, systems must be careful not to double account for bandwidth allocation at merged points (e.g., tunnels). Solutions should allow for having the backup paths set up prior to the failure or as a result of failure. The choice should be made by configuration at the endpoints of the protected path. When resources are limited and cannot satisfy all PWs, the PWs with the higher setup priorities
ソリューションはPWセグメント、セグメントの系列、または終わりから端への経路に保護経路のシグナリングを考慮するべきです。 保護されたセグメントのための保護と第一の経路は同じそれぞれのセグメント終点を共有します。 入場コントロールが可能にされるとき、システムは、合併しているポイント(例えば、トンネル)での帯域幅配分のためのアカウントを倍にしないように慎重でなければなりません。 ソリューションは、失敗の前か失敗の結果、バックアップ道をセットアップさせると考慮するべきです。 保護された経路の終点での構成で選択をするべきです。 リソースが限られていて、より高いセットアッププライオリティにPWs、すべてのPWsを満たすことができるというわけではないなら
Bitar, et al. Informational [Page 16] RFC 5254 Requirements for Multi-Segment PWE3 October 2008
Bitar、他 マルチセグメントPWE3 October 2008のための情報[16ページ]のRFC5254要件
should be given preference when compared with the setup priorities of other PWs being set up or the holding priorities of existing PWs. Procedures must allow for the primary and backup paths to be diverse.
セットアップされる他のPWsのセットアッププライオリティか既存のPWsの把持プライオリティと比べると、優先を与えるべきです。 手順は、予備選挙とバックアップ道がさまざまであることを許容しなければなりません。
4.3.3. Quality of Service
4.3.3. サービスの質
When the T-PE attempts to signal an MS-PW, the following capability is required:
T-PEが、MS-PWに合図するのを試みると、以下の能力が必要です:
-i. Signaling must be able to identify the CoS associated with an
MS-PW.
-i。 シグナリングはMS-PWに関連しているCoSを特定できなければなりません。
-ii. Signaling must be able to carry the traffic parameters for an
MS-PW per CoS. Traffic parameters should be based on existing
INTSERV definitions and must be used for admission control
when admission control is enabled.
-ii。 シグナリングは1CoSあたり1MS-PWのための交通パラメタを運ぶことができなければなりません。 交通パラメタは既存のINTSERV定義に基づくべきであり、入場コントロールが可能にされるとき、入場コントロールに使用しなければなりません。
-iii. The PW signaling MUST enable separate traffic parameter values
to be specified for the forward and reverse directions of the
PW.
-iii。 PWシグナリングは、別々の交通パラメタ値がPWの前進の、そして、反対の方向に指定されるのを可能にしなければなりません。
-iv. PW traffic parameter representations MUST be the same for all
types of MS-PWs.
-iv。 MS-PWsのすべてのタイプに、PW交通パラメタ表現は同じであるに違いありません。
-v. The signaling protocol must be able to accommodate a method to
prioritize the PW setup and maintenance operation among PWs.
-v。 シグナリングプロトコルはPWsの中でPWセットアップと維持操作を最優先させる方法に対応できなければなりません。
4.3.4. Routing
4.3.4. ルート設定
See the requirements for "Resiliency" above.
上記を「弾性」のための要件見てください。
4.3.5. Additional Requirements on Signaled MS-PW Setup Mechanisms
4.3.5. 合図されたMS-PWセットアップメカニズムに関する追加要件
The following are further requirements on signaled MS-PW setup mechanisms:
↓これは合図されたMS-PWセットアップメカニズムに関するさらなる要件です:
-i. The signaling procedures MUST be defined such that the setup
of an MS-PW is considered successful if all segments of the
MS-PW are successfully set up.
-i。 シグナリング手順を定義しなければならないので、MS-PWのすべてのセグメントが首尾よくセットアップされるなら、MS-PWのセットアップはうまくいくと考えられます。
-ii. The MS-PW path MUST have the ability to be dynamically set up
between the T-PEs by provisioning only the T-PEs.
-ii。 MS-PW経路には、T-PEsの間でダイナミックにセットアップされるべき能力が、T-PEsだけに食糧を供給することによって、なければなりません。
Bitar, et al. Informational [Page 17] RFC 5254 Requirements for Multi-Segment PWE3 October 2008
Bitar、他 マルチセグメントPWE3 October 2008のための情報[17ページ]のRFC5254要件
-iii. Dynamic MS-PW setup requires that a unique identifier be
associated with a PW and be carried in the signaling message.
That identifier must contain sufficient information to
determine the path to the remote T-PE through intermediate
S-PEs.
-iii。 ダイナミックなMS-PWセットアップは、ユニークな識別子がPWに関連していて、シグナリングメッセージで運ばれるのを必要とします。 その識別子は中間的S-PEsを通してリモートT-PEに経路を決定できるくらいの情報を含まなければなりません。
-iv. In a single-provider domain, it is natural to have the T-PE
identified by one of its IP addresses. This may also apply
when an MS-PW is set up across multiple domains operated by
the same provider. However, some service providers have
security and confidentiality policies that prevent them from
advertising reachability to routers in their networks to other
providers (reachability to an ASBR is an exception). Thus,
procedures MUST be provided to allow dynamic set up of MS-PWs
under these conditions.
-iv。 ただ一つのプロバイダードメインでは、IPアドレスの1つでT-PEを特定させるのは当然です。 また、MS-PWが同じプロバイダーによって操作された複数のドメインの向こう側にセットアップされるとき、これは適用されるかもしれません。 しかしながら、いくつかのサービスプロバイダーには、それらのネットワークで他のプロバイダーにそれらを広告の可到達性からルータまで防ぐセキュリティと秘密性方針があります(ASBRへの可到達性は例外です)。 したがって、これらの条件でMS-PWsを上がっているダイナミックなセットを許容するために手順を提供しなければなりません。
4.4. Signaled PW / Dynamic Route
4.4. 合図されたPW/動力ルート
The following requirements apply, in addition to those in Sections 4.1 and 4.3, when both dynamic signaling and dynamic routing are used.
以下の要件は適用されます、セクション4.1と4.3におけるそれらに加えて、ダイナミックなシグナリングとダイナミックルーティングの両方が使用されているとき。
4.4.1. Architecture
4.4.1. 構造
There are no additional architectural requirements.
どんな追加建築要件もありません。
4.4.2. Resiliency
4.4.2. 弾性
The PW routing function MUST support dynamic re-routing around failure points when segments are set up using the dynamic setup method.
セグメントがセットアップされるとき、ダイナミックなセットアップ方法を使用して、PW経路選択機能は失敗ポイントの周りのダイナミックなコースを変更することを支持しなければなりません。
4.4.3. Quality of Service
4.4.3. サービスの質
There are no additional QoS requirements.
どんな追加QoS要件もありません。
4.4.4. Routing
4.4.4. ルート設定
The following are requirements associated with dynamic route selection for an MS-PW:
↓これはMS-PWのためのダイナミックなルート選択に関連している要件です:
-i. Routing must enable S-PEs and T-PEs to discover S-PEs on the
path to a destination T-PE.
-i。 ルート設定は、S-PEsとT-PEsが目的地T-PEにおいて経路のS-PEsを発見するのを可能にしなければなりません。
-ii. The MS-PW routing function MUST have the ability to
automatically select the S-PEs along the MS-PW path. Some of
the S-PEs MAY be statically selected and carried in the
signaling to constrain the route selection process.
-ii。 MS-PW経路選択機能に、MS-PW経路に沿って自動的にS-PEsを選択する能力がなければなりません。 いくつかのS-PEsが、ルート選択の過程を抑制するために静的に選択されて、シグナリングで運ばれるかもしれません。
Bitar, et al. Informational [Page 18] RFC 5254 Requirements for Multi-Segment PWE3 October 2008
Bitar、他 マルチセグメントPWE3 October 2008のための情報[18ページ]のRFC5254要件
-iii. The PW routing function MUST support re-routing around
failures that occur between the statically configured segment
endpoints. This may be done by choosing another PSN tunnel
between the two segment endpoints or setting up an alternative
tunnel.
-iii。 PW経路選択機能は、静的に構成されたセグメント終点の間に起こる失敗の周りでコースを変更するのを支持しなければなりません。 2つのセグメント終点の間の別のPSNトンネルを選ぶか、または代替のトンネルを設立することによって、これをするかもしれません。
-iv. Routing protocols must be able to advertise reachability
information of attachment circuit (AC) endpoints. This
reachability information must be consistent with the AC
identifiers carried in signaling.
-iv。 ルーティング・プロトコルは付属サーキット(西暦)終点の可到達性情報の広告を出すことができなければなりません。 この可到達性情報はシグナリングで運ばれる交流識別子と一致しているに違いありません。
5. Operations and Maintenance (OAM)
5. 操作と維持(OAM)
OAM mechanisms for the attachment circuits are defined in the specifications for PW emulated specific technologies (e.g., ITU-T I.610 [i610] for ATM). These mechanisms enable, among other things, defects in the network to be detected, localized, and diagnosed. They also enable communication of PW defect states on the PW attachment circuit. Note that this document uses the term OAM as Operations and Management as per ITU-T I.610.
付属サーキットがPWのための仕様に基づき定義されるので、OAMメカニズムは独自技術(例えば、ATMのためのITU-T I.610[i610])を見習いました。 これらのメカニズムは、特にネットワークにおける欠陥が検出されて、局所化されて、診断されるのを可能にします。 また、彼らはPW付属サーキットの上のPW欠陥州に関するコミュニケーションを可能にします。 このドキュメントがITU-T I.610に従ってOperationsとManagementとしてOAMという用語を使用することに注意してください。
The interworking of OAM mechanisms for SS-PWs between ACs and PWs is defined in [PWE3-OAM]. These enable defect states to be propagated across a PWE3 network following the failure and recovery from faults.
ACsとPWsの間のSS-PWsのためのOAMメカニズムを織り込むことは[PWE3-OAM]で定義されます。 欠点からの失敗と回復に続いて、これらは、欠陥州がPWE3ネットワークの向こう側に伝播されるのを可能にします。
OAM mechanisms for MS-PWs MUST provide at least the same capabilities as those for SS-PWs. In addition, it should be possible to support both segment and end-to-end OAM mechanisms for both defect notifications and connectivity verification in order to allow defects to be localized in a multi-segment network. That is, PW OAM segments can be T-PE to T-PE, T-PE to S-PE, or S-PE to S-PE.
MS-PWsのためのOAMメカニズムは少なくともSS-PWsのためのそれらと同じ能力を提供しなければなりません。 さらに、欠陥通知と接続性検証の両方のためにセグメントと終わりから終わりへのOAM両方のメカニズムをサポートするのは、欠陥がマルチセグメント・ネットワークで局所化されるのを許容するために可能であるべきです。 すなわち、PW OAMセグメントは、T-PEへのT-PE、S-PEへのT-PE、またはS-PEへのS-PEであるかもしれません。
The following requirements apply to OAM for MS-PWs:
以下の要件はMS-PWsのためにOAMに申し込まれます:
-i. Mechanisms for PW segment failure detection and notification
to other segments of an MS-PW MUST be provided.
-i。 PWのためのメカニズムは失敗検出と通知をさん-PW MUSTの他のセグメントに区分します。提供します。
-ii. MS-PW OAM SHOULD be supported end-to-end across the network.
-ii。 さん-PW OAM SHOULD、支持されたネットワークの向こう側の終わりから終わりになってください。
-iii. Single ended monitoring SHOULD be supported for both
directions of the MS-PW.
-iii。 SHOULDをモニターしながら、シングルを終わらせました。MS-PWの両方の指示には、支持されてください。
-iv. SS-PW OAM mechanisms (e.g., [RFC5085]) SHOULD be extended to
support MS-PWs on both an end-to-end basis and segment basis.
-iv。 SS-PW OAMメカニズム(例えば、[RFC5085])SHOULDは両方のサポートMS-PWs終わらせる終わりの基礎に広げられて、基礎を区分します。
-v. All PE routers along the MS-PW MUST agree on a common PW OAM
mechanism to use for the MS-PW.
-v。 さん-PW MUSTに沿ったすべてのPEルータがMS-PWに使用する一般的なPW OAMメカニズムに同意します。
Bitar, et al. Informational [Page 19] RFC 5254 Requirements for Multi-Segment PWE3 October 2008
Bitar、他 マルチセグメントPWE3 October 2008のための情報[19ページ]のRFC5254要件
-vi. At the S-PE, defects on an PSN tunnel MUST be propagated to
all PWs that utilize that particular PSN tunnel.
-vi。 S-PEでは、その特定のPSNトンネルを利用するすべてのPWsにPSNトンネルの上の欠陥を伝播しなければなりません。
-vii. The directionality of defect notifications MUST be maintained
across the S-PE.
-vii。 S-PEの向こう側に欠陥通知の方向性を維持しなければなりません。
-viii. The S-PE SHOULD be able to behave as a segment endpoint for PW
OAM mechanisms.
-viii。 S-PE SHOULD、PW OAMメカニズムのためのセグメント終点として振る舞うことができてください。
-ix. The S-PE MUST be able to pass T-PE to T-PE PW OAM messages
transparently.
-ix。 S-PE MUST、透明にT-PE PW OAMメッセージにT-PEを渡すことができてください。
-x. Performance OAM is required for both MS-PWs and SS-PWs to
measure round-trip delay, one-way delay, jitter, and packet
loss ratio.
-x。 MS-PWsとSS-PWsの両方がパフォーマンスOAMが往復の遅れ、片道遅れ、ジター、およびパケット損害率を測定しなければなりません。
6. Management of Multi-Segment Pseudowires
6. マルチセグメントPseudowiresの管理
Each PWE3 approach that uses MS-PWs SHOULD provide some mechanisms for network operators to manage the emulated service. Management mechanisms for MS-PWs MUST provide at least the same capabilities as those for SS-PWs, as defined in [RFC3916].
ネットワーク・オペレータが見習われたサービスを管理するように、MS-PWs SHOULDを使用するそれぞれのPWE3アプローチはいくつかのメカニズムを提供します。 MS-PWsのための管理メカニズムは[RFC3916]で定義されるように少なくともSS-PWsのためのそれらと同じ能力を提供しなければなりません。
It SHOULD also be possible to manage the additional attributes for MS-PWs. Since the operator that initiates the establishment of an MS-PW may reside in a different PSN domain from the S-PEs and one of the T-PEs along the path of the MS-PW, mechanisms for the remote management of the MS-PW SHOULD be provided.
それ、SHOULD、また、MS-PWsのために追加属性を管理するのにおいて可能であってください。 MS-PWの設立を開始するオペレータが異なったPSNドメインに住むかもしれないので、S-PEsとMS-PWの経路に沿ったT-PEsの1つ、さん-PW SHOULDのリモート管理のためのメカニズムから、提供してください。
The following additional requirements apply:
以下の追加要件は適用されます:
6.1. MIB Requirements
6.1. MIB要件
-i. MIB Tables MUST be designed to facilitate configuration and
provisioning of the MS-PW at the S-PEs and T-PEs.
-i。 S-PEsとT-PEsでMS-PWの構成と食糧を供給することを容易にするようにMIB Tablesを設計しなければなりません。
-ii. The MIB(s) MUST facilitate inter-PSN configuration and
monitoring of the ACs.
-ii。 MIB(s)はACsの相互PSN構成とモニターを容易にしなければなりません。
Bitar, et al. Informational [Page 20] RFC 5254 Requirements for Multi-Segment PWE3 October 2008
Bitar、他 マルチセグメントPWE3 October 2008のための情報[20ページ]のRFC5254要件
6.2. Management Interface Requirements
6.2. 管理インターフェース要件
-i. Mechanisms MUST be provided to enable remote management of an
MS-PW at an S-PE or T-PE. It SHOULD be possible for these
mechanisms to operate across PSN domains. An example of a
commonly available mechanism is the command line interface
(CLI) over a telnet session.
-i。 S-PEかT-PEでMS-PWのリモート管理を可能にするためにメカニズムを提供しなければなりません。 それ、SHOULD、これらのメカニズムがPSNドメインの向こう側に動作するのにおいて、可能であってください。 telnetセッションの間、一般的に利用可能なメカニズムに関する例はコマンドラインインタフェース(CLI)です。
-ii. For security or other reasons, it SHOULD be possible to
disable the remote management of an MS-PW.
-ii。 何らかのセキュリティは推論して、それはSHOULDです。MS-PWのリモート管理を無効にするのにおいて、可能であってください。
7. Security Considerations
7. セキュリティ問題
This document specifies the requirements both for MS-PWs that can be set up across domain boundaries administered by one or more service providers (inter-provider MS-PWs), and for MS-PWs that are only set up across one provider (intra-provider MS-PWs).
このドキュメントは1つ以上のサービスプロバイダー(相互プロバイダーMS-PWs)によって管理されたドメイン境界の向こう側にセットアップできるMS-PWs、および1つのプロバイダー(イントラプロバイダーMS-PWs)の向こう側にセットアップされるだけであるMS-PWsのための要件を指定します。
7.1. Inter-Provider MS-PWs
7.1. 相互プロバイダーMS-PWs
The security requirements for MS-PW setup across domains administered by one service provider are the same as those described under security considerations in [RFC4447] and [RFC3916]. These requirements also apply to inter-provider MS-PWs.
1つのサービスプロバイダーによって管理されたドメイン中のMS-PWセットアップのためのセキュリティ要件はものが[RFC4447]と[RFC3916]のセキュリティ問題の下で説明したのと同じです。 また、これらの要件は相互プロバイダーMS-PWsに適用されます。
In addition, [RFC4111] identifies user and provider requirements for L2 VPNs that apply to MS-PWs described in this document. In this section, the focus is on the additional security requirements for inter-provider operation of MS-PWs in both the control plane and data plane, and some of these requirements may overlap with those in [RFC4111].
さらに、[RFC4111]は本書では説明されたMS-PWsに適用するL2 VPNsのためにユーザとプロバイダー要件を特定します。 このセクションに、焦点が制御飛行機とデータ飛行機とこれらの要件のいくつかの両方でのMS-PWsの操作が[RFC4111]のそれらに重ね合わせるかもしれない相互プロバイダーのための追加担保要件にあります。
7.1.1. Data-Plane Security Requirements
7.1.1. データ飛行機セキュリティ要件
By security in the "data plane", we mean protection against the following possibilities:
「データ飛行機」のセキュリティで、私たちは以下の可能性に対する保護を言っています:
-i. Packets from within an MS-PW traveling to a PE or an AC to
which the PW is not intended to be connected, other than in a
manner consistent with the policies of the MS-PW.
-i。 PEに旅行するMS-PWかPWが接続されることを意図しない西暦からのMS-PWの方針と一致した方法以外のパケット。
-ii. Packets from outside an MS-PW entering the MS-PW, other than
in a manner consistent with the policies of the MS-PW.
-ii。 MS-PWの外からのMS-PWの方針があるMS-PWの、そして、方法を除いて、一貫したパケットの入ること。
MS-PWs that cross service provider (SP) domain boundaries may connect one T-PE in a SP domain to a T-PE in another provider domain. They may also transit other provider domains even if the two T-PEs are under the control of one SP. Under these scenarios, there is a
サービスプロバイダー(SP)ドメイン境界に交差するMS-PWsはSPドメインの1T-PEを別のプロバイダードメインのT-PEに接続するかもしれません。 また、2T-PEsが、あるSPのコントロールの下にあっても、彼らは他のプロバイダードメインを通過するかもしれません。 これらのシナリオの下では、aがあります。
Bitar, et al. Informational [Page 21] RFC 5254 Requirements for Multi-Segment PWE3 October 2008
Bitar、他 マルチセグメントPWE3 October 2008のための情報[21ページ]のRFC5254要件
chance that one or more PDUs could be falsely inserted into an MS-PW at any of the originating, terminating, or transit domains. Such false injection can be the result of a malicious attack or fault in the S-PE. Solutions MAY provide mechanisms for ensuring the end-to-end authenticity of MS-PW PDUs.
間違って由来、終わり、またはトランジットドメインのどれかのMS-PWに1PDUsを挿入できたやってみてください。 そのような偽の注射はS-PEの悪意ある攻撃か欠点の結果であるかもしれません。 ソリューションはMS-PW PDUsの終わりから終わりへの信憑性を確実にするのにメカニズムを提供するかもしれません。
The data plane security requirements at a service provider border for MS-PWs are similar to those for inter-provider BGP/MPLS IP Virtual Private Networks [RFC4364]. In particular, an S-PE or T-PE SHOULD discard a packet received from a particular neighbor over the service provider border unless one of the following two conditions holds:
相互プロバイダーBGP/MPLS IP Virtual兵士のNetworks[RFC4364]に、MS-PWsのためのサービスプロバイダー境界のデータ飛行機セキュリティ要件はそれらと同様です。 特に以下の2つの条件の1つが持ちこたえない場合パケットがサービスプロバイダー境界の上の特定の隣人から受けたS-PEかT-PE SHOULD破棄:
-i. Any MPLS label processed at the receiving S-PE or T-PE, such
the PSN tunnel label or the PW label has a label value that
the receiving system has distributed to that neighbor; or
-i。 そのようなS-PE、T-PE、PSNトンネルラベルまたはPWがラベルする受信のときに処理されたどんなMPLSラベルも受電方式がその隣人に分配したラベル値を持っています。 または
-ii. Any MPLS label processed at the receiving S-PE or T-PE, such
as the PSN tunnel label or the PW label has a label value that
the receiving S-PE or T-PE has previously distributed to the
peer S-PE or T-PE beyond that neighbor (i.e., when it is known
that the path from the system to which the label was
distributed to the receiving system is via that neighbor).
-ii。 PSNトンネルなどのS-PEかT-PEがラベルするか、またはPWがラベルする受信のときに処理されたどんなMPLSラベルも受信S-PEかT-PEが以前にその隣人で同輩S-PEかT-PEに分配したラベル値を持っています(すなわち、いつその隣人を通してラベルが分配されたシステムから受電方式までの経路があるのが知られていますか)。
One of the domains crossed by an MS-PW may decide to selectively mirror the PDUs of an MS-PW for eavesdropping purposes. It may also decide to selectively hijack the PDUs of an MS-PW by directing the PDUs away from their destination. In either case, the privacy of an MS-PW can be violated.
MS-PWによって交差されたドメインのひとりは、雨垂れの目的のために選択的にMS-PWのPDUsを映すと決めるかもしれません。 また、それは、彼らの目的地から遠くでPDUsを指示することによって選択的にMS-PWのPDUsをハイジャックすると決めるかもしれません。 どちらの場合ではも、MS-PWのプライバシーに違反できます。
Some types of PWs make assumptions about the security of the underlying PSN. The minimal security provided by an MPLS PSN might not be sufficient to meet the security requirements expected by the applications using the MS-PW. This document does not place any requirements on protecting the privacy of an MS-PW PDU via encryption. However, encryption may be required at a higher layer in the protocol stack, based on the application or network requirements.
PWsのタイプの中には基本的なPSNのセキュリティに関する仮定をする人もいます。 MPLS PSNによって提供された最小量のセキュリティは、MS-PWを使用しながらアプリケーションで予想されたセキュリティ必要条件を満たすために十分でないかもしれません。 このドキュメントは暗号化でMS-PW PDUのプライバシーを保護するのにどんな要件も置きません。 しかしながら、暗号化がアプリケーションかネットワーク要件に基づいてプロトコル・スタックの、より高い層で必要であるかもしれません。
The data plane of an S-PE at a domain boundary MUST be able to police incoming MS-PW traffic to the MS-PW traffic parameters or to an administratively configured profile. The option to enable/disable policing MUST be provided to the network administrator. This is to ensure that an MS-PW or a group of MS-PWs do not grab more resources than they are allocated. In addition, the data plane of an S-PE MUST be able to police OAM messages to a pre-configured traffic profile or to filter out these messages upon administrative configuration.
ドメイン境界のS-PEのデータ飛行機はMS-PW交通パラメタ、または、行政上構成されたプロフィールへの入って来るMS-PW交通を取り締まることができなければなりません。 取り締まりを可能にするか、または無能にするオプションをネットワーク管理者に提供しなければなりません。 これは、MS-PWかMS-PWsのグループがそれらを割り当てるより多くのリソースをつかまないのを保証するためのものです。 さらに、データを平らにします。S-PE MUSTでは、あらかじめ設定された交通プロフィールまでOAMメッセージを取り締まるか、または管理構成に関するこれらのメッセージを無視できてください。
Bitar, et al. Informational [Page 22] RFC 5254 Requirements for Multi-Segment PWE3 October 2008
Bitar、他 マルチセグメントPWE3 October 2008のための情報[22ページ]のRFC5254要件
An ingress S-PE MUST ensure that an MS-PW receives the CoS treatment configured or signaled for that MS-PW at the S-PE. Specifically, an S-PE MUST guard against packets marked in the exp bits or IP-header Differentiated Services (DS) field (depending on the PSN) for a better CoS than they should receive.
S-PE MUSTがS-PEでそのそれのために処理が構成したCoSを受けるか、または合図されたMS-PW MS-PWを確実にするイングレス。 明確に、彼らより良いCoSのためにexpビットかIP-ヘッダーDifferentiated Services(DS)分野(PSNによる)でマークされたパケットに対するS-PE MUST護衛は受信するべきです。
An ingress S-PE MUST be able to define per-interface or interface-group (a group may correspond to interfaces to a peer- provider) label space for MPLS-PWs. An S-PE MUST be configurable not to accept labeled packets from another provider unless the bottom label is a PW-label assigned by the S-PE on the interface on which the packet arrived.
イングレスS-PE MUSTはインタフェースを定義できるか、またはグループを連結します(グループは同輩プロバイダーへのインタフェースに一致するかもしれません)。MPLS-PWsのためのラベルスペース。 S-PE MUST、化粧紙がパケットが到着したインタフェースのS-PEによって割り当てられたPW-ラベルでないなら別のプロバイダーからラベルされたパケットを受け入れないのにおいて、構成可能であってください。
Data plane security considerations for SS-PWs specified in [RFC3985] also apply to MS-PWs.
また、[RFC3985]で指定されたSS-PWsのためのデータ飛行機セキュリティ問題はMS-PWsに適用されます。
7.1.2. Control-Plane Security Requirements
7.1.2. 制御飛行機セキュリティ要件
An MS-PW connects two attachment circuits. It is important to make sure that PW connections are not arbitrarily accepted from anywhere, or else a local attachment circuit might get connected to an arbitrary remote attachment circuit. The fault in the connection can start at a remote T-PE or an S-PE.
MS-PWは2個の付属サーキットをつなげます。 PW接続が任意にどこからも受け入れられないのを確実にするのが重要であるか、または地方の付属サーキットは任意の遠く離れた付属サーキットに関連づけられるかもしれません。 接続における欠点はリモートT-PEかS-PEで始まることができます。
Where a PW segment crosses a border between one provider and another provider, the PW segment endpoints (S-PEs) SHOULD be on ASBRs interconnecting the two providers. Directly interconnecting the S-PEs using a physically secure link, and enabling signaling and routing authentication between the S-PEs, eliminates the possibility of receiving an MS-PW signaling message or packet from an untrusted peer. Other configurations are possible. For example, P routers for the PSN tunnel between the adjacent S-PEs/T-PEs may reside on the ASBRs. In which case, the S-PEs/T-PEs MUST satisfy themselves of the security and privacy of the path.
PWセグメントが1つのプロバイダーと別のプロバイダーとの境界を越えるところでは、PWセグメント終点(S-PEs)SHOULDは2つのプロバイダーとインタコネクトするASBRsで越えます。 肉体的に安全なリンクを使用することで直接S-PEsとインタコネクトして、S-PEsの間のシグナリングとルーティング認証を可能にすると、信頼されていない同輩からMS-PWシグナリングメッセージかパケットを受け取る可能性は排除されます。 他の構成は可能です。 例えば、隣接しているS-PEs/T-PEsの間のPSNトンネルへのPルータはASBRsにあるかもしれません。 その場合、S-PEs/T-PEsは満足しなければなりません。
The configuration and maintenance protocol MUST provide a strong authentication and control protocol data protection mechanism. This option MUST be implemented, but it should be deployed according to the specific PSN environment requirements. Furthermore, authentication using a signature for each individual MS-PW setup message MUST be available, in addition to an overall control protocol session authentication and message validation.
構成と維持プロトコルは強い認証と制御プロトコルデータ保護メカニズムを提供しなければなりません。 このオプションを実行しなければなりませんが、特定のPSN環境要件に従って、それは配備されるべきです。 その上、それぞれの個々のMS-PWセットアップメッセージに署名を使用する認証は利用可能であるに違いありません、総括経営プロトコルセッション認証とメッセージ合法化に加えて。
Since S-PEs in different provider networks SHOULD reside at each end of a physically secure link, or be interconnected by a limited number of trusted PSN tunnels, each S-PE will have a trust relationship with only a limited number of S-PEs in other ASs. Thus, it is expected that current security mechanisms based on manual key management will
異なったプロバイダーネットワークにおけるS-PEs以来、各S-PEには、SHOULDが肉体的に安全なリンクの各端に住んでいるか、または限られた数の信じられたPSNトンネルによってインタコネクトされて、他のASsのS-PEsの限られた数だけとの信用関係があるでしょう。 したがって、手動のかぎ管理に基づく現在のセキュリティー対策がそうすると予想されます。
Bitar, et al. Informational [Page 23] RFC 5254 Requirements for Multi-Segment PWE3 October 2008
Bitar、他 マルチセグメントPWE3 October 2008のための情報[23ページ]のRFC5254要件
be sufficient. If deployment situations arise that require large scale connection to S-PEs in other ASs, then a mechanism based on RFC 4107 [RFC4107] MUST be developed.
十分であってください。 他のASsのS-PEsに大規模接続を必要とする展開状況が起こるなら、RFC4107[RFC4107]に基づくメカニズムを開発しなければなりません。
Peer authentication protects against IP address spoofing but does not prevent one peer (S-PE or T-PE) from connecting to the wrong attachment circuit. Under a single administrative authority, this may be the result of a misconfiguration. When the MS-PW crosses multiple provider domains, this may be the result of a malicious act by a service provider or a security hole in that provider network. Static manual configuration of MS-PWs at S-PEs and T-PEs provides a greater degree of security. If an identification of both ends of an MS-PW is configured and carried in the signaling message, an S-PE can verify the signaling message against the configuration. To support dynamic signaling of MS-PWs, whereby only endpoints are provisioned and S-PEs are dynamically discovered, mechanisms SHOULD be provided to configure such information on a server and to use that information during a connection attempt for validation.
同輩認証は、IPアドレススプーフィングから守りますが、接続から間違った付属サーキットまで1人の同輩(S-PEかT-PE)を防ぎません。 ただ一つの職務権限の下では、これはmisconfigurationの結果であるかもしれません。 MS-PW十字であるときに、複数のプロバイダードメインであり、これはサービスプロバイダーによる悪意がある行為の結果であるかもしれませんかセキュリティがそのプロバイダーネットワークで掘られます。 S-PEsとT-PEsのMS-PWsの静的な手動の構成は、より大きい度のセキュリティを提供します。 MS-PWの両端の識別がシグナリングメッセージで構成されて、運ばれるなら、S-PEは構成に対してシグナリングメッセージについて確かめることができます。 メカニズムSHOULD、終点だけが食糧を供給されて、S-PEsがダイナミックに発見されるMS-PWsのダイナミックなシグナリングを支持するために、合法化に提供して、サーバのそのような情報を構成して、接続試みの間、その情報を使用してください。
An incoming MS-PW request/reply MUST NOT be accepted unless its IP source address is known to be the source of an "eligible" peer. An eligible peer is an S-PE or a T-PE with which the originating S-PE or T-PE has a trust relationship. The number of such trusted T-PEs or S-PEs is bounded and not anticipated to create a scaling issue for the control plane authentication mechanisms.
「適任」の同輩の源であることをIPソースアドレスを知らない場合、入って来るMS-PW要求/回答を受け入れてはいけません。 適任の同輩は、由来しているS-PEかT-PEには信用関係があるS-PEかT-PEです。 そのような信じられたT-PEsかS-PEsの数は、境界があって、制御飛行機認証機構のためにスケーリング問題を作成するために予期されません。
If a peering adjacency has to be established prior to exchanging setup requests/responses, peering MUST only be done with eligible peers. The set of eligible peers could be pre-configured (either as a list of IP addresses, or as a list of address/mask combinations) or automatically generated from the local PW configuration information.
セットアップ要求/応答を交換する前にじっと見る隣接番組を確立しなければならないなら、適任の同輩と共にじっと見ることをするだけでよいです。 適任の同輩のセットは、あらかじめ設定されたか(IPアドレスのリストとして、または、アドレス/マスク組み合わせのリストとして)、またはローカルのPW設定情報から自動的に発生できました。
Furthermore, the restriction of peering sessions to specific interfaces MUST also be provided. The S-PE and T-PE MUST drop the unaccepted signaling messages in the data path to avoid a Denial-of-Service (DoS) attack on the control plane.
その上、また、特定のインタフェースへのじっと見るセッションの制限を提供しなければなりません。 S-PEとT-PE MUSTは制御飛行機に対するサービスのDenial(DoS)攻撃を避けるデータ経路の非受諾されたシグナリングメッセージを落とします。
Even if a connection request appears to come from an eligible peer, its source address may have been spoofed. Thus, means of preventing source address spoofing must be in place. For example, if eligible peers are in the same network, source address filtering at the border routers of that network could eliminate the possibility of source address spoofing.
接続要求が適任の同輩から来るように見えても、ソースアドレスはだまされたかもしれません。 したがって、ソースアドレススプーフィングを防ぐ手段が適所にあるに違いありません。 例えば、同じネットワークに適任の同輩がいるなら、そのネットワークの境界ルータにおけるソースアドレスフィルタリングはソースアドレススプーフィングの可能性を排除するかもしれません。
Bitar, et al. Informational [Page 24] RFC 5254 Requirements for Multi-Segment PWE3 October 2008
Bitar、他 マルチセグメントPWE3 October 2008のための情報[24ページ]のRFC5254要件
S-PEs that connect one provider domain to another provider domain MUST have the capability to rate-limit signaling traffic in order to prevent DoS attacks on the control plane. Furthermore, detection and disposition of malformed packets and defense against various forms of attacks that can be protocol-specific MUST be provided.
別のプロバイダードメインに1つのプロバイダードメインをつなげるS-PEsは、制御飛行機に対するDoS攻撃を防ぐためにレート限界シグナリング交通に能力を持たなければなりません。 その上、様々な形式のプロトコル特有である場合がある攻撃に対する誤った形式のパケットとディフェンスの検出と気質を提供しなければなりません。
7.2. Intra-Provider MS-PWs
7.2. イントラプロバイダーMS-PWs
Security requirements for pseudowires are provided in [RFC3916]. These requirements also apply to MS-PWs.
pseudowiresのためのセキュリティ要件を[RFC3916]に提供します。 また、これらの要件はMS-PWsに適用されます。
MS-PWs are intended to enable many more PEs to provide PWE3 services in a given service provider network than traditional SS-PWs, particularly in access and metro environments where the PE may be situated closer to the ultimate endpoint of the service. In order to limit the impact of a compromise of one T-PE in a service provider network, the data path security requirements for inter-provider MS-PWs also apply to intra-provider MS-PWs in such cases.
伝統的なSS-PWsよりMS-PWsが、ずっと多くのPEsが与えられたサービスプロバイダーネットワークでサービスをPWE3に供給するのを可能にすることを意図します、特にPEが究極のサービスの終点の、より近くに位置するかもしれないアクセスと地下鉄環境で。 また、サービスプロバイダーネットワークにおける、1T-PEの妥協の影響を制限するために、相互プロバイダーMS-PWsのためのデータ経路セキュリティ要件はそのような場合イントラプロバイダーMS-PWsに申し込まれます。
8. Acknowledgments
8. 承認
The editors gratefully acknowledge the following contributors: Dimitri Papadimitriou (Alcatel-Lucent), Peter Busschbach (Alcatel-Lucent), Sasha Vainshtein (Axerra), Richard Spencer (British Telecom), Simon Delord (France Telecom), Deborah Brungard (AT&T), David McDysan (Verizon), Rahul Aggarwal (Juniper), Du Ke (ZTE), Cagatay Buyukkoc (ZTE), and Stewart Bryant (Cisco).
エディタは感謝して以下の貢献者を承認します: ディミトリPapadimitriou(アルカテル透明な)、ピーターBusschbach(アルカテル透明な)、サシャVainshtein(Axerra)、リチャード・スペンサー(ブリティッシュ・テレコム)、サイモンDelord(フランステレコム)、デボラBrungard(AT&T)、デヴィッドMcDysan(ベライゾン)、Rahul Aggarwal(杜松)、Du Ke(ZTE)、Cagatay Buyukkoc(ZTE)、およびスチュワートブライアント(シスコ)。
9. References
9. 参照
9.1. Normative References
9.1. 引用規格
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。
[RFC3916] Xiao, X., Ed., McPherson, D., Ed., and P. Pate, Ed.,
"Requirements for Pseudo-Wire Emulation Edge-to-Edge
(PWE3)", RFC 3916, September 2004.
そして、[RFC3916]Xiao、X.(エド)、マクファーソン、D.(エド)、P.頭(エド)、「疑似ワイヤエミュレーションのための要件は縁に斜めに進PWE3()」、RFC3916、2004年9月。
[RFC3985] Bryant, S., Ed., and P. Pate, Ed., "Pseudo Wire Emulation
Edge-to-Edge (PWE3) Architecture", RFC 3985, March 2005.
[RFC3985]ブライアント、S.、エド、P.頭、エド、「疑似ワイヤのエミュレーションの縁から縁(PWE3)への構造」、RFC3985、3月2005日
9.2. Informative References
9.2. 有益な参照
[i610] Recommendation I.610 "B-ISDN operation and maintenance
principles and functions", February 1999.
[i610]推薦I.610、「B-ISDN維持管理原則と機能」、2月1999日
Bitar, et al. Informational [Page 25] RFC 5254 Requirements for Multi-Segment PWE3 October 2008
Bitar、他 マルチセグメントPWE3 October 2008のための情報[25ページ]のRFC5254要件
[RFC5085] Nadeau, T., Ed., and C. Pignataro, Ed., "Pseudowire
Virtual Circuit Connectivity Verification (VCCV): A
Control Channel for Pseudowires", RFC 5085, December 2007.
[RFC5085]ナドー、T.、エド、C.Pignataro、エド、「Pseudowireの仮想のサーキット接続性検証(VCCV):」 「Pseudowiresの制御チャンネル」、RFC5085、2007年12月。
[RFC4447] Martini, L., Ed., Rosen, E., El-Aawar, N., Smith, T., and
G. Heron, "Pseudowire Setup and Maintenance Using the
Label Distribution Protocol (LDP)", RFC 4447, April 2006.
[RFC4447]マティーニ、L.(エド)、ローゼン、E.、高架鉄道-Aawar、N.、スミス、T.、およびG.サギ、「ラベル分配を使用するPseudowireセットアップと維持が(自由民主党)について議定書の中で述べます」、RFC4447、2006年4月。
[RFC4111] Fang, L., Ed., "Security Framework for Provider-
Provisioned Virtual Private Networks (PPVPNs)", RFC 4111,
July 2005.
[RFC4111] 牙、L.、エド、「プロバイダーのためのセキュリティフレームワークは仮想私設網(PPVPNs)に食糧を供給した」RFC4111、7月2005日
[PWE3-OAM] Nadeau, T., Ed., Morrow, M., Ed., Busschbach, P., Ed.,
Alissaoui, M.,Ed., D. Allen, Ed., "Pseudo Wire (PW) OAM
Message Mapping", Work in Progress, March 2005.
[PWE3-OAM]ナドー、T.(エド)、翌日、M.(エド)、Busschbach、P.(エド)、Alissaoui、M.(エド)、D.アレン(エド)「疑似ワイヤ(PW)OAMメッセージマッピング」というは進行中(2005年3月)で働いています。
[RFC2914] Floyd, S., "Congestion Control Principles", BCP 41, RFC
2914, September 2000.
[RFC2914]フロイド、S.、「輻輳制御プリンシプルズ」、BCP41、RFC2914、2000年9月。
[RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private
Networks (VPNs)", RFC 4364, February 2006.
[RFC4364]ローゼンとE.とY.Rekhter、「BGP/MPLS IP仮想私設網(VPNs)」、RFC4364 2006年2月。
[RFC4107] Bellovin, S. and R. Housley, "Guidelines for Cryptographic
Key Management", BCP 107, RFC 4107, June 2005.
[RFC4107]Bellovin、S.とR.Housley、「暗号化キー管理のためのガイドライン」BCP107、2005年6月のRFC4107。
Authors' Addresses
作者のアドレス
Nabil Bitar Verizon 117 West Street Waltham, MA 02145 EMail: nabil.n.bitar@verizon.com
ウォルサム、Nabil Bitarベライゾン117ウェスト・ストリートMA 02145はメールされます: nabil.n.bitar@verizon.com
Matthew Bocci Alcatel-Lucent Telecom Ltd, Voyager Place Shoppenhangers Road Maidenhead Berks, UK EMail: matthew.bocci@alcatel-lucent.co.uk
マシューのBocciのアルカテル透明な電子通信Ltd、旅行者場所Shoppenhangers道路Maidenheadバーク、イギリスのメール: matthew.bocci@alcatel-lucent.co.uk
Luca Martini Cisco Systems, Inc. 9155 East Nichols Avenue, Suite 400 Englewood, CO, 80112 EMail: lmartini@cisco.com
ルカマティーニシスコシステムズ, Inc.9155のEastニコルズAvenue、イングルウッド、Suite400CO 80112はメールされます: lmartini@cisco.com
Bitar, et al. Informational [Page 26] RFC 5254 Requirements for Multi-Segment PWE3 October 2008
Bitar、他 マルチセグメントPWE3 October 2008のための情報[26ページ]のRFC5254要件
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The IETF Trust (2008).
IETFが信じる著作権(C)(2008)。
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, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントとここに含まれた情報はその人が代理をするか、または(もしあれば)後援される組織、インターネットの振興発展を目的とする組織、「そのままで」という基礎と貢献者の上で提供していて、IETFはそして、インターネット・エンジニアリング・タスク・フォースがすべての保証を放棄すると信じます、急行である、または暗示していて、他を含んでいて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるということであるかいずれが市場性か特定目的への適合性の黙示的な保証です。
Intellectual Property
知的所有権
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFはどんな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に情報を記述してください。
Bitar, et al. Informational [Page 27]
Bitar、他 情報[27ページ]
一覧
スポンサーリンク
