マキシムのTDM over Packet (TDMoP)デバイスと他ベンダのTDMoPデバイスとの相互運用性
要約
このアプリケーションノートは、マキシムのTDM over Packet (TDMoP)デバイスを他ベンダのTDMoPデバイスとともに使用するための要件を提供します。このアプリケーションノートでカバーされるマキシムTDMoPデバイスは、DS34T101、DS34T102、DS34T104、DS34T108、DS34S101、DS34S102、DS34S104、およびDS34S108です。
相互運用性の要件
相互運用性は、システムオペレータの介入がほとんどなしに、他ベンダのシステムと連動するシステムの性能です。システムの相互運用性によって、他のシステムとのサービスの受渡し、さまざまなベンダのシステムの適切な連動を行うことができます。
このアプリケーションノートは、マキシムのTDM-over-packet (TDMoP)デバイスと他ベンダのTDMoPデバイスとの相互運用性を実装する方法について説明します。このアプリケーションノートでカバーされるマキシムTDMoPデバイスは、DS34T101、DS34T102、DS34T104、DS34T108、DS34S101、DS34S102、DS34S104、およびDS34S108です。
マキシムのTDMoPデバイスによって作成されるパケットストリームは、他ベンダのTDMoPデバイスによって作成されるものと同じパケットヘッダ情報を持たない場合があります。マキシムデバイスを相互運用可能にするには、ユーザはセットアップタイプを知る必要があります。セットアップは、次の中の1つが可能です。
- IP/UDP/RTP/SAToP
- IP/UDP/RTP/CESoPSN
- MEF/CESoETH-unstructured (すなわち、MEF/SAToP)
- MEF/CESoETH-structured locked (すなわち、MEF/CESoPSN)
TDM-over-Packet (TDMoP)
このセクションでは、TDM-over-packetモジュールの機能説明を定義します。
TDMoPパケットフォーマット
パケットスイッチトネットワークからTDMデータを伝送するために、TDMoPデバイスは、TDMデータをEthernetパケットにカプセル化します(図1参照)。
図1. EthernetパケットのTDM-over-packetカプセル化
表1. Ethernetパケット構造
| フィールド | 説明 |
| Preamble | 同期化に使用される56ビット配列(交互の1値と0値)。信号の存在を検出するためにネットワーク時間の構成要素を提供します。 |
| Start Frame Delimiter | パケットの開始を示す8ビット配列(10101011) |
| Destination and Source Addresses | Destination Address (宛先アドレス)フィールドは、パケットを受信する1つの局または複数の局を識別します。Source Address (発信元アドレス)は、パケットの発信元である局を定義します。Destination Address (宛先アドレス)は、単一の局行きの個別アドレス、または局グループ行きのマルチキャストアドレスを指定することができます。すべて1ビットのDestination Address (宛先アドレス)は、LAN上のすべての局を参照し、ブロードキャストアドレスと呼ばれます。 |
| Type | Etherタイプ |
| Data and Padding | このフィールドは、発信局から1つまたは複数の宛先局に伝送されるデータを含みます。このフィールドの最大サイズは、1500バイトです。このフィールドのサイズが46バイトより小さい場合、パディングを使ってパケットサイズを最小の長さまでにします。最小EthernetパケットサイズはDestination Address (宛先アドレス)フィールドからのFrame Check Sequence (フレームチェックシーケンス)までの64バイトです。 |
| Frame Check Sequence | このフィールドは、誤りチェックに使用される4バイトの巡回冗長検査(CRC)値を含みます。発信局は、パケットをアセンブルするとき、Padフィールド(つまり、Preamble (プリアンブル)、Start Frame Delimiter (スタートフレームデリミタ)、およびFrame Check Sequence (フレームチェックシーケンス)を除くすべてのフィールド)を通じて、Destination Address (宛先アドレス)からのパケット内の全ビットのCRC計算を実行します。発信局は、このフィールドに値を格納し、それをパケットの一部として送信します。宛先局は、パケットを受け取ると、同じ検査を実行します。計算値がこのフィールドの値と一致しない場合、宛先局は、送信中に誤りが発生したと見なし、このパケットを破棄します。 |
VLANタグ
LAN規格のIEEE® 802.1qに規定されているように、12ビットVLAN識別IDのタグ付きパケットによって、最大4,096個のVLANを構築することができます。このVLAN制限が不適切な場合、VLANスタックが2レベルのVLANタグ構造を提供し、VLAN IDスペースを1600万個以上のVLANに拡張します。各パケットは、VLANタグなし、1個のVLANタグ、または2個のVLANタグ(VLANスタック)で送信することができます。図2と図3は、それぞれ、1個のVLANタグとスタックVLANタグを示しています。
図2. 1個のVLANタグ
図3. スタックVLANタグ
VLANタグの識別に使用されるVLANタグのプロトコルID (TPID)は、0x8100、またはvlan_2nd_tag_identifier設定レジスタで設定された値が可能です。
- User Priorityフィールドは、Ethernetパケットに優先度レベルを割り当てるために使用されます。
- CFI (Canonical Format Indicator)フィールドは、Router Informationフィールドの存在を示します。
- VLAN IDフィールドは、Ethernetパケットの所属先のVLANを一意に識別します。
- 図4は、UDP/IPv4ヘッダ構造を示しています。
- 図5は、UDP/IPv6ヘッダ構造を示しています。
- 図6は、MPLSヘッダ構造を示しています。
- 図7は、MEFヘッダ構造を示しています。
- 図8は、L2TPv3/IPv4ヘッダ構造を示しています。
- 図9は、L2TPv3/IPv6ヘッダ構造を示しています。
- 図10は、Control Wordヘッダ構造を示しています。
- 図11は、RTPヘッダ構造を示しています。
- 表2は、IPv4ヘッダ構造のさまざまなフィールドについて記述しています。
- 表3は、UDPヘッダ構造のさまざまなフィールドについて記述しています。
- 表4は、IPv6ヘッダ構造のさまざまなフィールドについて記述しています。
- 表5は、MPLSヘッダ構造のさまざまなフィールドについて記述しています。
- 表6は、MEFヘッダ構造のさまざまなフィールドについて記述しています。
- 表7は、L2TPv3/IPv4ヘッダ構造のさまざまなフィールドについて記述しています。
- 表8は、L2TPv3ヘッダ構造のさまざまなフィールドについて記述しています。
- 表9は、L2TPv3/IPv6ヘッダ構造のさまざまなフィールドについて記述しています。
- 表10は、Control Wordヘッダ構造のさまざまなフィールドについて記述しています。
- 表11は、RTPヘッダ構造のさまざまなフィールドについて記述しています。
UDP/IPv4ヘッダ
図4. UDP/IPv4ヘッダ
表2. IPv4ヘッダ構造
| フィールド | 説明 |
| IPVER | IPバージョン番号。IPv4の場合、IPVER = 4 |
| IHL | IPヘッダの32ビットワード長、IHL = 5 |
| IP TOS | IPタイプのサービス |
| Total Length | IPヘッダおよびデータ長(8ビットバイト) |
| Identification | IPフラグメントID |
| Flags | IP制御フラグ。断片化を避けるには010に設定する必要があります。 |
| Fragment Offset | データグラム内でフラグメントが所属する位置を示します。TDM-over-packetには使用されません。 |
| Time to Live | IP Time-to-Liveフィールド。このフィールドにゼロを含むデータグラムは破棄されます。 |
| Protocol | UDPを示すには0x11に設定する必要があります。 |
| IP Header Checksum | IPヘッダのチェックサム |
| Source IP Address | ソースのIPアドレス |
| Destination IP Address | 宛先のIPアドレス |
表3. UDPヘッダ構造
| フィールド | 説明 |
| Source Port Number, Destination Port Number | Source Port NumberまたはDestination Port Numberは、バンドルIDを持っています。未使用のフィールドは、0x85E (2142)に設定することができます。これは、Internet Assigned Numbers Authority (IANA)によってTDM-over-packetに割り当てられたユーザポート番号です。UDP/IP固有のOAMパケットの場合、バンドルIDはすべて1です。 |
| UDP Length | UDPヘッダおよびデータ長(8ビットバイト) |
| UDP Checksum | UDP/IPヘッダおよびデータのチェックサム。計算されない場合、ゼロに設定される必要があります。 |
UDP/IPv6ヘッダ
図5. UDP/IPv6ヘッダ
表4. IPv6ヘッダ構造
| フィールド | 説明 |
| IPVER | IPバージョン番号。IPv6の場合、IPVER = 6 |
| Traffic Class | IPv4のToS (Type of Service)フィールドに類似した8ビットフィールド |
| Flow Label | 20ビットFlow Labelフィールドは、特定のフローのパケットをタグ付けしてネットワーク層の各パケットを区別するために使用することができます。 |
| Payload Length | IPv4のTotal Lengthフィールドと同様に、このフィールドは、IPヘッダおよびデータ(8ビットバイト)の全長を示します。 |
| Next Header | IPv4のProtocolフィールドと同様に、このフィールドは、基本IPv6ヘッダに後続する情報タイプを決定します。UDPを表すには0x11を設定する必要があります。 |
| Hop Limit | IPv4のTime-to-Liveフィールドと同様 |
| Source IP Address | IPv4のSource Addressフィールドに同様。ただし、このフィールドは、IPv4用の32ビット発信元アドレスの代わりに、IPv6の128ビット発信元アドレスを含みます。 |
| Destination Address | IPv4のDestination Addressフィールドに同様。ただし、このフィールドは、IPv4用の32ビット宛先アドレスの代わりに、IPv6の128ビット宛先アドレスを含みます。 |
MPLSヘッダ
図6. MPLSヘッダ
表5. MPLSヘッダ構造
| フィールド | 説明 |
| Outer Labels | これらのMPLSラベルは、MPLSネットワークからTDMoMPLSパケットを通すために使用されるMPLS LSPを識別します。これらは、トンネルラベルまたはトランスポートラベルとも呼ばれます。このラベル番号は、マニュアルまたはMPLS制御プロトコルによって割り当てることができます。ゼロ個、1個、または2個の外側ラベルが可能です。 |
| EXP | Experimentalフィールド |
| S | スタックビット：1はスタックボトムを示します。すべての外側ラベルではS = 0 |
| TTL | MPLS有効期限 |
| Inner Label | MPLS内側ラベル(PWラベルまたはインタワーキングラベルとも呼ぶ)は、同じトンネル内で複数のバンドルを多重化するために使用されるバンドルIDを含みます。常に、MPLSラベルスタックの底にあるため、そのスタックビットが設定されます。 |
MEFヘッダ
図7. MEFヘッダ
表6. MEFヘッダ構造
| フィールド | 説明 |
| ECID | エミュレータ回路ID (ECID)はバンドルIDを含みます。 |
L2TPv3/IPv4ヘッダ
図8. L2TPv3/IPv4ヘッダ
表7. L2TPv3/IPv4ヘッダ構造
| フィールド | 説明 |
| IPVER | IPバージョン番号。IPv4の場合、IPVER = 4 |
| IHL | IPヘッダの32ビットワード長、IHL = 5 |
| IP TOS | IPタイプのサービス |
| Total Length | ヘッダおよびデータ長(8ビットバイト) |
| Identification | IPフラグメントID |
| Flags | IP制御フラグ。断片化を避けるには010に設定する必要があります。 |
| Fragment Offset | データグラム内でフラグメントが所属する位置を示します。TDM-over-packetには使用されません。 |
| Time to Live | IP Time-to-Liveフィールド。このフィールドにゼロを含むデータグラムは破棄されます。 |
| Protocol | L2TPv3を表すには0x73に設定する必要があります。 |
| IP Header Checksum | IPヘッダのチェックサム |
| Source IP Address | 発信元のIPアドレス |
| Destination IP Address | 宛先のIPアドレス |
表8. L2TPv3ヘッダ構造
| フィールド | 説明 |
| Session ID (32 Bits) | ローカルに有意味なL2TPセッションID。バンドルIDも含みます。予約の0を除き、すべてのバンドルIDを使用することができます。 |
| Cookie (32 or 64 Bits) | オプションフィールド。パケットと予期されたバンドルIDとの関連付けを有効にするために使用されるランダムに選択された値を含みます。 |
L2TPv3/IPv6ヘッダ
図9. L2TPv3/IPv6ヘッダ
表9. L2TPv3/IPv6ヘッダ構造
| フィールド | 説明 |
| IPVER | 表4を参照 |
| Traffic Class | |
| Flow Label | |
| Payload Length | |
| Next Header | L2TPv3を表すには0x73に設定する必要があります。 |
| Hop Limit | 表4を参照 |
| Source Address | |
| Destination Address |
L2TPv3ヘッダ構造については、表8を参照してください。
制御ワード
図10. 制御ワード
表10. 制御ワード構造
| フィールド | 説明 |
| RES | 予約ビット。ゼロに設定する必要があります。 |
| L | ローカルLOS (loss-of-sync)エラー。このビットはCPUによって設定されます。設定されたLビットは、発信元が送信されるデータに影響するTDM物理層フォルトを検出したか、または通知されたことを示します。このビットは、遠端でAIS生成をトリガする物理層LOSを示すために使用されます。設定されて、TDMフォルトが修正された場合、Lビットはクリアされる必要があります。 |
| R | リモート受信エラー。このビットはCPUによって設定されます。設定されたRビットは、発信元がEthernetポートでパケットを受信していない(つまり、双方向接続のこの方向でエラーが存在する)ことを示します。この表示は、混雑状態またはその他のネットワーク関連のフォルトを知らせるために使用することができます。リモートエラー表示は、混雑の回避のフォールバック機構をトリガすることができます。Rビットは、事前設定された数の連続パケットが受信されなかった後に設定し、パッケージが再度受信されたらクリアする必要があります。 |
| M | Defect修飾子エラー。これらのビットはCPUによって設定されます。このフィールドはオプションです。使用された場合、Lビットの意味を補完します。 |
| FRG | フラグメントフィールド。このフィールドは、CASバンドルで構造化されたCESoPSNの場合に、マルチフレーム構造を複数のパケットに断片化するために使用されます。 このフィールドは、次のように使用されます。 00 - 単一パケットでマルチフレーム構造全体(断片化されていない)が伝送されることを示します 01 - 最初のフラグメントを伝送するパケットを示します。 10 - 最後のフラグメントを伝送するパケットを示します。 11 - 中間のフラグメントを伝送するパケットを示します。 |
| Length | UDP/IPパケットでない場合、制御ワード、ペイロード、およびRTPヘッダ(存在する場合)を含みます。この合計が64バイトより小さい場合に使用されます。それ以外は、ゼロに設定します。 |
| Sequence Number | TDM-over-packetシーケンス番号。この値は、バンドルごとに個別に定義され、そのバンドルに送信された各TDMoPパケットに1ずつインクリメントされます。シーケンス番号の初期値は、セキュリティ目的のためランダム(予測不可能)で、値は、バンドルごとに個別にラップアラウンドでインクリメントされます。これは、受信者によって、パケット消失を検出し、パケットシーケンスを復元するために使用されます。 HDLCペイロードタイプマシンは、このフィールドに対して、常にゼロ、ラップアラウンドでインクリメント、またはラップアラウンド値でインクリメント(ゼロ値をスキップ)、という3種類のモードをサポートします。 OAMパケット(TDM-over-packetペイロードを参照)では、これは、メッセージを一意に識別します。その値は、当該のバンドルのTDMoPデータパケットのシーケンス番号に関連していません。これは、クエリメッセージでインクリメントされ、応答内に、変更なしで複製されます。 |
RTPヘッダ
図11. RTPヘッダ
表11. RTPヘッダ構造
| フィールド | 説明 |
| V | RTPバージョン：2に設定する必要があります。 |
| P | パディングビット：0に設定する必要があります。 |
| X | エクステンションビット：0に設定する必要があります。 |
| CC | CSRCカウント：0に設定する必要があります。 |
| M | マーカビット。0に設定する必要があります。 |
| PT | ペイロードタイプ。1つのPT値は、バンドルの各方向のダイナミック値の範囲から割り当てられる必要があります。同じPT値は、バンドルの両方向に再使用することができ、異なるバンドル間でも再使用することができます。 |
| SN | シーケンス番号。制御ワードのシーケンス番号と同じ |
| TS | タイムスタンプ。RTPヘッダは、次のようなモードのタイムスタンプ生成とともに使用することができます。 絶対モード：チップは、着信するTDM回路から復元されたクロックを使用し、タイムスタンプを設定します。その結果、タイムスタンプはシーケンス番号と緊密に相関しています。タイムスタンプは、125µsごとに1ずつインクリメントされます。 差動(コモンクロック)モード：バンドルエッジの2つのチップは、同じ高品質クロック発信元へのアクセス権を持っており、このクロックソースはタイム生成に使用されます。 |
| SSRC | 同期化ソースを識別します。このIDは、同一のRTP内の2個の同期化ソースが同じSSRC IDを持たないように、ランダムに選択される必要があります。 |
他ベンダのTDMoPデバイスからのパケットコンテンツを知る方法
Ethernetパケットヘッダを分析するために、ソフトウェアを使用することができます。このアプリケーションノートでは、Wireshark®ソフトウェアが使用されました。ユーザは、このフリーウェアをwww.wireshark.org/download.htmlからダウンロードすることができます。Wiresharkの詳細については、Wireshark Frequently Asked Questionsをご覧ください。
ユーザが正しいプロトコルで正しいパケットを送信していることを確認するために、ユーザは、他ベンダからの2つのTDMoPシステムボードが相互に同期するように保証する必要があります。その後、ユーザは、Wiresharkプログラムを使用し、パケットをキャプチャする必要があります。このプログラムの画面は、図12のようになります。
画像の拡大(PDF)
図12. Ethernetパケットヘッダの分析に使用されるWiresharkプログラムの画面
システムを相互運用可能にするには、次の要件を考慮する必要があります。
- 発信元ポート番号と宛先ポート番号
- パケットバイト、IP長、UDP長、およびデータバイトの合計数
- Etherタイプ
発信元ポート番号と宛先ポート番号
TDMoIP_Port_Numberは、Packet Classifierブロックによって、TDM-over-packetのUDP/IPを識別するために使用されます。TDMoIP_Port_Numberとして、2個の異なる値を設定することができます。マキシムのTDMoPデバイスは2つのTDMoIP_Port_Numberレジスタを持っていますが、大半の場合、両方のレジスタは、IANAによってTDM-over-packet用に割り当てられたデフォルト値(0x085E)を持っています。SourceまたはDestination Port Numberは、バンドルIDを保持します。未使用のフィールドは、0x85E (10進数では2142)に設定することができます。これは、Internet Assigned Numbers Authority (IANA)によって、TDM-over-packetに割り当てられたユーザポート番号です。図4で示されるように、マキシムのデバイスは、まず、Source Port Numberを挿入し、次にDestination Port Numberを挿入します。図13は、UDP (ユーザデータグラムプロトコル)のコンテンツを示しています。Source Port Numberが2に設定され、TDMoIP Destination Port Numberが0x85E (10進数では2142)に設定されています。
図13. UDP発信元および宛先ポート番号
一部のベンダは、0x85EをUDP Source Port NumberとUDP Destination Port Numberとして挿入します。このシナリオでは、ユーザは、事前設定メニューを使用し、システムを設定する必要があります。デフォルトのマキシムSWメニューは、次のようになります。
PreConfig Configuration
1. Link Type E1
2. Bundle Number ID Location Port in DST, Bundle in SRC UDP Port
3. UDP Mask 1FFF
4. VCCV OAM Mask [0 - 4] 0
5. VCCV OAM Value 1FFF
6. MEF Ethernet Type 88D8
7. MEF OAM Type 0
8. TDMoIP Port Number 1 85E
9. Oscillator Type OCXO (Stratum 3E)
10. RTP Clock Source ABSOLUTE
11. Common clock Rate 19440000
12. IP Version IPv4
13. Clock Recovery Smart Statistics Enable
14. One or Two Clock Mode One
マキシムSWメニューからの項目2は、希望のBundle Number ID Location (バンドル番号ID位置)を選択するために使用されます。上記メニューからの項目2は、以下のセクションを提供します。
Bundle Number ID Location
1: Ignore port, Bundle in SRC UDP PORT,
2: Port in DST, Bundle in SRC UDP PORT
3: Port in SRC, Bundle in DST UDP PORT,
4: Ignore Port, Bundle in DST UDP PORT
マキシムのデバイスのデフォルトのBundle Number ID Location (バンドル番号ID位置)は、上記メニューの項目2：「Port in DST, Bundle in SRC UDP PORT」です。マキシムのデバイスを他ベンダのデバイスと連動可能にするには、ユーザは必要に応じて、項目1、3、または4を選択する必要があります。たとえば、TDMoPデバイスベンダのデバイスの1つは、DestinationポートをSource (SRS)位置に挿入し、バンドルポート番号はDestination (DST)に挿入します。ユーザが上記メニューから項目3を選択した場合、UDP SourceポートのBundle Number ID Locationは、0x85E (10進数では2142)に設定され、UDP宛先ポートは2を持ちます(図14参照)。これは、そのベンダのTDMoPパケットヘッダに一致するため、相互運用性が有効になります。
図14. UDP発信元および宛先ポート番号(図13のと逆転)
パケットバイト、IP長、UDP長、およびデータバイトの合計数
図15. 異なるパケット長情報を示しているキャプチャされたパケット
図15は、さまざまなパケット長を持つパケットのコンテンツを示しています。
ユーザは、次の長さを考慮する必要があります。
A. データバイト：図15は、パケット1が1244バイトを含むことを示しています。バンドル設定では、IP/UDP/CESoPSNプロトコルが使用されました。31個のタイムスロットを使用し、E1 TDMデータが送信されました。各タイムスロットは40フレームバイトを持っていました。TDMデータフレームバイトの合計数は、40 × 31 = 1240フレームバイトです。4バイトの制御ワードの追加によって1244バイトになります。マキシムのTDMoPデバイスを使用する多くの利点の1つは、適応型クロックリカバリモードにおける利点です。デフォルトモードは、パケット内にRTP (リアルタイムプロトコル)ヘッダを使用しないため、ペイロードデータの一部のBWが開放されます。ほとんどの他ベンダは、12バイトのRTPを使用しています。TDMoPパケット内にRTPが使用された場合、データバイトは1256 (1244 + 12)となります。TDMデータバイトの合計数(この場合は1240バイト)がわかったら、ユーザは、マキシムデバイスも1240バイトのTDMデータ、またはWiresharkプログラムで検出された数を生成するように、マキシムデバイスをプログラムする必要があります。相互運用性は、すべてのパケット長が一致することを必要とします。これらの長さが同じでない場合、ユーザはSWメニューを使用し、同じパケット長を持つように、マキシムのTDMoPデバイスを設定する必要があります。B. UDP長：図15は、パケット1のUDP長が1252バイトで、1244バイトのデータと8バイトのUDPプロトコルで構成されることを示しています。
C. IP長:図15は、パケット1のIP長が1272バイトで、1244バイトのデータ、20バイトのIPヘッダ、および8バイトのUDPプロトコルで構成されることを示しています。
D. フレームバイトの合計数：図15は、パケット1が1290バイトを含むことを示しています。これは、1244バイトのデータで、20バイトのIPヘッダ、8バイトのUDPプロトコルヘッダ、2バイトのEtherタイプ、4バイトのVLANタグ、および12バイトの発信元および宛先MACアドレスで構成されます。
Etherタイプ
マキシムのTDMoPデバイスは、既知のEtherタイプである、次のようなEtherタイプを考慮します。
- IPv4 (0x800)
- IPv6 (0x86DD)
- MPLSユニキャスト(0x8847)
- MPLSマルチキャスト(0x8848)
- ARP (0x806)
- MEF Etherタイプ(Mef_ether_type設定レジスタで設定)
- MEF OAM Etherタイプ(Mef_oam_ether_type設定レジスタで設定)
- 特定のEtherタイプ(CPU_dest_ether_type設定レジスタで設定)
図16. Etherタイプ値は0x800で、IPv4であることを示しています。
Ethernetタイプが決定されたら、ユーザは、同じEtherタイプのパケットを生成するためにマキシムのTDMoPデバイスを設定する必要があります。Etherタイプは、PSNタイプを変更することによって、Bundle Configuration (バンドル設定)メニューから選択されます。Bundle Configuration (バンドル設定)メニュー(部分)は、次のとおりです。
Main Menu>Bundle Configuration>CES Bundle Configuration ... (P) 11. VLAN ID 1[1 - 4095] ... (100) 12. VLAN Priority[0 - 7] ... (7) 13. IP Tos[0 - 255] ... (0) 14. IP TTL[0 - 255] ... (128) 15. PSN Type > (IP)上記メニューからの項目15は、以下のセクションを提供します。
Main Menu>Bundle Configuration>CES Bundle Configuration>PSN Type () 1. IP 2. MPLS 3. L2TPV3 4. EthernetBundle Configuration (バンドル設定)メニューから希望の組合せを選択することによって、キャプチャされたパケットのEtherタイプがマッチングされます。
結論
相互運用性とは、さまざまなシステムと組織が連動(相互運用)する性能を指します。各製品は、公開されたインタフェース規格を順守するか、または1つの製品のインタフェースを別製品のインタフェースに「オンザフライ」で変換する設定変更を可能にすることによって、他製品との相互運用性を達成します。他のTDMoPデバイスによって生成されたパケットのコンテンツを知ることによって、マキシムのデバイスは、他のTDMoPデバイスのパケット設定にマッチングするように、容易に設定することができます。
TDMoP製品、またはマキシムのテレコム製品を使用するその他の状況についてさらにご質問がある場合は、テレコム製品アプリケーションサポートチーム (または電話：972-371-6555)までお問い合わせください(英語のみの対応となります)。