[要約] RFC 5087は、TDMoIP（IP上の時分割多重）に関する標準化ドキュメントであり、TDM信号をIPネットワーク上で伝送するためのプロトコルを定義しています。目的は、既存のTDMベースの通信システムをIPネットワークに統合することで、効率的な通信とネットワークの柔軟性を実現することです。
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)
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）を介した時間分割多重化は、Pseudowires（PWS）を使用して、マルチプレックス（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回路と呼ばれることが多い）の上に運ばれます。パケット切り替えネットワーク（PSNS）の急増により、PSNインフラストラクチャを介したTDMサービスの輸送が望ましいものになりました。PWE3アーキテクチャ[RFC3985]に記載されているように、PSN上のTDM回路のエミュレーションは、Pseudowires（PWS）を使用して実行できます。このエミュレーションは、ネイティブ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.
PSNSを介してTDMを輸送するための構造と存在するTDM上のパケット（SATOP）[RFC4553]は、構造と存在するプロトコルです。現在のドキュメントでは、TDMトランスポートの構造認識方法であるIP（TDMOIP）を介して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）プロトコルは、IPv4またはIPv6またはMPLSのUDP、Layer 2 Tunneling Protocolバージョン3（L2TPV3）、IP、および純粋なイーサネットを含むいくつかのタイプのPSNで動作する場合があります。特定のPSNSの実装の詳細については、セクション4で説明します。プロトコルはより一般的にはTDMOPWと呼ばれる必要がありますが、その特定の実装TDMOIP、TDMOLLSなど。
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をカプセル化し、PSNにパケットを注入するIWFはPSNバウンドインターワーキング関数と呼ばれ、パケットからTDMデータを抽出し、TDMネットワーク上でトラフィックを生成するIWFはTDMバウンドインターワーキング関数と呼ばれます。エミュレートされたTDM回路は、常にポイントツーポイント、双方向、および両方向で同じ速度でTDMを輸送します。
As with all PWs, TDMoIP PWs may be manually configured or set up using the PWE3 control protocol [RFC4447]. Extensions to the PWE3 control protocol required specifically for setup and maintenance of TDMoIP pseudowires are described in [TDM-CONTROL].
すべてのPWSと同様に、TDMOIP PWSは、PWE3コントロールプロトコル[RFC4447]を使用して手動で構成またはセットアップされる場合があります。PWE3制御プロトコルへの拡張は、TDMOIPプソイドワイヤのセットアップとメンテナンスに特に必要です。
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].
「必須」、「そうしない」、「必須」、「shall」、「shall "、" ingle "、" should "、" not "、" becommended "、" bay "、および「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回路は任意のビットストリームを運ぶために使用できますが、「構造」と呼ばれる一定の長さのデータブロックを運ぶための標準化された方法があります。おなじみの構造は、それぞれ長さ193および256ビットのT1またはE1フレーム[G704]です。連続したT1またはE1フレームの連結により、スーパーフレームまたはマルチフェームと呼ばれるより高いレベルの構造を構築できます。T3およびE3フレーム[G704] [G751]はT1およびE1のフレームよりもはるかに大きく、[TRAU]で説明されているGSM ABISチャネルでさらに大きな構造が使用されています。TDM構造には、TDMデータと構造間頭部が含まれています。たとえば、193ビットT1フレームには、単一のビットの構造オーバーヘッドと24バイトのデータが含まれていますが、32バイトE1フレームにはオーバーヘッドのバイトと31のデータバイトが含まれています。
Structured TDM circuits are frequently used to transport multiplexed channels. A single byte in the TDM frame (called a timeslot) is allocated to each channel. A frame of a channelized T1 carries 24 byte-sized channels, while an E1 frame consists of 31 channels. Since TDM frames are sent 8000 times per second, a single byte-sized channel carries 64 kbps.
構造化されたTDM回路は、多重化されたチャネルの輸送に頻繁に使用されます。TDMフレームの単一バイト（タイムスロットと呼ばれる）が各チャネルに割り当てられます。チャネル化されたT1のフレームは24バイトサイズのチャネルを搭載し、E1フレームは31チャネルで構成されています。TDMフレームは毎秒8000回送信されるため、単一のバイトサイズのチャネルには64 kbpsが含まれます。
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）と呼ばれる簡単に検出可能な周期ビットパターンを配置することにより、普遍的に区切られています。構造オーバーヘッドには、エラー監視と欠陥の適応症がさらに含まれる場合があります。「構造化されたTDM」という用語を使用して、FAによって課されるあらゆるレベルの構造を持つTDMを参照します。非構造化されたTDMは、構造が課されていないビットストリームを意味し、すべてのビットがユーザーデータに使用できることを意味します。
SAToP [RFC4553] is a structure-agnostic protocol for transporting TDM using PWs. SAToP treats the TDM input as an arbitrary bit-stream, completely disregarding any structure that may exist in the TDM bit-stream. Hence, SAToP is ideal for transport of truly unstructured TDM, but is also suitable for transport of structured TDM when there is no need to protect structure integrity nor interpret or manipulate individual channels during transport. In particular, SAToP is the technique of choice for PSNs with negligible packet loss, and for applications that do not require discrimination between channels nor intervention in TDM signaling.
SATOP [RFC4553]は、PWSを使用してTDMを輸送するための構造に依存しないプロトコルです。SATOPは、TDM入力を任意のビットストリームとして扱い、TDMビットストリームに存在する可能性のある構造を完全に無視します。したがって、SATOPは真に構造化されていないTDMの輸送に理想的ですが、構造の完全性を保護したり、輸送中に個々のチャネルを解釈または操作する必要がない場合は、構造化されたTDMの輸送にも適しています。特に、SATOPは、無視できるパケット損失を伴うPSNS、およびチャネル間の差別やTDMシグナル伝達の介入を必要としないアプリケーションに最適な手法です。
As described in [RFC4553], when a single SAToP packet is lost, an "all ones" pattern is played out to the TDM interface. This pattern 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パケットが失われると、TDMインターフェイスに「すべてのもの」パターンが再生されます。このパターンは、TDMエンド機器によってアラーム表示信号（AIS）として解釈されます。これは、TDM標準[G826]によれば、すぐに「ひどく誤った2番目の」イベントをトリガーします。そのようなイベントは非常に望ましくないと考えられているため、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構造を明示的に保護することができ、パケット損失イベントを効果的に隠すことができます。構造認識輸送は、少なくともある程度のTDM構造を活用して、パケット損失または他のPSNの欠点に対する堅牢性を高めます。構造を認識しているTDM PWは、PSNを横切って構造を輸送するために必要はありません。特に、FAはPSNバウンドIWFによって剥がされ、TDMバウンドIWFによって再生される必要があります。ただし、FA以外の情報が含まれている可能性があるため、構造のオーバーヘッドは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つの方法すべてには利点があります。構造ロックは[RFC5086]で説明されていますが、現在の文書では、構造指定（セクション5.1を参照）と構造制度（セクション5.2を参照）の両方のアプローチの両方を指定しています。構造指定は、チャネルが静的に割り当てられている場合、および/または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.
適切なTDM展開には、運用、管理、およびメンテナンス（OAM）メカニズムが不可欠です。前述のように、構造認識メカニズムは、PSN全体で構造のオーバーヘッドを輸送することを控え、OAM機能を破壊する可能性があります。2つのOAMケース、「トレイル終了」と「トレイル拡張」シナリオを区別することは有益です。トレイルは、データと関連するOAM情報転送の組み合わせであると定義されています。TDMトレイルが終了すると、エラー監視や欠陥の表示などのOAM情報はPSNを介して輸送されず、TDMネットワークは別々のOAMドメインとして機能します。トレイル拡張ケースでは、OAM情報をPSNに転送します（必ずしもネイティブ形式ではありませんが）。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イーサネットのヘッダーであり、PSNバウンドIWFからTDMバウンド用にパケットを転送するために必要なすべての情報を含んでいます。PSNは、必要なTDMデータの輸送を可能にするのに十分な信頼性があり、十分な帯域幅であると想定されています。
A TDMoIP IWF may simultaneously support multiple TDM PWs, and the TDMoIP IWF MUST maintain context information for each TDM PW. Distinct PWs are differentiated based on PW labels, which are carried in the PSN-specific layers. Since TDM is inherently bidirectional, the association of two PWs in opposite directions is required. The PW labels of the two directions MAY take different values.
TDMOIP IWFは複数のTDM PWSを同時にサポートする場合があり、TDMOIP IWFは各TDM PWのコンテキスト情報を維持する必要があります。個別のPWは、PSN固有のレイヤーで運ばれるPWラベルに基づいて区別されます。TDMは本質的に双方向であるため、反対方向の2つのPWの関連が必要です。2つの方向のPWラベルは、異なる値をとる場合があります。
In addition to the aforementioned headers, an OPTIONAL 12-byte RTP header may appear in order to enable explicit transfer of timing information. This usage is a purely formal reuse of the header format of [RFC3550]. RTP mechanisms, such as header extensions, contributing source (CSRC) list, padding, RTP Control Protocol (RTCP), RTP header compression, Secure RTP (SRTP), etc., are not applicable.
前述のヘッダーに加えて、タイミング情報の明示的な転送を可能にするために、オプションの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、P（パディング）、X（ヘッダー拡張）、CC（CSRCカウント）、およびRTPヘッダーのM（マーカー）フィールドに設定する必要があります。値は、動的値の範囲から割り当てる必要があります。RTPシーケンス番号は、TDMOIPコントロールワードのシーケンス番号と同一でなければなりません（以下を参照）。RTPタイムスタンプは、[RFC3550]で確立されたルールに従って生成する必要があります。クロック周波数は8 kHzの整数倍でなければならず、適切な標準に準拠するタイミング回復を可能にするために選択する必要があります（セクション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
図2. TDMOIPコントロールワードの構造
RES (4 bits) The first nibble of the control word MUST be set to zero when the PSN is MPLS, in order to ensure that the packet does not alias an IP packet when forwarding devices perform deep packet inspection. For PSNs other than MPLS, the first nibble MAY be set to zero; however, in earlier versions of TDMoIP this field contained a format identifier that was optionally used to specify the payload format.
RES（4ビット）PSNがMPLSである場合、コントロールワードの最初のニブルはゼロに設定する必要があります。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.
l局所障害（1ビット）Lフラグは、IWFが転送されるTDMデータに影響を与えるTDM物理層障害を検出または通知されたときに設定されます。「Trail Extended」OAMシナリオでは、IWFが信号の損失、フレーム同期の損失、またはAISを検出したときに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.
Rリモート障害（1ビット）Rフラグは、IWFが検出または通知されたときに設定されます。TDMデータはリモートTDMネットワークから受信されておらず、双方向接続の逆方向の障害を示します。IWFは、Rフラグの表示を受け取ったときにTDMリモート欠陥インジケーター（RDI）を生成する必要があります。「トレイル拡張」OAMシナリオでは、IWFがRDIを検出したときにRフラグを設定する必要があります。Rフラグの使用については、セクション6でさらに説明します。
M Defect Modifier (2 bits) Use of the M field is optional; when used, it supplements the meaning of the L flag.
M欠陥修飾子（2ビット）Mフィールドの使用はオプションです。使用すると、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は、アラームをトリガーしないIDLE TDMデータを示します。ペイロードが抑制されている場合、EgressでPRECOUNONFIGURED IDLEコードを生成する必要があります。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ビット）は、PSNの最小送信ユニット要件を満たすためにパディングが使用された場合に備えて、TDMOIPパケットの長さ（コントロールワードとペイロード）を示すために使用されます。合計パケット長（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シーケンス関数を提供し、紛失および誤ったパケットの検出を可能にします。シーケンス番号スペースは、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 PWSは、UDP/IP（IPv4とIPv6の両方）、IP（介在するUDPなし）、MPLS、およびLayer-2イーサネットを介したL2TPV3を含むさまざまな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 PSNSの場合、形式は[Y1413]および[Y1414]で指定されたものと一致します。UDP/IP PSNSの場合、形式は[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 PSNSのTDMOIPの実装は、Y.1453サブクラース9.2.2またはY.1452句に準拠するように設計された実装と相互運用します。
For UDP/IPv4, the headers as described in [RFC768] and [RFC791] are prefixed to the TDMoIP data. The format is similar for UDP/IPv6, except the IP header described in [RFC2460] is used. The TDMoIP packet structure is depicted in Figure 3.
UDP/IPv4の場合、[RFC768]および[RFC791]に記載されているヘッダーは、TDMOIPデータの前に付けられています。[RFC2460]で説明されているIPヘッダーが使用されることを除いて、Formatは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
図3. UDP/IPの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ヘッダーで、6行目と7行目はUDPヘッダーです。行8〜10はオプションのRTPヘッダーです。行11はTDMOIPコントロールワードです。
IPVER (4 bits) is the IP version number, e.g., IPVER=4 for IPv4.
IPVer（4ビット）はIPバージョン番号です。たとえば、IPv4の場合はIPver = 4です。
IHL (4 bits) is the length in 32-bit words of the IP header, IHL=5.
IHL（4ビット）は、IPヘッダーの32ビット語の長さ、IHL = 5です。
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.
フラグメントオフセット（13ビット）は、データグラムのどこにフラグメントが属し、TDMOIPには使用されていないことを示します。
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.
UDPを意味するには、プロトコル（8ビット）を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をマルチプレックスおよび非難することができます。Architectally [RFC3985]、これによりUDPポートがPWラベルとして機能します。PWエンドポイントは、ソースUDPまたは宛先UDPポートのいずれかをPWラベルとして使用することに同意する必要があります。
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ポート番号（0xc000〜0xffff）の範囲内である必要があります。
While many UDP-based protocols are able to traverse middleboxes without dire consequences, the use of UDP ports as PW labels makes middlebox traversal more difficult. Hence, it is NOT RECOMMENDED to use UDP-based PWs where port-translating middleboxes are present between PW endpoints.
多くのUDPベースのプロトコルは、悲惨な結果なしにミドルボックスを通過することができますが、PWラベルとしてUDPポートを使用すると、ミドルボックスの移動がより困難になります。したがって、PWエンドポイントの間にポート翻訳ミドルボックスが存在するUDPベースのPWSを使用することはお勧めしません。
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 PSNSの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
図4. MPLSの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ヘッダーです。3番目は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ネットワークを介してTDMパケットをトンネルするために使用されるMPLS LSPを識別する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スタックボトムを示します。すべてのトンネルラベルでS = 0、PWラベルではS = 1。
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
図5. L2TPV3のTDMOIPパケット形式
Rows 6 through 8 are the L2TPv3 header. Fields not previously described will now be explained.
行6から8は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プロトコルフィールドです。IANAによってL2TPに割り当てられたユーザーポート番号である0x73（115）に設定する必要があります。
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.
Cookie（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]は、イーサネットネットワークを介して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ヘッダー、およびEtherTypeをプレフィックスすることにより、イーサネットフレームにカプセル化され、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カプセル化のイーサネットペイロードの長さは1472バイトであり、1500バイトの最大許容ペイロードサイズを下回ります。
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バウンド方向で無視されます）。EtherTypeは、IEEEによってこの目的のために割り当てられた値0x88D8（35032）に設定する必要がありますが、MPLSの倫理である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.
行1〜6は（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 EtherType（16ビット）0x8100は、[IEEE802.1Q]で指定されたオプションのVLANタグ付けが使用され、次の2バイトにVLP、C、およびVLAN IDフィールドが含まれていることを示しています。VLANタグは積み重ねられる場合があります。この場合、VLAN IDに続く2バイトフィールドは再びVLAN Ethertypeです。
VLP (3 bits) is the VLAN priority, see [IEEE802.1Q].
VLP（3ビット）はVLANの優先度です。[IEEE802.1Q]を参照してください。
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).
EtherType（16ビット）は、IEEEによって割り当てられたプロトコル識別子です。EtherTypeは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は、一定レートのリアルタイムトラフィック用の2つの異なる適応アルゴリズムと、可変レートリアルタイムトラフィック用の2つの異なる適応アルゴリズムを提供します。
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.
TDMOIPは、回路エミュレーションに一定のレートAAL1 [AAL1、CES]を使用しますが、ループエミュレーションには可変レートAAL2 [AAL2]が使用されます。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.
さらに、3番目のモードは、TDMチャネルで運ばれる高レベルデータリンク制御（HDLC）ベースの共通チャネルシグナル（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上の回路エミュレーションに使用されていることで説明されています。付録BでAAL1テクノロジーのハイライトを簡単に確認します。このセクションでは、TDMOIPのコンテキストでの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 PDUS」で構成されています。図7aおよび7bを参照してください。PDUの数は事前に構成されている必要があり、全体のパケットサイズがPSNで許可された最大値を超えないように選択する必要があります（たとえば、イーサネット上のUDP/IPの場合）。パケットあたりのPDUの正確な数は、通常、レイテンシと帯域幅の制約を考慮して選択されます。単一のPDUを使用すると、最小限のレイテンシーが発生しますが、最も高いオーバーヘッドが発生します。すべてのTDMOIP実装は、E1およびT1回路のパケットごとに1〜8 PDU、E3およびT3回路ではパケットあたり5〜15 PDUSをサポートする必要があります。
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]は、チャネル関連シグナル伝達（CA）で構造化され構造化された2つのモードを定義します。構造化された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
図8. TDMOIPパケットにおけるAAL2 PDUSの連結
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ペイロードは1つ以上の可変長さの「AAL2 PDUS」で構成されています。図8を参照してください。各AAL2 PDUには、3バイトのオーバーヘッドと1〜64バイトのペイロードが含まれています。すべてのアクティブチャネルに対応する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関数が実行される場合があります。これらには、オンフック/オフフックステータス、音声アクティビティ検出、音声圧縮、FAX/モデム/トーンリレーなどのテストが含まれます。
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、SSC、LES]に記載されているすべてのメカニズムは、TDMOIPに使用できます。特に、[aal2]、[sscs]で定義されている形式のエンコード形式、および[les]で説明されているCAおよびCCSシグナル伝達の輸送に従って、パッドオクテットをエンコードおよび使用するチャネル識別子（CID）の使用はすべてPSNバウンドで使用できます方向、およびTDMバインド方向でサポートする必要があります。オーバーラップ機能とAAL-CUタイマーおよび関連する機能は必要ない場合があり、STF（Startフィールド）は使用されません。エラー検出コードの計算 - つまり、AAL2 PDUヘッダーのヘッダーエラーチェック（HEC）とCASパケットのCRCは、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を処理する動機は、TDMストリームに埋め込まれたSS7 [SS7]やISDN PRIシグナル伝達[ISDN-PRI]などの一般的なチャネル信号（CCS）を効率的に輸送することです。このメカニズムは、一般的な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形式は、ポートモードで動作することを目的としており、すべてのHDLCデータと制御メッセージを個別のPWに透過的に渡します。カプセル化は[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が正しくない場合、フレームは破棄されます。それ以外の場合、フレームは初期フラグまたは最終フラグの後に送信され、FCは破棄され、ゼロ除去が実行されました。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ネットワークは、TDMビットストリームの前方欠陥（AIS）と逆欠陥（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（ES1）からTDMOIP IWF 1（IWF1）を介してTDMOIP IWF 2（IWF2）を介してTDMOIP IWF 1（IWF2）を介してTDMOIP IWF 1（IWF1）を介してTDMネットワーク1を介して下流のTDMフローを考慮することで最もよく理解されています。図に示されているように、ネットワーク2、TDM End System 2（ES2）に向けて。TDMネットワーク1、PSN、およびTDMネットワーク2の欠陥を検出するだけでなく、適切なネットワークでのみアラームを上げるためにそのような欠陥をローカライズすることを希望します。
In the "trail terminated" OAM scenario, only user data is exchanged between TDM network 1 and TDM network 2. The IWF functions as a TDM trail termination function, and defects detected in TDM network 1 are not relayed to network 2, or vice versa.
「トレイル終了」OAMシナリオでは、ユーザーデータのみがTDMネットワーク1とTDMネットワーク2の間で交換されます。IWFはTDMトレイル終了関数として機能し、TDMネットワーク1で検出された欠陥はネットワーク2にリレーされません。。
In the "trail extended" OAM scenario, if there is a defect (e.g., loss of signal or loss of frame synchronization) anywhere in TDM network 1 before the ultimate link, the following TDM node will generate AIS downstream (towards TDMoIP IWF1). If a break occurs in the ultimate link, the IWF itself will detect the loss of signal. In either case, IWF1 having directly detected lack of validity of the TDM signal, or having been informed of an earlier problem, raises the local ("L") defect flag in the control word of the packets it sends across the PSN. In this way the trail is extended to TDM network 2 across the PSN.
「トレイル拡張」OAMシナリオでは、最終リンクの前のTDMネットワーク1のどこかで欠陥がある場合（たとえば、信号の損失またはフレーム同期の損失）、次のTDMノードがAISの下流（TDMOIP IWF1に向かって）を生成します。究極のリンクで休憩が発生した場合、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欠陥フラグを設定します。ご覧のとおり、これにより、AISの表示がES2に到達します。これは、トレイル終了であり、TDM RDIを生成する可能性があります。
When the L flag is set there are four possibilities for treatment of payload content. The default is for IWF1 to fill the payload with the appropriate amount of AIS (usually all-ones) data. If the AIS has been generated before the IWF this can be accomplished by copying the received TDM data; if the penultimate TDM link fails and the IWF needs to generate the AIS itself. Alternatively, with structure-aware transport of channelized TDM one SHOULD fill the payload with "trunk conditioning"; this involves placing a preconfigured "out of service" code in each individual channel (the "out of service" code may differ between voice and data channels). Trunk conditioning MUST be used when channels taken from several TDM PWs are combined by the TDM-bound IWF into a single TDM circuit. The third possibility is to suppress the payload altogether. Finally, if IWF1 believes that the TDM defect is minor or correctable (e.g., loss of multiframe synchronization, or initial phases of detection of incorrect frame 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（通常はすべて）データでペイロードを入力することです。IWFの前にAISが生成されている場合、受信したTDMデータをコピーすることでこれを実現できます。最後から2番目のTDMリンクが失敗し、IWFがAIS自体を生成する必要がある場合。あるいは、チャネル化されたTDMの構造認識輸送では、ペイロードを「トランクコンディショニング」で埋める必要があります。これには、個々のチャネルに事前に設定された「サービス不在」コードを配置することが含まれます（音声チャネルとデータチャネルの間で「サービスを使用していない」コードは異なる場合があります）。いくつかのTDM PWSから取得したチャネルがTDMバウンドIWFによって単一のTDM回路に組み合わされている場合、トランクコンディショニングを使用する必要があります。3番目の可能性は、ペイロードを完全に抑制することです。最後に、IWF1がTDM欠陥がマイナーまたは修正可能であると考えている場合（たとえば、マルチフレーム同期の損失、または誤ったフレーム同期の検出の初期フェーズ）、受信したTDMデータをペイロードフィールドに配置し、TDMデータが破損しているが、潜在的に回復可能であるという欠陥変更フィールド（ "m"）。
When IWF2 receives a local defect indication without M field modification, it forwards (or generates if the payload has been suppressed) AIS or trunk conditioning towards ES2 (the choice between AIS and conditioning being preconfigured). Thus AIS has been properly delivered to ES2 emulating the TDM scenario from the TDM end system's point of view. In addition, IWF2 receiving the L flag uniquely specifies that the defect was in TDM network 1 and not in TDM network 2, thus suppressing alarms in the correctly functioning network.
IWF2がMフィールド変更なしで局所的な欠陥の表示を受け取ると、ES2に向けてAISまたはトランクコンディショニングを転送（またはペイロードが抑制された場合に生成します）（AISとコンディショニングの選択は事前に設定されています）。したがって、AISは、TDM Endシステムの観点からTDMシナリオをエミュレートするES2に適切に配信されました。さらに、L FLAGを受信するIWF2は、欠陥がTDMネットワーク1にあり、TDMネットワーク2ではなく、正しく機能するネットワークのアラームを抑制することを一意に指定しています。
If the M field indicates that the TDM has been marked as potentially recoverable, then implementation specific algorithms (not herein specified) may optionally be utilized to minimize the impact of transient defects on the overall network performance. If the M field indicates that the TDM is "idle", no alarms should be raised and IWF2 treats the payload contents as regular TDM data. If the payload has been suppressed, trunk conditioning and not AIS MUST be generated by IWF2.
Mフィールドが、TDMが潜在的に回復可能であるとマークされていることを示している場合、実装固有のアルゴリズム（本明細書ではない）をオプションで使用して、過渡性欠陥の全体的なネットワークパフォーマンスへの影響を最小限に抑えることができます。MフィールドがTDMが「アイドル」であることを示している場合、アラームを上げる必要はなく、IWF2はペイロードコンテンツを通常のTDMデータとして扱います。ペイロードが抑制されている場合、AIではなくトランクコンディショニングをIWF2によって生成する必要があります。
The second case is when the defect is in TDM network 2. Such defects cause AIS generation towards ES2, which may respond by sending TDM RDI in the reverse direction. In the trail terminated scenario this RDI is restricted to network 2. In the trail extended scenario, IWF2 upon observing this RDI inserted into valid TDM data, MUST indicate this by setting the "R" flag in packets sent back across the PSN towards IWF1. IWF1, upon receiving this indication, generates RDI towards ES1, thus emulating a single conventional TDM network.
2番目のケースは、欠陥がTDMネットワーク2にある場合です。このような欠陥は、AIS生成をES2に引き起こします。これは、TDM RDIを逆方向に送信することで応答する場合があります。トレイル終了シナリオでは、このRDIはネットワーク2に制限されています。トレイル拡張シナリオでは、有効なTDMデータに挿入されたこのRDIを観察する際にIWF2は、PSNを介して送信されたパケットの「R」フラグをIWF1に向けて設定することにより、これを示す必要があります。IWF1は、この兆候を受信すると、ES1に向かってRDIを生成し、単一の従来のTDMネットワークをエミュレートします。
The final possibility is that of a unidirectional defect in the PSN. In such a case, TDMoIP IWF1 sends packets toward IWF2, but these are not received. IWF2 MUST inform the PSN's management system of this problem, and furthermore generate TDM AIS towards ES2. ES2 may respond with TDM RDI, and as before, in the trail extended scenario, when IWF2 detects RDI it MUST raise the "R" flag indication. When IWF1 receives packets with the "R" flag set it has been informed of a reverse defect, and MUST generate TDM RDI towards ES1.
最終的な可能性は、PSNの単方向欠陥の可能性です。そのような場合、TDMOIP IWF1はIWF2にパケットを送信しますが、これらは受信されません。IWF2は、この問題をPSNの管理システムに通知し、さらにES2に向かってTDM AIを生成する必要があります。ES2はTDM RDIで応答する場合があり、以前と同様に、Trail拡張シナリオでは、IWF2がRDIを検出すると、「R」フラグの表示を上げなければなりません。IWF1が「R」フラグセットでパケットを受信すると、逆の欠陥が通知され、ES1に対してTDM RDIを生成する必要があります。
In all cases, if any of the above defects persist for a preconfigured period (default value of 2.5 seconds) a service failure is declared. Since TDM PWs are inherently bidirectional, a persistent defect in either directional results in a bidirectional service failure. In addition, if signaling is sent over a distinct PW as per Section 5.3, both PWs are considered to have failed when persistent defects are detected in either.
すべての場合において、上記の欠陥のいずれかが事前に設定された期間（デフォルト値2.5秒）の間持続する場合、サービスの障害が宣言されます。TDM PWSは本質的に双方向であるため、どちらの方向にも双方向サービスの障害をもたらす持続的な欠陥があります。さらに、セクション5.3に従って異なるPWを介してシグナル伝達が送信される場合、どちらでも持続的な欠陥が検出された場合、両方の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 IWFSがそれぞれのTDMネットワークにAIS（およびトランクコンディショニングではなく）を送信し始めます。IWFは、接続性が回復するまで付録Dに記載されているように、ネイティブメソッドまたは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機器に一定の速度で送信されます。ジッターバッファーの使用は、追加のレイテンシを除いて、従来の同期TDMネットワークではなくPSNが通過したという事実を部分的に隠しています。慣習的な慣行は、ジッターバッファーを約半分のフルで動作させるため、オーバーフローまたはアンダーフローの確率を最小限に抑えることです。したがって、追加の遅延はジッターバッファサイズの半分に等しくなります。ジッターバッファの長さは構成可能であり、動的である可能性があります（つまり、パケット遅延変動（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タイミングを保持するためにメカニズムはフィラーデータを出力する必要があります。誤った順序で到着するパケットは並べ替える必要があります。失われたパケット処理は、適切なFAが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のタイミングを維持するのに十分かもしれませんが、テレフォニートラフィックの場合、音声、迷惑、または理解できないオーディオになるオーディオギャップまたはアーティファクトにつながる可能性があります。実装は、失われたサンプルの代わりに事前に設定された一定の値を盲目的に挿入する場合があり、この値は知覚効果を最小限に抑えるために選択する必要があります。または、以前に受け取ったパケットを再生することもできます。計算リソースが利用可能な場合、実装は、知覚エラーを最小限に抑えるために、欠落しているサンプル値を適切に推定することにより、パケット損失イベントを隠す必要があります。
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の長期的な精度が1つの長期的な精度で、少なくとも1つの非常に正確なプライマリ参照クロックが常に存在します。このノードは、精度がやや低いセカンダリノードへの参照タイミングを提供し、これらはタイミング情報をさらに配布します。この時間同期の階層は、ネットワーク全体の適切な機能に不可欠です。詳細については、[G823] [G824]を参照してください。
Packets in PSNs reach their destination with delay that has a random component, known as packet delay variation (PDV). When emulating TDM on a PSN, extracting data from the jitter buffer at a constant rate overcomes much of the high frequency component of this randomness ("jitter"). The rate at which we extract data from the jitter buffer is determined by the destination clock, and were this to be precisely matched to the source clock proper timing would be maintained. Unfortunately, the source clock information is not disseminated through a PSN, and the destination clock frequency will only nominally equal the source clock frequency, leading to low frequency ("wander") timing inaccuracies.
PSNSのパケットは、パケット遅延バリエーション（PDV）と呼ばれるランダムコンポーネントを持つ遅延を持つ宛先に到達します。PSNでTDMをエミュレートする場合、一定の速度でジッターバッファーからデータを抽出すると、このランダム性の高周波成分の多くが克服されます（「ジッター」）。ジッターバッファーからデータを抽出する速度は、宛先クロックによって決定され、これはソースクロックと正確に一致していたため、適切なタイミングが維持されます。残念ながら、ソースクロック情報はPSNを介して広められておらず、宛先クロック周波数はソースクロック周波数に名目上のみ等しく、低周波（「ワンダー」）タイミングの不正確さにつながります。
In broadest terms, there are four methods of overcoming this difficulty. In the first and second methods timing information is provided by some means independent of the PSN. This timing may be provided to the TDM end systems (method 1) or to the IWFs (method 2). In a third method, a common clock is assumed available to both IWFs, and the relationship between the TDM source clock and this clock is encoded in the packet. This encoding may take the form of RTP timestamps or may utilize the synchronous residual timestamp (SRTS) bits in the AAL1 overhead. In the final method (adaptive clock recovery) the timing must be deduced solely based on the packet arrival times. Example scenarios are detailed in [RFC4197] and in [Y1413].
最も広い用語では、この困難を克服する4つの方法があります。1番目と2番目の方法では、タイミング情報は、PSNとは無関係に何らかの手段によって提供されます。このタイミングは、TDMエンドシステム（方法1）またはIWFS（方法2）に提供される場合があります。3番目の方法では、両方の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.
Adaptive Clock Recoveryは、PSNから到着するパケットの観測可能な特性のみを使用します。たとえば、TDMバインドIWFでのパケットの到着時間、またはジッターバッファーの塗りつぶしレベルの時間の関数としてのみです。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]で定義されているように、Jitterと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）[RFC2212]およびDiffServ対応ドメイン[RFC2475]をサポートするIntServ対応ドメイン（EF）[RFC3246]をサポートするPSNの例を提供します。このようなメカニズムは、隣接するストリームに対するTDMOIPの効果をある程度否定します。IP PSNS上のTDMOIPトラフィックの境界トラフィックコンディショニングを容易にするために、TDMOIPパケットは、デフォルトあたりの動作（PHB）[RFC2474]に予約されているDiffServコードポイント（DSCP）値を使用してはなりません。
When TDMoIP is run over a PSN providing best-effort service, packet loss SHOULD be monitored in order to detect congestion. If congestion is detected and bandwidth reduction is possible, then such reduction SHOULD be enacted. If bandwidth reduction is not possible, then the TDMoIP PW SHOULD shut down bi-directionally for some period of time as described in Section 6.5 of [RFC3985].
TDMOIPが最高のエフォルトサービスを提供する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.
1. AAL1モードでは、Packetの到着の予想レートが固定されており、既知であるため、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.
2. PSNが送達を強化した場合、パケット損失測定の結果は、重度の鬱血の有無の信頼できる兆候ではない場合があります。たとえば、TDMOIPトラフィックが他のトラフィックよりも優先される場合、深刻な輻輳はTDMOIPパケットの損失に大きな影響を与えない場合があります。
3. The TDM services emulated by TDMoIP have high availability objectives (see [G826]) that MUST be taken into account when deciding on temporary shutdown.
3. TDMOIPによってエミュレートされたTDMサービスには、一時的なシャットダウンを決定する際に考慮する必要がある高可用性目標（[G826]を参照）があります。
This specification does not define exact criteria for detecting severe congestion or specific methods for TDMoIP shutdown or subsequent re-start. However, the following considerations may be used as guidelines for implementing the shutdown mechanism:
この仕様は、TDMOIPシャットダウンまたはその後の再起動のための重度の輻輳または特定の方法を検出するための正確な基準を定義しません。ただし、以下の考慮事項は、シャットダウンメカニズムを実装するためのガイドラインとして使用できます。
1. If the TDMoIP PW has been set up using the PWE3 control protocol [RFC4447], the regular PW teardown procedures of these protocols SHOULD be used.
1. TDMOIP PWがPWE3コントロールプロトコル[RFC4447]を使用してセットアップされている場合、これらのプロトコルの通常のPW分解手順を使用する必要があります。
2. If one of the TDMoIP IWFs stops transmission of packets for a sufficiently long period, its peer (observing 100% packet loss) will necessarily detect "severe congestion" and also stop transmission, thus achieving bi-directional PW shutdown.
2. TDMOIP IWFSの1つが十分に長い間パケットの送信を停止すると、そのピア（100％のパケット損失を観察する）は必然的に「重度の混雑」を検出し、伝送を停止し、したがって双方向PWシャットダウンを達成します。
TDMoIP does not provide mechanisms to ensure timely delivery or provide other quality-of-service guarantees; hence it is required that the lower-layer services do so. Layer 2 priority can be bestowed upon a TDMoIP stream by using the VLAN priority field, MPLS priority can be provided by using EXP bits, and layer 3 priority is controllable by using TOS. Switches and routers which the TDMoIP stream must traverse should be configured to respect these priorities.
TDMOIPは、タイムリーな配信を確保したり、他のサービス品質の保証を提供したりするメカニズムを提供しません。したがって、低層サービスがそうする必要があります。レイヤー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の場合、PW固有のセキュリティメカニズムが必要になる場合がありますが、IPベースのPSNSの場合、IPSEC [RFC4301]が使用される場合があります。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を参照]）、実装は機密性、完全性、および認証のためにあらゆるメカニズムを一般的なPWSに対して開発する必要があります。これらの方法は、このドキュメントの範囲を超えています。
Random initialization of sequence numbers, in both the control word and the optional RTP header, makes known-plaintext attacks on encrypted TDMoIP more difficult. Encryption of PWs is beyond the scope of this document.
コントロールワードとオプションのRTPヘッダーの両方で、シーケンス番号のランダムな初期化により、暗号化されたTDMOIPに対する既知のプレーンテキスト攻撃がより困難になります。PWSの暗号化は、このドキュメントの範囲を超えています。
PW labels SHOULD be selected in an unpredictable manner rather than sequentially or otherwise in order to deter session hijacking. When using L2TPv3, a cryptographically random [RFC4086] Cookie SHOULD be used to protect against off-path packet insertion attacks, and a 64- bit Cookie is RECOMMENDED for protection against brute-force, blind, insertion attacks.
PWラベルは、セッションのハイジャックを阻止するために、順次またはその他の方法ではなく、予測不可能な方法で選択する必要があります。L2TPV3を使用する場合、暗号化されたランダム[RFC4086] Cookieを使用して、オフパスパケット挿入攻撃から保護する必要があり、ブルートフォース、ブラインド、挿入攻撃に対する保護には64ビットCookieが推奨されます。
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 PSNSの場合、TDMOIP PWの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.
UDP/IP PSNSの場合、ソースポートがPWラベルとして使用される場合、宛先ポート番号は0x085E（2142）に設定する必要があります。
It must be recognized that the emulation provided by TDMoIP may be imperfect, and the service may differ from the native TDM circuit in the following ways.
TDMOIPによって提供されるエミュレーションは不完全であり、サービスがネイティブTDM回路と次の方法で異なる場合があることを認識する必要があります。
The end-to-end delay of a TDM circuit emulated using TDMoIP may exceed that of a native TDM circuit.
TDMOIPを使用してエミュレートされたTDM回路のエンドツーエンド遅延は、ネイティブTDM回路のエンドツーエンド遅延を超える可能性があります。
When using adaptive clock recovery, the timing performance of the emulated TDM circuit depends on characteristics of the PSN, and thus may be inferior to that of a native TDM circuit.
適応クロック回復を使用する場合、エミュレートされたTDM回路のタイミングパフォーマンスはPSNの特性に依存するため、ネイティブTDM回路の特性よりも劣る可能性があります。
If the TDM structure overhead is not transported over the PSN, then non-FAS data in the overhead will be lost.
TDM構造のオーバーヘッドがPSNで輸送されない場合、オーバーヘッドの非FASデータが失われます。
When packets are lost in the PSN, TDMoIP mechanisms ensure that frame synchronization will be maintained. When packet loss events are properly concealed, the effect on telephony channels will be perceptually minimized. However, the bit error rate will be degraded as compared to the native service.
PSNでパケットが失われると、TDMOIPメカニズムにより、フレームの同期が維持されます。パケット損失イベントが適切に隠されると、テレフォニーチャネルへの影響が知覚的に最小化されます。ただし、ネイティブサービスと比較して、ビットエラー率は低下します。
Data in inactive channels is not transported in AAL2 mode, and thus this data will differ from that of the native service.
非アクティブチャネルのデータはAAL2モードでは輸送されないため、このデータはネイティブサービスのデータとは異なります。
Native TDM connections are point-to-point, while PSNs are shared infrastructures. Hence, the level of security of the emulated service may be less than that of the native service.
ネイティブTDM接続はポイントツーポイントであり、PSNSは共有インフラストラクチャです。したがって、エミュレートサービスのセキュリティのレベルは、ネイティブサービスのセキュリティレベルよりも少ない場合があります。
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.
著者は、Hugo Silberman、Shimon Halevy、Tuvia Segal、およびLad Data CommunicationsのEitan Schwartzに、本書に記載されている技術への貴重な貢献に感謝したいと思います。
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.
コントロールワードのシーケンス番号フィールドは、失われたパケットと誤ったパケットの検出を可能にします。ここでは、関連する問題を明確にするために、アルゴリズムの例の擬似コードを提供します。これらの問題は実装固有であり、すべての可能性をキャプチャできない単一の説明はありません。
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.
プレイアウトバッファーを導入した後、このバッファーの過剰およびアンダーランを明示的に扱います。パケットが非常に速く到着したときにオーバーランが発生し、プレイアウト用に保存できません。これは通常、ひどいタイミングの不正確さや誤解の兆候であり、そのような初期のパケットを破棄することはほとんどできません。アンダーランは、通常、ネットワークの飢starの兆候であり、混雑またはネットワークの障害に起因します。
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:
さらに、アルゴリズムには1つのパラメーターが必要です。
R: maximum lateness for a packet to be recoverable (Note 1).
R：回復可能なパケットの最大遅延（注1）。
Note 1: this is only required for the optional re-ordering
Note 2: this number is always in the range -2^15 ... +2^15 - 1
Note 3: the playout buffer is emptied by the TDM playout process,
which runs asynchronously to the packet arrival processing,
and which is not herein specified
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
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]で定義された3種類のAAL1回路エミュレーションサービスに対応する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は非構造化されたPDUであり、全体の回路の透明な移動に使用されます（T1、E1、T3、E3）。AAL1は、構造化されていない輸送のSATOPと比較して固有の利点を提供しませんが、特定の場合、AAL1が必要または望ましい場合があります。たとえば、既存のAAL1ベースのネットワークとインターワークする必要がある場合、またはAAL1固有のメカニズムに基づくクロック回復が好まれる場合。
For unstructured AAL1, the 47 bytes after the sequence number byte contain the full 376 bits from the TDM bit stream. No frame synchronization is supplied or implied, and framing is the sole responsibility of the end-user equipment. Hence, the unstructured mode can be used to carry data, and for circuits with nonstandard frame synchronization. For the T1 case the raw frame consists of 193 bits, and hence 1 183/193 T1 frames fit into each AAL1 PDU. The E1 frame consists of 256 bits, and so 1 15/32 E1 frames fit into each PDU.
非構造化されたAAL1の場合、シーケンス番号バイトの後の47バイトには、TDMビットストリームからの完全な376ビットが含まれています。フレームの同期は提供または暗示されておらず、フレーミングはエンドユーザー機器の唯一の責任です。したがって、非構造化モードを使用してデータを運ぶことができ、非標準のフレームの同期を備えた回路に使用できます。T1の場合、生のフレームは193ビットで構成されているため、1 183/193 T1フレームが各AAL1 PDUに適合します。E1フレームは256ビットで構成されているため、各PDUに15/32のE1フレームが適合します。
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回路エミュレーションサービスの1つを使用することが有利です。構造化されたAAL1は、データを単に少しストリームとしてではなく、チャネルの束と見なしています。さらに、CASシグナル伝達を使用すると、容易に検出および操作できるようにフォーマットできます。
In the structured circuit emulation mode without CAS, N bytes from the N channels to be transported are first arranged in order of channel number. Thus if channels 2, 3, 5, 7 and 11 are to be transported, the corresponding five bytes are placed in the PDU immediately after the sequence number byte. This placement is repeated until all 47 bytes in the PDU are filled.
CASのない構造化された回路エミュレーションモードでは、輸送されるNチャネルからのnバイトが最初にチャネル番号の順に配置されます。したがって、チャネル2、3、5、7、11を輸送する場合、対応する5バイトがシーケンス番号バイトの直後にPDUに配置されます。この配置は、PDUの47バイトすべてが満たされるまで繰り返されます。
byte 1 2 3 4 5 6 7 8 9 10 --- 41 42 43 44 45 46 47 channel 2 3 5 7 11 2 3 5 7 11 --- 2 3 5 7 11 2 3
バイト1 2 3 4 5 6 7 8 9 10 --- 41 42 43 44 45 46 47チャンネル2 3 5 7 11 2 3 5 7 11 --- 2 3 5 7 11 2 3
The next PDU commences where the present PDU left off.
次のPDUは、現在のPDUが中断したところから始まります。
byte 1 2 3 4 5 6 7 8 9 10 --- 41 42 43 44 45 46 47 channel 5 7 11 2 3 5 7 11 2 3 --- 5 7 11 2 3 5 7
バイト1 2 3 4 5 6 7 8 9 10 --- 41 42 43 44 45 46 47チャンネル5 7 11 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バイトを含むほとんどのAAL1 PDUSとは異なり、ポインター（PフォーマットPDU）を含む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.
c（1ビット）収束昇華指示、p-format pdusのc = 1。
SN (3 bits) is an even AAL1 sequence number.
SN（3ビット）は、均等なAAL1シーケンス番号です。
CRC (3 bits) is a 3-bit error cyclic redundancy code on C and SN.
CRC（3ビット）は、CおよびSNの3ビットエラー周期冗長性コードです。
P (1 bit) even byte parity LSB (least significant bit) for sequence number byte.
P（1ビット）シーケンス番号バイトのバイトパリティLSB（最低ビット）。
E (1 bit) even byte parity MSB for pointer byte.
e（1ビット）ポインターバイトのバイトパリティMSBの均等。
pointer (7 bits) pointer to next structure boundary.
次の構造境界へのポインター（7ビット）ポインター。
Since P-format PDUs have 46 bytes of payload and the next PDU has 47 bytes, viewed as a single entity the pointer needs to indicate one of 93 bytes. If P=0 it is understood that the structure commences with the following byte (i.e., the first byte in the payload belongs to the lowest numbered channel). P=93 means that the last byte of the second PDU is the final byte of the structure, and the following PDU commences with a new structure. The special value P=127 indicates that there is no structure boundary to be indicated (needed when extremely large structures are being transported).
p-format PDUには46バイトのペイロードがあり、次のPDUには47バイトがあるため、単一のエンティティとして表示されているため、ポインターは93バイトのいずれかを示す必要があります。p = 0の場合、構造は次のバイト（つまり、ペイロードの最初のバイトが最低番号付きチャネルに属します）で始まることが理解されます。P = 93は、2番目のPDUの最後のバイトが構造の最終バイトであり、次のPDUが新しい構造から始まることを意味します。特別な値p = 127は、示されるべき構造境界がないことを示しています（非常に大きな構造が輸送されている場合に必要です）。
The P-format PDU is always placed at the first possible position in the sequence number cycle that a structure boundary occurs, and can only occur once per cycle.
P-Format PDUは、構造境界が発生するシーケンス番号サイクルの最初の可能な位置に常に配置され、サイクルごとに1回しか発生しません。
The only difference between the structured circuit emulation format and structured circuit emulation with CAS is the definition of the structure. Whereas in structured circuit emulation the structure is composed of the N channels, in structured circuit emulation with CAS the structure encompasses the superframe consisting of multiple repetitions of the N channels and then the CAS signaling bits. The CAS bits are tightly packed into bytes and the final byte is padded with zeros if required.
構造化回路エミュレーション形式とCASを使用した構造化回路エミュレーションの唯一の違いは、構造の定義です。構造化された回路エミュレーションでは、構造はNチャネルで構成されていますが、CASを使用した構造化回路エミュレーションでは、構造には、Nチャネルの複数の繰り返しとCASシグナル伝達ビットで構成されるスーパーフレームが含まれます。CASビットはバイトにしっかりと詰め込まれており、必要に応じて最終バイトにゼロがパディングされています。
For example, for E1 circuits the CAS signaling bits are updated once per superframe of 16 frames. Hence, the structure for N*64 derived from an E1 with CAS signaling consists of 16 repetitions of N bytes, 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フレームのスーパーフレームごとに1回更新されます。したがって、CASシグナル伝達を備えたE1に由来するN*64の構造は、Nバイトの16の繰り返しで構成され、その後4つのABCDビットのNセット、最後にnが奇数の場合は4つのゼロビットで構成されます。たとえば、チャネル2、3、5の構造は次のとおりです。
2 3 5 2 3 5 2 3 5 2 3 5 2 3 5 2 3 5 2 3 5 2 3 5 2 3 5 2 3 5 2 3 5 2 3 5 2 3 5 2 3 5 2 3 5 2 3 5 [ABCD2 ABCD3] [ABCD5 0000]
2 3 5 2 3 5 2 3 5 2 3 5 2 3 5 2 3 5 2 3 5 2 3 5 2 3 5 2 3 5 2 3 5 2 3 5 2 3 5 2 3 5 2 3 5 2 3 5 [ABCD2ABCD3] [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フレームであり、構造は24のnバイトの繰り返しで構成され、以前と同様にABCDビットが続きます。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にとって一意でなければならない識別子です。値0-7は特別な目的のために予約されています（そして、VODSLとの相互作用が必要な場合、[LES]で指定されている値8〜15も同様です）。チャネルへのCID値のマッピングは、手動で手動で構成されたり、信号を送信したりする場合があります。
LI (6 bits) length indicator is one less than the length of the payload in bytes. Note that the payload is limited to 64 bytes.
Li（6ビット）長さインジケーターは、バイト内のペイロードの長さより1枚未満です。ペイロードは64バイトに制限されていることに注意してください。
UUI (5 bits) user-to-user indication is the higher layer (application) identifier and counter. For voice data, the UUI will always be in the range 0-15, and SHOULD be incremented modulo 16 each time a channel buffer is sent. The receiver MAY monitor this sequence. UUI is set to 24 for CAS signaling packets.
UUI（5ビット）ユーザーからユーザーへの表示は、より高い層（アプリケーション）識別子とカウンターです。音声データの場合、UUIは常に0〜15の範囲にあり、チャネルバッファーが送信されるたびにModulo 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.
ペイロード - 音声音声サンプルのLiが示す長さのブロックは、AAL2パケットに配置されます。
Payload - CAS signaling For CAS signaling the payload is formatted as an AAL2 "fully protected" (type 3) packet (see [AAL2]) in order to ensure error protection. The signaling is sent with the same CID as the corresponding voice channel. Signaling MUST be sent whenever the state of the ABCD bits changes, and SHOULD be sent with triple redundancy, i.e., sent three times spaced 5 milliseconds apart. In addition, the entire set of the signaling bits SHOULD be sent periodically to ensure reliability.
ペイロード-CASのCASシグナル伝達ペイロードのシグナリングは、エラー保護を確保するために、AAL2「完全に保護された」（タイプ3）パケット（[AAL2]を参照）としてフォーマットされます。シグナリングは、対応する音声チャネルと同じCIDで送信されます。ABCDビットの状態が変更されたときはいつでもシグナリングを送信する必要があり、トリプル冗長性で送信する必要があります。つまり、5ミリ秒離れた3倍の間隔で送信されます。さらに、信頼性を確保するために、信号ビットのセット全体を定期的に送信する必要があります。
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|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.
赤（2ビット）はトリプル冗長性カウンターです。最初のパケットでは、2番目の01および3番目の10の場合、値00が必要です。Red= 11は非冗長情報を意味し、トリプル冗長性が採用されていない場合に使用され、定期的な更新メッセージに使用されます。
Timestamp (14 bits) The timestamp is optional and in particular is not needed if RTP is employed. If not used, the timestamp MUST be set to zero. When used with triple redundancy, it MUST be the same for all three redundant transmissions.
タイムスタンプ（14ビット）タイムスタンプはオプションであり、特にRTPが使用されている場合は必要ありません。使用していない場合は、タイムスタンプをゼロに設定する必要があります。トリプル冗長性とともに使用する場合、3つの冗長な送信すべてで同じでなければなりません。
RES (4 bits) is reserved and MUST be set to zero.
RES（4ビット）は予約されており、ゼロに設定する必要があります。
ABCD (4 bits) are the CAS signaling bits.
ABCD（4ビット）はCASシグナル伝達ビットです。
type (6 bits) for CAS signaling this is 000011.
CASシグナル伝達のタイプ（6ビット）これは000011です。
CRC-10 (10 bits) is a 10-bit CRC error detection code.
CRC-10（10ビット）は、10ビットCRCエラー検出コードです。
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.
PWは、エミュレートされたサービスに影響を与えるパフォーマンス測定を監視するためにOAMメカニズムを必要とします。パケット損失比やパケット遅延の変動などのパフォーマンス測定は、さまざまなパラメーターとしきい値を設定するために使用できます。TDMOIPの場合、PWS適応タイミング回復とパケット損失の隠蔽アルゴリズムは、そのような情報から利益を得ることができます。さらに、OAMメカニズムを使用して、基礎となるPSN [RFC2330]に関連する統計を収集し、TDMサービスを運ぶことに適しています。
TDMoIP IWFs may benefit from knowledge of PSN performance metrics, such as round trip time (RTT), packet delay variation (PDV) and packet loss ratio (PLR). These measurements are conventionally performed by a separate flow of packets designed for this purpose, e.g., ICMP packets [RFC792] or MPLS LSP ping packets [RFC4379] with multiple timestamps. For AAL1 mode, TDMoIP sends packets across the PSN at a constant rate, and hence no additional OAM flow is required for measurement of PDV or PLR. However, separate OAM flows are required for RTT measurement, for AAL2 mode PWs, for measurement of parameters at setup, for monitoring of inactive backup PWs, and for low-rate monitoring of PSNs after PWs have been withdrawn due to service failures.
TDMOIP IWFSは、往復時間（RTT）、パケット遅延変動（PDV）、パケット損失比（PLR）などのPSNパフォーマンスメトリックの知識の恩恵を受ける可能性があります。これらの測定は、この目的のために設計された個別のパケットの流れ、例えばICMPパケット[RFC792]またはMPLS LSP Pingパケット[RFC4379]によって、複数のタイムスタンプを備えたMPLS LSP Pingパケット[RFC4379]によって従来実行されます。AAL1モードの場合、TDMOIPはPSN全体で一定の速度でパケットを送信するため、PDVまたはPLRの測定には追加のOAMフローは必要ありません。ただし、RTT測定、AAL2モードPWS、セットアップ時のパラメーターの測定、非アクティブなバックアップPWの監視、およびサービスの障害によりPWS後のPSNSの低レートモニタリングには、個別のOAMフローが必要です。
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に、接続検証を提供する適切なメンテナンスメカニズムがある場合は、RTT、PDV、およびPWの測定値とよく相関するPLR測定値を備えている場合、これらのメカニズムを使用する必要があります。そのようなメカニズムが利用できない場合、2つの同様のOAMシグナル伝達メカニズムのいずれかを使用できます。1つ目はPWの内部であり、INBAND VCCV [RFC5085]に基づいており、2番目はUDP/IP PSNSに対してのみ定義され、別のPWに基づいています。後者は、多数の運命共有TDM PWSにとって特に効率的です。
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 PWSを使用すると、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.
この問題は、TDMOIP IWFが最初に育てられたときに発生する可能性があります。TDM結合IWFがPSNから障害または切断されたとき、またはPWが壊れている場合。老化した後、宛先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障害が検出されたときに1秒あたり送信される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シグナリングがなければ、宛先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メトリックを要求および報告できます。また、リモート診断にも使用できます。潜在的な問題の未承諾の報告の場合（たとえば、Gaspメッセージの死に至る）。
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.
Inband Performance Monitoringを使用すると、同じ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を示すためにPRECONFIGUREDを使用するPWラベルを使用する必要があります。すべてのPSN層パラメーターは、監視対象のPWのパラメーターのままでなければなりません。
The format of an inband OAM PW message packet for UDP/IP PSNs is based on [RFC2679]. The PSN-specific layers are identical to those defined in Section 4.1 with the PW label set to the value preconfigured or assigned for PW OAM.
UDP/IP PSNSのインバンド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 MSGタイプ（8ビット）は、メッセージの関数を示します。現在、以下が定義されています。
0 for one-way connectivity query message 8 for one-way connectivity reply message.
0一元配置接続の場合は、一元配置接続のためのメッセージ8の返信メッセージの場合。
OAM Msg Code (8 bits) is used to carry information related to the message, and its interpretation depends on the message type. For type 0 (connectivity query) messages the following codes are defined:
OAM MSGコード（8ビット）は、メッセージに関連する情報を伝達するために使用され、その解釈はメッセージタイプに依存します。タイプ0（接続クエリ）メッセージの場合、次のコードが定義されています。
0 validate connection. 1 do not validate connection
0接続を検証します。1接続を検証しないでください
for type 8 (connectivity reply) messages the available codes are:
タイプ8（接続の返信）メッセージの場合、利用可能なコードは次のとおりです。
0 acknowledge valid query 1 invalid query (configuration mismatch).
0有効なクエリ1無効なクエリ（構成の不一致）を確認します。
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.
TSSの数（8ビット）は、輸送されるチャネルの数です。たとえば、完全なT1の場合は24です。
Number of SFs (8 bits) is the number of 48-byte AAL1 PDUs per packet, e.g., 8 when packing 8 PDUs per packet.
SFSの数（8ビット）は、パケットあたり48バイトのAAL1 PDUの数です。たとえば、パケットごとに8 PDUを梱包する場合は8です。
Forward PW label (16 bits) is the PW label used for TDMoIP traffic from the source to destination IWF.
フォワードPWラベル（16ビット）は、ソースから宛先IWFへのTDMOIPトラフィックに使用されるPWラベルです。
Reverse PW label (16 bits) is the PW label used for TDMoIP traffic from the destination to source IWF.
リバースPWラベル（16ビット）は、宛先からソースIWFまでのTDMOIPトラフィックに使用されるPWラベルです。
Source Transmit Timestamp (32 bits) represents the time the PSN-bound IWF transmitted the query message. This field and the following ones only appear if delay is being measured. All time units are derived from a clock of preconfigured frequency, the default being 100 microseconds.
ソース送信タイムスタンプ（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).
RTPの使用（使用する場合：一般的なクロック、PT、SSRC値の頻度）。
During operation, the following statistics and impairment indications SHOULD be collected for each TDM PW, and can be queried by the management system.
操作中、各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)
誤ったパケットの適応
for AAL1 mode PWs:
AAL1モードPWSの場合：
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モードPWSの場合：
number of malformed minicells (incorrect HEC)
奇形のミニセルの数（間違ったHEC）
indication of misordered minicells (unexpected UUI)
誤ったミニセルの兆候（予期しない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:
HDLCモードPWSの場合：
number of discarded frames from TDM (e.g., CRC error, illegal packet size)
TDMから廃棄されたフレームの数（例：CRCエラー、違法なパケットサイズ）
number of seconds with jitter buffer over-run events.
ジッターバッファオーバーランイベントを使用した秒数。
During operation, the following statistics MAY be collected for each TDM PW.
操作中、TDM PWごとに次の統計を収集できます。
number of packets sent to PSN
psnに送信されるパケットの数
number of packets received from PSN
PSNから受け取ったパケットの数
number of seconds during which packets were received with L flag set
Lフラグセットでパケットが受信された秒数
number of seconds during which packets were received with R flag set.
Rフラグセットでパケットが受信された秒数。
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（11/88） - 34368 kbit/sの3次ビットレートで動作するデジタル多重装置と139264 kbit/sの4次ビットレートで動作し、正の正当化を使用して
[G823] ITU-T Recommendation G.823 (03/00) - The control of jitter and wander within digital networks which are based on the 2048 Kbit/s hierarchy
[G823] ITU -Tの推奨G.823（03/00） - 2048 KBIT/S階層に基づくデジタルネットワーク内でのジッターとさまよう制御
[G824] ITU-T Recommendation G.824 (03/00) - The control of jitter and wander within digital networks which are based on the 1544 Kbit/s hierarchy
[G824] ITU -T推奨G.824（03/00） - 1544 Kbit/s階層に基づくデジタルネットワーク内でのジッターとさまよう制御
[G826] ITU-T Recommendation G.826 (12/02) - End-to-end error performance parameters and objectives for international, constant bit-rate digital paths and connections
[G826] ITU-T推奨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
[LES] ATMフォーラム仕様ATM-VMOA-0145（LES）Voice and Multimedia over ATM-loopエミュレーションサービスAAL2を使用
[MEF8] Metro Ethernet Forum, "Implementation Agreement for the Emulation of PDH Circuits over Metro Ethernet Networks", October 2004.
[MEF8] Metro Ethernet Forum、「メトロイーサネットネットワーク上のPDH回路のエミュレーションのための実装契約」、2004年10月。
[RFC768] Postel, J., "User Datagram Protocol (UDP)", STD 6, RFC 768, August 1980.
[RFC768] POSTEL、J。、「ユーザーデータグラムプロトコル（UDP）」、STD 6、RFC 768、1980年8月。
[RFC791] Postel, J., "Internet Protocol (IP)", STD 5, RFC 791, September 1981.
[RFC791] Postel、J。、「インターネットプロトコル（IP）」、STD 5、RFC 791、1981年9月。
[RFC2119] Bradner, S., "Key Words in RFCs to Indicate Requirement Levels", RFC 2119, March 1997.
[RFC2119] Bradner、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] Rosen、E.、Tappan、D.、Fedorkow、G.、Rekhter、Y.、Farinacci、D.、Li、T。、およびA. conta、「Mpls Label Stack ending」、RFC 3032、2001年1月。
[RFC3931] Lau, J., Townsley, M., Goyret, I., "Layer Two Tunneling Protocol - Version 3 (L2TPv3)", RFC 3931, March 2005.
[RFC3931] Lau、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.、Frederick、R。、およびJacobson、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] Martini、L。、「Pseudowire Edge to Edge Emulation（PWE3）へのIANAの割り当て」、BCP 116、RFC 4446、2006年4月。
[RFC4447] Martini, L., Rosen, E., El-Aawar, N., Smith, T., and G. Heron, "Pseudowire Setup and Maintenance Using the Label Distribution Protocol (LDP)", RFC 4447, April 2006.
[RFC4447] Martini、L.、Rosen、E.、El-Aawar、N.、Smith、T.、およびG. Heron、「ラベル分布プロトコル（LDP）を使用した擬似ワイヤーのセットアップとメンテナンス」、RFC 4447、2006年4月。
[RFC4553] Vainshtein A., and Stein YJ., "Structure-Agnostic TDM over Packet (SAToP)", RFC 4553, June 2006.
[RFC4553] Vainshtein A.、およびStein YJ。、「構造と存在するTDM Over Packet（SATOP）」、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] Martini L.、Rosen E.、Heron 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] Nadeau、T.、ed。、およびC. Pignataro、ed。、「Pseudowire Virtual Curned Connectivity Verification：Pseudowiresの制御チャネル」、RFC 5085、2007年12月。
[SSCS] ITU-T Recommendation I.366.2 (11/00) - AAL type 2 service specific convergence sublayer for narrow-band services.
[SSC] 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] Postel 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.、Partridge、C。、およびR. Guerin、「保証されたサービス品質の仕様」、RFC 2212、1997年9月。
[RFC2330] Paxson, V., Almes, G., Mahdavi, J., Mathis M., "Framework for IP Performance Metrics", RFC 2330, May 1998.
[RFC2330] Paxson、V.、Almes、G.、Mahdavi、J.、Mathis M.、「IPパフォーマンスメトリックのフレームワーク」、RFC 2330、1998年5月。
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998.
[RFC2460] Deering、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] Nichols、K.、Blake、S.、Baker、F。、およびD. Black、「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] Blake、S.、Black、D.、Carlson、M.、Davies、E.、Wang、Z.、およびW. Weiss、「Distementiated Serviceの建築」、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] Davie、B.、Charny、A.、Bennet、J.C.、Benson、K.、Le Boudec、J.、Courtney、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.、McGrew、D.、Naslund、M.、Carrara、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] Bryant、S。およびP. Pate、「Pseudo Wire Emulation Edge-to-Edge（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] Eastlake、D.、3rd、Schiller、J。、およびS. Crocker、「セキュリティのランダム性要件」、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] Riegel、M。、「パケットスイッチングネットワーク上のマルチプレックス（TDM）回路のエッジ間エミュレーションの要件」、RFC 4197、2005年10月。
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005.
[RFC4301] Kent、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。およびSwallow、G。、「マルチプロトコルラベルスイッチ（MPLS）データプレーンの障害の検出」、RFC 4379、2006年2月。
[RFC4385] Bryant, S., Swallow, G., Martini, L., and D. McPherson, "Pseudowire Emulation Edge-to-Edge (PWE3) Control Word for Use over an MPLS PSN", RFC 4385, February 2006.
[RFC4385] Bryant、S.、Swallow、G.、Martini、L。、およびD. McPherson、「Pseudowire Emulation Edge-to-Edge（PWE3）がMPLS PSNを介して使用するための単語」、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.、Ed。、Sasson、I.、Metz、E.、Frost、T.、およびP. Pate、「構造認識時分割多重化（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）Stein、「MPLSネットワークにおけるTDM Pseudowiresのセットアップのコントロールプロトコル拡張」、2007年11月、Work in Progress。
[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（Jonathan）Stein Rad Data Communications 24 Raoul Wallenberg St.、Bldg C Tel Aviv 69719イスラエル
Phone: +972 3 645-5389
EMail: yaakov_s@rad.com
Ronen Shashoua RAD Data Communications 24 Raoul Wallenberg St., Bldg C Tel Aviv 69719 ISRAEL
Ronen Shashoua Rad Data Communications 24 Raoul Wallenberg St.、Bldg C Tel Aviv 69719イスラエル
Phone: +972 3 645-5447
EMail: ronen_s@rad.com
Ron Insler RAD Data Communications 24 Raoul Wallenberg St., Bldg C Tel Aviv 69719 ISRAEL
Ron Insler Rad Data Communications 24 Raoul Wallenberg St.、Bldg C Tel Aviv 69719イスラエル
Phone: +972 3 645-5445
EMail: ron_i@rad.com
Motty (Mordechai) Anavi RAD Data Communications 900 Corporate Drive Mahwah, NJ 07430 USA
Motty（Mordechai）Anavi Rad Data Communications 900 Corporate Drive Mahwah、NJ 07430 USA
Phone: +1 201 529-1100 Ext. 213
EMail: motty@radusa.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2007).
著作権（c）The IETF Trust（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.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供され、貢献者、彼/彼女が代表する組織（もしあれば）、インターネット協会、IETFトラスト、インターネットエンジニアリングタスクフォースがすべてを否認します。明示的または黙示的な保証。ここでの情報の使用は、特定の目的に対する商品性または適合性の権利または暗黙の保証を侵害しないという保証を含むがこれらに限定されない。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、知的財産権またはその他の権利の有効性または範囲に関して、本書に記載されている技術の実装または使用、またはそのような権利に基づくライセンスに基づくライセンスの範囲に関連すると主張される可能性のある他の権利に関しては、立場を取得しません。利用可能になります。また、そのような権利を特定するために独立した努力をしたことも表明していません。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.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得するための試みの結果を取得できます。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への情報をお問い合わせください。