TDM-over-Packet (TDMoP) ICのDS34S132を他ベンダのTDMoPデバイスと相互運用可能にする方法
要約
相互運用性は、システムオペレータの介入がほとんどなしに、他ベンダのシステムと組み合わせて動作するシステムの能力です。システムの相互運用性によって、他のシステムとの間でサービスのやり取りが可能になります。これによって、異なる複数のベンダのシステムを組み合わせて正常に動作させることができます。このアプリケーションノートでは、TDM-over-Packet (TDMoP) ICのDS34S132をセットアップして他ベンダのTDMoPデバイスとの相互運用性を提供する方法について説明します。
はじめに
今日の通信がシステムや部品間でますます複雑な相互作用を必要としていることは周知のことです。こうした背景の中で、相互運用性は各技術的進歩においてより大きな重要性を担っています。相互運用性は、システムオペレータの介入がほとんどなしに、他ベンダのシステムと組み合わせて動作するシステムの能力です。システムの相互運用性によって、他のシステムとの間でサービスのやり取りが可能になります。これによって、異なる複数のベンダのシステムを組み合わせて正常に動作させることができます。
このアプリケーションノートでは、マキシムのTDM-over-Packet (TDMoP) ICであるDS34S132を中心に取り上げます。このアプリケーションノートでは、DS34S132と他ベンダのTDMoPデバイス間の相互運用性を提供するためのセットアップ要件について説明します。
相互運用性の要件
マキシムのTDMoPデバイスによって作成されるパケットストリームは、他ベンダのTDMoPデバイスと同じパケットヘッダ情報を備えていない場合があります。TDMoPデバイスを相互運用可能にするには、ユーザーはデバイスのセットアップタイプを知る必要があります。マキシムデバイスのセットアップは、次の1つとなります。
- IP/UDP/RTP/SAToP
- IP/UDP/RTP/CESoPSN
- MEF/RTP/CESoETH：構造化なし(すなわち、MEF/SAToP)
- MEF/RTP/CESoETH：構造化ロック(すなわち、MEF/CESoPSN)
- MPLS/RTP/SAToP：構造化なし(すなわち、MPLS/RTP/SAToP)
- MPLS/RTP/CESoPSN：構造化ロック(すなわち、MPLS/RTP/CESoPSN)
TDMoPフォーマット
この項では、TDM-over-packetモジュールの機能説明を示します。パケットスイッチトネットワークを通じてTDMデータを伝送するには、TDMoPデバイスは、図1に示すように、TDMデータをイーサネットパケットにカプセル化します。TDMoPのさまざまなブロックの説明は、表1に提供されています。
図1. イーサネットパケットのTDMoPカプセル化
表1. イーサネットパケット構造
| Field | Description |
| Preamble | A sequence of 56 bits (alternating 1 and 0 values) used for synchronization. Gives components in the network time to detect the presence of a signal. |
| Start frame delimiter | A sequence of 8 bits (10101011) that indicates the start of the packet. |
| Destination and Source Addresses | The Destination Address field identifies the station or stations that are to receive the packet. The Source Address identifies the station that originated the packet. A Destination Address can specify either an "individual address" destined for a single station, or a "multicast address" destined for a group of stations. A Destination Address of all 1 bits refers to all stations on the LAN and is called a "broadcast address." |
| Type | Ether type |
| Data and padding | This field contains the data transferred from the source station to the destination station or stations. The maximum size of this field is 1500 bytes. A minimum size Ethernet packet is 64 bytes from the Destination Address field through the Frame Check Sequence. If the packet size of this field is less than 46 bytes, padding is used to bring the packet size up to the minimum length. |
| Frame check sequence | This field contains a 4-byte cyclical redundancy check (CRC) value used for error checking. When a source station assembles a packet, it performs a CRC calculation on all the bits in the packet from the Destination Address through the pad fields (that is, all fields except the preamble, start frame delimiter, and Frame Check Sequence). The source station stores the value in this field and transmits it as part of the packet. When the destination station receives the packet, it performs an identical check. If the calculated value does not match the value in this field, the destination station assumes that an error has occurred during transmission and discards the packet. |
ユーザーは、次の2つの項の相互運用性を確保するTDMoPヘッダに注意を向ける必要があります。
- 相互運用性を確保するUDP/IPv4ヘッダ
- 相互運用性を確保するRTPヘッダ
相互運用性を確保するUDP/IPv4ヘッダ
図2は、UDP/IPv4ヘッダ構造を示しています。表2と表3は、IPv4およびUDPヘッダ構造の各フィールドを記述しています。
図2. UDP/IPv4ヘッダ
表2. IPv4ヘッダ構造
| Field | Description |
| IPVER | IP version number; IPv4 IPVER = 4 |
| IHL | Length in 32-bit words of the IP Header, IHL = 5 |
| IP TOS | IP type of service |
| Total length | Length in octets of IP Header and data |
| Identification | IP fragmentation identification |
| Flags | IP control flags; must be set to 010 to avoid fragmentation |
| Fragment offset | Indicates where in the datagram the fragment belongs; not used for TDMoP |
| Time to live | IP time-to-live field; datagrams with zero in this field are discarded |
| Protocol | Must be set to 0x11 to signify UDP |
| IP Header checksum | Checksum for the IP Header |
| Source IP address | IP address of the source |
| Destination IP address | IP address of the destination |
表3. UDPヘッダ構造
| Field | Description |
| Source port number, destination port number | Either the source or the destination port number holds the bundle identifier. The unused field can be set to 0x85E (2142), which is the user's port number assigned to TDMoP by the Internet Assigned Numbers Authority (IANA). For UDP/IP-specific OAM packets, the bundle identifier is all 1s. |
| UDP length | Length in octets of UDP Header and data |
| UDP checksum | Checksum of UDP/IP Header and data. If not computed, it must be set to zero. |
IANAに従って、UDPヘッダの宛先ポート(Destination Port)は、TDMoPに割り当てられるユーザーのポート番号である、0x85E (2142)に設定される必要があります。マキシムのTDMoPデバイスはデフォルトでこの規定を順守しています。
TDMoPベンダによっては、バンドル識別子を、UDPヘッダ内の発信元ポート(source port)番号位置ではなく、宛先ポート番号位置に割り当てます。また、ベンダによっては、ユーザーポート番号として、IANAによって割り当てられた0x85Eではなく、乱数を割り当てます。ユーザーは、DS34S132を使用して次の2つの方法でこれらの問題を解決することができます。
- すべてのバンドル識別子を事前設定メニューの所望の位置に割り当てる
- 着信パケット内のバンドル識別子を予期する位置をバンドルエンジンに示す
- すべてのバンドル識別子を事前設定メニュー内の所望の位置に割り当てる
DS34S132の事前設定は、図3に示されています。
図3. DS34S132の事前設定メニュー項目4のBundle Number ID Locationは、バンドル識別子を検索する場所を示します。ユーザーがこのメニューを選択すると、次のオプションが表示されます(図4)。
図4. DS34S132の事前設定メニューのオプション4図4におけるオプション3のBundle in DST UDP PORTは、バンドル識別子をUDPヘッダ内の宛先ポート番号位置に割り当てます。オプション4のBundle in SRC UDP PORTは、バンドル識別子をUDPヘッダ内の発信元ポート番号位置に割り当てます。
したがって、着信パケットのバンドル識別子位置を識別した後、ユーザーは各自のバンドル識別子を適切な位置に割り当てることができます。
ユーザーポート番号として、IANAによって割り当てられた0x85Eではなく、乱数を割り当てるには、ユーザーは事前設定メニューのオプション10および11の変更を選択することができます。
- 着信パケット内のバンドル識別子を予期する位置をバンドルエンジンに示す
図4に戻って、オプション1のBundle Configuration Decides (BCDR4)は、図5に示されるユーザーのバンドル設定に基づいて、バンドル識別子を宛先ポートまたは発信元ポート番号位置のいずれかに割り当てます。
図5. DS34S132のバンドル設定メニュー上記のバンドル設定メニューでは、ユーザーはバンドル識別子をUDP発信元ポート番号位置に挿入しています。ユーザーは、パケット分類子がUDP発信元ポート位置内の着信パケットのバンドル識別子を予期することも示しています。
ユーザーは、着信パケットのバンドル識別子がUDP宛先ポート番号位置にあることを知っている場合、オプション45のRX Bundle Number Location at UDP portを図6に示された宛先に変更することによってそれを簡単に示すことができます。
図6. DS34S132のバンドル設定メニューのオプション45
相互運用性を確保するRTPヘッダ
図7はRTPヘッダ構造を示し、表4はRTPヘッダ構造の各フィールドを記述しています。
RTPヘッダ
図7. RTPヘッダ
表4. RTPヘッダ構造
| Field | Description |
| V | RTP version; must be set to 2. |
| P | Padding bit; must be set to 0. |
| X | Extension bit; must be set to 0. |
| CC | CSRC count; must be set to 0. |
| M | Marker bit; must be set to 0. |
| PT | Payload type. One PT value MUST be allocated from the range of dynamic values for each direction of the bundle. The same PT value MAY be reused for both directions of the bundle, and is also reused between different bundles. |
| SN | The sequence number identical to the sequence number in the control word. |
| TS | Timestamp. The RTP Header can be used in conjunction with the following modes of timestamp generation: Absolute mode: the chip sets timestamps using the clock recovered from the incoming TDM circuit. Differential (common clock) mode: The two chips at bundle edges have access to the same high-quality clock source, and this clock source is used for timestamp generation. |
| SSRC | Identifies the synchronization source. This identifier should be chosen randomly, with the intent that no two synchronization sources within the same RTP session will have the same SSRC identifier. |
絶対クロックリカバリモードでタイムスタンプを生成するには、Port Receive Configuration Register 4 (PRCR4)のRTP Generator Timestamp Mode Select (TSGMS)ビットは1に、すなわち、PRCR4.TSGMS = 1に設定される必要があります。差動クロックリカバリモードでタイムスタンプを生成するには、PRCR4レジスタのTSGMSビットは0に、すなわちPRCR4.TSGMS = 0に設定される必要があります。ユーザーは、これらのレジスタビットをマニュアルで設定する必要がありません。バンドル設定内でRTPがイネーブルされると、これらのビットが設定されます。
適応型モードの場合、マキシムのTDMoPデバイスDS34S132におけるクロックリカバリアルゴリズムは、パケット間の着信時間遅延に基づいてクロックをリカバリします。したがって、適応型モードの場合のRTPのイネーブルは、適応型クロックリカバリモードのオプションです。しかし、差動モードの場合、マキシムのTDMoPデバイスDS34S132におけるクロックリカバリアルゴリズムは、RTPヘッダ内のタイムスタンプの解析に基づいてクロックをリカバリします。したがって、RTPのイネーブルは差動クロックリカバリモードの必須です。
相互運用可能であるには、ユーザーは他のTDMoPベンダがRTPヘッダ内のタイムスタンプの生成に使用しているモードを決定する必要があります。またユーザーは、他のシステムが適応型または差動クロックリカバリモードかどうかを知る必要もあります。クロックリカバリモードは、インタフェース設定においてポート単位で変更することができます。図8は、クロックリカバリモードの変更方法を示しています。デフォルトでは、ポート単位の適応型モードとなります。
図8. インタフェース設定
ユーザーは、クロックリカバリモードを変更したい場合、図9に示すように、オプション40のAdaptive or Differential Modeを使用する必要があります。
図9. インタフェース設定における差動クロックリカバリモードの選択
マキシムのTDMoPデバイスと異なり、TDMoPベンダによっては適応型または差動クロックリカバリモードのいずれかのRTPヘッダ内のタイムスタンプに基づいてクロックをリカバリします。そのため、これらのベンダのシステムと相互運用可能であるには、マキシムのTDMoPデバイスは適応型クロックリカバリモードでRTPをイネーブルする必要があります。DS34S132、および他のTDMoPベンダのデバイスは、次の3つの方法でRTPヘッダ内のタイムスタンプを生成することができます。
- ビットモード
- バイトモード
- フレームモード
図10. インタフェース設定におけるタイムスタンプのビット、バイト、またはフレームモードの選択
インタフェース設定でクロックリカバリモードとタイムスタンプ生成モードの選択が完了した後、ユーザーは、バンドル設定のRTPモードをイネーブルする必要があります。前に、図5はRTPモードがディセーブルされたバンドル設定を示しました。このバンドル設定メニューから、ユーザーは図11に示すように、オプション27を使用してRTPモードをイネーブルする必要があります。
図11. インタフェース設定におけるタイムスタンプのビット、バイト、またはフレームモードの選択
RTPモードがイネーブルされると、バンドル設定メニューは図12のような表示になります。
図12. RTPモードをイネーブルした後のバンドル設定メニュー
他ベンダのTDMoPデバイスからのパケットコンテンツを識別する方法
イーサネット上のパケットヘッダを解析するためのさまざまな種類のソフトウェアがあります。このアプリケーションノートでは、Wireshark®ソフトウェアが使用されました。このフリーウェアはダウンロードして入手可能です。Wiresharkの詳細については、ウェブサイトのFrequently Asked Questions sectionsセクションを使用してください。
結論
相互運用性とは、多様なシステムや組織がシームレスに連携して動作する能力を指します。各製品は、公開されたインタフェース規格を順守するか、または1つの製品のインタフェースを別製品のインタフェースに｢オンザフライ｣で変換する設定変更を可能にすることによって、相互運用性を達成します。他のTDMoPデバイスによって生成されたパケットのコンテンツを知ることによって、マキシムのデバイスは、他のTDMoPデバイスのパケット設定にマッチングするように、容易に設定することができます。
TDMoP製品やその他のマキシムのテレコム製品に関してご質問がある場合は、マキシムのメンバーセンターにご登録ください
メンバーシップのサインアップ手続きが完了しましたら、オンラインのテクニカルサポートリクエストフォームからサポートリクエストをご送信ください。