Network Working Group Y(J). Stein
Request for Comments: 5087 R. Shashoua
Category: Informational R. Insler
M. Anavi
RAD Data Communications
December 2007
Time Division Multiplexing over 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のは）擬似回線（PWの）を使用して、時分割多重（TDM）信号を輸送するための構造を意識した方法です。構造意識して、のTDMoIPはTDM構造の整合性を確保するため、構造に依存しない交通機関よりも優れたネットワークの劣化に耐えることができます。構造を意識した方法は、パケット損失の隠蔽と帯域幅の節約を可能にする、個々のチャネルを識別することができます。 TDMシグナリングのアクセシビリティは、シグナリングを利用または操作機構を容易にします。
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
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].
電話トラフィックは、従来（緩く本明細書TDM回線と呼ばれる）接続指向同期またはプレシオクロナスリンクを介して行われます。パケット交換ネットワーク（PSNが）の増殖に、PSNのインフラの上にTDMサービスの輸送が望まれるようになっています。 PWE3アーキテクチャ[RFC3985]に記載されているようにPSN上TDM回路のエミュレーションは、疑似回線（PWの）を用いて行うことができます。このエミュレーションは、ネイティブTDMのサービス品質を維持しなければなりません。 TDM PW要件文書[RFC4197]に記載されているように特定の音声品質、遅延、タイミング、およびシグナリングの特徴では、既存のTDMネットワークのものと類似していなければなりません。
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.
パケット（のSAToP）上の構造にとらわれないTDM [RFC4553]はのPSN上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）プロトコルは、IPオーバーIPv4またはIPv6、MPLS、レイヤ2トンネリングプロトコルバージョン3（L2TPv3の）上のUDP、および純粋なイーサネット（登録商標）を含む、PSNのいくつかのタイプを、上で動作することができます。プロトコルは、より一般的TDMoPW等の特定の実装ののTDMoIP、TDMoMPLSを呼び出さなければならないが、特定のPSNの実装詳細はセクション4に記載されている、我々は、以前の使用との一貫性のための命名の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の世界の間を接続するインターワーキング機能は、のTDMoIPインターワーキング機能（IWF）と呼ばれる、それはプロバイダエッジ（PE）で、または顧客エッジ（CE）に位置してもよいです。パケットからTDMデータを抽出し、TDMネットワーク上のトラフィックを生成するIWFはTDM結合インターワーキング機能と呼ぶことにしながら、TDMをカプセル化し、PSNにパケットを注入IWFは、PSNに結合したインターワーキング機能と呼ぶことにします。エミュレートされた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].
全てのPWと同様、のTDMoIP PWSが手動で設定またはPWE3制御プロトコル[RFC4447]を使用して設定することができます。 TDMoIPの疑似回線の設定や保守のために特に必要PWE3制御プロトコルへの拡張は、[TDM-CONTROL]に記載されています。
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"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はあります[RFC2119]に記載されているように解釈されます。
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回路は、任意のビットストリームを運ぶために使用することができるが、「構造」と呼ばれるデータの一定の長ブロックを運ぶための標準化された方法があります。おなじみの構造は、T1またはE1、それぞれのフレーム長193の[G704]及び256ビットです。連続したT1またはE1フレームの連結によって、我々は、スーパーフレームまたはマルチフレームと呼ばれる、より高いレベルの構造を構築することができます。 T3およびE3フレーム[G704] [G751] [TRAU]に記載GSMエービスチャネルで使用されるT1とE1、及びより大きな構造のものよりもはるかに大きいです。 TDM構造は、TDMデータを加えた構造のオーバーヘッドが含まれています。 32バイトE1フレームがオーバーヘッドと31データバイトのバイトを含むが、例えば、193ビットのT1フレームは、構造のオーバーヘッドとデータの24バイトの単一ビットを含みます。
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フレーム内の単一のバイトは、各チャネルに割り当てられます。 E1フレームは31個のチャネルで構成されながら、チャネル化T1のフレームは、24バイトサイズのチャネルを運びます。 TDMフレームは毎秒8000回送信されるので、単一バイトサイズのチャネルが64kbpsのを運びます。
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.
TDM構造は普遍的に容易に検出可能な周期的なビットパターンを配置することによって区切られ、構造オーバーヘッドでは、フレームアライメント信号（FAS）と呼ばれます。構造オーバーヘッドはさらにエラー監視と欠陥表示を含んでいてもよいです。私たちは、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]はのPWを用いてTDMを輸送するための構造に依存しないプロトコルです。 SAToP完全TDMビットストリーム内に存在し得る任意の構造を無視し、任意のビットストリームとしてTDM入力を処理します。したがって、のSAToPは本当に非構造化TDMの輸送のための理想的ですが、構造の完全性を保護したり解釈したり、輸送中に個々のチャンネルを操作する必要がない場合も、構造化TDMの輸送に適しています。特に、のSAToPは無視できる程度のパケットロスでのPSNのための、および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 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.
[RFC4553]に記載されているように単一のSAToPパケットが失われた場合、「すべて1」のパターンは、TDMインタフェースに再生されます。このパターンは、TDM標準に従って、アラーム表示信号（AIS）、[G826]としてTDMエンド機器によって解釈され、すぐに「重大エラー秒」イベントをトリガします。このようなイベントは、非常に望ましくないと考えられている通り、のSAToPの適合性は、非常に信頼性が高く、十分に利用されていないのPSNに制限されています。
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 PWをはPSNの向こう構造のオーバーヘッドを輸送する必要はありません。具体的には、FASは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輸送はまた、このように、チャネルレベルで洗練されたパケット損失隠蔽を可能にする、チャネル化TDMの個々のタイムスロットを識別することができます。 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構造の完全性を確保するの三の概念的に異なる方法があります。構造ロックはTDM構造の開始時に開始するように、全体構造またはその整数倍を含むように各パケットを必要とします。構造表示は、パケットは、基本的な構造の任意の断片を含むことができますが、各構造が始まる場所を示すためにポインタを使用します。構造再構築だけチャネライズド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つの方法は、それぞれの長所を持っています。本文書は、構造指示（セクション5.1を参照のこと）および構造再組立の両方を指定しながら、構造ロックが近づく（セクション5.2を参照）、[RFC5086]に記載されています。チャネルは、静的に割り当てることができる場合、及び/又はAAL1に基づいて、既存の回路エミュレーションシステム（CES）と連動する必要がある場合、構造表示が使用されています。チャネルの動的割り当てが望まれる場合、および/またはAAL2に基づいて、既存のループエミュレーションシステム（LES）と連動する必要がある場合、構造リアセンブリが使用されます。
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.
運用、管理、および保守（OAM）メカニズムは、適切なTDMの展開のために不可欠です。前述のように、構造認識メカニズムは、OAM機能を破壊する、PSNを横切る構造オーバーヘッドを輸送控えることができます。これは、2 OAMのケースを区別することが有益である、「道は終了」とのシナリオを「道が拡張しました」。トレイルは、データ及び関連OAM情報転送の組み合わせであると定義されます。 TDM証跡が終了すると、そのようなエラーの監視及び欠陥指標としてOAM情報は、PSN上で輸送されていない、およびTDMネットワーク機能別OAMドメインとして。トレイル拡張場合、我々は（必ずしもそのネイティブ形式である）PSN上OAM情報を転送します。 OAMは、第6節でさらに議論されます。
The overall format of TDMoIP packets is shown in Figure 1.
TDMoIPパケットの全体的なフォーマットは図1に示されています。
+---------------------+
| PSN Headers |
+---------------------+
| TDMoIP Control Word |
+---------------------+
| Adapted Payload |
+---------------------+
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イーサネット（登録商標）のものであり、TDM-結合した1つのPSN結合IWFからパケットを転送するために必要な全ての情報を含みます。 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のPWをサポートすることができる、とのTDMoIP IWFは、各TDM PWのコンテキスト情報を維持しなければなりません。別個のPWは、PSN固有層で運ばれるPWラベルに基づいて区別されます。 TDMは本質的に双方向であるため、逆方向に2つのPWの関連付けが必要です。二方向の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.
前述のヘッダに加えて、オプション12バイトのRTPヘッダはタイミング情報の明示的な転送を可能にするために表示されてもよいです。この用法は、[RFC3550]のヘッダ形式の純粋に形式的な再利用です。等ヘッダ拡張、寄与ソース（CSRC）リスト、パディング、RTP制御プロトコル（RTCP）、RTPヘッダ圧縮、セキュアRTP（SRTP）としてRTPメカニズムは、適用されません。
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のIWFに利用できる共通のクロックの単位でパケット作成時刻を示します。 TDMoIPのIWFは、十分に正確なローカルクロックを有するか、または明示的なタイムスタンプなしで十分に正確なタイミングを得ることができるときに共通のクロックが利用できない場合、または、RTPヘッダは省略されるべきです。
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タイプの制御ワードに従わなければなりません。バージョン番号が2に設定されなければならない、RTPヘッダ内のP（パディング）、X（ヘッダ拡張）、CC（CSRCカウント）、およびM（マーカー）フィールドをゼロに設定しなければならず、ペイロードタイプ（PT）値は、動的な値の範囲から割り当てられなければなりません。 RTPシーケンス番号（下記参照）のTDMoIP制御ワードのシーケンス番号と同一でなければなりません。 RTPタイムスタンプは、[RFC3550]に確立された規則に従って生成されなければなりません。クロック周波数は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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2. Structure of the TDMoIP Control Word
TDMoIPの制御ワードの図2の構造
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がMPLSのときRES（4ビット）、制御ワードの最初のニブルは転送デバイスがディープパケットインスペクションを実行すると、パケットがIPパケットをエイリアスしないことを保証するために、ゼロに設定しなければなりません。 MPLS以外のPSNのために、最初のニブルはゼロに設定されてもよいです。ただし、のTDMoIPの以前のバージョンでは、このフィールドは、必要に応じて、ペイロード・フォーマットを指定するために使用されたフォーマット識別子を含んでいました。
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物理層の障害を通知されたときL局所再発（1ビット）は、Lフラグが設定されています。 IWFは、信号の損失、フレーム同期、またはAISの損失を検出したときに「道拡張」OAMシナリオでLフラグを設定しなければなりません。 Lフラグが設定されている場合、パケットの内容は意味がないかもしれない、そしてペイロードは、帯域幅を節約するために抑制することができます。 TDM障害が整流された場合に設定されると、Lフラグをクリアする必要があります。 Lフラグの使用は、セクション6で説明されています。
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.
IWFが検出したまたは双方向接続の逆方向の失敗を示す、TDMデータがリモートTDMネットワークから受信されていないことを、知らされたときRリモート障害（1ビット）は、Rフラグが設定されています。 IWFは、Rフラグ指示を受信するとTDMリモート障害インジケータ（RDI）を生成する必要があります。 IWFがRDIを検出したときに「道拡張」OAMシナリオで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フィールドのM欠陥修飾（2ビット）の使用はオプションです。使用された場合、それはLフラグの意味を補足します。
When L is cleared (indicating valid TDM data) the M field is used as follows:
Lは、（有効なTDMデータを示す）がクリアされたときに、以下のようにMフィールドが使用されています。
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が設定されている場合、以下のように（無効TDMデータ）Mフィールドが使用されています。
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 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.
シーケンス番号（16ビット）のTDMoIPシーケンス番号は[RFC3985]に記載の一般的なPW配列機能を提供し、失われたとmisorderedパケットの検出を可能にします。シーケンス番号空間は、16ビット符号なし円形の空間です。シーケンス番号の初期値は、セキュリティ目的のために（予測不可能な）ランダムれるべきであり、その値は各PWのために別々にモジュロ2 ^ 16をインクリメントします。 TDM結合IWFは、付録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つの適応アルゴリズム（セクション5を参照）のいずれかを使用して適合され、そして得られた適合ペイロードをパケットに入れられます。
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のPWは、UDP / IP（IPv4とIPv6の両方）、L2TPv3のオーバーIP（NO介在UDPで）、MPLS、及びレイヤ2イーサネット（登録商標）を含む各種のPSNを利用することができます。以下のサブセクションでは、これらのケースのためのパケットフォーマットを示しています。
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のPSNのために、フォーマットは、[Y1413]と[Y1414]で指定されたものと整合されます。 UDP / IPのPSNのために、フォーマットは、[Y1453]と[Y1452]で指定されたものと整合されます。レイヤ2イーサネット上のトランスポートのためのフォーマットは、[MEF8]と整列されます。
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とはわずかに異なるが、本明細書に記載されるようにUDP / IPのためのPSNのTDMoIPの実装は、Y.1453副次9.2.2またはY.1452項10に準拠するように設計された実装と相互運用します。
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の場合、[RFC791] [RFC768]に記載されたようにヘッダはのTDMoIPデータに前置されています。フォーマットは、[RFC2460]に記載のIPヘッダを除いて使用され、UDP / IPv6のと同様です。 TDMoIPパケット構造は、図3に示されています。
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 |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3. TDMoIP Packet Format for UDP/IP
UDP / IPについては、図3のTDMoIPパケットフォーマット
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.
最初の5行がIPヘッダであり、第六及び第七行がUDPヘッダです。 10を介して行8は、オプションのRTPヘッダです。行11は、TDMoIPの制御ワードです。
IPVER (4 bits) is the IP version number, e.g., IPVER=4 for IPv4.
IPVER（4ビット）は、IPv4のIPバージョン番号、例えば、IPVER = 4です。
IHL (4 bits) is the length in 32-bit words of the IP header, IHL=5.
IHL（4ビット）、IHL = 5 IPヘッダの32ビットワードの長さです。
IP TOS (8 bits) is the IP type of service.
IP TOS（8ビット）は、サービスのIPタイプです。
Total Length (16 bits) is the length in bytes of header and data.
全体の長さ（16ビット）、ヘッダとデータのバイト単位の長さです。
Identification (16 bits) is the IP fragmentation identification field.
識別（16ビット）は、IPフラグメンテーション識別フィールドです。
Flags (3 bits) are the IP control flags and MUST be set to 2 in order to avoid fragmentation.
フラグ（3ビット）は、IP制御フラグであり、断片化を避けるために2に設定しなければなりません。
Fragment Offset (13 bits) indicates where in the datagram the fragment belongs and is not used for TDMoIP.
データグラムに断片が属するとのTDMoIPのために使用されていない場合にフラグメントオフセット（13ビット）を示しています。
Time to Live (8 bits) is the IP time to live field. Datagrams with zero in this field are to be discarded.
（8ビット）の生存時間は、フィールドを生きるIP時間です。この分野のゼロのデータグラムが破棄されることになります。
Protocol (8 bits) MUST be set to 0x11 (17) to signify UDP.
プロトコル（8ビット）は、UDPを意味する0x11を（17）に設定しなければなりません。
IP Header Checksum (16 bits) is a checksum for the IP header.
IPヘッダチェックサム（16ビット）は、IPヘッダのチェックサムです。
Source IP Address (32 bits) is the IP address of the source.
送信元IPアドレス（32ビット）は、ソースのIPアドレスです。
Destination IP Address (32 bits) is the IP address of the destination.
宛先IPアドレス（32ビット）、宛先のIPアドレスです。
Source and Destination Port Numbers (16 bits each)
送信元と宛先ポート番号（各16ビット）
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ポートまたは宛先UDPポートのいずれかは、ノード間の個々のPWを多重化及び逆多重化するために使用されるかもしれません。アーキテクチャ[RFC3985]、これはPWラベルとしてUDPポートの行為になります。 PWエンドポイントは、PWラベルとしてソースUDPまたは宛先UDPポートのいずれかの使用に同意しなければなりません。
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ポートを手動PWの両方のエンドポイントで構成されなければなりません。一緒に両方のソースおよび宛先IPアドレスで設定されたソースまたは宛先ポート（どちらか一方、両方ではない）が一意にPWを識別する。ソースUDPポートがPWラベルとして使用する場合、宛先UDPポート番号は、0x085E（2142）のIANA割り当てられた値に設定しなければなりません。 PWラベルとして機能するすべてのUDPポート値は、動的に割り当てられたUDPポート番号（0xFFFFのスルー0xC000）の範囲であるべきです。
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ベースのプロトコルは、悲惨な結果なしでミドルボックスを通過することができますが、PWラベルとしてUDPポートの使用はミドルトラバーサルをより困難にします。したがって、ポート翻訳中間装置は、PWエンドポイントとの間に存在しているUDPベースのPWを使用することが推奨されていません。
UDP Length (16 bits) is the length in bytes of UDP header and data.
UDP長さ（16ビット）は、UDPヘッダとデータのバイト単位の長さです。
UDP Checksum (16 bits) is the checksum of UDP/IP header and data. If not computed it MUST be set to zero.
UDPチェックサム（16ビット）は、UDP / IPヘッダとデータのチェックサムです。計算されない場合は、それをゼロに設定しなければなりません。
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勧告Y.1413 [Y1413]はMPLSネットワーク上でTDMを輸送するための構造に依存しないと構造認識機構が記載されています。同様に、ITU-T勧告Y.1414 [Y1413]は、この目的のために構造再アセンブリメカニズムを定義しています。ここで使用される用語は、ITUとはわずかに異なるが、本明細書に記載のMPLSのPSNのためのTDMoIPの実装は、Y.1413副次9.2.2またはY.1414項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.
[RFC3032]に記載されているように、MPLSヘッダは制御ワードとTDMペイロードに前置されています。パケット構造は、図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 |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4. TDMoIP Packet Format for MPLS
MPLSについては、図4のTDMoIPパケットフォーマット
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.
上に示した最初の2行は、MPLSヘッダです。第三は、TDMoIPの制御ワードです。以前に説明されていないフィールドについて説明します。
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].
トンネルラベル（20ビット）がMPLS LSPは、MPLSネットワークを介してトンネルにTDMパケットを使用識別するMPLSラベルです。ラベルは、手動プロビジョニングによって、またはMPLS制御プロトコルを介してのいずれかで割り当てることができます。 MPLSネットワークを通過しながら、ゼロ、1つ、またはいくつかのトンネルラベル行があってもよいです。ラベルスタックの使用方法については、[RFC3032]を参照してください。
EXP (3 bits) experimental field, may be used to carry Diffserv classification for tunnel labels.
EXP（3ビット）実験フィールドが、トンネルラベルのDiffservの分類を運ぶために使用されてもよいです。
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ビット）積層ビットは、MPLSスタックの底部を示しています。 PWラベルのすべてのトンネルラベル、S = 1、S = 0。
TTL (8 bits) MPLS Time to live.
TTL（8ビット）生きてMPLS時間。
PW Label (20 bits) This label MUST be a valid MPLS label, and MAY be configured or signaled.
PWラベル（20ビット）このラベルは、有効なMPLSラベルでなければなりません、そして構成またはシグナリングすることができます。
The L2TPv3 header defined in [RFC3931] is prefixed to the TDMoIP data. The packet structure is depicted in Figure 5.
[RFC3931]で定義されたL2TPv3ヘッダがのTDMoIPデータに前置されています。パケット構造は、図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 |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5. TDMoIP Packet Format for L2TPv3
L2TPv3のための図5のTDMoIPパケットフォーマット
Rows 6 through 8 are the L2TPv3 header. Fields not previously described will now be explained.
〜8行6は、L2TPv3ヘッダーです。以前に説明されていないフィールドについて説明します。
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.
プロトコル（8ビット）は、IPプロトコルフィールドです。それは0x73（115）、IANAによってL2TPに割り当てられたユーザポート番号に設定されなければなりません。
Session ID (32 bits) is the locally significant L2TP session identifier, and contains the PW label. The value 0 is reserved.
セッションID（32ビット）は、ローカルで有効なL2TPセッション識別子であり、PWラベルを含んでいます。値0は予約されています。
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.
クッキー（32または64ビット）が期待PWと、受信フレームの関連を検証するために使用することができ、ランダムに選択された値を含むオプションのフィールドです。
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.
メトロ・イーサネット・フォーラムの実装合意書8 [MEF8]は、Ethernetネットワーク上でTDMを輸送するための構造に依存しないと構造を意識したメカニズムについて説明します。本明細書に記載されるような構造で示したのTDMoIPの実装は、MEF 8節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.
TDMoIPのペイロードはイーサネット宛先および送信元MACアドレス、VLANオプションヘッダ、およびイーサタイプを付ける、及び4バイトのフレームチェックシーケンスを接尾辞を付けることによって、イーサネットフレーム内にカプセル化されています。 TDMoIP実装は、業界標準（DIX）イーサネットおよびIEEE 802.3 [IEEE802.3]フレームの両方を受信し、イーサネットフレームを送信すべきことができなければなりません。
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.
イーサネットカプセル化は、最小値と最大値の両方のパケットサイズに制限が導入されました。全体のTDMoIPパケットが64バイト未満であるときはいつでも、パディングが導入され、真の長さは、制御ワードの長さフィールドを使用することによって示されます。断片化を回避するために、のTDMoIPパケットの最大ペイロードサイズに制限しなければなりません。例えば、パケット当たり30台のPDUとAAL1形式のペイロードのUDP / IPカプセル化イーサネットペイロードの長さが1500バイトのペイロードサイズを許容最大下回る1472バイトです。
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:
イーサネットフレームは、IPまたはMPLS層を介在せずにTDMoIPの輸送のために使用することができるが、MPLS-スタイルラベルは常に存在しなければなりません。この4バイトのヘッダS = 1であり、他のすべての非標識ビットは（PSN-バウンド方向にゼロに設定され、TDM結合方向に無視）予約されています。イーサタイプは、イーサタイプMPLSの、0x88D8（35032）、IEEEによってこの目的のために割り当てられた値に設定する必要がありますが、0x8847（34887）に設定されてもよいです。次のように全体的なフレーム構造は次のとおりです。
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
イーサネットについては、図6のTDMoIPパケットフォーマット
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.
〜6行1（DIX）イーサネットヘッダです。 802.3のために[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].
宛先MACアドレス（48ビット）は、パケットを受信することで、単一の駅のグローバル一意のアドレスです。フォーマットは、[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].
送信元MACアドレス（48ビット）は、パケットを発信駅のグローバル一意のアドレスです。フォーマットは、[IEEE802.3]で定義されています。
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イーサタイプ（16ビット）この位置では0x8100 [IEEE802.1Q]で指定されたオプションのVLANタグが使用されることを示し、次の2つのバイトはVLP、C、およびVLAN IDフィールドが含まれていること。 VLANタグを積層してもよく、その場合、VLAN IDを次の2バイトのフィールドは再びVLANイーサタイプです。
VLP (3 bits) is the VLAN priority, see [IEEE802.1Q].
VLP（3ビット）、[IEEE802.1Q]参照VLAN優先度です。
C (1 bit) the "canonical format indicator" being set, indicates that route descriptors appear; see [IEEE802.1Q].
C（1ビット）、「カノニカルフォーマットインジケータ」が設定されているが、ルート記述子が表示されていることを示しています。 [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ビット）のVLAN識別子が一意にフレームが属するVLANを識別する。ゼロの場合は、唯一のVLP情報は有意義です。値1とFFFが予約されています。他の4093個の値が有効なVLAN識別子です。
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).
IEEEによって割り当てられるようにイーサタイプ（16ビット）は、プロトコル識別子です。イーサタイプが0x88D8（35032）に設定する必要がありますが、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ラベル（20ビット）このラベルが手動で設定しなければなりません。この行の残りの部分は、MPLSラベルに類似するようにフォーマットされます。
Frame Check Sequence (32 bits) is a Cyclic Redundancy Check (CRC) error detection field, calculated per [IEEE802.3].
フレームチェックシーケンス（32ビット）[IEEE802.3]毎に算出巡回冗長検査（CRC）エラー検出フィールド、です。
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.
第3の端部に論じたように、のTDMoIPは、最初のストリームからバイトを抽出し、これらのバイトを適合させることにより、リアルタイムのストリームを搬送します。 TDMoIPのは、二つの異なる適応アルゴリズム、一定のレートリアルタイムトラフィックのための1、および可変レートリアルタイムトラフィックのための1つを提供しています。
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".
すべてのチャネルでの非構造化TDM、または構造化されたが、チャネライズドTDM、または構造化されたチャネル化TDMアクティブすべての時間のために、一定のレートの適応が必要とされています。このような場合のTDMoIPは、ネイティブTDM回路をエミュレートするために、構造表示を使用し、適応は、「回線エミュレーション」として知られています。しかし、（電話用語で「ループ」に対応）は、個々のチャネルが頻繁に不活性である、請求チャTDMため、帯域幅が唯一の活性チャネルを輸送することによって保存することができます。これは、のTDMoIPは個々のループをエミュレートするために構造再アセンブリを使用するための可変レート実時間トラフィックをもたらし、適応は「ループエミュレーション」として知られています。
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.
可変レートAAL2 [AAL2]はループエミュレーションのために使用されている間のTDMoIPは、回線エミュレーションのための一定速度AAL1 [AAL1、CES]を使用します。 AAL1モードはチャネライズドデータの構造化された輸送のために使用しなければならなくて、比較的一定の用途に回路に使用されるべきです。 TDM結合IWFが高いタイミング精度を維持するために必要とされる場合以外に、AAL1を使用しなければならない（例えば、そのタイミングをさらに分散される場合）と高い信頼性が要求されるときに使用されるべきです。帯域幅を保存する必要があり、音声を運ぶチャネルの使用は非常に可変であることが予想されるときはいつでも使用可能な場合は、AAL2チャネル化TDMのために使用されるべきです。
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.
また、第三のモードは、ハイレベルデータリンク制御（HDLC）の効率的な輸送のために特別にTDMチャネルで運ばれる共通線信号（CCS）をベースに定義されます。
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.
プロトコルのAALファミリは、TDMエミュレーションのための自然な選択です。元々ATMの剛性フォーマットにアプリケーション・各種データを適合させるために開発されているが、メカニズムは、パケットネットワークを介して一定または可変レート実時間ストリームを輸送する問題に対する一般的な解決策です。
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.
AALメカニズムが広範囲内および公衆電話システムの縁上に配備されているので、それらは確実に音声グレード・チャネル、データ及び電話シグナリングを転送することが実証されています。これらのメカニズムは、成熟した、よく理解され、かつ実装が容易に入手可能です。
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.
最後に、レガシーネットワークと単純化されたサービスインターワーキングは、のTDMoIPの主要な設計目標です。再利用AALテクノロジの既存のAAL1-とAAL2ベースのネットワークとのインターワーキングを簡素化します。
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.
チャネル割り当てが静的であるためチャネライズドTDM、またはチャネル化TDMの優勢なケースでは、ペイロードは、効率的に定速度AAL1適応を使用して符号化することができます。 AAL1フォーマットは[AAL1]及び[CES]にATM上の回線エミュレーションのための使用に記載されています。私たちは、簡単に私たちはのTDMoIPの文脈におけるAAL1の使用を記載している。このセクションでは付録BにAAL1技術のハイライトを確認します。
+-------------+----------------+
|control word | AAL1 PDU |
+-------------+----------------+
Figure 7a. Single AAL1 PDU per TDMoIP Packet
図7a。 TDMoIPパケットあたりのシングルAAL1のPDU
+-------------+----------------+ +----------------+
|control word | AAL1 PDU |---| AAL1 PDU |
+-------------+----------------+ +----------------+
Figure 7b. Multiple AAL1 PDUs per TDMoIP Packet
図7b。 TDMoIPパケットごとに複数のAAL1のPDU
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モードでのTDMoIPペイロードは、少なくとも1つ、おそらくは多く、48バイト「AAL1 PDUの」から成る、図7Aおよび7Bを参照します。 PDUの数は、事前に設定しなければならなくて、全体的なパケットサイズは、PSN（イーサネット上のUDP / IPのための例えば、30）によって許可された最大値を超えないように選択されなければなりません。パケットあたりのPDUの正確な数は、一般的に考慮しての遅延と帯域幅の制約を選択されています。単一PDUを使用することで、最小限のレイテンシを提供しますが、最高のオーバーヘッドが発生します。全てのTDMoIP実装は、E1およびT1回路にパケットあたり1〜8のPDUをサポートし、E3およびT3回路用パケットあたり5〜15のPDUしなければなりません。
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は、構造に依存しないと構造認識輸送に対応する非構造化および構造化データ転送、区別します。構造に依存しないトランスポートのために、AAL1はのSAToPと比較して何ら固有の利点を提供しません。ただし、その使用が望まれるためシナリオがあってもよいです。例えば、既存のAAL1 ATM回線エミュレーションシステム、または場合AAL1固有のメカニズムに基づいてクロックの回復が促進されると連動する必要があります。
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.
構造認識輸送のために、[CESは、2つのモード、構造およびチャネル連携信号（CAS）と構造を定義します。構造化AAL1はAAL1 PDUヘッダ内の次のフレームの先頭へのポインタを埋め込むことにより、TDMフレーム同期を維持します。同様に、CASで構成AAL1は、次のマルチフレームの先頭へのポインタを埋め込むことにより、TDMフレーム及びマルチフレーム同期を維持します。また、CASで構成AAL1はCASシグナリングビットを含む部分構造を含有します。
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.
AAL1は、フラクショナルE1またはT1回線を搬送するように構成してもよいが、搬送されるチャネルの割り当てが原因AAL1は、一定のレートのビットストリームを搬送するという事実に静的でなければなりません。それは、TDM回路ではないすべてのチャネルが同時にアクティブである場合（「オフフック」）は、多くの場合であり、活動状態はTDMシグナリングチャネルの観察によって決定することができます。また、もアクティブコールの間に、約半分の時間は、音声アクティビティ検出（VAD）を使用して同定することができる沈黙です。可変レートAAL2モードを使用して、我々は、動的従って、帯域幅を節約し、搬送されるチャネルを割り当てることができます。
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.
AAL2フォーマットは、[AAL2]に記載されており、ATM上のループエミュレーションのためのその使用は[SSCS、LES]で説明されています。私たちは、簡単にこのセクションでは、付録C.でAAL2技術のハイライトを確認し、我々は、のTDMoIPの文脈におけるAAL2の使用を記載しています。
+-------------+----------------+ +----------------+
|control word | AAL2 PDU |---| AAL2 PDU |
+-------------+----------------+ +----------------+
Figure 8. Concatenation of AAL2 PDUs in a TDMoIP Packet
TDMoIPパケットにAAL2 PDUの8連結の図
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.
AAL2モードでのTDMoIPペイロードは、一つ以上の可変長「AAL2 PDUの」からなり、図8を参照して各AAL2 PDUは、オーバーヘッドとペイロードの1と64バイトとの間の3つのバイトを含みます。パケットは、特定の時間に準備PDUを付加することにより、又は任意の他の手段によって、すべてのアクティブなチャネルに対応するPDUを挿入することによって構築することができます。したがって、単一チャネルに属する複数のPDUはパケットで表示されてもよいです。
[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]は、ペイロードとしてのその使用前にネイティブサービス処理（NSP）の関数としてTDMデータのすべての処理を意味します。 AAL2は、本質的に可変レートであるため、チャネルはAAL2ループエミュレーションペイロードに配置される前に、任意NSP機能が実行されてもよいです。これらは、オンフック/オフフックの状態、音声アクティビティ検出、音声圧縮、ファックス/モデム/トーンリレーなどのテストを含めます
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.
[AAL2、SSCS、LES]に記載された全てのメカニズムは、のTDMoIPのために使用することができます。 [AAL2]、エンコード[SSCS]で定義されたフォーマット、およびCASの輸送および[LES]に記載されているようにシグナリングCCSによると、特に、チャネル識別子（CID）符号化およびPADオクテットの使用は、すべてに使用されるかもしれPSN-バウンド方向、およびTDM-バウンド方向に支持されなければなりません。オーバーラップ機能とAAL-CUタイマと関連する機能は必要とされないこと、およびSTFは、（フィールドを開始する）は使用されません。エラー検出コードの計算 - すなわち、ヘッダ・エラー・チェック（HEC）AAL2 PDUヘッダおよびCRCにおけるCASパケットには - 適切なエラー検出メカニズムがPSNにより提供された場合に不必要です。このような場合には、これらのフィールドはゼロに設定されてもよいです。
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.
TDMoIPでHDLCを処理するための動機を効率的に輸送することである共通チャネル信号（CCS）などのSS7 [SS7]またはISDN PRIは、[ISDN-PRI]をシグナリング、TDMストリームに埋め込まれました。このメカニズムは、一般的なHDLCペイロードためのもの、およびHDLCメッセージが最大パケットサイズよりも常に短くしていることを前提とされていません。
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フォーマットは透過別PW上全てHDLCデータ及び制御メッセージを渡し、ポートモードで動作することが意図されています。カプセル化は[RFC4618]のものと互換性がある、しかし、シーケンス番号生成および処理は、上記のセクション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は、フラグを監視します。フレームの内容を収集し、フレームチェックシーケンス（FCS）がテストされます。 FCSが正しくない場合、フレームは破棄されます。そうでない場合、フレームは、初期または最終フラグの後に送信され、FCSは廃棄されており、ゼロ除去が行われています。 TDMoIP-HDLCフレームを受信したとき、そのFCSを再計算し、元のHDLCフレームが再構成されています。
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データ彼らは、潜在的な影響に対して遅延してはいけませんメッセージ。遅いOAMメッセージングのためのメカニズムは、付録Dで説明されています
+---+ +-----+ +------+ +-----+ +------+ +-----+ +---+
|TDM|->-| |->-|TDMoIP|->-| |->-|TDMoIP|->-| |->-|TDM|
| | |TDM 1| | | | PSN | | | |TDM 2| | |
|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 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.
TDMoIP欠陥処理の動作はTDMネットワーク1を介して、のTDMoIP IWF 1（IWF1）を介して、PSNを介して、のTDMoIP IWF 2（IWF2）を介して、TDMを介してTDMエンドシステム1（ES1）から下流TDMの流れを考慮することによって最もよく理解されていますネットワーク2、TDMエンドシステム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で検出IWF TDMトレイル終端機能として機能し、欠陥が2、またはその逆をネットワークに中継されていない2 TDMネットワーク1とTDMネットワークの間で交換されます。
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自体は、信号の損失を検出します。いずれの場合においても、IWF1直接TDM信号の有効性の欠如を検出したか、または以前の問題を通知された、それは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.
すべてのネットワーク要素によって生成される前方障害の適応症は異なり、欠陥指示のみトレイル終端機能によって生成される逆。トレイル終端シナリオでは、IWF1は、TDMネットワーク1のためのトレイル終端関数として機能し、従ってIWF1直接TDM信号の有効性の欠如を検出した場合、または以前の問題が通知され、それはTDM ES1に向かってTDMのRDIを生成することができます。トレイル拡張シナリオでIWF1はトレイル終端ないので、TDM RDIを生成してはいけません、むしろ、これまで見てきたように、L欠陥フラグをセットします。私たちが見るように、これはトレイル終端であるES2に到達するためにAIS表示の原因となりますし、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 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.
Lフラグが設定されている場合、ペイロードコンテンツの治療のための4つの可能性があります。 IWF1はAISの適切な量（通常、すべての-もの）のデータとペイロードを埋めるためのデフォルトです。 AISは、IWFの前に生成されている場合、これは、受信したTDMデータをコピーすることによって達成することができます。最後から二番目のTDMリンクは失敗し、IWFは、AIS自体を生成する必要がある場合。あるいは、チャネル化TDMの構造認識輸送すると、ワン「は、トランクコンディショニング」のペイロードを満たすべきです。これは、個々のチャネルの「サービスのうち」事前設定されたコードを確定する（「サービスのうち」コードする音声およびデータチャネルの間で異なることができる）を含みます。いくつかのTDMのPWから採取したチャネルは、単一のTDM回路にTDM結合IWFによって結合されたときにトランクコンディショニングを使用しなければなりません。第三の可能性は完全にペイロードを抑制することです。 IWF1はTDM欠陥が軽度または訂正であると考えている場合は最後に、（例えば、マルチフレーム同期、または不正なフレームシンクの検出の初期段階の損失）、それは、ペイロードフィールドに受信したTDMデータを置き、中に指定してもよい（MAY）欠陥修正フィールド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ネットワークにおけるTDMネットワーク2における1となかったことを指定します。
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は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 RDIを送信することによって応答することができるES2に向かってAIS生成を引き起こすTDMネットワーク内にあるときに、第2の場合です。トレイル終端シナリオでは、このRDIは、証跡拡張シナリオで2ネットワークに制限され、IWF2は、有効なTDMデータに挿入され、このRDIを観察する際に、IWF1向かっPSN横切っ返送パケットに「R」フラグを設定することによって、これを示さなければなりません。 IWF1は、この指示を受信すると、このように単一の従来のTDMネットワークをエミュレートする、ES1に向かってRDIを生成します。
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は、この問題のPSNの管理システムに通知し、さらにES2に向けてTDM AISを発生させなければなりません。 ES2はIWF2がRDIを検出した場合、それは「R」フラグ指示を上げる必要があり、トレイル拡張シナリオでは、前述のようにTDM RDIで応答し、そしてよいです。 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を介して送信された場合、永続的欠陥がどちらかで検出された場合に加えて、両方のPWに障害が発生したと考えられます。
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を回収しなければならない、との両方のTDMoIPのIWFは、それぞれのTDMネットワークにAISを（及びコンディショニングをトランクしない）送信開始します。付録Dに記載されるように接続が回復するまでのIWFは、その後、ネイティブ・メソッドまたはのTDMoIP OAMを使用して接続テストに従事する。
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の実装に不可欠な追加的な側面を確認します。
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からのデータは、その変数の到着レートで書き込まれるメモリのブロックであり、データが読み出され、一定速度で先TDM機器に送信されます。ジッタバッファの使用は、部分的にPSNが追加待ち時間を除いて、従来の同期TDMネットワークではなく、トラバースされたという事実を隠し。慣行は、したがって、そのオーバーフローまたはアンダーフローの確率を最小化する、約半分のジッタバッファで動作させることです。従って、付加的な遅延は半分ジッタバッファのサイズに等しいです。ジッタバッファの長さは設定されるべきであり、動的であってもよい（即ち、パケット遅延変動（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.
（まれ）、パケット損失および誤った順序を処理するために、パケットシーケンス完全性機構が提供されなければなりません。このメカニズムは、到着するパケットのシリアル番号を追跡しなければならないし、異常が検出されたときに適切な行動を取る必要があります。パケット（単数または複数）を失った場合、TDMタイミングを維持するために機構MUST出力充填データを検出します。間違った順序で到着したパケットは、並べ替えられるべきです。失われたパケットの処理は、適切なFASは、TDMネットワークに送信されることを確認する必要があります。例えば、シーケンス番号処理アルゴリズムは、付録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タイミングを維持するのに十分かもしれないが、電話トラフィックのためには、途切れ迷惑あるいは不明瞭オーディオもたらすオーディオギャップまたはアーチファクトをもたらし得ます。実装は盲目的に、失われたサンプルの代わりに、事前に設定一定の値を挿入することができ、この値は、知覚の影響を最小限に抑えるように選択する必要があります。また一つは、以前に受信したパケットを再生してもよい（MAY）。計算リソースが利用可能な場合、実装は、知覚誤差を最小にするよう、適切な方法で欠落しているサンプル値を推定することにより、パケット損失イベントを隠すべきです。
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ネットワークは、本質的に同期しています。どこかのネットワークに常に1E-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.
PSN内のパケットは、パケット遅延変動（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つの方法があります。いくつかによって提供されるタイミング情報を第一及び第二の方法ではPSNの独立を意味します。このタイミングは、TDMエンドシステム（方法1）またはのIWF（方法2）に提供されてもよいです。第三の方法では、共通のクロックが両方のIWFに利用可能とし、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.
適応クロック回復は、TDM結合IWFのパケット、又は時間の関数としてのジッタバッファの充填レベルの到着の正確な時刻としてPSNから到着するパケットのみ観察可能な特性を利用します。 PSNのパケット遅延変動に、観察可能な特徴の統計的性質に対処フィルタリング処理を使用しなければなりません。周波数ロックループ（FLL）とフェーズがループ（PLL）は、この作業に適していますロックされました。
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の出力は、ジッタに従わなければならなくて、[G823] [G824]で定義されるように、TDMトラフィックインターフェイスの仕様をさまよいます。一部のアプリケーションでは、より厳しいジッタとワンダ公差が課される可能性があります。
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].
可能な限り、のTDMoIPは、帯域予約および入場制御または転送優先順位付けと境界トラフィック調整機構のいずれかを提供トラフィックエンジニアリングのPSNを横切って実施すべきです。保証型サービス（GS）をサポートするのIntServ対応ドメイン[RFC2212]及び緊急転送（EF）をサポートDiffservの対応ドメイン[RFC2475]、[RFC3246]は、このようなのPSNの例を提供します。そのようなメカニズムは、ある程度まで、隣接するストリーム上のTDMoIPの効果を無効にします。 IPのPSN経由のTDMoIPトラフィックの境界交通調節を容易にするために、のTDMoIPパケットは、デフォルトのホップ単位動作のために予約のDiffservコードポイント（DSCP）値（PHB）[RFC2474]を使用しないでください。
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のは、ベストエフォート型のサービスを提供するPSN上で実行されると、パケット損失は、輻輳を検出するために監視する必要があります。輻輳が検出され、帯域幅の低減が可能である場合、そのような減少が制定されるべきです。帯域幅の削減が可能でない場合、その後のTDMoIP PWは[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.
パケット到着の期待速度が一定と知られているので、AAL1モードのTDMoIPにおいては、本質的にパケット損失測定を提供することができます。
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.
PSNが増加送達を提供する場合2.パケット損失測定の結果は、重度の輻輳の有無を信頼できる指標ではないかもしれません。 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のティアダウン手順を使用すべきです。
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のIWFの一つは十分に長い期間のパケットの送信を停止した場合、そのピア（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は、タイムリーな配送を確保するか、他のサービス品質保証を提供するためのメカニズムを提供していません。したがって、下位層のサービスがそうすることが必要とされます。レイヤ2優先度がVLAN優先度フィールドを使用してのTDMoIPストリームに授与することができ、MPLS優先度がEXPビットを使用することによって提供することができ、およびレイヤ3の優先順位は、TOSを使用することによって制御可能です。 TDMoIPの流れが横断しなければならないスイッチおよびルータは、これらの優先順位を尊重するように構成されるべきです。
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.
必要なときにTDMoIPが強化または基礎PSNのセキュリティ性能を損なわない、むしろそれは、暗号化、整合性、および認証のために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である場合、IPベースのPSNのために、IPsecの[RFC4301]を使用することができるが、PW固有のセキュリティメカニズムは、必要とされ得ます。 L2TPv3を使用してのTDMoIPは、[RFC3931]のセクション8で説明したセキュリティ問題を受けます。
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.
TDMoIP共有スードワイヤ層攻撃の数に対する感受性（[RFC3985]を参照）および実施は、機密性、完全性、および認証のためにどのようなメカニズムを使用すべきである一般のPWのために開発されています。これらのメソッドは、このドキュメントの範囲を超えています。
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上の既知平文攻撃をより困難にします。 PW暗号化は、このドキュメントの範囲を超えています。
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ラベルは、セッションハイジャックを阻止するためにではなく順次にまたは他の方法で予測不可能な方法で選択されるべきです。 L2TPv3の、暗号ランダム[RFC4086]を使用する場合クッキーは、挿入攻撃、ブラインド、オフパスパケット挿入攻撃から保護するために使用されるべきであり、64ビット・クッキーはブルートフォースに対する保護のために推奨されます。
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]を参照）メカニズムが適用されません。
For MPLS PSNs, PW Types for TDMoIP PWs are allocated in [RFC4446].
MPLSのPSNのために、のTDMoIP PWsのためのPWタイプは、[RFC4446]に割り当てられています。
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のPSNため、宛先ポート番号は、0x085E（2142）、のTDMoIPにIANAによって割り当てられたユーザポート番号に設定しなければなりません。
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.
TDM回路のエンドツーエンド遅延は、ネイティブTDM回路のそれを超える可能性のTDMoIPを使用してエミュレートされました。
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のデータが失われます。
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.
PSNのインフラを共有している間、ネイティブTDM接続は、ポイントツーポイントです。したがって、エミュレートされたサービスのセキュリティのレベルは、ネイティブサービスのそれよりも小さくてもよいです。
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.
著者は、ここに記載された技術への貴重な貢献のためヒューゴシルバーマン、シモンHALEVY、Tuviaシーガル、およびRADデータ・コミュニケーションズのエイタン・シュワルツに感謝したいと思います。
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.
説明を簡単にするために、モジュロ演算は、一貫して周期性のアドホック治療の代わりに使用されています。すべてのインデックスとの違いを明示的範囲に変換されている[-2 ^ 15 ... + 2 ^ 15から1]違いの看板の簡単なチェックが正しくパケット到着順序を予測することを確実にします。
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.
我々が明示的に実行オーバーとアンダーランがこのバッファの扱い再生バッファを導入しました。オーバーランパケットは、彼らが再生のために保存することができないので、すぐに到着したときに発生します。これは通常、総タイミングの不正確さや設定ミスの指標である、と私たちはほとんどないが、このような早期のパケットを破棄することができます。アンダーラン輻輳やネットワーク障害から生じ、通常、ネットワーク飢餓のサインです。
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）
In addition, the algorithm requires one parameter:
また、このアルゴリズムは、一つのパラメータが必要です。
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：これは、オプションの再順序付け（注2）のために必要とされる：この数は範囲-2 ^ 15 ... + 2 ^ 15で常に - 1注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 +受信）=予想セット再生バッファ他の廃棄パケットの内容にパケットの内容を配置する他のmod 2 ^ 16（= Dを計算します（期待受信）MOD 2 ^ 16） - 2 ^ 15であればD> 0、次いで{パケットは、予想される予想+ 1、...受信-1は失われている}しばらくしないオーバーラン場所フィラー（すべてのもの又は補間）再生バッファにし、「他の^ 16 =（受信+ 1）のmod 2 {後半にパケットが到着}予想宣言する設定再生バッファ他の廃棄パケットの内容にパケットの内容を「受信」に置く更新しない後半のパケットではない上、実行している場合期待される」パケットを破棄するかのどちらかではないアンダーランその後、L =（（演奏に受信）のmod 2 ^ 16）を計算する場合 - 2 ^ 15の場合を0 <L <= Rは、前に失われた他の廃棄パケット注としてマークされたパケットからデータを交換します：R = 0を選択することによって、私たちはいつも遅れてパケットを破棄します
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.
48バイトのAAL1のPDUの最初のバイトは常にエラー保護さ3ビットのシーケンス番号を含みます。
1 2 3 4 5 6 7 8
+-+-+-+-+-+-+-+-+-----------------------
|C| SN | CRC |P| 47 bytes of payload
+-+-+-+-+-+-+-+-+-----------------------
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.
SN（3ビット）PDUからPDUに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.
容易に推測できるように、シーケンス番号をインクリメントすることの重要性はすぐに明らかになるだろう、8 PDUシーケンス番号サイクルを形成します。
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バイトの構造は、[CES]で定義されたAAL1回路エミュレーションサービスの三種類に対応する、3つあるうちPDUタイプに依存します。これらは、非構造化回路エミュレーション、構造化された回路エミュレーション、および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、E1、T3、E3）の透明な転送のために使用される構造化されていない一つです。構造化されていない輸送のための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 193分の183 T1フレームはそれぞれAAL1 PDUに収まります。 E1フレームは256ビットで構成され、そのため1つの15/32 E1フレームは、各PDUに収まります。
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]に従ってチャネル化されている場合、特にそれがフラクショナルE1またはT1に所望される場合、構造化AAL1回路エミュレーションサービスのいずれかを使用することが有利です。構造化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バイトは、第1のチャネル番号の順に配置されて搬送されます。チャネル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
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
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で使用される特定の方法は、8つのPDUごとに一連番号サイクルポインタを挿入することです。ポインタは7ビットであり、偶数パリティMSB（最上位ビット）で保護され、したがって、単一バイトを占有します。 7ビットが47より大きいオフセットを表現するのに十分であるので、私たちも、シーケンス番号でのPDUへのポインタ・バイトの配置を制限することができます。 47 TDMバイト、ポインタ（P-フォーマットPDU）を含むPDUを含む最もAAL1のPDUとは異なり、以下のフォーマットを有します。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-----------------------
where
どこ
C (1 bit) convergence sublayer indication, C=1 for P-format PDUs.
PフォーマットのPDUのためのC（1ビット）収束サブレイヤ表示、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フォーマットのPDUは、ペイロードの46バイトを有し、次のPDUは、ポインタが93バイトの1つを示すために必要単一のエンティティとして見47バイトを有している。ためP = 0の場合は、構造は、次のバイト（すなわち、ペイロードの最初のバイトが最も低い番号のチャンネルに属する）から始まることが理解されます。 P = 93が第二PDUの最後のバイトが構造の最後のバイトであり、そして次のPDUが新しい構造で開始することを意味します。 = 127特殊値Pは、（非常に大きな構造体が搬送されるときに必要）に示さすべき構造体の境界が存在しないことを示しています。
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は、常に構造境界が生じるシーケンス番号サイクルの最初の可能な位置に配置され、一度だけ、サイクル当たりに発生することができます。
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で構成回路エミュレーションフォーマットおよび構造化回線エミュレーションの間の唯一の違いは、構造の定義です。構造化回線エミュレーションにおける一方の構造は、CASで構成回路エミュレーション構造は、Nチャネルの複数の繰り返し、次いでCASシグナリングビットからなるスーパーフレームを含む、Nチャンネルで構成されています。 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, 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:
例えば、E1回路にCASシグナリングビットは、16のフレームのスーパーフレームごとに一度更新されます。したがって、E1 CASとのシグナリングに由来するN * 64のための構造は、4つのABCDビットのN組、およびNが奇数の場合、最終的に4ゼロ・ビットが続いNバイトの16回の繰り返しからなります。例えば以下のように、チャネル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]
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の場合のシグナリングビットは、一般に、それらの通常の（ビット奪わ）位置及び構造の終わりに、2回表示されます。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+------------
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のために一意でなければならない識別子です。従ってPWあたり248（240）のCIDを残し、（[LES]で指定されるように15を介して8とVoDSLと連動が必要とされる場合、そう値は）値0-7は、特別な目的のために予約されています。チャネルの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ビット）の長さインジケータは、バイト単位でペイロードの長さよりも短いものです。ペイロードは、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は常に範囲0-15になり、モジュロ16をチャネル・バッファが送信されるたびにインクリメントされるべきです。受信機は、このシーケンスを監視することができます。 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.
ペイロード - AAL2パケットにそのまま音声サンプルのLIで示される長さのブロックに音声が配置されています。
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は、CASは、ペイロードをシグナリングするためのシグナリングは、AAL2としてフォーマットされる「完全に保護された」（タイプ3）パケット誤り保護を確実にするために、（[AAL2]参照）。シグナリングは、対応する音声チャネルと同一のCIDを用いて送信されます。 ABCDの状態変化をビット、及び三重冗長で送信されるべきであるときはいつでもシグナリングが送信されなければならない、すなわち、3回離れて5ミリ秒離間送りました。また、シグナリングビットのセット全体は、信頼性を確保するために定期的に送信されるべきです。
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|RED| timestamp |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RES | ABCD | type | 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ビット）三重冗長カウンタです。最初のパケットのために、第01のために、値00を取得し、第10の赤= 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エラー検出コードです。
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 PWを適応タイミング回復およびパケット損失隠蔽アルゴリズムのために、このような情報から利益を得ることができます。また、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のIWFは、ラウンドトリップ時間（RTT）としてPSNパフォーマンス・メトリック、パケット遅延変動（PDV）とパケット損失率（PLR）の知識から利益を得ることができます。これらの測定は、従来、この目的のために設計されたパケットの別個の流れ、例えば、ICMPパケット[RFC792]または複数のタイムスタンプとのMPLS LSP pingパケット[RFC4379]によって実行されます。 AAL1モードの場合、のTDMoIPは、一定の速度でPSNを介してパケットを送信し、したがって追加のOAMフローは、PDV又はPLRの測定のために必要とされません。しかし、別のOAMフローは、RTT測定のための、AAL2モードPWをするために、セットアップでのパラメータの測定のために、非アクティブなバックアップのPW監視のため、およびPWが原因サービスの障害に撤回された後のPSNの低レート監視のために必要とされます。
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のものとよく相関する接続性検証、RTT、PDV、及びPLRの測定値を提供する適切なメンテナンス機構を有する場合、これらのメカニズムが使用されるべきです。そのようなメカニズムが利用できない場合、2つの類似OAMシグナリングメカニズムのいずれかを使用することができます。最初は、PWの内部とインバンドVCCV [RFC5085]に基づいており、そして第二には、UDP / IPのPSNのみ定義され、そして別PWに基づいています。後者は運命共有TDMのPWの多数のために特に効率的です。
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アプリケーションでは、サーバは、クライアントからの明示的な要求の後に、ネットワークを介した情報の一部有限量を送信します。 TDMoIP PWをしてPSN結合IWFはTDM-バインド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.
TDM結合IWFが失敗したか、PSNから切断されている、またはPWが壊れているときのTDMoIP IWFはまず、育てている場合、この問題が発生することがあります。熟成時間の後、宛先IWFは不明となり、中間スイッチは、新しいパスを見つけるための試みでのTDMoIPパケットでネットワークをあふれさせることがあります。
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障害が検出されたときに毎秒送信のTDMoIPパケットの数を減少させるために、及びPWが利用可能である場合にのみ、フルレートに戻すことです。故障と復旧の検出は、一方向の接続検証メッセージの定期的な交換によって可能となります。
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メッセージを送信し、各メッセージの宛先応答を有することによって試験されます。接続性検証メカニズムは、セットアップと構成の際に使用されるべきです。 OAMシグナリングせずに、1は、宛先IWFはそれらを送信するために開始する前に、パケットを受信する準備ができていることを確認する必要があります。 TDMoIPのIWFが全二重で動作するので、両方を設定し、洪水を回避すべきであるならば、適切に同時に設定する必要があります。接続性検証を使用している場合、それは完全なレートで伝送する前に、そのピアを検出するまで、設定さ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).
一方向接続に加えて、OAMシグナル伝達機構を要求するために使用することができ、それらはまた、遠隔診断のために使用することができる等の一方向遅延、往復遅延、パケット遅延変動など、様々なPSNの指標について報告、および潜在的な問題（例えば、喘ぎメッセージを死ぬ）の未承諾報告のため。
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のPSNのための帯域内OAM PWメッセージパケットのフォーマットは、[RFC2679]に基づいています。 PSN-特定の層は、事前構成又はPW OAMのために割り当てられた値に設定PWラベルとセクション4.1で定義されたものと同一です。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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シーケンス番号（16ビット）メッセージを一意に識別するために使用されます。その値は、問題のPWのためのTDMoIPデータパケットのシーケンス番号とは無関係です。これは、クエリメッセージでインクリメント、および応答の変化なしに複製されます。
OAM Msg Type (8 bits) indicates the function of the message. At present the following are defined:
OAMメッセージタイプ（8ビット）は、メッセージの機能を示します。現時点では、以下が定義されています。
0 for one-way connectivity query message
8 for one-way connectivity reply message.
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メッセージコード（8ビット）は、メッセージに関連する情報を搬送するために使用され、その解釈は、メッセージのタイプに依存します。タイプ0（接続クエリー）メッセージについては、次のコードが定義されています。
0 validate connection.
1 do not validate connection
for type 8 (connectivity reply) messages the available codes are:
タイプ8（接続応答）メッセージのために利用可能なコードは、以下のとおりです。
0 acknowledge valid query
1 invalid query (configuration mismatch).
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ビット）のIWFの間で構成情報を交換するために使用することができるフィールドです。それが使用されていない場合、このフィールドはゼロを含まなければなりません。その解釈は、ペイロードタイプによって異なります。現時点では、以下を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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Number of TSs (8 bits) is the number of channels being transported, e.g., 24 for full T1.
TS（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.
SFの数（8ビット）は、例えば、8パケット当たり8つのPDUを充填するとき、パケットあたり48バイトのAAL1 PDUの数です。
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.
（16ビット）PWラベルを逆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.
ソース送信タイムスタンプ（32ビット）PSN結合IWFは、クエリメッセージを送信した時間を表します。遅延が測定されている場合は、このフィールドと、次のものがのみ表示されます。すべての時間単位は、事前に設定周波数のクロックから導出され、デフォルトでは100マイクロ秒です。
Destination Receive Timestamp (32 bits) represents the time the destination IWF received the query message.
宛先は、タイムスタンプ（32ビット）を受信し、宛先IWFがクエリメッセージを受信した時刻を表します。
Destination Transmit Timestamp (32 bits) represents the time the destination IWF transmitted the reply message.
先の送信タイムスタンプ（32ビット）、宛先IWFは、応答メッセージを送信した時間を表します。
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の特定のタイプ、および上記で定義したモードのサブセットをサポートします。次の機能は、管理システムで照会することができるようになります。
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型（E1、T1、E3、T3、フラクショナルE1、フラクショナルT1）
for fractional links: number of 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
パケットあたりのAAL1 PDUの数
for AAL2 mode:
AAL2モード用：
CID mapping
CIDマッピング
creation time of full minicell (units of 125 microsecond)
フルミニセル（125マイクロ秒の単位）の作成時間
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).
（使用する場合：共通のクロックの周波数、PT及びSSRC値）RTPの使用。
During operation, the following statistics and impairment indications SHOULD be collected for each TDM PW, and can be queried by the management system.
動作時には、次の統計及び減損兆候は、各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モードPWを：
indication of malformed PDUs (incorrect CRC, bad C, P or E)
不正なPDUの指示（誤った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モードPWを：
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のために：ジッタバッファと秒数のイベントを実行する上で、
for HDLC mode PWs:
四ITLSはどのようにブッシェル：
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フラグを設定して受信された時の秒数。
References
リファレンス
Normative References
引用規格
[AAL1] ITU-T Recommendation I.363.1 (08/96) - B-ISDN ATM Adaptation Layer (AAL) specification: Type 1
[AAL1] ITU-T勧告I.363.1（08/96） - B-ISDN ATMアダプテーションレイヤ（AAL）仕様：タイプ1
[AAL2] ITU-T Recommendation I.363.2 (11/00) - B-ISDN ATM Adaptation Layer (AAL) specification: Type 2
【AAL2] ITU-T勧告I. 363.2（11/00） - B-ISDN ATMアダプテーションレイヤ（AAL）仕様：タイプ2
[CES] ATM forum specification atm-vtoa-0078 (CES 2.0) Circuit Emulation Service Interoperability Specification Ver. 2.0
【CES】ATMフォーラム仕様ATM-VTOA-0078（CES 2.0）回線エミュレーションサービスの相互運用性仕様Ver。 2.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勧告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勧告G.751（88分の11） - 34368キロビット/秒の三次ビットレート及び139264キロビット/秒の四次ビットレートで動作し、正の正当化を使用してデジタル多重機器
[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勧告G.823（03/00） - 2048キロビット/秒の階層に基づいて、ジッタの制御とデジタルネットワーク内でワンダは
[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勧告G.824（03/00） - 1544キロビット/秒の階層に基づいて、ジッタの制御とデジタルネットワーク内でワンダは
[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勧告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)
[IEEE802.3] IEEE 802.3、IEEE標準ローカルおよびメトロポリタンエリアネットワーク - 衝突検出（CSMA / CD）アクセス方法および物理層仕様（2002）搬送波感知多重アクセス
[LES] ATM forum specification atm-vmoa-0145 (LES) Voice and Multimedia over ATM - Loop Emulation Service Using AAL2
AAL2を使用してループエミュレーションサービス - ATMを超える[LES] ATMフォーラム仕様ATM-vmoa-0145（LES）の音声およびマルチメディア
[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）"、STD 6、RFC 768、1980年8月。
[RFC791] Postel, J., "Internet Protocol (IP)", STD 5, RFC 791, September 1981.
[RFC791]ポステル、J.、 "インターネット・プロトコル（IP）"、STD 5、RFC 791、1981年9月。
[RFC2119] Bradner, S., "Key Words in RFCs to Indicate Requirement Levels", RFC 2119, March 1997.
[RFC2119]ブラドナーの、S.、 "要件レベルを示すために、RFCの中のキーワード"、RFC 2119、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ラベルスタックエンコーディング"、RFC 3032、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の）"、RFC 3931、2005年3月。
[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：リアルタイムアプリケーションのためのトランスポートプロトコル"、STD 64、RFC 3550、2003年7月。
[RFC4446] Martini, L., "IANA Allocations for Pseudowire Edge to Edge Emulation (PWE3)", BCP 116, RFC 4446, April 2006.
[RFC4446]マティーニ、L.、BCP 116、RFC 4446、2006年4月 "エッジエミュレーションに擬似回線縁（PWE3）のためのIANAの割り当て"。
[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.サギ、 "ラベル配布プロトコル（LDP）を使用して、擬似回線の設定とメンテナンス"、RFC 4447、2006年4月マティーニ。
[RFC4553] Vainshtein A., and Stein YJ., "Structure-Agnostic TDM over Packet (SAToP)", RFC 4553, June 2006.
[RFC4553] VainshteinのA.、およびスタインYJ。、 "パケット（のSAToP）の上に構造 - 不可知論者TDM"、RFC 4553、2006年6月。
[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）の輸送のためのカプセル化方法"、RFC 4618、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の仮想回線接続性検証：スードワイヤための制御チャネル"。。、RFC 5085、2007年12月。
[SSCS] ITU-T Recommendation I.366.2 (11/00) - AAL type 2 service specific convergence sublayer for narrow-band services.
【SSCS] ITU-T勧告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勧告Y.1413（03/04） - TDM-MPLSネットワークインターワーキング - ユーザプレーンインターワーキング
[Y1414] ITU-T Recommendation Y.1414 (07/04) - Voice services - MPLS network interworking.
[Y1414] ITU-T勧告Y.1414（07/04） - 音声サービス - MPLSネットワークのインターワーキング。
[Y1452] ITU-T Recommendation Y.1452 (03/06) - Voice trunking over IP networks.
[Y1452] ITU-T勧告Y.1452（03/06） - IPネットワーク上の音声トランク。
[Y1453] ITU-T Recommendation Y.1453 (03/06) - TDM-IP interworking - User plane interworking.
[Y1453] ITU-T勧告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勧告Q.931（05/98） - 基本的な呼制御のためのISDNユーザ・網インタフェースレイヤ3仕様。
[RFC792] Postel J., "Internet Control Message Protocol", STD 5, RFC 792, September 1981.
[RFC792]ポステルJ.、 "インターネット制御メッセージプロトコル"、STD 5、RFC 792、1981年9月。
[RFC2212] Shenker, S., Partridge, C., and R. Guerin, "Specification of Guaranteed Quality of Service", RFC 2212, September 1997.
[RFC2212] Shenker、S.、ヤマウズラ、C.、およびR.ゲラン、 "保証されたサービスの質の仕様"、RFC 2212、1997年9月。
[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パフォーマンス・メトリックのための枠組み"、RFC 2330、1998年5月。
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998.
[RFC2460]デアリング、S.とR. Hindenと、 "インターネットプロトコルバージョン6（IPv6）の仕様"、RFC 2460、1998年12月。
[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分野）の定義"、RFC 2474、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.ワイス、 "差別化サービスのためのアーキテクチャ"、RFC 2475、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の遅延メトリック"、RFC 2679、1999年9月。
[RFC2914] Floyd, S., "Congestion Control Principles", BCP 41, RFC 2914, September 2000.
[RFC2914]フロイド、S.、 "輻輳制御の原理"、BCP 41、RFC 2914、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.、Charny、A.、ベネット、JC、ベンソン、K.、ルBoudec、J.、コートニー、W.、Davari、S.、Firoiu、V.、およびD. Stiliadis、「アン緊急転送PHB（ホップ単位動作）」、RFC 3246、2002年3月。
[RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. Norrman, "The Secure Real-time Transport Protocol (SRTP)", RFC 3711, March 2004.
[RFC3711] Baugher、M.、マグリュー、D.、Naslund、M.、カララ、E.、およびK. Norrman、 "セキュアリアルタイム転送プロトコル（SRTP）"、RFC 3711、2004年3月。
[RFC3985] Bryant, S. and P. Pate, "Pseudo Wire Emulation Edge-to-Edge (PWE3) Architecture", RFC 3985, March 2005.
[RFC3985]ブライアント、S.とP.パテ、 "疑似ワイヤーエミュレーション端から端まで（PWE3）アーキテクチャ"、RFC 3985、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.クロッカー、 "セキュリティのためのランダム要件"、BCP 106、RFC 4086、2005年6月。
[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.、RFC 4197、2005年10月、「パケット交換網の上に時分割多重（TDM）回路の端から端までエミュレーションのための要件」。
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005.
[RFC4301]ケント、S.とK. Seo、 "インターネットプロトコルのためのセキュリティアーキテクチャ"、RFC 4301、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.、2006年2月、RFC 4379 "を検出マルチプロトコルラベルは（MPLS）データプレーン障害をスイッチ"。
[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.、ツバメ、G.、マティーニ、L.、およびD.マクファーソン、 "MPLS PSNの上の使用のための擬似回線エミュレーションエッジツーエッジ（PWE3）制御ワード"、RFC 4385、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.編、Sasson、I.、メッツ、E.、フロスト、T.、およびP.パテ、「構造-Awareの時分割多重（TDM）回線エミュレーションサービスパケットネットワーク（のCESoPSNをスイッチの上に）」、RFC 5086、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信号システム第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-CONTROL] Vainshtein、A.およびY（J）スタイン、 "制御プロトコルの拡張MPLSネットワークにおけるTDMスードワイヤのセットアップについて"、進歩、2007年11月に作業。
[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] GSM 08.60（10/01） - デジタルセルラー通信システム（フェーズ2+）;強化されたフル・レート（EFR）とフルレートトラフィックチャネル用のリモートトランスコーダおよびレートアダプタのインバンド制御。
Authors' Addresses
著者のアドレス
Yaakov (Jonathan) Stein RAD Data Communications 24 Raoul Wallenberg St., Bldg C Tel Aviv 69719 ISRAEL
Yaakovの（ジョナサン）スタインRADデータ・コミュニケーションズ24ラウル・ワレンバーグセント、ビルCテルアビブ69719イスラエル
Phone: +972 3 645-5389 EMail: yaakov_s@rad.com
電話番号：+972 3 645-5389 Eメール：yaakov_s@rad.com
Ronen Shashoua RAD Data Communications 24 Raoul Wallenberg St., Bldg C Tel Aviv 69719 ISRAEL
Ronen氏Shashoua RADデータ・コミュニケーションズ24ラウル・ワレンバーグセント、ビルCテルアビブ69719イスラエル
Phone: +972 3 645-5447 EMail: ronen_s@rad.com
電話番号：+972 3 645-5447 Eメール：ronen_s@rad.com
Ron Insler RAD Data Communications 24 Raoul Wallenberg St., Bldg C Tel Aviv 69719 ISRAEL
ロンInsler RADデータ・コミュニケーションズ24ラウル・ワレンバーグセント、ビルCテルアビブ69719イスラエル
Phone: +972 3 645-5445 EMail: ron_i@rad.com
電話番号：+972 3 645-5445 Eメール：ron_i@rad.com
Motty (Mordechai) Anavi RAD Data Communications 900 Corporate Drive Mahwah, NJ 07430 USA
Motty（モルデハイ）Anavi RADデータ・コミュニケーションズ900コーポレート・ドライブマーワー、NJ 07430 USA
Phone: +1 201 529-1100 Ext. 213 EMail: motty@radusa.com
電話：+1 201 529-1100内線。 213 Eメール：motty@radusa.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2007).
著作権（C）IETFトラスト（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.
この文書では、BCP 78に含まれる権利と許可と制限の適用を受けており、その中の記載を除いて、作者は彼らのすべての権利を保有します。
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.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットSOCIETY、（もしあれば）を後援し、IETF TRUST ANDインターネットエンジニアリングタスクフォース放棄ALLに設けられています。保証は、明示または黙示、この情報の利用および特定目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証がこれらに限定されません。
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は、本書またはそのような権限下で、ライセンスがたりないかもしれない程度に記載された技術の実装や使用に関係すると主張される可能性があります任意の知的財産権やその他の権利の有効性または範囲に関していかなる位置を取りません利用可能です。またそれは、それがどのような権利を確認する独自の取り組みを行ったことを示すものでもありません。 RFC文書の権利に関する手続きの情報は、BCP 78およびBCP 79に記載されています。
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リポジトリから。
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に情報を記述してください。