アプリケーションノート 4785

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デバイスのセットアップは、異なるパケットヘッダを備えています。相互運用可能であるためには、マキシムのTDMoPデバイスからのパケットヘッダは、他ベンダのデバイスからのパケットヘッダと同じ形式でフォーマットされている必要があります。すなわち、ユーザーはTDMoPデバイスのパケットヘッダを比較し、フォーマットの違いを見つける必要があります。このアプリケーションノートでは、マキシムのユーザーアプリケーションを使用することによって、TDMoPデバイスのDS34S132のパケットヘッダ値を変更する方法を紹介します。またこのアプリケーションノートでは、マキシムのバンドル設定を変更し、同じプロトコルでもヘッダ情報が異なるパケットを受け付ける方法についても説明します。

TDMoPフォーマット

この項では、TDM-over-packetモジュールの機能説明を示します。パケットスイッチトネットワークを通じてTDMデータを伝送するには、TDMoPデバイスは、図1に示すように、TDMデータをイーサネットパケットにカプセル化します。TDMoPのさまざまなブロックの説明は、表1に提供されています。

図1. イーサネットパケットのTDMoPカプセル化
図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ヘッダに注意を向ける必要があります。
  1. 相互運用性を確保するUDP/IPv4ヘッダ
  2. 相互運用性を確保するRTPヘッダ

相互運用性を確保するUDP/IPv4ヘッダ

図2は、UDP/IPv4ヘッダ構造を示しています。表2表3は、IPv4およびUDPヘッダ構造の各フィールドを記述しています。

図2. UDP/IPv4ヘッダ
図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つの方法でこれらの問題を解決することができます。
  1. すべてのバンドル識別子を事前設定メニューの所望の位置に割り当てる
  2. 着信パケット内のバンドル識別子を予期する位置をバンドルエンジンに示す

  1. すべてのバンドル識別子を事前設定メニュー内の所望の位置に割り当てる
  2. DS34S132の事前設定は、図3に示されています。

    Figure 3. Preconfiguration menu of DS34S132.
    図3. DS34S132の事前設定メニュー

    項目4のBundle Number ID Locationは、バンドル識別子を検索する場所を示します。ユーザーがこのメニューを選択すると、次のオプションが表示されます(図4)。

    図4. DS34S132の事前設定メニューのオプション4
    図4. DS34S132の事前設定メニューのオプション4

    図4におけるオプション3のBundle in DST UDP PORTは、バンドル識別子をUDPヘッダ内の宛先ポート番号位置に割り当てます。オプション4のBundle in SRC UDP PORTは、バンドル識別子をUDPヘッダ内の発信元ポート番号位置に割り当てます。

    したがって、着信パケットのバンドル識別子位置を識別した後、ユーザーは各自のバンドル識別子を適切な位置に割り当てることができます。

    ユーザーポート番号として、IANAによって割り当てられた0x85Eではなく、乱数を割り当てるには、ユーザーは事前設定メニューのオプション10および11の変更を選択することができます。

  3. 着信パケット内のバンドル識別子を予期する位置をバンドルエンジンに示す
  4. 図4に戻って、オプション1のBundle Configuration Decides (BCDR4)は、図5に示されるユーザーのバンドル設定に基づいて、バンドル識別子を宛先ポートまたは発信元ポート番号位置のいずれかに割り当てます。

    図5. DS34S132のバンドル設定メニュー
    図5. DS34S132のバンドル設定メニュー

    上記のバンドル設定メニューでは、ユーザーはバンドル識別子をUDP発信元ポート番号位置に挿入しています。ユーザーは、パケット分類子がUDP発信元ポート位置内の着信パケットのバンドル識別子を予期することも示しています。

    ユーザーは、着信パケットのバンドル識別子がUDP宛先ポート番号位置にあることを知っている場合、オプション45のRX Bundle Number Location at UDP portを図6に示された宛先に変更することによってそれを簡単に示すことができます。

    図6. DS34S132のバンドル設定メニューのオプション45
    図6. DS34S132のバンドル設定メニューのオプション45

相互運用性を確保するRTPヘッダ

図7はRTPヘッダ構造を示し、表4はRTPヘッダ構造の各フィールドを記述しています。

RTPヘッダ

図7. 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. インタフェース設定
図8. インタフェース設定

ユーザーは、クロックリカバリモードを変更したい場合、図9に示すように、オプション40のAdaptive or Differential Modeを使用する必要があります。

図9. インタフェース設定における差動クロックリカバリモードの選択
図9. インタフェース設定における差動クロックリカバリモードの選択

マキシムのTDMoPデバイスと異なり、TDMoPベンダによっては適応型または差動クロックリカバリモードのいずれかのRTPヘッダ内のタイムスタンプに基づいてクロックをリカバリします。そのため、これらのベンダのシステムと相互運用可能であるには、マキシムのTDMoPデバイスは適応型クロックリカバリモードでRTPをイネーブルする必要があります。DS34S132、および他のTDMoPベンダのデバイスは、次の3つの方法でRTPヘッダ内のタイムスタンプを生成することができます。
  1. ビットモード
  2. バイトモード
  3. フレームモード
パケットが適応型クロックリカバリモードの場合も差動クロックリカバリモードの場合も、ユーザーは図10に示すように、インタフェースおよびバンドル設定を変更することによって、RTPヘッダ内のタイムスタンプを生成することができます。

図10. インタフェース設定におけるタイムスタンプのビット、バイト、またはフレームモードの選択
図10. インタフェース設定におけるタイムスタンプのビット、バイト、またはフレームモードの選択

インタフェース設定でクロックリカバリモードとタイムスタンプ生成モードの選択が完了した後、ユーザーは、バンドル設定のRTPモードをイネーブルする必要があります。前に、図5はRTPモードがディセーブルされたバンドル設定を示しました。このバンドル設定メニューから、ユーザーは図11に示すように、オプション27を使用してRTPモードをイネーブルする必要があります。

図11. インタフェース設定におけるタイムスタンプのビット、バイト、またはフレームモードの選択
図11. インタフェース設定におけるタイムスタンプのビット、バイト、またはフレームモードの選択

RTPモードがイネーブルされると、バンドル設定メニューは図12のような表示になります。

図12. RTPモードをイネーブルした後のバンドル設定メニュー
図12. RTPモードをイネーブルした後のバンドル設定メニュー

他ベンダのTDMoPデバイスからのパケットコンテンツを識別する方法

イーサネット上のパケットヘッダを解析するためのさまざまな種類のソフトウェアがあります。このアプリケーションノートでは、Wireshark®ソフトウェアが使用されました。このフリーウェアはダウンロードして入手可能です。Wiresharkの詳細については、ウェブサイトのFrequently Asked Questions sectionsセクションを使用してください。

結論

相互運用性とは、多様なシステムや組織がシームレスに連携して動作する能力を指します。各製品は、公開されたインタフェース規格を順守するか、または1つの製品のインタフェースを別製品のインタフェースに「オンザフライ」で変換する設定変更を可能にすることによって、相互運用性を達成します。他のTDMoPデバイスによって生成されたパケットのコンテンツを知ることによって、マキシムのデバイスは、他のTDMoPデバイスのパケット設定にマッチングするように、容易に設定することができます。

TDMoP製品やその他のマキシムのテレコム製品に関してご質問がある場合は、マキシムのメンバーセンターにご登録ください

メンバーシップのサインアップ手続きが完了しましたら、オンラインのテクニカルサポートリクエストフォームからサポートリクエストをご送信ください。