RFC5087 日本語訳
5087 Time Division Multiplexing over IP (TDMoIP). Y(J). Stein, R.Shashoua, R. Insler, M. Anavi. December 2007. (Format: TXT=113071 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
英語原文
Network Working Group Y(J). Stein
Request for Comments: 5087 R. Shashoua
Category: Informational R. Insler
M. Anavi
RAD Data Communications
December 2007
ワーキンググループY(J)をネットワークでつないでください。 コメントを求めるシタインRequest: 5087年のR.Shashouaカテゴリ: 情報のR.インスラーM.Anavi radデータ通信2007年12月
Time Division Multiplexing over IP (TDMoIP)
IPの上の時分割多重化(TDMoIP)
Status of This Memo
このメモの状態
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのための情報を提供します。 それはどんな種類のインターネット標準も指定しません。 このメモの分配は無制限です。
Abstract
要約
Time Division Multiplexing over IP (TDMoIP) is a structure-aware method for transporting Time Division Multiplexed (TDM) signals using pseudowires (PWs). Being structure-aware, TDMoIP is able to ensure TDM structure integrity, and thus withstand network degradations better than structure-agnostic transport. Structure-aware methods can distinguish individual channels, enabling packet loss concealment and bandwidth conservation. Accesibility of TDM signaling facilitates mechanisms that exploit or manipulate signaling.
IP(TDMoIP)の上の時間事業部Multiplexingは、pseudowires(PWs)を使用することでTime事業部Multiplexed(TDM)信号を輸送するための構造意識している方法です。 構造意識していて、TDMoIPは構造保全をTDMに確実にして、その結果、ネットワーク転落に構造不可知論者輸送よりよく耐えることができます。 パケット損失隠すことと帯域幅保護を可能にして、構造意識している方法は独特のチャンネルを区別できます。 TDMシグナリングのAccesibilityはシグナリングを利用するか、または操るメカニズムを容易にします。
Stein, et al. Informational [Page 1] RFC 5087 TDMoIP December 2007
シタイン、他 [1ページ]情報のRFC5087TDMoIP2007年12月
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. TDM Structure and Structure-aware Transport . . . . . . . . . 4
3. TDMoIP Encapsulation . . . . . . . . . . . . . . . . . . . . . 6
4. Encapsulation Details for Specific PSNs . . . . . . . . . . . 9
4.1. UDP/IP . . . . . . . . . . . . . . . . . . . . . . . . . . 9
4.2. MPLS . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
4.3. L2TPv3 . . . . . . . . . . . . . . . . . . . . . . . . . . 14
4.4. Ethernet . . . . . . . . . . . . . . . . . . . . . . . . . 15
5. TDMoIP Payload Types . . . . . . . . . . . . . . . . . . . . . 17
5.1. AAL1 Format Payload . . . . . . . . . . . . . . . . . . . 18
5.2. AAL2 Format Payload . . . . . . . . . . . . . . . . . . . 19
5.3. HDLC Format Payload . . . . . . . . . . . . . . . . . . . 20
6. TDMoIP Defect Handling . . . . . . . . . . . . . . . . . . . . 21
7. Implementation Issues . . . . . . . . . . . . . . . . . . . . 24
7.1. Jitter and Packet Loss . . . . . . . . . . . . . . . . . . 24
7.2. Timing Recovery . . . . . . . . . . . . . . . . . . . . . 25
7.3. Congestion Control . . . . . . . . . . . . . . . . . . . . 26
8. Security Considerations . . . . . . . . . . . . . . . . . . . 27
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28
10. Applicability Statement . . . . . . . . . . . . . . . . . . . 28
11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 29
Appendix A. Sequence Number Processing (Informative) . . . . . . 30
Appendix B. AAL1 Review (Informative) . . . . . . . . . . . . . . 32
Appendix C. AAL2 Review (Informative) . . . . . . . . . . . . . . 36
Appendix D. Performance Monitoring Mechanisms (Informative) . . . 38
D.1. TDMoIP Connectivity Verification . . . . . . . . . . . . . 38
D.2. OAM Packet Format . . . . . . . . . . . . . . . . . . . . 39
Appendix E. Capabilities, Configuration and Statistics
(Informative) . . . . . . . . . . . . . . . . . . . . 42
References . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
Normative References . . . . . . . . . . . . . . . . . . . . . . 45
Informative References . . . . . . . . . . . . . . . . . . . . . 47
1. 序論. . . . . . . . . . . . . . . . . . . . . . . . . 3 2。 TDM構造と構造意識している輸送. . . . . . . . . 4 3。 TDMoIPカプセル化. . . . . . . . . . . . . . . . . . . . . 6 4。 特定のPSNs. . . . . . . . . . . 9 4.1のためのカプセル化の詳細。 UDP/IP. . . . . . . . . . . . . . . . . . . . . . . . . . 9 4.2。 MPLS. . . . . . . . . . . . . . . . . . . . . . . . . . . 12 4.3。 L2TPv3. . . . . . . . . . . . . . . . . . . . . . . . . . 14 4.4。 イーサネット. . . . . . . . . . . . . . . . . . . . . . . . . 15 5。 TDMoIP有効搭載量は.175.1をタイプします。 AAL1は有効搭載量. . . . . . . . . . . . . . . . . . . 18 5.2をフォーマットします。 AAL2は有効搭載量. . . . . . . . . . . . . . . . . . . 19 5.3をフォーマットします。 HDLCは有効搭載量. . . . . . . . . . . . . . . . . . . 20 6をフォーマットします。 .217を扱って、TDMoIPは亡命します。 導入問題. . . . . . . . . . . . . . . . . . . . 24 7.1。 ジターとパケット損失. . . . . . . . . . . . . . . . . . 24 7.2。 回復. . . . . . . . . . . . . . . . . . . . . 25 7.3を調節します。 輻輳制御. . . . . . . . . . . . . . . . . . . . 26 8。 セキュリティ問題. . . . . . . . . . . . . . . . . . . 27 9。 IANA問題. . . . . . . . . . . . . . . . . . . . . 28 10。 適用性証明. . . . . . . . . . . . . . . . . . . 28 11。 承認. . . . . . . . . . . . . . . . . . . . . . . 29の(有益)の.30付録B.AAL1付録A.一連番号処理レビュー(有益な).32付録C.AAL2は.36台の(有益)の付録D.パフォーマンス監視メカニズム(有益な).38D.1を見直します。 TDMoIP接続性検証. . . . . . . . . . . . . 38D.2。 OAMパケット・フォーマット. . . . . . . . . . . . . . . . . . . . 39付録E.能力、構成、および統計(有益な).42の参照箇所. . . . . . . . . . . . . . . . . . . . . . . . . . . . 45引用規格. . . . . . . . . . . . . . . . . . . . . . 45の有益な参照. . . . . . . . . . . . . . . . . . . . . 47
Stein, et al. Informational [Page 2] RFC 5087 TDMoIP December 2007
シタイン、他 [2ページ]情報のRFC5087TDMoIP2007年12月
1. Introduction
1. 序論
Telephony traffic is conventionally carried over connection-oriented synchronous or plesiochronous links (loosely called TDM circuits herein). With the proliferation of Packet Switched Networks (PSNs), transport of TDM services over PSN infrastructures has become desirable. Emulation of TDM circuits over the PSN can be carried out using pseudowires (PWs), as described in the PWE3 architecture [RFC3985]. This emulation must maintain service quality of native TDM; in particular voice quality, latency, timing, and signaling features must be similar to those of existing TDM networks, as described in the TDM PW requirements document [RFC4197].
電話交通は慣習上同期かplesiochronousの接続指向のリンクの上まで運ばれます(緩くここにTDMサーキットと呼ばれます)。 Packet Switched Networks(PSNs)の増殖によると、PSNインフラストラクチャの上のTDMサービスの輸送は望ましくなりました。 pseudowires(PWs)を使用することでPSNの上のTDMサーキットのエミュレーションを行うことができます、PWE3構造[RFC3985]で説明されるように。 このエミュレーションはネイティブのTDMのサービス品質を維持しなければなりません。 特に音声の品質、潜在と、タイミングと、特徴に合図するのは既存のTDMネットワークのものと同様であるに違いありません、TDM PW要件ドキュメント[RFC4197]で説明されるように。
Structure-Agnostic TDM over Packet (SAToP) [RFC4553] is a structure- agnostic protocol for transporting TDM over PSNs. The present document details TDM over IP (TDMoIP), a structure-aware method for TDM transport. In contrast to SAToP, structure-aware methods such as TDMoIP ensure the integrity of TDM structure and thus enable the PW to better withstand network degradations. Individual multiplexed channels become visible, enabling the use of per channel mechanisms for packet loss concealment and bandwidth conservation. TDM signaling also becomes accessible, facilitating mechanisms that exploit or manipulate this signaling.
Packet(SAToP)[RFC4553]の上の構造不可知論者TDMは、PSNsの上でTDMを輸送するための構造の不可知論者のプロトコルです。 現在のドキュメントはIP(TDMoIP)、TDM輸送のための構造意識している方法の上にTDMについて詳述します。 SAToPと対照して、TDMoIPなどの構造意識している方法は、TDM構造の保全を確実にして、その結果、PWがネットワーク転落により耐えるのを可能にします。 個人はチャンネルを多重送信しました。パケット損失隠すことと帯域幅保護のために目に見えるようになって、チャンネルメカニズム単位で使用を可能にします。 また、このシグナリングを利用するか、または操るメカニズムを容易にして、TDMシグナリングはアクセスしやすくなります。
Despite its name, the TDMoIP(R) protocol herein described may operate over several types of PSN, including UDP over IPv4 or IPv6, MPLS, Layer 2 Tunneling Protocol version 3 (L2TPv3) over IP, and pure Ethernet. Implementation specifics for particular PSNs are discussed in Section 4. Although the protocol should be more generally called TDMoPW and its specific implementations TDMoIP, TDMoMPLS, etc., we retain the nomenclature TDMoIP for consistency with earlier usage.
名前にもかかわらず、ここに説明されたTDMoIP(R)プロトコルはPSNのいくつかのタイプで作動するかもしれません、IP、および純粋なイーサネットの上にIPv4かIPv6、MPLSの上のUDP、Layer2Tunnelingプロトコルバージョン3(L2TPv3)を含んでいて。 セクション4で特定のPSNsのための実現詳細について議論します。 プロトコルは、より一般にTDMoPWと特定の実現TDMoIP、TDMoMPLSなどと呼ばれるべきですが、私たちは以前の用法で一貫性のための用語体系TDMoIPを保有します。
The interworking function that connects between the TDM and PSN worlds will be called a TDMoIP interworking function (IWF), and it may be situated at the provider edge (PE) or at the customer edge (CE). The IWF that encapsulates TDM and injects packets into the PSN will be called the PSN-bound interworking function, while the IWF that extracts TDM data from packets and generates traffic on a TDM network will be called the TDM-bound interworking function. Emulated TDM circuits are always point-to-point, bidirectional, and transport TDM at the same rate in both directions.
TDMとPSN世界の間で接続する織り込む機能は機能(IWF)を織り込むTDMoIPと呼ばれるでしょう、そして、それはプロバイダー縁(PE)において、または、顧客縁(CE)に位置するかもしれません。 TDMを要約して、PSNにパケットを注ぐIWFはPSN行きの織り込む機能と呼ばれるでしょう、パケットからTDMデータを抜粋して、TDMネットワークで交通を発生させるIWFはTDM行きの織り込む機能と呼ばれるでしょうが。 見習われたTDMサーキットは、いつも双方向のポイントツーポイントであり、同じレートで両方の方向にTDMを輸送します。
As with all PWs, TDMoIP PWs may be manually configured or set up using the PWE3 control protocol [RFC4447]. Extensions to the PWE3 control protocol required specifically for setup and maintenance of TDMoIP pseudowires are described in [TDM-CONTROL].
すべてのPWsなら、TDMoIP PWsは、PWE3制御プロトコル[RFC4447]を使用することで手動で構成されるか、またはセットアップするかもしれません。 拡大は[TDM-CONTROL]に特にTDMoIP pseudowiresのセットアップとメンテナンスに必要であるPWE3制御プロトコルに説明されます。
Stein, et al. Informational [Page 3] RFC 5087 TDMoIP December 2007
シタイン、他 [3ページ]情報のRFC5087TDMoIP2007年12月
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. TDM Structure and Structure-aware Transport
2. TDM構造と構造意識している輸送
Although TDM circuits can be used to carry arbitrary bit-streams, there are standardized methods for carrying constant-length blocks of data called "structures". Familiar structures are the T1 or E1 frames [G704] of length 193 and 256 bits, respectively. By concatenation of consecutive T1 or E1 frames we can build higher level structures called superframes or multiframes. T3 and E3 frames [G704][G751] are much larger than those of T1 and E1, and even larger structures are used in the GSM Abis channel described in [TRAU]. TDM structures contain TDM data plus structure overhead; for example, the 193-bit T1 frame contains a single bit of structure overhead and 24 bytes of data, while the 32-byte E1 frame contains a byte of overhead and 31 data bytes.
任意のビットストリームを運ぶのにTDMサーキットを使用できますが、「構造」と呼ばれる恒長ブロックのデータを運ぶための標準化法があります。 身近な構造は193と256ビットと、それぞれ長さのT1か1Eのフレーム[G704]です。 連続したT1か1Eのフレームの連結で、私たちは、より高いレベルの「スーパー-フレーム」と呼ばれる構造か「マルチ-フレーム」を造ることができます。 T3で3Eのフレーム[G704][G751]がさらに大きい構造のものが[TRAU]で説明されたGSM Abisチャンネルで使用されるよりはるかに大きいです。 TDM構造はTDMデータと構造オーバーヘッドを含んでいます。 例えば、193ビットのT1フレームは構造オーバーヘッドと24バイトのデータの1ビットを含んでいます、1 32バイトのEのフレームが1バイトのオーバーヘッドと31データ・バイトを含んでいますが。
Structured TDM circuits are frequently used to transport multiplexed channels. A single byte in the TDM frame (called a timeslot) is allocated to each channel. A frame of a channelized T1 carries 24 byte-sized channels, while an E1 frame consists of 31 channels. Since TDM frames are sent 8000 times per second, a single byte-sized channel carries 64 kbps.
構造化されたTDMサーキットは、多重送信されたチャンネルを輸送するのに頻繁に使用されます。 TDMフレーム(timeslotと呼ばれる)の1バイトを各チャンネルに割り当てます。 channelized T1のフレームは24個のバイトサイズのチャンネルを運びますが、1Eのフレームは31個のチャンネルから成ります。 1秒あたり8000回をTDMフレームに送るので、単独のバイトサイズのチャンネルは64キロビット毎秒を運びます。
TDM structures are universally delimited by placing an easily detectable periodic bit pattern, called the Frame Alignment Signal (FAS), in the structure overhead. The structure overhead may additionally contain error monitoring and defect indications. We will use the term "structured TDM" to refer to TDM with any level of structure imposed by an FAS. Unstructured TDM signifies a bit stream upon which no structure has been imposed, implying that all bits are available for user data.
Frame Alignment Signal(FAS)は、TDM構造が容易に検出可能な周期的なビット・パターンを置くことによって一般に区切られると呼びました、構造オーバーヘッドで。 構造オーバーヘッドはさらに、誤りモニターと欠陥指摘を含むかもしれません。 私たちはFASによって課されるどんなレベルの構造と共にもTDMについて言及するために「TDMを構造化する」という用語を使用するつもりです。 不統一なTDMは構造が全く課されていない流れを少し意味します、すべてのビットが利用者データに有効であることを含意して。
SAToP [RFC4553] is a structure-agnostic protocol for transporting TDM using PWs. SAToP treats the TDM input as an arbitrary bit-stream, completely disregarding any structure that may exist in the TDM bit- stream. Hence, SAToP is ideal for transport of truly unstructured TDM, but is also suitable for transport of structured TDM when there is no need to protect structure integrity nor interpret or manipulate individual channels during transport. In particular, SAToP is the technique of choice for PSNs with negligible packet loss, and for applications that do not require discrimination between channels nor intervention in TDM signaling.
SAToP[RFC4553]は、PWsを使用することでTDMを輸送するための構造不可知論者プロトコルです。 TDMビットに存在するどんな構造も完全に無視して、TDMが任意のビットストリームとして入力したSAToPの御馳走は流れます。 したがって、SAToPも本当に不統一なTDMの輸送に理想的ですが、また、輸送の間に独特のチャンネルを構造保全を保護して、解釈するか、または操作する必要は全くないとき、構造化されたTDMの輸送に適しています。 SAToPは特に、取るにたらないパケット損失を伴うPSNs、およびチャンネルの間の区別を必要としないアプリケーションのための選択のテクニックであり、TDMでの介入はシグナリングです。
As described in [RFC4553], when a single SAToP packet is lost, an "all ones" pattern is played out to the TDM interface. This pattern
単一のSAToPパケットが無くなるとき、[RFC4553]で説明されるように、「すべてのもの」パターンはTDMインタフェースに展開されます。 このパターン
Stein, et al. Informational [Page 4] RFC 5087 TDMoIP December 2007
シタイン、他 [4ページ]情報のRFC5087TDMoIP2007年12月
is interpreted by the TDM end equipment as an Alarm Indication Signal (AIS), which, according to TDM standards [G826], immediately triggers a "severely errored second" event. As such events are considered highly undesirable, the suitability of SAToP is limited to extremely reliable and underutilized PSNs.
TDM終わりの設備で、Alarm Indication Signal(AIS)として解釈されます。(TDM規格[G826]に従って、Alarm Indication Signalはすぐに、「厳しくerroredされた2番目」出来事の引き金となります)。 そういうものとして、出来事は非常に望ましくないと考えられて、SAToPの適合は非常に信頼できるのに制限されます。そして、underutilized PSNs。
When structure-aware TDM transport is employed, it is possible to explicitly safeguard TDM structure during transport over the PSN, thus making possible to effectively conceal packet loss events. Structure-aware transport exploits at least some level of the TDM structure to enhance robustness to packet loss or other PSN shortcomings. Structure-aware TDM PWs are not required to transport structure overhead across the PSN; in particular, the FAS MAY be stripped by the PSN-bound IWF and MUST be regenerated by the TDM- bound IWF. However, structure overhead MAY be transported over the PSN, since it may contain information other than FAS.
構造意識しているTDM輸送が採用しているとき、その結果、PSNの上の輸送、事実上、パケット損失出来事を隠すのにおいて可能な作成の間、明らかにTDM構造を保護しているのは可能です。 構造意識している輸送は、パケット損失か他のPSN短所に丈夫さを高めるのにTDM構造の少なくとも何らかのレベルを利用します。 構造意識しているTDM PWsはPSNの向こう側に構造オーバーヘッドを輸送する必要はありません。 FAS MAYを特に、PSN行きのIWFによって剥取られて、TDMの制限されたIWFは作り直さなければなりません。 しかしながら、FAS以外の情報を含むかもしれないので、構造オーバーヘッドはPSNの上で輸送されるかもしれません。
In addition to guaranteeing maintenance of TDM synchronization, structure-aware TDM transport can also distinguish individual timeslots of channelized TDM, thus enabling sophisticated packet loss concealment at the channel level. TDM signaling also becomes visible, facilitating mechanisms that maintain or exploit this information. Finally, by taking advantage of TDM signaling and/or voice activity detection, structure-aware TDM transport makes bandwidth conservation possible.
また、TDM同期の維持を保証することに加えて、構造意識しているTDM輸送はchannelized TDMの個々のtimeslotsを区別できます、その結果、チャンネルレベルで洗練されたパケット損失隠すことを可能にします。 また、この情報を保守するか、または利用するメカニズムを容易にして、TDMシグナリングは目に見えるようになります。 最終的に、TDMシグナリング、そして/または、声のアクティビティ検出を利用することによって、構造意識しているTDM輸送で帯域幅保護は可能になります。
There are three conceptually distinct methods of ensuring TDM structure integrity -- namely, structure-locking, structure- indication, and structure-reassembly. Structure-locking requires each packet to commence at the start of a TDM structure, and to contain an entire structure or integral multiples thereof. Structure-indication allows packets to contain arbitrary fragments of basic structures, but employs pointers to indicate where each structure commences. Structure-reassembly is only defined for channelized TDM; the PSN-bound IWF extracts and buffers individual channels, and the original structure is reassembled from the received constituents by the TDM-bound IWF.
TDMは保全を構造化します--すなわち、構造ロック、構造指示、および構造-再アセンブリを確実にする3つの概念的に異なった方法があります。 構造ロックは、各パケットがTDM構造の始めで始まって、全体の構造かそれの整数倍を含むのを必要とします。 構造指示は、パケットが基本構造の任意の断片を含むのを許容しますが、各構造がどこで始まるかを示すのにポインタを使います。 構造-再アセンブリはchannelized TDMのために定義されるだけです。 PSN行きのIWFは独特のチャンネルを抽出して、バッファリングします、そして、元の構造はTDM行きのIWFによって容認された成分から組み立て直されます。
All three methods of TDM structure preservation have their advantages. Structure-locking is described in [RFC5086], while the present document specifies both structure-indication (see Section 5.1) and structure-reassembly (see Section 5.2) approaches. Structure-indication is used when channels may be allocated statically, and/or when it is required to interwork with existing circuit emulation systems (CES) based on AAL1. Structure-reassembly is used when dynamic allocation of channels is desirable and/or when it is required to interwork with existing loop emulation systems (LES) based on AAL2.
TDM構造保持のすべての3つの方法には、それらの利点があります。 構造ロックは[RFC5086]で説明されます、現在のドキュメントは構造指示(セクション5.1を見る)と構造-再アセンブリ(セクション5.2を見る)アプローチの両方を指定しますが。 静的にチャンネルを割り当てるかもしれなくて、存在するのにサーキットエミュレーションがAAL1に基づくシステム(CES)であると織り込むためにそれを必要とするとき、構造指示は使用されています。 チャンネルの動的割当てが望ましく、それが存在するのに輪のエミュレーションがAAL2に基づくシステム(LES)であると織り込むのに必要であるときに、構造-再アセンブリは使用されています。
Stein, et al. Informational [Page 5] RFC 5087 TDMoIP December 2007
シタイン、他 [5ページ]情報のRFC5087TDMoIP2007年12月
Operation, administration, and maintenance (OAM) mechanisms are vital for proper TDM deployments. As aforementioned, structure-aware mechanisms may refrain from transporting structure overhead across the PSN, disrupting OAM functionality. It is beneficial to distinguish between two OAM cases, the "trail terminated" and the "trail extended" scenarios. A trail is defined to be the combination of data and associated OAM information transfer. When the TDM trail is terminated, OAM information such as error monitoring and defect indications are not transported over the PSN, and the TDM networks function as separate OAM domains. In the trail extended case, we transfer the OAM information over the PSN (although not necessarily in its native format). OAM will be discussed further in Section 6.
適切なTDM展開に、操作、管理、および維持(OAM)メカニズムは重大です。 前述の、そして、構造意識しているメカニズムが、輸送するのを控えるかもしれないように、OAMの機能性を混乱させて、PSNの向こう側にオーバーヘッドを構造化してください。 2つのOAMケース、「終えられた道」、および「広げられた道」シナリオを見分けるのは有益です。 道は、データと関連OAM情報転送の組み合わせであることのようになるように定義されます。 いつ、TDM道が誤りモニターなどの終えられたOAM情報であるか、そして、欠陥指摘はPSNの上で輸送されません、そして、TDMネットワークは別々のOAMドメインとして機能します。 道の拡張場合では、私たちはOAM情報をPSNの上に移します(必ずどんなネイティブの形式でもそうするというわけではありませんが)。 セクション6で、より詳しくOAMについて議論するでしょう。
3. TDMoIP Encapsulation
3. TDMoIPカプセル化
The overall format of TDMoIP packets is shown in Figure 1.
TDMoIPパケットの総合的な書式は図1に示されます。
+---------------------+
| PSN Headers |
+---------------------+
| TDMoIP Control Word |
+---------------------+
| Adapted Payload |
+---------------------+
+---------------------+ | PSNヘッダー| +---------------------+ | TDMoIPコントロールWord| +---------------------+ | 適合している有効搭載量| +---------------------+
Figure 1. Basic TDMoIP Packet Format
図1。 基本的なTDMoIPパケット・フォーマット
The PSN-specific headers are those of UDP/IP, L2TPv3/IP, MPLS or layer 2 Ethernet, and contain all information necessary for forwarding the packet from the PSN-bound IWF to the TDM-bound one. The PSN is assumed to be reliable enough and of sufficient bandwidth to enable transport of the required TDM data.
PSN特有のヘッダーは、UDP/IP、L2TPv3/IP、MPLSまたは層の2つのイーサネットのものであり、PSN行きのIWFからTDM行きのものまでパケットを進めるのに必要なすべての情報を含んでいます。 PSNは十分信頼できると思われて、必要なTDMデータの輸送を可能にすることができるくらいの帯域幅についてそうします。
A TDMoIP IWF may simultaneously support multiple TDM PWs, and the TDMoIP IWF MUST maintain context information for each TDM PW. Distinct PWs are differentiated based on PW labels, which are carried in the PSN-specific layers. Since TDM is inherently bidirectional, the association of two PWs in opposite directions is required. The PW labels of the two directions MAY take different values.
TDMoIP IWFは同時に複数のTDM PWsを支持するかもしれません、そして、TDMoIP IWFは各TDM PWのための文脈情報を保守しなければなりません。 異なったPWsはPWラベルに基づいて微分されます。ラベルはPSN特有の層で運ばれます。 TDMが本来双方向であるので、2PWsの協会がそれぞれ反対の方向に必要です。 2つの方向のPWラベルは異価を取るかもしれません。
In addition to the aforementioned headers, an OPTIONAL 12-byte RTP header may appear in order to enable explicit transfer of timing information. This usage is a purely formal reuse of the header format of [RFC3550]. RTP mechanisms, such as header extensions, contributing source (CSRC) list, padding, RTP Control Protocol (RTCP), RTP header compression, Secure RTP (SRTP), etc., are not applicable.
前述のヘッダーに加えて、OPTIONALの12バイトのRTPヘッダーは、タイミング情報の明白な転送を可能にするために現れるかもしれません。 この用法は[RFC3550]のヘッダー形式の純粋に正式な再利用です。 ソース(CSRC)リスト、詰め物、RTP Controlプロトコル(RTCP)、RTPヘッダー圧縮、Secure RTP(SRTP)などを寄付して、ヘッダー拡大などのRTPメカニズムは適切ではありません。
Stein, et al. Informational [Page 6] RFC 5087 TDMoIP December 2007
シタイン、他 [6ページ]情報のRFC5087TDMoIP2007年12月
The RTP timestamp indicates the packet creation time in units of a common clock available to both communicating TDMoIP IWFs. When no common clock is available, or when the TDMoIP IWFs have sufficiently accurate local clocks or can derive sufficiently accurate timing without explicit timestamps, the RTP header SHOULD be omitted.
RTPタイムスタンプはともにTDMoIP IWFsを伝えるのに利用可能な一般的な時計のユニットでパケット創造時間を示します。 一般的でないときに、時計が利用可能であるか、またはTDMoIP IWFsであるときに、十分正確な地方の時計を持っているか、明白なタイムスタンプなしで十分正確なタイミングを引き出すことができます、RTPヘッダーSHOULD。省略されます。
If RTP is used, the fixed RTP header described in [RFC3550] MUST immediately follow the control word for all PSN types except UDP/IP, for which it MUST precede the control word. The version number MUST be set to 2, the P (padding), X (header extension), CC (CSRC count), and M (marker) fields in the RTP header MUST be set to zero, and the payload type (PT) values MUST be allocated from the range of dynamic values. The RTP sequence number MUST be identical to the sequence number in the TDMoIP control word (see below). The RTP timestamp MUST be generated in accordance with the rules established in [RFC3550]; the clock frequency MUST be an integer multiple of 8 kHz, and MUST be chosen to enable timing recovery that conforms with the appropriate standards (see Section 7.2).
RTPが使用されているなら、[RFC3550]で説明された固定RTPヘッダーはすぐに、UDP/IP以外のすべてのPSNタイプに対する規制単語に従わなければなりません。それはIPに関して規制単語に先行しなければなりません。 バージョン番号を2に設定しなければなりません、P(そっと歩く)、X(ヘッダー拡大)、CC(CSRCは数える)、そして、ダイナミックな値の範囲からゼロに合わせるようにRTPヘッダーの分野を設定しなければならなくて、ペイロードタイプ(太平洋標準時の)が評価するM(マーカー)を割り当てなければなりません。 RTP一連番号はTDMoIP規制単語による一連番号と同じであるに違いありません(以下を見てください)。 [RFC3550]に確立された規則に従って、RTPタイムスタンプは発生しなければなりません。 クロック周波数を8kHzの整数倍数でなければならなく、適切な規格に従うタイミング回復を可能にするために選ばなければなりません(セクション7.2を見てください)。
The 32-bit control word MUST appear in every TDMoIP packet. Its format, in conformity with [RFC4385], is depicted in Figure 2.
32ビットの規制単語はあらゆるTDMoIPパケットに現れなければなりません。 [RFC4385]と一致して、書式は図2に表現されます。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RES |L|R| M |RES| Length | Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | RES|L|R| M|RES| 長さ| 一連番号| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2. Structure of the TDMoIP Control Word
図2。 コントロールが言い表すTDMoIPの構造
RES (4 bits) The first nibble of the control word MUST be set to
zero when the PSN is MPLS, in order to ensure that the packet does
not alias an IP packet when forwarding devices perform deep packet
inspection. For PSNs other than MPLS, the first nibble MAY be set
to zero; however, in earlier versions of TDMoIP this field
contained a format identifier that was optionally used to specify
the payload format.
装置を進めるとき、PSNがパケットがどんな別名にもIPパケットをしないのを確実にするMPLSであるときには合わせてください規制単語の最初の少量を設定しなければならないゼロRES(4ビット)は深いパケット点検を実行します。 MPLS以外のPSNsにおいて、最初の少量がゼロに設定されるかもしれません。 しかしながら、TDMoIPの以前のバージョンでは、この分野はペイロード形式を指定するのに任意に使用された形式IDを含みました。
L Local Failure (1 bit) The L flag is set when the IWF has detected
or has been informed of a TDM physical layer fault impacting the
TDM data being forwarded. In the "trail extended" OAM scenario
the L flag MUST be set when the IWF detects loss of signal, loss
of frame synchronization, or AIS. When the L flag is set the
contents of the packet may not be meaningful, and the payload MAY
be suppressed in order to conserve bandwidth. Once set, if the
TDM fault is rectified the L flag MUST be cleared. Use of the L
flag is further explained in Section 6.
IWFは転送されるTDMデータに影響を与えるTDMの物理的な層の欠点において検出するか、または知識があるとき、Failure(1ビット)Lが旗を揚げさせるLローカルが用意ができています。 「道は広がった」OAMというシナリオでは、IWFが信号の損失、フレーム同期化の損失、またはAISを検出すると、L旗を設定しなければなりません。 L旗が設定されるとき、パケットのコンテンツは重要でないかもしれません、そして、ペイロードは、帯域幅を保存するために抑圧されるかもしれません。 いったん設定されると、TDM欠点が正されるなら、L旗をきれいにしなければなりません。 L旗の使用はセクション6でさらに説明されます。
Stein, et al. Informational [Page 7] RFC 5087 TDMoIP December 2007
シタイン、他 [7ページ]情報のRFC5087TDMoIP2007年12月
R Remote Failure (1 bit) The R flag is set when the IWF has detected
or has been informed, that TDM data is not being received from the
remote TDM network, indicating failure of the reverse direction of
the bidirectional connection. An IWF SHOULD generate TDM Remote
Defect Indicator (RDI) upon receipt of an R flag indication. In
the "trail extended" OAM scenario the R flag MUST be set when the
IWF detects RDI. Use of the R flag is further explained in
Section 6.
RリモートFailure(1ビット)Rは、IWFが設定されたとき、検出されて、設定されるか、または知識があるので、そのTDMデータがリモートTDMネットワークから受け取られていないということであり、双方向の接続の反対の方向の失敗を示しながら、弛みます。 IWF SHOULDはR旗の指示を受け取り次第TDM Remote Defect Indicator(RDI)を発生させます。 「道は広がった」OAMというシナリオでは、IWFがRDIを検出すると、R旗を設定しなければなりません。 R旗の使用はセクション6でさらに説明されます。
M Defect Modifier (2 bits) Use of the M field is optional; when
used, it supplements the meaning of the L flag.
Mの欠陥Modifier(2ビット)使用がさばくMは任意です。 使用されると、それはL旗の意味を補います。
When L is cleared (indicating valid TDM data) the M field is used
as follows:
Lがクリアされるとき、Mがさばく(有効なTDMデータを示します)は以下の通り使用されます:
0 0 indicates no local defect modification.
0 1 reserved.
1 0 reserved.
1 1 reserved.
0 0はどんな地方の欠陥変更も示しません。 予約された0 1。 予約された1 0。 予約された1 1。
When L is set (invalid TDM data) the M field is used as follows:
LがMを設定する(無効のTDMデータ)ことであるときに、分野は以下の通り使用されます:
0 0 indicates a TDM defect that should trigger conditioning
or AIS generation by the TDM-bound IWF.
0 1 indicates idle TDM data that should not trigger any alarm.
If the payload has been suppressed then the preconfigured
idle code should be generated at egress.
1 0 indicates corrupted but potentially recoverable TDM data.
1 1 reserved.
0 0はTDM行きのIWFによる調節かAIS世代の引き金となるべきであるTDM欠陥を示します。 0 1は少しのアラームも引き金となるべきでない無駄なTDMデータを示します。 ペイロードが抑圧されたなら、あらかじめ設定された無駄なコードは出口で発生するべきです。 1 0は崩壊しましたが、潜在的に回復可能なTDMデータを示します。 予約された1 1。
Use of the M field is further explained in Section 6.
M分野の使用はセクション6でさらに説明されます。
RES (2 bits) These bits are reserved and MUST be set to zero.
RES、(2ビット) これらのビットを予約されていて、ゼロに設定しなければなりません。
Length (6 bits) is used to indicate the length of the TDMoIP packet
(control word and payload), in case padding is employed to meet
minimum transmission unit requirements of the PSN. It MUST be
used if the total packet length (including PSN, optional RTP,
control word, and payload) is less than 64 bytes, and MUST be set
to zero when not used.
長さ(6ビット)はTDMoIPパケット(規制単語とペイロード)の長さを示すのに使用されます、詰め物がPSNの最小のトランスミッション原単位を満たすのに使われるといけないので。 それを総パケット長(PSN、任意のRTP、規制単語、およびペイロードを含んでいる)が64バイト未満であるなら使用しなければならなくて、使用されないと、ゼロに設定しなければなりません。
Sequence number (16 bits) The TDMoIP sequence number provides the
common PW sequencing function described in [RFC3985], and enables
detection of lost and misordered packets. The sequence number
space is a 16-bit, unsigned circular space; the initial value of
the sequence number SHOULD be random (unpredictable) for security
TDMoIP一連番号が[RFC3985]で説明された一般的なPW配列機能を提供して、検出を可能にする一連番号(16ビット)は、パケットを失って、misorderedしました。 一連番号スペースは16ビットの、そして、無記名の円形のスペースです。 初期の値、一連番号SHOULDでは、セキュリティのために無作為であってください(予測できない)。
Stein, et al. Informational [Page 8] RFC 5087 TDMoIP December 2007
シタイン、他 [8ページ]情報のRFC5087TDMoIP2007年12月
purposes, and its value is incremented modulo 2^16 separately for
each PW. Pseudocode for a sequence number processing algorithm
that could be used by a TDM-bound IWF is provided in Appendix A.
目的、値は別々に各PWのための増加している法2^16です。 TDM行きのIWFが使用できた一連番号処理アルゴリズムのための擬似コードをAppendix Aに提供します。
In order to form the TDMoIP payload, the PSN-bound IWF extracts bytes from the continuous TDM stream, filling each byte from its most significant bit. The extracted bytes are then adapted using one of two adaptation algorithms (see Section 5), and the resulting adapted payload is placed into the packet.
TDMoIPペイロードを形成するために、PSN行きのIWFは連続したTDMの流れからバイトを抽出します、最上位ビットからの各バイトをいっぱいにしていて。 次に、抽出されたバイトは2つの適合アルゴリズムの1つを使用することで適合させられます、そして、(セクション5を見てください)結果として起こる適合しているペイロードはパケットに置かれます。
4. Encapsulation Details for Specific PSNs
4. 特定のPSNsのためのカプセル化の詳細
TDMoIP PWs may exploit various PSNs, including UDP/IP (both IPv4 and IPv6), L2TPv3 over IP (with no intervening UDP), MPLS, and layer-2 Ethernet. In the following subsections, we depict the packet format for these cases.
TDMoIP PWsは様々なPSNsを利用するかもしれません、UDP/IP(IPv4とIPv6の両方)、IPの上のL2TPv3(介入しているUDPのない)、MPLS、および層-2つのイーサネットを含んでいて。 以下の小区分では、私たちはこれらのケースのためにパケット・フォーマットについて表現します。
For MPLS PSNs, the format is aligned with those specified in [Y1413] and [Y1414]. For UDP/IP PSNs, the format is aligned with those specified in [Y1453] and [Y1452]. For transport over layer 2 Ethernet the format is aligned with [MEF8].
MPLS PSNsに関しては、形式は[Y1413]と[Y1414]で指定されるそれらに並べられます。 UDP/IP PSNsに関しては、形式は[Y1453]と[Y1452]で指定されるそれらに並べられます。 層2のイーサネットの上の輸送において、形式は[MEF8]に並べられます。
4.1. UDP/IP
4.1. UDP/IP
ITU-T recommendation Y.1453 [Y1453] describes structure-agnostic and structure-aware mechanisms for transporting TDM over IP networks. Similarly, ITU-T recommendation Y.1452 [Y1452] defines structure- reassembly mechanisms for this purpose. Although the terminology used here differs slightly from that of the ITU, implementations of TDMoIP for UDP/IP PSNs as described herein will interoperate with implementations designed to comply with Y.1453 subclause 9.2.2 or Y.1452 clause 10.
ITU-T推薦Y.1453[Y1453]は、IPネットワークの上でTDMを輸送するために構造不可知論者の、そして、構造意識しているメカニズムについて説明します。 同様に、ITU-T推薦Y.1452[Y1452]はこのために構造再アセンブリメカニズムを定義します。 ここで使用された用語はITUのものと若干異なりますが、実現がY.1453 subclause9.2.2か10番目のY.1452節に従うように設計されている状態で、ここに説明されるUDP/IP PSNsのためのTDMoIPの実現は共同利用するでしょう。
For UDP/IPv4, the headers as described in [RFC768] and [RFC791] are prefixed to the TDMoIP data. The format is similar for UDP/IPv6, except the IP header described in [RFC2460] is used. The TDMoIP packet structure is depicted in Figure 3.
UDP/IPv4に関しては、[RFC768]と[RFC791]で説明されるヘッダーはTDMoIPデータへ前に置かれています。 UDP/IPv6に、形式が同様である、IPを除いて、[RFC2460]で説明されたヘッダーは使用されています。 TDMoIPパケット構造は図3に表現されます。
Stein, et al. Informational [Page 9] RFC 5087 TDMoIP December 2007
シタイン、他 [9ページ]情報のRFC5087TDMoIP2007年12月
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPVER | IHL | IP TOS | Total Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Identification |Flags| Fragment Offset |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Time to Live | Protocol | IP Header Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source IP Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination IP Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Port Number | Destination Port Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| UDP Length | UDP Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
opt|RTV|P|X| CC |M| PT | RTP Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
opt| Timestamp |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
opt| SSRC identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RES |L|R| M |RES| Length | Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Adapted Payload |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPVER| IHL| IP TOS| 全長| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 識別|旗| 断片オフセット| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 生きる時間| プロトコル| IPヘッダーチェックサム| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ソースIPアドレス| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 送付先IPアドレス| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ソースポートナンバー| 仕向港番号| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | UDPの長さ| UDPチェックサム| +++++++++++++++++++++++++++++++++は選ばれます。|RTV|P|X| CC|M| 太平洋標準時| RTP一連番号| +++++++++++++++++++++++++++++++++は選ばれます。| タイムスタンプ| +++++++++++++++++++++++++++++++++は選ばれます。| SSRC識別子| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | RES|L|R| M|RES| 長さ| 一連番号| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | 適合している有効搭載量| | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3. TDMoIP Packet Format for UDP/IP
Figure 3. TDMoIP Packet Format for UDP/IP
The first five rows are the IP header, the sixth and seventh rows are the UDP header. Rows 8 through 10 are the optional RTP header. Row 11 is the TDMoIP control word.
The first five rows are the IP header, the sixth and seventh rows are the UDP header. Rows 8 through 10 are the optional RTP header. Row 11 is the TDMoIP control word.
IPVER (4 bits) is the IP version number, e.g., IPVER=4 for IPv4.
IPVER (4 bits) is the IP version number, e.g., IPVER=4 for IPv4.
IHL (4 bits) is the length in 32-bit words of the IP header, IHL=5.
IHL (4 bits) is the length in 32-bit words of the IP header, IHL=5.
IP TOS (8 bits) is the IP type of service.
IP TOS (8 bits) is the IP type of service.
Total Length (16 bits) is the length in bytes of header and data.
Total Length (16 bits) is the length in bytes of header and data.
Identification (16 bits) is the IP fragmentation identification
field.
Identification (16 bits) is the IP fragmentation identification field.
Stein, et al. Informational [Page 10] RFC 5087 TDMoIP December 2007
Stein, et al. Informational [Page 10] RFC 5087 TDMoIP December 2007
Flags (3 bits) are the IP control flags and MUST be set to 2 in
order to avoid fragmentation.
Flags (3 bits) are the IP control flags and MUST be set to 2 in order to avoid fragmentation.
Fragment Offset (13 bits) indicates where in the datagram the
fragment belongs and is not used for TDMoIP.
Fragment Offset (13 bits) indicates where in the datagram the fragment belongs and is not used for TDMoIP.
Time to Live (8 bits) is the IP time to live field. Datagrams with
zero in this field are to be discarded.
Time to Live (8 bits) is the IP time to live field. Datagrams with zero in this field are to be discarded.
Protocol (8 bits) MUST be set to 0x11 (17) to signify UDP.
Protocol (8 bits) MUST be set to 0x11 (17) to signify UDP.
IP Header Checksum (16 bits) is a checksum for the IP header.
IP Header Checksum (16 bits) is a checksum for the IP header.
Source IP Address (32 bits) is the IP address of the source.
Source IP Address (32 bits) is the IP address of the source.
Destination IP Address (32 bits) is the IP address of the
destination.
Destination IP Address (32 bits) is the IP address of the destination.
Source and Destination Port Numbers (16 bits each)
Source and Destination Port Numbers (16 bits each)
Either the source UDP port or destination UDP port MAY be used to
multiplex and demultiplex individual PWs between nodes.
Architecturally [RFC3985], this makes the UDP port act as the PW
Label. PW endpoints MUST agree upon use of either the source UDP
or destination UDP port as the PW Label.
Either the source UDP port or destination UDP port MAY be used to multiplex and demultiplex individual PWs between nodes. Architecturally [RFC3985], this makes the UDP port act as the PW Label. PW endpoints MUST agree upon use of either the source UDP or destination UDP port as the PW Label.
UDP ports MUST be manually configured by both endpoints of the PW.
The configured source or destination port (one or the other, but
not both) together with both the source and destination IP
addresses uniquely identify the PW. When the source UDP port is
used as the PW label, the destination UDP port number MUST be set
to the IANA assigned value of 0x085E (2142). All UDP port values
that function as PW labels SHOULD be in the range of dynamically
allocated UDP port numbers (0xC000 through 0xFFFF).
UDP ports MUST be manually configured by both endpoints of the PW. The configured source or destination port (one or the other, but not both) together with both the source and destination IP addresses uniquely identify the PW. When the source UDP port is used as the PW label, the destination UDP port number MUST be set to the IANA assigned value of 0x085E (2142). All UDP port values that function as PW labels SHOULD be in the range of dynamically allocated UDP port numbers (0xC000 through 0xFFFF).
While many UDP-based protocols are able to traverse middleboxes
without dire consequences, the use of UDP ports as PW labels makes
middlebox traversal more difficult. Hence, it is NOT RECOMMENDED
to use UDP-based PWs where port-translating middleboxes are
present between PW endpoints.
While many UDP-based protocols are able to traverse middleboxes without dire consequences, the use of UDP ports as PW labels makes middlebox traversal more difficult. Hence, it is NOT RECOMMENDED to use UDP-based PWs where port-translating middleboxes are present between PW endpoints.
UDP Length (16 bits) is the length in bytes of UDP header and data.
UDP Length (16 bits) is the length in bytes of UDP header and data.
UDP Checksum (16 bits) is the checksum of UDP/IP header and data.
If not computed it MUST be set to zero.
UDP Checksum (16 bits) is the checksum of UDP/IP header and data. If not computed it MUST be set to zero.
Stein, et al. Informational [Page 11] RFC 5087 TDMoIP December 2007
Stein, et al. Informational [Page 11] RFC 5087 TDMoIP December 2007
4.2. MPLS
4.2. MPLS
ITU-T recommendation Y.1413 [Y1413] describes structure-agnostic and structure-aware mechanisms for transporting TDM over MPLS networks. Similarly, ITU-T recommendation Y.1414 [Y1413] defines structure- reassembly mechanisms for this purpose. Although the terminology used here differs slightly from that of the ITU, implementations of TDMoIP for MPLS PSNs as described herein will interoperate with implementations designed to comply with Y.1413 subclause 9.2.2 or Y.1414 clause 10.
ITU-T recommendation Y.1413 [Y1413] describes structure-agnostic and structure-aware mechanisms for transporting TDM over MPLS networks. Similarly, ITU-T recommendation Y.1414 [Y1413] defines structure- reassembly mechanisms for this purpose. Although the terminology used here differs slightly from that of the ITU, implementations of TDMoIP for MPLS PSNs as described herein will interoperate with implementations designed to comply with Y.1413 subclause 9.2.2 or Y.1414 clause 10.
The MPLS header as described in [RFC3032] is prefixed to the control word and TDM payload. The packet structure is depicted in Figure 4.
The MPLS header as described in [RFC3032] is prefixed to the control word and TDM payload. The packet structure is depicted in Figure 4.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tunnel Label | EXP |S| TTL |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PW label | EXP |1| TTL |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RES |L|R| M |RES| Length | Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
opt|RTV|P|X| CC |M| PT | RTP Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
opt| Timestamp |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
opt| SSRC identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Adapted Payload |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Tunnel Label | EXP |S| TTL | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | PW label | EXP |1| TTL | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | RES |L|R| M |RES| Length | Sequence Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ opt|RTV|P|X| CC |M| PT | RTP Sequence Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ opt| Timestamp | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ opt| SSRC identifier | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Adapted Payload | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4. TDMoIP Packet Format for MPLS
Figure 4. TDMoIP Packet Format for MPLS
The first two rows depicted above are the MPLS header; the third is the TDMoIP control word. Fields not previously described will now be explained.
The first two rows depicted above are the MPLS header; the third is the TDMoIP control word. Fields not previously described will now be explained.
Tunnel Label (20 bits) is the MPLS label that identifies the MPLS
LSP used to tunnel the TDM packets through the MPLS network. The
label can be assigned either by manual provisioning or via an MPLS
control protocol. While transiting the MPLS network there may be
zero, one, or several tunnel label rows. For label stack usage
see [RFC3032].
Tunnel Label (20 bits) is the MPLS label that identifies the MPLS LSP used to tunnel the TDM packets through the MPLS network. The label can be assigned either by manual provisioning or via an MPLS control protocol. While transiting the MPLS network there may be zero, one, or several tunnel label rows. For label stack usage see [RFC3032].
Stein, et al. Informational [Page 12] RFC 5087 TDMoIP December 2007
Stein, et al. Informational [Page 12] RFC 5087 TDMoIP December 2007
EXP (3 bits) experimental field, may be used to carry Diffserv
classification for tunnel labels.
EXP (3 bits) experimental field, may be used to carry Diffserv classification for tunnel labels.
S (1 bit) the stacking bit indicates MPLS stack bottom. S=0 for all
tunnel labels, and S=1 for the PW label.
S (1 bit) the stacking bit indicates MPLS stack bottom. S=0 for all tunnel labels, and S=1 for the PW label.
TTL (8 bits) MPLS Time to live.
TTL (8 bits) MPLS Time to live.
PW Label (20 bits) This label MUST be a valid MPLS label, and MAY be
configured or signaled.
PW Label (20 bits) This label MUST be a valid MPLS label, and MAY be configured or signaled.
Stein, et al. Informational [Page 13] RFC 5087 TDMoIP December 2007
Stein, et al. Informational [Page 13] RFC 5087 TDMoIP December 2007
4.3. L2TPv3
4.3. L2TPv3
The L2TPv3 header defined in [RFC3931] is prefixed to the TDMoIP data. The packet structure is depicted in Figure 5.
The L2TPv3 header defined in [RFC3931] is prefixed to the TDMoIP data. The packet structure is depicted in Figure 5.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPVER | IHL | IP TOS | Total Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Identification |Flags| Fragment Offset |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Time to Live | Protocol | IP Header Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source IP Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination IP Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Session ID = PW label |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| cookie 1 (optional) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| cookie 2 (optional) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RES |L|R| M |RES| Length | Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
opt|RTV|P|X| CC |M| PT | RTP Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
opt| Timestamp |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
opt| SSRC identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Adapted Payload |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPVER | IHL | IP TOS | Total Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Identification |Flags| Fragment Offset | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Time to Live | Protocol | IP Header Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Source IP Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Destination IP Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Session ID = PW label | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | cookie 1 (optional) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | cookie 2 (optional) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | RES |L|R| M |RES| Length | Sequence Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ opt|RTV|P|X| CC |M| PT | RTP Sequence Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ opt| Timestamp | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ opt| SSRC identifier | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Adapted Payload | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5. TDMoIP Packet Format for L2TPv3
Figure 5. TDMoIP Packet Format for L2TPv3
Rows 6 through 8 are the L2TPv3 header. Fields not previously described will now be explained.
Rows 6 through 8 are the L2TPv3 header. Fields not previously described will now be explained.
Protocol (8 bits) is the IP protocol field. It must be set to 0x73
(115), the user port number that has been assigned to L2TP by
IANA.
Protocol (8 bits) is the IP protocol field. It must be set to 0x73 (115), the user port number that has been assigned to L2TP by IANA.
Session ID (32 bits) is the locally significant L2TP session
identifier, and contains the PW label. The value 0 is reserved.
Session ID (32 bits) is the locally significant L2TP session identifier, and contains the PW label. The value 0 is reserved.
Stein, et al. Informational [Page 14] RFC 5087 TDMoIP December 2007
Stein, et al. Informational [Page 14] RFC 5087 TDMoIP December 2007
Cookie (32 or 64 bits) is an optional field that contains a randomly
selected value that can be used to validate association of the
received frame with the expected PW.
Cookie (32 or 64 bits) is an optional field that contains a randomly selected value that can be used to validate association of the received frame with the expected PW.
4.4. Ethernet
4.4. Ethernet
Metro Ethernet Forum Implementation Agreement 8 [MEF8] describes structure-agnostic and structure-aware mechanisms for transporting TDM over Ethernet networks. Implementations of structure-indicated TDMoIP as described herein will interoperate with implementations designed to comply with MEF 8 Section 6.3.3.
Metro Ethernet Forum Implementation Agreement 8 [MEF8] describes structure-agnostic and structure-aware mechanisms for transporting TDM over Ethernet networks. Implementations of structure-indicated TDMoIP as described herein will interoperate with implementations designed to comply with MEF 8 Section 6.3.3.
The TDMoIP payload is encapsulated in an Ethernet frame by prefixing the Ethernet destination and source MAC addresses, optional VLAN header, and Ethertype, and suffixing the four-byte frame check sequence. TDMoIP implementations MUST be able to receive both industry standard (DIX) Ethernet and IEEE 802.3 [IEEE802.3] frames and SHOULD transmit Ethernet frames.
The TDMoIP payload is encapsulated in an Ethernet frame by prefixing the Ethernet destination and source MAC addresses, optional VLAN header, and Ethertype, and suffixing the four-byte frame check sequence. TDMoIP implementations MUST be able to receive both industry standard (DIX) Ethernet and IEEE 802.3 [IEEE802.3] frames and SHOULD transmit Ethernet frames.
Ethernet encapsulation introduces restrictions on both minimum and maximum packet size. Whenever the entire TDMoIP packet is less than 64 bytes, padding is introduced and the true length indicated by using the Length field in the control word. In order to avoid fragmentation, the TDMoIP packet MUST be restricted to the maximum payload size. For example, the length of the Ethernet payload for a UDP/IP encapsulation of AAL1 format payload with 30 PDUs per packet is 1472 bytes, which falls below the maximal permitted payload size of 1500 bytes.
Ethernet encapsulation introduces restrictions on both minimum and maximum packet size. Whenever the entire TDMoIP packet is less than 64 bytes, padding is introduced and the true length indicated by using the Length field in the control word. In order to avoid fragmentation, the TDMoIP packet MUST be restricted to the maximum payload size. For example, the length of the Ethernet payload for a UDP/IP encapsulation of AAL1 format payload with 30 PDUs per packet is 1472 bytes, which falls below the maximal permitted payload size of 1500 bytes.
Ethernet frames MAY be used for TDMoIP transport without intervening IP or MPLS layers, however, an MPLS-style label MUST always be present. In this four-byte header S=1, and all other non-label bits are reserved (set to zero in the PSN-bound direction and ignored in the TDM-bound direction). The Ethertype SHOULD be set to 0x88D8 (35032), the value allocated for this purpose by the IEEE, but MAY be set to 0x8847 (34887), the Ethertype of MPLS. The overall frame structure is as follows:
Ethernet frames MAY be used for TDMoIP transport without intervening IP or MPLS layers, however, an MPLS-style label MUST always be present. In this four-byte header S=1, and all other non-label bits are reserved (set to zero in the PSN-bound direction and ignored in the TDM-bound direction). The Ethertype SHOULD be set to 0x88D8 (35032), the value allocated for this purpose by the IEEE, but MAY be set to 0x8847 (34887), the Ethertype of MPLS. The overall frame structure is as follows:
Stein, et al. Informational [Page 15] RFC 5087 TDMoIP December 2007
Stein, et al. Informational [Page 15] RFC 5087 TDMoIP December 2007
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination MAC Address
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Destination MAC Address (cont) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source MAC Address
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Source MAC Address (cont) | VLAN Ethertype (opt) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|VLP|C| VLAN ID (opt) | Ethertype |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PW label | RES |1| RES |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RES |L|R| M |RES| Length | Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
opt|RTV|P|X| CC |M| PT | RTP Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
opt| Timestamp |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
opt| SSRC identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Adapted Payload |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Frame Check Sequence |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Destination MAC Address +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Destination MAC Address (cont) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Source MAC Address +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Source MAC Address (cont) | VLAN Ethertype (opt) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |VLP|C| VLAN ID (opt) | Ethertype | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | PW label | RES |1| RES | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | RES |L|R| M |RES| Length | Sequence Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ opt|RTV|P|X| CC |M| PT | RTP Sequence Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ opt| Timestamp | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ opt| SSRC identifier | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Adapted Payload | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Frame Check Sequence | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6. TDMoIP Packet Format for Ethernet
Figure 6. TDMoIP Packet Format for Ethernet
Rows 1 through 6 are the (DIX) Ethernet header; for 802.3 there may be additional fields, depending on the value of the length field, see [IEEE802.3]. Fields not previously described will now be explained.
Rows 1 through 6 are the (DIX) Ethernet header; for 802.3 there may be additional fields, depending on the value of the length field, see [IEEE802.3]. Fields not previously described will now be explained.
Destination MAC Address (48 bits) is the globally unique address of
a single station that is to receive the packet. The format is
defined in [IEEE802.3].
Destination MAC Address (48 bits) is the globally unique address of a single station that is to receive the packet. The format is defined in [IEEE802.3].
Source MAC Address (48 bits) is the globally unique address of the
station that originated the packet. The format is defined in
[IEEE802.3].
Source MAC Address (48 bits) is the globally unique address of the station that originated the packet. The format is defined in [IEEE802.3].
Stein, et al. Informational [Page 16] RFC 5087 TDMoIP December 2007
Stein, et al. Informational [Page 16] RFC 5087 TDMoIP December 2007
VLAN Ethertype (16 bits) 0x8100 in this position indicates that
optional VLAN tagging specified in [IEEE802.1Q] is employed, and
that the next two bytes contain the VLP, C, and VLAN ID fields.
VLAN tags may be stacked, in which case the two-byte field
following the VLAN ID is once again a VLAN Ethertype.
VLAN Ethertype (16 bits) 0x8100 in this position indicates that optional VLAN tagging specified in [IEEE802.1Q] is employed, and that the next two bytes contain the VLP, C, and VLAN ID fields. VLAN tags may be stacked, in which case the two-byte field following the VLAN ID is once again a VLAN Ethertype.
VLP (3 bits) is the VLAN priority, see [IEEE802.1Q].
VLP (3 bits) is the VLAN priority, see [IEEE802.1Q].
C (1 bit) the "canonical format indicator" being set, indicates that
route descriptors appear; see [IEEE802.1Q].
C (1 bit) the "canonical format indicator" being set, indicates that route descriptors appear; see [IEEE802.1Q].
VLAN ID (12 bits) the VLAN identifier uniquely identifies the VLAN
to which the frame belongs. If zero, only the VLP information is
meaningful. Values 1 and FFF are reserved. The other 4093 values
are valid VLAN identifiers.
VLAN ID (12 bits) the VLAN identifier uniquely identifies the VLAN to which the frame belongs. If zero, only the VLP information is meaningful. Values 1 and FFF are reserved. The other 4093 values are valid VLAN identifiers.
Ethertype (16 bits) is the protocol identifier, as allocated by the
IEEE. The Ethertype SHOULD be set to 0x88D8 (35032), but MAY be
set to 0x8847 (34887).
Ethertype (16 bits) is the protocol identifier, as allocated by the IEEE. The Ethertype SHOULD be set to 0x88D8 (35032), but MAY be set to 0x8847 (34887).
PW Label (20 bits) This label MUST be manually configured. The
remainder of this row is formatted to resemble an MPLS label.
PW Label (20 bits) This label MUST be manually configured. The remainder of this row is formatted to resemble an MPLS label.
Frame Check Sequence (32 bits) is a Cyclic Redundancy Check (CRC)
error detection field, calculated per [IEEE802.3].
Frame Check Sequence (32 bits) is a Cyclic Redundancy Check (CRC) error detection field, calculated per [IEEE802.3].
5. TDMoIP Payload Types
5. TDMoIP Payload Types
As discussed at the end of Section 3, TDMoIP transports real-time streams by first extracting bytes from the stream, and then adapting these bytes. TDMoIP offers two different adaptation algorithms, one for constant-rate real-time traffic, and one for variable-rate real- time traffic.
As discussed at the end of Section 3, TDMoIP transports real-time streams by first extracting bytes from the stream, and then adapting these bytes. TDMoIP offers two different adaptation algorithms, one for constant-rate real-time traffic, and one for variable-rate real- time traffic.
For unstructured TDM, or structured but unchannelized TDM, or structured channelized TDM with all channels active all the time, a constant-rate adaptation is needed. In such cases TDMoIP uses structure-indication to emulate the native TDM circuit, and the adaptation is known as "circuit emulation". However, for channelized TDM wherein the individual channels (corresponding to "loops" in telephony terminology) are frequently inactive, bandwidth may be conserved by transporting only active channels. This results in variable-rate real-time traffic, for which TDMoIP uses structure- reassembly to emulate the individual loops, and the adaptation is known as "loop emulation".
For unstructured TDM, or structured but unchannelized TDM, or structured channelized TDM with all channels active all the time, a constant-rate adaptation is needed. In such cases TDMoIP uses structure-indication to emulate the native TDM circuit, and the adaptation is known as "circuit emulation". However, for channelized TDM wherein the individual channels (corresponding to "loops" in telephony terminology) are frequently inactive, bandwidth may be conserved by transporting only active channels. This results in variable-rate real-time traffic, for which TDMoIP uses structure- reassembly to emulate the individual loops, and the adaptation is known as "loop emulation".
Stein, et al. Informational [Page 17] RFC 5087 TDMoIP December 2007
Stein, et al. Informational [Page 17] RFC 5087 TDMoIP December 2007
TDMoIP uses constant-rate AAL1 [AAL1,CES] for circuit emulation, while variable-rate AAL2 [AAL2] is employed for loop emulation. The AAL1 mode MUST be used for structured transport of unchannelized data and SHOULD be used for circuits with relatively constant usage. In addition, AAL1 MUST be used when the TDM-bound IWF is required to maintain a high timing accuracy (e.g., when its timing is further distributed) and SHOULD be used when high reliability is required. AAL2 SHOULD be used for channelized TDM when bandwidth needs to be conserved, and MAY be used whenever usage of voice-carrying channels is expected to be highly variable.
TDMoIP uses constant-rate AAL1 [AAL1,CES] for circuit emulation, while variable-rate AAL2 [AAL2] is employed for loop emulation. The AAL1 mode MUST be used for structured transport of unchannelized data and SHOULD be used for circuits with relatively constant usage. In addition, AAL1 MUST be used when the TDM-bound IWF is required to maintain a high timing accuracy (e.g., when its timing is further distributed) and SHOULD be used when high reliability is required. AAL2 SHOULD be used for channelized TDM when bandwidth needs to be conserved, and MAY be used whenever usage of voice-carrying channels is expected to be highly variable.
Additionally, a third mode is defined specifically for efficient transport of High-Level Data Link Control (HDLC)-based Common Channel Signaling (CCS) carried in TDM channels.
Additionally, a third mode is defined specifically for efficient transport of High-Level Data Link Control (HDLC)-based Common Channel Signaling (CCS) carried in TDM channels.
The AAL family of protocols is a natural choice for TDM emulation. Although originally developed to adapt various types of application data to the rigid format of ATM, the mechanisms are general solutions to the problem of transporting constant or variable-rate real-time streams over a packet network.
The AAL family of protocols is a natural choice for TDM emulation. Although originally developed to adapt various types of application data to the rigid format of ATM, the mechanisms are general solutions to the problem of transporting constant or variable-rate real-time streams over a packet network.
Since the AAL mechanisms are extensively deployed within and on the edge of the public telephony system, they have been demonstrated to reliably transfer voice-grade channels, data and telephony signaling. These mechanisms are mature and well understood, and implementations are readily available.
Since the AAL mechanisms are extensively deployed within and on the edge of the public telephony system, they have been demonstrated to reliably transfer voice-grade channels, data and telephony signaling. These mechanisms are mature and well understood, and implementations are readily available.
Finally, simplified service interworking with legacy networks is a major design goal of TDMoIP. Re-use of AAL technologies simplifies interworking with existing AAL1- and AAL2-based networks.
Finally, simplified service interworking with legacy networks is a major design goal of TDMoIP. Re-use of AAL technologies simplifies interworking with existing AAL1- and AAL2-based networks.
5.1. AAL1 Format Payload
5.1. AAL1 Format Payload
For the prevalent cases of unchannelized TDM, or channelized TDM for which the channel allocation is static, the payload can be efficiently encoded using constant-rate AAL1 adaptation. The AAL1 format is described in [AAL1] and its use for circuit emulation over ATM in [CES]. We briefly review highlights of AAL1 technology in Appendix B. In this section we describe the use of AAL1 in the context of TDMoIP.
For the prevalent cases of unchannelized TDM, or channelized TDM for which the channel allocation is static, the payload can be efficiently encoded using constant-rate AAL1 adaptation. The AAL1 format is described in [AAL1] and its use for circuit emulation over ATM in [CES]. We briefly review highlights of AAL1 technology in Appendix B. In this section we describe the use of AAL1 in the context of TDMoIP.
+-------------+----------------+
|control word | AAL1 PDU |
+-------------+----------------+
+-------------+----------------+ |control word | AAL1 PDU | +-------------+----------------+
Figure 7a. Single AAL1 PDU per TDMoIP Packet
Figure 7a. Single AAL1 PDU per TDMoIP Packet
Stein, et al. Informational [Page 18] RFC 5087 TDMoIP December 2007
Stein, et al. Informational [Page 18] RFC 5087 TDMoIP December 2007
+-------------+----------------+ +----------------+
|control word | AAL1 PDU |---| AAL1 PDU |
+-------------+----------------+ +----------------+
+-------------+----------------+ +----------------+ |control word | AAL1 PDU |---| AAL1 PDU | +-------------+----------------+ +----------------+
Figure 7b. Multiple AAL1 PDUs per TDMoIP Packet
Figure 7b. Multiple AAL1 PDUs per TDMoIP Packet
In AAL1 mode the TDMoIP payload consists of at least one, and perhaps many, 48-byte "AAL1 PDUs", see Figures 7a and 7b. The number of PDUs MUST be pre-configured and MUST be chosen such that the overall packet size does not exceed the maximum allowed by the PSN (e.g., 30 for UDP/IP over Ethernet). The precise number of PDUs per packet is typically chosen taking latency and bandwidth constraints into account. Using a single PDU delivers minimal latency, but incurs the highest overhead. All TDMoIP implementations MUST support between 1 and 8 PDUs per packet for E1 and T1 circuits, and between 5 and 15 PDUs per packet for E3 and T3 circuits.
In AAL1 mode the TDMoIP payload consists of at least one, and perhaps many, 48-byte "AAL1 PDUs", see Figures 7a and 7b. The number of PDUs MUST be pre-configured and MUST be chosen such that the overall packet size does not exceed the maximum allowed by the PSN (e.g., 30 for UDP/IP over Ethernet). The precise number of PDUs per packet is typically chosen taking latency and bandwidth constraints into account. Using a single PDU delivers minimal latency, but incurs the highest overhead. All TDMoIP implementations MUST support between 1 and 8 PDUs per packet for E1 and T1 circuits, and between 5 and 15 PDUs per packet for E3 and T3 circuits.
AAL1 differentiates between unstructured and structured data transfer, which correspond to structure-agnostic and structure-aware transport. For structure-agnostic transport, AAL1 provides no inherent advantage as compared to SAToP; however, there may be scenarios for which its use is desirable. For example, when it is necessary to interwork with an existing AAL1 ATM circuit emulation system, or when clock recovery based on AAL1-specific mechanisms is favored.
AAL1 differentiates between unstructured and structured data transfer, which correspond to structure-agnostic and structure-aware transport. For structure-agnostic transport, AAL1 provides no inherent advantage as compared to SAToP; however, there may be scenarios for which its use is desirable. For example, when it is necessary to interwork with an existing AAL1 ATM circuit emulation system, or when clock recovery based on AAL1-specific mechanisms is favored.
For structure-aware transport, [CES] defines two modes, structured and structured with Channel Associated Signaling (CAS). Structured AAL1 maintains TDM frame synchronization by embedding a pointer to the beginning of the next frame in the AAL1 PDU header. Similarly, structured AAL1 with CAS maintains TDM frame and multiframe synchronization by embedding a pointer to the beginning of the next multiframe. Furthermore, structured AAL1 with CAS contains a substructure including the CAS signaling bits.
For structure-aware transport, [CES] defines two modes, structured and structured with Channel Associated Signaling (CAS). Structured AAL1 maintains TDM frame synchronization by embedding a pointer to the beginning of the next frame in the AAL1 PDU header. Similarly, structured AAL1 with CAS maintains TDM frame and multiframe synchronization by embedding a pointer to the beginning of the next multiframe. Furthermore, structured AAL1 with CAS contains a substructure including the CAS signaling bits.
5.2. AAL2 Format Payload
5.2. AAL2 Format Payload
Although AAL1 may be configured to transport fractional E1 or T1
circuits, the allocation of channels to be transported must be static
due to the fact that AAL1 transports constant-rate bit-streams. It
is often the case that not all the channels in a TDM circuit are
simultaneously active ("off-hook"), and activity status may be
determined by observation of the TDM signaling channel. Moreover,
even during active calls, about half the time is silence that can be
identified using voice activity detection (VAD). Using the variable-
rate AAL2 mode, we may dynamically allocate channels to be
transported, thus conserving bandwidth.
Although AAL1 may be configured to transport fractional E1 or T1 circuits, the allocation of channels to be transported must be static due to the fact that AAL1 transports constant-rate bit-streams. It is often the case that not all the channels in a TDM circuit are simultaneously active ("off-hook"), and activity status may be determined by observation of the TDM signaling channel. Moreover, even during active calls, about half the time is silence that can be identified using voice activity detection (VAD). Using the variable- rate AAL2 mode, we may dynamically allocate channels to be transported, thus conserving bandwidth.
Stein, et al. Informational [Page 19] RFC 5087 TDMoIP December 2007
Stein, et al. Informational [Page 19] RFC 5087 TDMoIP December 2007
The AAL2 format is described in [AAL2] and its use for loop emulation over ATM is explained in [SSCS,LES]. We briefly review highlights of AAL2 technology in Appendix C. In this section, we describe the use of AAL2 in the context of TDMoIP.
The AAL2 format is described in [AAL2] and its use for loop emulation over ATM is explained in [SSCS,LES]. We briefly review highlights of AAL2 technology in Appendix C. In this section, we describe the use of AAL2 in the context of TDMoIP.
+-------------+----------------+ +----------------+
|control word | AAL2 PDU |---| AAL2 PDU |
+-------------+----------------+ +----------------+
+-------------+----------------+ +----------------+ |control word | AAL2 PDU |---| AAL2 PDU | +-------------+----------------+ +----------------+
Figure 8. Concatenation of AAL2 PDUs in a TDMoIP Packet
Figure 8. Concatenation of AAL2 PDUs in a TDMoIP Packet
In AAL2 mode the TDMoIP payload consists of one or more variable- length "AAL2 PDUs", see Figure 8. Each AAL2 PDU contains 3 bytes of overhead and between 1 and 64 bytes of payload. A packet may be constructed by inserting PDUs corresponding to all active channels, by appending PDUs ready at a certain time, or by any other means. Hence, more than one PDU belonging to a single channel may appear in a packet.
In AAL2 mode the TDMoIP payload consists of one or more variable- length "AAL2 PDUs", see Figure 8. Each AAL2 PDU contains 3 bytes of overhead and between 1 and 64 bytes of payload. A packet may be constructed by inserting PDUs corresponding to all active channels, by appending PDUs ready at a certain time, or by any other means. Hence, more than one PDU belonging to a single channel may appear in a packet.
[RFC3985] denotes as Native Service Processing (NSP) functions all processing of the TDM data before its use as payload. Since AAL2 is inherently variable rate, arbitrary NSP functions MAY be performed before the channel is placed in the AAL2 loop emulation payload. These include testing for on-hook/off-hook status, voice activity detection, speech compression, fax/modem/tone relay, etc.
[RFC3985] denotes as Native Service Processing (NSP) functions all processing of the TDM data before its use as payload. Since AAL2 is inherently variable rate, arbitrary NSP functions MAY be performed before the channel is placed in the AAL2 loop emulation payload. These include testing for on-hook/off-hook status, voice activity detection, speech compression, fax/modem/tone relay, etc.
All mechanisms described in [AAL2,SSCS,LES] may be used for TDMoIP. In particular, channel identifier (CID) encoding and use of PAD octets according to [AAL2], encoding formats defined in [SSCS], and transport of CAS and CCS signaling as described in [LES] MAY all be used in the PSN-bound direction, and MUST be supported in the TDM- bound direction. The overlap functionality and AAL-CU timer and related functionalities may not be required, and the STF (start field) is NOT used. Computation of error detection codes -- namely, the Header Error Check (HEC) in the AAL2 PDU header and the CRC in the CAS packet -- is superfluous if an appropriate error detection mechanism is provided by the PSN. In such cases, these fields MAY be set to zero.
All mechanisms described in [AAL2,SSCS,LES] may be used for TDMoIP. In particular, channel identifier (CID) encoding and use of PAD octets according to [AAL2], encoding formats defined in [SSCS], and transport of CAS and CCS signaling as described in [LES] MAY all be used in the PSN-bound direction, and MUST be supported in the TDM- bound direction. The overlap functionality and AAL-CU timer and related functionalities may not be required, and the STF (start field) is NOT used. Computation of error detection codes -- namely, the Header Error Check (HEC) in the AAL2 PDU header and the CRC in the CAS packet -- is superfluous if an appropriate error detection mechanism is provided by the PSN. In such cases, these fields MAY be set to zero.
5.3. HDLC Format Payload
5.3. HDLC Format Payload
The motivation for handling HDLC in TDMoIP is to efficiently transport common channel signaling (CCS) such as SS7 [SS7] or ISDN PRI signaling [ISDN-PRI], embedded in the TDM stream. This mechanism is not intended for general HDLC payloads, and assumes that the HDLC messages are always shorter than the maximum packet size.
The motivation for handling HDLC in TDMoIP is to efficiently transport common channel signaling (CCS) such as SS7 [SS7] or ISDN PRI signaling [ISDN-PRI], embedded in the TDM stream. This mechanism is not intended for general HDLC payloads, and assumes that the HDLC messages are always shorter than the maximum packet size.
Stein, et al. Informational [Page 20] RFC 5087 TDMoIP December 2007
Stein, et al. Informational [Page 20] RFC 5087 TDMoIP December 2007
The HDLC mode should only be used when the majority of the bandwidth of the input HDLC stream is expected to be occupied by idle flags. Otherwise, the CCS channel should be treated as an ordinary channel.
使用されていない旗で入力HDLCストリームの帯域幅の大部分が占領されることが期待されるときだけ、HDLCモードは使用されるべきです。 さもなければ、CCSチャンネルは普通のチャンネルとして扱われるべきです。
The HDLC format is intended to operate in port mode, transparently passing all HDLC data and control messages over a separate PW. The encapsulation is compatible with that of [RFC4618], however the sequence number generation and processing SHOULD be performed according to Section 3 above.
HDLC形式がポートモードで作動することを意図します、透明にすべてのHDLCデータとコントロールメッセージを別々のPWの上に通過して。 カプセル化はしかしながら、[RFC4618]、一連番号世代のものと互換性があります、そして、SHOULDを処理して、上のセクション3に従って、実行されてください。
The PSN-bound IWF monitors flags until a frame is detected. The contents of the frame are collected and the Frame Check Sequence (FCS) tested. If the FCS is incorrect, the frame is discarded; otherwise, the frame is sent after initial or final flags and FCS have been discarded and zero removal has been performed. When a TDMoIP-HDLC frame is received, its FCS is recalculated, and the original HDLC frame reconstituted.
フレームが検出されるまで、PSN行きのIWFは旗をモニターします。 フレームの内容は集められました、そして、Frame Check Sequence(FCS)はテストしました。 FCSが不正確であるなら、フレームは捨てられます。 さもなければ、初期的、または、最終的な旗とFCSを捨てて、取り外しを全く実行していなかった後にフレームを送ります。 TDMoIP-HDLCフレームが受け取られているとき、FCSは再計算されていてHDLCフレームが再編成したオリジナルです。
6. TDMoIP Defect Handling
6. TDMoIP欠陥取り扱い
Native TDM networks signify network faults by carrying indications of forward defects (AIS) and reverse defects (RDI) in the TDM bit stream. Structure-agnostic TDM transport transparently carries all such indications; however, for structure-aware mechanisms where the PSN-bound IWF may remove TDM structure overhead carrying defect indications, explicit signaling of TDM defect conditions is required.
固有のTDMネットワークは、前進の欠陥(AIS)のしるしを運ぶことによってネットワーク障害を意味して、TDMビットストリームで欠陥(RDI)を覆します。 構造不可知論者TDM輸送は透明にそのようなすべての指摘を運びます。 しかしながら、PSN行きのIWFが欠陥指摘を運びながらTDM構造オーバーヘッドを取り除くかもしれない構造意識しているメカニズムにおいて、TDM欠陥状態の明白なシグナリングが必要です。
We saw in Section 3 that defects can be indicated by setting flags in the control word. This insertion of defect reporting into the packet rather than in a separate stream mimics the behavior of native TDM OAM mechanisms that carry such indications as bit patterns embedded in the TDM stream. The flags are designed to address the urgent messaging, i.e., messages whose contents must not be significantly delayed with respect to the TDM data that they potentially impact. Mechanisms for slow OAM messaging are discussed in Appendix D.
私たちは、セクション3で規制単語に旗をはめ込むことによって欠陥を示すことができるのを見ました。 別々の流れでというよりむしろパケットへの欠陥報告のこの挿入はビット・パターンがTDMの流れに埋め込んだような指摘を乗せる固有のTDM OAMメカニズムの振舞いをまねます。 旗は、緊急のメッセージング(すなわち、コンテンツがそれらが潜在的に影響を与えるTDMデータに関してかなり遅れてはいけないメッセージ)を記述するように設計されています。 Appendix Dで遅いOAMメッセージングのためのメカニズムについて議論します。
+---+ +-----+ +------+ +-----+ +------+ +-----+ +---+
|TDM|->-| |->-|TDMoIP|->-| |->-|TDMoIP|->-| |->-|TDM|
| | |TDM 1| | | | PSN | | | |TDM 2| | |
|ES1|-<-| |-<-| IWF1 |-<-| |-<-| IWF2 |-<-| |-<-|ES2|
+---+ +-----+ +------+ +-----+ +------+ +-----+ +---+
+---+ +-----+ +------+ +-----+ +------+ +-----+ +---+ |TDM| >| | >|TDMoIP| >| | >|TDMoIP| >| | >|TDM| | | |TDM1| | | | PSN| | | |TDM2| | | |ES1| <| | <| IWF1| <| | <| IWF2| <| | <|ES2| +---+ +-----+ +------+ +-----+ +------+ +-----+ +---+
Figure 9. Typical TDMoIP Network Configuration
図9。 典型的なTDMoIPネットワーク・コンフィギュレーション
The operation of TDMoIP defect handling is best understood by considering the downstream TDM flow from TDM end system 1 (ES1) through TDM network 1, through TDMoIP IWF 1 (IWF1), through the PSN, through TDMoIP IWF 2 (IWF2), through TDM network 2, towards TDM end
川下のTDMがTDMエンドシステム1(ES1)からTDMネットワーク1の流れであると考えるのにTDMoIP欠陥取り扱いの操作は特に解釈されます、TDMoIP IWF1(IWF1)を通して、PSNを通して、TDMoIP IWF2(IWF2)を通して、TDMネットワーク2を通して、TDMエンドに向かって
Stein, et al. Informational [Page 21] RFC 5087 TDMoIP December 2007
シタイン、他 [21ページ]情報のRFC5087TDMoIP2007年12月
system 2 (ES2), as depicted in the figure. We wish not only to detect defects in TDM network 1, the PSN, and TDM network 2, but to localize such defects in order to raise alarms only in the appropriate network.
図に表現されるようなシステム2(ES2)。 私たちはどんなTDMネットワーク1、PSNに欠陥を検出するために唯一とTDMネットワーク2も願っていませんが、そのようなものを局所化するのは、適切なネットワークだけでアラームを上げるために亡命されます。
In the "trail terminated" OAM scenario, only user data is exchanged between TDM network 1 and TDM network 2. The IWF functions as a TDM trail termination function, and defects detected in TDM network 1 are not relayed to network 2, or vice versa.
「道は終わった」OAMというシナリオでは、TDMネットワーク1とTDMネットワーク2の間で利用者データだけを交換します。 TDM道の終了としてのIWF機能は機能します、そして、TDMネットワーク1で検出された欠陥はネットワーク2にリレーされないか、逆もまた同様です。
In the "trail extended" OAM scenario, if there is a defect (e.g.,
loss of signal or loss of frame synchronization) anywhere in TDM
network 1 before the ultimate link, the following TDM node will
generate AIS downstream (towards TDMoIP IWF1). If a break occurs in
the ultimate link, the IWF itself will detect the loss of signal. In
either case, IWF1 having directly detected lack of validity of the
TDM signal, or having been informed of an earlier problem, raises the
local ("L") defect flag in the control word of the packets it sends
across the PSN. In this way the trail is extended to TDM network 2
across the PSN.
「道は広がった」OAMというシナリオでは、欠陥(フレーム同期化の例えば、信号の損失か損失)が究極のリンクの前にTDMネットワーク1で何処かでにあると、以下のTDMノードが川下(TDMoIP IWF1に向かって)でAISを発生させるでしょう。 中断が究極のリンクに起こると、IWF自身は信号の損失を検出するでしょう。 どちらの場合ではも、TDM信号の正当性、または以前の問題について知識があったことの直接検出された不足を持っているIWF1がそれがPSNの向こう側に送るパケットの規制単語でローカルの(「L」)欠陥旗を上げます。 このように、道はPSNの向こう側にTDMネットワーク2に広げられます。
Unlike forward defect indications that are generated by all network elements, reverse defect indications are only generated by trail termination functions. In the trail terminated scenario, IWF1 serves as a trail termination function for TDM network 1, and thus when IWF1 directly detects lack of validity of the TDM signal, or is informed of an earlier problem, it MAY generate TDM RDI towards TDM ES1. In the trail extended scenario IWF1 is not a trail termination, and hence MUST NOT generate TDM RDI, but rather, as we have seen, sets the L defect flag. As we shall see, this will cause the AIS indication to reach ES2, which is the trail termination, and which MAY generate TDM RDI.
すべてのネットワーク要素で発生する前進の欠陥指摘と異なって、逆の欠陥指摘は道の終了機能で発生するだけです。 道では、シナリオが終わっていました、TDMネットワーク1のための道の終了機能としてのIWF1サーブ、そして、その結果、IWF1は直接TDM信号の正当性の不足を検出するか、または以前の問題において知識があるとき、それがTDM ES1に向かってTDM RDIを発生させるかもしれません。 道では、拡張シナリオIWF1は道の終了でなく、したがって、TDM RDIを発生させてはいけませんが、むしろ周知のごとくL欠陥旗を設定します。 私たちが見るように、AIS指示はこれで、ES2に達するでしょう。(ES2は道の終了であり、TDM RDIを発生させるかもしれません)。
When the L flag is set there are four possibilities for treatment of payload content. The default is for IWF1 to fill the payload with the appropriate amount of AIS (usually all-ones) data. If the AIS has been generated before the IWF this can be accomplished by copying the received TDM data; if the penultimate TDM link fails and the IWF needs to generate the AIS itself. Alternatively, with structure- aware transport of channelized TDM one SHOULD fill the payload with "trunk conditioning"; this involves placing a preconfigured "out of service" code in each individual channel (the "out of service" code may differ between voice and data channels). Trunk conditioning MUST be used when channels taken from several TDM PWs are combined by the TDM-bound IWF into a single TDM circuit. The third possibility is to suppress the payload altogether. Finally, if IWF1 believes that the TDM defect is minor or correctable (e.g., loss of multiframe synchronization, or initial phases of detection of incorrect frame
L旗が設定されるとき、ペイロード内容の処理のための4つの可能性があります。 デフォルトはIWF1が適切な量のAIS(通常オールもの)データでペイロードを満たすことです。 AISがIWFの前で発生したなら、受信されたTDMデータをコピーすることによって、これを達成できます。 終わりから二番目のTDMリンクが失敗して、IWFが、AIS自身を発生させる必要があるなら。 あるいはまた、channelized TDM1の構造の意識している輸送で、SHOULDは「トランク調節」でペイロードを満たします。 これは、あらかじめ設定された「使われなくなる」コードをそれぞれの独特のチャンネルに置くことを伴います(「使われなくなる」コードは声とデータ・チャンネルの間で異なるかもしれません)。 数個のTDM PWsから取られたチャンネルがTDM行きのIWFによってただ一つのTDMサーキットに結合されるとき、トランク調節を使用しなければなりません。 3番目の可能性は全体でペイロードを抑圧することです。 IWF1が、TDM欠陥が小さい方である、または修正可能であると最終的に信じている、(例えば、「マルチ-フレーム」同期の損失、または不正確なフレームの検出の初期位相
Stein, et al. Informational [Page 22] RFC 5087 TDMoIP December 2007
シタイン、他 [22ページ]情報のRFC5087TDMoIP2007年12月
sync), it MAY place the TDM data it has received into the payload
field, and specify in the defect modification field ("M") that the
TDM data is corrupted, but potentially recoverable.
同時性)、TDMデータが崩壊していますが、潜在的に回復可能であることは、それがペイロード分野に受け取ったTDMデータを置いて、欠陥変更分野(「M」)で指定するかもしれません。
When IWF2 receives a local defect indication without M field modification, it forwards (or generates if the payload has been suppressed) AIS or trunk conditioning towards ES2 (the choice between AIS and conditioning being preconfigured). Thus AIS has been properly delivered to ES2 emulating the TDM scenario from the TDM end system's point of view. In addition, IWF2 receiving the L flag uniquely specifies that the defect was in TDM network 1 and not in TDM network 2, thus suppressing alarms in the correctly functioning network.
または、IWF2がM分野変更なしで地方の欠陥指示を受けて、それがフォワードである、(ペイロードが抑圧されたなら発生する、)、ES2(あらかじめ設定されるAISと調節の選択)に向かったAISかトランク調節。 したがって、AISをTDMエンドシステムの観点からTDMシナリオを見習うES2に適切に渡しました。 さらに、唯一L旗を受けるIWF2は、TDMネットワーク1には欠陥がTDMネットワーク2にはあったのではなく、あったと指定します、その結果、正しく機能しているネットワークでアラームを抑圧します。
If the M field indicates that the TDM has been marked as potentially recoverable, then implementation specific algorithms (not herein specified) may optionally be utilized to minimize the impact of transient defects on the overall network performance. If the M field indicates that the TDM is "idle", no alarms should be raised and IWF2 treats the payload contents as regular TDM data. If the payload has been suppressed, trunk conditioning and not AIS MUST be generated by IWF2.
M分野が、TDMが潜在的に回復可能であるとしてマークされたのを示すなら、実現の特定のアルゴリズム(ここに指定されない)は、総合的なネットワーク性能のときに一時的な欠陥の影響を最小にするのに任意に利用されるかもしれません。 M分野が、TDMが「活動していません」を示すなら、アラームを全く上げるべきではありません、そして、IWF2は通常のTDMデータとしてペイロードコンテンツを扱います。 ペイロードがAIS MUSTではなく、抑圧されたトランク調節であるなら、IWF2によって、発生してください。
The second case is when the defect is in TDM network 2. Such defects cause AIS generation towards ES2, which may respond by sending TDM RDI in the reverse direction. In the trail terminated scenario this RDI is restricted to network 2. In the trail extended scenario, IWF2 upon observing this RDI inserted into valid TDM data, MUST indicate this by setting the "R" flag in packets sent back across the PSN towards IWF1. IWF1, upon receiving this indication, generates RDI towards ES1, thus emulating a single conventional TDM network.
2番目のケースはTDMネットワーク2には欠陥がある時です。 そのような欠陥はES2に向かってAIS世代を引き起こします。ES2は、反対の方向にTDM RDIを送ることによって、応じるかもしれません。 道の終えられたシナリオでは、このRDIはネットワーク2に制限されます。 道で、拡張シナリオ(有効なTDMデータに挿入されたこのRDIを観測するときのIWF2)は、PSNの向こう側にIWF1に向かって返送されたパケットに「R」旗をはめ込むことによって、これを示さなければなりません。 この指示を受けるときIWF1はES1に向かってRDIを発生させて、その結果、ただ一つの従来のTDMネットワークを見習います。
The final possibility is that of a unidirectional defect in the PSN. In such a case, TDMoIP IWF1 sends packets toward IWF2, but these are not received. IWF2 MUST inform the PSN's management system of this problem, and furthermore generate TDM AIS towards ES2. ES2 may respond with TDM RDI, and as before, in the trail extended scenario, when IWF2 detects RDI it MUST raise the "R" flag indication. When IWF1 receives packets with the "R" flag set it has been informed of a reverse defect, and MUST generate TDM RDI towards ES1.
最終的な可能性はPSNの単方向の欠陥のものです。 このような場合には、TDMoIP IWF1はIWF2に向かってパケットを送りますが、これらは受け取られていません。 IWF2 MUSTはPSNのこの問題のマネージメントシステムを知らせて、その上、ES2に向かってTDM AISを発生させます。 ES2はTDM RDIと共に応じるかもしれません、そして、シナリオが以前道で広がっていたので、IWF2がRDIを検出するとき、それは「R」旗の指示を上げなければなりません。 IWF1が「R」旗のセットでパケットを受けるとき、それは、逆の欠陥において知識があって、ES1に向かってTDM RDIを発生させなければなりません。
In all cases, if any of the above defects persist for a preconfigured period (default value of 2.5 seconds) a service failure is declared. Since TDM PWs are inherently bidirectional, a persistent defect in either directional results in a bidirectional service failure. In addition, if signaling is sent over a distinct PW as per Section 5.3, both PWs are considered to have failed when persistent defects are detected in either.
すべての場合では、上の欠陥のどれかがあらかじめ設定された期間(2.5秒のデフォルト値)、持続しているなら、サービス失敗は宣言されます。 TDM PWsが本来双方向であるので、方向のしつこい欠陥は双方向のサービス失敗をもたらします。 さらに、セクション5.3に従って異なったPWの上にシグナリングを送るなら、しつこい欠陥がどちらかに検出されるとき、失敗したと両方のPWsを考えます。
Stein, et al. Informational [Page 23] RFC 5087 TDMoIP December 2007
シタイン、他 [23ページ]情報のRFC5087TDMoIP2007年12月
When failure is declared the PW MUST be withdrawn, and both TDMoIP IWFs commence sending AIS (and not trunk conditioning) to their respective TDM networks. The IWFs then engage in connectivity testing using native methods or TDMoIP OAM as described in Appendix D until connectivity is restored.
失敗がPW MUSTであると宣言されたら引き下がってください。そうすれば、両方のTDMoIP IWFsは、AIS(どんなトランクも条件としないで)を彼らのそれぞれのTDMネットワークに送り始めます。 そして、接続性が回復するまでAppendix Dで説明されるように固有の方法かTDMoIP OAMを使用することでIWFsは接続性テストに従事しています。
7. Implementation Issues
7. 導入問題
General requirements for transport of TDM over pseudo-wires are detailed in [RFC4197]. In the following subsections we review additional aspects essential to successful TDMoIP implementation.
TDMの輸送のための一般要件は[RFC4197]で疑似ワイヤの上に詳しく述べられます。 以下の小区分では、私たちはうまくいっているTDMoIP実現に不可欠の追加局面について調査します。
7.1. Jitter and Packet Loss
7.1. ジターとパケット損失
In order to compensate for packet delay variation that exists in any PSN, a jitter buffer MUST be provided. A jitter buffer is a block of memory into which the data from the PSN is written at its variable arrival rate, and data is read out and sent to the destination TDM equipment at a constant rate. Use of a jitter buffer partially hides the fact that a PSN has been traversed rather than a conventional synchronous TDM network, except for the additional latency. Customary practice is to operate with the jitter buffer approximately half full, thus minimizing the probability of its overflow or underflow. Hence, the additional delay equals half the jitter buffer size. The length of the jitter buffer SHOULD be configurable and MAY be dynamic (i.e., grow and shrink in length according to the statistics of the Packet Delay Variation (PDV)).
どんなPSNにも存在するパケット遅れ変化を補うために、ジターバッファを提供しなければなりません。 ジターバッファがPSNからのデータが可変到着率で書かれている1ブロックのメモリであり、一定の割合で目的地TDM設備にデータを読みだして、送ります。 ジターバッファの使用はPSNが従来の同期TDMネットワークよりむしろ横断されたという事実を部分的に隠します、追加潜在を除いて。 ジターバッファにほとんど半分入っていた状態で、通例の習慣は作動することになっています、その結果、そのオーバーフローかアンダーフローの確率を最小にします。 したがって、追加遅れはジターバッファサイズの半分と等しいです。 ジターバッファSHOULDの長さは、構成可能であり、ダイナミックであるかもしれません(すなわち、成長して、Packet Delay Variation(PDV)の統計によると、丈が詰まっています)。
In order to handle (infrequent) packet loss and misordering, a packet sequence integrity mechanism MUST be provided. This mechanism MUST track the serial numbers of arriving packets and MUST take appropriate action when anomalies are detected. When lost packet(s) are detected, the mechanism MUST output filler data in order to retain TDM timing. Packets arriving in incorrect order SHOULD be reordered. Lost packet processing SHOULD ensure that proper FAS is sent to the TDM network. An example sequence number processing algorithm is provided in Appendix A.
パケット損失とmisorderingを扱う(珍しい)ために、パケット系列保全メカニズムを提供しなければなりません。 このメカニズムは、到着パケットの通し番号を追跡しなければならなくて、例外が検出されるとき、適切な行動を取らなければなりません。 無くなっているパケットが検出されるとき、メカニズムは、TDMタイミングを保有するためにフィラーデータを出力しなければなりません。 不正確に到着するパケットはSHOULDを注文します。再命令されます。 無くなっているパケット処理SHOULDは、適切なFASがTDMネットワークに送られるのを確実にします。 例の一連番号処理アルゴリズムをAppendix Aに提供します。
While the insertion of arbitrary filler data may be sufficient to maintain the TDM timing, for telephony traffic it may lead to audio gaps or artifacts that result in choppy, annoying or even unintelligible audio. An implementation MAY blindly insert a preconfigured constant value in place of any lost samples, and this value SHOULD be chosen to minimize the perceptual effect. Alternatively one MAY replay the previously received packet. When computational resources are available, implementations SHOULD conceal the packet loss event by properly estimating missing sample values in such fashion as to minimize the perceptual error.
任意のフィラーデータの挿入が電話交通のTDMタイミングを維持するために十分であるかもしれない間、それは変わりやすいか、煩わしいか難解なオーディオさえもたらすオーディオギャップか人工物に通じるかもしれません。 実現は盲目的にどんな無くなっているサンプル、およびこの値のSHOULDに代わってあらかじめ設定された恒常価値を挿入するかもしれません。知覚の効果を最小にするために、選ばれています。 あるいはまた、以前に容認されたパケットを再演するかもしれません。 コンピュータのリソースが利用可能であるときに、実現SHOULDは、そのようなファッションで欠陥試料値を知覚の誤りを最小にするほど適切に見積もっていることによって、パケット損失出来事を隠します。
Stein, et al. Informational [Page 24] RFC 5087 TDMoIP December 2007
シタイン、他 [24ページ]情報のRFC5087TDMoIP2007年12月
7.2. Timing Recovery
7.2. タイミング回復
TDM networks are inherently synchronous; somewhere in the network there will always be at least one extremely accurate primary reference clock, with long-term accuracy of one part in 1E-11. This node provides reference timing to secondary nodes with somewhat lower accuracy, and these in turn distribute timing information further. This hierarchy of time synchronization is essential for the proper functioning of the network as a whole; for details see [G823][G824].
TDMネットワークは本来同時です。 ネットワークにおけるどこかに、少なくとも1個の非常に正確な第一の基準クロックがいつもあるでしょう、1ユーロの-11における、一部の長期の精度で。 このノードはいくらか下側の精度と共に二次ノードに参照タイミングを備えます、そして、これらは順番にさらにタイミング情報を分配します。 全体でネットワークの適切な機能に、時間同期化のこの階層構造は不可欠です。 詳細に関しては、[G823][G824]を見てください。
Packets in PSNs reach their destination with delay that has a random
component, known as packet delay variation (PDV). When emulating TDM
on a PSN, extracting data from the jitter buffer at a constant rate
overcomes much of the high frequency component of this randomness
("jitter"). The rate at which we extract data from the jitter buffer
is determined by the destination clock, and were this to be precisely
matched to the source clock proper timing would be maintained.
Unfortunately, the source clock information is not disseminated
through a PSN, and the destination clock frequency will only
nominally equal the source clock frequency, leading to low frequency
("wander") timing inaccuracies.
PSNsのパケットはパケット遅れ変化(PDV)として知られている無作為のコンポーネントを持っている遅れと共に目的地に到着します。 PSNの上のTDMを見習うとき、ジターバッファからデータを抜粋すると、この偶発性(「ジター」)の高周波成分の多くが一定の割合で打ち勝たれます。 私たちがジターバッファからデータを抜粋するレートは目的地時計によって測定されます、そして、これが正確にソース時計に合わせられることになっているなら、適切なタイミングは維持されるでしょうに。 残念ながら、ソース時計情報はPSNを通して広められません、そして、目的地クロック周波数は名目上はソースクロック周波数と等しいだけでしょう、長波(「歩き回る」)タイミング誤りに通じて。
In broadest terms, there are four methods of overcoming this difficulty. In the first and second methods timing information is provided by some means independent of the PSN. This timing may be provided to the TDM end systems (method 1) or to the IWFs (method 2). In a third method, a common clock is assumed available to both IWFs, and the relationship between the TDM source clock and this clock is encoded in the packet. This encoding may take the form of RTP timestamps or may utilize the synchronous residual timestamp (SRTS) bits in the AAL1 overhead. In the final method (adaptive clock recovery) the timing must be deduced solely based on the packet arrival times. Example scenarios are detailed in [RFC4197] and in [Y1413].
最も広い諸条件には、この困難を克服する4つの方法があります。 1番目と2番目の方法に、PSNの如何にかかわらずどうでもタイミング情報を提供します。 TDMエンドシステム(方法1)、または、IWFs(方法2)にこのタイミングを提供するかもしれません。 3番目の方法で、一般的な時計は両方のIWFsに利用可能であると思われます、そして、TDMソース時計とこの時計との関係はパケットでコード化されます。 このコード化は、RTPタイムスタンプの形を取るか、またはAAL1オーバーヘッドで同期残りのタイムスタンプ(SRTS)ビットを利用するかもしれません。 最終的な方法(適応型の時計回復)で、唯一パケット到着時間に基づいてタイミングを推論しなければなりません。 例のシナリオは[RFC4197]と[Y1413]で詳細です。
Adaptive clock recovery utilizes only observable characteristics of the packets arriving from the PSN, such as the precise time of arrival of the packet at the TDM-bound IWF, or the fill-level of the jitter buffer as a function of time. Due to the packet delay variation in the PSN, filtering processes that combat the statistical nature of the observable characteristics must be employed. Frequency Locked Loops (FLL) and Phase Locked Loops (PLL) are well suited for this task.
適応型の時計回復はPSNから到着するパケットの観察可能な特性だけを利用します、TDM行きのIWFのパケットの到着の正確な時間、または時間の関数としてのジターバッファの中詰めレベルなどのように。 PSNのパケット遅れ変化のため、観察可能な特性の統計的な本質と戦うろ過過程を使わなければなりません。 頻度Locked Loops(FLL)とPhase Locked Loops(PLL)はこのタスクによく合っています。
Stein, et al. Informational [Page 25] RFC 5087 TDMoIP December 2007
シタイン、他 [25ページ]情報のRFC5087TDMoIP2007年12月
Whatever timing recovery mechanism is employed, the output of the TDM-bound IWF MUST conform to the jitter and wander specifications of TDM traffic interfaces, as defined in [G823][G824]. For some applications, more stringent jitter and wander tolerances MAY be imposed.
いかなる採用しているタイミング回収機構、TDM行きのIWF MUSTの出力は、ジターに従って、TDM交通インタフェースの仕様をさまよわせます、[G823][G824]で定義されるように。 寛容を曲がりくねらせてください。そして、いくつかのアプリケーション、より厳しいジター、課されてもよいです。
7.3. Congestion Control
7.3. 輻輳制御
As explained in [RFC3985], the underlying PSN may be subject to congestion. Unless appropriate precautions are taken, undiminished demand of bandwidth by TDMoIP can contribute to network congestion that may impact network control protocols.
[RFC3985]で説明されるように、基本的なPSNは混雑を受けることがあるかもしれません。 適切な注意が払われない場合、TDMoIPによる帯域幅の衰えていない要求はネットワーク制御プロトコルに影響を与えるかもしれないネットワークの混雑に貢献できます。
The AAL1 mode of TDMoIP is an inelastic constant bit-rate (CBR) flow and cannot respond to congestion in a TCP-friendly manner prescribed by [RFC2914], although the percentage of total bandwidth they consume remains constant. The AAL2 mode of TDMoIP is variable bit-rate (VBR), and it is often possible to reduce the bandwidth consumed by employing mechanisms that are beyond the scope of this document.
TDMoIPのAAL1モードは、弾力性のない一定のビット伝送速度(CBR)流動であり、[RFC2914]によって定められたTCPに優しい方法で混雑に応じることができません、彼らが消費する総帯域幅の割合は一定のままで残っていますが。 TDMoIPのAAL2モードは可変ビット伝送速度(VBR)です、そして、このドキュメントの範囲にあるメカニズムを使うことによって消費された帯域幅を減少させるのはしばしば可能です。
Whenever possible, TDMoIP SHOULD be carried across traffic- engineered PSNs that provide either bandwidth reservation and admission control or forwarding prioritization and boundary traffic conditioning mechanisms. IntServ-enabled domains supporting Guaranteed Service (GS) [RFC2212] and Diffserv-enabled domains [RFC2475] supporting Expedited Forwarding (EF) [RFC3246] provide examples of such PSNs. Such mechanisms will negate, to some degree, the effect of TDMoIP on neighboring streams. In order to facilitate boundary traffic conditioning of TDMoIP traffic over IP PSNs, the TDMoIP packets SHOULD NOT use the Diffserv Code Point (DSCP) value reserved for the Default Per-Hop Behavior (PHB) [RFC2474].
可能であるときはいつも、どちらの帯域幅の予約と入場コントロールも提供する交通の設計されたPSNsの向こう側に運ばれるか、または優先順位づけを進めることであるTDMoIP SHOULDとExpedited Forwarding(EF)[RFC3246]を支持しながらメカニズムGuaranteed Service(GS)を支持するIntServによって可能にされたドメイン[RFC2212]とDiffservによって可能にされたドメイン[RFC2475]を条件とさせる境界交通がそのようなPSNsに関する例を提供します。 そのようなメカニズムは隣接している流れへのTDMoIPの効果をある程度否定するでしょう。IP PSNsの上のTDMoIP交通の境界交通調節を容易にするために、TDMoIPパケットSHOULD NOTはDefault Per-ホップBehavior(PHB)[RFC2474]のために予約されたDiffserv Code Point(DSCP)値を使用します。
When TDMoIP is run over a PSN providing best-effort service, packet loss SHOULD be monitored in order to detect congestion. If congestion is detected and bandwidth reduction is possible, then such reduction SHOULD be enacted. If bandwidth reduction is not possible, then the TDMoIP PW SHOULD shut down bi-directionally for some period of time as described in Section 6.5 of [RFC3985].
TDMoIPが走ったら、ベストエフォート型サービス、パケット損失SHOULDを提供するPSNの上では、混雑を検出するためにモニターされてください。 混雑が検出されて、帯域幅削減が可能で、次に、そのような減少SHOULDであるなら、制定されてください。 帯域幅削減が可能でないなら、TDMoIP PW SHOULDはいつかの期間の間、[RFC3985]のセクション6.5で説明されるように両性愛者の方向を止めます。
Note that:
以下のことに注意してください。
1. In AAL1 mode TDMoIP can inherently provide packet loss
measurement since the expected rate of packet arrival is fixed and
known.
1. AAL1モードに、パケット到着の予想された速度が固定されていて、知られているので、TDMoIPは本来パケット損失測定を提供できます。
Stein, et al. Informational [Page 26] RFC 5087 TDMoIP December 2007
シタイン、他 [26ページ]情報のRFC5087TDMoIP2007年12月
2. The results of the packet loss measurement may not be a
reliable indication of presence or absence of severe congestion if
the PSN provides enhanced delivery. For example, if TDMoIP
traffic takes precedence over other traffic, severe congestion may
not significantly affect TDMoIP packet loss.
2. パケット損失測定の結果は存在の信頼できるしるしでないかもしれませんPSNが提供するなら、厳しい混雑の欠如が配送を機能アップしました。 例えば、TDMoIP交通が他の交通の上で優先するなら、厳しい混雑はTDMoIPパケット損失にかなり影響しないかもしれません。
3. The TDM services emulated by TDMoIP have high availability
objectives (see [G826]) that MUST be taken into account when
deciding on temporary shutdown.
3. TDMoIPによって見習われたTDMサービスは一時的な閉鎖を決めるとき考慮に入れなければならない高可用性目的([G826]を見る)を持っています。
This specification does not define exact criteria for detecting severe congestion or specific methods for TDMoIP shutdown or subsequent re-start. However, the following considerations may be used as guidelines for implementing the shutdown mechanism:
この仕様は厳しい混雑を検出する正確な評価基準かTDMoIP閉鎖かその後の再開のための特定の方法を定義しません。 しかしながら、以下の問題は閉鎖メカニズムを実行するのにガイドラインとして使用されるかもしれません:
1. If the TDMoIP PW has been set up using the PWE3 control
protocol [RFC4447], the regular PW teardown procedures of these
protocols SHOULD be used.
1. TDMoIP PWがあったなら、PWE3制御プロトコル[RFC4447]、通常のPW分解手順を用いるのがセットアップされて、これらのプロトコルSHOULDに、使用されてください。
2. If one of the TDMoIP IWFs stops transmission of packets for a
sufficiently long period, its peer (observing 100% packet loss)
will necessarily detect "severe congestion" and also stop
transmission, thus achieving bi-directional PW shutdown.
2. TDMoIP IWFsの1つが十分長い期間、パケットのトランスミッションを止めると、同輩(100%のパケット損失を観測する)は、必ず「厳しい混雑」を検出して、また、トランスミッションを止めるでしょう、その結果、双方向のPW閉鎖を達成します。
TDMoIP does not provide mechanisms to ensure timely delivery or provide other quality-of-service guarantees; hence it is required that the lower-layer services do so. Layer 2 priority can be bestowed upon a TDMoIP stream by using the VLAN priority field, MPLS priority can be provided by using EXP bits, and layer 3 priority is controllable by using TOS. Switches and routers which the TDMoIP stream must traverse should be configured to respect these priorities.
TDMoIPはタイムリーな配送を確実にするか、または他のサービスの質保証を提供するためにメカニズムを提供しません。 したがって、下層サービスがそうするのが必要です。 VLAN優先権分野を使用することによって、層の2優先権をTDMoIPの流れに授与できます、そして、EXPビットを使用することによって、MPLS優先権を提供できます、そして、層の3優先権はTOSを使用することによって、制御可能です。 TDMoIPの流れが横断しなければならないスイッチとルータは、これらのプライオリティを尊敬するために構成されるべきです。
8. Security Considerations
8. セキュリティ問題
TDMoIP does not enhance or detract from the security performance of the underlying PSN, rather it relies upon the PSN's mechanisms for encryption, integrity, and authentication whenever required. The level of security provided may be less than that of a native TDM service.
基本的なPSNのセキュリティ性能は、TDMoIPで高めないか、または損なわれないで、必要であるときに、むしろそれは暗号化、保全、および認証のためにPSNのメカニズムを当てにされます。 セキュリティのレベルはネイティブのTDMのもの以下がサービスであったかもしれないなら提供されました。
When the PSN is MPLS, PW-specific security mechanisms MAY be required, while for IP-based PSNs, IPsec [RFC4301] MAY be used. TDMoIP using L2TPv3 is subject to the security considerations discussed in Section 8 of [RFC3931].
PSNがMPLSであるときに、PW特有のセキュリティー対策が必要であるかもしれませんが、IPベースのPSNsのために、IPsec[RFC4301]は使用されるかもしれません。 L2TPv3を使用するTDMoIPは[RFC3931]のセクション8で議論したセキュリティ問題を受けることがあります。
Stein, et al. Informational [Page 27] RFC 5087 TDMoIP December 2007
シタイン、他 [27ページ]情報のRFC5087TDMoIP2007年12月
TDMoIP shares susceptibility to a number of pseudowire-layer attacks (see [RFC3985]) and implementations SHOULD use whatever mechanisms for confidentiality, integrity, and authentication are developed for general PWs. These methods are beyond the scope of this document.
秘密性、保全、および認証のためのどんなメカニズムも一般的なPWsのために開発されても、TDMoIPは多くのpseudowire-層の攻撃([RFC3985]を見る)と実現SHOULD使用と敏感さを共有します。 これらの方法はこのドキュメントの範囲を超えています。
Random initialization of sequence numbers, in both the control word and the optional RTP header, makes known-plaintext attacks on encrypted TDMoIP more difficult. Encryption of PWs is beyond the scope of this document.
規制単語と任意のRTPヘッダーの両方での一連番号の無作為の初期化で、コード化されたTDMoIPに対する知られている平文攻撃は、より難しくなります。 PWsの暗号化はこのドキュメントの範囲を超えています。
PW labels SHOULD be selected in an unpredictable manner rather than sequentially or otherwise in order to deter session hijacking. When using L2TPv3, a cryptographically random [RFC4086] Cookie SHOULD be used to protect against off-path packet insertion attacks, and a 64- bit Cookie is RECOMMENDED for protection against brute-force, blind, insertion attacks.
PWが選択されたコネが予測できない方法であったならむしろSHOULDとラベルする、連続するかそうでない、セッションハイジャックを思いとどまらせてください。 暗号でL2TPv3、aを使用する、無作為の[RFC4086]クッキーSHOULD、Cookieからオフ経路パケット挿入攻撃、および64ビット守るのにおいて使用されているのは、馬鹿力に対する保護のためのRECOMMENDEDです、盲目です、挿入攻撃ということになってください。
Although TDMoIP MAY employ an RTP header when explicit transfer of timing information is required, SRTP (see [RFC3711]) mechanisms are not applicable.
タイミング情報の明白な転送が必要であるときに、TDMoIPはRTPヘッダーを雇うかもしれませんが、SRTP([RFC3711]を見る)メカニズムは適切ではありません。
9. IANA Considerations
9. IANA問題
For MPLS PSNs, PW Types for TDMoIP PWs are allocated in [RFC4446].
MPLS PSNsに関しては、[RFC4446]にTDMoIP PWsのためのPW Typesを割り当てます。
For UDP/IP PSNs, when the source port is used as PW label, the destination port number MUST be set to 0x085E (2142), the user port number assigned by IANA to TDMoIP.
ソース港がPWラベルとして使用されるとき、UDP/IP PSNsにおいて、0x085E(2142)(IANAによってTDMoIPに割り当てられたユーザポートナンバー)に目的地ポートナンバーを設定しなければなりません。
10. Applicability Statement
10. 適用性証明
It must be recognized that the emulation provided by TDMoIP may be imperfect, and the service may differ from the native TDM circuit in the following ways.
TDMoIPによって提供されたエミュレーションが不完全であるかもしれなく、サービスが以下の方法でネイティブのTDMサーキットと異なるかもしれないと認めなければなりません。
The end-to-end delay of a TDM circuit emulated using TDMoIP may exceed that of a native TDM circuit.
TDMoIPを使用することで見習われたTDMサーキットの終わりから終わりへの遅れはネイティブのTDMサーキットのものを超えるかもしれません。
When using adaptive clock recovery, the timing performance of the emulated TDM circuit depends on characteristics of the PSN, and thus may be inferior to that of a native TDM circuit.
適応型の時計回復を使用するとき、見習われたTDMサーキットのタイミング行動は、PSNの特性に依存して、その結果、ネイティブのTDMサーキットのものに劣っているかもしれません。
If the TDM structure overhead is not transported over the PSN, then non-FAS data in the overhead will be lost.
TDM構造オーバーヘッドがPSNの上で輸送されないと、オーバーヘッドにおける非FASデータは失われるでしょう。
Stein, et al. Informational [Page 28] RFC 5087 TDMoIP December 2007
シタイン、他 [28ページ]情報のRFC5087TDMoIP2007年12月
When packets are lost in the PSN, TDMoIP mechanisms ensure that frame synchronization will be maintained. When packet loss events are properly concealed, the effect on telephony channels will be perceptually minimized. However, the bit error rate will be degraded as compared to the native service.
パケットがPSNで失われているとき、TDMoIPメカニズムは、フレーム同期化が維持されるのを確実にします。 適切にパケット損失出来事を隠すとき、知覚のに電話チャンネルへの効果を最小にするでしょう。 しかしながら、ネイティブのサービスと比べて、ビット誤り率は下げられるでしょう。
Data in inactive channels is not transported in AAL2 mode, and thus this data will differ from that of the native service.
不活発なチャンネルによるデータはAAL2モードで輸送されません、そして、その結果、このデータはネイティブのサービスのものと異なるでしょう。
Native TDM connections are point-to-point, while PSNs are shared infrastructures. Hence, the level of security of the emulated service may be less than that of the native service.
ネイティブのTDM接続は二地点間ですが、PSNsは共有されたインフラストラクチャです。 したがって、見習われたサービスのセキュリティのレベルはネイティブのサービスのものより少ないかもしれません。
11. Acknowledgments
11. 承認
The authors would like to thank Hugo Silberman, Shimon HaLevy, Tuvia Segal, and Eitan Schwartz of RAD Data Communications for their invaluable contributions to the technology described herein.
作者はユーゴー・シルバーマンに感謝したがっています、と技術への彼らの非常に貴重な貢献のためのRAD Data CommunicationsのシモンHaLevy、Tuviaシーガル、およびEitanシュワルツはここに説明しました。
Stein, et al. Informational [Page 29] RFC 5087 TDMoIP December 2007
シタイン、他 [29ページ]情報のRFC5087TDMoIP2007年12月
Appendix A. Sequence Number Processing (Informative)
付録A.一連番号処理(有益)です。
The sequence number field in the control word enables detection of lost and misordered packets. Here we give pseudocode for an example algorithm in order to clarify the issues involved. These issues are implementation specific and no single explanation can capture all the possibilities.
規制単語による一連番号分野は無くなっていてmisorderedされたパケットの検出を可能にします。 ここに、かかわった問題をはっきりさせて、私たちは例のアルゴリズムのために擬似コードを与えます。 これらの問題は実現特有です、そして、どんなただ一つの説明もすべての可能性を得ることができるというわけではありません。
In order to simplify the description, modulo arithmetic is consistently used in lieu of ad-hoc treatment of the cyclicity. All differences between indexes are explicitly converted to the range [-2^15 ... +2^15 - 1] to ensure that simple checking of the difference's sign correctly predicts the packet arrival order.
記述を簡素化するために、モジュロ演算はサイクル性の臨時の処理の代わりに一貫して使用されます。 All differences between indexes are explicitly converted to the range [-2^15 ... +2^15 - 1] to ensure that simple checking of the difference's sign correctly predicts the packet arrival order.
Furthermore, we introduce the notion of a playout buffer in order to unambiguously define packet lateness. When a packet arrives after previously having been assumed lost, the TDM-bound IWF may discard it, and continue to treat it as lost. Alternatively, if the filler data that had been inserted in its place has not yet been played out, the option remains to insert the true data into the playout buffer. Of course, the filler data may be generated upon initial detection of a missing packet or upon playout. This description is stated in terms of a packet-oriented playout buffer rather than a TDM byte oriented one; however, this is not a true requirement for re-ordering implementations since the latter could be used along with pointers to packet commencement points.
その上、私たちは、明白にパケット遅れを定義するために再生バッファの概念を紹介します。 無くなると思われて、パケットが以前に後に到着するとき、TDM行きのIWFは、失われているようにそれを捨てて、それを扱い続けるかもしれません。 あるいはまた、場所に挿入されたフィラーデータがまだ展開されていないなら、オプションは、再生バッファの中に本当のデータを挿入するために残っています。 もちろん、フィラーデータはなくなったパケットの初期の検出か再生で発生するかもしれません。 この記述はTDMバイト指向のものよりむしろパケット指向の再生バッファで述べられています。 しかしながら、ポインタと共に後者をパケット始めポイントまで使用できたので、これは再注文実現のための本当の要件ではありません。
Having introduced the playout buffer we explicitly treat over-run and under-run of this buffer. Over-run occurs when packets arrive so quickly that they can not be stored for playout. This is usually an indication of gross timing inaccuracy or misconfiguration, and we can do little but discard such early packets. Under-run is usually a sign of network starvation, resulting from congestion or network failure.
再生バッファを紹介したので、私たちは明らかにこのバッファで超過で経営で扱います。 パケットが非常にすばやく到着するので再生のためにそれらを格納できないとき、超過は起こります。 通常、これが総計のタイミングの不正確かmisconfigurationのしるしであり、私たちは、少ししかしませんが、そのような早いパケットを捨てることができます。 通常、経営であることは、ネットワーク飢餓、混雑から生じるか、またはネットワーク失敗のサインです。
The external variables used by the pseudocode are:
擬似コードによって使用される外部の変数は以下の通りです。
received: sequence number of packet received
played: sequence number of the packet being played out (Note 1)
over-run: is the playout buffer full? (Note 3)
under-run: has the playout buffer been exhausted? (Note 3)
受け取られている: 受け取られたパケットの一連番号はプレーしました: オーバランして、使い果たされる(注意1)パケットの一連番号: 再生バッファは完全ですか? (注意3) 経営: 再生バッファは消耗しましたか? (注意3)
The internal variables used by the pseudocode are:
擬似コードによって使用される内部の変数は以下の通りです。
expected: sequence number we expect to receive next
D: difference between expected and received (Note 2)
L: difference between sequence numbers of packet being played out
and that just received (Notes 1 and 2)
予想される: 私たちが次のDを受けると予想する一連番号: 予想されて容認された(注意2)Lの違い: 使い果たされるただ受信されたパケットの一連番号の違い(注意1と2)
Stein, et al. Informational [Page 30] RFC 5087 TDMoIP December 2007
シタイン、他 [30ページ]情報のRFC5087TDMoIP2007年12月
In addition, the algorithm requires one parameter:
さらに、アルゴリズムは1つのパラメタを必要とします:
R: maximum lateness for a packet to be recoverable (Note 1).
R: パケットが回復可能である最大の遅れ(注意1)。
Note 1: this is only required for the optional re-ordering
Note 2: this number is always in the range -2^15 ... +2^15 - 1
Note 3: the playout buffer is emptied by the TDM playout process,
which runs asynchronously to the packet arrival processing,
and which is not herein specified
注意1: これが任意の再注文Note2に必要であるだけです: この数はいつも範囲-2^15にあります… +2^15 - 1 Note 3: 再生バッファはTDM再生工程で空にされています。(それは、パケット到着処理に非同期に駆けつけて、ここに指定されません)。
Sequence Number Processing Algorithm
一連番号処理アルゴリズム
Upon receipt of a packet
if received = expected
{ treat packet as in-order }
if not over-run then
place packet contents into playout buffer
else
discard packet contents
set expected = (received + 1) mod 2^16
else
calculate D = ( (expected-received) mod 2^16 ) - 2^15
if D > 0 then
{ packets expected, expected+1, ... received-1 are lost }
while not over-run
place filler (all-ones or interpolation) into playout buffer
if not over-run then
place packet contents into playout buffer
else
discard packet contents
set expected = (received + 1) mod 2^16
else { late packet arrived }
declare "received" to be a late packet
do NOT update "expected"
either
discard packet
or
if not under-run then
calculate L = ( (played-received) mod 2^16 ) - 2^15
if 0 < L <= R then
replace data from packet previously marked as lost
else
discard packet
Note: by choosing R=0 we always discard the late packet
… 予想されたパケット、期待している+1、= 予想されて、受け取って、オーバランしないで、再生バッファの中へのほかの当時の場所パケット含有量がパケットコンテンツセットを捨てるなら整然としている御馳走の同じくらいパケットが、= (+ 1を受け取ります)モッズ風の2^16が、DがD>0であるならモッズ2^16)--2^15と等しいと(予想されて受け取られていている)見込むと予想したなら受け取られていている1がパケットを受け取り次第無くなる、オーバランしていない間、フィラー(オールものか挿入)を再生バッファの中に置いてください; パケットコンテンツセットがほかにモッズ2^16と等しいと(+ 1を受け取ります)予想した再生のバッファのほかの破棄に遅いパケットは到達しました。当時の場所パケットコンテンツをオーバランさせない、遅いパケットが「予想されて」破棄をアップデートしないということになるように「受け」て、次に、まして、パケットか経営の下では、L=((プレーされて受け取られている)のモッズ風の2^16)について計算してください--次に、0<L<=Rが以前にほかに失われているようにマークされたパケットからデータを置き換えるなら2^15がパケットNoteを捨てると宣言してください: R=0を選ぶことによって、私たちは遅いパケットをいつも捨てます。
Stein, et al. Informational [Page 31] RFC 5087 TDMoIP December 2007
シタイン、他 [31ページ]情報のRFC5087TDMoIP2007年12月
Appendix B. AAL1 Review (Informative)
付録B.AAL1レビュー(有益)です。
The first byte of the 48-byte AAL1 PDU always contains an error- protected 3-bit sequence number.
AAL1 PDUがいつも誤りの保護された3ビットの一連番号に含む48バイトの最初のバイト。
1 2 3 4 5 6 7 8
+-+-+-+-+-+-+-+-+-----------------------
|C| SN | CRC |P| 47 bytes of payload
+-+-+-+-+-+-+-+-+-----------------------
1 2 3 4 5 6 7 8 +-+-+-+-+-+-+-+-+----------------------- |C| SN| CRC|P| 47バイトのペイロード+++++++++-----------------------
C (1 bit) convergence sublayer indication, its use here is limited
to indication of the existence of a pointer (see below); C=0 means
no pointer, C=1 means a pointer is present.
C(1ビット)集合副層指示、ここでの使用はポインタの存在のしるしに制限されます(以下を見てください)。 C=0は、ポインタがない、C=1が、ポインタが存在していることを意味することを意味します。
SN (3 bits) The AAL1 sequence number increments from PDU to PDU.
PDUによって一連番号が増加するSN(3ビット)AAL1。
CRC (3 bits) is a 3-bit error cyclic redundancy code on C and SN.
CRC(3ビット)はCとSNの3ビットの誤り周期的な冗長コードです。
P (1 bit) even byte parity.
P(1ビット)同等のバイトの同等。
As can be readily inferred, incrementing the sequence number forms an eight-PDU sequence number cycle, the importance of which will become clear shortly.
容易に推論できるように、一連番号を増加すると、8PDUの一連番号サイクルは形成されます。その重要性はまもなく、明確になるでしょう。
The structure of the remaining 47 bytes in the AAL1 PDU depends on the PDU type, of which there are three, corresponding to the three types of AAL1 circuit emulation service defined in [CES]. These are known as unstructured circuit emulation, structured circuit emulation, and structured circuit emulation with CAS.
AAL1 PDUの残っている47バイトの構造をPDUタイプに頼っています、[CES]で定義された3つのタイプのAAL1サーキットエミュレーションサービスに対応しています。(そこには、3があります)。 これらは不統一なサーキットエミュレーションとして知られていて、構造化されたサーキットエミュレーションの、そして、構造化されたサーキットはCASがあるエミュレーションです。
The simplest PDU is the unstructured one, which is used for transparent transfer of whole circuits (T1,E1,T3,E3). Although AAL1 provides no inherent advantage as compared to SAToP for unstructured transport, in certain cases AAL1 may be required or desirable. For example, when it is necessary to interwork with an existing AAL1- based network, or when clock recovery based on AAL1-specific mechanisms is favored.
最も簡単なPDUは不統一なものです。(そのものは全体のサーキット(T1、T3、3EのE1)のわかりやすい転送に使用されます)。 不統一な輸送のためにSAToPと比べて、AAL1はどんな固有の利点も提供しませんが、ある場合には、AAL1は必要であるか、または望ましいかもしれません。 それが既存のAAL1ベースのネットワークと共に織り込むのに例えば必要であるか、またはAAL1特有のメカニズムに基づく時計回復が好評であるときに。
For unstructured AAL1, the 47 bytes after the sequence number byte contain the full 376 bits from the TDM bit stream. No frame synchronization is supplied or implied, and framing is the sole responsibility of the end-user equipment. Hence, the unstructured mode can be used to carry data, and for circuits with nonstandard frame synchronization. For the T1 case the raw frame consists of 193 bits, and hence 1 183/193 T1 frames fit into each AAL1 PDU. The E1 frame consists of 256 bits, and so 1 15/32 E1 frames fit into each PDU.
不統一なAAL1に関しては、次々と一連番号47バイトはTDMビットストリームから完全な376ビットを含んでいます。 フレーム同期化を全く供給もしませんし、含意もしません、そして、縁どりはエンドユーザ設備の唯一の責任です。 したがって、データを運ぶのに使用される、および標準的でないフレーム同期化があるサーキットには不統一なモードがあることができます。 T1ケースのために、生のフレームは193ビットから成ります、そして、したがって、1 183/193個のT1フレームが各AAL1 PDUに収まります。 1Eのフレームが256ビットから成るので、1 15/32個の1Eのフレームが各PDUに収まります。
Stein, et al. Informational [Page 32] RFC 5087 TDMoIP December 2007
シタイン、他 [32ページ]情報のRFC5087TDMoIP2007年12月
When the TDM circuit is channelized according to [G704], and in particular when it is desired to fractional E1 or T1, it is advantageous to use one of the structured AAL1 circuit emulation services. Structured AAL1 views the data not merely as a bit stream, but as a bundle of channels. Furthermore, when CAS signaling is used it can be formatted so that it can be readily detected and manipulated.
TDMサーキットが[G704]に従ってchannelizedされて、それが1断片的なEかT1に望まれているとき特にchannelizedされるとき、構造化されたAAL1サーキットエミュレーションサービスの1つを使用するのは有利です。 しかし、チャンネルのバンドルとして少し流れるとき、構造化されたAAL1は単にないデータを見ます。 CASシグナリングが使用されているとき、その上、それを容易に検出して、操ることができるようにそれをフォーマットできます。
In the structured circuit emulation mode without CAS, N bytes from the N channels to be transported are first arranged in order of channel number. Thus if channels 2, 3, 5, 7 and 11 are to be transported, the corresponding five bytes are placed in the PDU immediately after the sequence number byte. This placement is repeated until all 47 bytes in the PDU are filled.
CASのない構造化されたサーキットエミュレーション・モードでは、論理機番の順にN輸送されるべきチャンネルからNバイトは最初に、アレンジされます。 したがって、チャンネル2、3、5、7、および11が輸送されるつもりであるなら、対応する5バイトは一連番号バイト直後PDUに置かれます。 PDUのすべての47バイトがいっぱいにされるまで、このプレースメントは繰り返されます。
byte 1 2 3 4 5 6 7 8 9 10 --- 41 42 43 44 45 46 47
channel 2 3 5 7 11 2 3 5 7 11 --- 2 3 5 7 11 2 3
バイト1 2 3 4 5 6 7 8 9 10--- 41 42 43 44 45 46 47チャンネル2 3 5 7 11、2 3 5 7、11--- 2 3 5 7 11 2 3
The next PDU commences where the present PDU left off.
次のPDUは現在のPDUがやめたところから始まります。
byte 1 2 3 4 5 6 7 8 9 10 --- 41 42 43 44 45 46 47
channel 5 7 11 2 3 5 7 11 2 3 --- 5 7 11 2 3 5 7
バイト1 2 3 4 5 6 7 8 9 10--- 41 42 43 44 45 46 47チャンネル5 7 11、2 3 5 7、11、2 3--- 5 7 11 2 3 5 7
And so forth. The set of channels 2,3,5,7,11 is the basic structure and the point where one structure ends and the next commences is the structure boundary.
など。 チャンネル2、3、5、7、11のセットは基本構造です、そして、1つの構造が終わって、次が始まるポイントは構造限界です。
The problem with this arrangement is the lack of explicit indication of the byte identities. As can be seen in the above example, each AAL1 PDU starts with a different channel, so a single lost packet will result in misidentifying channels from that point onwards, without possibility of recovery. The solution to this deficiency is the periodic introduction of a pointer to the next structure boundary. This pointer need not be used too frequently, as the channel identifications are uniquely inferable unless packets are lost.
このアレンジメントに関する問題はバイトのアイデンティティの明白なしるしの不足です。 各AAL1 PDUが上記の例で見ることができるように異なったチャンネルから始めるので、単一の無くなっているパケットはそのポイントからチャンネルを前方へ誤認するのに結果として生じるでしょう、回復の可能性なしで。 この欠乏の解決策は次の構造限界へのポインタの周期的な導入です。 パケットが無くならない場合チャネル識別が唯一推論可能であるので、このポインタはあまりに頻繁に使用される必要はありません。
The particular method used in AAL1 is to insert a pointer once every sequence number cycle of eight PDUs. The pointer is seven bits and protected by an even parity MSB (most significant bit), and so occupies a single byte. Since seven bits are sufficient to represent offsets larger than 47, we can limit the placement of the pointer byte to PDUs with even sequence numbers. Unlike most AAL1 PDUs that contain 47 TDM bytes, PDUs that contain a pointer (P-format PDUs) have the following format.
AAL1で使用される特定の方法は8PDUsの一連番号サイクル毎に一度ポインタを挿入することです。 ポインタは、7ビットであり、偶数パリティMSB(最上位ビット)で保護するので、1バイトを占領します。 7ビットが47より大きいオフセットを表すために十分であるので、私たちはポインタバイトのプレースメントを一連番号があってもPDUsに制限できます。 47TDMバイトを含むほとんどのAAL1 PDUsと異なって、ポインタ(P-形式PDUs)を含むPDUsが以下の形式を持っています。
Stein, et al. Informational [Page 33] RFC 5087 TDMoIP December 2007
シタイン、他 [33ページ]情報のRFC5087TDMoIP2007年12月
0 1
1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-----------------------
|C| SN | CRC |P|E| pointer | 46 bytes of payload
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-----------------------
0 1 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+----------------------- |C| SN| CRC|P|E| ポインタ| 46バイトのペイロード+++++++++++++++++-----------------------
where
どこ
C (1 bit) convergence sublayer indication, C=1 for P-format PDUs.
C(1ビット)集合副層指示、P-形式PDUsのためのC=1。
SN (3 bits) is an even AAL1 sequence number.
SN(3ビット)は同等のAAL1一連番号です。
CRC (3 bits) is a 3-bit error cyclic redundancy code on C and SN.
CRC(3ビット)はCとSNの3ビットの誤り周期的な冗長コードです。
P (1 bit) even byte parity LSB (least significant bit) for sequence
number byte.
一連番号バイトP(1ビット)バイトパリティLSB(最下位ビット)さえ。
E (1 bit) even byte parity MSB for pointer byte.
ポインタバイトE(1ビット)バイトパリティMSBさえ。
pointer (7 bits) pointer to next structure boundary.
次の構造限界へのポインタ(7ビット)ポインタ。
Since P-format PDUs have 46 bytes of payload and the next PDU has 47 bytes, viewed as a single entity the pointer needs to indicate one of 93 bytes. If P=0 it is understood that the structure commences with the following byte (i.e., the first byte in the payload belongs to the lowest numbered channel). P=93 means that the last byte of the second PDU is the final byte of the structure, and the following PDU commences with a new structure. The special value P=127 indicates that there is no structure boundary to be indicated (needed when extremely large structures are being transported).
以来、P-形式PDUsには、46バイトのペイロードがあります、そして、次のPDUには、ポインタが93バイトの1つを示すために必要とする単一体として見なされた47バイトがあります。 P=0であるなら、構造が以下のバイトと共に始まるのが(すなわち、ペイロードにおける最初のバイトは最も低い番号付のチャンネルのものです)理解されています。 P=93は、第2PDUの最後のバイトが構造の最終的なバイトであり、以下のPDUが新しい構造と共に始まることを意味します。 特別な値のP=127は、示される(非常に大きい構造を輸送するのが必要である)ために構造限界が全くないのを示します。
The P-format PDU is always placed at the first possible position in the sequence number cycle that a structure boundary occurs, and can only occur once per cycle.
P-形式PDUはいつも第1代構造限界が起こって、1サイクルに一度起こることができるだけであるという一連番号サイクルにおける可能な位置に置かれます。
The only difference between the structured circuit emulation format and structured circuit emulation with CAS is the definition of the structure. Whereas in structured circuit emulation the structure is composed of the N channels, in structured circuit emulation with CAS the structure encompasses the superframe consisting of multiple repetitions of the N channels and then the CAS signaling bits. The CAS bits are tightly packed into bytes and the final byte is padded with zeros if required.
CASがある構造化されたサーキットエミュレーション形式と構造化されたサーキットエミュレーションの唯一の違いは構造の定義です。 構造はNチャンネルで構造化されたサーキットエミュレーションで構成されますが、CASがある構造化されたサーキットエミュレーションで、構造はNチャンネルと次に、CASシグナリングビットの複数の反復から成る「スーパー-フレーム」を取り囲みます。 CASビットはしっかりバイトに詰め込まれます、そして、必要なら、最終的なバイトはゼロで水増しされます。
For example, for E1 circuits the CAS signaling bits are updated once per superframe of 16 frames. Hence, the structure for N*64 derived from an E1 with CAS signaling consists of 16 repetitions of N bytes,
例えば、1Eのサーキットにおいて、CASシグナリングビットを16個のフレームの「スーパー-フレーム」に一度アップデートします。 したがって、CASが合図している状態でE1から引き出されたN*64のための構造はNバイトの16の反復から成ります。
Stein, et al. Informational [Page 34] RFC 5087 TDMoIP December 2007
シタイン、他 [34ページ]情報のRFC5087TDMoIP2007年12月
followed by N sets of the four ABCD bits, and finally four zero bits if N is odd. For example, the structure for channels 2,3 and 5 will be as follows:
4ABCDビットについてNセットによって続かれていて、Nが変であるなら、最終的に4ゼロ・ビット続かれました。 例えば、チャンネル2、3、および5のための構造は以下の通りになるでしょう:
2 3 5 2 3 5 2 3 5 2 3 5 2 3 5 2 3 5 2 3 5 2 3 5 2 3 5 2 3 5 2 3 5
2 3 5 2 3 5 2 3 5 2 3 5 2 3 5 [ABCD2 ABCD3] [ABCD5 0000]
2 3 5 2 3 5 2 3 5 2 3 5 2 3 5 2 3 5 2 3 5 2 3 5 2 3 5 2 3 5 2 3 5 2 3 5 2 3 5 2 3 5 2 3 5 2 3 5[ABCD2 ABCD3][ABCD5 0000]
Similarly for T1 ESF circuits the superframe is 24 frames, and the structure consists of 24 repetitions of N bytes, followed by the ABCD bits as before. For the T1 case the signaling bits will in general appear twice, in their regular (bit-robbed) positions and at the end of the structure.
同様に、T1 ESFサーキットに、「スーパー-フレーム」は24個のフレームです、そして、構造はABCDビットが従来と同様支えたNバイトの24の反復から成ります。 一般に、T1ケースに関しては、シグナリングビットはそれらの通常(ビットを略奪された)の位置と構造の端に二度現れるでしょう。
Stein, et al. Informational [Page 35] RFC 5087 TDMoIP December 2007
シタイン、他 [35ページ]情報のRFC5087TDMoIP2007年12月
Appendix C. AAL2 Review (Informative)
付録C.AAL2レビュー(有益)です。
The basic AAL2 PDU is:
基本的なAAL2 PDUは以下の通りです。
| Byte 1 | Byte 2 | Byte 3 |
0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+------------
| CID | LI | UUI | HEC | PAYLOAD
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+------------
| バイト1| バイト2| バイト3| 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+------------ | Cid| 李| UUI| HEC| ペイロード+++++++++++++++++++++++++------------
CID (8 bits) channel identifier is an identifier that must be unique
for the PW. The values 0-7 are reserved for special purposes,
(and if interworking with VoDSL is required, so are values 8
through 15 as specified in [LES]), thus leaving 248 (240) CIDs per
PW. The mapping of CID values to channels MAY be manually
configured manually or signaled.
CID(8ビット)チャンネル識別子はPWに、ユニークであるに違いない識別子です。 そして、値0-7が特別な目的のために予約される、(したがって、VoDSLとの織り込むのが必要であるなら、[LES)で指定されて、その結果、PW単位で248(240)CIDsを残すとしての値8〜15が必要です。 チャンネルへのCID値に関するマッピングは、手動で手動で構成されるか、または合図されるかもしれません。
LI (6 bits) length indicator is one less than the length of the
payload in bytes. Note that the payload is limited to 64 bytes.
LI(6ビット)長さのインディケータはバイトで表現されるペイロードの長さよりそれほど1です。 ペイロードが64バイトに制限されることに注意してください。
UUI (5 bits) user-to-user indication is the higher layer
(application) identifier and counter. For voice data, the UUI
will always be in the range 0-15, and SHOULD be incremented modulo
16 each time a channel buffer is sent. The receiver MAY monitor
this sequence. UUI is set to 24 for CAS signaling packets.
UUI(5ビット)ユーザからユーザへの指示は、より高い層(アプリケーション)の識別子とカウンタです。 声のデータに関しては、UUIは増加している法が16であったならチャンネルバッファを送るたびに範囲の0-15、およびSHOULDにあるためにいつも望んでいます。 受信機はこの系列をモニターするかもしれません。 UUIはCASシグナリングパケットのための24へのセットです。
HEC (5 bits) the header error control
ヘッダーのHEC(5ビット)誤り制御
Payload - voice
A block of length indicated by LI of voice samples are placed as-
is into the AAL2 packet.
有効搭載量--長さのAブロックを声に出すのが、声のLIでサンプルが置かれるのを示した、-、AAL2パケットには、あります。
Payload - CAS signaling
For CAS signaling the payload is formatted as an AAL2 "fully
protected" (type 3) packet (see [AAL2]) in order to ensure error
protection. The signaling is sent with the same CID as the
corresponding voice channel. Signaling MUST be sent whenever the
state of the ABCD bits changes, and SHOULD be sent with triple
redundancy, i.e., sent three times spaced 5 milliseconds apart.
In addition, the entire set of the signaling bits SHOULD be sent
periodically to ensure reliability.
有効搭載量--ペイロードに合図するCASシグナリングFor CASは、誤り保護を確実にする「完全に保護された」AAL2としてフォーマットされた(3をタイプする)パケット([AAL2]を見る)です。 対応する音声チャンネルと同じCIDと共にシグナリングを送ります。 ABCDビットの状態が変化するときはいつも、シグナリングを送らなければなりませんでした、そして、三重の冗長と共にSHOULDを送って、すなわち、送って、3回は何ミリセカンドも離れて5を区切りました。 さらに、全体がシグナリングビットSHOULDをセットしました。信頼性を定期的に確実にさせてください。
Stein, et al. Informational [Page 36] RFC 5087 TDMoIP December 2007
シタイン、他 [36ページ]情報のRFC5087TDMoIP2007年12月
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|RED| timestamp |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RES | ABCD | type | CRC
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
CRC (cont) |
+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |赤| タイムスタンプ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | RES| ABCD| タイプ| CRC+++++++++++++++++CRC(cont)| +-+-+-+-+-+-+-+-+
RED (2 bits) is the triple redundancy counter. For the first packet
it takes the value 00, for the second 01 and for the third 10.
RED=11 means non-redundant information, and is used when triple
redundancy is not employed, and for periodic refresh messages.
RED(2ビット)は三重の冗長カウンタです。 最初のパケットのために、それは2番目の01と3番目の10に値00を要します。 そして、RED=11が非余分な情報を意味して、三重の冗長が採用していないとき使用されている、周期的である、メッセージをリフレッシュしてください。
Timestamp (14 bits) The timestamp is optional and in particular is
not needed if RTP is employed. If not used, the timestamp MUST be
set to zero. When used with triple redundancy, it MUST be the
same for all three redundant transmissions.
タイムスタンプ、(14ビット) タイムスタンプは、任意であり、RTPが採用しているなら、特に必要ではありません。 使用されないなら、ゼロにタイムスタンプを設定しなければなりません。 三重の冗長と共に使用されると、すべての3個の余分なトランスミッションに、それは同じであるに違いありません。
RES (4 bits) is reserved and MUST be set to zero.
RES(4ビット)は予約されていて、ゼロに用意ができなければなりません。
ABCD (4 bits) are the CAS signaling bits.
ABCD(4ビット)はCASシグナリングビットです。
type (6 bits) for CAS signaling this is 000011.
これに合図するCASのためのタイプ(6ビット)は000011です。
CRC-10 (10 bits) is a 10-bit CRC error detection code.
CRC-10(10ビット)は10ビットのCRCエラー検出コードです。
Stein, et al. Informational [Page 37] RFC 5087 TDMoIP December 2007
シタイン、他 [37ページ]情報のRFC5087TDMoIP2007年12月
Appendix D. Performance Monitoring Mechanisms (Informative)
付録D.パフォーマンス監視メカニズム(有益)です。
PWs require OAM mechanisms to monitor performance measures that impact the emulated service. Performance measures, such as packet loss ratio and packet delay variation, may be used to set various parameters and thresholds; for TDMoIP PWs adaptive timing recovery and packet loss concealment algorithms may benefit from such information. In addition, OAM mechanisms may be used to collect statistics relating to the underlying PSN [RFC2330], and its suitability for carrying TDM services.
PWsは、見習われたサービスに影響を与える性能測定をモニターするためにOAMメカニズムを必要とします。 パケット損害率やパケット遅れ変化などのパフォーマンス基準は様々なパラメタと敷居を設定するのに使用されるかもしれません。 TDMoIP PWsに関しては、適応型のタイミング回復とパケット損失隠すことのアルゴリズムはそのような情報の利益を得るかもしれません。 さらに、OAMメカニズムは、基本的なPSN[RFC2330]、およびTDMサービスを提供することへのその適合に関連する統計を集めるのに使用されるかもしれません。
TDMoIP IWFs may benefit from knowledge of PSN performance metrics, such as round trip time (RTT), packet delay variation (PDV) and packet loss ratio (PLR). These measurements are conventionally performed by a separate flow of packets designed for this purpose, e.g., ICMP packets [RFC792] or MPLS LSP ping packets [RFC4379] with multiple timestamps. For AAL1 mode, TDMoIP sends packets across the PSN at a constant rate, and hence no additional OAM flow is required for measurement of PDV or PLR. However, separate OAM flows are required for RTT measurement, for AAL2 mode PWs, for measurement of parameters at setup, for monitoring of inactive backup PWs, and for low-rate monitoring of PSNs after PWs have been withdrawn due to service failures.
TDMoIP IWFsはPSN性能測定基準に関する知識の利益を得るかもしれません、周遊旅行時間(RTT)や、パケット遅れ変化(PDV)やパケット損害率(PLR)などのように。 これらの測定はこのために設計されたパケットの別々の流れによって慣習上実行されます、例えば、ICMPパケット[RFC792]かMPLS LSPが複数のタイムスタンプでパケット[RFC4379]を確認します。 AAL1モードのために、TDMoIPはPSNの向こう側に一定の割合でパケットを送ります、そして、したがって、どんな追加OAM流動もPDVかPLRの測定に必要ではありません。 しかしながら、別々のOAM流れがRTT測定、AAL2モードPWs、セットアップにおけるパラメタの測定、不活発なバックアップPWsのモニター、およびPWsがサービス失敗のため引っ込められた後にPSNsの低率モニターに必要です。
If the underlying PSN has appropriate maintenance mechanisms that provide connectivity verification, RTT, PDV, and PLR measurements that correlate well with those of the PW, then these mechanisms SHOULD be used. If such mechanisms are not available, either of two similar OAM signaling mechanisms may be used. The first is internal to the PW and based on inband VCCV [RFC5085], and the second is defined only for UDP/IP PSNs, and is based on a separate PW. The latter is particularly efficient for a large number of fate-sharing TDM PWs.
基本的なPSNにPW、当時のこれらのメカニズムのものでSHOULDをよく関連させる測定値を接続性検証、RTT、PDV、およびPLRに供給する適切な維持メカニズムがあるなら、使用されてください。 そのようなメカニズムが利用可能でないなら、2台の同様のOAMシグナル伝達機構のどちらかが使用されるかもしれません。 第1がPWとinband VCCV[RFC5085]に基づいて内部であり、2番目は、UDP/IP PSNsのためだけに定義されて、別々のPWに基づいています。 多くの運命を共有するTDM PWsには、後者は特に効率的です。
D.1. TDMoIP Connectivity Verification
D.1。 TDMoIP接続性検証
In most conventional IP applications a server sends some finite amount of information over the network after explicit request from a client. With TDMoIP PWs the PSN-bound IWF could send a continuous stream of packets towards the destination without knowing whether the TDM-bound IWF is ready to accept them. For layer-2 networks, this may lead to flooding of the PSN with stray packets.
ほとんどの従来のIPアプリケーションでは、サーバはいくらかの有限情報量をクライアントから明白な要求の後のネットワークの上に送ります。 TDM行きのIWFがそれらを受け入れる準備ができているかどうかを知らない、TDMoIP PWsと共に、PSN行きのIWFはパケットの連続した流れを目的地に向かって送ることができました。 層-2つのネットワークのために、これは迷っているパケットがあるPSNの氾濫に導くかもしれません。
This problem may occur when a TDMoIP IWF is first brought up, when the TDM-bound IWF fails or is disconnected from the PSN, or the PW is broken. After an aging time the destination IWF becomes unknown, and intermediate switches may flood the network with the TDMoIP packets in an attempt to find a new path.
TDMoIP IWFが最初に持って来られるとき、この問題は起こるかもしれません、TDM行きのIWFが失敗するか、PSNから外される、またはPWが壊れているとき。 古い時間の後に、目的地IWFは未知になります、そして、中間的スイッチはTDMoIPパケットで新しい経路を見つける試みでネットワークをあふれさせるかもしれません。
Stein, et al. Informational [Page 38] RFC 5087 TDMoIP December 2007
シタイン、他 [38ページ]情報のRFC5087TDMoIP2007年12月
The solution to this problem is to significantly reduce the number of TDMoIP packets transmitted per second when PW failure is detected, and to return to full rate only when the PW is available. The detection of failure and restoration is made possible by the periodic exchange of one-way connectivity-verification messages.
この問題の解決は検出される、およびPWが利用可能でありだけ全額料金へのリターンにはPWの故障があるとき、1秒単位で伝えられたTDMoIPパケットの数をかなり減少させることです。 片道接続性検証メッセージの周期的な交換で失敗と回復の検出を可能にします。
Connectivity is tested by periodically sending OAM messages from the source IWF to the destination IWF, and having the destination reply to each message. The connectivity verification mechanism SHOULD be used during setup and configuration. Without OAM signaling, one must ensure that the destination IWF is ready to receive packets before starting to send them. Since TDMoIP IWFs operate full-duplex, both would need to be set up and properly configured simultaneously if flooding is to be avoided. When using connectivity verification, a configured IWF may wait until it detects its peer before transmitting at full rate. In addition, configuration errors may be readily discovered by using the service specific field of the OAM PW packets.
ソースIWFから目的地IWFまでメッセージをOAMに送って、目的地に各メッセージに答えさせながら、接続性は定期的によってテストされます。 接続性検証メカニズムSHOULD、セットアップと構成の間、使用されてください。 OAMシグナリングがなければ、それらを送り始める前に目的地IWFがパケットを受ける準備ができているのを確実にしなければなりません。 TDMoIP IWFsが全二重を操作するので、氾濫が避けられるつもりであるなら、両方が、セットアップされて、同時に適切に構成される必要があるでしょう。 接続性検証を使用するとき、全額料金で伝わる前に同輩を検出するまで、構成されたIWFは待つかもしれません。 さらに、構成誤りはOAM PWパケットの容易に発見されたサービスを利用することによって特定の状態で分野であるかもしれません。
In addition to one-way connectivity, OAM signaling mechanisms can be used to request and report on various PSN metrics, such as one-way delay, round trip delay, packet delay variation, etc. They may also be used for remote diagnostics, and for unsolicited reporting of potential problems (e.g., dying gasp messages).
片道接続性に加えて、様々なPSN測定基準に関して要求して、報告するのにOAMシグナル伝達機構を使用できます、片道遅れ、周遊旅行遅れ、パケット遅れ変化などのように また、それらは遠隔点検、および潜在的な問題(例えば、死にかかっている喘ぎメッセージ)の求められていない報告に使用されるかもしれません。
D.2. OAM Packet Format
D.2。 OAMパケット・フォーマット
When using inband performance monitoring, additional packets are sent using the same PW label. These packets are identified by having their first nibble equal to 0001, and must be separated from TDM data packets before further processing of the control word.
「不-バンド」性能を使用するとき、モニターしていて、追加しているパケットに同じPWラベルを使用させます。 これらのパケットをそれらの0001と等しい最初の少量を持っていることによって特定されて、規制単語のさらなる処理の前にTDMデータ・パケットから分離しなければなりません。
When using a separate OAM PW, all OAM messages MUST use the PW label preconfigured to indicate OAM. All PSN layer parameters MUST remain those of the PW being monitored.
別々のOAM PWを使用するとき、すべてのOAMメッセージがOAMを示すためにあらかじめ設定されたPWラベルを使用しなければなりません。 すべてのPSN層のパラメタがモニターされるPWのもののままで残らなければなりません。
The format of an inband OAM PW message packet for UDP/IP PSNs is based on [RFC2679]. The PSN-specific layers are identical to those defined in Section 4.1 with the PW label set to the value preconfigured or assigned for PW OAM.
UDP/IP PSNsのためのinband OAM PWメッセージパケットの形式は[RFC2679]に基づいています。 PSN特有の層はPWラベル・セットでセクション4.1でPW OAMのためにあらかじめ設定されたか、または割り当てられた値と定義されたものと同じです。
Stein, et al. Informational [Page 39] RFC 5087 TDMoIP December 2007
シタイン、他 [39ページ]情報のRFC5087TDMoIP2007年12月
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PSN-specific layers (with preconfigured PW label) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0|L|R| M |RES| Length | OAM Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OAM Msg Type | OAM Msg Code | Service specific information |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Forward PW label | Reverse PW label |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Transmit Timestamp |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination Receive Timestamp |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination Transmit Timestamp |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | PSN特有の層(あらかじめ設定されたPWラベルがある)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0 0 0 0|L|R| M|RES| 長さ| OAM一連番号| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | OAMエムエスジータイプ| OAMエムエスジーコード| 特殊情報を修理してください。| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 前進のPWラベル| 逆のPWラベル| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 情報筋はタイムスタンプを伝えます。| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 目的地はタイムスタンプを受け取ります。| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 目的地はタイムスタンプを伝えます。| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
L, R, and M are identical to those of the PW being tested.
L、R、およびMはテストされるPWのものと同じです。
Length is the length in bytes of the OAM message packet.
長さはOAMメッセージパケットのバイトで表現される長さです。
OAM Sequence Number (16 bits) is used to uniquely identify the
message. Its value is unrelated to the sequence number of the
TDMoIP data packets for the PW in question. It is incremented in
query messages, and replicated without change in replies.
OAM Sequence Number(16ビット)は、唯一メッセージを特定するのに使用されます。 問題のPWに、値はTDMoIPデータ・パケットの一連番号に関係ありません。 それは、質問メッセージで増加されて、変化なしで回答で模写されます。
OAM Msg Type (8 bits) indicates the function of the message. At
present the following are defined:
OAMエムエスジーType(8ビット)はメッセージの機能を示します。 現在のところ、以下は定義されます:
0 for one-way connectivity query message
8 for one-way connectivity reply message.
片道接続性のための0は片道接続性応答メッセージへのメッセージ8について質問します。
OAM Msg Code (8 bits) is used to carry information related to the
message, and its interpretation depends on the message type. For
type 0 (connectivity query) messages the following codes are
defined:
OAMエムエスジーCode(8ビット)はメッセージに関連する情報を運ぶのに使用されます、そして、解釈はメッセージタイプに頼っています。 タイプ0(接続性質問)メッセージに関しては、以下のコードは定義されます:
0 validate connection.
1 do not validate connection
0は接続を有効にします。 1 接続を有効にしないでください。
for type 8 (connectivity reply) messages the available codes are:
タイプ8(接続性回答)メッセージに関しては、利用可能なコードは以下の通りです。
0 acknowledge valid query
1 invalid query (configuration mismatch).
0は有効な質問1の無効の質問(構成ミスマッチ)を承諾します。
Stein, et al. Informational [Page 40] RFC 5087 TDMoIP December 2007
シタイン、他 [40ページ]情報のRFC5087TDMoIP2007年12月
Service specific information (16 bits) is a field that can be used
to exchange configuration information between IWFs. If it is not
used, this field MUST contain zero. Its interpretation depends on
the payload type. At present, the following is defined for AAL1
payloads.
(16ビット)がIWFsの間で設定情報を交換するのに使用できる分野であるという特殊情報を修理してください。 それが使用されていないなら、この分野はゼロを含まなければなりません。 解釈はペイロードタイプに頼っています。 現在のところ、以下はAAL1ペイロードのために定義されます。
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Number of TSs | Number of SFs |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | TSsの数| SFsの数| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Number of TSs (8 bits) is the number of channels being transported,
e.g., 24 for full T1.
TSs(8ビット)の数は輸送されるチャンネルの数、例えば、完全なT1のための24です。
Number of SFs (8 bits) is the number of 48-byte AAL1 PDUs per
packet, e.g., 8 when packing 8 PDUs per packet.
1パケットあたり8PDUsを梱包するとき、SFs(8ビット)の数は1パケットあたりの48バイトのAAL1 PDUs、例えば、8の数です。
Forward PW label (16 bits) is the PW label used for TDMoIP traffic
from the source to destination IWF.
前進のPWラベル(16ビット)はソースから目的地IWFまでのTDMoIP交通に使用されるPWラベルです。
Reverse PW label (16 bits) is the PW label used for TDMoIP traffic
from the destination to source IWF.
逆のPWラベル(16ビット)は目的地からソースIWFまでのTDMoIP交通に使用されるPWラベルです。
Source Transmit Timestamp (32 bits) represents the time the PSN-
bound IWF transmitted the query message. This field and the
following ones only appear if delay is being measured. All time
units are derived from a clock of preconfigured frequency, the
default being 100 microseconds.
ソースTransmit Timestamp(32ビット)はPSNの制限されたIWFが質問メッセージを送った時を表します。 遅れが測定されている場合にだけ、この分野と以下の人は現れます。 デフォルトが100マイクロセカンドでありあらかじめ設定された頻度の時計からすべてのタイム・ユニットを得ます。
Destination Receive Timestamp (32 bits) represents the time the
destination IWF received the query message.
目的地Receive Timestamp(32ビット)は目的地IWFが質問メッセージを受け取った時を表します。
Destination Transmit Timestamp (32 bits) represents the time the
destination IWF transmitted the reply message.
目的地Transmit Timestamp(32ビット)は目的地IWFが応答メッセージを伝えた時を表します。
Stein, et al. Informational [Page 41] RFC 5087 TDMoIP December 2007
シタイン、他 [41ページ]情報のRFC5087TDMoIP2007年12月
Appendix E. Capabilities, Configuration and Statistics (Informative)
付録E.能力、構成、および統計(有益)です。
Every TDMoIP IWF will support some number of physical TDM connections, certain types of PSN, and some subset of the modes defined above. The following capabilities SHOULD be able to be queried by the management system:
あらゆるTDMoIP IWFが物理的なTDM接続の何らかの数、PSNのあるタイプ、および上で定義されたモードの何らかの部分集合をサポートするでしょう。 以下の能力SHOULD、マネージメントシステムは質問できてください:
AAL1 capable
できるAAL1
AAL2 capable (and AAL2 parameters, e.g., support for VAD and
compression)
できるAAL2(そして、AAL2パラメタ、例えば、VADと圧縮のサポート)
HDLC capable
できるHDLC
Supported PSN types (UDP/IPv4, UDP/IPv6, L2TPv3/IPv4, L2TPv3/IPv6,
MPLS, Ethernet)
支持されたPSNはタイプします。(UDP/IPv4、UDP/IPv6、L2TPv3/IPv4、L2TPv3/IPv6、MPLS、イーサネット)
OAM support (none, separate PW, VCCV) and capabilities (CV, delay
measurement, etc.)
OAMサポート(なにも、別々のPW、VCCV)と能力(CV、遅れ測定など)
maximum packet size supported.
サイズが支持した最大のパケット。
For every TDM PW the following parameters MUST be provisioned or signaled:
あらゆるTDM PWに関しては、以下のパラメタに食糧を供給されなければならないか、または合図しなければなりません:
PW label (for UDP and Ethernet the label MUST be manually
configured)
PWラベル(UDPとイーサネットにおいて、ラベルを手動で構成しなければなりません)
TDM type (E1, T1, E3, T3, fractional E1, fractional T1)
TDMはタイプします。(1E、T1、E3、T3の1断片的なE断片的なT1)
for fractional links: number of timeslots
断片的なリンクに: timeslotsの数
TDMoIP mode (AAL1, AAL2, HDLC)
TDMoIPモード(AAL1、AAL2、HDLC)
for AAL1 mode:
AAL1モードのために:
AAL1 type (unstructured, structured, structured with CAS)
AAL1はタイプします。(不統一で、構造化されて、構造化されたCASと共に)
number of AAL1 PDUs per packet
1パケットあたりのAAL1 PDUsの数
for AAL2 mode:
AAL2モードのために:
CID mapping
CIDマッピング
creation time of full minicell (units of 125 microsecond)
完全なミニ細胞の創造時間(125マイクロセカンドのユニット)
Stein, et al. Informational [Page 42] RFC 5087 TDMoIP December 2007
シタイン、他 [42ページ]情報のRFC5087TDMoIP2007年12月
size of jitter buffer (in 32-bit words)
ジターバッファのサイズ(32ビットの単語による)
clock recovery method (local, loop-back timing, adaptive, common
clock)
時計回復方法(地方の、そして、輪の逆タイミング、適応型の、そして、一般的な時計)
use of RTP (if used: frequency of common clock, PT and SSRC
values).
RTP(使用されて、: コモンの頻度は時間を計るか、そして、PTとSSRC値)の使用。
During operation, the following statistics and impairment indications SHOULD be collected for each TDM PW, and can be queried by the management system.
操作の間、以下の統計と損傷指摘SHOULDを各TDM PWのために集めて、マネージメントシステムは質問できます。
average round-trip delay
平均した往復の遅れ
packet delay variation (maximum delay - minimum delay)
パケット遅れ変化(最大の遅れ--最小の遅れ)
number of potentially lost packets
潜在的に無くなっているパケットの数
indication of misordered packets (successfully reordered or
dropped)
misorderedパケットのしるし(首尾よく再命令されるか、または落とされます)
for AAL1 mode PWs:
AAL1モードPWsのために:
indication of malformed PDUs (incorrect CRC, bad C, P or E)
奇形のPDUsのしるし(不正確なCRC、悪いC、PまたはE)
indication of cells with pointer mismatch
ポインタミスマッチがあるセルのしるし
number of seconds with jitter buffer over-run events
ジターバッファ超過イベントに伴う秒数
number of seconds with jitter buffer under-run events
経営の下にジターバッファイベントがある秒数
for AAL2 mode PWs:
AAL2モードPWsのために:
number of malformed minicells (incorrect HEC)
奇形のミニ細胞の数(不正確なHEC)
indication of misordered minicells (unexpected UUI)
misorderedミニ細胞のしるし(予期していなかったUUI)
indication of stray minicells (CID unknown, illegal UUI)
迷っているミニ細胞のしるし(CIDの未知の、そして、不法なUUI)
indication of mis-sized minicells (unexpected LI)
誤サイズのミニ細胞のしるし(予期していなかったLI)
for each CID: number of seconds with jitter buffer over-run
events
各CIDのために: ジターバッファ超過イベントに伴う秒数
Stein, et al. Informational [Page 43] RFC 5087 TDMoIP December 2007
シタイン、他 [43ページ]情報のRFC5087TDMoIP2007年12月
for HDLC mode PWs:
HDLCモードPWsのために:
number of discarded frames from TDM (e.g., CRC error, illegal
packet size)
TDMからの捨てられたフレームの数(例えば、CRC誤り、不法なパケットサイズ)
number of seconds with jitter buffer over-run events.
ジターバッファがある秒数は出来事をオーバランさせます。
During operation, the following statistics MAY be collected for each TDM PW.
操作の間、以下の統計は各TDM PWのために集められるかもしれません。
number of packets sent to PSN
PSNに送られたパケットの数
number of packets received from PSN
PSNから受け取られたパケットの数
number of seconds during which packets were received with L flag
set
パケットがL旗で受け取られた秒数はセットしました。
number of seconds during which packets were received with R flag
set.
パケットがR旗で受け取られた秒数はセットしました。
Stein, et al. Informational [Page 44] RFC 5087 TDMoIP December 2007
シタイン、他 [44ページ]情報のRFC5087TDMoIP2007年12月
References
参照
Normative References
引用規格
[AAL1] ITU-T Recommendation I.363.1 (08/96) - B-ISDN ATM
Adaptation Layer (AAL) specification: Type 1
[AAL1]ITU-T Recommendation I.363.1(08/96)--B-ISDN ATM Adaptation Layer(AAL)仕様: 1をタイプしてください。
[AAL2] ITU-T Recommendation I.363.2 (11/00) - B-ISDN ATM
Adaptation Layer (AAL) specification: Type 2
[AAL2]ITU-T Recommendation I.363.2(11/00)--B-ISDN ATM Adaptation Layer(AAL)仕様: 2をタイプしてください。
[CES] ATM forum specification atm-vtoa-0078 (CES 2.0) Circuit
Emulation Service Interoperability Specification Ver.
2.0
[CES]ATMフォーラム仕様気圧-vtoa-0078(CES2.0)サーキットEmulation Service Interoperability Specification Ver2.0
[G704] ITU-T Recommendation G.704 (10/98) - Synchronous frame
structures used at 1544, 6312, 2048, 8448 and 44736
kbit/s hierarchical levels
[G704]ITU-T Recommendation G.704(10/98)--1544年、6312年、2048年、8448年に使用された同期枠組構造と44736のkbit/s階層レベル
[G751] ITU-T Recommendation G.751 (11/88) - Digital multiplex
equipments operating at the third order bit rate of
34368 kbit/s and the fourth order bit rate of 139264
kbit/s and using positive justification
[G751]ITU-T Recommendation G.751(11/88)--34368kbit/sの3番目のオーダービット伝送速度と139264kbit/sの4番目のオーダービット伝送速度で作動して、積極的な正当化を使用するデジタルマルチプレックス機器
[G823] ITU-T Recommendation G.823 (03/00) - The control of
jitter and wander within digital networks which are
based on the 2048 Kbit/s hierarchy
[G823] ITU-T Recommendation G.823(03/00)--ジターのコントロール、2048年のキロビット/s階層構造に基づいているディジタル通信網の中を歩き回ってください。
[G824] ITU-T Recommendation G.824 (03/00) - The control of
jitter and wander within digital networks which are
based on the 1544 Kbit/s hierarchy
[G824] ITU-T Recommendation G.824(03/00)--ジターのコントロール、1544年のキロビット/s階層構造に基づいているディジタル通信網の中を歩き回ってください。
[G826] ITU-T Recommendation G.826 (12/02) - End-to-end error
performance parameters and objectives for
international, constant bit-rate digital paths and
connections
[G826]ITU-T Recommendation G.826(12/02)--国際的で、一定のビット伝送速度デジタル経路と接続のための終わりから終わりへの誤り性能パラメタと目的
[IEEE802.1Q] IEEE 802.1Q, IEEE Standards for Local and Metropolitan
Area Networks -- Virtual Bridged Local Area Networks
(2003)
[IEEE802.1Q]IEEE 802.1Q、地方とメトロポリタンエリアネットワークのIEEE規格--仮想の橋を架けられたローカル・エリア・ネットワーク(2003)
[IEEE802.3] IEEE 802.3, IEEE Standard Local and Metropolitan Area
Networks - Carrier Sense Multiple Access with Collision
Detection (CSMA/CD) Access Method and Physical Layer
Specifications (2002)
IEEEの標準の[IEEE802.3]IEEE802.3、地方、およびメトロポリタンエリアネットワーク--衝突検出型搬送波検知多重アクセス(CSMA/CD)アクセス法と物理的な層の仕様(2002)
Stein, et al. Informational [Page 45] RFC 5087 TDMoIP December 2007
シタイン、他 [45ページ]情報のRFC5087TDMoIP2007年12月
[LES] ATM forum specification atm-vmoa-0145 (LES) Voice and
Multimedia over ATM - Loop Emulation Service Using AAL2
ATMの上の[LES]ATMフォーラム仕様気圧-vmoa-0145(LES)声とMultimedia--輪のEmulation Service Using AAL2
[MEF8] Metro Ethernet Forum, "Implementation Agreement for the
Emulation of PDH Circuits over Metro Ethernet
Networks", October 2004.
[MEF8]地下鉄イーサネットフォーラム、「地下鉄イーサネットネットワークの上のPDHサーキットのエミュレーションのための実現協定」、2004年10月。
[RFC768] Postel, J., "User Datagram Protocol (UDP)", STD 6, RFC
768, August 1980.
[RFC768] ポステル、J.、「ユーザー・データグラム・プロトコル(UDP)」、STD6、RFC768、1980年8月。
[RFC791] Postel, J., "Internet Protocol (IP)", STD 5, RFC 791,
September 1981.
[RFC791] ポステル、J.、「インターネットプロトコル(IP)」、STD5、RFC791、1981年9月。
[RFC2119] Bradner, S., "Key Words in RFCs to Indicate Requirement
Levels", RFC 2119, March 1997.
[RFC2119] ブラドナー、S.、「要件レベルを示すRFCsのキーワード」、RFC2119、1997年3月。
[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月)。
[RFC3931] Lau, J., Townsley, M., Goyret, I., "Layer Two Tunneling
Protocol - Version 3 (L2TPv3)", RFC 3931, March 2005.
[RFC3931]ラウ、J.、Townsley、M.、Goyret、I.、「2トンネリングプロトコルを層にしてください--バージョン3(L2TPv3)」、RFC3931、3月2005日
[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and
Jacobson, V., "RTP: A Transport Protocol for Real-Time
Applications", STD 64, RFC 3550, July 2003.
[RFC3550]SchulzrinneとH.とCasnerとS.とフレディリック、R.とジェーコブソン、V.、「RTP:」 「リアルタイムのアプリケーションのためのトランスポート・プロトコル」、STD64、RFC3550、2003年7月。
[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月。
[RFC4447] Martini, L., 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月。
[RFC4553] Vainshtein A., and Stein YJ., "Structure-Agnostic TDM
over Packet (SAToP)", RFC 4553, June 2006.
[RFC4553]Vainshtein A.、およびシタインYJ、「パケット(SAToP)の上の構造不可知論者TDM」、RFC4553、6月2006日
[RFC4618] Martini L., Rosen E., Heron G., and Malis A.,
"Encapsulation Methods for Transport of PPP/High-Level
Data Link Control (HDLC) over MPLS Networks", RFC 4618,
September 2006.
[RFC4618] マティーニL.、ローゼンE.、サギG.、およびMalis A.、「MPLSネットワークの上のppp/ハイレベル・データ・リンク制御手順(HDLC)の輸送のためのカプセル化方法」、RFC4618(2006年9月)。
[RFC5085] Nadeau, T., Ed., and C. Pignataro, Ed., "Pseudowire
Virtual Circuit Connectivity Verification: A Control
Channel for Pseudowires", RFC 5085, December 2007.
[RFC5085]ナドー、T.、エド、C.Pignataro、エド、「Pseudowireの仮想のサーキット接続性検証:」 「Pseudowiresの制御チャンネル」、RFC5085、2007年12月。
Stein, et al. Informational [Page 46] RFC 5087 TDMoIP December 2007
シタイン、他 [46ページ]情報のRFC5087TDMoIP2007年12月
[SSCS] ITU-T Recommendation I.366.2 (11/00) - AAL type 2
service specific convergence sublayer for narrow-band
services.
[SSCS]ITU-T Recommendation I.366.2(11/00)--AALタイプ2は狭周波数帯サービスのために特定の集合副層を修理します。
[Y1413] ITU-T Recommendation Y.1413 (03/04) - TDM-MPLS network
interworking - User plane interworking
[Y1413]ITU-T Recommendation Y.1413(03/04)--TDM-MPLSネットワークの織り込むこと--ユーザ飛行機の織り込むこと
[Y1414] ITU-T Recommendation Y.1414 (07/04) - Voice services -
MPLS network interworking.
[Y1414]ITU-T Recommendation Y.1414(07/04)--ボイスサービス--MPLSは織り込むことをネットワークでつなぎます。
[Y1452] ITU-T Recommendation Y.1452 (03/06) - Voice trunking
over IP networks.
[Y1452]ITU-T Recommendation Y.1452(03/06)--IPネットワークの上で中継方式を声に出してください。
[Y1453] ITU-T Recommendation Y.1453 (03/06) - TDM-IP
interworking - User plane interworking.
[Y1453]ITU-T Recommendation Y.1453(03/06)--TDM-IPの織り込むこと--ユーザ飛行機の織り込むこと。
Informative References
有益な参照
[ISDN-PRI] ITU-T Recommendation Q.931 (05/98) - ISDN user-network
interface layer 3 specification for basic call control.
[ISDN-PRI] ITU-T Recommendation Q.931(05/98)--基本的な呼び出しコントロールのためのISDNユーザネットワーク・インターフェース層の3仕様。
[RFC792] Postel J., "Internet Control Message Protocol", STD 5,
RFC 792, September 1981.
[RFC792]ポステルJ.、「インターネット・コントロール・メッセージ・プロトコル」、STD5、RFC792、1981年9月。
[RFC2212] Shenker, S., Partridge, C., and R. Guerin,
"Specification of Guaranteed Quality of Service", RFC
2212, September 1997.
1997年9月の[RFC2212]ShenkerとS.とヤマウズラ、C.とR.ゲラン、「保証されたサービスの質の仕様」RFC2212。
[RFC2330] Paxson, V., Almes, G., Mahdavi, J., Mathis M.,
"Framework for IP Performance Metrics", RFC 2330, May
1998.
[RFC2330]パクソン(V.、Almes、G.、Mahdavi、J.、マシスM.、「IPパフォーマンス測定基準のための枠組み」、RFC2330)は1998がそうするかもしれません。
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version
6 (IPv6) Specification", RFC 2460, December 1998.
[RFC2460]デアリング、S.とR.Hinden、「インターネットプロトコル、バージョン6(IPv6)仕様」、RFC2460、12月1998日
[RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black,
"Definition of the Differentiated Services Field (DS
Field) in the IPv4 and IPv6 Headers", RFC 2474,
December 1998.
[RFC2474] ニコルズ、K.、ブレーク、S.、ベイカー、F.、およびD.黒、「IPv4とIPv6ヘッダーとの微分されたサービス分野(DS分野)の定義」、RFC2474(1998年12月)。
[RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang,
Z., and W. Weiss, "An Architecture for Differentiated
Service", RFC 2475, December 1998.
[RFC2475] ブレーク、S.は黒くされます、D.、カールソン、M.、デイヴィース、E.、ワング、Z.とW.ウィス、「微分されたサービスのための構造」RFC2475、1998年12月。
[RFC2679] Almes, G., Kalidindi, S., and M. Zekauskas, "A One-way
Delay Metric for IPPM", RFC 2679, September 1999.
[RFC2679]Almes、G.、Kalidindi、S.、およびM.Zekauskas、「IPPMにおける、メートル法のA One-道の遅れ」、RFC2679、1999年9月。
Stein, et al. Informational [Page 47] RFC 5087 TDMoIP December 2007
シタイン、他 [47ページ]情報のRFC5087TDMoIP2007年12月
[RFC2914] Floyd, S., "Congestion Control Principles", BCP 41, RFC
2914, September 2000.
[RFC2914]フロイド、S.、「輻輳制御プリンシプルズ」、BCP41、RFC2914、2000年9月。
[RFC3246] Davie, B., Charny, A., Bennet, J.C., Benson, K., Le
Boudec, J., Courtney, W., Davari, S., Firoiu, V., and
D. Stiliadis, "An Expedited Forwarding PHB (Per-Hop
Behavior)", RFC 3246, March 2002.
[RFC3246] デイビー、B.、シャルニー、A.、アメリカダイコンソウ、J.C.、ベンソン、K.、Le Boudec、J.、コートニー、W.、Davari、S.、Firoiu、V.、および2002年のD.Stiliadis、「完全優先転送PHB(1ホップあたりの振舞い)」、RFC3246行進。
[RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and
K. Norrman, "The Secure Real-time Transport Protocol
(SRTP)", RFC 3711, March 2004.
[RFC3711] 2004年のBaugher、M.、マグリュー、D.、ジーター、M.、カラーラ、E.、およびK.Norrman、「安全なリアルタイムのトランスポート・プロトコル(SRTP)」、RFC3711行進。
[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月。
[RFC4086] Eastlake, D., 3rd, Schiller, J., and S. Crocker,
"Randomness Requirements for Security", BCP 106, RFC
4086, June 2005.
[RFC4086]イーストレークとD.と3番目、シラー、J.とS.クロッカー、「セキュリティのための偶発性要件」BCP106、2005年6月のRFC4086。
[RFC4197] Riegel, M., "Requirements for Edge-to-Edge Emulation of
Time Division Multiplexed (TDM) Circuits over Packet
Switching Networks", RFC 4197, October 2005.
[RFC4197]リーゲル、M.、「縁から縁への時間事業部のエミュレーションのための要件は(TDM)サーキットをパケット交換網の上に多重送信しました」、RFC4197、2005年10月。
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the
Internet Protocol", RFC 4301, December 2005.
[RFC4301] ケントとS.とK.Seo、「インターネットプロトコルのためのセキュリティー体系」、RFC4301、2005年12月。
[RFC4379] Kompella, K. and Swallow, G., "Detecting Multi-Protocol
Label Switched (MPLS) Data Plane Failures", RFC 4379,
February 2006.
[RFC4379] KompellaとK.とツバメ、G.、「マルチプロトコルのラベルの切り換えられた(MPLS)データ飛行機の故障を検出します」、RFC4379、2006年2月。
[RFC4385] Bryant, S., Swallow, G., Martini, L., and D. McPherson,
"Pseudowire Emulation Edge-to-Edge (PWE3) Control Word
for Use over an MPLS PSN", RFC 4385, February 2006.
[RFC4385] ブライアント、S.は飲み込まれます、マティーニ、L.とD.マクファーソン、「縁から縁(PWE3)へのコントロールがMPLS PSNの上の使用のために言い表すPseudowireエミュレーション」RFC4385、G.、2006年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月)。
[SS7] ITU-T Recommendation Q.700 (03/93) - Introduction to
CCITT Signalling System No. 7.
[SS7]ITU-T推薦Q.700(03/93)--CCITT合図システムNo.7への序論。
[TDM-CONTROL] Vainshtein, A. and Y(J) Stein, "Control Protocol
Extensions for Setup of TDM Pseudowires in MPLS
Networks", Work in Progress, November 2007.
[TDM-コントロール] 「MPLSネットワークにおける、TDM Pseudowiresのセットアップのための制御プロトコル拡大」というVainshtein、A.、およびY(J)シタインは進行中(2007年11月)で働いています。
Stein, et al. Informational [Page 48] RFC 5087 TDMoIP December 2007
シタイン、他 [48ページ]情報のRFC5087TDMoIP2007年12月
[TRAU] GSM 08.60 (10/01) - Digital cellular telecommunications
system (Phase 2+); Inband control of remote transcoders
and rate adaptors for Enhanced Full Rate (EFR) and full
rate traffic channels.
[TRAU]GSM08.60(10/01)(デジタルセル情報通信システム(フェーズ2+)) リモートトランスコーダのInbandコントロール、Enhanced Full Rate(EFR)のためのレートアダプター、および全額料金交通チャンネル。
Authors' Addresses
作者のアドレス
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
Ronen Shashoua RAD Data Communications 24 Raoul Wallenberg St., Bldg C Tel Aviv 69719 ISRAEL
ローネンShashoua RADデータ通信24ラウルワレンバーグBldg Cテルアビブ69719通り(イスラエル)
Phone: +972 3 645-5447 EMail: ronen_s@rad.com
以下に電話をしてください。 +972 3 645-5447 メールしてください: ronen_s@rad.com
Ron Insler RAD Data Communications 24 Raoul Wallenberg St., Bldg C Tel Aviv 69719 ISRAEL
ロンインスラーradデータ通信24ラウルワレンバーグBldg Cテルアビブ69719通り(イスラエル)
Phone: +972 3 645-5445 EMail: ron_i@rad.com
以下に電話をしてください。 +972 3 645-5445 メールしてください: ron_i@rad.com
Motty (Mordechai) Anavi RAD Data Communications 900 Corporate Drive Mahwah, NJ 07430 USA
法人のMotty(モルデハイ)Anavi radデータ通信900Driveニュージャージー07430マフワー(米国)
Phone: +1 201 529-1100 Ext. 213 EMail: motty@radusa.com
以下に電話をしてください。 +1 201 529-1100Ext。 213 メール: motty@radusa.com
Stein, et al. Informational [Page 49] RFC 5087 TDMoIP December 2007
シタイン、他 [49ページ]情報のRFC5087TDMoIP2007年12月
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The IETF Trust (2007).
IETFが信じる著作権(C)(2007)。
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に情報を記述してください。
Stein, et al. Informational [Page 50]
シタイン、他 情報[50ページ]
一覧
スポンサーリンク
