互操作性的要求
互操作性是一個(gè)系統(tǒng)與其它廠家的系統(tǒng)共同工作時(shí)無(wú)需或者只需很少的系統(tǒng)管理員干預(yù)的能力。系統(tǒng)具有互操作性就可以提供服務(wù)給其它系統(tǒng)或者接受來(lái)自其它系統(tǒng)的服務(wù),使得不同廠家的系統(tǒng)可以共同正常工作。本應(yīng)用筆記介紹Maxim的TDM-over-Packet (TDMoP)設(shè)備與其它廠家TDMoP設(shè)備共同工作時(shí)的一些要求。這篇應(yīng)用筆記涵蓋的Maxim TDMoP芯片包括:DS34T101,DS34T102,DS34T104,DS34T108,DS34S101,DS34S102,DS34S104和DS34S108。
Maxim的TDMoP設(shè)備產(chǎn)生的報(bào)文數(shù)據(jù)也許和其它廠家的TDMoP設(shè)備產(chǎn)生的報(bào)文數(shù)據(jù)采用不同的報(bào)文頭信息。為了實(shí)現(xiàn)Maxim設(shè)備的互操作性,用戶需要知道設(shè)置類型。設(shè)置類型可以是下列選項(xiàng)中的一種:
- IP/UDP/RTP/SAToP
- IP/UDP/RTP/CESoPSN
- MEF/CESoETH-非結(jié)構(gòu)化(比如MEF/SAToP)
- MEF/CESoETH-結(jié)構(gòu)化鎖定(比如MEF/CESoPSN)
TDM-over-Packet (TDMoP)
這一部分將定義TDM-over-Packet模塊的功能描述。TDMoP報(bào)文格式
在包交換的網(wǎng)絡(luò)上傳輸TDM數(shù)據(jù),TDMoP芯片需要將TDM數(shù)據(jù)如圖1描述的那樣封裝為以太報(bào)文。圖1. TDM-over-Packet封裝進(jìn)入以太報(bào)文
表1. 以太報(bào)文結(jié)構(gòu)
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 may 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. If the size of this field is less than 46 bytes, then padding is used to bring the packet size up to the minimum length. A minimum Ethernet packet size is 64 bytes from the Destination Address field through the Frame Check Sequence. |
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 an error has occurred during transmission and discards the packet. |
VLAN標(biāo)記
如同IEEE? 802.1q標(biāo)準(zhǔn)規(guī)定的一樣,由12位的VLAN標(biāo)識(shí)符標(biāo)記的報(bào)文可以最多構(gòu)建4096個(gè)不同的VLAN。對(duì)于那些由于這個(gè)限制而數(shù)量不夠的應(yīng)用,VLAN嵌套實(shí)現(xiàn)了兩層的VLAN標(biāo)記結(jié)構(gòu),它將VLAN的ID空間擴(kuò)展到1600萬(wàn)個(gè)VLAN。每一個(gè)報(bào)文在發(fā)送時(shí)可以沒(méi)有VLAN標(biāo)記,具有一個(gè)VLAN標(biāo)記或者具有兩個(gè)VLAN標(biāo)記(VLAN嵌套)。圖2和圖3所示分別為一個(gè)VLAN標(biāo)記和嵌套的VLAN標(biāo)記。圖2. 單一的VLAN標(biāo)記
圖3. 嵌套的VLAN標(biāo)記
VLAN標(biāo)記的協(xié)議ID (TPID)用來(lái)識(shí)別VLAN標(biāo)記,它可以是0x8100或者是vlan_2nd_tag_identifier配置寄存器中的數(shù)值。
- 用戶優(yōu)先級(jí)字段用來(lái)給以太報(bào)文指定一個(gè)優(yōu)先級(jí)的級(jí)別
- CFI (規(guī)范格式指示符)字段表明有路由信息字段
- VLAN ID字段唯一識(shí)別以太報(bào)文屬于哪個(gè)VLAN
- 圖4所示為UDP/IPv4的報(bào)頭結(jié)構(gòu)
- 圖5所示為UDP/IPv6的報(bào)頭結(jié)構(gòu)
- 圖6所示為MPLS的報(bào)頭結(jié)構(gòu)
- 圖7所示為MEF的報(bào)頭結(jié)構(gòu)
- 圖8所示為L(zhǎng)2TPv3/IPv4的報(bào)頭結(jié)構(gòu)
- 圖9所示為L(zhǎng)2TPv3/IPv6的報(bào)頭結(jié)構(gòu)
- 圖10所示為Control Word的報(bào)頭結(jié)構(gòu)
- 圖11所示為RTP的報(bào)頭結(jié)構(gòu)
- 表2描述了IPv4報(bào)頭結(jié)構(gòu)的不同字段
- 表3描述了UDP報(bào)頭結(jié)構(gòu)的不同字段
- 表4描述了IPv6報(bào)頭結(jié)構(gòu)的不同字段
- 表5描述了MPLS報(bào)頭結(jié)構(gòu)的不同字段
- 表6描述了MEF報(bào)頭結(jié)構(gòu)的不同字段
- 表7描述了L2TPv3/IPv4報(bào)頭結(jié)構(gòu)的不同字段
- 表8描述了L2TPv3報(bào)頭結(jié)構(gòu)的不同字段
- 表9描述了L2TPv3/IPv6報(bào)頭結(jié)構(gòu)的不同字段
- 表10描述了控制字報(bào)頭結(jié)構(gòu)的不同字段
- 表11描述了RTP報(bào)頭結(jié)構(gòu)的不同字段
UDP/IPv4報(bào)頭
圖4. UDP/IPv4報(bào)頭
表2. IPv4報(bào)頭結(jié)構(gòu)
Field | Description |
IPVER | IP version number; for 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 TDM-over-packet |
Time to Live | IP Time-to-Live field; datagrams with zero in this field are to be 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報(bào)頭結(jié)構(gòu)
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 port number assigned to TDM-over-packet by the Internet Assigned Numbers Authority (IANA). For UDP/IP-specific OAM packets, the bundle identifier is all ones. |
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 |
UDP/IPv6報(bào)頭
圖5. UDP/IPv6報(bào)頭
表4. UDP報(bào)頭結(jié)構(gòu)
Field | Description |
IPVER | IP version number; for IPv6 IPVER = 6 |
Traffic Class | An 8-bit field similar to the type-of-service (ToS) field in IPv4 |
Flow Label | The 20-bit Flow Label field can be used to tag packets of a specific flow to differentiate the packets at the network layer. |
Payload Length | Similar to the Total Length field in IPv4, this field indicates the total length of the IP header and data in octets. |
Next Header | Similar to the Protocol field in IPv4, this field determines the type of information following the basic IPv6 header. It must be set to 0x11 to signify UDP. |
Hop Limit | Similar to the Time-to-Live field in IPv4 |
Source IP Address | Similar to the Source Address field in IPv4, except that this field contains a 128-bit source address for IPv6 instead of a 32-bit source address for IPv4. |
Destination Address | Similar to the Destination Address field in IPv4, except that this field contains a 128-bit destination address for IPv6 instead of a 32-bit destination address for IPv4. |
MPLS報(bào)頭
圖6. MPLS報(bào)頭
表5. MPLS報(bào)頭結(jié)構(gòu)
Field | Description |
Outer Labels | These MPLS labels identify the MPLS LSP used to tunnel the TDMoMPLS packets through the MPLS network. They are also known as tunnel labels or transport labels. The label number can be assigned either manually or via the MPLS control protocol. There can be zero, one, or two outer labels. |
EXP | Experimental field |
S | Stacking bit: 1 indicates stack bottom; S = 0 for all outer labels |
TTL | MPLS time to live |
Inner Label | The MPLS Inner Label (also known as the PW label or the interworking label) contains the bundle identifier used to multiplex multiple bundles within the same tunnel. It is always at the bottom of the MPLS label stack, and hence its stacking bit is set. |
MEF報(bào)頭
圖7. MEF報(bào)頭
表6. MEF報(bào)頭結(jié)構(gòu)
Field | Description |
ECID | The Emulated Circuit Identifier (ECID) contains the bundle identifier. |
L2TPv3/IPv4報(bào)頭
圖8. L2TPv3/IPv4報(bào)頭
表7. L2TPv3/IPv4報(bào)頭結(jié)構(gòu)
Field | Description |
IPVER | IP version number; e.g., for 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 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 TDM-over-packet |
Time to Live | IP Time-to-Live field; datagrams with zero in this field are to be discarded |
Protocol | Must be set to 0x73 to signify L2TPv3 |
IP Header Checksum | Checksum for the IP header |
Source IP Address | IP address of the source |
Destination IP Address | IP address of the destination |
表8. L2TPv3報(bào)頭結(jié)構(gòu)
Field | Description |
Session ID (32 Bits) | Locally significant L2TP session identifier, also contains the bundle identifier; all bundle identifiers are available for use except 0, which is reserved |
Cookie (32 or 64 Bits) | Optional field that contains a randomly selected value used to validate association of the packet with the expected bundle identifier |
L2TPv3/IPv6報(bào)頭
圖9. L2TPv3/IPv6報(bào)頭
表9. L2TPv3/IPv6報(bào)頭結(jié)構(gòu)
Field | Description |
IPVER | See Table 4 |
Traffic Class | |
Flow Label | |
Payload Length | |
Next Header | Must be set to 0x73 to signify L2TPv3 |
Hop Limit | See Table 4 |
Source Address | |
Destination Address |
L2TPv3報(bào)頭結(jié)構(gòu)見(jiàn)表8。
控制字
圖10. 控制字
表10. 控制字結(jié)構(gòu)
Field | Description |
RES | Reserved bits—must be set to zero |
L | Local loss-of-sync (LOS) failure. This bit is set by the CPU. A set L bit indicates that the source has detected, or has been informed of, a TDM physical layer fault that impacts the data to be transmitted. This bit can be used to indicate physical layer LOS that should trigger AIS generation at the far end. Once set, if the TDM fault is rectified, the L bit must be cleared. |
R | Remote receive failure. This bit is set by the CPU. A set R bit indicates that the source is not receiving packets at the Ethernet port (i.e., there is a failure in the direction of the bidirectional connection). This indication can be used to signal congestion or other network-related faults. A remote failure indication may trigger fallback mechanisms for congestion avoidance. The R bit must be set after a preconfigured number of consecutive packets are not received, and must be cleared once packets are received again. |
M | Defect modifier failure. These bits are set by the CPU. This field is optional. When used, it supplements the L-bit meaning. |
FRG | Fragmentation field. This field is used for fragmenting multiframe structures into multiple packets in case of CESoPSN structured with CAS bundles. The field is used as follows: 00 - Indicates that the entire (unfragmented) multiframe structure is carried in a single packet 01 - Indicates the packet carrying the first fragment 10 - Indicates the packet carrying the last fragment 11 - Indicates a packet carrying an intermediate fragment |
Length | Includes control word, payload, and RTP header (if it exists), unless it is a UDP/IP packet. It is used when this sum is less than 64 bytes. Otherwise, set to zero. |
Sequence Number | TDM-over-packet sequence number. This value is defined separately for each bundle and incremented by one for each TDMoP packet sent for that bundle. The initial value of the sequence number is random (unpredictable) for security purposes, and the value is incremented in wrap-around manner separately for each bundle. It is used by the receiver to detect packet loss and restore packet sequence. The HDLC payload type machine supports three different modes for this field: always zero, incremented in wrap-around manner, or incremented in wrap-around value, but skips zero value. For OAM packets (see TDM-over-packet payload), it uniquely identifies the message. Its value is unrelated to the sequence number of the TDMoP data packets for the bundle in question. It is incremented in query messages, and replicated without change in replies. |
RTP報(bào)頭
圖11. RTP報(bào)頭
表11. RTP報(bào)頭結(jié)構(gòu)
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 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. As a consequence, the timestamps are closely correlated with the sequence numbers. The timestamp is incremented by one every 125μs. 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. |
如何獲取其它廠家的TDMoP設(shè)備的報(bào)文內(nèi)容
有一些軟件可以用來(lái)分析以太網(wǎng)的報(bào)文頭。本應(yīng)用筆記使用Wireshark?軟件。用戶可以從www.wireshark.org/download.html下載這個(gè)免費(fèi)軟件。關(guān)于Wireshark的更多信息,請(qǐng)看Wireshark常見(jiàn)問(wèn)題(English only)。為了確認(rèn)用戶正確的發(fā)送了帶有正確協(xié)議的報(bào)文,用戶需要保證兩塊來(lái)自其它廠家的TDMoP系統(tǒng)板間相互同步。完成此步后,用戶需要利用Wireshark程序來(lái)捕捉報(bào)文。圖12所示為這個(gè)程序的截屏圖。
更詳細(xì)的圖片(PDF)
圖12. 用來(lái)分析以太報(bào)文頭的Wireshark程序截屏圖
為了使系統(tǒng)間能夠互通,必須考慮下面的要求:
- 源端口號(hào)和目的端口號(hào)
- 報(bào)文字節(jié),IP長(zhǎng)度,UDP長(zhǎng)度和數(shù)據(jù)字節(jié)的總長(zhǎng)度
- 以太類型
源端口號(hào)和目的端口號(hào)
報(bào)文分類模塊利用TDMoP端口號(hào)來(lái)識(shí)別TDM-over-Packet的UDP/IP。TDMoIP_Port_Number可以配置為兩個(gè)不同的值。雖然Maxim的TDMoP設(shè)備有兩個(gè)TDMoIP_Port_Number寄存器,但是在很多情況下,兩個(gè)寄存器都應(yīng)該配置為IANA為T(mén)DM-over-Packet分配的默認(rèn)值(0x085E)。源端口號(hào)或者目的端口號(hào)中含有綁定標(biāo)識(shí)號(hào)。未用字段可以設(shè)置為0x85E (十進(jìn)制的2142),它是IANA為T(mén)DM-over-Packet分配的用戶端口號(hào)。如圖4所示,Maxim的設(shè)備首先插入源端口號(hào),然后插入TDMoP目的端口號(hào)。圖13所示為用戶數(shù)據(jù)報(bào)協(xié)議(UDP)的內(nèi)容,源端口號(hào)被設(shè)為2,TDMoP目的端口號(hào)被設(shè)為0x85E (十進(jìn)制的2142)。圖13. UDP源和目的端口號(hào)
有些廠家插入0x85E作為UDP的源端口號(hào)和UDP的目的端口號(hào)。在這種情況下,用戶必須通過(guò)preconfiguration菜單來(lái)配置系統(tǒng),Maxim軟件的默認(rèn)值如下所示:
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 OneMaxim軟件菜單的第二項(xiàng)用來(lái)選取所需的Bundle Number ID Location。上面菜單的第二項(xiàng)提供以下可選項(xiàng):
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在上面的菜單中,Maxim設(shè)備的默認(rèn)Bundle Number ID Location是選項(xiàng)2: “Port in DST, Bundle in SRC UDP PORT”。為了使得Maxim的設(shè)備能夠與其它廠家的設(shè)備互通,用戶需要適當(dāng)?shù)剡x取選項(xiàng)1、3或者4。比如,某TDMoP廠家的設(shè)備在Source (SRS)位置插入Destination端口,在Destination (DST)插入綁定端口號(hào)。如果用戶在上面的菜單中選取選項(xiàng)3,那么UDP源端口Bundle Number ID Location就被設(shè)置為0x85E (十進(jìn)制的2142),UDP目的端口就會(huì)為2,如圖14所示。這樣就可以匹配那個(gè)廠家的TDMoP報(bào)文頭,因此,他們可以互操作。
圖14. UDP源和目的端口號(hào)與圖13中相反
報(bào)文字節(jié),IP長(zhǎng)度,UDP長(zhǎng)度和數(shù)據(jù)字節(jié)的總長(zhǎng)度
圖15. 捕獲的報(bào)文具有不同的報(bào)文長(zhǎng)度信息
圖15所示為具有不同報(bào)文長(zhǎng)度信息的報(bào)文內(nèi)容,編號(hào)為1。
用戶必須考慮下面的長(zhǎng)度:
A. 數(shù)據(jù)字節(jié):圖15所示報(bào)文1共有1244個(gè)字節(jié)。在綁定配置中,我們采用IP/UDP/CESoPSN協(xié)議。發(fā)送的E1 TDM數(shù)據(jù)使用31個(gè)時(shí)隙,每個(gè)時(shí)隙有40個(gè)幀字節(jié),那么總的TDM數(shù)據(jù)幀字節(jié)就是40 × 31 = 1240個(gè)幀字節(jié)。附加4字節(jié)的控制字后就變成了1244個(gè)字節(jié)。使用Maxim的TDMoP芯片的眾多優(yōu)點(diǎn)之一就是在自適應(yīng)時(shí)鐘恢復(fù)模式下,默認(rèn)模式的報(bào)文里并不使用RTP (實(shí)時(shí)協(xié)議)頭,因此可以為凈荷數(shù)據(jù)節(jié)省一些帶寬。大部分的其它廠家使用12字節(jié)的RTP。如果我們?cè)赥DMoP數(shù)據(jù)字節(jié)中使用RTP,那么總的數(shù)據(jù)字節(jié)將會(huì)是1256 (1244 + 12)。得到TDM數(shù)據(jù)字節(jié)的總數(shù)后,本例中為1240字節(jié),用戶需要對(duì)Maxim的設(shè)備進(jìn)行編程,使其也生成1240字節(jié)的TDM數(shù)據(jù),或者是我們?cè)赪ireshark程序中得到的數(shù)目。互操作要求所有的報(bào)文長(zhǎng)度都匹配。如果這些長(zhǎng)度不同,那么用戶必須利用軟件菜單來(lái)配置Maxim的TDMoP設(shè)備,使其具有相同的報(bào)文長(zhǎng)度。
B.UDP長(zhǎng)度:圖15所示表明報(bào)文1的UDP長(zhǎng)度為1252字節(jié),它由1244字節(jié)的數(shù)據(jù)加上8字節(jié)的UDP協(xié)議組成。
C.IP長(zhǎng)度:圖15所示表明報(bào)文1的IP長(zhǎng)度為1272字節(jié),它由1244字節(jié)的數(shù)據(jù)、20字節(jié)的IP報(bào)頭加上8字節(jié)的UDP協(xié)議報(bào)頭組成。
D.幀字節(jié)的總數(shù)目:圖15所示表明報(bào)文1共有1290字節(jié)。它由1244字節(jié)的數(shù)據(jù)、20字節(jié)的IP報(bào)頭、8字節(jié)的UDP協(xié)議報(bào)頭、2字節(jié)的以太類型、4字節(jié)的VLAN標(biāo)記加上12字節(jié)的源和目的MAC地址組成。
以太類型
Maxim的TDMoP設(shè)備主要將下列以太類型作為已知的以太類型:- IPv4 (0x800)
- IPv6 (0x86DD)
- MPLS單播(0x8847)
- MPLS多播(0x8848)
- ARP (0x806)
- 配置在Mef_ether_type配置寄存器中的MEF以太類型
- 配置在Mef_oam_ether_type配置寄存器中的MEF OAM以太類型
- 配置在CPU_dest_ether_type配置寄存器中的特定以太類型
圖16. 以太類型值為0x800,代表著它是IPv4
一旦確定了以太類型,用戶必須將Maxim的TDMoP設(shè)備配置成為可以生成同樣的以太類型。每個(gè)以太類型可以在Bundle Configuration菜單中通過(guò)改變PSN類型進(jìn)行選擇。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)上面菜單中的選項(xiàng)15具有下面的內(nèi)容:
Main Menu>Bundle Configuration>CES Bundle Configuration>PSN Type () 1. IP 2. MPLS 3. L2TPV3 4. Ethernet通過(guò)在Bundle Configuration菜單中選擇合適的組合,就可以匹配捕獲報(bào)文的以太類型。
總結(jié)
互操作性是指不同的設(shè)備和組織間可以共同工作(相互操作)。與其它產(chǎn)品可以實(shí)現(xiàn)互操作的設(shè)備或者遵循公開(kāi)的接口標(biāo)準(zhǔn),或者容許改變配置,將一個(gè)產(chǎn)品的接口直接的轉(zhuǎn)換為另一個(gè)產(chǎn)品的接口。通過(guò)了解其它TDMoP設(shè)備生成報(bào)文的類型,Maxim的設(shè)備可以很容易的實(shí)現(xiàn)與其它TDMoP設(shè)備的報(bào)文配置匹配。如果您對(duì)TDMoP產(chǎn)品或者M(jìn)axim的電信產(chǎn)品在使用中有進(jìn)一步的問(wèn)題,請(qǐng)通過(guò)電子郵件 telecom.support@maxim-ic.com (English only)或電話972-371-6555 (美國(guó))與電信產(chǎn)品應(yīng)用支持小組聯(lián)系
IEEE是美國(guó)電子和電器工程師協(xié)會(huì)的注冊(cè)服務(wù)標(biāo)志。
Wireshark是Gerald Combs的注冊(cè)商標(biāo)。
評(píng)論
查看更多