RFC4447 日本語訳
4447 Pseudowire Setup and Maintenance Using the Label DistributionProtocol (LDP). L. Martini, Ed., E. Rosen, N. El-Aawar, T. Smith, G.Heron. April 2006. (Format: TXT=76204 bytes) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
Network Working Group L. Martini, Ed.
Request for Comments: 4447 E. Rosen
Category: Standards Track Cisco Systems, Inc.
N. El-Aawar
Level 3 Communications, LLC.
T. Smith
Network Appliance, Inc.
G. Heron
Tellabs
April 2006
エド、ワーキンググループL.マティーニをネットワークでつないでください。コメントのために以下を要求してください。 4447年のE.ローゼンカテゴリ: LLC、規格はシスコシステムズInc.N.高架鉄道-Aawarレベル3 コミュニケーションを追跡します。 T。 スミスネットアプライアンスInc.G.サギのTellabs2006年4月
Pseudowire Setup and Maintenance
Using the Label Distribution Protocol (LDP)
ラベル分配プロトコルを使用するPseudowireセットアップと維持(自由民主党)
Status of This Memo
このメモの状態
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (2006).
Copyright(C)インターネット協会(2006)。
Abstract
要約
Layer 2 services (such as Frame Relay, Asynchronous Transfer Mode, and Ethernet) can be "emulated" over an MPLS backbone by encapsulating the Layer 2 Protocol Data Units (PDU) and transmitting them over "pseudowires". It is also possible to use pseudowires to provide low-rate Time Division Multiplexed and a Synchronous Optical NETworking circuit emulation over an MPLS-enabled network. This document specifies a protocol for establishing and maintaining the pseudowires, using extensions to Label Distribution Protocol (LDP). Procedures for encapsulating Layer 2 PDUs are specified in a set of companion documents.
MPLS背骨の上でLayer2プロトコルData Units(PDU)を要約して、"pseudowires"の上に彼らを伝えることによって、層2のサービス(Frame Relayや、Asynchronous Transfer Modeや、イーサネットなどの)を「見習うことができます」。 また、低率Time事業部MultiplexedとSynchronous Optical NETworkingサーキットエミュレーションをMPLSによって可能にされたネットワークの上に提供するのにpseudowiresを使用するのも可能です。 このドキュメントはLabel Distributionプロトコル(自由民主党)に拡張子を使用して、pseudowiresを設立して、維持するのにプロトコルを指定します。 Layer2PDUsを要約するための手順は1セットの仲間ドキュメントで指定されます。
Martini, et al. Standards Track [Page 1] RFC 4447 PWE3 Using LDP April 2006
マティーニ、他 2006年4月に自由民主党を使用する標準化過程[1ページ]RFC4447PWE3
Table of Contents
目次
1. Introduction ....................................................3
2. Specification of Requirements ...................................5
3. The Pseudowire Label ............................................5
4. Details Specific to Particular Emulated Services ................7
4.1. IP Layer 2 Transport .......................................7
5. LDP .............................................................7
5.1. LDP Extensions .............................................8
5.2. The PWid FEC Element .......................................8
5.3. The Generalized PWid FEC Element ..........................10
5.3.1. Attachment Identifiers .............................11
5.3.2. Encoding the Generalized ID FEC Element ............13
5.3.2.1. Interface Parameters TLV ..................14
5.3.2.2. PW Grouping TLV ...........................14
5.3.3. Signaling Procedures ...............................15
5.4. Signaling of Pseudowire Status ............................16
5.4.1. Use of Label Mappings Messages .....................16
5.4.2. Signaling PW Status ................................17
5.4.3. Pseudowire Status Negotiation Procedures ...........18
5.5. Interface Parameters Sub-TLV ..............................19
6. Control Word ...................................................20
6.1. PW Types for Which the Control Word is REQUIRED ...........20
6.2. PW Types for Which the Control Word is NOT Mandatory ......21
6.3. LDP Label Withdrawal Procedures ...........................22
6.4. Sequencing Considerations .................................23
6.4.1. Label Advertisements ...............................23
6.4.2. Label Release ......................................24
7. IANA Considerations ............................................24
7.1. LDP TLV TYPE ..............................................24
7.2. LDP Status Codes ..........................................24
7.3. FEC Type Name Space .......................................25
8. Security Considerations ........................................25
8.1. Data-Plane Security .......................................25
8.2. Control-Plane Security ....................................26
9. Acknowledgements ...............................................27
10. Normative References ..........................................27
11. Informative References ........................................27
12. Additional Contributing Authors ...............................28
Appendix A. C-bit Handling Procedures Diagram .....................31
1. 序論…3 2. 要件の仕様…5 3. Pseudowireラベル…5 4. 特定に特定の詳細はサービスを見習いました…7 4.1. IP層2の輸送…7 5. 自由民主党…7 5.1. 自由民主党の拡大…8 5.2. PWid FEC要素…8 5.3. 一般化されたPWid FEC要素…10 5.3.1. 付属識別子…11 5.3.2. 一般化されたID FEC要素をコード化します…13 5.3.2.1. パラメタTLVを連結してください…14 5.3.2.2. PW組分けTLV…14 5.3.3. シグナリング手順…15 5.4. Pseudowire状態のシグナリング…16 5.4.1. ラベルマッピングメッセージの使用…16 5.4.2. シグナリングPW状態…17 5.4.3. Pseudowire状態交渉手順…18 5.5. パラメタサブTLVを連結してください…19 6. Wordを制御してください…20 6.1. Which Control WordのためのPW TypesはREQUIREDです…20 6.2. Which Control WordのためのPW TypesはMandatoryではありません…21 6.3. 自由民主党ラベル退出手順…22 6.4. 問題を配列します…23 6.4.1. 広告を分類してください…23 6.4.2. リリースを分類してください…24 7. IANA問題…24 7.1. 自由民主党TLVはタイプします…24 7.2. 自由民主党ステータスコード…24 7.3. FECは名前スペースをタイプします…25 8. セキュリティ問題…25 8.1. データ飛行機セキュリティ…25 8.2. 制御飛行機セキュリティ…26 9. 承認…27 10. 標準の参照…27 11. 有益な参照…27 12. 追加貢献している作者…28 手順が図解する付録A.C-ビット操作…31
Martini, et al. Standards Track [Page 2] RFC 4447 PWE3 Using LDP April 2006
マティーニ、他 2006年4月に自由民主党を使用する標準化過程[2ページ]RFC4447PWE3
1. Introduction
1. 序論
In [FRAME], [ATM], [PPPHDLC], and [ETH], it is explained how to encapsulate a Layer 2 Protocol Data Unit (PDU) for transmission over an MPLS-enabled network. Those documents specify that a "pseudowire header", consisting of a demultiplexor field, will be prepended to the encapsulated PDU. The pseudowire demultiplexor field is prepended before transmitting a packet on a pseudowire. When the packet arrives at the remote endpoint of the pseudowire, the demultiplexor is what enables the receiver to identify the particular pseudowire on which the packet has arrived. To transmit the packet from one pseudowire endpoint to another, the packet may need to travel through a "Packet Switched Network (PSN) tunnel"; this will require that an additional header be prepended to the packet.
[FRAME]、[ATM]、[PPPHDLC]、および[ETH]では、トランスミッションのために、どのように、Layer2プロトコルData Unit(PDU)をMPLSによって可能にされたネットワークの上に要約するかは説明されます。 それらのドキュメントは、「反-マルチプレクサー」分野から成って、「pseudowireヘッダー」が要約のPDUにprependedされると指定します。 pseudowireでパケットを伝える前に、pseudowire demultiplexor分野はprependedされます。 パケットがpseudowireの遠く離れた終点に到着すると、「反-マルチプレクサー」は受信機がパケットが到着した特定のpseudowireを特定するのを可能にするものです。 1つのpseudowire終点から別の終点までパケットを伝えるために、パケットは、「パケットSwitched Network(PSN)トンネル」を通って旅行する必要があるかもしれません。 これは、追加ヘッダーがパケットにprependedされるのを必要とするでしょう。
Accompanying documents [CEP, SAToP] specify methods for transporting time-division multiplexing (TDM) digital signals (TDM circuit emulation) over a packet-oriented MPLS-enabled network. The transmission system for circuit-oriented TDM signals is the Synchronous Optical Network (SONET)[SDH]/Synchronous Digital Hierarchy (SDH) [ITUG]. To support TDM traffic, which includes voice, data, and private leased-line service, the pseudowires must emulate the circuit characteristics of SONET/SDH payloads. The TDM signals and payloads are encapsulated for transmission over pseudowires. A pseudowire demultiplexor and a PSN tunnel header is prepended to this encapsulation.
添付書類[CEP、SAToP]はパケット指向のMPLSによって可能にされたネットワークの上で時分割多重化(TDM)ディジタル信号(TDMサーキットエミュレーション)を輸送するための方法を指定します。 サーキット指向のTDM信号の伝動装置は同期式光通信網(Sonet)[SDH]/同期デジタルハイアラーキ(SDH)[ITUG]です。 TDM交通を支持するために、pseudowiresはSonet/SDHペイロードのサーキットの特性を見習わなければなりません。(交通は声、データ、および個人的な専用線サービスを含んでいます)。 TDM信号とペイロードはトランスミッションのためにpseudowiresの上にカプセルに入れられます。 pseudowire demultiplexorとPSNトンネルヘッダーはこのカプセル化にprependedされます。
[SAToP] describes methods for transporting low-rate time-division multiplexing (TDM) digital signals (TDM circuit emulation) over PSNs, while [CEP] similarly describes transport of high-rate TDM (SONET/SDH). To support TDM traffic, the pseudowires must emulate the circuit characteristics of the original T1, E1, T3, E3, SONET, or SDH signals. [SAToP] does this by encapsulating an arbitrary but constant amount of the TDM data in each packet, and the other methods encapsulate TDM structures.
[SAToP]はPSNsの上で低率時分割多重化(TDM)ディジタル信号(TDMサーキットエミュレーション)を輸送するための方法を説明します、[CEP]は同様に高い率TDM(Sonet/SDH)の輸送について説明しますが。 TDM交通を支持するために、pseudowiresはオリジナルのT1、1E、T3、3E、Sonet、またはSDH信号のサーキットの特性を見習わなければなりません。 [SAToP]は各パケットのTDMデータの任意の、しかし、一定の量を要約することによって、これをします、そして、他の方法はTDM構造を要約します。
In this document, we specify the use of the MPLS Label Distribution Protocol, LDP [RFC3036], as a protocol for setting up and maintaining the pseudowires. In particular, we define new TLVs, FEC elements, parameters, and codes for LDP, which enable LDP to identify pseudowires and to signal attributes of pseudowires. We specify how a pseudowire endpoint uses these TLVs in LDP to bind a demultiplexor field value to a pseudowire, and how it informs the remote endpoint of the binding. We also specify procedures for reporting pseudowire status changes, for passing additional information about the pseudowire as needed, and for releasing the bindings.
本書では、私たちはMPLS Label Distributionプロトコルの使用を指定します、自由民主党[RFC3036]、pseudowiresをセットアップして、維持するためのプロトコルとして。 特に、私たちは自由民主党のための自由民主党がpseudowiresを特定して、pseudowiresの属性に合図するのを可能にする新しいTLVs、FEC要素、パラメタ、およびコードを定義します。 私たちは、pseudowire終点が「反-マルチプレクサー」分野価値をpseudowireに縛るのに自由民主党にどのようにこれらのTLVsを使用するか、そして、それがどのように結合の遠く離れた終点を知らせるかを指定します。 また、私たちはpseudowire状態変化を報告して、必要に応じてpseudowireに関する追加情報を通過して、結合をリリースするための手順を指定します。
Martini, et al. Standards Track [Page 3] RFC 4447 PWE3 Using LDP April 2006
マティーニ、他 2006年4月に自由民主党を使用する標準化過程[3ページ]RFC4447PWE3
In the protocol specified herein, the pseudowire demultiplexor field is an MPLS label. Thus, the packets that are transmitted from one end of the pseudowire to the other are MPLS packets, which must be transmitted through an MPLS tunnel. However, if the pseudowire endpoints are immediately adjacent and penultimate hop popping behavior is in use, the MPLS tunnel may not be necessary. Any sort of PSN tunnel can be used, as long as it is possible to transmit MPLS packets through it. The PSN tunnel can itself be an MPLS LSP, or any other sort of tunnel that can carry MPLS packets. Procedures for setting up and maintaining the MPLS tunnels are outside the scope of this document.
ここに指定されたプロトコルでは、pseudowire demultiplexor分野はMPLSラベルです。 したがって、pseudowireの片端からもう片方まで伝えられるパケットはMPLSパケットです。(MPLSトンネルを通してそのパケットを送らなければなりません)。 しかしながら、振舞いはMPLSトンネルがpseudowire終点がすぐに、隣接していて終わりから二番目ののホップの飛び出しであるなら使用中である必要はないかもしれません。 それを通してMPLSパケットを伝えるのが可能である限り、どんな種類のPSNトンネルも使用できます。 PSNは運ばれることができるMPLS LSP、またはいかなる他の種類のトンネルもMPLSパケットであったなら缶自体にトンネルを堀ります。 このドキュメントの範囲の外にMPLSトンネルを設立して、維持するための手順があります。
This document deals only with the setup and maintenance of point-to- point pseudowires. Neither point-to-multipoint nor multipoint-to- point pseudowires are discussed.
このドキュメントはポイントからポイントへのpseudowiresのセットアップと維持だけに対処します。 ポイントツーマルチポイントも多点からポイントへのpseudowiresも議論しません。
QoS-related issues are not discussed in this document. The following two figures describe the reference models that are derived from [RFC3985] to support the PW emulated services.
本書ではQoS関連の問題について議論しません。 以下の2つの数字が[RFC3985]からサポートまで引き出されて、PWがサービスを見習ったということである規範モデルについて説明します。
|<-------------- Emulated Service ---------------->|
| |
| |<------- Pseudowire ------->| |
| | | |
|Attachment| |<-- PSN Tunnel -->| |Attachment|
| Circuit V V V V Circuit |
V (AC) +----+ +----+ (AC) V
+-----+ | | PE1|==================| PE2| | +-----+
| |----------|............PW1.............|----------| |
| CE1 | | | | | | | | CE2 |
| |----------|............PW2.............|----------| |
+-----+ ^ | | |==================| | | ^ +-----+
^ | +----+ +----+ | | ^
| | Provider Edge 1 Provider Edge 2 | |
| | | |
Customer | | Customer
Edge 1 | | Edge 2
| |
native service native service
| <。-------------- 見習われたサービス---------------->|、|、|、| | <、-、-、-、-、-、-- Pseudowire------->|、|、|、|、|、| |付属| | <-- PSNはトンネルを堀ります-->| |付属| | サーキットV V V Vサーキット| (西暦)+に対して----+ +----+ +に対する(西暦)-----+ | | PE1|==================| PE2| | +-----+ | |----------|............PW1…|----------| | | CE1| | | | | | | | CE2| | |----------|............PW2…|----------| | +-----+ ^ | | |==================| | | ^ +-----+ ^ | +----+ +----+ | | ^ | | 1つのプロバイダー縁のプロバイダー縁2| | | | | | 顧客| | 顧客縁1| | 縁2| | ネイティブのサービスネイティブのサービス
Figure 1: PWE3 Reference Model
図1: PWE3規範モデル
Martini, et al. Standards Track [Page 4] RFC 4447 PWE3 Using LDP April 2006
マティーニ、他 2006年4月に自由民主党を使用する標準化過程[4ページ]RFC4447PWE3
+-----------------+ +-----------------+
|Emulated Service | |Emulated Service |
|(e.g., TDM, ATM) |<==== Emulated Service ===>|(e.g., TDM, ATM) |
+-----------------+ +-----------------+
| Payload | | Payload |
| Encapsulation |<====== Pseudowire =======>| Encapsulation |
+-----------------+ +-----------------+
|PW Demultiplexer | |PW Demultiplexer |
| PSN Tunnel, |<======= PSN Tunnel ======>| PSN Tunnel, |
| PSN & Physical | | PSN & Physical |
| Layers | | Layers |
+-------+---------+ __________ +---------+-------+
| / \ |
+===============/ PSN \================+
\ /
\____________/
+-----------------+ +-----------------+ |見習われたサービス| |見習われたサービス| |(例えば、TDM、気圧) |<== 見習われたサービス===>|(例えば、TDM、気圧) | +-----------------+ +-----------------+ | 有効搭載量| | 有効搭載量| | カプセル化|<=== Pseudowire=======>| カプセル化| +-----------------+ +-----------------+ |PWデマルチプレクサ| |PWデマルチプレクサ| | PSNはトンネルを堀ります。|<==== PSNトンネル======>| PSNはトンネルを堀ります。| | PSN的で物理的です。| | PSN的で物理的です。| | 層| | 層| +-------+---------+ __________ +---------+-------+ | / \ | +===============/PSN\================+ \ / \____________/
Figure 2: PWE3 Protocol Stack Reference Model
図2: PWE3プロトコル・スタック規範モデル
For the purpose of this document, PE1 will be defined as the ingress router, and PE2 as the egress router. A layer 2 PDU will be received at PE1, encapsulated at PE1, transported and decapsulated at PE2, and transmitted out of PE2.
このドキュメントの目的のために、PE1は出口ルータとしてイングレスルータ、およびPE2と定義されるでしょう。 2PDU層は、PE1に受け取られて、PE1で要約されて、PE2で輸送されて、decapsulatedされて、PE2から伝えられるでしょう。
2. Specification of Requirements
2. 要件の仕様
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
キーワード“MUST"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTは[RFC2119]で説明されるように本書では解釈されることであるべきですか?
3. The Pseudowire Label
3. Pseudowireラベル
Suppose that it is desired to transport Layer 2 PDUs from ingress LSR PE1 to egress LSR PE2, across an intervening MPLS-enabled network. We assume that there is an MPLS tunnel from PE1 to PE2. That is, we assume that PE1 can cause a packet to be delivered to PE2 by encapsulating the packet in an "MPLS tunnel header" and sending the result to one of its adjacencies. The MPLS tunnel is an MPLS Label Switched Path (LSP); thus, putting on an MPLS tunnel encapsulation is a matter of pushing on an MPLS label.
イングレスLSR PE1から出口LSR PE2までLayer2PDUsを輸送するのが必要であると仮定してください、介入しているMPLSによって可能にされたネットワークの向こう側に。 私たちは、PE1からPE2までMPLSトンネルがあると思います。 すなわち、私たちは、PE1がパケットをPE2に「MPLSトンネルヘッダー」でパケットをカプセルに入れって、隣接番組の1つに結果を送ることによって渡させることができると思います。 MPLSトンネルはMPLS Label Switched Path(LSP)です。 したがって、MPLSトンネルカプセル化を置くのは、MPLSラベルを押す問題です。
We presuppose that a large number of pseudowires can be carried through a single MPLS tunnel. Thus, it is never necessary to maintain state in the network core for individual pseudowires. We do not presuppose that the MPLS tunnels are point to point; although the pseudowires are point to point, the MPLS tunnels may be multipoint to point. We do not presuppose that PE2 will even be able to determine the MPLS tunnel through which a received packet was transmitted.
私たちは、単一のMPLSトンネルを通って多くのpseudowiresを運ぶことができるのを予想します。 したがって、個々のpseudowiresのためにネットワークコアで状態を維持するのは決して必要ではありません。 私たちは、MPLSトンネルがポイント・ツー・ポイントであることを予想しません。 pseudowiresはポイント・ツー・ポイントですが、MPLSトンネルは示す多点であるかもしれません。 私たちは、PE2が容認されたパケットが送られたMPLSトンネルを決定さえできるのを予想しません。
Martini, et al. Standards Track [Page 5] RFC 4447 PWE3 Using LDP April 2006
マティーニ、他 2006年4月に自由民主党を使用する標準化過程[5ページ]RFC4447PWE3
(For example, if the MPLS tunnel is an LSP and penultimate hop popping is used, when the packet arrives at PE2, it will contain no information identifying the tunnel.)
(例えば、MPLSトンネルがLSPであり、パケットがPE2に到着するとき終わりから二番目のホップの飛び出しが使用されていると、それはトンネルを特定する情報を全く含まないでしょう。)
When PE2 receives a packet over a pseudowire, it must be able to determine that the packet was in fact received over a pseudowire, and it must be able to associate that packet with a particular pseudowire. PE2 is able to do this by examining the MPLS label that serves as the pseudowire demultiplexor field shown in Figure 2. Call this label the "PW label".
PE2がpseudowireの上にパケットを受けるとき、事実上、パケットがpseudowireの上に受け取られたことを決定できなければなりません、そして、そのパケットを特定のpseudowireに関連づけることができなければなりません。 PE2は、図2に示されたpseudowire demultiplexor分野として機能するMPLSラベルを調べることによって、これができます。 このラベルを「PWラベル」と呼んでください。
When PE1 sends a Layer 2 PDU to PE2, it creates an MPLS packet by adding the PW label to the packet, thus creating the first entry of the label stack. If the PSN tunnel is an MPLS LSP, the PE1 pushes another label (the tunnel label) onto the packet as the second entry of the label stack. The PW label is not visible again until the MPLS packet reaches PE2. PE2's disposition of the packet is based on the PW label.
PE1がLayer2PDUをPE2に送るとき、PWラベルをパケットに加えることによって、MPLSパケットを作成します、その結果、ラベルスタックの初記入を作成します。 PSNトンネルがMPLS LSPであるなら、PE1はラベルスタックの2番目のエントリーとして別のラベル(トンネルラベル)をパケットに押します。 MPLSパケットがPE2に達するまで、PWラベルは再び目に見えません。 PE2のパケットの気質はPWラベルに基づいています。
If the payload of the MPLS packet is, for example, an ATM AAL5 PDU, the PW label will generally correspond to a particular ATM VC at PE2. That is, PE2 needs to be able to infer from the PW label the outgoing interface and the VPI/VCI value for the AAL5 PDU. If the payload is a Frame Relay PDU, then PE2 needs to be able to infer from the PW label the outgoing interface and the DLCI value. If the payload is an Ethernet frame, then PE2 needs to be able to infer from the PW label the outgoing interface, and perhaps the VLAN identifier. This process is uni-directional and will be repeated independently for bi-directional operation. It is REQUIRED that the same PW ID and PW type be assigned for a given circuit in both directions. The group ID (see below) MUST NOT be required to match in both directions. The transported frame MAY be modified when it reaches the egress router. If the header of the transported Layer 2 frame is modified, this MUST be done at the egress LSR only. Note that the PW label must always be at the bottom of the packet's label stack, and labels MUST be allocated from the per-platform label space.
例えば、MPLSパケットのペイロードがATM AAL5 PDUであるなら、一般に、PWラベルはPE2の特定のATM VCに対応するでしょう。 すなわち、PE2は、AAL5 PDUのためにPWラベルから外向的なインタフェースとVPI/VCI値を推論できる必要があります。 ペイロードがFrame Relay PDUであるなら、PE2は、PWラベルから外向的なインタフェースとDLCI値を推論できる必要があります。 ペイロードがイーサネットフレームであるなら、PE2は、PWラベルから外向的なインタフェース、および恐らくVLAN識別子を推論できる必要があります。 この過程は、uni方向上であり、双方向の操作のために独自に繰り返されるでしょう。 同じPW IDとPWタイプが両方の方向への与えられたサーキットに選任されるのは、REQUIREDです。 両方の方向に合うようにグループID(以下を見る)を必要としてはいけません。 出口ルータに達するとき、輸送されたフレームは変更されるかもしれません。 輸送されたLayer2フレームのヘッダーが変更しているなら、出口LSRだけにこれをしなければなりません。 PWラベルがパケットのラベルスタックの下部にいつもあるに違いなくて、1プラットホームあたりのラベルスペースからラベルを割り当てなければならないことに注意してください。
This document does not specify a method for distributing the MPLS tunnel label or any other labels that may appear above the PW label on the stack. Any acceptable method of MPLS label distribution will do. This document specifies a protocol for assigning and distributing the PW label. This protocol is LDP, extended as specified in the remainder of this document. An LDP session must be set up between the pseudowire endpoints. LDP MUST be used in its "downstream unsolicited" mode. LDP's "liberal label retention" mode SHOULD be used.
このドキュメントはスタックの上のPWラベルの上に現れるかもしれないMPLSトンネルラベルかいかなる他のラベルも分配するための方法を指定しません。 MPLSラベル分配のどんな許容できる方法も大丈夫です。 このドキュメントはPWラベルを割り当てて、分配するのにプロトコルを指定します。 このプロトコルはこのドキュメントの残りで指定されるように広げられた自由民主党です。 pseudowire終点の間で自由民主党のセッションをセットアップしなければなりません。 「川下求められていません、な」モードで自由民主党を使用しなければなりません。 自由主義者は」 モードSHOULDと保有をラベルします。自由民主党のもの、「使用されます。
Martini, et al. Standards Track [Page 6] RFC 4447 PWE3 Using LDP April 2006
マティーニ、他 2006年4月に自由民主党を使用する標準化過程[6ページ]RFC4447PWE3
In addition to the protocol specified herein, static assignment of PW labels may be used, and implementations of this protocol SHOULD provide support for static assignment.
ここに指定されたプロトコルに加えて、PWラベルの静的な課題は使用されるかもしれません、そして、このプロトコルSHOULDの実現は静的な課題のサポートを提供します。
This document specifies all the procedures necessary to set up and maintain the pseudowires needed to support "unswitched" point-to- point services, where each endpoint of the pseudowire is provisioned with the identify of the other endpoint. There are also protocol mechanisms specified herein that can be used to support switched services and other provisioning models. However, the use of the protocol mechanisms to support those other models and services is not described in this document.
このドキュメントがセットアップして、pseudowiresが、"「非-切り換え」"のポイントからポイントに対するpseudowireの各終点に食糧を供給されるサービスを支持する必要だったと主張するのに必要なすべての手順を指定する、特定、もう片方の終点について。 また、ここに指定されたモデルに食糧を供給しながら切り換えられたサービスを支持するのにおいて中古の、そして、他である場合があるプロトコルメカニズムがあります。 しかしながら、それらの他のモデルとサービスをサポートするプロトコルメカニズムの使用は本書では説明されません。
4. Details Specific to Particular Emulated Services
4. 特定の見習われたサービスに特定の詳細
4.1. IP Layer 2 Transport
4.1. IP層2の輸送
This mode carries IP packets over a pseudowire. The encapsulation used is according to [RFC3032]. The PW control word MAY be inserted between the MPLS label stack and the IP payload. The encapsulation of the IP packets for forwarding on the attachment circuit is implementation specific, is part of the native service processing (NSP) function [RFC3985], and is outside the scope of this document.
このモードはpseudowireの上までIPパケットを運びます。 [RFC3032]に従って、使用されるカプセル化があります。 PW規制単語はMPLSラベルスタックとIPペイロードの間に挿入されるかもしれません。 付属サーキットにおける推進のためのIPパケットのカプセル化は、実現特有であり、ネイティブのサービス処理(NSP)機能[RFC3985]の一部であり、このドキュメントの範囲の外にあります。
5. LDP
5. 自由民主党
The PW label bindings are distributed using the LDP downstream unsolicited mode described in [RFC3036]. The PEs will establish an LDP session using the Extended Discovery mechanism described in [LDP, sections 2.4.2 and 2.5].
PWラベル結合は、[RFC3036]で説明された自由民主党の川下の求められていないモードを使用することで分配されています。 PEsは、[セクション2.4 自由民主党、.2、および2.5]で説明されたExtendedディスカバリーメカニズムを使用することで自由民主党のセッションを確立するでしょう。
An LDP Label Mapping message contains an FEC TLV, a Label TLV, and zero or more optional parameter TLVs.
自由民主党Label MappingメッセージはFEC TLVか、Label TLVと、ゼロか、より多くの任意のパラメタTLVsを含んでいます。
The FEC TLV is used to indicate the meaning of the label. In the current context, the FEC TLV would be used to identify the particular pseudowire that a particular label is bound to. In this specification, we define two new FEC TLVs to be used for identifying pseudowires. When setting up a particular pseudowire, only one of these FEC TLVs is used. The one to be used will depend on the particular service being emulated and on the particular provisioning model being supported.
FEC TLVは、ラベルの意味を示すのに使用されます。 現在の背景では、FEC TLVは、特定のラベルが制限されている特定のpseudowireを特定するのに使用されるでしょう。 この仕様では、私たちは、pseudowiresを特定するのに使用されるために2新しいFEC TLVsを定義します。 特定のpseudowireをセットアップするとき、これらのFEC TLVsの1つだけが使用されています。 使用されるべきものは見習われて、モデル存在に食糧を供給する特定で支持される特定のサービスによるでしょう。
LDP allows each FEC TLV to consist of a set of FEC elements. For setting up and maintaining pseudowires, however, each FEC TLV MUST contain exactly one FEC element.
自由民主党で、各FEC TLVは1セットのFEC要素から成ることができます。 しかしながら、pseudowiresをセットアップして、維持するために、各FEC TLV MUSTはちょうど1つのFEC要素を含んでいます。
Martini, et al. Standards Track [Page 7] RFC 4447 PWE3 Using LDP April 2006
マティーニ、他 2006年4月に自由民主党を使用する標準化過程[7ページ]RFC4447PWE3
The LDP base specification has several kinds of label TLVs, including the Generic Label TLV, as specified in [RFC3036], section 3.4.2.1. For setting up and maintaining pseudowires, the Generic Label TLV MUST be used.
自由民主党基礎仕様には数種類のラベルTLVsがあります、Generic Label TLVを含んでいて、[RFC3036]、セクション3.4.2で.1に指定されるように pseudowiresをセットアップして、維持するために、Generic Label TLVを使用しなければなりません。
5.1. LDP Extensions
5.1. 自由民主党の拡大
This document specifies no new LDP messages.
このドキュメントはどんな新しい自由民主党メッセージも指定しません。
This document specifies the following new TLVs to be used with LDP:
このドキュメントは自由民主党と共に使用されるために以下の新しいTLVsを指定します:
TLV Specified in Section Defined for Message =================================================================== PW Status TLV 5.4.2 Notification PW Interface Parameters TLV 5.3.2.1 FEC PW Grouping ID TLV 5.3.2.2 FEC
メッセージのために定義されたセクションで指定されたTLV=================================================================== PW状態TLV5.4.2の通知PWインタフェース・パラメータTLV5.3.2.1FEC PW組分けID TLV5.3.2.2FEC
Additionally, the following new FEC element types are defined:
さらに、以下の新しいFEC要素型は定義されます:
FEC Element Type Specified in Section Defined for Message =================================================================== 0x80 5.2 FEC 0x81 5.3 FEC
メッセージのために定義されたセクションで指定されたFEC要素型=================================================================== 0×80 5.2FEC0x81 5.3FEC
The following new LDP error codes are also defined:
また、以下の新しい自由民主党エラーコードは定義されます:
Status Code Specified in Section ==================================================================== "Illegal C-Bit" 6.1 "Wrong C-Bit" 6.2 "Incompatible bit-rate" [CEP] "CEP/TDM mis-configuration" [CEP] "PW status" 5.4.2 "Unassigned/Unrecognized TAI" 5.3.3 "Generic Misconfiguration Error" [SAToP] "Label Withdraw PW Status Method Not Supported" 5.4.1
セクションで指定されたステータスコード==================================================================== 「不法なC-ビット」の6.1「間違ったC-ビット」6.2「両立しないビット伝送速度」[CEP]「CEP/TDM誤構成」[CEP]「PW状態」5.4.2「割り当てられなかったか認識されていないTAI」5.3.3「一般的なMisconfiguration誤り」「ラベルは方法が支持しなかったPW状態を引き下がる」という[SAToP]5.4.1
5.2. The PWid FEC Element
5.2. PWid FEC要素
The PWid FEC element may be used whenever both pseudowire endpoints have been provisioned with the same 32-bit identifier for the pseudowire.
両方のpseudowire終点がpseudowireのために同じ32ビットの識別子で食糧を供給されたときはいつも、PWid FEC要素は使用されるかもしれません。
Martini, et al. Standards Track [Page 8] RFC 4447 PWE3 Using LDP April 2006
マティーニ、他 2006年4月に自由民主党を使用する標準化過程[8ページ]RFC4447PWE3
For this purpose, a new type of FEC element is defined. The FEC element type is 0x80 and is defined as follows:
このために、新しいタイプのFEC要素は定義されます。 FEC要素型は、0×80であり、以下の通り定義されます:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PWid (0x80) |C| PW type |PW info Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Group ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PW ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface Parameter Sub-TLV |
| " |
| " |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | PWid(0×80)|C| PWはタイプします。|PWインフォメーションLength| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | グループID| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | PW ID| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | インタフェース・パラメータサブTLV| | " | | " | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- PW type
- PWはタイプします。
A 15-bit quantity containing a value that represents the type of
PW. Assigned values are specified in "IANA Allocations for
Pseudowire Edge to Edge Emulation (PWE3)" [IANA].
PWのタイプの代理をする値を含む15ビットの量。 割り当てられた値は「PseudowireのためのIANA配分はエミュレーション(PWE3)を斜めに進ませるために斜めに進むところ」で[IANA]指定されます。
- Control word bit (C)
- コントロール単語ビット(C)
The bit (C) is used to flag the presence of a control word as
follows:
ビット(C)は以下の規制単語の存在に旗を揚げさせるのに使用されます:
C = 1 Control word present on this PW.
C = 0 No control word present on this PW.
CはこのPWの現在の1つの規制単語と等しいです。 CはこのPWの現在の0いいえ規制単語と等しいです。
Please see the section "C-Bit Handling Procedures" for further
explanation.
詳細な説明に関して「C-ビット操作手順」というセクションを見てください。
- PW information length
- PW情報の長さ
Length of the PW ID field and the interface parameters sub-TLV in
octets. If this value is 0, then it references all PWs using the
specified group ID, and there is no PW ID present; nor are there
any interface parameter sub-TLVs.
八重奏におけるサブTLVのPW ID分野とインタフェース・パラメータの長さ。 この値が0であるなら、指定されたグループIDを使用することですべてのPWsに参照をつけます、そして、どんな存在しているPW IDもありません。 また、どんなインタフェース・パラメータサブTLVsもありません。
- Group ID
- グループID
An arbitrary 32-bit value that represents a group of PWs that is
used to create groups in the PW space. The group ID is intended
to be used as a port index, or a virtual tunnel index. To
simplify configuration, a particular PW ID at ingress could be
part of the virtual tunnel for transport to the egress router.
作成するのにおいて使用されたPWsのグループを代表する任意の32ビットの値はPWスペースで分類されます。 ポートインデックス、または仮想のトンネルインデックスとしてグループIDが使用されることを意図します。 構成を簡素化するために、イングレスにおける特定のPW IDは出口ルータへの輸送のための仮想のトンネルの一部であるかもしれません。
Martini, et al. Standards Track [Page 9] RFC 4447 PWE3 Using LDP April 2006
マティーニ、他 2006年4月に自由民主党を使用する標準化過程[9ページ]RFC4447PWE3
The Group ID is very useful for sending wild card label
withdrawals, or PW wild card status notification messages to
remote PEs upon physical port failure.
Group IDは非常に物理的なポートの故障でワイルドカードラベル退出、またはPWワイルドカード状態通知メッセージをリモートPEsに送ることの役に立ちます。
- PW ID
- PW ID
A non-zero 32-bit connection ID that, together with the PW type,
identifies a particular PW. Note that the PW ID and the PW type
MUST be the same at both endpoints.
PWタイプと共に特定のPWを特定する非ゼロの32ビットの接続ID。 PW IDとPWタイプが両方の終点で同じであるに違いないことに注意してください。
- Interface Parameter Sub-TLV
- インタフェース・パラメータサブTLV
This variable-length TLV is used to provide interface-specific
parameters, such as attachment circuit MTU.
この可変長のTLVは、付属サーキットMTUなどのインタフェース特有のパラメタを提供するのに使用されます。
Note that as the "interface parameter sub-TLV" is part of the FEC,
the rules of LDP make it impossible to change the interface
parameters once the pseudowire has been set up. Thus, the
interface parameters field must not be used to pass information,
such as status information, that may change during the life of the
pseudowire. Optional parameter TLVs should be used for that
purpose.
それに注意する、「インタフェース・パラメータサブTLV」がFECの一部である、自由民主党の規則で、pseudowireがいったんセットアップされるとインタフェース・パラメータを変更させるのは不可能になります。 したがって、pseudowireの人生の間に変化するかもしれない状態情報などの情報を通過するのにインタフェース・パラメータ分野を使用してはいけません。 任意のパラメタTLVsはそのために使用されるべきです。
Using the PWid FEC, each of the two pseudowire endpoints independently initiates the setup of a unidirectional LSP. An outgoing LSP and an incoming LSP are bound together into a single pseudowire if they have the same PW ID and PW type.
PWid FECを使用して、それぞれの2つのpseudowire終点が独自に単方向LSPのセットアップに着手します。 彼らが同じPW IDとPWにタイプさせるなら、出発しているLSPと入って来るLSPは単一のpseudowireに一緒に制限されています。
5.3. The Generalized PWid FEC Element
5.3. 一般化されたPWid FEC要素
The PWid FEC element can be used if a unique 32-bit value has been assigned to the PW, and if each endpoint has been provisioned with that value. The Generalized PWid FEC element requires that the PW endpoints be uniquely identified; the PW itself is identified as a pair of endpoints. In addition, the endpoint identifiers are structured to support applications where the identity of the remote endpoints needs to be auto-discovered rather than statically configured.
ユニークな32ビットの値をPWに割り当ててあって、各終点がその値で食糧を供給されたなら、PWid FEC要素を使用できます。 Generalized PWid FEC要素は、PW終点が唯一特定されるのを必要とします。 PW自身は1組の終点として特定されます。 さらに、終点識別子は、遠く離れた終点のアイデンティティが静的に構成されるより自動むしろ発見されている必要があるアプリケーションを支持するために構造化されます。
The "Generalized PWid FEC Element" is FEC type 0x81.
「一般化されたPWid FEC要素」はFECタイプ0x81です。
The Generalized PWid FEC Element does not contain anything corresponding to the "Group ID" of the PWid FEC element. The functionality of the "Group ID" is provided by a separate optional LDP TLV, the "PW Grouping TLV", described below. The Interface Parameters field of the PWid FEC element is also absent; its functionality is replaced by the optional Interface Parameters TLV, described below.
Generalized PWid FEC ElementはPWid FEC要素の「グループID」に対応するものは何も含んでいません。 別々の任意のLDP TLV、以下で説明された「PW組分けTLV」によって「グループID」の機能性は提供されます。 また、PWid FEC要素のInterface Parameters分野も欠けています。 機能性を以下で説明された任意のInterface Parameters TLVに取り替えます。
Martini, et al. Standards Track [Page 10] RFC 4447 PWE3 Using LDP April 2006
マティーニ、他 2006年4月に自由民主党を使用する標準化過程[10ページ]RFC4447PWE3
5.3.1. Attachment Identifiers
5.3.1. 付属識別子
As discussed in [RFC3985], a pseudowire can be thought of as connecting two "forwarders". The protocol used to set up a pseudowire must allow the forwarder at one end of a pseudowire to identify the forwarder at the other end. We use the term "attachment identifier", or "AI", to refer to the field that the protocol uses to identify the forwarders. In the PWid FEC, the PWid field serves as the AI. In this section, we specify a more general form of AI that is structured and of variable length.
[RFC3985]で議論するように、2「混載業者」を接続するとpseudowireを考えることができます。 pseudowireをセットアップするのに使用されるプロトコルで、pseudowireの片端の混載業者はもう一方の端のときに混載業者を特定できなければなりません。 私たちは、プロトコルが混載業者を特定するのに使用する野原について言及するのに用語「付属識別子」、または「AI」を使用します。 PWid FECでは、PWid分野はAIとして機能します。 このセクションでは、私たちは構造化されるAIと可変長の、より一般的なフォームを指定します。
Every Forwarder in a PE must be associated with an Attachment Identifier (AI), either through configuration or through some algorithm. The Attachment Identifier must be unique in the context of the PE router in which the Forwarder resides. The combination <PE router IP address, AI> must be globally unique.
PEのあらゆるForwarderが構成を通して、または、何らかのアルゴリズムを通してAttachment Identifierに関連しているに違いありません(AI)。 Attachment IdentifierはForwarderが住んでいるPEルータの文脈でユニークであるに違いありません。 組み合わせ<PEルータIPアドレスであり、AI>はグローバルにユニークでなければなりません。
It is frequently convenient to regard a set of Forwarders as being members of a particular "group", where PWs may only be set up among members of a group. In such cases, it is convenient to identify the Forwarders relative to the group, so that an Attachment Identifier would consist of an Attachment Group Identifier (AGI) plus an Attachment Individual Identifier (AII).
Forwardersの1セットをPWsがグループのメンバーの中でセットアップされるだけであるかもしれない特定の「グループ」のメンバーであると見なすのは頻繁に便利です。 そのような場合、グループに比例してForwardersを特定するのは便利です、Attachment IdentifierがAttachment Group Identifier(AGI)とAttachment Individual Identifier(AII)から成るように。
An Attachment Group Identifier may be thought of as a VPN-id, or a VLAN identifier, some attribute that is shared by all the Attachment PWs (or pools thereof) that are allowed to be connected.
Attachment Group IdentifierはVPN-イド、またはVLAN識別子(接続できるすべてのAttachment PWs(または、それのプール)によって共有される何らかの属性)として考えられるかもしれません。
The details of how to construct the AGI and AII fields identifying the pseudowire endpoints are outside the scope of this specification. Different pseudowire applications, and different provisioning models, will require different sorts of AGI and AII fields. The specification of each such application and/or model must include the rules for constructing the AGI and AII fields.
この仕様の範囲の外にどうpseudowire終点を特定するAGIとAII分野を構成するかに関する詳細があります。 異なったpseudowireアプリケーションの、そして、異なった食糧を供給することはモデル化されて、異なった種類のAGIとAII分野を必要とするでしょう。 そのようなそれぞれのアプリケーション、そして/または、モデルの仕様はAGIとAII分野を構成するための規則を含まなければなりません。
As previously discussed, a (bidirectional) pseudowire consists of a pair of unidirectional LSPs, one in each direction. If a particular pseudowire connects PE1 with PE2, the PW direction from PE1 to PE2 can be identified as:
以前に議論するように、(双方向)のpseudowireは1組の単方向LSPsから成って、あるコネは各指示です。 特定のpseudowireがPE1をPE2に接続するなら、以下としてPW PE1からPE2への指示を特定できます。
<PE1, <AGI, AII1>, PE2, <AGI, AII2>>,
<PE1、<阿木、AII1>、PE2、<阿木、AII2>>。
The PW direction from PE2 to PE1 can be identified by:
以下はPW PE2からPE1への指示を特定できます。
<PE2, <AGI, AII2>, PE1, <AGI, AII1>>.
<PE2、<阿木、AII2>、PE1、<阿木、AII1>>。
Martini, et al. Standards Track [Page 11] RFC 4447 PWE3 Using LDP April 2006
マティーニ、他 2006年4月に自由民主党を使用する標準化過程[11ページ]RFC4447PWE3
Note that the AGI must be the same at both endpoints, but the AII will in general be different at each endpoint. Thus, from the perspective of a particular PE, each pseudowire has a local or "Source AII", and a remote or "Target AII". The pseudowire setup protocol can carry all three of these quantities:
AGIが両方の終点で同じであるに違いありませんが、一般に、AIIが各終点で異なることに注意してください。 したがって、各pseudowireはローカルか「ソースAII」と、aを特定のPEの見解から、リモートにするか、「AIIを狙ってください。」 pseudowireセットアッププロトコルはこれらのすべての3つの量を運ぶことができます:
- Attachment Group Identifier (AGI)
- 付属グループ識別子(阿木)
- Source Attachment Individual Identifier (SAII)
- ソースの付属の個々の識別子(SAII)
- Target Attachment Individual Identifier (TAII)
- 付属の個々の識別子を狙ってください。(TAII)
If the AGI is non-null, then the Source AI (SAI) consists of the AGI together with the SAII, and the Target AI (TAI) consists of the TAII together with the AGI. If the AGI is null, then the SAII and TAII are the SAI and TAI, respectively.
AGIが非ヌルであるなら、Source AI(SAI)はSAIIと共にAGIから成ります、そして、Target AI(TAI)はAGIと共にTAIIから成ります。 AGIがヌルであるなら、SAIIとTAIIはそれぞれSAIとTAIです。
The interpretation of the SAI and TAI is a local matter at the respective endpoint.
SAIとTAIの解釈はそれぞれの終点の地域にかかわる事柄です。
The association of two unidirectional LSPs into a single bidirectional pseudowire depends on the SAI and the TAI. Each application and/or provisioning model that uses the Generalized ID FEC element must specify the rules for performing this association.
単一の双方向のpseudowireへの2単方向LSPsの協会はSAIとTAIによります。 各アプリケーション、そして/または、Generalized ID FEC要素を使用するモデルに食糧を供給すると、この協会を実行するための規則は指定されなければなりません。
Martini, et al. Standards Track [Page 12] RFC 4447 PWE3 Using LDP April 2006
マティーニ、他 2006年4月に自由民主党を使用する標準化過程[12ページ]RFC4447PWE3
5.3.2. Encoding the Generalized ID FEC Element
5.3.2. 一般化されたID FEC要素をコード化します。
FEC element type 0x81 is used. The FEC element is encoded as follows:
FEC要素型0x81は使用されています。 FEC要素は以下の通りコード化されます:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Gen PWid (0x81)|C| PW Type |PW info Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AGI Type | Length | Value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ AGI Value (contd.) ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AII Type | Length | Value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ SAII Value (contd.) ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AII Type | Length | Value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ TAII Value (contd.) ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |PWid(0×81)に情報を得てください。|C| PWはタイプします。|PWインフォメーションLength| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AGIはタイプします。| 長さ| 値| +++++++++++++++++++++++++++++++++~AGIは(contd)を評価します。 ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AIIはタイプします。| 長さ| 値| +++++++++++++++++++++++++++++++++~SAIIは(contd)を評価します。 ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AIIはタイプします。| 長さ| 値| +++++++++++++++++++++++++++++++++~TAIIは(contd)を評価します。 ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
This document does not specify the AII and AGI type field values; specification of the type field values to be used for a particular application is part of the specification of that application. IANA has assigned these values using the method defined in the [IANA] document.
このドキュメントはAIIを指定しません、そして、AGIは分野値をタイプします。 特定用途に使用されるべきタイプ分野値の仕様はそのアプリケーションの仕様の一部です。 IANAは、[IANA]ドキュメントで定義された方法を使用することでこれらの値を割り当てました。
The SAII, TAII, and AGI are simply carried as octet strings. The length byte specifies the size of the Value field. The null string can be sent by setting the length byte to 0. If a particular application does not need all three of these sub-elements, it MUST send all the sub-elements but set the length to 0 for the unused sub-elements.
SAII、TAII、およびAGIは八重奏ストリングとして単に運ばれます。 長さのバイトはValue分野のサイズを指定します。 長さのバイトを0に設定することによって、ヌルストリングを送ることができます。 特定用途がこれらのすべての3つの下位要素を必要とするというわけではないなら、それは、未使用の下位要素のためにすべての下位要素を送りますが、0に長さを設定しなければなりません。
The PW information length field contains the length of the SAII, TAII, and AGI, combined in octets. If this value is 0, then it references all PWs using the specified grouping ID. In this case, there are no other FEC element fields (AGI, SAII, etc.) present, nor any interface parameters TLVs.
PW情報長さの分野は八重奏で結合されたSAII、TAII、およびAGIの長さを含んでいます。 この値が0であるなら、それは、指定された組分けIDを使用することですべてのPWsに参照をつけます。 この場合、(阿木、SAIIなど)が提示する分野、およびどんなインタフェース・パラメータTLVsも他のFEC要素がではなくありません。
Note that the interpretation of a particular field as AGI, SAII, or TAII depends on the order of its occurrence. The type field identifies the type of the AGI, SAII, or TAII. When comparing two
阿木、SAII、またはTAIIとしての特定の分野の解釈が発生の注文によることに注意してください。 タイプ分野は阿木、SAII、またはTAIIのタイプを特定します。 2を突き合わせたいつ
Martini, et al. Standards Track [Page 13] RFC 4447 PWE3 Using LDP April 2006
マティーニ、他 2006年4月に自由民主党を使用する標準化過程[13ページ]RFC4447PWE3
occurrences of an AGI (or SAII or TAII), the two occurrences are considered identical if the type, length, and value fields of one are identical, respectively, to those of the other.
AGI(または、SAIIかTAII)の発生、1のタイプ、長さ、および値の分野がそれぞれもう片方のものと同じであるなら、2回の発生が同じであると考えられます。
5.3.2.1. Interface Parameters TLV
5.3.2.1. インタフェース・パラメータTLV
This TLV MUST only be used when sending the Generalized PW FEC. It specifies interface-specific parameters. Specific parameters, when applicable, MUST be used to validate that the PEs and the ingress and egress ports at the edges of the circuit have the necessary capabilities to interoperate with each other.
このTLV MUST、Generalized PW FECを送るときには単に使用されてください。 それはインタフェース特有のパラメタを指定します。 適切であるときに、特定のパラメタはそれを有効にするのに使用されて、サーキットの縁のPEs、イングレス、および出口港には互いと共に共同利用する必要機能があるということであるに違いありません。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0|0| PW Intf P. TLV (0x096B) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sub-TLV Type | Length | Variable Length Value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Variable Length Value |
| " |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0|0| PW Intf P.TLV(0x096B)| 長さ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | サブTLVはタイプします。| 長さ| 可変長値| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 可変長値| | " | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
A more detailed description of this field can be found in the section "Interface Parameters Sub-TLV", below.
以下の「インタフェース・パラメータサブTLV」というセクションでこの分野の、より詳細な記述を見つけることができます。
5.3.2.2. PW Grouping TLV
5.3.2.2. TLVを分類するPW
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0|0|PW Grouping ID TLV (0x096C)| Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0|0|ID TLV(0x096C)を分類するPW| 長さ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 値| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The PW Grouping ID is an arbitrary 32-bit value that represents an arbitrary group of PWs. It is used to create group PWs; for example, a PW Grouping ID can be used as a port index and assigned to all PWs that lead to that port. Use of the PW Grouping ID enables one to send "wild card" label withdrawals, or "wild card" status notification messages, to remote PEs upon physical port failure.
PW Grouping IDはPWsの任意のグループを代表する任意の32ビットの値です。 それはグループPWsを作成するのに使用されます。 例えば、PW Grouping IDをポートインデックスとして使用して、そのポートに通じるすべてのPWsに割り当てることができます。 PW Grouping IDの使用は、1つが「ワイルドカード」ラベル退出、または「ワイルドカード」状態通知メッセージを送るのを可能にします、物理的なポートの故障のリモートPEsに。
Note Well: The PW Grouping ID is different from, and has no relation to, the Attachment Group Identifier.
以下によく注意してください。 IDは異なって、関係がないPW Grouping、Attachment Group Identifier。
The PW Grouping ID TLV is not part of the FEC and will not be advertised except in the PW FEC advertisement. The advertising PE
PW Grouping ID TLVはFECの一部でなく、またPW FEC広告以外に、広告を出さないでしょう。 広告PE
Martini, et al. Standards Track [Page 14] RFC 4447 PWE3 Using LDP April 2006
マティーニ、他 2006年4月に自由民主党を使用する標準化過程[14ページ]RFC4447PWE3
MAY use the wild card withdraw semantics, but the remote PEs MUST implement support for wild card messages. This TLV MUST only be used when sending the Generalized PW ID FEC.
使用するかもしれません。ワイルドカードは意味論を引き下がらせますが、リモートPEsはワイルドカードメッセージのサポートを実行しなければなりません。 このTLV MUST、Generalized PW ID FECを送るときには単に使用されてください。
To issue a wildcard command (status or withdraw):
ワイルドカードコマンドを発行する、(状態、引き下がってください、)、:
- Set the PW Info Length to 0 in the Generalized ID FEC Element.
- 一般化されたID FEC要素の0にPWインフォメーションの長さを設定してください。
- Send only the PW Grouping ID TLV with the FEC (no AGI/SAII/TAII is
sent).
- FECとPW Grouping ID TLVだけを送ってください(阿木/SAII/TAIIを全く送りません)。
5.3.3. Signaling Procedures
5.3.3. シグナリング手順
In order for PE1 to begin signaling PE2, PE1 must know the address of the remote PE2, and a TAI. This information may have been configured at PE1, or it may have been learned dynamically via some autodiscovery procedure.
PE1がPE2に合図し始めるように、PE1はリモートPE2のアドレス、およびTAIを知らなければなりません。 この情報がPE1で構成されたかもしれませんか、またはそれは何らかのautodiscovery手順でダイナミックに学習されたかもしれません。
The egress PE (PE1), which has knowledge of the ingress PE, initiates the setup by sending a Label Mapping Message to the ingress PE (PE2). The Label Mapping message contains the FEC TLV, carrying the Generalized PWid FEC Element (type 0x81). The Generalized PWid FEC element contains the AGI, SAII, and TAII information.
イングレスPE(PE2)にLabel Mapping Messageを送ることによって、出口PE(PE1)はセットアップに着手します。(PEはイングレスPEに関する知識を持っています)。 Generalized PWid FEC Elementを運んで、Label MappingメッセージはFEC TLVを含んでいます(0×81をタイプしてください)。 Generalized PWid FEC要素は阿木、SAII、およびTAII情報を含んでいます。
Next, when PE2 receives such a Label Mapping message, PE2 interprets the message as a request to set up a PW whose endpoint (at PE2) is the Forwarder identified by the TAI. From the perspective of the signaling protocol, exactly how PE2 maps AIs to Forwarders is a local matter. In some Virtual Private Wire Services (VPWS) provisioning models, the TAI might, for example, be a string that identifies a particular Attachment Circuit, such as "ATM3VPI4VCI5", or it might, for example, be a string, such as "Fred", that is associated by configuration with a particular Attachment Circuit. In VPLS, the AGI could be a VPN-id, identifying a particular VPLS instance.
PE2がそのようなLabel Mappingメッセージを受け取るとき、次に、PE2は終点(PE2の)がTAIによって特定されたForwarderであるPWをセットアップするという要求としてメッセージを解釈します。 シグナリングプロトコルの見解から、PE2がちょうどどうAIsをForwardersに写像するかは、地域にかかわる事柄です。 例えば、TAIはモデルに食糧を供給するいくつかのVirtual兵士のWire Services(VPWS)では特定のAttachment Circuitを特定するストリングであるかもしれません、「そうするかもしれなくて、例えば、構成によって特定の付属サーキットに関連づけられる「フレッド」などのストリングになってください」などのように。 VPLSでは、特定のVPLS例を特定して、AGIはVPN-イドであるかもしれません。
If PE2 cannot map the TAI to one of its Forwarders, then PE2 sends a Label Release message to PE1, with a Status Code of "Unassigned/Unrecognized TAI", and the processing of the Label Mapping message is complete.
PE2がForwardersの1つにTAIを写像できないなら、PE2はLabel ReleaseメッセージをPE1に送ります、「割り当てられなかったか認識されていないTAI」のStatus Codeと共に、そして、Label Mappingメッセージの処理は完全です。
The FEC TLV sent in a Label Release message is the same as the FEC TLV received in the Label Mapping being released (but without the interface parameter TLV). More generally, the FEC TLV is the same in all LDP messages relating to the same PW. In a Label Release, this means that the SAII is the remote peer's AII and the TAII is the sender's local AII.
FEC TLVがリリースされる(しかしインタフェース・パラメータTLVなしで)Label Mappingで受信したとき、FEC TLVは、Label Releaseメッセージが同じであることを送りました。 より一般に、FEC TLVはすべての自由民主党メッセージで同じPWに関連するのにおいて同じです。 Label Releaseでは、これは、SAIIがリモート同輩のAIIであることを意味します、そして、TAIIは送付者の地方のAIIです。
Martini, et al. Standards Track [Page 15] RFC 4447 PWE3 Using LDP April 2006
マティーニ、他 2006年4月に自由民主党を使用する標準化過程[15ページ]RFC4447PWE3
If the Label Mapping Message has a valid TAI, PE2 must decide whether to accept it. The procedures for so deciding will depend on the particular type of Forwarder identified by the TAI. Of course, the Label Mapping message may be rejected due to standard LDP error conditions as detailed in [RFC3036].
Label Mapping Messageに有効なTAIがあるなら、PE2は、それを受け入れるかどうか決めなければなりません。 そう決めるための手順はTAIによって特定されたForwarderの特定のタイプに頼るでしょう。 もちろん、Label Mappingメッセージは標準の自由民主党エラー条件のため[RFC3036]で詳しく述べられるように拒絶されるかもしれません。
If PE2 decides to accept the Label Mapping message, then it has to make sure that a PW LSP is set up in the opposite (PE1-->PE2) direction. If it has already signaled for the corresponding PW LSP in that direction, nothing more needs to be done. Otherwise, it must initiate such signaling by sending a Label Mapping message to PE1. This is very similar to the Label Mapping message PE2 received, but the SAI and TAI are reversed.
PE2が、Label Mappingメッセージを受け入れると決めるなら、PW LSPが反対(PE1-->PE2)の方向にセットアップされるのは確実にされなければなりません。 対応するPW LSPのために既にその方向に合図したなら、それ以上何もは、する必要がありません。 さもなければ、それは、Label MappingメッセージをPE1に送ることによって、そのようなシグナリングを開始しなければなりません。 これはPE2が受け取ったLabel Mappingメッセージと非常に同様ですが、SAIとTAIは逆にされます。
Thus, a bidirectional PW consists of two LSPs, where the FEC of one has the SAII and TAII reversed with respect to the FEC of the other.
したがって、双方向のPWを2LSPsから成らせます。そこでは、1のFECがもう片方のFECに関してSAIIとTAIIを逆にさせます。
5.4. Signaling of Pseudowire Status
5.4. Pseudowire状態のシグナリング
5.4.1. Use of Label Mappings Messages
5.4.1. ラベルマッピングメッセージの使用
The PEs MUST send Label Mapping Messages to their peers as soon as the PW is configured and administratively enabled, regardless of the attachment circuit state. The PW label should not be withdrawn unless the operator administratively configures the pseudowire down (or the PW configuration is deleted entirely). Using the procedures outlined in this section, a simple label withdraw method MAY also be supported as a legacy means of signaling PW status and AC status. In any case, if the label-to-PW binding is not available, the PW MUST be considered in the down state.
PWが構成されて、行政上有効にされるとすぐに、PEsは彼らの同輩にLabel Mapping Messagesを送らなければなりません、付属サーキット州にかかわらず。 オペレータが、pseudowireがダウンするのを(PW構成は完全に削除されます)行政上構成しない場合、PWラベルを引っ込めるべきではありません。 概説された手順を用いて、また、遺産が意味するようにこのセクション、簡単なラベルが引き下がるaでは方法はシグナリングPW状態と交流状態についてサポートされるかもしれません。 どのような場合でも、PW MUST、ラベルからPWとの結合が利用可能でないなら下に状態で考えられてください。
Once the PW status negotiation procedures are completed, if they result in the use of the label withdraw method for PW status communication, and this method is not supported by one of the PEs, then that PE must send a Label Release Message to its peer with the following error:
PW状態交渉手順がいったん完了していると、ラベルの使用をもたらすなら、PW状態コミュニケーションのために方法を引き下がらせてください。そうすれば、この方法はPEsのひとりによって支持されません、PEが以下の誤りと共にLabel Release Messageを同輩に送らなければならないその時:
"Label Withdraw PW Status Method Not Supported"
「ラベルは方法が支持しなかったPW状態を引き下がらせます」
If the label withdraw method for PW status communication is selected for the PW, it will result in the Label Mapping Message being advertised only if the attachment circuit is active. The PW status signaling procedures described in this section MUST be fully implemented.
ラベルがPWのために方法を引き下がらせるなら、状態コミュニケーションはPWのために選択されて、それは付属サーキットがアクティブである場合にだけ広告に掲載されるLabel Mapping Messageをもたらすでしょう。 このセクションで説明されたPW状態シグナリング手順を完全に実行しなければなりません。
Martini, et al. Standards Track [Page 16] RFC 4447 PWE3 Using LDP April 2006
マティーニ、他 2006年4月に自由民主党を使用する標準化過程[16ページ]RFC4447PWE3
5.4.2. Signaling PW Status
5.4.2. シグナリングPW状態
The PE devices use an LDP TLV to indicate status to their remote peers. This PW Status TLV contains more information than the alternative simple Label Withdraw message.
PE装置は、彼らのリモート同輩に状態を示すのにLDP TLVを使用します。 このPW Status TLVは代替の簡単なLabel Withdrawメッセージより多くの情報を含んでいます。
The format of the PW Status TLV is:
PW Status TLVの形式は以下の通りです。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1|0| PW Status (0x096A) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Status Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |1|0| PW状態、(0x096A)| 長さ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ステータスコード| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The status code is a 4-octet bit field as specified in the PW IANA Allocations document [IANA]. The length specifies the length of the Status Code field in octets (equal to 4).
ステータスコードは指定されるとしてPW IANA Allocationsドキュメント[IANA]の4八重奏の噛み付いている分野です。 長さは八重奏(4と等しい)における、Status Code分野の長さを指定します。
Each bit in the status code field can be set individually to indicate more than a single failure at once. Each fault can be cleared by sending an appropriate Notification message in which the respective bit is cleared. The presence of the lowest bit (PW Not Forwarding) acts only as a generic failure indication when there is a link-down event for which none of the other bits apply.
ステータスコード分野の各ビットがすぐにただ一つの失敗以上を示すように個別に設定できます。 それぞれのビットがきれいにされる適切なNotificationメッセージを送ることによって、各欠点をクリアすることができます。 他のビットのいずれも適用されない下にリンクする出来事があるとき、最も低いビット(PW Not Forwarding)の存在は単に一般的な失敗指示として機能します。
The Status TLV is transported to the remote PW peer via the LDP Notification message. The general format of the Notification Message is:
Status TLVは自由民主党NotificationメッセージでリモートPW同輩に輸送されます。 Notification Messageの一般形式は以下の通りです。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| Notification (0x0001) | Message Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Status (TLV) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PW Status TLV |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PWId FEC TLV or Generalized ID FEC TLV |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0| 通知(0×0001)| メッセージ長| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | メッセージID| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 状態(TLV)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | PW状態TLV| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | PWId FEC TLVか一般化されたID FEC TLV| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Martini, et al. Standards Track [Page 17] RFC 4447 PWE3 Using LDP April 2006
マティーニ、他 2006年4月に自由民主党を使用する標準化過程[17ページ]RFC4447PWE3
The Status TLV status code is set to 0x00000028, "PW status", to indicate that PW status follows. Since this notification does not refer to any particular message, the Message Id and Message Type fields are set to 0.
0×00000028、「PW状態」にStatus TLVステータスコードが、PW状態が従うのを示すように設定されます。 この通知がどんな特定のメッセージも示さないので、Message IdとMessage Type分野は0に用意ができています。
The PW FEC TLV SHOULD not include the interface parameter sub-TLVs, as they are ignored in the context of this message. When a PE's attachment circuit encounters an error, use of the PW Notification Message allows the PE to send a single "wild card" status message, using a PW FEC TLV with only the group ID set, to denote this change in status for all affected PW connections. This status message contains either the PW FEC TLV with only the group ID set, or else it contains the Generalized FEC TLV with only the PW Grouping ID TLV.
PW FEC TLV SHOULDはインタフェース・パラメータサブTLVsを含んでいません、彼らがこのメッセージの文脈で無視されるとき。 PEの付属サーキットが誤りに遭遇するとき、PEはPW Notification Messageの使用でただ一つの「ワイルドカード」ステータスメッセージを送ることができます、すべての影響を受けるPW接続のために状態のこの変化を指示するのにグループIDセットだけがあるPW FEC TLVを使用して。 このステータスメッセージがグループIDセットだけがあるPW FEC TLVを含んでいるか、またはそれはPW Grouping ID TLVだけとGeneralized FEC TLVを含んでいます。
As mentioned above, the Group ID field of the PWid FEC element, or the PW Grouping ID TLV used with the Generalized ID FEC element, can be used to send a status notification for all arbitrary sets of PWs. This procedure is OPTIONAL, and if it is implemented, the LDP Notification message should be as follows: If the PWid FEC element is used, the PW information length field is set to 0, the PW ID field is not present, and the interface parameter sub-TLVs are not present. If the Generalized FEC element is used, the AGI, SAII, and TAII are not present, the PW information length field is set to 0, the PW Grouping ID TLV is included, and the Interface Parameters TLV is omitted. For the purpose of this document, this is called the "wild card PW status notification procedure", and all PEs implementing this design are REQUIRED to accept such a notification message but are not required to send it.
以上のように、PWsのすべての任意のセットのための状態通知を送るのにPWid FEC要素のGroup ID分野、またはGeneralized ID FEC要素と共に使用されるPW Grouping ID TLVは使用できます。 この手順はOPTIONALです、そして、それが実行されるなら、自由民主党Notificationメッセージは以下の通りであるべきです: PWid FEC要素が使用されているなら、PW情報長さの分野は0に設定されます、そして、PW ID分野は存在していません、そして、インタフェース・パラメータサブTLVsは存在していません。 Generalized FEC要素が使用されているなら、阿木、SAII、およびTAIIは出席していません、そして、PW情報長さの分野は0に設定されます、そして、PW Grouping ID TLVは含まれています、そして、Interface Parameters TLVは省略されます。 このドキュメントの目的のために、これが「ワイルドカードPW状態通知手順」と呼ばれて、このデザインを実行するすべてのPEsが、そのような通知メッセージを受け入れるREQUIREDですが、それを送るのに必要であるというわけではありません。
5.4.3. Pseudowire Status Negotiation Procedures
5.4.3. Pseudowire状態交渉手順
When a PW is first set up, the PEs MUST attempt to negotiate the usage of the PW status TLV. This is accomplished as follows: A PE that supports the PW Status TLV MUST include it in the initial Label Mapping message following the PW FEC and the interface parameter sub-TLVs. The PW Status TLV will then be used for the lifetime of the pseudowire. This is shown in the following diagram:
PWが第一セットであるときに、上がって、PEsは、用法を交渉するのをPW状態TLVを試みなければなりません。 これは以下の通り達成されます: PW FECとインタフェース・パラメータサブTLVsに続いて、PW Status TLVを支持するPEは初期のLabel Mappingメッセージにそれを含まなければなりません。 そして、PW Status TLVはpseudowireの生涯に使用されるでしょう。 これは以下のダイヤグラムで示されます:
Martini, et al. Standards Track [Page 18] RFC 4447 PWE3 Using LDP April 2006
マティーニ、他 2006年4月に自由民主党を使用する標準化過程[18ページ]RFC4447PWE3
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ PWId FEC or Generalized ID FEC +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface Parameters |
| " |
| " |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0|0| Generic Label (0x0200) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Label |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1|0| PW Status (0x096A) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Status Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + PWId FECか一般化されたID FEC+| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | インタフェース・パラメータ| | " | | " | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0|0| 一般的なラベル(0×0200)| 長さ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ラベル| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |1|0| PW状態、(0x096A)| 長さ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ステータスコード| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
If a PW Status TLV is included in the initial Label Mapping message for a PW, then if the Label Mapping message from the remote PE for that PW does not include a PW status TLV, or if the remote PE does not support the PW Status TLV, the PW will revert to the label withdraw method of signaling PW status. Note that if the PW Status TLV is not supported by the remote peer, the peer will automatically ignore it, since the I (ignore) bit is set in the TLV. The PW Status TLV, therefore, will not be present in the corresponding FEC advertisement from the remote LDP peer, which results in exactly the above behavior.
PW Status TLVが含まれているなら、次に、リモートPEがPW Status TLVを支持しないならそのPWのためのリモートPEからのLabel MappingメッセージがPW状態TLVを含んでいないなら、PWに関して、PWがラベルに戻るという初期のLabel Mappingメッセージでは、PW状態に合図する方法を引き下がらせてください。 PW Status TLVがリモート同輩によって支持されないと、同輩が自動的にそれを無視することに注意してください、I(無視する)ビットがTLVに設定されるので。 したがって、PW Status TLVはリモート自由民主党の同輩からの対応するFEC広告に存在しないでしょう。(その同輩は、まさに上の振舞いをもたらします)。
If the PW Status TLV is not present following the FEC TLV in the initial PW Label Mapping message received by a PE, then the PW Status TLV will not be used, and both PEs supporting the pseudowire will revert to the label withdraw procedure for signaling status changes.
PEによって受け取られた初期のPW Label MappingメッセージでFEC TLVに続いて、PW Status TLVが存在していないと、PW Status TLVは使用されないでしょう、そして、pseudowireを支持するとラベルに振り向けられる両方のPEsはシグナリング状態変化のために手順を引き下がらせます。
If the negotiation process results in the usage of the PW status TLV, then the actual PW status is determined by the PW status TLV that was sent within the initial PW Label Mapping message. Subsequent updates of PW status are conveyed through the notification message.
交渉の過程がPW状態TLVの使用法をもたらすなら、実際のPW状態は初期のPW Label Mappingメッセージの中で送られたPW状態TLVのそばで決定しています。 PW状態のその後のアップデートは通知メッセージを通して伝えられます。
5.5. Interface Parameters Sub-TLV
5.5. インタフェース・パラメータサブTLV
This field specifies interface-specific parameters. When applicable, it MUST be used to validate that the PEs and the ingress and egress ports at the edges of the circuit have the necessary capabilities to interoperate with each other. The field structure is defined as follows:
この分野はインタフェース特有のパラメタを指定します。 適切であるときに、それを有効にするのに使用されて、サーキットの縁のPEs、イングレス、および出口港には互いと共に共同利用する必要機能があるということであるに違いありません。 磁場構造は以下の通り定義されます:
Martini, et al. Standards Track [Page 19] RFC 4447 PWE3 Using LDP April 2006
マティーニ、他 2006年4月に自由民主党を使用する標準化過程[19ページ]RFC4447PWE3
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sub-TLV Type | Length | Variable Length Value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Variable Length Value |
| " |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | サブTLVはタイプします。| 長さ| 可変長値| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 可変長値| | " | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The interface parameter sub-TLV type values are specified in "IANA Allocations for Pseudowire Edge to Edge Emulation (PWE3)" [IANA].
インタフェース・パラメータサブTLVタイプ値は「PseudowireのためのIANA配分はエミュレーション(PWE3)を斜めに進ませるために斜めに進むところ」で[IANA]指定されます。
The Length field is defined as the length of the interface parameter including the parameter id and length field itself. Processing of the interface parameters should continue when unknown interface parameters are encountered, and they MUST be silently ignored.
Length分野はパラメタイドと長さの分野自体を含むインタフェース・パラメータの長さと定義されます。 未知のインタフェース・パラメータが遭遇して、静かにそれらを無視しなければならないとき、インタフェース・パラメータの処理は続くべきです。
- Interface MTU sub-TLV type
- インタフェースMTUサブTLVはタイプします。
A 2-octet value indicating the MTU in octets. This is the Maximum
Transmission Unit, excluding encapsulation overhead, of the egress
packet interface that will be transmitting the decapsulated PDU
that is received from the MPLS-enabled network. This parameter is
applicable only to PWs transporting packets and is REQUIRED for
these PW types. If this parameter does not match in both
directions of a specific PW, that PW MUST NOT be enabled.
八重奏でMTUを示す2八重奏の値。 これはMaximum Transmission Unitです、MPLSによって可能にされたネットワークから受け取られるdecapsulated PDUを伝える出口のパケットインタフェースのカプセル化オーバーヘッドを除いて。 このパラメタは、パケットを輸送するPWsだけに適切であり、これらのPWタイプのためのREQUIREDです。 パラメタはこれであるなら特定のPWの両方の方向に合わないで、PW MUST NOTは有効にされます。
- Optional Interface Description string sub-TLV type
- 任意のInterface記述ストリングサブTLVはタイプします。
This arbitrary, and OPTIONAL, interface description string is used
to send a human-readable administrative string describing the
interface to the remote. This parameter is OPTIONAL and is
applicable to all PW types. The interface description parameter
string length is variable and can be from 0 to 80 octets. Human-
readable text MUST be provided in the UTF-8 charset using the
Default Language [RFC2277].
そして、これほど任意である、OPTIONAL、人間読み込み可能な管理ストリングにインタフェースについてリモートに説明させるのにインタフェース記述ストリングは使用されます。 このパラメタは、OPTIONALであり、すべてのPWタイプに適切です。 インタフェース記述パラメタストリング長は、可変であり、0〜80の八重奏であるかもしれません。 Default Language[RFC2277]を使用して、人間の読み込み可能なテキストをUTF-8 charsetに提供しなければなりません。
6. Control Word
6. コントロールWord
6.1. PW Types for Which the Control Word is REQUIRED
6.1. Which Control WordのためのPW TypesはREQUIREDです。
The Label Mapping messages that are sent in order to set up these PWs MUST have c=1. When a Label Mapping message for a PW of one of these types is received and c=0, a Label Release message MUST be sent, with an "Illegal C-bit" status code. In this case, the PW will not be enabled.
これらのPWsをセットアップするために送られるLabel Mappingメッセージはc=1を持たなければなりません。 これらのタイプのひとりのPWへのLabel Mappingメッセージがいつ、受信されているか、そして、c=0、Label Releaseメッセージを送らなければなりません、「不法なC-ビット」ステータスコードで。 この場合、PWは有効にされないでしょう。
Martini, et al. Standards Track [Page 20] RFC 4447 PWE3 Using LDP April 2006
マティーニ、他 2006年4月に自由民主党を使用する標準化過程[20ページ]RFC4447PWE3
6.2. PW Types for Which the Control Word is NOT Mandatory
6.2. Which Control WordのためのPW TypesはMandatoryではありません。
If a system is capable of sending and receiving the control word on PW types for which the control word is not mandatory, then each such PW endpoint MUST be configurable with a parameter that specifies whether the use of the control word is PREFERRED or NOT PREFERRED. For each PW, there MUST be a default value of this parameter. This specification does NOT state what the default value should be.
規制単語が義務的でないPWタイプに関する規制知らせを送って、システムが受け取ることができるなら、そのようなそれぞれのPW終点は規制単語の使用がPREFERREDかそれともNOT PREFERREDであるかを指定するパラメタで構成可能であるに違いありません。 各PWのために、このパラメタのデフォルト値があるに違いありません。 この仕様は、デフォルト値が何であるべきであるかを述べません。
If a system is NOT capable of sending and receiving the control word on PW types for which the control word is not mandatory, then it behaves exactly as if it were configured for the use of the control word to be NOT PREFERRED.
規制単語が義務的でないPWタイプに関する規制知らせを送って、システムが受け取ることができないなら、それはまるでちょうど規制単語の使用がNOT PREFERREDであるために構成されるかのように反応します。
If a Label Mapping message for the PW has already been received but no Label Mapping message for the PW has yet been sent, then the procedure is as follows:
既にPWへのLabel Mappingメッセージを受け取りましたが、まだPWへのLabel Mappingメッセージを全く送らないなら、手順は以下の通りです:
-i. If the received Label Mapping message has c=0, send a Label
Mapping message with c=0; the control word is not used.
-i。 受信されたLabel Mappingメッセージにc=0があるなら、c=0があるLabel Mappingメッセージを送ってください。 規制単語は使用されていません。
-ii. If the received Label Mapping message has c=1 and the PW is
locally configured such that the use of the control word is
preferred, then send a Label Mapping message with c=1; the
control word is used.
-ii。 受信されたLabel Mappingメッセージにはc=1があって、PWが局所的に構成されるので規制単語の使用が好まれるなら、c=1があるLabel Mappingメッセージを送ってください。 規制単語は使用されています。
-iii. If the received Label Mapping message has c=1 and the PW is
locally configured such that the use of the control word is
not preferred or the control word is not supported, then act
as if no Label Mapping message for the PW had been received
(i.e., proceed to the next paragraph).
-iii。 受信されたLabel Mappingメッセージにはc=1があって、PWが局所的に構成されるので規制単語の使用が好まれないか、または規制単語がサポートされないなら、まるでPWへのLabel Mappingメッセージを全く受け取っていないかのように(すなわち、次のパラグラフに続いてください)、行動してください。
If a Label Mapping message for the PW has not already been received (or if the received Label Mapping message had c=1 and either local configuration says that the use of the control word is not preferred or the control word is not supported), then send a Label Mapping message in which the c bit is set to correspond to the locally configured preference for use of the control word. (That is, set c=1 if locally configured to prefer the control word, and set c=0 if locally configured to prefer not to use the control word or if the control word is not supported).
PWへのLabel Mappingメッセージが既に受け取られていないなら(受信されたLabel Mappingメッセージにはc=1があって、どちらの地方の構成も、規制単語の使用が好まれないか、または規制単語がサポートされないと言うなら)、cビットが規制単語の使用のための局所的に構成された好みに相当するように設定されるLabel Mappingメッセージを送ってください。 (すなわち、規制言葉を好むために局所的に構成されるならc=1を設定して、規制単語を使用しないのを好むために局所的に構成されるか、または規制単語がサポートされないなら、c=0を設定します。)
Martini, et al. Standards Track [Page 21] RFC 4447 PWE3 Using LDP April 2006
マティーニ、他 2006年4月に自由民主党を使用する標準化過程[21ページ]RFC4447PWE3
The next action depends on what control message is next received for that PW. The possibilities are as follows:
次の動作はどんなコントロールメッセージがそのPWにおいて受け取られていた状態で次であるかよります。 可能性は以下の通りです:
-i. A Label Mapping message with the same c bit value as
specified in the Label Mapping message that was sent. PW
setup is now complete, and the control word is used if c=1
but is not used if c=0.
-i。 指定されるのと同じc噛み付いている値が送られたLabel MappingメッセージにあるLabel Mappingメッセージ。 PWセットアップが現在、完全であり、規制単語は、c=1であるなら使用されていますが、c=0であるなら使用されていません。
-ii. A Label Mapping message with c=1, but the Label Mapping
message that was sent has c=0. In this case, ignore the
received Label Mapping message and continue to wait for the
next control message for the PW.
-ii。 c=1があるので、送られたLabel Mappingメッセージだけがc=0を持っているというLabel Mappingメッセージ。 この場合、受信されたLabel Mappingメッセージを無視してください、そして、PWへの次のコントロールメッセージを待ち続けてください。
-iii. A Label Mapping message with c=0, but the Label Mapping
message that was sent has c=1. In this case, send a Label
Withdraw message with a "Wrong C-bit" status code, followed
by a Label Mapping message that has c=0. PW setup is now
complete, and the control word is not used.
-iii。 c=0があるので、送られたLabel Mappingメッセージだけがc=1を持っているというLabel Mappingメッセージ。 この場合、c=0を持っているLabel Mappingメッセージがあとに続いた「間違ったC-ビット」ステータスコードがあるLabel Withdrawメッセージを送ってください。 PWセットアップは現在完全です、そして、規制単語は使用されていません。
-iv. A Label Withdraw message with the "Wrong c-bit" status code.
Treat as a normal Label Withdraw, but do not respond.
Continue to wait for the next control message for the PW.
-iv。 「間違ったc-ビット」ステータスコードがあるLabel Withdrawメッセージ。 正常なLabel Withdrawとして扱いなさい、ただし、応じないでください。 PWへの次のコントロールメッセージを待ち続けてください。
If at any time after a Label Mapping message has been received a corresponding Label Withdraw or Release is received, the action taken is the same as for any Label Withdraw or Release that might be received at any time.
対応するLabel WithdrawかReleaseがLabel Mappingメッセージを受け取った後にいつでも受け取られているなら、取られた行動はいつでも受け取られるどんなLabel WithdrawやReleaseのようにも同じです。
If both endpoints prefer the use of the control word, this procedure will cause it to be used. If either endpoint prefers not to use the control word or does not support the control word, this procedure will cause it not to be used. If one endpoint prefers to use the control word but the other does not, the one that prefers not to use it is has no extra protocol to execute; it just waits for a Label Mapping message that has c=0.
両方の終点であるなら、規制単語の使用を好んでください、そして、この手順でそれを使用するでしょう。 どちらの終点も規制単語を使用しないのを好むか、または規制言葉をサポートしないと、この手順で、それを使用しないでしょう。 1つの終点が、規制単語を使用するのを好みますが、もう片方が好むというわけではないなら、それが使用でないより好むのは実行するどんな付加的なプロトコルも持っていません。 それはただc=0を持っているLabel Mappingメッセージを待っています。
The diagram in Appendix A illustrates the above procedure.
Appendix Aのダイヤグラムは上の手順を例証します。
6.3. LDP Label Withdrawal Procedures
6.3. 自由民主党ラベル退出手順
As mentioned above, the Group ID field of the PWid FEC element, or the PW Grouping ID TLV used with the Generalized ID FEC element, can be used to withdraw all PW labels associated with a particular PW group. This procedure is OPTIONAL, and if it is implemented, the LDP Label Withdraw message should be as follows: If the PWid FEC element is used, the PW information length field is set to 0, the PW ID field is not present, the interface parameter sub-TLVs are not present, and the Label TLV is not present.
以上のように、特定のPWグループに関連しているすべてのPWラベルを引っ込めるのにPWid FEC要素のGroup ID分野、またはGeneralized ID FEC要素と共に使用されるPW Grouping ID TLVは使用できます。 この手順はOPTIONALです、そして、それが実装されるなら、自由民主党Label Withdrawメッセージは以下の通りであるべきです: PWid FEC要素が使用されているなら、PW情報長さの分野は0に設定されます、そして、PW ID分野は存在していません、そして、インタフェース・パラメータサブTLVsは存在していません、そして、Label TLVは存在していません。
Martini, et al. Standards Track [Page 22] RFC 4447 PWE3 Using LDP April 2006
マティーニ、他 2006年4月に自由民主党を使用する標準化過程[22ページ]RFC4447PWE3
If the Generalized FEC element is used, the AGI, SAII, and TAII are not present, the PW information length field is set to 0, the PW Grouping ID TLV is included, the Interface Parameters TLV is not present, and the Label TLV is not present. For the purpose of this document, this is called the "wild card withdraw procedure", and all PEs implementing this design are REQUIRED to accept such withdrawn message but are not required to send it. Note that the PW Grouping ID TLV only applies to PWs using the Generalized ID FEC element, while the Group ID only applies to PWid FEC element.
Generalized FEC要素が使用されているなら、阿木、SAII、およびTAIIは出席していません、そして、PW情報長さの分野は0に設定されます、そして、PW Grouping ID TLVは含まれています、そして、Interface Parameters TLVは存在していません、そして、Label TLVは存在していません。 このドキュメントの目的のために、これが呼ばれる、「ワイルドカードは手順を引き下がっ」て、このデザインを実装するすべてのPEsが、あれほどよそよそしいメッセージを受け入れるREQUIREDですが、それを送るのに必要であるというわけではありません。 PW Grouping ID TLVがGeneralized ID FEC要素を使用することでPWsに適用するだけであることに注意してください、Group IDはPWid FEC要素に適用されるだけですが。
The interface parameter sub-TLVs, or TLV, MUST NOT be present in any LDP PW Label Withdraw or Label Release message. A wild card Label Release message MUST include only the group ID, or Grouping ID TLV. A Label Release message initiated by a PE router must always include the PW ID.
インタフェース・パラメータサブTLVs、またはTLVがどんな自由民主党PW Label WithdrawやLabel Releaseメッセージにも存在しているはずがありません。 ワイルドカードLabel ReleaseメッセージはグループだけのID、またはGrouping ID TLVを含まなければなりません。 PEルータによって開始されたLabel ReleaseメッセージはいつもPW IDを含まなければなりません。
6.4. Sequencing Considerations
6.4. 配列問題
In the case where the router considers the sequence number field in the control word, it is important to note the following details when advertising labels.
ルータが一連番号分野を考える場合では、ラベルの広告を出すとき、規制単語であり、以下の詳細に注意するのは重要です。
6.4.1. Label Advertisements
6.4.1. ラベル広告
After a label has been withdrawn by the output router and/or released by the input router, care must be taken not to advertise (re-use) the same released label until the output router can be reasonably certain that old packets containing the released label no longer persist in the MPLS-enabled network.
ラベルが出力ルータによって引き下がられる、そして/または、入力ルータによって放出された後に、出力ルータがリリースされたラベルを含む古いパケットがもうMPLSによって可能にされたネットワークに固執しないのを合理的に確信する場合があるまで同じリリースされたラベルの広告を出さない(再使用する)ように注意しなければなりません。
This precaution is required to prevent the imposition router from restarting packet forwarding with a sequence number of 1 when it receives a Label Mapping message that binds the same FEC to the same label if there are still older packets in the network with a sequence number between 1 and 32768. For example, if there is a packet with sequence number=n, where n is in the interval [1,32768] traveling through the network, it would be possible for the disposition router to receive that packet after it re-advertises the label. Since the label has been released by the imposition router, the disposition router SHOULD be expecting the next packet to arrive with a sequence number of 1. Receipt of a packet with a sequence number equal to n will result in n packets potentially being rejected by the disposition router until the imposition router imposes a sequence number of n+1 into a packet. Possible methods to avoid this are for the disposition router always to advertise a different PW label, or for the disposition router to wait for a sufficient time before
この注意が、ネットワークにより古いパケットが1〜32768の一連番号と共にまだあれば同じラベルに同じFECを縛るLabel Mappingメッセージを受け取るとき、賦課ルータが1の一連番号でパケット推進を再開するのを防ぐのに必要です。 例えば、nがネットワークを通って旅行しながら間隔[1、32768]にある一連番号=nでのパケットがあれば、ラベルの再広告を出した後に気質ルータがそのパケットを受けるのは、可能でしょう。 以来、ラベルは、1の一連番号と共に到着するように賦課ルータ、次のパケットを予想することである気質ルータSHOULDによって放出されています。 nと等しい一連番号があるパケットの領収書は賦課ルータがn+1の一連番号をパケットに課すまで気質ルータによって潜在的に拒絶されるnパケットをもたらすでしょう。 これを避ける可能なメソッドはいつも異なったPWラベルの広告を出すか、または気質ルータが十分な時以前を待つ気質ルータのためのものです。
Martini, et al. Standards Track [Page 23] RFC 4447 PWE3 Using LDP April 2006
マティーニ、他 2006年4月に自由民主党を使用する標準化過程[23ページ]RFC4447PWE3
attempting to re-advertise a recently released label. This is only an issue when sequence number processing is enabled at the disposition router.
最近リリースされたラベルの再広告を出すのを試みます。 一連番号処理が気質ルータで可能にされるときだけ、これは問題です。
6.4.2. Label Release
6.4.2. ラベルリリース
In situations where the imposition router wants to restart forwarding of packets with sequence number 1, the router shall 1) send to the disposition router a Label Release Message, and 2) send to the disposition router a Label Request message. When sequencing is supported, advertisement of a PW label in response to a Label Request message MUST also consider the issues discussed in the section on Label Advertisements.
賦課ルータが再開したがっている一連番号1、ルータがあるパケットの推進がそうする状況で、1は)気質ルータにLabel Release Messageを送ります、そして、2は)Label Requestメッセージを気質ルータに送ります。 また、配列がサポートされるとき、Label Requestメッセージに対応したPWラベルの広告はLabel Advertisementsの上のセクションで議論した問題を考えなければなりません。
7. IANA Considerations
7. IANA問題
7.1. LDP TLV TYPE
7.1. 自由民主党TLVはタイプします。
This document uses several new LDP TLV types; IANA already maintains a registry of name "TLV TYPE NAME SPACE" defined by RFC 3036. The following values are suggested for assignment:
このドキュメントはいくつかの新しいLDP TLVタイプを使用します。 IANAは既にRFC3036によって定義された名前「TLV型名スペース」の登録を維持します。 以下の値は課題のために示されます:
TLV type Description
=====================================
0x096A PW Status TLV
0x096B PW Interface Parameters TLV
0x096C Group ID TLV
TLVは記述をタイプします。===================================== 0x096A PW状態TLV 0x096B PWインタフェース・パラメータTLV 0x096CグループID TLV
7.2. LDP Status Codes
7.2. 自由民主党ステータスコード
This document uses several new LDP status codes; IANA already maintains a registry of name "STATUS CODE NAME SPACE" defined by RFC 3036. The following values are suggested for assignment:
このドキュメントはいくつかの新しい自由民主党ステータスコードを使用します。 IANAは既にRFC3036によって定義された名前「ステータスコード名前スペース」の登録を維持します。 以下の値は課題のために示されます:
Range/Value E Description Reference ------------- ----- ---------------------- --------- 0x00000024 0 Illegal C-Bit [RFC4447] 0x00000025 0 Wrong C-Bit [RFC4447] 0x00000026 0 Incompatible bit-rate [RFC4447] 0x00000027 0 CEP-TDM mis-configuration [RFC4447] 0x00000028 0 PW Status [RFC4447] 0x00000029 0 Unassigned/Unrecognized TAI [RFC4447] 0x0000002A 0 Generic Misconfiguration Error [RFC4447] 0x0000002B 0 Label Withdraw PW Status Method [RFC4447]
範囲/値のE記述参照------------- ----- ---------------------- --------- 0×00000024 0不法なC-ビット[RFC4447]0x00000025 0Wrong C-ビット[RFC4447]0x00000026 0Incompatibleビット伝送速度[RFC4447]0×00000027 0CEP-TDM誤構成[RFC4447]0x00000028 0のPW Status[RFC4447]0x00000029 0Unassigned/認識されていないTAI[RFC4447]0x0000002A0Generic Misconfiguration Error[RFC4447]0x0000002B0Label Withdraw PW Status Method[RFC4447]
Martini, et al. Standards Track [Page 24] RFC 4447 PWE3 Using LDP April 2006
マティーニ、他 2006年4月に自由民主党を使用する標準化過程[24ページ]RFC4447PWE3
7.3. FEC Type Name Space
7.3. FEC型名スペース
This document uses two new FEC element types, 0x80 and 0x81, from the registry "FEC Type Name Space" for the Label Distribution Protocol (LDP RFC 3036).
このドキュメントは2人の新しいFEC要素型、0×80、および0×81を使用します、Label Distributionプロトコル(LDP RFC3036)のための登録「FEC型名スペース」から。
8. Security Considerations
8. セキュリティ問題
This document specifies the LDP extensions that are needed for setting up and maintaining pseudowires. The purpose of setting up pseudowires is to enable Layer 2 frames to be encapsulated in MPLS and transmitted from one end of a pseudowire to the other. Therefore, we treat the security considerations for both the data plane and the control plane.
このドキュメントはpseudowiresをセットアップして、維持するのに必要である自由民主党の拡大を指定します。 pseudowiresをセットアップする目的はLayer2フレームがMPLSでカプセル化されて、pseudowireの片端からもう片方まで伝えられるのを可能にすることです。 したがって、私たちはデータ飛行機と制御飛行機の両方のためにセキュリティ問題を扱います。
8.1. Data-Plane Security
8.1. データ飛行機セキュリティ
With regard to the security of the data plane, the following areas must be considered:
データ飛行機のセキュリティに関して、以下の領域を考えなければなりません:
- MPLS PDU inspection
- MPLS PDU spoofing
- MPLS PDU alteration
- MPLS PSN protocol security
- Access Circuit security
- Denial-of-service prevention on the PE routers
- MPLS PDU点検--MPLS PDUスプーフィング--MPLS PDU変更--MPLS PSNプロトコルセキュリティ--アクセスCircuitセキュリティ--PEルータにおけるサービスの否定防止
When an MPLS PSN is used to provide pseudowire service, there is a perception that security MUST be at least equal to the currently deployed Layer 2 native protocol networks that the MPLS/PW network combination is emulating. This means that the MPLS-enabled network SHOULD be isolated from outside packet insertion in such a way that it SHOULD not be possible to insert an MPLS packet into the network directly. To prevent unwanted packet insertion, it is also important to prevent unauthorized physical access to the PSN, as well as unauthorized administrative access to individual network elements.
MPLS PSNがpseudowireサービスを提供するのに使用されるとき、セキュリティが少なくともそうであるに違いない知覚がMPLS/PWネットワーク組み合わせが見習っている現在配布しているLayer2の固有のプロトコルネットワークと等しい状態であります。 これが、MPLSによって可能にされたネットワークSHOULDが外のパケット挿入からそのような方法で隔離されることを意味する、それ、それ、SHOULD、直接MPLSパケットをネットワークに挿入するのにおいて、可能であってください。 また、求められていないパケット挿入を防ぐために、PSNへの権限のない物理的なアクセスを防ぐのも重要です、個々のネットワーク要素への権限のない管理アクセスと同様に。
As mentioned above, as MPLS enabled network should not accept MPLS packets from its external interfaces (i.e., interfaces to CE devices or to other providers' networks) unless the top label of the packet was legitimately distributed to the system from which the packet is being received. If the packet's incoming interface leads to a different SP (rather than to a customer), an appropriate trust relationship must also be present, including the trust that the other SP also provides appropriate security measures.
以上のように、MPLSとして、パケットのトップラベルが合法的にパケットが受け取られているシステムに分配されない場合、可能にされたネットワークは外部のインタフェース(すなわち、CEデバイス、または、他のプロバイダーのネットワークへのインタフェース)からMPLSパケットを認めないでしょうに。 パケットの入って来るインタフェースが異なったSPに通じる、(むしろ、顧客、)、また、適切な信頼関係はまたもう片方のSPが適切な安全策を提供する信頼を含むプレゼントであるに違いありません。
The three main security problems faced when using an MPLS-enabled network to transport PWs are spoofing, alteration, and inspection.
PWsを輸送するのにMPLSによって可能にされたネットワークを使用するとき直面されていた3つの主な警備上の問題は、スプーフィングと、変更と、点検です。
Martini, et al. Standards Track [Page 25] RFC 4447 PWE3 Using LDP April 2006
マティーニ、他 2006年4月に自由民主党を使用する標準化過程[25ページ]RFC4447PWE3
First, there is a possibility that the PE receiving PW PDUs will get a PDU that appears to be from the PE transmitting the PW into the PSN, but that was not actually transmitted by the PE originating the PW. (That is, the specified encapsulations do not by themselves enable the decapsulator to authenticate the encapsulator.) A second problem is the possibility that the PW PDU will be altered between the time it enters the PSN and the time it leaves the PSN (i.e., the specified encapsulations do not by themselves assure the decapsulator of the packet's integrity.) A third problem is the possibility that the PDU's contents will be seen while the PDU is in transit through the PSN (i.e., the specification encapsulations do not ensure privacy.) How significant these issues are in practice depends on the security requirements of the applications whose traffic is being sent through the tunnel, and how secure the PSN itself is.
まず最初に、PW PDUsを受けるPEがPWをPSNに伝えながらPEからあるように見えましたが、実際にPWを溯源するPEによって伝えられなかったPDUを手に入れる可能性があります。 (すなわち、指定されたカプセル化は、decapsulatorがencapsulatorを認証するのを自分たちで可能にしません。) 2番目の問題はPW PDUがそれがPSNに入る時、PSNを残す時の間で変更される(すなわち、指定されたカプセル化は自分たちでパケットの保全をdecapsulatorに保証しません。)可能性です。 3番目の問題はPDUがPSNを通したトランジット中である間(すなわち、仕様カプセル化は秘密を守りません。)PDUのコンテンツが見られる可能性です。 これらの問題が実際にはどれくらい重要であるかがトンネルを通してトラフィックをだれのものに送って、PSN自身がどれくらい安全であるかをアプリケーションのセキュリティ要件によります。
8.2. Control-Plane Security
8.2. 制御飛行機セキュリティ
General security considerations with regard to the use of LDP are specified in section 5 of RFC 3036. Those considerations also apply to the case where LDP is used to set up pseudowires.
自由民主党の使用に関する総合証券問題はRFC3036のセクション5で指定されます。 また、それらの問題は自由民主党がpseudowiresをセットアップするのに使用されるケースに適用されます。
A pseudowire connects two attachment circuits. It is important to make sure that LDP connections are not arbitrarily accepted from anywhere, or else a local attachment circuit might get connected to an arbitrary remote attachment circuit. Therefore, an incoming LDP session request MUST NOT be accepted unless its IP source address is known to be the source of an "eligible" LDP peer. 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 it could be discovered dynamically via an auto-discovery protocol that is itself trusted. (Obviously, if the auto-discovery protocol were not trusted, the set of "eligible peers" it produces could not be trusted.)
pseudowireは2個の付属回路をつなげます。 自由民主党の接続が任意にどこからも受け入れられないのを確実にするのが重要であるか、または地方の付属回路は任意の遠く離れた付属回路に関連づけられるかもしれません。 したがって、「適任」の自由民主党の同輩の源であることをIPソースアドレスを知らない場合、入って来る自由民主党のセッション要求を受け入れてはいけません。 適任の同輩のセットをあらかじめ設定できましたか(IPアドレスのリストとして、または、アドレス/マスク組み合わせのリストとして)、または信じられる自動発見プロトコルでダイナミックにそれを発見できるでしょう。 (明らかに、自動発見プロトコルが信じられないなら、それが生産する「適任の同輩」のセットを信じることができないでしょうに。)
Even if an LDP connection request appears to come from an eligible peer, its source address may have been spoofed. Therefore, some means of preventing source address spoofing must be in place. For example, if all the 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.
自由民主党の接続要求が適任の同輩から来るように見えても、ソースアドレスは偽造されたかもしれません。 したがって、ソースアドレススプーフィングを防ぐいくつかの手段が適所にあるに違いありません。 例えば、同じネットワークにすべての適任の同輩がいるなら、そのネットワークの境界ルータにおけるソースアドレスフィルタリングはソースアドレススプーフィングの可能性を排除するかもしれません。
The LDP MD5 authentication key option, as described in section 2.9 of RFC 3036, MUST be implemented, and for a greater degree of security, it must be used. This provides integrity and authentication for the LDP messages and eliminates the possibility of source address spoofing. Use of the MD5 option does not provide privacy, but privacy of the LDP control messages is not usually considered important. As the MD5 option relies on the configuration of pre-
RFC3036のセクション2.9で説明されるLDP MD5の認証の主要なオプションを実装しなければなりません、そして、より大きい度合いのセキュリティのために、それを使用しなければなりません。 これは、自由民主党メッセージのための保全と認証を提供して、ソースアドレススプーフィングの可能性を排除します。 MD5オプションの使用はプライバシーを提供しませんが、通常、自由民主党コントロールメッセージのプライバシーは重要であると考えられません。 オプションが構成を当てにするMD5、プレ
Martini, et al. Standards Track [Page 26] RFC 4447 PWE3 Using LDP April 2006
マティーニ、他 2006年4月に自由民主党を使用する標準化過程[26ページ]RFC4447PWE3
shared keys, it does not provide much protection against replay attacks. In addition, its reliance on pre-shared keys may make it very difficult to deploy when the set of eligible neighbors is determined by an auto-configuration protocol.
共有されたキーであり、それは反射攻撃に対する多くの保護を提供しません。 さらに、あらかじめ共有されたキーへの信用で、適任の隣人のセットが自動構成プロトコルで決定するとき展開するのは非常に難しくなるかもしれません。
When the Generalized ID FEC Element is used, it is possible that a particular LDP peer may be one of the eligible LDP peers but may not be the right one to connect to the particular attachment circuit identified by the particular instance of the Generalized ID FEC element. However, given that the peer is known to be one of the eligible peers (as discussed above), this would be the result of a configuration error, rather than a security problem. Nevertheless, it may be advisable for a PE to associate each of its local attachment circuits with a set of eligible peers rather than have just a single set of eligible peers associated with the PE as a whole.
Generalized ID FEC Elementが使用されているとき、特定の自由民主党の同輩が適任の自由民主党の同輩のひとりであるかもしれませんが、Generalized ID FEC要素の特定のインスタンスによって特定された特定の付属回路に関連づける正しいのでないことは可能です。 しかしながら、同輩が適任の同輩のひとりであることが知られているなら(上で議論するように)、これは警備上の問題よりむしろ構成誤りの結果でしょう。 それにもかかわらず、PEがまさしく全体でPEに関連している適任の同輩の1セットを持っているよりむしろそれぞれの地方の付属回路を1セットの適任の同輩に関連づけるのは、賢明であるかもしれません。
9. Acknowledgements
9. 承認
The authors wish to acknowledge the contributions of Vach Kompella, Vanson Lim, Wei Luo, Himanshu Shah, and Nick Weeds.
作者はVach Kompella、Vansonリム、ウェイ・羅、Himanshuシャー、およびニックWeedsの貢献を承諾したがっています。
10. Normative References
10. 引用規格
[RFC2119] Bradner S., "Key words for use in RFCs to Indicate
Requirement Levels", RFC 2119, March 1997
[RFC2119]ブラドナーS.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、RFC2119、1997年3月
[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月。
[RFC3032] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y.,
Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack
Encoding", RFC 3032, January 2001.
[RFC3032] ローゼン、E.、タッパン、D.、Fedorkow、G.、Rekhter、Y.、ファリナッチ、D.、李、T.、およびA.コンタ、「MPLSラベルスタックコード化」、RFC3032(2001年1月)。
[IANA] Martini, L., "IANA Allocations for Pseudowire Edge to Edge
Emulation (PWE3)", BCP 116, RFC 4446, April 2006.
[IANA] マティーニ、L.、「PseudowireのためのIANA配分はエミュレーション(PWE3)を斜めに進ませるために斜めに進む」BCP116、RFC4446、2006年4月。
11. Informative References
11. 有益な参照
[CEP] Malis, A., Pate, P., Cohen, R., Ed., and D. Zelig,
"SONET/SDH Circuit Emulation Service Over Packet (CEP)",
Work in Progress.
[CEP] Malis、A.、頭、P.、コーエン、R.(エド)、およびD.カメレオンマン、「Sonet/SDH回路エミュレーションサービスオーバーパケット(CEP)」は進行中で動きます。
[SAToP] Vainshtein, A., Ed. and Y. Stein, Ed., "Structure-Agnostic
TDM over Packet (SAToP)", Work in Progress.
エド[SAToP]Vainshtein、A.、Y.シタイン、エド、「パケット(SAToP)の上の構造不可知論者TDM」は進行中で働いています。
Martini, et al. Standards Track [Page 27] RFC 4447 PWE3 Using LDP April 2006
マティーニ、他 2006年4月に自由民主党を使用する標準化過程[27ページ]RFC4447PWE3
[FRAME] Martini, L., Ed. and C. Kawa, Ed., "Encapsulation Methods
for Transport of Frame Relay Over MPLS Networks", Work in
Progress.
エド[フレーム]マティーニ、L.、C.Kawa、エド、「MPLSネットワークの上のフレームリレーの輸送のためのカプセル化メソッド」は進行中で働いています。
[ATM] Martini, L., Ed., El-Aawar, N., and M. Bocci, Ed.,
"Encapsulation Methods for Transport of ATM Over MPLS
Networks", Work in Progress.
[気圧]マティーニ、L.(エド)、高架鉄道-Aawar、N.、およびM.Bocci(エド)、「MPLSネットワークの上の気圧の輸送のためのカプセル化メソッド」は進行中で働いています。
[PPPHDLC] Martini, L., Rosen, E., Heron, G., and A. Malis,
"Encapsulation Methods for Transport of PPP/HDLC Frames
Over IP and MPLS Networks", Work in Progress.
「IPとMPLSネットワークの上のppp/HDLCフレームの輸送のためのカプセル化メソッド」という[PPPHDLC]のマティーニ、L.、ローゼン、E.、サギ、G.、およびA.Malisは進行中で働いています。
[ETH] Martini, L., Rosen, E., El-Aawar, N., and G. Heron,
"Encapsulation Methods for Transport of Ethernet Over MPLS
Networks", RFC 4448, April 2006.
[ETH] マティーニ、L.、ローゼン、E.、高架鉄道-Aawar、N.、およびG.サギ、「MPLSネットワークの上のイーサネットの輸送のためのカプセル化メソッド」、RFC4448(2006年4月)。
[SDH] American National Standards Institute, "Synchronous Optical
Network Formats," ANSI T1.105-1995.
[SDH]American National Standards Institut、「同期式光通信網形式」、ANSI T1.105-1995。
[ITUG] ITU Recommendation G.707, "Network Node Interface For The
Synchronous Digital Hierarchy", 1996.
[ITUG]ITU推薦G.707、「同期デジタルハイアラーキのためのネットワーク・ノードインタフェース」、1996。
[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月。
[RFC2277] Alvestrand, H., "IETF Policy on Character Sets and
Languages", BCP 18, RFC 2277, January 1998.
[RFC2277] Alvestrand、H.、「文字コードと言語に関するIETF方針」、BCP18、RFC2277、1998年1月。
12. Additional Contributing Authors
12. 追加貢献している作者
Dimitri Stratton Vlachos Mazu Networks, Inc. 125 Cambridgepark Drive Cambridge, MA 02140
ディミトリストラットンVlachosマヅはInc.125Cambridgepark Driveケンブリッジ、MA 02140をネットワークでつなぎます。
EMail: d@mazunetworks.com
メール: d@mazunetworks.com
Jayakumar Jayakumar, Cisco Systems Inc. 225, E.Tasman, MS-SJ3/3, San Jose, CA, 95134
Jayakumar Jayakumar、シスコシステムズ株式会社225、E.タスマン、MS-SJ3/3、サンノゼ、カリフォルニア 95134
EMail: jjayakum@cisco.com
メール: jjayakum@cisco.com
Martini, et al. Standards Track [Page 28] RFC 4447 PWE3 Using LDP April 2006
マティーニ、他 2006年4月に自由民主党を使用する標準化過程[28ページ]RFC4447PWE3
Alex Hamilton, Cisco Systems Inc. 285 W. Tasman, MS-SJCI/3/4, San Jose, CA, 95134
アレックス・ハミルトン、シスコシステムズ株式会社285のW.タスマン、さん-SJCI/3/4、サンノゼ、カリフォルニア 95134
EMail: tahamilt@cisco.com
メール: tahamilt@cisco.com
Steve Vogelsang ECI Telecom Omega Corporate Center 1300 Omega Drive Pittsburgh, PA 15205
スティーブ・フォーゲルザング・ECIテレコムオメガ法人のセンター1300オメガDriveピッツバーグ、PA 15205
EMail: stephen.vogelsang@ecitele.com
メール: stephen.vogelsang@ecitele.com
John Shirron ECI Telecom Omega Corporate Center 1300 Omega Drive Pittsburgh, PA 15205
ジョン・Shirron ECIテレコムオメガ法人のセンター1300オメガDriveピッツバーグ、PA 15205
EMail: john.shirron@ecitele.com
メール: john.shirron@ecitele.com
Andrew G. Malis Tellabs 90 Rio Robles Dr. San Jose, CA 95134
サンノゼ、アンドリューG.Malis Tellabs90リオロブレスカリフォルニア博士 95134
EMail: Andy.Malis@tellabs.com
メール: Andy.Malis@tellabs.com
Vinai Sirkay Redback Networks 300 Holger Way San Jose, CA 95134
Vinai Sirkay20ドル紙幣は300オルガーWayサンノゼ(カリフォルニア)95134をネットワークでつなぎます。
EMail: vsirkay@redback.com
メール: vsirkay@redback.com
Vasile Radoaca Nortel Networks 600 Technology Park Billerica MA 01821
バシレRadoacaノーテルネットワーク600技術公園ビルリカMA 01821
EMail: vasile@nortelnetworks.com
メール: vasile@nortelnetworks.com
Martini, et al. Standards Track [Page 29] RFC 4447 PWE3 Using LDP April 2006
マティーニ、他 2006年4月に自由民主党を使用する標準化過程[29ページ]RFC4447PWE3
Chris Liljenstolpe Alcatel 11600 Sallie Mae Dr. 9th Floor Reston, VA 20193
Floorレストン、クリスLiljenstolpeアルカテル11600学生金融公庫博士の第9ヴァージニア 20193
EMail: chris.liljenstolpe@alcatel.com
メール: chris.liljenstolpe@alcatel.com
Dave Cooper Global Crossing 960 Hamlin Court Sunnyvale, CA 94089
デーヴ・桶屋グローバルクロッシング960ハムリン法廷サニーベル、カリフォルニア 94089
EMail: dcooper@gblx.net
メール: dcooper@gblx.net
Kireeti Kompella Juniper Networks 1194 N. Mathilda Ave Sunnyvale, CA 94089
Kireeti Kompella杜松は1194N.マチルダ・Aveサニーベル、カリフォルニア 94089をネットワークでつなぎます。
EMail: kireeti@juniper.net
メール: kireeti@juniper.net
Dan Tappan Cisco Systems, Inc. 1414 Massachusetts Avenue Boxborough, MA 01719
マサチューセッツ通りBoxborough、ダンタッパンシスコシステムズInc.1414MA 01719
EMail: tappan@cisco.com
メール: tappan@cisco.com
Martini, et al. Standards Track [Page 30] RFC 4447 PWE3 Using LDP April 2006
マティーニ、他 2006年4月に自由民主党を使用する標準化過程[30ページ]RFC4447PWE3
Appendix A. C-bit Handling Procedures Diagram
手順が図解する付録A.C-ビット操作
------------------
Y | Received Label | N
-------| Mapping Msg? |--------------
| ------------------ |
-------------- |
| | |
------- ------- |
| C=0 | | C=1 | |
------- ------- |
| | |
| ---------------- |
| | Control Word | N |
| | Capable? |----------- |
| ---------------- | |
| Y | | |
| | | |
| ---------------- | |
| | Control Word | N | |
| | Preferred? |---- | |
| ---------------- | | |
| Y | | | |
| | | | ----------------
| | | | | Control Word |
| | | | | Preferred? |
| | | | ----------------
| | | | N | Y |
| | | | | |
Send Send Send Send Send Send
C=0 C=1 C=0 C=0 C=0 C=1
| | | |
----------------------------------
| If receive the same as sent, |
| PW setup is complete. If not: |
----------------------------------
| | | |
------------------- -----------
| Receive | | Receive |
| C=1 | | C=0 |
------------------- -----------
| |
Wait for the Send
next message Wrong C-Bit
|
Send Label
Mapping Message
------------------ Y| 容認されたラベル| N-------| エムエスジーを写像しますか? |-------------- | ------------------ | -------------- | | | | ------- ------- | | C=0| | C=1| | ------- ------- | | | | | ---------------- | | | コントロールWord| N| | | できますか? |----------- | | ---------------- | | | Y| | | | | | | | ---------------- | | | | コントロールWord| N| | | | 都合のよい |---- | | | ---------------- | | | | Y| | | | | | | | ---------------- | | | | | コントロールWord| | | | | | 都合のよい | | | | | ---------------- | | | | N| Y| | | | | | | 発信、発信、発信、発信、発信、0 0 0 1 0C=C=C=C=C=C=1を送ってください。| | | | ---------------------------------- | 送るように同じように受信してください。| | PWセットアップは完全です。 そうでなければ: | ---------------------------------- | | | | ------------------- ----------- | 受信してください。| | 受信してください。| | C=1| | C=0| ------------------- ----------- | | 次のメッセージWrongがCで噛み付いたSendを待ってください。| ラベルマッピングメッセージを送ってください。
Martini, et al. Standards Track [Page 31] RFC 4447 PWE3 Using LDP April 2006
マティーニ、他 2006年4月に自由民主党を使用する標準化過程[31ページ]RFC4447PWE3
Authors' Addresses
作者のアドレス
Luca Martini Cisco Systems, Inc. 9155 East Nichols Avenue, Suite 400 Englewood, CO, 80112
ルカマティーニシスコシステムズ, Inc.9155のEastニコルズAvenue、イングルウッド、Suite400CO 80112
EMail: lmartini@cisco.com
メール: lmartini@cisco.com
Nasser El-Aawar Level 3 Communications, LLC. 1025 Eldorado Blvd. Broomfield, CO, 80021
LLC、ナセル高架鉄道-Aawarは3つのコミュニケーションを平らにします。 1025 エルドラドBlvd. ブルームフィールド、CO 80021
EMail: nna@level3.net
メール: nna@level3.net
Giles Heron Tellabs Abbey Place 24-28 Easton Street High Wycombe Bucks HP11 1NT UK
ジャイルスのサギのTellabs修道院の地域24-28イーストン通りハイウィカムバックスHP11 1NTイギリス
EMail: giles.heron@tellabs.com
メール: giles.heron@tellabs.com
Eric C. Rosen Cisco Systems, Inc. 1414 Massachusetts Avenue Boxborough, MA 01719
マサチューセッツ通りBoxborough、エリックC.ローゼンシスコシステムズInc.1414MA 01719
EMail: erosen@cisco.com
メール: erosen@cisco.com
Toby Smith Network Appliance, Inc. 800 Cranberry Woods Drive Suite 300 Cranberry Township, PA 16066
トビースミスネットアプライアンスInc.800クランベリーウッズドライブスイート300クランベリー郡区、PA 16066
EMail: tob@netapp.com
メール: tob@netapp.com
Martini, et al. Standards Track [Page 32] RFC 4447 PWE3 Using LDP April 2006
マティーニ、他 2006年4月に自由民主党を使用する標準化過程[32ページ]RFC4447PWE3
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)によって提供されます。
Martini, et al. Standards Track [Page 33]
マティーニ、他 標準化過程[33ページ]
一覧
スポンサーリンク
