Maxim的TDM-over-Packet (TDMoP)设

摘要：本应用笔记介绍Maxim的TDM-over-Packet (TDMoP)设备与其它厂家TDMoP设备共同工作时的一些要求。这篇应用笔记涵盖的Maxim TDMoP芯片包括：DS34T101，DS34T102，DS34T104，DS34T108，DS34S101，DS34S102，DS34S104和DS34S108。

互操作性的要求

互操作性是一个系统与其它厂家的系统共同工作时无需或者只需很少的系统管理员干预的能力。系统具有互操作性就可以提供服务给其它系统或者接受来自其它系统的服务，使得不同厂家的系统可以共同正常工作。

本应用笔记介绍Maxim的TDM-over-Packet (TDMoP)设备与其它厂家TDMoP设备共同工作时的一些要求。这篇应用笔记涵盖的Maxim TDMoP芯片包括：DS34T101，DS34T102，DS34T104，DS34T108，DS34S101，DS34S102，DS34S104和DS34S108。

Maxim的TDMoP设备产生的报文数据也许和其它厂家的TDMoP设备产生的报文数据采用不同的报文头信息。为了实现Maxim设备的互操作性，用户需要知道设置类型。设置类型可以是下列选项中的一种：

• IP/UDP/RTP/SAToP
• IP/UDP/RTP/CESoPSN
• MEF/CESoETH-非结构化(比如MEF/SAToP)
• MEF/CESoETH-结构化锁定(比如MEF/CESoPSN)

每种设置具有不同的报文头。为了实现互操作，Maxim的TDMoP设备的报文头必须与其它厂家的TDMoP设备的报文头具有同样的格式。用户需要比较Maxim的TDMoP设备的报文头和其它厂家TDMoP设备的报文头。如果存在格式上的区别，本应用笔记将会演示如何利用Maxim的用户指南来调整TDMoP设备的报文头。

TDM-over-Packet (TDMoP)

这一部分将定义TDM-over-Packet模块的功能描述。

TDMoP报文格式

在包交换的网络上传输TDM数据，TDMoP芯片需要将TDM数据如图1描述的那样封装为以太报文。


图1. TDM-over-Packet封装进入以太报文

表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 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标记

如同IEEE® 802.1q标准规定的一样，由12位的VLAN标识符标记的报文可以最多构建4096个不同的VLAN。对于那些由于这个限制而数量不够的应用，VLAN嵌套实现了两层的VLAN标记结构，它将VLAN的ID空间扩展到1600万个VLAN。每一个报文在发送时可以没有VLAN标记，具有一个VLAN标记或者具有两个VLAN标记(VLAN嵌套)。图2和图3所示分别为一个VLAN标记和嵌套的VLAN标记。


图2. 单一的VLAN标记


图3. 嵌套的VLAN标记

VLAN标记的协议ID (TPID)用来识别VLAN标记，它可以是0x8100或者是vlan_2nd_tag_identifier配置寄存器中的数值。

• 用户优先级字段用来给以太报文指定一个优先级的级别
• CFI (规范格式指示符)字段表明有路由信息字段
• VLAN ID字段唯一识别以太报文属于哪个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描述了控制字报头结构的不同字段
• 表11描述了RTP报头结构的不同字段

UDP/IPv4报头

图4. UDP/IPv4报头

表2. IPv4报头结构

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报头结构

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报头

图5. UDP/IPv6报头

表4. UDP报头结构

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报头

图6. MPLS报头

表5. MPLS报头结构

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报头

图7. MEF报头

表6. MEF报头结构

Field	Description
ECID	The Emulated Circuit Identifier (ECID) contains the bundle identifier.

L2TPv3/IPv4报头

图8. L2TPv3/IPv4报头

表7. L2TPv3/IPv4报头结构

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报头结构

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报头

图9. L2TPv3/IPv6报头

表9. L2TPv3/IPv6报头结构

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报头结构见表8。

控制字

图10. 控制字

表10. 控制字结构

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报头

图11. RTP报头

表11. 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 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设备的报文内容

有一些软件可以用来分析以太网的报文头。本应用笔记使用Wireshark®软件。用户可以从www.wireshark.org/download.html下载这个免费软件。关于Wireshark的更多信息，请看Wireshark常见问题(English only)。

为了确认用户正确的发送了带有正确协议的报文，用户需要保证两块来自其它厂家的TDMoP系统板间相互同步。完成此步后，用户需要利用Wireshark程序来捕捉报文。图12所示为这个程序的截屏图。


更详细的图片(PDF)
图12. 用来分析以太报文头的Wireshark程序截屏图

为了使系统间能够互通，必须考虑下面的要求：

1. 源端口号和目的端口号
2. 报文字节，IP长度，UDP长度和数据字节的总长度
3. 以太类型

源端口号和目的端口号

报文分类模块利用TDMoP端口号来识别TDM-over-Packet的UDP/IP。TDMoIP_Port_Number可以配置为两个不同的值。虽然Maxim的TDMoP设备有两个TDMoIP_Port_Number寄存器，但是在很多情况下，两个寄存器都应该配置为IANA为TDM-over-Packet分配的默认值(0x085E)。源端口号或者目的端口号中含有绑定标识号。未用字段可以设置为0x85E (十进制的2142)，它是IANA为TDM-over-Packet分配的用户端口号。如图4所示，Maxim的设备首先插入源端口号，然后插入TDMoP目的端口号。图13所示为用户数据报协议(UDP)的内容，源端口号被设为2，TDMoP目的端口号被设为0x85E (十进制的2142)。


图13. UDP源和目的端口号

有些厂家插入0x85E作为UDP的源端口号和UDP的目的端口号。在这种情况下，用户必须通过preconfiguration菜单来配置系统，Maxim软件的默认值如下所示：

                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

Maxim软件菜单的第二项用来选取所需的Bundle Number ID Location。上面菜单的第二项提供以下可选项：

                   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设备的默认Bundle Number ID Location是选项2： “Port in DST, Bundle in SRC UDP PORT”。为了使得Maxim的设备能够与其它厂家的设备互通，用户需要适当地选取选项1、3或者4。比如，某TDMoP厂家的设备在Source (SRS)位置插入Destination端口，在Destination (DST)插入绑定端口号。如果用户在上面的菜单中选取选项3，那么UDP源端口Bundle Number ID Location就被设置为0x85E (十进制的2142)，UDP目的端口就会为2，如图14所示。这样就可以匹配那个厂家的TDMoP报文头，因此，他们可以互操作。


图14. UDP源和目的端口号与图13中相反

报文字节，IP长度，UDP长度和数据字节的总长度

图15. 捕获的报文具有不同的报文长度信息

图15所示为具有不同报文长度信息的报文内容，编号为1。

用户必须考虑下面的长度：

A. 数据字节：图15所示报文1共有1244个字节。在绑定配置中，我们采用IP/UDP/CESoPSN协议。发送的E1 TDM数据使用31个时隙，每个时隙有40个帧字节，那么总的TDM数据帧字节就是40 × 31 = 1240个帧字节。附加4字节的控制字后就变成了1244个字节。使用Maxim的TDMoP芯片的众多优点之一就是在自适应时钟恢复模式下，默认模式的报文里并不使用RTP (实时协议)头，因此可以为净荷数据节省一些带宽。大部分的其它厂家使用12字节的RTP。如果我们在TDMoP数据字节中使用RTP，那么总的数据字节将会是1256 (1244 + 12)。得到TDM数据字节的总数后，本例中为1240字节，用户需要对Maxim的设备进行编程，使其也生成1240字节的TDM数据，或者是我们在Wireshark程序中得到的数目。

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字节的以太类型、4字节的VLAN标记加上12字节的源和目的MAC地址组成。

互操作要求所有的报文长度都匹配。如果这些长度不同，那么用户必须利用软件菜单来配置Maxim的TDMoP设备，使其具有相同的报文长度。

以太类型

Maxim的TDMoP设备主要将下列以太类型作为已知的以太类型：

1. IPv4 (0x800)
2. IPv6 (0x86DD)
3. MPLS单播(0x8847)
4. MPLS多播(0x8848)
5. ARP (0x806)
6. 配置在Mef_ether_type配置寄存器中的MEF以太类型
7. 配置在Mef_oam_ether_type配置寄存器中的MEF OAM以太类型
8. 配置在CPU_dest_ether_type配置寄存器中的特定以太类型

想要实现Maxim的TDMoP设备的互操作性，用户必须确定来自其它TDMoP设备的输入报文采用何种以太类型。这个类型位于VLAN ID报头字节之后。图16所示的输入报文以太类型为0x800，它代表报文为IPv4。


图16. 以太类型值为0x800，代表着它是IPv4

一旦确定了以太类型，用户必须将Maxim的TDMoP设备配置成为可以生成同样的以太类型。每个以太类型可以在Bundle Configuration菜单中通过改变PSN类型进行选择。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. Ethernet

通过在Bundle Configuration菜单中选择合适的组合，就可以匹配捕获报文的以太类型。

总结

互操作性是指不同的设备和组织间可以共同工作(相互操作)。与其它产品可以实现互操作的设备或者遵循公开的接口标准，或者容许改变配置，将一个产品的接口直接的转换为另一个产品的接口。通过了解其它TDMoP设备生成报文的类型，Maxim的设备可以很容易的实现与其它TDMoP设备的报文配置匹配。

如果您对TDMoP产品或者Maxim的电信产品在使用中有进一步的问题，请通过电子邮件 [e-mail] (English only)或电话972-371-6555 (美国)与电信产品应用支持小组联系

IEEE是美国电子和电器工程师协会的注册服务标志。
Wireshark是Gerald Combs的注册商标。