[要約] RFC 5087は、TDM（時分割多重）トラフィックをIPネットワーク上で透過的に転送するための「TDMoIP」プロトコルの仕様を、情報提供目的で記録した文書です。E1/T1などのシリアル回線をIPパケットでカプセル化し、タイミング同期やジッタ制御を行うための技術的な詳細を提示しています（業界標準となったPWE3仕様の先行実装の一つです）。
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）は、擬似ワイヤ（PW）を用いて時分割多重化（TDM）信号を転送する、構造認識型の方式です。TDMoIPはTDM構造の完全性を保てるため、構造非依存型の転送よりネットワーク劣化への耐性が高くなります。構造認識型の方式では個々のチャネルを識別できるため、パケット損失の隠蔽と帯域幅の節約が可能です。TDMシグナリングを利用できるため、これを活用または操作する仕組みも可能になります。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. TDM Structure and Structure-aware Transport . . . . . . . . . 4
3. TDMoIP Encapsulation . . . . . . . . . . . . . . . . . . . . . 6
4. Encapsulation Details for Specific PSNs . . . . . . . . . . . 9
4.1. UDP/IP . . . . . . . . . . . . . . . . . . . . . . . . . . 9
4.2. MPLS . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
4.3. L2TPv3 . . . . . . . . . . . . . . . . . . . . . . . . . . 14
4.4. Ethernet . . . . . . . . . . . . . . . . . . . . . . . . . 15
5. TDMoIP Payload Types . . . . . . . . . . . . . . . . . . . . . 17
5.1. AAL1 Format Payload . . . . . . . . . . . . . . . . . . . 18
5.2. AAL2 Format Payload . . . . . . . . . . . . . . . . . . . 19
5.3. HDLC Format Payload . . . . . . . . . . . . . . . . . . . 20
6. TDMoIP Defect Handling . . . . . . . . . . . . . . . . . . . . 21
7. Implementation Issues . . . . . . . . . . . . . . . . . . . . 24
7.1. Jitter and Packet Loss . . . . . . . . . . . . . . . . . . 24
7.2. Timing Recovery . . . . . . . . . . . . . . . . . . . . . 25
7.3. Congestion Control . . . . . . . . . . . . . . . . . . . . 26
8. Security Considerations . . . . . . . . . . . . . . . . . . . 27
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28
10. Applicability Statement . . . . . . . . . . . . . . . . . . . 28
11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 29
Appendix A. Sequence Number Processing (Informative) . . . . . . 30
Appendix B. AAL1 Review (Informative) . . . . . . . . . . . . . . 32
Appendix C. AAL2 Review (Informative) . . . . . . . . . . . . . . 36
Appendix D. Performance Monitoring Mechanisms (Informative) . . . 38
D.1. TDMoIP Connectivity Verification . . . . . . . . . . . . . 38
D.2. OAM Packet Format . . . . . . . . . . . . . . . . . . . . 39
Appendix E. Capabilities, Configuration and Statistics
(Informative) . . . . . . . . . . . . . . . . . . . . 42
References . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
Normative References . . . . . . . . . . . . . . . . . . . . . . 45
Informative References . . . . . . . . . . . . . . . . . . . . . 47
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1. はじめに .......................................................3
2. TDM Structure and Structure-aware Transport . . . . . . . . . 4
2. TDM構造と構造認識型伝送 ........................................4
3. TDMoIP Encapsulation . . . . . . . . . . . . . . . . . . . . . 6
3. TDMoIPのカプセル化 .............................................6
4. Encapsulation Details for Specific PSNs . . . . . . . . . . . 9
4. 特定のPSNにおけるカプセル化の詳細 ..............................9
4.1. UDP/IP . . . . . . . . . . . . . . . . . . . . . . . . . . 9
4.1. UDP/IP .....................................................9
4.2. MPLS . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
4.2. MPLS ......................................................12
4.3. L2TPv3 . . . . . . . . . . . . . . . . . . . . . . . . . . 14
4.3. L2TPv3 ....................................................14
4.4. Ethernet . . . . . . . . . . . . . . . . . . . . . . . . . 15
4.4. Ethernet ..................................................15
5. TDMoIP Payload Types . . . . . . . . . . . . . . . . . . . . . 17
5. TDMoIPのペイロード型 ..........................................17
5.1. AAL1 Format Payload . . . . . . . . . . . . . . . . . . . 18
5.1. AAL1形式のペイロード ......................................18
5.2. AAL2 Format Payload . . . . . . . . . . . . . . . . . . . 19
5.2. AAL2形式のペイロード ......................................19
5.3. HDLC Format Payload . . . . . . . . . . . . . . . . . . . 20
5.3. HDLC形式のペイロード ......................................20
6. TDMoIP Defect Handling . . . . . . . . . . . . . . . . . . . . 21
6. TDMoIPの障害処理 ..............................................21
7. Implementation Issues . . . . . . . . . . . . . . . . . . . . 24
7. 実装上の課題 ..................................................24
7.1. Jitter and Packet Loss . . . . . . . . . . . . . . . . . . 24
7.1. ジッターとパケット損失 ....................................24
7.2. Timing Recovery . . . . . . . . . . . . . . . . . . . . . 25
7.2. タイミング回復 ............................................25
7.3. Congestion Control . . . . . . . . . . . . . . . . . . . . 26
7.3. 輻輳制御 ..................................................26
8. Security Considerations . . . . . . . . . . . . . . . . . . . 27
8. セキュリティに関する考慮事項 ..................................27
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28
9. IANAに関する考慮事項 ..........................................28
10. Applicability Statement . . . . . . . . . . . . . . . . . . . 28
10. 適用性に関する記述 ............................................28
11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 29
11. 謝辞 ..........................................................29
Appendix A. Sequence Number Processing (Informative) . . . . . . 30
Appendix A. シーケンス番号の処理（参考情報） .....................30
Appendix B. AAL1 Review (Informative) . . . . . . . . . . . . . . 32
Appendix B. AAL1の概要（参考情報） ...............................32
Appendix C. AAL2 Review (Informative) . . . . . . . . . . . . . . 36
Appendix C. AAL2の概要（参考情報） ...............................36
Appendix D. Performance Monitoring Mechanisms (Informative) . . . 38
Appendix D. 性能監視機構（参考情報） .............................38
D.1. TDMoIP Connectivity Verification . . . . . . . . . . . . . 38
D.1. TDMoIPの接続性検証 ........................................38
D.2. OAM Packet Format . . . . . . . . . . . . . . . . . . . . 39
D.2. OAMパケット形式 ...........................................39
Appendix E. Capabilities, Configuration and Statistics
(Informative) . . . . . . . . . . . . . . . . . . . . 42
Appendix E. 機能、構成、統計情報（参考情報） .....................42
References . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
参考文献 ..........................................................45
Normative References . . . . . . . . . . . . . . . . . . . . . . 45
規範的な参考文献 ................................................45
Informative References . . . . . . . . . . . . . . . . . . . . . 47
情報提供的参考文献 ..............................................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].
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.
Structure-Agnostic TDM over Packet（SAToP）[RFC4553]は、PSN上でTDMを転送するための構造非依存型プロトコルです。本書では、TDM転送の構造認識型方式であるTDM over IP（TDMoIP）を詳述します。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上のUDP、MPLS、IP上のLayer 2 Tunneling Protocol version 3（L2TPv3）、およびEthernetなど、複数の種類のPSN上で動作できます。各PSNに固有の実装詳細はセクション4で説明します。このプロトコルは一般にはTDMoPW、その個別の実装はTDMoIP、TDMoMPLSなどと呼ぶほうが適切ですが、従来の用法との一貫性を保つため、ここではTDMoIPという名称を使います。
The interworking function that connects between the TDM and PSN worlds will be called a TDMoIP interworking function (IWF), and it may be situated at the provider edge (PE) or at the customer edge (CE). The IWF that encapsulates TDM and injects packets into the PSN will be called the PSN-bound interworking function, while the IWF that extracts TDM data from packets and generates traffic on a TDM network will be called the TDM-bound interworking function. Emulated TDM circuits are always point-to-point, bidirectional, and transport TDM at the same rate in both directions.
TDMとPSNの各領域を接続する相互接続機能をTDMoIP相互接続機能（IWF）と呼び、プロバイダーエッジ（PE）またはカスタマーエッジ（CE）に配置できます。TDMをカプセル化してPSNにパケットを送り込むIWFをPSN側IWFと呼び、パケットからTDMデータを取り出してTDMネットワーク上に信号を生成するIWFをTDM側IWFと呼びます。エミュレートされたTDM回線は常にポイントツーポイントかつ双方向であり、両方向に同じ速度でTDMを転送します。
As with all PWs, TDMoIP PWs may be manually configured or set up using the PWE3 control protocol [RFC4447]. Extensions to the PWE3 control protocol required specifically for setup and maintenance of TDMoIP pseudowires are described in [TDM-CONTROL].
他のPWと同様に、TDMoIP PWは手動で設定するか、PWE3制御プロトコル[RFC4447]を使って設定できます。TDMoIP擬似ワイヤの設定と保守に特化して必要となるPWE3制御プロトコルの拡張は[TDM-CONTROL]に記述されています。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
この文書におけるキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、「OPTIONAL」は、[RFC2119]に記述されているとおりに解釈します。
Although TDM circuits can be used to carry arbitrary bit-streams, there are standardized methods for carrying constant-length blocks of data called "structures". Familiar structures are the T1 or E1 frames [G704] of length 193 and 256 bits, respectively. By concatenation of consecutive T1 or E1 frames we can build higher level structures called superframes or multiframes. T3 and E3 frames [G704][G751] are much larger than those of T1 and E1, and even larger structures are used in the GSM Abis channel described in [TRAU]. TDM structures contain TDM data plus structure overhead; for example, the 193-bit T1 frame contains a single bit of structure overhead and 24 bytes of data, while the 32-byte E1 frame contains a byte of overhead and 31 data bytes.
TDM回線は任意のビットストリームを運べますが、「構造」と呼ばれる固定長データブロックを運ぶ標準化方式があります。よく知られた構造には、それぞれ193ビットおよび256ビット長のT1フレームとE1フレーム[G704]があります。連続するT1フレームまたはE1フレームを連結すると、スーパーフレームやマルチフレームと呼ばれる上位の構造を構成できます。T3フレームとE3フレーム[G704][G751]はT1フレームやE1フレームより大幅に大きく、[TRAU]で説明するGSM Abisチャネルではさらに大きな構造が使われます。TDM構造にはTDMデータと構造オーバーヘッドが含まれます。たとえば、193ビットのT1フレームには構造オーバーヘッド1ビットとデータ24バイトが含まれ、32バイトのE1フレームにはオーバーヘッド1バイトとデータ31バイトが含まれます。
Structured TDM circuits are frequently used to transport multiplexed channels. A single byte in the TDM frame (called a timeslot) is allocated to each channel. A frame of a channelized T1 carries 24 byte-sized channels, while an E1 frame consists of 31 channels. Since TDM frames are sent 8000 times per second, a single byte-sized channel carries 64 kbps.
構造化TDM回線は、多重化されたチャネルの伝送によく使われます。TDMフレーム内の1バイト（タイムスロットと呼びます）が各チャネルに割り当てられます。チャネル化されたT1の1フレームは24個の1バイトチャネルを運び、E1フレームは31個のチャネルで構成されます。TDMフレームは1秒間に8000回送信されるため、1バイト幅のチャネルは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）と呼ばれる検出しやすい周期ビットパターンを構造オーバーヘッド内に配置し、構造の境界を示します。構造オーバーヘッドには、エラー監視や障害表示も含めることができます。ここでは、FASによって何らかの構造が与えられたTDMを「構造化TDM」と呼びます。非構造化TDMは構造を持たないビットストリームであり、すべてのビットをユーザーデータに利用できます。
SAToP [RFC4553] is a structure-agnostic protocol for transporting TDM using PWs. SAToP treats the TDM input as an arbitrary bit-stream, completely disregarding any structure that may exist in the TDM bit-stream. Hence, SAToP is ideal for transport of truly unstructured TDM, but is also suitable for transport of structured TDM when there is no need to protect structure integrity nor interpret or manipulate individual channels during transport. In particular, SAToP is the technique of choice for PSNs with negligible packet loss, and for applications that do not require discrimination between channels nor intervention in TDM signaling.
SAToP [RFC4553]は、PWを使ってTDMを転送する構造非依存型プロトコルです。SAToPはTDM入力を任意のビットストリームとして扱い、その中に存在し得る構造を完全に無視します。そのため、SAToPは真に非構造化されたTDMの転送に最適ですが、構造の完全性を保護する必要がなく、転送中に個々のチャネルを解釈または操作する必要もない場合には、構造化TDMの転送にも適しています。特に、SAToPはパケット損失が無視できるPSNや、チャネルを区別したりTDMシグナリングに介入したりする必要のない用途に適した方式です。
As described in [RFC4553], when a single SAToP packet is lost, an "all ones" pattern is played out to the TDM interface. This pattern is interpreted by the TDM end equipment as an Alarm Indication Signal (AIS), which, according to TDM standards [G826], immediately triggers a "severely errored second" event. As such events are considered highly undesirable, the suitability of SAToP is limited to extremely reliable and underutilized PSNs.
[RFC4553]で説明されているように、SAToPパケットが1つ失われると、TDMインターフェイスには「全ビット1」のパターンが出力されます。TDM端末はこのパターンを警報表示信号（AIS）として解釈します。TDM標準[G826]によれば、AISは直ちに「重大誤り秒（Severely Errored Second）」イベントを引き起こします。このようなイベントは極めて望ましくないため、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上で転送する必要はありません。特に、PSN側IWFはFASを除去してもよく (MAY)、TDM側IWFはFASを再生成しなければなりません (MUST)。ただし、構造オーバーヘッドにはFAS以外の情報が含まれる場合があるため、これをPSN上で転送してもかまいません (MAY)。
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シグナリングや音声アクティビティ検出を利用することで、帯域幅を節約できます。
There are three conceptually distinct methods of ensuring TDM structure integrity -- namely, structure-locking, structure-indication, and structure-reassembly. Structure-locking requires each packet to commence at the start of a TDM structure, and to contain an entire structure or integral multiples thereof. Structure-indication allows packets to contain arbitrary fragments of basic structures, but employs pointers to indicate where each structure commences. Structure-reassembly is only defined for channelized TDM; the PSN-bound IWF extracts and buffers individual channels, and the original structure is reassembled from the received constituents by the TDM-bound IWF.
TDM構造の完全性を保つ方法には、概念的に異なる構造固定、構造指示、構造再構成の3種類があります。構造固定では、各パケットをTDM構造の先頭から始め、その構造全体またはその整数倍の構造を含めます。構造指示では、パケットに基本構造の任意の断片を含めることができますが、各構造の開始位置を示すポインターを使います。構造再構成はチャネル化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機能が損なわれることがあります。OAMには「トレイル終端」と「トレイル延長」の2つの状況があり、区別すると有用です。トレイルとは、データとそれに関連する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
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 Ethernetの各ヘッダーです。これらには、PSN側IWFからTDM側IWFへパケットを転送するために必要な情報がすべて含まれます。PSNには、必要なTDMデータを転送するのに十分な信頼性と帯域幅があるものとします。
A TDMoIP IWF may simultaneously support multiple TDM PWs, and the TDMoIP IWF MUST maintain context information for each TDM PW. Distinct PWs are differentiated based on PW labels, which are carried in the PSN-specific layers. Since TDM is inherently bidirectional, the association of two PWs in opposite directions is required. The PW labels of the two directions MAY take different values.
TDMoIP IWFは複数のTDM PWを同時にサポートする場合があり、各TDM PWのコンテキスト情報を保持しなければなりません (MUST)。個々のPWは、PSN固有の層で運ばれるPWラベルによって識別されます。TDMは本質的に双方向であるため、反対方向の2つのPWを対応付ける必要があります。両方向のPWラベルは異なる値でもかまいません (MAY)。
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ヘッダーを含めてもかまいません (MAY)。この用途では[RFC3550]のヘッダー形式を形式上再利用するだけです。ヘッダー拡張、CSRCリスト、パディング、RTP Control Protocol（RTCP）、RTPヘッダー圧縮、Secure 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ヘッダーを省略すべきです (SHOULD)。
If RTP is used, the fixed RTP header described in [RFC3550] MUST immediately follow the control word for all PSN types except UDP/IP, for which it MUST precede the control word. The version number MUST be set to 2, the P (padding), X (header extension), CC (CSRC count), and M (marker) fields in the RTP header MUST be set to zero, and the payload type (PT) values MUST be allocated from the range of dynamic values. The RTP sequence number MUST be identical to the sequence number in the TDMoIP control word (see below). The RTP timestamp MUST be generated in accordance with the rules established in [RFC3550]; the clock frequency MUST be an integer multiple of 8 kHz, and MUST be chosen to enable timing recovery that conforms with the appropriate standards (see Section 7.2).
RTPを使用する場合、[RFC3550]に記載されている固定RTPヘッダーは、UDP/IP以外のすべてのPSN種別ではコントロールワードの直後に配置しなければなりません (MUST)。UDP/IPの場合は、コントロールワードの前に配置しなければなりません (MUST)。バージョン番号は2に設定しなければなりません (MUST)。RTPヘッダーのP（パディング）、X（ヘッダー拡張）、CC（CSRC数）、M（マーカー）フィールドは0に設定しなければなりません (MUST)。ペイロードタイプ（PT）値は動的値の範囲から割り当てなければなりません (MUST)。RTPシーケンス番号はTDMoIPコントロールワード内のシーケンス番号と同一でなければなりません (MUST)（以下を参照）。RTPタイムスタンプは[RFC3550]で定められた規則に従って生成しなければなりません (MUST)。クロック周波数は8 kHzの整数倍でなければなりません (MUST)。また、適切な標準（セクション7.2参照）に準拠したタイミング回復を可能にするように選択しなければなりません (MUST)。
The 32-bit control word MUST appear in every TDMoIP packet. Its format, in conformity with [RFC4385], is depicted in Figure 2.
32ビットのコントロールワードは、すべてのTDMoIPパケットに含まれなければなりません (MUST)。[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
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の場合、転送装置がディープパケット検査を行う際にパケットがIPパケットと誤認されないよう、コントロールワードの先頭ニブルを0に設定しなければなりません (MUST)。MPLS以外のPSNでは、先頭ニブルを0に設定してもかまいません (MAY)。ただし、以前の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ビット）：転送対象のTDMデータに影響するTDM物理層障害をIWFが検出した場合、またはその通知を受けた場合にLフラグを設定します。「トレイル延長」型のOAMでは、信号断、フレーム同期喪失、AISのいずれかをIWFが検出した場合、Lフラグを設定しなければなりません (MUST)。Lフラグが設定されていると、パケットの内容は意味をなさない可能性があり、帯域幅を節約するためペイロードを省略してもかまいません (MAY)。一度Lフラグを設定した後でTDM障害が解消した場合は、Lフラグを解除しなければなりません (MUST)。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ビット）：双方向接続の逆方向で障害が発生したことを示すため、リモートTDMネットワークからTDMデータを受信していないことをIWFが検出した場合、またはその通知を受けた場合にRフラグを設定します。IWFはRフラグの指示を受信したとき、TDM Remote Defect Indicator（RDI）を生成することが推奨されます (SHOULD)。「トレイル延長」型のOAMでは、IWFがRDIを検出した場合、Rフラグを設定しなければなりません (MUST)。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は、アラームを引き起こすべきでないアイドルTDMデータを示します。ペイロードを省略した場合、出力側で事前設定されたアイドルコードを生成すべきです。1 0は破損しているものの、回復できる可能性があるTDMデータを示します。1 1は予約済みです。
Use of the M field is further explained in Section 6.
Mフィールドの使用については、セクション6でさらに説明します。
RES (2 bits) These bits are reserved and MUST be set to zero.
RES（2ビット）：これらのビットは予約済みであり、0に設定しなければなりません (MUST)。
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.
Length（6ビット）：PSNの最小伝送単位の要件を満たすためにパディングを使う場合に、TDMoIPパケット（コントロールワードとペイロード）の長さを示します。PSNヘッダー、任意のRTPヘッダー、コントロールワード、ペイロードを含むパケット全体の長さが64バイト未満の場合、このフィールドを使用しなければなりません (MUST)。使用しない場合は0に設定しなければなりません (MUST)。
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.
Sequence number（16ビット）：TDMoIPシーケンス番号は、[RFC3985]で説明されている共通PW順序付け機能を提供し、パケットの損失や順序の乱れを検出できるようにします。シーケンス番号空間は16ビットの符号なし巡回空間です。セキュリティ上、初期値はランダム（予測困難）であるべきです (SHOULD)。値はPWごとに個別に2^16を法として増分されます。TDM側IWFで使用できるシーケンス番号処理アルゴリズムの疑似コードを付録Aに示します。
In order to form the TDMoIP payload, the PSN-bound IWF extracts bytes from the continuous TDM stream, filling each byte from its most significant bit. The extracted bytes are then adapted using one of two adaptation algorithms (see Section 5), and the resulting adapted payload is placed into the packet.
TDMoIPペイロードを形成するため、PSN側IWFは連続するTDMストリームからバイトを抽出し、各バイトの最上位ビットから順にビットを格納します。抽出したバイト列は、2つの適応アルゴリズムのいずれかで変換し（セクション5参照）、変換後のペイロードをパケットに格納します。
TDMoIP PWs may exploit various PSNs, including UDP/IP (both IPv4 and IPv6), L2TPv3 over IP (with no intervening UDP), MPLS, and layer-2 Ethernet. In the following subsections, we depict the packet format for these cases.
TDMoIP PWでは、UDP/IP（IPv4とIPv6の両方）、IP上のL2TPv3（途中にUDPを介さない）、MPLS、レイヤー2 Ethernetなど、さまざまなPSNを利用できます。以下の各節では、これらの場合のパケット形式を示します。
For MPLS PSNs, the format is aligned with those specified in [Y1413] and [Y1414]. For UDP/IP PSNs, the format is aligned with those specified in [Y1453] and [Y1452]. For transport over layer 2 Ethernet the format is aligned with [MEF8].
MPLS PSNの場合、形式は[Y1413]および[Y1414]で規定された形式に準拠します。UDP/IP PSNの場合は[Y1453]および[Y1452]で規定された形式に準拠します。レイヤー2 Ethernet上で転送する場合は[MEF8]に準拠した形式です。
ITU-T recommendation Y.1453 [Y1453] describes structure-agnostic and structure-aware mechanisms for transporting TDM over IP networks. Similarly, ITU-T recommendation Y.1452 [Y1452] defines structure-reassembly mechanisms for this purpose. Although the terminology used here differs slightly from that of the ITU, implementations of TDMoIP for UDP/IP PSNs as described herein will interoperate with implementations designed to comply with Y.1453 subclause 9.2.2 or Y.1452 clause 10.
ITU-T勧告Y.1453 [Y1453]は、IPネットワーク上でTDMを転送する構造非依存型および構造認識型の方式を記述しています。同様に、ITU-T勧告Y.1452 [Y1452]は、この目的のための構造再構成方式を規定しています。ここで使う用語はITUの用語とわずかに異なりますが、本書で説明するUDP/IP PSN向けTDMoIPの実装は、Y.1453のサブ条項9.2.2またはY.1452の条項10に準拠する実装と相互運用できます。
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
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のType of Serviceです。
Total Length (16 bits) is the length in bytes of header and data.
Total Length（16ビット）はヘッダーとデータを合わせたバイト数です。
Identification (16 bits) is the IP fragmentation identification field.
Identification（16ビット）はIPフラグメンテーション識別フィールドです。
Flags (3 bits) are the IP control flags and MUST be set to 2 in order to avoid fragmentation.
Flags（3ビット）はIP制御フラグです。フラグメント化を避けるため、値を2に設定しなければなりません (MUST)。
Fragment Offset (13 bits) indicates where in the datagram the fragment belongs and is not used for TDMoIP.
Fragment Offset（13ビット）はデータグラム内でのフラグメントの位置を示しますが、TDMoIPでは使用しません。
Time to Live (8 bits) is the IP time to live field. Datagrams with zero in this field are to be discarded.
Time to Live（8ビット）はIPの生存時間フィールドです。このフィールドが0のデータグラムは破棄します。
Protocol (8 bits) MUST be set to 0x11 (17) to signify UDP.
Protocol（8ビット）はUDPを示す0x11（17）に設定しなければなりません (MUST)。
IP Header Checksum (16 bits) is a checksum for the IP header.
IP Header Checksum（16ビット）はIPヘッダーのチェックサムです。
Source IP Address (32 bits) is the IP address of the source.
Source IP Address（32ビット）は送信元のIPアドレスです。
Destination IP Address (32 bits) is the IP address of the destination.
Destination IP Address（32ビット）は宛先のIPアドレスです。
Source and Destination Port Numbers (16 bits each)
Source and Destination Port Numbers（各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.
ノード間で個々のPWを多重化および逆多重化するため、ソースUDPポートまたは宛先UDPポートを使用してもかまいません (MAY)。アーキテクチャ上[RFC3985]では、この場合UDPポートがPWラベルとして機能します。PWの両端は、ソースUDPポートと宛先UDPポートのどちらをPWラベルとして使うか合意しなければなりません (MUST)。
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).
PWの両端ではUDPポートを手動で設定しなければなりません (MUST)。ソースポートまたは宛先ポートのいずれか一方（両方ではありません）の設定値と、送信元および宛先の両IPアドレスの組み合わせによって、PWを一意に識別します。ソースUDPポートをPWラベルとして使う場合、宛先UDPポート番号をIANA割り当て値0x085E（2142）に設定しなければなりません (MUST)。PWラベルとして使うUDPポート値はすべて、動的に割り当てられるUDPポート番号の範囲（0xC000～0xFFFF）内にすることが推奨されます (SHOULD)。
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ベースのプロトコルの多くは深刻な問題なくミドルボックスを通過できますが、UDPポートをPWラベルとして使うとミドルボックスを通過しにくくなります。したがって、PWの両端の間にポート変換を行うミドルボックスがある場合、UDPベースのPWを使用すべきではありません (SHOULD NOT)。
UDP Length (16 bits) is the length in bytes of UDP header and data.
UDP Length（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 Checksum（16ビット）はUDP/IPヘッダーとデータのチェックサムです。チェックサムを計算しない場合は0に設定しなければなりません (MUST)。
ITU-T recommendation Y.1413 [Y1413] describes structure-agnostic and structure-aware mechanisms for transporting TDM over MPLS networks. Similarly, ITU-T recommendation Y.1414 [Y1413] defines structure-reassembly mechanisms for this purpose. Although the terminology used here differs slightly from that of the ITU, implementations of TDMoIP for MPLS PSNs as described herein will interoperate with implementations designed to comply with Y.1413 subclause 9.2.2 or Y.1414 clause 10.
ITU-T勧告Y.1413 [Y1413]は、MPLSネットワーク上でTDMを転送する構造非依存型および構造認識型の方式を記述しています。同様に、ITU-T勧告Y.1414 [Y1413]は、この目的のための構造再構成方式を規定しています。ここで使う用語はITUの用語とわずかに異なりますが、本書で説明するMPLS PSN向けTDMoIPの実装は、Y.1413のサブ条項9.2.2またはY.1414の条項10に準拠する実装と相互運用できます。
The MPLS header as described in [RFC3032] is prefixed to the control word and TDM payload. The packet structure is depicted in Figure 4.
[RFC3032]に記載されたMPLSヘッダーをコントロールワードとTDMペイロードの前に付加します。パケット構造を図4に示します。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tunnel Label | EXP |S| TTL |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PW label | EXP |1| TTL |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RES |L|R| M |RES| Length | Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
opt|RTV|P|X| CC |M| PT | RTP Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
opt| Timestamp |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
opt| SSRC identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Adapted Payload |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4. TDMoIP Packet Format for MPLS
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].
Tunnel Label（20ビット）は、MPLSネットワークを通じてTDMパケットをトンネル転送するMPLS LSPを識別するラベルです。ラベルは手動設定またはMPLS制御プロトコルによって割り当てられます。MPLSネットワーク内の転送中に、トンネルラベルのスタックエントリーは0個、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ビット）はスタック末尾を示すビットです。すべてのトンネルラベルでは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 Label（20ビット）は有効なMPLSラベルでなければなりません (MUST)。設定するか、シグナリングによって通知してもかまいません (MAY)。
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
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.
Protocol（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.
Session 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.
Metro Ethernet Forum Implementation Agreement 8 [MEF8]は、Ethernetネットワーク上でTDMを転送する構造非依存型および構造認識型の方式を記述しています。本書で説明する構造指示型TDMoIPの実装は、MEF 8のセクション6.3.3に準拠する実装と相互運用できます。
The TDMoIP payload is encapsulated in an Ethernet frame by prefixing the Ethernet destination and source MAC addresses, optional VLAN header, and Ethertype, and suffixing the four-byte frame check sequence. TDMoIP implementations MUST be able to receive both industry standard (DIX) Ethernet and IEEE 802.3 [IEEE802.3] frames and SHOULD transmit Ethernet frames.
TDMoIPペイロードは、Ethernetの宛先および送信元MACアドレス、任意のVLANヘッダー、Ethertypeを先頭に付加し、4バイトのフレームチェックシーケンスを末尾に付加することで、Ethernetフレームにカプセル化されます。TDMoIP実装は、業界標準の（DIX）EthernetフレームとIEEE 802.3 [IEEE802.3]フレームの両方を受信できなければなりません (MUST)。また、Ethernetフレームを送信することが推奨されます (SHOULD)。
Ethernet encapsulation introduces restrictions on both minimum and maximum packet size. Whenever the entire TDMoIP packet is less than 64 bytes, padding is introduced and the true length indicated by using the Length field in the control word. In order to avoid fragmentation, the TDMoIP packet MUST be restricted to the maximum payload size. For example, the length of the Ethernet payload for a UDP/IP encapsulation of AAL1 format payload with 30 PDUs per packet is 1472 bytes, which falls below the maximal permitted payload size of 1500 bytes.
Ethernetカプセル化では、パケットサイズに最小値と最大値の制約が生じます。TDMoIPパケット全体が64バイト未満の場合はパディングを追加し、実際の長さをコントロールワードのLengthフィールドで示します。フラグメント化を避けるため、TDMoIPパケットのサイズを最大ペイロードサイズ以下に制限しなければなりません (MUST)。たとえば、パケットごとに30個のPDUを使うAAL1形式ペイロードをUDP/IPでカプセル化する場合、Ethernetペイロードの長さは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:
Ethernetフレームを、IP層やMPLS層を介さずにTDMoIP転送に使用してもかまいません (MAY)。ただし、MPLS形式のラベルは常に存在しなければなりません (MUST)。この4バイトヘッダーではS=1とし、ラベル以外のビットはすべて予約済みです（PSN側への転送方向では0に設定し、TDM側への転送方向では無視します）。Ethertypeは、IEEEがこの用途に割り当てた値0x88D8（35032）に設定することが推奨されます (SHOULD)が、MPLSのEthertypeである0x8847（34887）に設定してもかまいません (MAY)。フレーム全体の構造を以下に示します。
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
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）Ethernetヘッダーです。802.3ではLengthフィールドの値によって追加フィールドがある場合があります。[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].
Destination MAC Address（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].
Source MAC Address（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を一意に識別します。値が0の場合、意味を持つのは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）に設定することが推奨されます (SHOULD)が、0x8847（34887）に設定してもかまいません (MAY)。
PW Label (20 bits) This label MUST be manually configured. The remainder of this row is formatted to resemble an MPLS label.
PW Label（20ビット）：このラベルは手動で設定しなければなりません (MUST)。この行の残りの部分はMPLSラベルに似た形式です。
Frame Check Sequence (32 bits) is a Cyclic Redundancy Check (CRC) error detection field, calculated per [IEEE802.3].
Frame Check Sequence（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種類の適応アルゴリズムを提供します。
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モードを使用しなければなりません (MUST)。使用状況が比較的一定の回線にもAAL1を使用することが推奨されます (SHOULD)。TDM側IWFで高精度のタイミングを維持する必要がある場合（たとえば、そのタイミングをさらに配信する場合）はAAL1を使用しなければなりません (MUST)。高い信頼性が必要な場合もAAL1の使用が推奨されます (SHOULD)。帯域幅を節約する必要があるチャネル化TDMにはAAL2の使用が推奨され (SHOULD)、音声を運ぶチャネルの使用状況が大きく変動すると予想される場合はAAL2を使用してもかまいません (MAY)。
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.
さらに、TDMチャネルで運ばれるHigh-Level Data Link Control（HDLC）ベースのCommon Channel Signaling（CCS）を効率的に転送するため、専用の第3のモードを定義します。
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エミュレーションに適した選択肢です。AALはもともと、さまざまな種類のアプリケーションデータを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]に、ATM上の回線エミュレーションにAAL1を使用する方法は[CES]に記述されています。付録BではAAL1技術の要点を簡潔に確認します。この節ではTDMoIPにおけるAAL1の使用方法を説明します。
+-------------+----------------+
|control word | AAL1 PDU |
+-------------+----------------+
Figure 7a. Single AAL1 PDU per TDMoIP Packet
+-------------+----------------+ +----------------+
|control word | AAL1 PDU |---| AAL1 PDU |
+-------------+----------------+ +----------------+
Figure 7b. Multiple AAL1 PDUs per TDMoIP Packet
In AAL1 mode the TDMoIP payload consists of at least one, and perhaps many, 48-byte "AAL1 PDUs", see Figures 7a and 7b. The number of PDUs MUST be pre-configured and MUST be chosen such that the overall packet size does not exceed the maximum allowed by the PSN (e.g., 30 for UDP/IP over Ethernet). The precise number of PDUs per packet is typically chosen taking latency and bandwidth constraints into account. Using a single PDU delivers minimal latency, but incurs the highest overhead. All TDMoIP implementations MUST support between 1 and 8 PDUs per packet for E1 and T1 circuits, and between 5 and 15 PDUs per packet for E3 and T3 circuits.
AAL1モードでは、TDMoIPペイロードは48バイトの「AAL1 PDU」を少なくとも1個、多い場合は複数個含みます（図7aおよび図7b参照）。PDU数は事前に設定しなければなりません (MUST)。また、パケット全体のサイズがPSNで許容される最大値を超えないように選ばなければなりません (MUST)（たとえば、Ethernet上のUDP/IPでは30個です）。パケット当たりの正確なPDU数は、通常、遅延と帯域幅の制約を考慮して選びます。PDUを1個にすると遅延を最小限にできますが、オーバーヘッドは最大になります。すべてのTDMoIP実装は、T1およびE1回線ではパケット当たり1～8個、T3およびE3回線では5～15個のPDUをサポートしなければなりません (MUST)。
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]は構造化モードと、Channel Associated Signaling（CAS）を伴う構造化モードの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回線を転送するよう設定できますが、一定レートのビットストリームを転送するため、転送対象チャネルの割り当ては静的でなければなりません。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
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 PDU」が含まれます（図8参照）。各AAL2 PDUには3バイトのオーバーヘッドと1～64バイトのペイロードが含まれます。パケットは、アクティブな全チャネルに対応するPDUを挿入する方法、特定時点で利用可能なPDUを追加する方法、その他の方法で構成できます。そのため、1つのチャネルに属する複数の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]では、TDMデータをペイロードとして使う前に行うすべての処理をNative Service Processing（NSP）機能と呼びます。AAL2は本質的に可変レートであるため、チャネルをAAL2ループエミュレーションのペイロードに格納する前に、任意のNSP機能を実行してもかまいません (MAY)。これには、オンフック／オフフック状態の検査、音声アクティビティ検出、音声圧縮、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,SSCS,LES]に記載されたすべての方式をTDMoIPで使用できます。特に、[AAL2]に従ったチャネル識別子（CID）の符号化とPADオクテットの使用、[SSCS]で定義された符号化形式、[LES]で説明されたCASおよびCCSシグナリングの転送は、いずれもPSN側への転送方向で使用してもかまいません (MAY)。また、これらはTDM側への転送方向でサポートしなければなりません (MUST)。オーバーラップ機能、AAL-CUタイマーおよび関連機能は不要な場合があり、STF（Start Field）は使用しません。PSNが適切な誤り検出機構を提供する場合、誤り検出符号、すなわちAAL2 PDUヘッダーのHeader Error Check（HEC）およびCASパケットのCRCを計算しても意味がありません。その場合、これらのフィールドを0に設定してもかまいません (MAY)。
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]などのCommon Channel Signaling（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に従って行うことが推奨されます (SHOULD)。
The PSN-bound IWF monitors flags until a frame is detected. The contents of the frame are collected and the Frame Check Sequence (FCS) tested. If the FCS is incorrect, the frame is discarded; otherwise, the frame is sent after initial or final flags and FCS have been discarded and zero removal has been performed. When a TDMoIP-HDLC frame is received, its FCS is recalculated, and the original HDLC frame reconstituted.
PSN側IWFはフレームを検出するまでフラグを監視します。フレームの内容を収集し、Frame Check Sequence（FCS）を検査します。FCSが誤っている場合、フレームを破棄します。正しい場合は、先頭または末尾のフラグとFCSを取り除き、ゼロ除去を行ってからフレームを送信します。TDMoIP-HDLCフレームを受信すると、FCSを再計算して元のHDLCフレームを再構成します。
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転送では、こうした表示をすべて透過的に転送します。一方、障害表示を含むTDM構造オーバーヘッドをPSN側IWFが取り除く可能性のある構造認識型方式では、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
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フローを考えると理解しやすくなります。このフローはTDM端末ES1から始まり、TDMネットワーク1、TDMoIP IWF1、PSN、TDMoIP IWF2、TDMネットワーク2を順に通ってTDM端末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ノードがTDMoIP IWF1に向かって下流方向にAISを生成します。最終リンクで断線した場合は、IWF自体が信号断を検出します。どちらの場合も、IWF1はTDM信号が無効であることを直接検出したか、先行する障害の通知を受けたため、PSN上へ送信するパケットのコントロールワードにローカル（L）障害フラグを設定します。このようにして、PSNを越えてTDMネットワーク2までトレイルを延長します。
Unlike forward defect indications that are generated by all network elements, reverse defect indications are only generated by trail termination functions. In the trail terminated scenario, IWF1 serves as a trail termination function for TDM network 1, and thus when IWF1 directly detects lack of validity of the TDM signal, or is informed of an earlier problem, it MAY generate TDM RDI towards TDM ES1. In the trail extended scenario IWF1 is not a trail termination, and hence MUST NOT generate TDM RDI, but rather, as we have seen, sets the L defect flag. As we shall see, this will cause the AIS indication to reach ES2, which is the trail termination, and which MAY generate TDM RDI.
全ネットワーク要素が生成する順方向障害表示とは異なり、逆方向障害表示はトレイル終端機能だけが生成します。トレイル終端型の状況では、IWF1はTDMネットワーク1のトレイル終端機能として動作します。そのため、TDM信号が無効であることを直接検出した場合、または先行する障害の通知を受けた場合、TDM ES1に向けてTDM RDIを生成してもかまいません (MAY)。トレイル延長型の状況ではIWF1はトレイル終端ではないため、TDM RDIを生成してはなりません (MUST NOT)。代わりに、これまで説明したとおりL障害フラグを設定します。するとAIS表示がトレイル終端であるES2まで届き、ES2はTDM RDIを生成してもかまいません (MAY)。
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データ（通常は全ビット1）を入れます。IWFより手前でAISが生成されていれば、受信したTDMデータをコピーすることで実現できます。最後から2番目のTDMリンクが故障し、IWF自身がAISを生成する必要がある場合もあります。別の方法として、チャネル化TDMの構造認識型転送では、ペイロードに「トランク条件付け」を行うことが推奨されます (SHOULD)。これは、各チャネルに事前設定された「サービス停止」コードを入れる方法です（音声チャネルとデータチャネルではコードが異なる場合があります）。複数のTDM PWから取り出したチャネルをTDM側IWFが1つのTDM回線にまとめる場合、トランク条件付けを使用しなければなりません (MUST)。第3の方法はペイロード全体を省略することです。最後に、IWF1がTDM障害は軽微または修復可能だと判断した場合（マルチフレーム同期の喪失や、不正なフレーム同期を検出した初期段階など）、受信したTDMデータをペイロードフィールドに入れてもかまいません (MAY)。その際、M（障害修飾子）フィールドで、TDMデータは破損しているものの回復可能な可能性があることを示します。
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とトランク条件付けのどちらを使うかは事前設定されています）。これにより、TDM端末から見て従来のTDM動作を再現し、AISをES2へ正しく届けます。さらに、IWF2がLフラグを受信したことにより、障害がTDMネットワーク2ではなくTDMネットワーク1にあったと特定できるため、正常に動作しているネットワークでの警報を抑止できます。
If the M field indicates that the TDM has been marked as potentially recoverable, then implementation specific algorithms (not herein specified) may optionally be utilized to minimize the impact of transient defects on the overall network performance. If the M field indicates that the TDM is "idle", no alarms should be raised and IWF2 treats the payload contents as regular TDM data. If the payload has been suppressed, trunk conditioning and not AIS MUST be generated by IWF2.
MフィールドがTDMデータを回復可能な可能性があるものとして示している場合、過渡的な障害がネットワーク全体の性能に与える影響を抑えるため、実装固有のアルゴリズム（本書では規定しません）を任意で使用できます。MフィールドがTDMデータを「アイドル」と示す場合は警報を発生させず、IWF2はペイロード内容を通常のTDMデータとして扱います。ペイロードが省略されている場合は、AISではなくトランク条件付けをIWF2が生成しなければなりません (MUST)。
The second case is when the defect is in TDM network 2. Such defects cause AIS generation towards ES2, which may respond by sending TDM RDI in the reverse direction. In the trail terminated scenario this RDI is restricted to network 2. In the trail extended scenario, IWF2 upon observing this RDI inserted into valid TDM data, MUST indicate this by setting the "R" flag in packets sent back across the PSN towards IWF1. IWF1, upon receiving this indication, generates RDI towards ES1, thus emulating a single conventional TDM network.
2つ目の状況は、障害がTDMネットワーク2にある場合です。このような障害によりES2に向けてAISが生成され、ES2は逆方向にTDM RDIを送信して応答する場合があります。トレイル終端型では、このRDIはネットワーク2内に限定されます。トレイル延長型では、有効なTDMデータに挿入されたRDIをIWF2が検出した場合、PSNを介してIWF1へ返送するパケットにRフラグを設定してこれを示さなければなりません (MUST)。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には届きません。IWF2はこの問題をPSNの管理システムに通知し、さらにES2に向けてTDM AISを生成しなければなりません (MUST)。ES2はTDM RDIで応答する場合があります。これまでと同様に、トレイル延長型では、IWF2がRDIを検出したときにRフラグを設定しなければなりません (MUST)。IWF1がRフラグの設定されたパケットを受信すると、逆方向の障害が通知されたことになるため、ES1に向けてTDM RDIを生成しなければなりません (MUST)。
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 PWは本質的に双方向であるため、どちらか一方向の障害が継続した場合も双方向サービスの障害となります。また、セクション5.3に従ってシグナリングを別のPWで送信している場合、どちらかの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を撤回しなければなりません (MUST)。両方のTDMoIP IWFは、それぞれのTDMネットワークにAIS（トランク条件付けではありません）を送信し始めます。その後、接続が回復するまで、付録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にも存在するパケット遅延変動を吸収するため、ジッターバッファを設けなければなりません (MUST)。ジッターバッファは、PSNから可変の到着間隔で届くデータを書き込み、一定の速度で読み出して宛先のTDM機器に送るメモリ領域です。ジッターバッファを使うと、追加の遅延を除き、従来の同期TDMネットワークではなくPSNを通過したことをある程度隠せます。通常はバッファをおよそ半分まで満たして動作させ、オーバーフローまたはアンダーフローの確率を最小にします。このため追加遅延はジッターバッファ容量の半分になります。ジッターバッファの長さは設定可能にすることが推奨され (SHOULD)、動的に変化させてもかまいません (MAY)（つまり、パケット遅延変動（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.
（まれに発生する）パケット損失や順序逆転に対処するため、パケットシーケンスの完全性を保つ機構を設けなければなりません (MUST)。この機構は到着したパケットのシーケンス番号を追跡しなければならず (MUST)、異常を検出した場合は適切な処置を行わなければなりません (MUST)。損失パケットを検出した場合、TDMのタイミングを保つためにフィラーデータを出力しなければなりません (MUST)。順序どおりでないパケットは並べ替えることが推奨されます (SHOULD)。損失パケットの処理では、適切なFASをTDMネットワークに送ることが推奨されます (SHOULD)。シーケンス番号処理アルゴリズムの例を付録Aに示します。
While the insertion of arbitrary filler data may be sufficient to maintain the TDM timing, for telephony traffic it may lead to audio gaps or artifacts that result in choppy, annoying or even unintelligible audio. An implementation MAY blindly insert a preconfigured constant value in place of any lost samples, and this value SHOULD be chosen to minimize the perceptual effect. Alternatively one MAY replay the previously received packet. When computational resources are available, implementations SHOULD conceal the packet loss event by properly estimating missing sample values in such fashion as to minimize the perceptual error.
任意のフィラーデータを挿入するだけでもTDMのタイミングを維持できる場合がありますが、電話通信では音声の途切れやノイズが生じ、聞き取りにくくなったり理解できなくなったりすることがあります。実装は、損失したサンプルの代わりに事前設定した固定値をそのまま挿入してもかまいません (MAY)。この値は知覚上の影響を最小限にするものを選ぶことが推奨されます (SHOULD)。別の方法として、直前に受信したパケットを再生してもかまいません (MAY)。計算資源に余裕がある場合、実装は知覚誤差を最小限にするよう欠落サンプル値を適切に推定し、パケット損失を隠蔽することが推奨されます (SHOULD)。
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つ常に存在します。このノードが、やや精度の低い二次ノードに基準タイミングを供給し、二次ノードはさらにタイミング情報を配信します。この時刻同期の階層はネットワーク全体を適切に動作させるために不可欠です。詳細は[G823][G824]を参照してください。
Packets in PSNs reach their destination with delay that has a random component, known as packet delay variation (PDV). When emulating TDM on a PSN, extracting data from the jitter buffer at a constant rate overcomes much of the high frequency component of this randomness ("jitter"). The rate at which we extract data from the jitter buffer is determined by the destination clock, and were this to be precisely matched to the source clock proper timing would be maintained. Unfortunately, the source clock information is not disseminated through a PSN, and the destination clock frequency will only nominally equal the source clock frequency, leading to low frequency ("wander") timing inaccuracies.
PSN内のパケットは、パケット遅延変動（PDV）と呼ばれるランダムな遅延を伴って宛先に到着します。PSN上でTDMをエミュレートする際、ジッターバッファから一定の速度でデータを取り出すと、このランダム性の高周波成分（「ジッター」）の大部分を除去できます。データを取り出す速度は宛先クロックで決まり、そのクロックを送信元クロックに正確に合わせれば適切なタイミングを維持できます。しかし、PSNを通じて送信元クロック情報を伝達することはできず、宛先クロックの周波数は送信元クロックと公称上同じであるにとどまります。その結果、低周波のタイミング誤差（「ワンダー」）が生じます。
In broadest terms, there are four methods of overcoming this difficulty. In the first and second methods timing information is provided by some means independent of the PSN. This timing may be provided to the TDM end systems (method 1) or to the IWFs (method 2). In a third method, a common clock is assumed available to both IWFs, and the relationship between the TDM source clock and this clock is encoded in the packet. This encoding may take the form of RTP timestamps or may utilize the synchronous residual timestamp (SRTS) bits in the AAL1 overhead. In the final method (adaptive clock recovery) the timing must be deduced solely based on the packet arrival times. Example scenarios are detailed in [RFC4197] and in [Y1413].
大別すると、この問題を解決する方法は4つあります。第1と第2の方法では、PSNとは独立した何らかの手段でタイミング情報を供給します。供給先はTDM端末（方法1）またはIWF（方法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.
適応クロック回復では、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]が定めるTDMインターフェイスのジッターおよびワンダーの仕様に適合しなければなりません (MUST)。用途によっては、さらに厳しいジッターおよびワンダーの許容値を課してもかまいません (MAY)。
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上で転送すべきです (SHOULD)。保証サービス（GS）[RFC2212]をサポートするIntServ対応ドメインや、優先転送（EF）[RFC3246]をサポートするDiffserv対応ドメイン[RFC2475]は、そのようなPSNの例です。こうした機構は、隣接するストリームに対するTDMoIPの影響をある程度打ち消します。IP PSN上のTDMoIPトラフィックに対する境界トラフィックコンディショニングを容易にするため、TDMoIPパケットではデフォルトのPer-Hop Behavior（PHB）[RFC2474]に予約されたDiffserv Code Point（DSCP）値を使用すべきではありません (SHOULD NOT)。
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].
ベストエフォートサービスを提供するPSN上でTDMoIPを運用する場合、輻輳を検出するためにパケット損失を監視することが推奨されます (SHOULD)。輻輳が検出され、帯域幅を削減できる場合は、その削減を実施することが推奨されます (SHOULD)。帯域幅を削減できない場合、[RFC3985]のセクション6.5で説明されているように、TDMoIP PWを一定期間、双方向に停止することが推奨されます (SHOULD)。
Note that:
次の点に留意してください。
1. In AAL1 mode TDMoIP can inherently provide packet loss measurement since the expected rate of packet arrival is fixed and known.
1. AAL1モードでは、パケットの到着間隔が一定で既知であるため、TDMoIPはパケット損失を本質的に測定できます。
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]参照）。一時停止を決める際には、この目標を考慮しなければなりません (MUST)。
This specification does not define exact criteria for detecting severe congestion or specific methods for TDMoIP shutdown or subsequent re-start. However, the following considerations may be used as guidelines for implementing the shutdown mechanism:
この仕様では、深刻な輻輳を検出する厳密な基準も、TDMoIPを停止または再開する具体的な方法も定めていません。ただし、停止機構を実装する際には、次の点を指針として利用できます。
1. If the TDMoIP PW has been set up using the PWE3 control protocol [RFC4447], the regular PW teardown procedures of these protocols SHOULD be used.
1. TDMoIP PWをPWE3制御プロトコル[RFC4447]で設定した場合は、このプロトコルで定められた通常のPW解放手順を使用することが推奨されます (SHOULD)。
2. If one of the TDMoIP IWFs stops transmission of packets for a sufficiently long period, its peer (observing 100% packet loss) will necessarily detect "severe congestion" and also stop transmission, thus achieving bi-directional PW shutdown.
2. 一方のTDMoIP IWFが十分に長い期間パケット送信を停止すると、ピアはパケット損失率100%を観測します。その結果、ピアは必然的に「深刻な輻輳」を検出して送信も停止し、PWの双方向停止が実現します。
TDMoIP does not provide mechanisms to ensure timely delivery or provide other quality-of-service guarantees; hence it is required that the lower-layer services do so. Layer 2 priority can be bestowed upon a TDMoIP stream by using the VLAN priority field, MPLS priority can be provided by using EXP bits, and layer 3 priority is controllable by using TOS. Switches and routers which the TDMoIP stream must traverse should be configured to respect these priorities.
TDMoIPには、タイムリーな転送やその他のサービス品質保証を実現する機構がありません。そのため、これらは下位層のサービスが提供する必要があります。VLAN優先度フィールドでTDMoIPストリームにレイヤー2の優先度を付け、EXPビットでMPLSの優先度を付け、TOSでレイヤー3の優先度を制御できます。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サービスより低い場合があります。
TDMoIP shares susceptibility to a number of pseudowire-layer attacks (see [RFC3985]) and implementations SHOULD use whatever mechanisms for confidentiality, integrity, and authentication are developed for general PWs. These methods are beyond the scope of this document.
TDMoIPは、擬似ワイヤ層を狙うさまざまな攻撃に対して脆弱です（[RFC3985]参照）。実装では、一般的なPW向けに開発される機密性、完全性、認証の各機構を使用することが推奨されます (SHOULD)。これらの方式は本書の範囲外です。
Random initialization of sequence numbers, in both the control word and the optional RTP header, makes known-plaintext attacks on encrypted TDMoIP more difficult. Encryption of PWs is beyond the scope of this document.
コントロールワードと任意のRTPヘッダーの両方でシーケンス番号をランダムに初期化すると、暗号化されたTDMoIPに対する既知平文攻撃を困難にできます。PWの暗号化は本書の範囲外です。
PW labels SHOULD be selected in an unpredictable manner rather than sequentially or otherwise in order to deter session hijacking. When using L2TPv3, a cryptographically random [RFC4086] Cookie SHOULD be used to protect against off-path packet insertion attacks, and a 64- bit Cookie is RECOMMENDED for protection against brute-force, blind, insertion attacks.
セッションハイジャックを防ぐため、PWラベルは連番などの予測可能な方法ではなく、予測困難な方法で選ぶべきです (SHOULD)。L2TPv3を使う場合、経路外からのパケット挿入攻撃を防ぐため、暗号学的に安全な乱数で生成したCookie [RFC4086]を使うべきです (SHOULD)。総当たりの盲目的なパケット挿入攻撃に対しては、64ビットCookieが推奨されます (SHOULD)。
Although TDMoIP MAY employ an RTP header when explicit transfer of timing information is required, SRTP (see [RFC3711]) mechanisms are not applicable.
タイミング情報を明示的に転送する必要がある場合、TDMoIPではRTPヘッダーを使用してもかまいません (MAY)。ただし、SRTP機構（[RFC3711]参照）は適用されません。
For MPLS PSNs, PW Types for TDMoIP PWs are allocated in [RFC4446].
MPLS PSN向け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 PSNでソースポートをPWラベルとして使う場合、宛先ポート番号を0x085E（2142）に設定しなければなりません (MUST)。この値はIANAがTDMoIP用に割り当てたユーザーポート番号です。
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接続はポイントツーポイントですが、PSNは共有インフラストラクチャです。そのため、エミュレートしたサービスのセキュリティ水準は従来のサービスより低い場合があります。
The authors would like to thank Hugo Silberman, Shimon HaLevy, Tuvia Segal, and Eitan Schwartz of RAD Data Communications for their invaluable contributions to the technology described herein.
著者は、RAD Data CommunicationsのHugo Silberman、Shimon HaLevy、Tuvia Segal、Eitan Schwartzに、この文書で説明する技術への多大な貢献について謝意を表します。
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.
コントロールワードのシーケンス番号フィールドにより、パケットの損失や順序逆転を検出できます。ここでは、関連する論点を明確にするため、アルゴリズムの例を疑似コードで示します。これらの論点は実装固有であり、1つの説明ですべての可能性を網羅できるわけではありません。
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バイト単位のプレイアウトバッファではなく、パケット単位のプレイアウトバッファを使って説明します。ただし、並べ替えを実装する際にパケット単位のバッファが必須というわけではなく、TDMバイト単位のバッファをパケット開始位置へのポインターと組み合わせて使用できます。
Having introduced the playout buffer we explicitly treat over-run and under-run of this buffer. Over-run occurs when packets arrive so quickly that they can not be stored for playout. This is usually an indication of gross timing inaccuracy or misconfiguration, and we can do little but discard such early packets. Under-run is usually a sign of network starvation, resulting from congestion or network failure.
プレイアウトバッファを導入したので、ここではバッファのオーバーランとアンダーランを明示的に扱います。パケットがあまりに速く到着し、再生用にバッファへ格納できない場合にオーバーランが発生します。通常これはタイミングの大幅な不一致や設定ミスを示すため、早着パケットを破棄する以外にできることはほとんどありません。アンダーランは通常、輻輳やネットワーク障害によるネットワークからのデータ供給不足を示します。
The external variables used by the pseudocode are:
疑似コードで使用する外部変数は次のとおりです。
received: sequence number of packet received played: sequence number of the packet being played out (Note 1) over-run: is the playout buffer full? (Note 3) under-run: has the playout buffer been exhausted? (Note 3)
received：受信したパケットのシーケンス番号。played：再生中のパケットのシーケンス番号（注1）。over-run：プレイアウトバッファは満杯か（注3）。under-run：プレイアウトバッファは空か（注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)
expected：次に受信すると予想するシーケンス番号。D：expectedとreceivedの差（注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
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ビット）：AAL1のシーケンス番号はPDUごとに増分します。
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で1周するシーケンス番号サイクルが形成されます。その重要性はすぐに明らかになります。
The structure of the remaining 47 bytes in the AAL1 PDU depends on the PDU type, of which there are three, corresponding to the three types of AAL1 circuit emulation service defined in [CES]. These are known as unstructured circuit emulation, structured circuit emulation, and structured circuit emulation with CAS.
AAL1 PDUの残り47バイトの構造はPDU型によって異なります。PDU型は3種類あり、[CES]で定義されたAAL1回線エミュレーションサービスの3種類に対応します。非構造化回線エミュレーション、構造化回線エミュレーション、CASを伴う構造化回線エミュレーションです。
The simplest PDU is the unstructured one, which is used for transparent transfer of whole circuits (T1,E1,T3,E3). Although AAL1 provides no inherent advantage as compared to SAToP for unstructured transport, in certain cases AAL1 may be required or desirable. For example, when it is necessary to interwork with an existing AAL1- based network, or when clock recovery based on AAL1-specific mechanisms is favored.
最も単純なPDUは非構造化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個のAAL1 PDUに1 183/193個のT1フレームが収まります。E1フレームは256ビットなので、1個のPDUに1 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回線エミュレーションサービスのいずれかを使うと有利です。構造化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の47バイトすべてを埋めます。
byte 1 2 3 4 5 6 7 8 9 10 --- 41 42 43 44 45 46 47 channel 2 3 5 7 11 2 3 5 7 11 --- 2 3 5 7 11 2 3
The next PDU commences where the present PDU left off.
次のPDUは、前のPDUの続きから始まります。
byte 1 2 3 4 5 6 7 8 9 10 --- 41 42 43 44 45 46 47 channel 5 7 11 2 3 5 7 11 2 3 --- 5 7 11 2 3 5 7
And so forth. The set of channels 2,3,5,7,11 is the basic structure and the point where one structure ends and the next commences is the structure boundary.
このように続きます。チャネル2、3、5、7、11の集合が基本構造です。ある構造が終わり、次の構造が始まる位置を構造境界と呼びます。
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ごとに先頭チャネルが異なるため、パケットを1つ失うと、それ以降のチャネルを誤って識別し、復旧できなくなります。この問題を解決するため、次の構造境界へのポインターを定期的に挿入します。パケットが失われない限りチャネルを一意に推定できるため、ポインターを頻繁に使う必要はありません。
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からなるシーケンス番号サイクルごとに1回、ポインターを挿入します。ポインターは7ビットで、偶数パリティの最上位ビット（MSB）によって保護されるため、1バイトを占めます。7ビットあれば47を超えるオフセットも表せるため、ポインターバイトをシーケンス番号が偶数のPDUにだけ配置できます。47バイトのTDMデータを含む通常のAAL1 PDUとは異なり、ポインターを含むPDU（P形式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形式PDUでは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.
pointer（7ビット）は次の構造境界を指すポインターです。
Since P-format PDUs have 46 bytes of payload and the next PDU has 47 bytes, viewed as a single entity the pointer needs to indicate one of 93 bytes. If P=0 it is understood that the structure commences with the following byte (i.e., the first byte in the payload belongs to the lowest numbered channel). P=93 means that the last byte of the second PDU is the final byte of the structure, and the following PDU commences with a new structure. The special value P=127 indicates that there is no structure boundary to be indicated (needed when extremely large structures are being transported).
P形式PDUのペイロードは46バイトで、次のPDUは47バイトです。そのため、両方を1つの連続領域として見ると、ポインターは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形式PDUは、構造境界が現れるシーケンス番号サイクル内で可能な限り最初の位置に常に配置され、1サイクルにつき1回だけ現れます。
The only difference between the structured circuit emulation format and structured circuit emulation with CAS is the definition of the structure. Whereas in structured circuit emulation the structure is composed of the N channels, in structured circuit emulation with CAS the structure encompasses the superframe consisting of multiple repetitions of the N channels and then the CAS signaling bits. The CAS bits are tightly packed into bytes and the final byte is padded with zeros if required.
構造化回線エミュレーション形式とCASを伴う構造化回線エミュレーション形式の違いは、構造の定義だけです。前者の構造はN個のチャネルで構成されます。後者の構造は、N個のチャネルを複数回繰り返した後にCASシグナリングビットを加えたスーパーフレームを含みます。CASビットはバイト単位に隙間なく詰められ、必要に応じて最後のバイトを0でパディングします。
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が奇数の場合は最後に0を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]
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フレームで、構造はNバイトを24回繰り返した後に、前述のABCDビットを並べます。T1では通常、シグナリングビットは本来の（ビット盗用された）位置と構造の末尾の2か所に現れます。
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も予約済みです。そのため、PWごとのCID数は通常248個、VoDSLとの相互接続時は240個です。CID値とチャネルの対応付けは手動で設定しても、シグナリングで通知してもかまいません (MAY)。
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の範囲となり、チャネルバッファを送信するたびに16を法として増分することが推奨されます (SHOULD)。受信側はこのシーケンスを監視してもかまいません (MAY)。CASシグナリングパケットではUUIを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ビットの状態が変化するたびにシグナリングを送信しなければなりません (MUST)。また、3重冗長で送信することが推奨されます (SHOULD)。つまり、5ミリ秒間隔で3回送信します。信頼性を確保するため、シグナリングビット一式を定期的に送信することも推奨されます (SHOULD)。
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|RED| timestamp |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RES | ABCD | type | CRC
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
CRC (cont) |
+-+-+-+-+-+-+-+-+
RED (2 bits) is the triple redundancy counter. For the first packet it takes the value 00, for the second 01 and for the third 10. RED=11 means non-redundant information, and is used when triple redundancy is not employed, and for periodic refresh messages.
RED（2ビット）は3重冗長カウンターです。1番目のパケットでは00、2番目では01、3番目では10になります。RED=11は非冗長情報を示し、3重冗長を使わない場合や定期的な更新メッセージに使います。
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.
Timestamp（14ビット）は任意であり、特にRTPを使う場合は不要です。使用しない場合、タイムスタンプを0に設定しなければなりません (MUST)。3重冗長とともに使う場合は、3つの冗長送信すべてで同じ値にしなければなりません (MUST)。
RES (4 bits) is reserved and MUST be set to zero.
RES（4ビット）は予約済みであり、0に設定しなければなりません (MUST)。
ABCD (4 bits) are the CAS signaling bits.
ABCD（4ビット）はCASシグナリングビットです。
type (6 bits) for CAS signaling this is 000011.
type（6ビット）：CASシグナリングの場合、値は000011です。
CRC-10 (10 bits) is a 10-bit CRC error detection code.
CRC-10（10ビット）は10ビットのCRC誤り検出コードです。
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 PWでは、適応タイミング回復やパケット損失隠蔽のアルゴリズムがこの情報を活用できます。また、OAM機構で下位PSN [RFC2330]の統計情報を収集し、TDMサービスの転送に適しているか評価できます。
TDMoIP IWFs may benefit from knowledge of PSN performance metrics, such as round trip time (RTT), packet delay variation (PDV) and packet loss ratio (PLR). These measurements are conventionally performed by a separate flow of packets designed for this purpose, e.g., ICMP packets [RFC792] or MPLS LSP ping packets [RFC4379] with multiple timestamps. For AAL1 mode, TDMoIP sends packets across the PSN at a constant rate, and hence no additional OAM flow is required for measurement of PDV or PLR. However, separate OAM flows are required for RTT measurement, for AAL2 mode PWs, for measurement of parameters at setup, for monitoring of inactive backup PWs, and for low-rate monitoring of PSNs after PWs have been withdrawn due to service failures.
TDMoIP IWFは、往復時間（RTT）、パケット遅延変動（PDV）、パケット損失率（PLR）など、PSNの性能指標に関する情報を活用できます。これらの指標は通常、専用のパケットフローを使って測定します。たとえば、ICMPパケット[RFC792]や複数のタイムスタンプを含むMPLS LSP pingパケット[RFC4379]を使います。AAL1モードではTDMoIPが一定レートでPSN上にパケットを送るため、PDVやPLRの測定に追加のOAMフローは不要です。一方、RTTの測定、AAL2モードのPW、設定時のパラメーター測定、非アクティブなバックアップPWの監視、サービス障害でPWを撤回した後のPSNの低頻度監視には、別個の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、PLRを測定でき、それらの測定値がPWの測定値とよく相関する場合、その機構を使用すべきです (SHOULD)。そのような機構がない場合は、類似する2種類のOAMシグナリング機構のいずれかを使用できます。1つ目はPW内で動作するインバンドVCCV [RFC5085]に基づく方式です。2つ目はUDP/IP PSNだけを対象とし、別個のPWを使う方式です。後者は、同じ障害共有関係にある多数のTDM PWを扱う場合に特に効率的です。
In most conventional IP applications a server sends some finite amount of information over the network after explicit request from a client. With TDMoIP PWs the PSN-bound IWF could send a continuous stream of packets towards the destination without knowing whether the TDM-bound IWF is ready to accept them. For layer-2 networks, this may lead to flooding of the PSN with stray packets.
一般的なIPアプリケーションでは、クライアントから明示的な要求を受けたサーバーが、有限量の情報をネットワーク経由で送信します。TDMoIP PWでは、PSN側IWFがTDM側IWFの受信準備を確認できないまま、宛先へパケットを連続送信することがあります。レイヤー2ネットワークでは、その結果、行き先のないパケットがPSN内にフラッディングされる可能性があります。
This problem may occur when a TDMoIP IWF is first brought up, when the TDM-bound IWF fails or is disconnected from the PSN, or the PW is broken. After an aging time the destination IWF becomes unknown, and intermediate switches may flood the network with the TDMoIP packets in an attempt to find a new path.
この問題は、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メッセージを定期送信し、宛先が各メッセージに応答することで検査します。設定および構成時には接続性検証機構を使用すべきです (SHOULD)。OAMシグナリングを使わない場合、送信開始前に宛先IWFがパケットを受信できる状態であることを確認する必要があります。TDMoIP IWFは全二重で動作するため、フラッディングを避けるには両方の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指標を要求および報告できます。リモート診断や、問題の可能性を自発的に通知する用途（たとえばdying 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.
インバンド性能監視では、同じPWラベルを使って追加パケットを送信します。これらのパケットは先頭ニブルが0001であることで識別され、コントロールワードを処理する前にTDMデータパケットから分離する必要があります。
When using a separate OAM PW, all OAM messages MUST use the PW label preconfigured to indicate OAM. All PSN layer parameters MUST remain those of the PW being monitored.
別個のOAM PWを使う場合、すべてのOAMメッセージはOAM用に事前設定されたPWラベルを使用しなければなりません (MUST)。すべてのPSN層パラメーターは、監視対象のPWと同じ値に保たなければなりません (MUST)。
The format of an inband OAM PW message packet for UDP/IP PSNs is based on [RFC2679]. The PSN-specific layers are identical to those defined in Section 4.1 with the PW label set to the value preconfigured or assigned for PW OAM.
UDP/IP PSN向けのインバンドOAM PWメッセージパケットの形式は[RFC2679]に基づきます。PSN固有の各層はセクション4.1で定義されたものと同一であり、PWラベルにはPW OAM用に事前設定または割り当てられた値を設定します。
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.
LengthはOAMメッセージパケットのバイト長です。
OAM Sequence Number (16 bits) is used to uniquely identify the message. Its value is unrelated to the sequence number of the TDMoIP data packets for the PW in question. It is incremented in query messages, and replicated without change in replies.
OAM Sequence Number（16ビット）はメッセージを一意に識別します。この値は、対象PWのTDMoIPデータパケットのシーケンス番号とは無関係です。クエリメッセージでは値を増分し、応答では変更せずに引き継ぎます。
OAM Msg Type (8 bits) indicates the function of the message. At present the following are defined:
OAM Msg Type（8ビット）はメッセージの機能を示します。現在、次の値を定義しています。
0 for one-way connectivity query message 8 for one-way connectivity reply message.
OAM Msg Code (8 bits) is used to carry information related to the message, and its interpretation depends on the message type. For type 0 (connectivity query) messages the following codes are defined:
OAM Msg Code（8ビット）はメッセージに関する情報を格納し、その解釈はメッセージ型によって異なります。型0（接続性クエリ）メッセージについては、次のコードを定義しています。
0 validate connection. 1 do not validate connection
for type 8 (connectivity reply) messages the available codes are:
タイプ8（接続の返信）メッセージの場合、利用可能なコードは次のとおりです。
0 acknowledge valid query 1 invalid query (configuration mismatch).
Service specific information (16 bits) is a field that can be used to exchange configuration information between IWFs. If it is not used, this field MUST contain zero. Its interpretation depends on the payload type. At present, the following is defined for AAL1 payloads.
Service specific information（16ビット）は、IWF間で構成情報を交換するためのフィールドです。使用しない場合は、このフィールドを0にしなければなりません (MUST)。解釈はペイロード型によって異なります。現在、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.
Number of 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.
Number of SFs（8ビット）は、1パケット当たりの48バイトAAL1 PDUの数です。たとえば、1パケットに8個のPDUを格納する場合は8です。
Forward PW label (16 bits) is the PW label used for TDMoIP traffic from the source to destination IWF.
Forward PW label（16ビット）は、送信元IWFから宛先IWFへTDMoIP通信を送るときに使うPWラベルです。
Reverse PW label (16 bits) is the PW label used for TDMoIP traffic from the destination to source IWF.
Reverse PW label（16ビット）は、宛先IWFから送信元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.
Source Transmit Timestamp（32ビット）は、PSN側IWFがクエリメッセージを送信した時刻を表します。このフィールドと後続のタイムスタンプは、遅延を測定する場合にだけ現れます。時刻値はすべて、周波数を事前設定したクロックから導出されます。既定の時間単位は100マイクロ秒です。
Destination Receive Timestamp (32 bits) represents the time the destination IWF received the query message.
Destination Receive Timestamp（32ビット）は、宛先IWFがクエリメッセージを受信した時刻を表します。
Destination Transmit Timestamp (32 bits) represents the time the destination IWF transmitted the reply message.
Destination Transmit Timestamp（32ビット）は、宛先IWFが応答メッセージを送信した時刻を表します。
Every TDMoIP IWF will support some number of physical TDM connections, certain types of PSN, and some subset of the modes defined above. The following capabilities SHOULD be able to be queried by the management system:
各TDMoIP IWFは、いくつかの物理TDM接続、特定のPSN種別、上記で定義したモードの一部をサポートします。管理システムから次の機能を照会できるようにすることが推奨されます (SHOULD)。
AAL1 capable
AAL1対応
AAL2 capable (and AAL2 parameters, e.g., support for VAD and compression)
AAL2対応（VADや圧縮のサポートなどのAAL2パラメーターを含む）
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、Ethernet）
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について、次のパラメーターを設定するか、シグナリングで通知しなければなりません (MUST)。
PW label (for UDP and Ethernet the label MUST be manually configured)
PWラベル（UDPおよびEthernetの場合、ラベルは手動で設定しなければなりません (MUST)）
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について、次の統計情報と品質劣化の表示を収集することが推奨されます (SHOULD)。管理システムからこれらを照会できます。
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モードのPWの場合：
indication of malformed PDUs (incorrect CRC, bad C, P or E)
不正なPDUの表示（CRC不正、C、P、Eの値が不正）
indication of cells with pointer mismatch
ポインターが不一致となったセルの表示
number of seconds with jitter buffer over-run events
ジッターバッファのオーバーランが発生した秒数
number of seconds with jitter buffer under-run events
ジッターバッファのアンダーランが発生した秒数
for AAL2 mode PWs:
AAL2モードのPWの場合：
number of malformed minicells (incorrect HEC)
不正なミニセル数（HEC不正）
indication of misordered minicells (unexpected UUI)
順序逆転したミニセルの表示（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モードのPWの場合：
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について次の統計情報を収集してもかまいません (MAY)。
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 Recommendation I.363.1 (08/96) - B-ISDN ATM Adaptation Layer (AAL) specification: Type 1
[AAL2] ITU-T Recommendation I.363.2 (11/00) - B-ISDN ATM Adaptation Layer (AAL) specification: Type 2
[AAL2] ITU-T Recommendation I.363.2 (11/00) - B-ISDN ATM Adaptation Layer (AAL) specification: Type 2
[CES] ATM forum specification atm-vtoa-0078 (CES 2.0) Circuit Emulation Service Interoperability Specification Ver. 2.0
[CES] ATM forum specification atm-vtoa-0078 (CES 2.0) Circuit Emulation Service Interoperability Specification 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 Recommendation G.704 (10/98) - Synchronous frame structures used at 1544, 6312, 2048, 8448 and 44736 kbit/s hierarchical levels
[G751] ITU-T Recommendation G.751 (11/88) - Digital multiplex equipments operating at the third order bit rate of 34368 kbit/s and the fourth order bit rate of 139264 kbit/s and using positive justification
[G751] ITU-T Recommendation G.751 (11/88) - 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
[G823] ITU-T Recommendation G.823 (03/00) - The control of jitter and wander within digital networks which are based on the 2048 Kbit/s hierarchy
[G823] ITU-T Recommendation G.823 (03/00) - The control of jitter and wander within digital networks which are based on the 2048 Kbit/s hierarchy
[G824] ITU-T Recommendation G.824 (03/00) - The control of jitter and wander within digital networks which are based on the 1544 Kbit/s hierarchy
[G824] ITU-T Recommendation G.824 (03/00) - The control of jitter and wander within digital networks which are based on the 1544 Kbit/s hierarchy
[G826] ITU-T Recommendation G.826 (12/02) - End-to-end error performance parameters and objectives for international, constant bit-rate digital paths and connections
[G826] ITU-T Recommendation G.826 (12/02) - End-to-end error performance parameters and objectives for international, constant bit-rate digital paths and connections
[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 Standards for Local and Metropolitan Area Networks -- Virtual Bridged Local Area Networks (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 Standard Local and Metropolitan Area Networks - Carrier Sense Multiple Access with Collision Detection (CSMA/CD) Access Method and Physical Layer Specifications (2002)
[LES] ATM forum specification atm-vmoa-0145 (LES) Voice and Multimedia over ATM - Loop Emulation Service Using AAL2
[LES] ATM forum specification atm-vmoa-0145 (LES) Voice and Multimedia over ATM - Loop Emulation Service Using AAL2
[MEF8] Metro Ethernet Forum, "Implementation Agreement for the Emulation of PDH Circuits over Metro Ethernet Networks", October 2004.
[MEF8] Metro Ethernet Forum, "Implementation Agreement for the Emulation of PDH Circuits over Metro Ethernet Networks", October 2004.
[RFC768] Postel, J., "User Datagram Protocol (UDP)", STD 6, RFC 768, August 1980.
[RFC768] Postel, J., "User Datagram Protocol (UDP)", STD 6, RFC 768, August 1980.
[RFC791] Postel, J., "Internet Protocol (IP)", STD 5, RFC 791, September 1981.
[RFC791] Postel, J., "Internet Protocol (IP)", STD 5, RFC 791, September 1981.
[RFC2119] Bradner, S., "Key Words in RFCs to Indicate Requirement Levels", RFC 2119, March 1997.
[RFC2119] Bradner, S., "Key Words in RFCs to Indicate Requirement Levels", RFC 2119, March 1997.
[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., and A. Conta, "MPLS Label Stack Encoding", RFC 3032, January 2001.
[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., "Layer Two Tunneling Protocol - Version 3 (L2TPv3)", RFC 3931, March 2005.
[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and Jacobson, V., "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, July 2003.
[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and Jacobson, V., "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, July 2003.
[RFC4446] Martini, L., "IANA Allocations for Pseudowire Edge to Edge Emulation (PWE3)", BCP 116, RFC 4446, April 2006.
[RFC4446] Martini, L., "IANA Allocations for Pseudowire Edge to Edge Emulation (PWE3)", BCP 116, RFC 4446, April 2006.
[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., and G. Heron, "Pseudowire Setup and Maintenance Using the Label Distribution Protocol (LDP)", RFC 4447, April 2006.
[RFC4553] Vainshtein A., and Stein YJ., "Structure-Agnostic TDM over Packet (SAToP)", RFC 4553, June 2006.
[RFC4553] Vainshtein A., and Stein YJ., "Structure-Agnostic TDM over Packet (SAToP)", RFC 4553, June 2006.
[RFC4618] Martini L., Rosen E., Heron G., and Malis A., "Encapsulation Methods for Transport of PPP/High-Level Data Link Control (HDLC) over MPLS Networks", RFC 4618, September 2006.
[RFC4618] 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.
[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., and C. Pignataro, Ed., "Pseudowire Virtual Circuit Connectivity Verification: A Control Channel for Pseudowires", RFC 5085, December 2007.
[SSCS] ITU-T Recommendation I.366.2 (11/00) - AAL type 2 service specific convergence sublayer for narrow-band services.
[SSCS] ITU-T Recommendation I.366.2 (11/00) - AAL type 2 service specific convergence sublayer for narrow-band services.
[Y1413] ITU-T Recommendation Y.1413 (03/04) - TDM-MPLS network interworking - User plane interworking
[Y1413] ITU-T Recommendation Y.1413 (03/04) - TDM-MPLS network interworking - User plane interworking
[Y1414] ITU-T Recommendation Y.1414 (07/04) - Voice services - MPLS network interworking.
[Y1414] ITU-T Recommendation Y.1414 (07/04) - Voice services - MPLS network interworking.
[Y1452] ITU-T Recommendation Y.1452 (03/06) - Voice trunking over IP networks.
[Y1452] ITU-T Recommendation Y.1452 (03/06) - Voice trunking over IP networks.
[Y1453] ITU-T Recommendation Y.1453 (03/06) - TDM-IP interworking - User plane interworking.
[Y1453] ITU-T Recommendation Y.1453 (03/06) - TDM-IP interworking - User plane interworking.
Informative References
情報提供的参考文献
[ISDN-PRI] ITU-T Recommendation Q.931 (05/98) - ISDN user-network interface layer 3 specification for basic call control.
[ISDN-PRI] ITU-T Recommendation Q.931 (05/98) - ISDN user-network interface layer 3 specification for basic call control.
[RFC792] Postel J., "Internet Control Message Protocol", STD 5, RFC 792, September 1981.
[RFC792] Postel J., "Internet Control Message Protocol", STD 5, RFC 792, September 1981.
[RFC2212] Shenker, S., Partridge, C., and R. Guerin, "Specification of Guaranteed Quality of Service", RFC 2212, September 1997.
[RFC2212] Shenker, S., Partridge, C., and R. Guerin, "Specification of Guaranteed Quality of Service", RFC 2212, September 1997.
[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., "Framework for IP Performance Metrics", RFC 2330, May 1998.
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998.
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998.
[RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, "Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers", RFC 2474, December 1998.
[RFC2474] 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.
[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., and W. Weiss, "An Architecture for Differentiated Service", RFC 2475, December 1998.
[RFC2679] Almes, G., Kalidindi, S., and M. Zekauskas, "A One-way Delay Metric for IPPM", RFC 2679, September 1999.
[RFC2679] Almes, G., Kalidindi, S., and M. Zekauskas, "A One-way Delay Metric for IPPM", RFC 2679, September 1999.
[RFC2914] Floyd, S., "Congestion Control Principles", BCP 41, RFC 2914, September 2000.
[RFC2914] Floyd, S., "Congestion Control Principles", BCP 41, RFC 2914, September 2000.
[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., and D. Stiliadis, "An Expedited Forwarding PHB (Per-Hop Behavior)", RFC 3246, March 2002.
[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., and K. Norrman, "The Secure Real-time Transport Protocol (SRTP)", RFC 3711, March 2004.
[RFC3985] Bryant, S. and P. Pate, "Pseudo Wire Emulation Edge-to-Edge (PWE3) Architecture", RFC 3985, March 2005.
[RFC3985] Bryant, S. and P. Pate, "Pseudo Wire Emulation Edge-to-Edge (PWE3) Architecture", RFC 3985, March 2005.
[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., and S. Crocker, "Randomness Requirements for Security", BCP 106, RFC 4086, June 2005.
[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., "Requirements for Edge-to-Edge Emulation of Time Division Multiplexed (TDM) Circuits over Packet Switching Networks", RFC 4197, October 2005.
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005.
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005.
[RFC4379] Kompella, K. and Swallow, G., "Detecting Multi-Protocol Label Switched (MPLS) Data Plane Failures", RFC 4379, February 2006.
[RFC4379] Kompella, K. and Swallow, G., "Detecting Multi-Protocol Label Switched (MPLS) Data Plane Failures", RFC 4379, February 2006.
[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., and D. McPherson, "Pseudowire Emulation Edge-to-Edge (PWE3) Control Word for Use over an MPLS PSN", RFC 4385, February 2006.
[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., and P. Pate, "Structure-Aware Time Division Multiplexed (TDM) Circuit Emulation Service over Packet Switched Network (CESoPSN)", RFC 5086, December 2007.
[SS7] ITU-T Recommendation Q.700 (03/93) - Introduction to CCITT Signalling System No. 7.
[SS7] ITU-T Recommendation Q.700 (03/93) - Introduction to CCITT Signalling System No. 7.
[TDM-CONTROL] Vainshtein, A. and Y(J) Stein, "Control Protocol Extensions for Setup of TDM Pseudowires in MPLS Networks", Work in Progress, November 2007.
[TDM-CONTROL] Vainshtein, A. and Y(J) Stein, "Control Protocol Extensions for Setup of TDM Pseudowires in MPLS Networks", Work in Progress, November 2007.
[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) - Digital cellular telecommunications system (Phase 2+); Inband control of remote transcoders and rate adaptors for Enhanced Full Rate (EFR) and full rate traffic channels.
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 ISRAEL
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 ISRAEL
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 ISRAEL
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).
Copyright (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 Trustおよび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開示の写し、提供可能なライセンスに関する保証、および本仕様の実装者または利用者がそのような所有権を使用するための一般ライセンスまたは許可を得ようとした結果は、IETFのオンラインIPRリポジトリ（http://www.ietf.org/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へ通知するよう呼びかけています。情報はietf-ipr@ietf.org宛てにお送りください。