RFC5287 日本語訳
5287 Control Protocol Extensions for the Setup of Time-DivisionMultiplexing (TDM) Pseudowires in MPLS Networks. A. Vainshtein, Y(J).Stein. August 2008. (Format: TXT=33070 bytes) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group A. Vainshtein
Request for Comments: 5287 ECI Telecom
Category: Standards Track Y(J). Stein
RAD Data Communications
August 2008
Vainshteinがコメントのために要求するワーキンググループA.をネットワークでつないでください: 5287年のECI電子通信カテゴリ: 規格はY(J)を追跡します。 シタインRADデータ通信2008年8月
Control Protocol Extensions for the Setup of
Time-Division Multiplexing (TDM) Pseudowires in MPLS Networks
MPLSネットワークにおける、時分割多重化(TDM)Pseudowiresのセットアップのための制御プロトコル拡大
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)の現行版を参照してください。 このメモの分配は無制限です。
Abstract
要約
This document defines extension to the Pseudowire Emulation Edge-to- Edge (PWE3) control protocol RFC 4447 and PWE3 IANA allocations RFC 4446 required for the setup of Time-Division Multiplexing (TDM) pseudowires in MPLS networks.
このドキュメントは4446がMPLSネットワークにおける、Time-事業部Multiplexing(TDM)pseudowiresのセットアップのために必要としたPseudowire Emulation Edgeから縁(PWE3)への制御プロトコルのRFC4447とPWE3 IANA配分RFCと拡大を定義します。
Table of Contents
目次
1. Introduction ....................................................2
2. PW FEC for Setup of TDM PWs .....................................2
3. Interface Parameters for TDM PWs ................................4
3.1. Overview ...................................................4
3.2. CEP/TDM Payload Bytes ......................................5
3.3. CEP/TDM Bit-Rate (0x07) ....................................5
3.4. Number of TDMoIP AAL1 Cells per Packet .....................6
3.5. TDMoIP AAL1 Mode ...........................................7
3.6. TDMoIP AAL2 Options ........................................7
3.7. Fragmentation Indicator ....................................8
3.8. TDM Options ................................................8
4. Extending CESoPSN Basic NxDS0 Services with CE
Application Signaling ..........................................11
5. LDP Status Codes ...............................................12
6. Using the PW Status TLV ........................................13
7. IANA Considerations ............................................13
8. Security Considerations ........................................14
9. Acknowledgements ...............................................14
10. References ....................................................14
10.1. Normative References .....................................14
10.2. Informative References ...................................14
1. 序論…2 2. TDM PWsのセットアップのためのPW FEC…2 3. TDM PWsのためのパラメタを連結してください…4 3.1. 概観…4 3.2. CEP/TDM有効搭載量バイト…5 3.3. CEP/TDMビット伝送速度(0×07)…5 3.4. 1パケットあたりのTDMoIP AAL1セルの数…6 3.5. TDMoIP AAL1モード…7 3.6. TDMoIP AAL2オプション…7 3.7. 断片化インディケータ…8 3.8. TDMオプション…8 4. 広がっているCESoPSN基本的なNxDS0はCeでアプリケーションシグナリングを修理します…11 5. 自由民主党ステータスコード…12 6. PW状態TLVを使用します…13 7. IANA問題…13 8. セキュリティ問題…14 9. 承認…14 10. 参照…14 10.1. 標準の参照…14 10.2. 有益な参照…14
Vainshtein & Stein Standards Track [Page 1] RFC 5287 Control Protocol Extensions for TDM Pseudowires August 2008
Vainshteinとシタイン標準化過程[1ページ]RFC5287は2008年8月にTDM Pseudowiresのためにプロトコル拡大を制御します。
1. Introduction
1. 序論
This document defines an extension to the PWE3 control protocol [RFC4447] and PWE3 IANA allocations [RFC4446] required for the setup of TDM pseudowires in MPLS networks.
このドキュメントはPWE3制御プロトコル[RFC4447]と拡大を定義します、そして、PWE3 IANA配分[RFC4446]がMPLSネットワークにおける、TDM pseudowiresのセットアップに必要です。
Structure-agnostic TDM pseudowires have been specified in [RFC4553], and structure-aware ones have been specified in [RFC5086] and [RFC5087].
構造不可知論者TDM pseudowiresは[RFC4553]で指定されました、そして、構造意識しているものは[RFC5086]と[RFC5087]で指定されました。
[RFC4447] defines extensions to the Label Distribution Protocol (LDP) [RFC5036] that are required to exchange PW labels for PWs emulating various Layer 2 services (Ethernet, Frame Relay (FR), Asynchronous Transfer Mode (ATM), High-Level Data Link Control (HDLC), etc.). The setup of TDM PWs requires both interpretation of the existing information elements of these extensions and exchange of additional information.
[RFC4447]は様々なLayer2サービス(イーサネット、Frame Relay(FR)、Asynchronous Transfer Mode(ATM)、High-レベルData Link Control(HDLC)など)を見習うPWsとPWラベルを交換するのに必要であるLabel Distributionプロトコル(自由民主党)[RFC5036]と拡大を定義します。 TDM PWsのセットアップはこれらの拡大の既存情報要素の解釈と追加情報の交換の両方を必要とします。
The setup of TDM PWs using L2TPv3 will be defined in a separate document.
L2TPv3を使用するTDM PWsのセットアップは別々のドキュメントで定義されるでしょう。
The status of attachment circuits of TDM PWs can be exchanged between the terminating Provider Edges (PEs) using the PW Status mechanism defined in [RFC4447] without any changes. However, usage of this mechanism is NOT RECOMMENDED for TDM PWs since the indication of the status of the TDM attachment circuits is carried in-band in the data plane.
終わりProvider Edges(PEs)の間で少しも変化なしで[RFC4447]で定義されたPW Statusメカニズムを使用することでTDM PWsの付属サーキットの状態を交換できます。 しかしながら、TDM付属サーキットの状態のしるしが運ばれたデータのバンドの飛行機であるので、このメカニズムの使用法はTDM PWsのためのNOT RECOMMENDEDです。
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]で説明されるように本書では解釈されることであるべきですか?
2. PW FEC for Setup of TDM PWs
2. TDM PWsのセットアップのためのPW FEC
[RFC4447] uses the LDP Label Mapping message [RFC5036] for advertising the FEC-to-PW Label binding, and defines two types of PW Forwarding Equivalence Classes (FECs) that can be used for this purpose:
[RFC4447]は、FECからPW Labelとの結合の広告を出すのに、自由民主党Label Mappingメッセージ[RFC5036]を使用して、このために使用できるPW Forwarding Equivalence Classes(FECs)の2つのタイプを定義します:
1. PWId FEC (FEC 128). This FEC contains:
1. PWId FEC(FEC128)。 このFECは以下を含んでいます。
a) PW type
a) PWはタイプします。
b) Control bit (indicates presence of the control word)
b) コントロールビット(規制単語の存在を示します)
c) Group ID
c) グループID
d) PW ID
d) PW ID
Vainshtein & Stein Standards Track [Page 2] RFC 5287 Control Protocol Extensions for TDM Pseudowires August 2008
Vainshteinとシタイン標準化過程[2ページ]RFC5287は2008年8月にTDM Pseudowiresのためにプロトコル拡大を制御します。
e) Interface parameters Sub-TLV
e) インタフェース・パラメータSub-TLV
2. Generalized PW FEC (FEC 129). This FEC contains only:
2. PW FEC(FEC129)を一般化しました。 このFECが含んでいる、単に:
a) PW type
a) PWはタイプします。
b) Control bit
b) コントロールビット
c) Attachment Group Identifier (AGI), Source Attachment Individual
Identifier (SAII), and Target Attachment Individual Identifier
(TAII) that replace the PW ID
c) 付属Group Identifier(AGI)、Source Attachment Individual Identifier(SAII)、およびPW IDを取り替えるTarget Attachment Individual Identifier(TAII)
The Group ID and the Interface Parameters are contained in separate TLVs, called the PW Grouping TLV and the Interface Parameters TLV.
PW Grouping TLVとInterface Parameters TLVは、Group IDとInterface Parametersが別々のTLVsに含まれていると呼びました。
Either of these types of PW FEC MAY be used for the setup of TDM PWs with the appropriate selection of PW types and interface parameters.
PW FEC MAYのこれらのタイプのどちらかが、PWタイプの適切な品揃えによるTDM PWsのセットアップに使用されて、パラメタを連結します。
The PW types for TDM PWs are allocated in [RFC4446] as follows:
以下の[RFC4446]にTDM PWsのためのPWタイプを割り当てます:
o 0x0011 Structure-agnostic E1 over Packet [RFC4553] o 0x0012 Structure-agnostic T1 (DS1) over Packet [RFC4553] o 0x0013 Structure-agnostic E3 over Packet [RFC4553] o 0x0014 Structure-agnostic T3 (DS3) over Packet [RFC4553] o 0x0015 CESoPSN basic mode [RFC5086] o 0x0016 TDMoIP AAL1 mode [RFC5087] o 0x0017 CESoPSN TDM with CAS [RFC5086] o 0x0018 TDMoIP AAL2 mode [RFC5087]
o 0×0011 CAS[RFC5086]o0x0018TDMoIP AAL2モードがあるPacket[RFC4553]o0×0015のCESoPSNの基本のモード[RFC5086]o0×0016TDMoIP AAL1モード[RFC5087]oの上のPacket[RFC4553]o0x0014Structure-不可知論者T3(DS3)0×0017CESoPSN TDMの上の3Packet[RFC4553]o Packet[RFC4553]o0x0013の上の0×0012Structure-不可知論者T1(DS1)Structure-不可知論者Eの上の1構造不可知論者E[RFC5087]
The two endpoints MUST agree on the PW type, as both directions of the PW are required to be of the same type.
2つの終点がPWタイプに同意しなければなりません、PWの両方の指示が同じタイプにはあるのに必要であるときに。
The Control bit MUST always be set for TDM PWs since all TDM PW encapsulations always use a control word.
すべてのTDM PWカプセル化がいつも規制単語を使用するので、いつもControlビットをTDM PWsに設定しなければなりません。
PW type 0x0012 MUST also be used for the setup of structure-agnostic TDM PWs between a pair of J1 attachment circuits (see [RFC4805]).
また、1組のJ1付属サーキットの間の構造不可知論者TDM PWsのセットアップにPWタイプ0x0012を使用しなければなりません([RFC4805]を見てください)。
Vainshtein & Stein Standards Track [Page 3] RFC 5287 Control Protocol Extensions for TDM Pseudowires August 2008
Vainshteinとシタイン標準化過程[3ページ]RFC5287は2008年8月にTDM Pseudowiresのためにプロトコル拡大を制御します。
3. Interface Parameters for TDM PWs
3. TDM PWsのためのインタフェース・パラメータ
3.1. Overview
3.1. 概観
The interface parameters that are relevant for the setup of the TDM PWs are listed below.
TDM PWsのセットアップにおいて、関連しているインタフェース・パラメータは以下にリストアップされています。
------------------------------------------------------------- | Interface Parameter | Sub-TLV ID | Length | Description | |-----------------------|------------|--------|-------------| | CEP/TDM Payload Bytes | 0x04 | 4 |Section 3.2 | |-----------------------|------------|--------|-------------| | CEP/TDM Bit-Rate | 0x07 | 6 |Section 3.3 | |-----------------------|------------|--------|-------------| | Number of TDMoIP AAL1 | 0x0E | 4 |Section 3.4 | | Cells per Packet | | | | |-----------------------|-------=----|--------|-------------| | TDMoIP AAL1 Mode | 0x10 | 4 |Section 3.5 | |-----------------------|------------|--------|-------------| | TDMoIP AAL2 Options | 0x11 | 8 or |Section 3.6 | | | | larger | | | | |see note| | |-----------------------|------------|--------|-------------| | Fragmentation | 0x09 | 4 |Section 3.7 | | Indicator | | | | |-----------------------|------------|--------|-------------| | TDM Options | 0x0B | 4, 8, |Section 3.8 | | | | or 12 | | -------------------------------------------------------------
------------------------------------------------------------- | インタフェース・パラメータ| サブTLV ID| 長さ| 記述| |-----------------------|------------|--------|-------------| | CEP/TDM有効搭載量バイト| 0×04| 4 |セクション3.2| |-----------------------|------------|--------|-------------| | CEP/TDMビット伝送速度| 0×07| 6 |セクション3.3| |-----------------------|------------|--------|-------------| | TDMoIP AAL1の数| 0x0E| 4 |セクション3.4| | 1パケットあたりのセル| | | | |-----------------------|-------=----|--------|-------------| | TDMoIP AAL1モード| 0×10| 4 |セクション3.5| |-----------------------|------------|--------|-------------| | TDMoIP AAL2オプション| 0×11| または8。|セクション3.6| | | | より大きい| | | | |注意を見てください。| | |-----------------------|------------|--------|-------------| | 断片化| 0×09| 4 |セクション3.7| | インディケータ| | | | |-----------------------|------------|--------|-------------| | TDMオプション| 0x0B| 4, 8, |セクション3.8| | | | または、12| | -------------------------------------------------------------
If not explicitly indicated otherwise in the appropriate description, the value of the interface parameter is interpreted as an unsigned integer of the appropriate size (16 or 32 bits).
別の方法で適切な記述で明らかに示されないなら、インタフェース・パラメータの値は適切なサイズ(16ビットか32ビット)の符号のない整数として解釈されます。
Note: The length of basic TDMoIP AAL2 Options interface parameter is 8 bytes, and when the optional Channel ID (CID) mapping bases field is used, there is one additional byte for each trunk transported. Thus, if 1 trunk is being supported, this message occupies 9 bytes. Since there can be no more than 248 CIDs in a given PW, this can never exceed 256 (this when each channel comes from a different trunk). 248 channels translates to less than 9 E1s, and so, for this case, the length is
以下に注意してください。 基本のTDMoIP AAL2 Optionsインタフェース・パラメータの長さは8バイトです、そして、ベースがさばく任意のChannel ID(CID)マッピングが使用されているとき、各トランクのための追加バイトが輸送した1つがあります。 したがって、1個のトランクが支えられているなら、このメッセージは9バイトを占領します。 248CIDsが与えられたPWにあることができるので、これは256を決して超えることができません(各チャンネルであるときに、これは異なったトランクから来ます)。 1E、長さがこのような場合翻訳して、248個のチャンネルが9未満に翻訳します。
Vainshtein & Stein Standards Track [Page 4] RFC 5287 Control Protocol Extensions for TDM Pseudowires August 2008
Vainshteinとシタイン標準化過程[4ページ]RFC5287は2008年8月にTDM Pseudowiresのためにプロトコル拡大を制御します。
no more than 17 bytes. A single PE is not required to support more than 10 AAL2 PWs (i.e., up to 2480 individual channels, which is more than carried by a fully populated STM1). Thus, the memory required to store all the AAL2 mapping information is typically between 80 and 170 bytes per PE.
17バイト未満。 独身のPEは、10AAL2 PWs(すなわち、2480個の独特のチャンネルまで、どちらが完全に居住されたSTM1によって運ばれるより多いか、)を支持するのに必要ではありません。 したがって、通常、1PEあたりすべてのAAL2マッピング情報を格納するのに必要であるメモリは80〜170バイトです。
3.2. CEP/TDM Payload Bytes
3.2. CEP/TDM有効搭載量バイト
This parameter is used for the setup of all SAToP and CESoPSN PWs (i.e., PW types 0x0011, 0x0012, 0x0013, 0x0014, 0x0015, and 0x0017) and employs the following semantics:
このパラメタは、すべてのSAToPとCESoPSN PWs(すなわち、PWは0×0011、0×0012、0×0013、0×0014、0×0015、および0×0017をタイプする)のセットアップに使用されて、以下の意味論を使います:
1. The two endpoints of a TDM PW MUST agree on the same value of this
parameter for the PW to be set up successfully.
1. TDM PW MUSTの2つの終点が、PWのためのこのパラメタの同じ値で首尾よくセットアップされるのに同意します。
2. Presence of this parameter in the PWId FEC or in the Interface
Parameters Field TLV is OPTIONAL. If this parameter is omitted,
default payload size defined for the corresponding service (see
[RFC4553], [RFC5086]) MUST be assumed.
2. PWId FECかInterface Parameters Field TLVでのこのパラメタの存在はOPTIONALです。 このパラメタが省略されるなら、対応するサービス([RFC5086]、[RFC4553]を見る)のために定義されたデフォルトペイロードサイズを想定しなければなりません。
3. For structure-agnostic emulation, any value consistent with the
MTU of the underlying PSN MAY be specified.
3. 構造不可知論者のエミュレーション、指定される基本的なPSN MAYのMTUと一致したどんな値のためにも。
4. For CESoPSN PWs:
4. CESoPSN PWsのために:
a) The specified value P MUST be an integer multiple of N, where N
is the number of timeslots in the attachment circuit.
a) 規定値PはNの整数倍数でなければなりません。そこでは、Nが付属サーキットのtimeslotsの数です。
b) For trunk-specific NxDS0 with CAS:
b) CASとトランク特有のNxDS0のために:
i) (P/N) MUST be an integer factor of the number of frames per
corresponding trunk multiframe (i.e., 16 for an E1 trunk and
24 for a T1 or J1 trunk).
i) (P/N) 対応するトランク「マルチ-フレーム」(すなわち、1Eのトランクのための16とT1かJ1トランクのための24)あたりのフレームの数の整数要素はそうであるに違いありませんか?
ii) The size of the signaling sub-structure is not accounted for
in the specified value P.
ii) シグナリング基礎のサイズは規定値Pで説明されません。
5. This parameter MUST NOT be used for the setup of TDMoIP PWs (i.e.,
PWs with PW types 0x0016 and 0x0018).
5. TDMoIP PWsのセットアップにこのパラメタを使用してはいけません(すなわち、PWとPWsは0×0016と0×0018をタイプします)。
3.3. CEP/TDM Bit-Rate (0x07)
3.3. CEP/TDMビット伝送速度(0×07)
This interface parameter represents the bit-rate of the TDM service in multiples of the "basic" 64 Kbit/s rate. Its usage for all types of TDM PWs assumes the following semantics:
このインタフェース・パラメータは「基本的な」64キロビット/sレートの倍数におけるTDMサービスのビット伝送速度を表します。 TDM PWsのすべてのタイプのための用法は以下の意味論を仮定します:
Vainshtein & Stein Standards Track [Page 5] RFC 5287 Control Protocol Extensions for TDM Pseudowires August 2008
Vainshteinとシタイン標準化過程[5ページ]RFC5287は2008年8月にTDM Pseudowiresのためにプロトコル拡大を制御します。
1. This interface parameter MAY be omitted if the attachment circuit
bit-rate can be unambiguously derived from the PW type (i.e., for
structure-agnostic emulation of E1, E3, and T3 circuits). If this
value is omitted for the structure-agnostic emulation of T1 PW
type, the basic emulation mode MUST be assumed.
1. PWタイプ(すなわち、1ユーロ、3ユーロ、およびT3サーキットの構造不可知論者エミュレーションのための)から付属サーキットビット伝送速度を明白に得ることができるなら、このインタフェース・パラメータを省略するかもしれません。 この値がT1 PWタイプの構造不可知論者エミュレーションのために省略されるなら、基本的なエミュレーション・モードを想定しなければなりません。
2. If present, only the following values MUST be specified for
structure-agnostic emulation (see [RFC4553]:
2. 存在しているなら、構造不可知論者エミュレーションに以下の値だけを指定しなければなりません。([RFC4553]を見てください:
a) Structure-agnostic E1 emulation - 32
a) 1構造不可知論者Eのエミュレーション--32
b) Structure-agnostic T1 emulation:
b) 構造不可知論者T1エミュレーション:
i) MUST be set to 24 in the basic emulation mode
i) 基本的なエミュレーション・モードで24に設定しなければなりません。
ii) MUST be set to 25 for the "Octet-aligned T1" emulation mode
ii) 「八重奏で並べられたT1"エミュレーション・モード」のために25に設定しなければなりません。
c) Structure-agnostic E3 emulation - 535
c) 3構造不可知論者Eのエミュレーション--535
d) Structure-agnostic T3 emulation - 699
d) 構造不可知論者T3エミュレーション--699
3. For all kinds of structure-aware emulation, this parameter MUST be
set to N, where N is the number of DS0 channels in the
corresponding attachment circuit.
3. すべての種類の構造意識しているエミュレーションにおいて、このパラメタをNに設定しなければなりません。そこでは、Nが対応する付属サーキットのDS0チャンネルの数です。
Note: The value 24 does not represent the actual bit-rate of the T1 or J1 circuit (1,544 Mbit/s) in units of 64 kbit/s. The values mentioned above are used for convenience.
以下に注意してください。 値24はユニットの64kbit/sのT1かJ1サーキット(1,544メガビット/s)の実際のビット伝送速度を表しません。 前記のように値は便宜に使用されます。
Note: A 4-byte space is reserved for this parameter for compatibility with [RFC4842].
以下に注意してください。 4バイトのスペースは[RFC4842]との互換性のためのこのパラメタのために予約されます。
3.4. Number of TDMoIP AAL1 Cells per Packet
3.4. 1パケットあたりのTDMoIP AAL1セルの数
This parameter MAY be present for TDMoIP AAL1 mode PWs (PW type 0x0016) and specifies the number of 48-byte AAL1 PDUs per MPLS packet. Any values consistent with the MTU of the underlying PSN MAY be specified. If this parameter is not specified, it defaults to 1 PDU per packet for low bit-rates (CEP/TDM Bit-Rate less than or equal to 32), and to 5 for high bit-rates (CEP/TDM Bit-Rate of 535 or 699).
このパラメタは、TDMoIP AAL1モードPWs(PWは0×0016をタイプする)のために存在しているかもしれなくて、MPLSパケット単位で48バイトのAAL1 PDUsの数を指定します。 指定される基本的なPSN MAYのMTUと一致したどんな値。 このパラメタが指定されないなら、それは低ビット伝送速度(32以下のCEP/TDM Bit-レート)のための1パケットあたり1PDUと、そして、高いビット伝送速度(535か699のCEP/TDM Bit-レート)のための5をデフォルトとします。
Vainshtein & Stein Standards Track [Page 6] RFC 5287 Control Protocol Extensions for TDM Pseudowires August 2008
Vainshteinとシタイン標準化過程[6ページ]RFC5287は2008年8月にTDM Pseudowiresのためにプロトコル拡大を制御します。
3.5. TDMoIP AAL1 Mode
3.5. TDMoIP AAL1モード
This parameter MAY be present for TDMoIP AAL1 mode PWs (PW type 0x0016) and specifies the AAL1 mode. If this parameter is not present, the AAL1 mode defaults to "structured". When specified, the values have the following significance:
このパラメタは、TDMoIP AAL1モードPWs(PWは0×0016をタイプする)のために存在しているかもしれなくて、AAL1モードを指定します。 このパラメタが存在していないなら、AAL1モードは「構造化されること」をデフォルトとします。 指定されると、値には、以下の意味があります:
0 - unstructured AAL1
2 - structured AAL1
3 - structured AAL1 with CAS
0(不統一なAAL1 2)はAAL1 3を構造化しました--CASとAAL1を構造化します。
The two endpoints MUST agree on the TDMoIP AAL1 mode.
2つの終点がTDMoIP AAL1モードに同意しなければなりません。
3.6. TDMoIP AAL2 Options
3.6. TDMoIP AAL2オプション
This parameter MUST be present for TDMoIP AAL2 mode PWs (PW type 0x0018) and has the following format:
このパラメタは、TDMoIP AAL2モードPWs(PWは0×0018をタイプする)のために存在していなければならなくて、以下の形式を持っています:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x11 | Length | V | ENCODING |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Maximum Duration |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| CID mapping bases |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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×11| 長さ| V| コード化| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 最大の持続時間| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ベースを写像するCID| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The fields in this parameter are defined as follows:
このパラメタの分野は以下の通り定義されます:
V defines the Voice Activity Detection (VAD) capabilities. Its values have the following significance:
VはVoice Activity Detection(VAD)能力を定義します。 値には、以下の意味があります:
0 means that activity is only indicated by signaling.
1 means that voice activity detection is employed.
3 means this channel is always active. In particular, this
channel may be used for timing recovery.
0 活動がシグナリングによって示されるだけであることを意味します。 アクティビティ検出を声に出す1つの手段が採用しています。 3 このチャンネルがいつも活発であることを意味します。 特に、このチャンネルはタイミング回復に使用されるかもしれません。
Encoding specifies native signal processing performed on the payload. When no native signal processing is performed (i.e., G.711 encoding), this field MUST be zero. Other specific values that can be used in this field are beyond the scope of this specification, but the two directions MUST match for the PW setup to succeed.
コード化はペイロードに実行されたネイティブの信号処理を指定します。 どんなネイティブの信号処理も実行されないとき(すなわち、G.711コード化)、この分野はゼロであるに違いありません。 この分野で使用できる他の特定の値はこの仕様の範囲を超えていますが、2つの方向が、PWセットアップが成功するように合わなければなりません。
Vainshtein & Stein Standards Track [Page 7] RFC 5287 Control Protocol Extensions for TDM Pseudowires August 2008
Vainshteinとシタイン標準化過程[7ページ]RFC5287は2008年8月にTDM Pseudowiresのためにプロトコル拡大を制御します。
Maximum Duration specifies the maximum time allowed for filling an AAL2 PDU, in units of 125 microseconds. For unencoded 64 kbps channels, this numerically equals the maximum number of bytes per PDU and MUST be less than 64. For other encoding parameters, larger values may be attained.
最大のDurationは125マイクロセカンドのユニットにAAL2 PDUをいっぱいにするのに最大の日限を指定します。 64個の暗号化されていないキロビット毎秒チャンネルにおいて、これは、数の上で1PDUあたりのバイトの最大数と等しく、64未満であるに違いありません。 他のコード化パラメタに関しては、より大きい値は得られるかもしれません。
CID mapping bases is an OPTIONAL parameter; its existence and length are determined by the length field. If the mapping of AAL2 CID values to a physical interface and time slot is statically configured, or if AAL2 switching [Q.2630.1] is employed, this parameter MUST NOT appear. When it is present, and the channels belong to N physical interfaces (i.e., N E1s or T1s), it MUST be N bytes in length. Each byte represents a number to be subtracted from the CID to get the timeslot number for each physical interface. For example, if the CID mapping bases parameter consists of the bytes 20 and 60, this signifies that timeslot 1 of trunk 1 corresponds to CID 21, and timeslot 1 of trunk 2 is called 61.
ベースを写像するCIDはOPTIONALパラメタです。 その存在と長さは長さの分野のそばで決定しています。 物理インターフェースと時間帯へのAAL2 CID値に関するマッピングが静的に構成されるか、またはAAL2の切り換え[Q.2630.1]が採用しているなら、このパラメタは現れてはいけません。 それが存在していて、チャンネルがN物理インターフェース(すなわち、N1EかT1s)に属すとき、それは長さがNバイトでなければなりません。 各バイトは、それぞれの物理インターフェースのtimeslot番号を得るためにCIDから引き算されるために数を表します。 例えば、パラメタはベースを写像するCIDであるならバイト20と60から成ります、そして、これは、トランク1のtimeslot1つがCID21に対応するのを意味します、そして、トランク2のtimeslot1つは61と呼ばれます。
3.7. Fragmentation Indicator
3.7. 断片化インディケータ
This interface parameter is specified in [RFC4446], and its usage is explained in [RFC4623]. It MUST be omitted in the FEC of all TDM PWs excluding trunk-specific NxDS0 services with CAS using the CESoPSN encapsulation. In the case of these services, it MUST be present in the PW FEC if the payload size specified value P differs from Nx(number of frames per trunk multiframe).
このインタフェース・パラメータは[RFC4446]で指定されます、そして、用法は[RFC4623]で説明されます。 CASがCESoPSNカプセル化を使用しているトランク特有のNxDS0サービスを除いたすべてのTDM PWsのFECでそれを省略しなければなりません。 これらのサービスの場合では、ペイロードサイズ規定値PがNx(トランク「マルチ-フレーム」あたりのフレームの数)と異なっているなら、PW FECに存在していなければなりません。
3.8. TDM Options
3.8. TDMオプション
This is a new interface parameter. Its Interface Parameter ID (0x0B) has been assigned by IANA, and its format is shown in Figure 1 below:
これは新しいインタフェース・パラメータです。 Interface Parameter ID(0x0B)はIANAによって割り当てられました、そして、書式は以下の図1に示されます:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Parameter ID | Length |R|D|F|X|SP |CAS| RSVD-1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| PT | RSVD-2 | FREQ |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SSRC |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | パラメタID| 長さ|R|D|F|X|SP|CAS| RSVD-1| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0| 太平洋標準時| RSVD-2| FREQ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SSRC| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1. Format of the TDM Options Interface Parameter Sub-TLV
図1。 TDMオプションインタフェース・パラメータサブTLVの形式
The fields shown in this diagram are used as follows:
このダイヤグラムで示された分野は以下の通り使用されます:
Parameter ID Identifies the TDM PW Options interface
parameter, 0x0B.
0x0B、パラメタID Identifies TDM PW Optionsはパラメタを連結します。
Vainshtein & Stein Standards Track [Page 8] RFC 5287 Control Protocol Extensions for TDM Pseudowires August 2008
Vainshteinとシタイン標準化過程[8ページ]RFC5287は2008年8月にTDM Pseudowiresのためにプロトコル拡大を制御します。
Length 4, 8, or 12 (see below).
長さ4、8、または12(以下を見ます)。
R The RTP Header Usage bit: if set, indicates that
the PW endpoint distributing this FEC expects to
receive RTP header in the encapsulation. RTP
header will be used only if both endpoints expect
to receive it. If this bit is cleared, Length
MUST be set to 4; otherwise, it MUST be either 8
or 12 (see below). If the peer PW endpoint
cannot meet this requirement, the Label Mapping
message containing the FEC in question MUST be
rejected with the appropriate status code (see
Section 4 below).
R RTP Header Usageは噛み付きました: セットして、このFECを分配すると予想されるPW終点がカプセル化でRTPヘッダーを受けるのを示します。 両方の終点が、それを受けると予想する場合にだけ、RTPヘッダーは使用されるでしょう。 このビットがきれいにされるなら、Lengthは4に用意ができなければなりません。 さもなければ、それは、8か12であるに違いありません(以下を見てください)。 同輩PW終点がこの必要条件を満たすことができないなら、適切なステータスコードで問題のFECを含むLabel Mappingメッセージを拒絶しなければなりません(以下のセクション4を見てください)。
D The Differential timestamping Mode bit: if set,
indicates that the PW endpoint distributing this
FEC expects the peer to use Differential
timestamping mode in the packets sent to it. If
the peer PW endpoint cannot meet this
requirement, the Label Mapping message containing
the FEC in question MUST be rejected with the
appropriate status code (see Section 4 below).
D Differential timestamping Modeは噛み付きました: セットして、このFECを分配すると同輩が予想されるPW終点が中のパケットがそれに送ったDifferential timestampingモードを使用するのを示します。 同輩PW終点がこの必要条件を満たすことができないなら、適切なステータスコードで問題のFECを含むLabel Mappingメッセージを拒絶しなければなりません(以下のセクション4を見てください)。
F, X Reserved for future extensions. MUST be cleared
when distributed and MUST be ignored upon
reception.
F、今後の拡大のためのX Reserved。 分配されるとクリアしなければならなくて、レセプションで無視しなければなりません。
SP Encodes support for the CESoPSN signaling packets
(see [RFC5086]):
SP EncodesはCESoPSNシグナリングのためにパケットを支持します([RFC5086]を見てください):
o '00' for PWs that do not use signaling packets
o '00'シグナリングパケットを使用しないPWsのために
o '01' for CESoPSN PWs carrying TDM data packets
and expecting Customer Edge (CE) application
signaling packets in a separate PW
o '01'別々のPWでTDMデータ・パケットを運んで、Customer Edge(CE)アプリケーションシグナリングパケットを予想するCESoPSN PWsのために
o '10' for a PW carrying CE application
signaling packets with the data packets in a
separate PW
o 別々のPWでデータ・パケットでCEアプリケーションシグナリングパケットを運ぶPWのための'10年'
o '11' for CESoPSN PWs carrying TDM data and CE
application signaling on the same PW
o 同じPWでTDMデータとCEアプリケーションシグナリングを運ぶCESoPSN PWsのための'11年'
Vainshtein & Stein Standards Track [Page 9] RFC 5287 Control Protocol Extensions for TDM Pseudowires August 2008
Vainshteinとシタイン標準化過程[9ページ]RFC5287は2008年8月にTDM Pseudowiresのためにプロトコル拡大を制御します。
CAS MUST be cleared for all types of TDM PWs
excluding trunk-specific NxDS0 services with CAS.
For these services, it encodes the trunk framing
like the following:
CAS MUST、CASとのトランク特有のNxDS0サービスを除いたTDM PWsのすべてのタイプには、クリアされてください。 これらのサービスのために、以下のようにトランク縁どりをコード化します:
o '01' - an E1 trunk
o '01'--1Eのトランク
o '10' - a T1/ESF trunk
o '10年'--T1/ESFトランク
o '11' - a T1 SF trunk
o '11年'--T1 SFトランク
RSVD-1 and RSVD-2 Reserved bits, which MUST be set to 0 by the PW
endpoint distributing this FEC and MUST be
ignored by the receiver.
RSVD-1とRSVD-2 Reservedビット。(そのビットをこのFECを分配するPW終点で0に用意ができなければならなくて、受信機で無視しなければなりません)。
PT Indicates the value of Payload Type in the RTP
header expected by the PW endpoint distributing
this FEC. A value of 0 means that the PT value
check will not be used for detecting malformed
packets.
RTPヘッダーの有効搭載量Typeの値がこのFECを分配するPW終点で予想したPT Indicates。 太平洋標準時がチェックするのを評価する0つの手段の値は、誤った形式のパケットを検出するのに使用されないでしょう。
FREQ Frequency of timestamping clock in units of 8
kHz.
8kHzのユニットのtimestamping時計のFREQ Frequency
SSRC Indicates the value of the Synchronization source
ID (SSRC ID) in the RTP header expected by the PW
endpoint distributing this FEC. A value of 0
means that the SSRC ID value check will not be
used for detecting misconnections.
Alternatively, Length can be set to 8 in this
case.
RTPヘッダーというSynchronizationソースID(SSRC ID)の値がこのFECを分配するPW終点で予想したSSRC Indicates。 0の値は、SSRC ID値のチェックが付け違いを検出するのに使用されないことを意味します。 あるいはまた、Lengthはこの場合8に用意ができることができます。
Notes:
注意:
1. This interface parameter MAY be omitted in the following cases:
1. このインタフェース・パラメータは以下の場合で省略されるかもしれません:
a) SAToP PWs that do not use RTP header [RFC4553].
a) RTPヘッダー[RFC4553]を使用しないSAToP PWs。
b) Basic CESoPSN NxDS0 services without CE application signaling
[RFC5086].
b) 基本的なCESoPSN NxDS0はCEなしでアプリケーションシグナリング[RFC5086]を修理します。
c) TDMoIP AAL1 mode 0 or 2 PWs that do not use RTP .
c) RTPを使用しないTDMoIP AAL1モード0か2PWs。
d) TDMoIP AAL2 PWs that do not relay CAS signaling and do not use
RTP.
d) CASシグナリングをリレーして、しないTDMoIP AAL2 PWsがRTPを使用しません。
Vainshtein & Stein Standards Track [Page 10] RFC 5287 Control Protocol Extensions for TDM Pseudowires August 2008
Vainshteinとシタイン標準化過程[10ページ]RFC5287は2008年8月にTDM Pseudowiresのためにプロトコル拡大を制御します。
2. This interface parameter MUST be present in the following cases:
2. このインタフェース・パラメータは以下の場合で存在していなければなりません:
a) All TDM PWs that use RTP headers.
a) RTPヘッダーを使用するすべてのTDM PWs。
b) CESoPSN PWs that carry basic NxDS0 services and use CESoPSN
signaling packets to carry CE application signaling. This case
is discussed in detail in Section 4 below.
b) CEアプリケーションシグナリングを運ぶようにパケットに合図する基本的なNxDS0サービスを提供して、CESoPSNを使用するCESoPSN PWs。 以下のセクション4で詳細に本件について議論します。
c) CESoPSN PWs that carry trunk-specific NxDS0 services with CAS.
c) CASとのトランク特有のNxDS0サービスを提供するCESoPSN PWs。
d) TDMoIP AAL1 mode 1 PWs.
d) TDMoIP AAL1モード1PWs。
e) TDMoIP AAL2 PWs that relay CAS signaling.
e) CASシグナリングをリレーするTDMoIP AAL2 PWs。
3. If RTP header and possibly the Differential timestamping mode are
used, the value of the Length field MUST be set to 8 or 12 in
order to accommodate the Timestamping Clock Frequency and SSRC
fields.
3. RTPヘッダーとことによるとDifferential timestampingモードが使用されているなら、Timestamping Clock FrequencyとSSRC野原を収容するためにLength分野の値を8か12に設定しなければなりません。
4. Usage or non-usage of the RTP header MUST match for the two
directions making up the TDM PW. However, it is possible to use
the Differential timestamping mode in just one direction.
4. RTPヘッダーの用法か非使用法がTDM PWを作る2つの方向のために合わなければなりません。 しかしながら、まさしく一方向にDifferential timestampingモードを使用するのは可能です。
4. Extending CESoPSN Basic NxDS0 Services with CE Application Signaling
4. Ceアプリケーションが合図している状態で、CESoPSNの基本的なNxDS0サービスを広げています。
[RFC5086] states that basic NxDS0 services can be extended to carry CE application signaling (e.g., CAS) in special signaling packets carried in a separate PW.
[RFC5086]は、別々のPWで運ばれた特別なシグナリングパケットでCEアプリケーションシグナリング(例えば、CAS)を運ぶために基本的なNxDS0サービスを広げることができると述べます。
The following rules define the setup of matching pairs of CESoPSN PWs using the PW ID FEC and the extensions defined above:
以下の規則はPW ID FECを使用することで組のCESoPSN PWsを合わせるセットアップと以下の上で定義された拡大を定義します。
1. The two PWs MUST:
1. 2PWsはそうしなければなりません:
a) Have the same PW type.
a) 同じPWにタイプさせてください。
b) Use the same setup method (i.e., either both use the PWId FEC,
or both use the Generalized PW FEC).
b) 同じセットアップ方法(すなわち、ともにPWId FECを使用するか、またはともにGeneralized PW FECを使用する)を使用してください。
c) Have the same values of all the Interface Parameters listed in
Section 3.1 above with the exception of the code point in the
SP field of the TDM Options parameter:
c) TDM OptionsパラメタのSP分野のコード・ポイントを除いた、上のセクション3.1にすべてのInterface Parametersの同じ値を記載させてください:
i) For the PW carrying TDM data packets, the SP bits MUST be
set to '01'.
i) TDMデータ・パケットを運ぶPWにおいて、'01'にSPビットを設定しなければなりません。
ii) For the PW carrying the signaling packets, the SP bits MUST
set to '10'.
ii) 'シグナリングパケットを運ぶPWに関して、SPビットは10年までセットしなければなりません'。
Vainshtein & Stein Standards Track [Page 11] RFC 5287 Control Protocol Extensions for TDM Pseudowires August 2008
Vainshteinとシタイン標準化過程[11ページ]RFC5287は2008年8月にTDM Pseudowiresのためにプロトコル拡大を制御します。
2. If the PWId FEC has been used:
2. PWId FECが使用されたなら:
a) The value of PW ID for the CESoPSN PW carrying TDM data packets
MUST be even.
a) TDMデータ・パケットを運ぶCESoPSN PWのためのPW IDの値は同等であるに違いありません。
b) The value of PW ID for the CESoPSN PW carrying CE application
signaling MUST be the next (odd) value after the (even) PW ID
of the CESoPSN PW carrying TDM data packets.
b) CEアプリケーションシグナリングを運ぶCESoPSN PWのためのPW IDの値が後の次の(変)の値でなければならない、)さえ TDMデータ・パケットを運ぶCESoPSN PWのPW ID。
When using the Generalized PW FEC for the setup of the two PWs, no specific rules for matching the two FECs are defined. Implementation-specific mechanisms MAY be employed to verify the proper matching of the TDM data PW with its associated CE signaling PW.
2PWsのセットアップにGeneralized PW FECを使用するとき、2FECsを合わせるためのどんな特定の規則も定義されません。 実現特有のメカニズムは、関連CEがPWに合図しているTDMデータPWの適切なマッチングについて確かめるのに使われるかもしれません。
If one of the two associated PWs has been established and the other failed to be established, or for any reason fails after having been established, the established PW MUST be torn down.
設立されたか、または設立された後のどんな理由やり損ない、確立したPW MUSTのためにも2関連PWsの1つが設立されるか、そして、もう片方は取りこわされませんでした。
5. LDP Status Codes
5. 自由民主党ステータスコード
In addition to the status codes defined in Sections 5.1 and 7.2 of [RFC4447], the following status codes defined in [RFC4446] MUST be used to indicate the reason of failure to establish a TDM PW:
[RFC4447]のセクション5.1と7.2で定義されたステータスコードに加えて、TDM PWを設立しないことの理由を示すのに[RFC4446]で定義された以下のステータスコードを使用しなければなりません:
1. Incompatible bit-rate:
1. 両立しないビット伝送速度:
a) In the case of a mismatch of T1 encapsulation modes (basic vs.
octet-aligned).
a) T1カプセル化モード(八重奏で並べられるに対して基本的な)のミスマッチの場合で。
b) In the case of a mismatch in the number of timeslots for NxDS0
basic services or trunk-specific NxDS0 services with CAS.
b) CASとのNxDS0基本サービスかトランク特有のNxDS0サービスのためのtimeslotsの数における、ミスマッチの場合で。
2. CEP/TDM misconfiguration:
2. CEP/TDM misconfiguration:
a) In the case of a mismatch in the desired usage of RTP header.
a) RTPヘッダーの必要な使用法における、ミスマッチの場合で。
b) In the case of a mismatch of the desired Timestamping Clock
Frequency.
b) 必要なTimestamping Clock Frequencyのミスマッチの場合で。
c) In the case of a mismatch of expected signaling packets
behavior for basic CESoPSN NxDS0 services extended to carry CE
application signaling in separate signaling packets.
c) 基本的なCESoPSN NxDS0サービスのためのパケットの振舞いが達した予想されたシグナリングのミスマッチの場合では、別々のシグナリングパケットでCEアプリケーションシグナリングを運んでください。
d) In the case of trunk-specific NxDS0 services with CAS if the
framing types of the trunks are different.
d) トランク特有のNxDS0の場合では、CASとのサービスはトランクスの縁どりタイプであるなら異なっています。
Vainshtein & Stein Standards Track [Page 12] RFC 5287 Control Protocol Extensions for TDM Pseudowires August 2008
Vainshteinとシタイン標準化過程[12ページ]RFC5287は2008年8月にTDM Pseudowiresのためにプロトコル拡大を制御します。
e) In the case of TDMoIP AAL1 PWs with different AAL1 modes
specified by the endpoints.
e) 異なったAAL1があるTDMoIP AAL1 PWsの場合では、モードは終点のそばで指定しました。
3. The generic misconfiguration error MAY be used to indicate any
setup failure not covered above.
3. 一般的なmisconfiguration誤りは、上にカバーされなかった少しのセットアップ失敗も示すのに使用されるかもしれません。
In cases 2a, 2b, 2c, and 2e above, the user MAY reconfigure the endpoints and attempt to set up the PW once again.
ケースの2a、2b、2c、および2eでは、上では、ユーザがもう一度PWに設定する終点と試みを再構成するかもしれません。
In the case of 2d, the failure is fatal.
2dの場合では、失敗は致命的です。
Note that setting of the Control bit (see Section 2 above) to zero MUST result in an LDP status of "Illegal C-Bit".
ゼロまで噛み付かれた(セクション2が上であることを見ます)Controlの設定が「不法なC-ビット」の自由民主党状態をもたらさなければならないことに注意してください。
6. Using the PW Status TLV
6. PW状態TLVを使用します。
The TDM PW control word carries status indications for both attachment circuits (L and M fields) and the PSN (R field) indication (see [RFC4553], [RFC5086], and [RFC5087]). Similar functionality is available via use of the PW Status TLV (see Section 5.4.2 of [RFC4447]). If the latter mechanism is employed, the signaling PE sends its peer a PW Status TLV for this PW, setting the appropriate bits (see Section 3.5 of [RFC4446]):
TDM PW規制単語は付属サーキット(LとM分野)とPSN(R分野)指示の両方のための状態指摘を運びます([RFC4553]、[RFC5086]、および[RFC5087]を見てください)。 同様の機能性はPW Status TLVの使用で利用可能です(.2セクション5.4[RFC4447]を見てください)。 後者のメカニズムが採用しているなら、シグナリングPEはこのPWのためにPW Status TLVを同輩に送ります、適切なビットを設定して([RFC4446]のセクション3.5を見てください):
o Pseudowire Not Forwarding
o Local Attachment Circuit (ingress) Receive Fault
o Local Attachment Circuit (egress) Transmit Fault
o Local PSN-facing PW (ingress) Receive Fault
o Local PSN-facing PW (egress) Transmit Fault
o Pseudowire Not Forwarding o Local Attachment Circuit(イングレス)が受信する、Fault o Local Attachment Circuit(出口)はPW(イングレス)が受けるFault o Local PSN-面のFault PW(出口)が伝えるo Local PSN-面のFaultを伝えます。
As long as the TDM PW interworking function is operational, usage of the Status TLV is NOT RECOMMENDED in order to avoid contention between status indications reported by the data and control plane. However, if the TDM PW interworking function (IWF) itself fails while the PWE3 control plane remains operational, a Status TLV with all of the above bits set SHOULD be sent.
TDM PW織り込む機能が操作上である限り、Status TLVの使用法は、データと制御飛行機によって報告された状態指摘の間の主張を避けるNOT RECOMMENDEDです。 優に上のビットのStatus TLVがPWE3制御飛行機が操作上のままで残っていますが、機能(IWF)自体を織り込むTDM PWが失敗するならどのようにSHOULDを設定したとしても、送ってください。
7. IANA Considerations
7. IANA問題
Most of the IANA assignments required by this document are already listed in [RFC4446]. Additional assignments have been made for four Interface Parameter Sub-TLV types (see Section 3.1):
このドキュメントによって必要とされたIANA課題の大部分は[RFC4446]に既に記載されています。 4つのInterface Parameter Sub-TLVタイプのために追加課題をしました(セクション3.1を見てください):
o TDM Options (0x0B)
o Number of TDMoIP AAL1 cells per packet (0x0E)
o TDMoIP AAL1 mode (0x10)
o TDMoIP AAL2 Options (0x11)
o パケット(0x0E)o TDMoIP AAL1モード(0×10)o TDMoIP AAL2 OptionsあたりのTDMoIP AAL1セルのTDM Options(0x0B)o Number(0×11)
Vainshtein & Stein Standards Track [Page 13] RFC 5287 Control Protocol Extensions for TDM Pseudowires August 2008
Vainshteinとシタイン標準化過程[13ページ]RFC5287は2008年8月にTDM Pseudowiresのためにプロトコル拡大を制御します。
8. Security Considerations
8. セキュリティ問題
This document does not have any additional impact on the security of PWs above that of basic LDP-based setup of PWs specified in [RFC4447].
このドキュメントは[RFC4447]で指定されたPWsの基本的な自由民主党ベースのセットアップのものの上にどんな追加影響力もPWsのセキュリティに持っていません。
9. Acknowledgements
9. 承認
Sharon Galtzur has reviewed one of the previous versions of this document. Y. (J.) Stein would like to thank Barak Schlosser for helpful discussions.
シャロンGaltzurはこのドキュメントの旧バージョンの1つを見直しました。 Y。 (J.) シタインは役立つ議論についてバラク・シュロッサーに感謝したがっています。
10. References
10. 参照
10.1. Normative References
10.1. 引用規格
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。
[RFC5036] Andersson, L., Ed., Minei, I., Ed., and B. Thomas, Ed.,
"LDP Specification", RFC 5036, October 2007.
[RFC5036] アンデション、L.、エド、Minei、I.、エド、B.トーマス、エド、「自由民主党仕様」、RFC5036、10月2007日
[RFC4447] Martini, L., Ed., Rosen, E., El-Aawar, N., Smith, T., and
G. Heron, "Pseudowire Setup and Maintenance Using the
Label Distribution Protocol (LDP)", RFC 4447, April 2006.
[RFC4447]マティーニ、L.(エド)、ローゼン、E.、高架鉄道-Aawar、N.、スミス、T.、およびG.サギ、「ラベル分配を使用するPseudowireセットアップと維持が(自由民主党)について議定書の中で述べます」、RFC4447、2006年4月。
[RFC4446] Martini, L., "IANA Allocations for Pseudowire Edge to Edge
Emulation (PWE3)", BCP 116, RFC 4446, April 2006.
[RFC4446] マティーニ、L.、「PseudowireのためのIANA配分はエミュレーション(PWE3)を斜めに進ませるために斜めに進む」BCP116、RFC4446、2006年4月。
[RFC4623] Malis, A. and M. Townsley, "Pseudowire Emulation Edge-to-
Edge (PWE3) Fragmentation and Reassembly", RFC 4623,
August 2006.
[RFC4623] Malis、A.、M.Townsley、および「Pseudowireエミュレーション縁から縁(PWE3)への断片化とReassembly」、RFC4623、8月2006日
[RFC4553] Vainshtein, A., Ed., and YJ. Stein, Ed., "Structure-
Agnostic Time Division Multiplexing (TDM) over Packet
(SAToP)", RFC 4553, June 2006.
[RFC4553] エドVainshtein、A.、YJ。 シタイン、エド、「パケット(SAToP)の上の構造の不可知論者の時分割多重化(TDM)」、RFC4553、6月2006日
10.2. Informative References
10.2. 有益な参照
[RFC5086] Vainshtein, A., Ed., Sasson, I., Metz, E., Frost, T., and
P. Pate, "Structure-Aware Time Division Multiplexed (TDM)
Circuit Emulation Service over Packet Switched Network
(CESoPSN)", RFC 5086, December 2007.
[RFC5086]Vainshtein、A.(エド)、サソン、I.、メス、E.、フロスト、T.、およびP.頭、「構造意識している時間事業部が多重送信されたのを(TDM)サーキットエミュレーションサービスオーバーパケット交換網(CESoPSN)」、RFC5086(2007年12月)。
[RFC5087] Y(J). Stein, Shashoua, R., Insler, R., and M. Anavi, "Time
Division Multiplexing over IP (TDMoIP)", RFC 5087,
December 2007.
[RFC5087]Y(J)。 2007年12月のシタインとShashouaとR.とインスラー、R.とM.Anavi、「IP(TDMoIP)の上の時分割多重化」RFC5087。
Vainshtein & Stein Standards Track [Page 14] RFC 5287 Control Protocol Extensions for TDM Pseudowires August 2008
Vainshteinとシタイン標準化過程[14ページ]RFC5287は2008年8月にTDM Pseudowiresのためにプロトコル拡大を制御します。
[Q.2630.1] ITU-T Recommendation Q.2630.1, December 1999, AAL type 2
signaling protocol - Capability set 1
[Q.2630.1]ITU-T Recommendation Q.2630.1、1999年12月に、AALは2シグナリングプロトコルをタイプします--能力は1を設定しました。
[RFC4805] Nicklass, O., Ed., "Definitions of Managed Objects for the
DS1, J1, E1, DS2, and E2 Interface Types", RFC 4805, March
2007.
[RFC4805]Nicklass、O.(エド)、「DS1のための管理オブジェクトの定義、J1、1Eです、DS2、および2Eのインタフェースがタイプします」、RFC4805、2007年3月。
[RFC4842] Malis, A., Pate, P., Cohen, R., Ed., and D. Zelig,
"Synchronous Optical Network/Synchronous Digital Hierarchy
(SONET/SDH) Circuit Emulation over Packet (CEP)", RFC
4842, April 2007.
[RFC4842]MalisとA.と頭とP.とコーエン、R.(エド)とD.カメレオンマン、「パケット(CEP)の上の同期式光通信網/同期デジタルハイアラーキ(Sonet/SDH)サーキットエミュレーション」RFC4842(2007年4月)。
Authors' Addresses
作者のアドレス
Alexander ("Sasha") Vainshtein
ECI Telecom
30 ha-Sivim St.,
PO Box 500 Petah-Tiqva, 49517 Israel
アレクサンダー(「サシャ」)Vainshtein ECIテレコム30、ハ、-、Sivim、聖、500ペタチクバ、私書箱49517イスラエル
EMail: Alexander.Vainshtein@ecitele.com
メール: Alexander.Vainshtein@ecitele.com
Yaakov (Jonathan) Stein RAD Data Communications 24 Raoul Wallenberg St., Bldg C Tel Aviv 69719 ISRAEL
Yaakov(ジョナサン)シタインRADデータ通信24ラウルワレンバーグBldg Cテルアビブ69719通り(イスラエル)
Phone: +972 3 645-5389 EMail: yaakov_s@rad.com
以下に電話をしてください。 +972 3 645-5389 メールしてください: yaakov_s@rad.com
Vainshtein & Stein Standards Track [Page 15] RFC 5287 Control Protocol Extensions for TDM Pseudowires August 2008
Vainshteinとシタイン標準化過程[15ページ]RFC5287は2008年8月にTDM Pseudowiresのためにプロトコル拡大を制御します。
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The IETF Trust (2008).
IETFが信じる著作権(C)(2008)。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントとここに含まれた情報はその人が代理をするか、または(もしあれば)後援される組織、インターネットの振興発展を目的とする組織、「そのままで」という基礎と貢献者の上で提供していて、IETFはそして、インターネット・エンジニアリング・タスク・フォースがすべての保証を放棄すると信じます、急行である、または暗示していて、他を含んでいて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるということであるかいずれが市場性か特定目的への適合性の黙示的な保証です。
Intellectual Property
知的所有権
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFはどんなIntellectual Property Rightsの正当性か範囲、実現に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するためのどんな独立している努力もしました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPR公開のコピーが利用可能に作られるべきライセンスの保証、または一般的な免許を取得するのが作られた試みの結果をIETF事務局といずれにもしたか、または http://www.ietf.org/ipr のIETFのオンラインIPR倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFはこの規格を実行するのに必要であるかもしれない技術をカバーするかもしれないどんな著作権もその注目していただくどんな利害関係者、特許、特許出願、または他の所有権も招待します。 ietf-ipr@ietf.org のIETFに情報を記述してください。
Vainshtein & Stein Standards Track [Page 16]
Vainshteinとシタイン標準化過程[16ページ]
一覧
スポンサーリンク
