Network Working Group Y(J). Stein
Request for Comments: 5087 R. Shashoua
Category: Informational R. Insler
M. Anavi
RAD Data Communications
December 2007
Network Working Group Y(J). Stein
Request for Comments: 5087 R. Shashoua
Category: Informational R. Insler
M. Anavi
RAD Data Communications
December 2007
Time Division Multiplexing over IP (TDMoIP)
IP时分多路复用（TDMoIP）
Status of This Memo
关于下段备忘
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
本备忘录为互联网社区提供信息。它没有规定任何类型的互联网标准。本备忘录的分发不受限制。
Abstract
摘要
Time Division Multiplexing over IP (TDMoIP) is a structure-aware method for transporting Time Division Multiplexed (TDM) signals using pseudowires (PWs). Being structure-aware, TDMoIP is able to ensure TDM structure integrity, and thus withstand network degradations better than structure-agnostic transport. Structure-aware methods can distinguish individual channels, enabling packet loss concealment and bandwidth conservation. Accesibility of TDM signaling facilitates mechanisms that exploit or manipulate signaling.
IP时分复用（TDMoIP）是一种利用伪线（PWs）传输时分复用（TDM）信号的结构感知方法。由于具有结构意识，TDMoIP能够确保TDM结构的完整性，因此比结构无关传输更好地承受网络退化。结构感知方法可以区分各个信道，实现包丢失隐藏和带宽节约。TDM信令的可接入性促进了利用或操纵信令的机制。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. TDM Structure and Structure-aware Transport . . . . . . . . . 4
3. TDMoIP Encapsulation . . . . . . . . . . . . . . . . . . . . . 6
4. Encapsulation Details for Specific PSNs . . . . . . . . . . . 9
4.1. UDP/IP . . . . . . . . . . . . . . . . . . . . . . . . . . 9
4.2. MPLS . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
4.3. L2TPv3 . . . . . . . . . . . . . . . . . . . . . . . . . . 14
4.4. Ethernet . . . . . . . . . . . . . . . . . . . . . . . . . 15
5. TDMoIP Payload Types . . . . . . . . . . . . . . . . . . . . . 17
5.1. AAL1 Format Payload . . . . . . . . . . . . . . . . . . . 18
5.2. AAL2 Format Payload . . . . . . . . . . . . . . . . . . . 19
5.3. HDLC Format Payload . . . . . . . . . . . . . . . . . . . 20
6. TDMoIP Defect Handling . . . . . . . . . . . . . . . . . . . . 21
7. Implementation Issues . . . . . . . . . . . . . . . . . . . . 24
7.1. Jitter and Packet Loss . . . . . . . . . . . . . . . . . . 24
7.2. Timing Recovery . . . . . . . . . . . . . . . . . . . . . 25
7.3. Congestion Control . . . . . . . . . . . . . . . . . . . . 26
8. Security Considerations . . . . . . . . . . . . . . . . . . . 27
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28
10. Applicability Statement . . . . . . . . . . . . . . . . . . . 28
11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 29
Appendix A. Sequence Number Processing (Informative) . . . . . . 30
Appendix B. AAL1 Review (Informative) . . . . . . . . . . . . . . 32
Appendix C. AAL2 Review (Informative) . . . . . . . . . . . . . . 36
Appendix D. Performance Monitoring Mechanisms (Informative) . . . 38
D.1. TDMoIP Connectivity Verification . . . . . . . . . . . . . 38
D.2. OAM Packet Format . . . . . . . . . . . . . . . . . . . . 39
Appendix E. Capabilities, Configuration and Statistics
(Informative) . . . . . . . . . . . . . . . . . . . . 42
References . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
Normative References . . . . . . . . . . . . . . . . . . . . . . 45
Informative References . . . . . . . . . . . . . . . . . . . . . 47
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. TDM Structure and Structure-aware Transport . . . . . . . . . 4
3. TDMoIP Encapsulation . . . . . . . . . . . . . . . . . . . . . 6
4. Encapsulation Details for Specific PSNs . . . . . . . . . . . 9
4.1. UDP/IP . . . . . . . . . . . . . . . . . . . . . . . . . . 9
4.2. MPLS . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
4.3. L2TPv3 . . . . . . . . . . . . . . . . . . . . . . . . . . 14
4.4. Ethernet . . . . . . . . . . . . . . . . . . . . . . . . . 15
5. TDMoIP Payload Types . . . . . . . . . . . . . . . . . . . . . 17
5.1. AAL1 Format Payload . . . . . . . . . . . . . . . . . . . 18
5.2. AAL2 Format Payload . . . . . . . . . . . . . . . . . . . 19
5.3. HDLC Format Payload . . . . . . . . . . . . . . . . . . . 20
6. TDMoIP Defect Handling . . . . . . . . . . . . . . . . . . . . 21
7. Implementation Issues . . . . . . . . . . . . . . . . . . . . 24
7.1. Jitter and Packet Loss . . . . . . . . . . . . . . . . . . 24
7.2. Timing Recovery . . . . . . . . . . . . . . . . . . . . . 25
7.3. Congestion Control . . . . . . . . . . . . . . . . . . . . 26
8. Security Considerations . . . . . . . . . . . . . . . . . . . 27
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28
10. Applicability Statement . . . . . . . . . . . . . . . . . . . 28
11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 29
Appendix A. Sequence Number Processing (Informative) . . . . . . 30
Appendix B. AAL1 Review (Informative) . . . . . . . . . . . . . . 32
Appendix C. AAL2 Review (Informative) . . . . . . . . . . . . . . 36
Appendix D. Performance Monitoring Mechanisms (Informative) . . . 38
D.1. TDMoIP Connectivity Verification . . . . . . . . . . . . . 38
D.2. OAM Packet Format . . . . . . . . . . . . . . . . . . . . 39
Appendix E. Capabilities, Configuration and Statistics
(Informative) . . . . . . . . . . . . . . . . . . . . 42
References . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
Normative References . . . . . . . . . . . . . . . . . . . . . . 45
Informative References . . . . . . . . . . . . . . . . . . . . . 47
Telephony traffic is conventionally carried over connection-oriented synchronous or plesiochronous links (loosely called TDM circuits herein). With the proliferation of Packet Switched Networks (PSNs), transport of TDM services over PSN infrastructures has become desirable. Emulation of TDM circuits over the PSN can be carried out using pseudowires (PWs), as described in the PWE3 architecture [RFC3985]. This emulation must maintain service quality of native TDM; in particular voice quality, latency, timing, and signaling features must be similar to those of existing TDM networks, as described in the TDM PW requirements document [RFC4197].
电话业务量通常通过面向连接的同步或准同步链路（本文中松散地称为TDM电路）承载。随着分组交换网络（PSN）的普及，通过PSN基础设施传输TDM服务已成为人们所期望的。如PWE3体系结构[RFC3985]中所述，可以使用伪线（PW）在PSN上模拟TDM电路。此仿真必须保持本机TDM的服务质量；特别是语音质量、延迟、定时和信令功能必须与现有TDM网络的类似，如TDM PW要求文件[RFC4197]中所述。
Structure-Agnostic TDM over Packet (SAToP) [RFC4553] is a structure-agnostic protocol for transporting TDM over PSNs. The present document details TDM over IP (TDMoIP), a structure-aware method for TDM transport. In contrast to SAToP, structure-aware methods such as TDMoIP ensure the integrity of TDM structure and thus enable the PW to better withstand network degradations. Individual multiplexed channels become visible, enabling the use of per channel mechanisms for packet loss concealment and bandwidth conservation. TDM signaling also becomes accessible, facilitating mechanisms that exploit or manipulate this signaling.
数据包上的结构不可知TDM（SAToP）[RFC4553]是一种用于在PSN上传输TDM的结构不可知协议。本文档详细介绍了TDM over IP（TDMoIP），一种TDM传输的结构感知方法。与SAToP相比，TDMoIP等结构感知方法确保了TDM结构的完整性，从而使PW能够更好地承受网络降级。单个多路复用信道变得可见，从而能够使用每个信道的机制来隐藏数据包丢失和节省带宽。TDM信令也变得可访问，从而促进利用或操纵该信令的机制。
Despite its name, the TDMoIP(R) protocol herein described may operate over several types of PSN, including UDP over IPv4 or IPv6, MPLS, Layer 2 Tunneling Protocol version 3 (L2TPv3) over IP, and pure Ethernet. Implementation specifics for particular PSNs are discussed in Section 4. Although the protocol should be more generally called TDMoPW and its specific implementations TDMoIP, TDMoMPLS, etc., we retain the nomenclature TDMoIP for consistency with earlier usage.
尽管名称不同，本文描述的TDMoIP（R）协议可以在几种类型的PSN上运行，包括IPv4或IPv6上的UDP、MPLS、IP上的第2层隧道协议版本3（L2TPv3）和纯以太网。第4节讨论了特定PSN的实施细节。虽然该协议更一般地称为TDMoPW及其具体实现TDMoIP、TDMoMPLS等，但为了与早期使用保持一致，我们保留了术语TDMoIP。
The interworking function that connects between the TDM and PSN worlds will be called a TDMoIP interworking function (IWF), and it may be situated at the provider edge (PE) or at the customer edge (CE). The IWF that encapsulates TDM and injects packets into the PSN will be called the PSN-bound interworking function, while the IWF that extracts TDM data from packets and generates traffic on a TDM network will be called the TDM-bound interworking function. Emulated TDM circuits are always point-to-point, bidirectional, and transport TDM at the same rate in both directions.
连接TDM和PSN世界的互通功能称为TDMoIP互通功能（IWF），它可能位于提供商边缘（PE）或客户边缘（CE）。封装TDM并将数据包注入PSN的IWF将被称为PSN绑定互通功能，而从数据包中提取TDM数据并在TDM网络上生成流量的IWF将被称为TDM绑定互通功能。仿真TDM电路始终是点对点、双向的，并且在两个方向上以相同的速率传输TDM。
As with all PWs, TDMoIP PWs may be manually configured or set up using the PWE3 control protocol [RFC4447]. Extensions to the PWE3 control protocol required specifically for setup and maintenance of TDMoIP pseudowires are described in [TDM-CONTROL].
与所有PW一样，可以使用PWE3控制协议[RFC4447]手动配置或设置TDMoIP PW。[TDM-control]中描述了设置和维护TDMoIP伪线所需的PWE3控制协议的扩展。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[RFC2119]中所述进行解释。
Although TDM circuits can be used to carry arbitrary bit-streams, there are standardized methods for carrying constant-length blocks of data called "structures". Familiar structures are the T1 or E1 frames [G704] of length 193 and 256 bits, respectively. By concatenation of consecutive T1 or E1 frames we can build higher level structures called superframes or multiframes. T3 and E3 frames [G704][G751] are much larger than those of T1 and E1, and even larger structures are used in the GSM Abis channel described in [TRAU]. TDM structures contain TDM data plus structure overhead; for example, the 193-bit T1 frame contains a single bit of structure overhead and 24 bytes of data, while the 32-byte E1 frame contains a byte of overhead and 31 data bytes.
尽管TDM电路可用于传输任意比特流，但有一些标准化方法用于传输称为“结构”的等长数据块。常见的结构是长度分别为193位和256位的T1或E1帧[G704]。通过串联连续T1或E1帧，我们可以构建称为超帧或多帧的更高层结构。T3和E3帧[G704][G751]比T1和E1的帧大得多，并且在[TRAU]中描述的GSM Abis信道中使用了更大的结构。TDM结构包含TDM数据和结构开销；例如，193位T1帧包含一位结构开销和24字节数据，而32字节E1帧包含一字节开销和31字节数据。
Structured TDM circuits are frequently used to transport multiplexed channels. A single byte in the TDM frame (called a timeslot) is allocated to each channel. A frame of a channelized T1 carries 24 byte-sized channels, while an E1 frame consists of 31 channels. Since TDM frames are sent 8000 times per second, a single byte-sized channel carries 64 kbps.
结构化TDM电路通常用于传输多路复用信道。TDM帧中的一个字节（称为时隙）分配给每个信道。信道化T1的帧承载24字节大小的信道，而E1帧包含31个信道。由于TDM帧每秒发送8000次，因此单字节大小的信道承载64 kbps。
TDM structures are universally delimited by placing an easily detectable periodic bit pattern, called the Frame Alignment Signal (FAS), in the structure overhead. The structure overhead may additionally contain error monitoring and defect indications. We will use the term "structured TDM" to refer to TDM with any level of structure imposed by an FAS. Unstructured TDM signifies a bit stream upon which no structure has been imposed, implying that all bits are available for user data.
TDM结构通过在结构开销中放置一个易于检测的周期性位模式（称为帧对齐信号（FAS））来进行通用分隔。结构开销还可能包含错误监控和缺陷指示。我们将使用术语“结构化TDM”来指FAS施加的任何结构水平的TDM。非结构化TDM表示没有结构的比特流，这意味着所有比特都可用于用户数据。
SAToP [RFC4553] is a structure-agnostic protocol for transporting TDM using PWs. SAToP treats the TDM input as an arbitrary bit-stream, completely disregarding any structure that may exist in the TDM bit-stream. Hence, SAToP is ideal for transport of truly unstructured TDM, but is also suitable for transport of structured TDM when there is no need to protect structure integrity nor interpret or manipulate individual channels during transport. In particular, SAToP is the technique of choice for PSNs with negligible packet loss, and for applications that do not require discrimination between channels nor intervention in TDM signaling.
SAToP[RFC4553]是一种结构无关协议，用于使用PWs传输TDM。SAToP将TDM输入视为任意比特流，完全忽略TDM比特流中可能存在的任何结构。因此，SAToP是真正非结构化TDM传输的理想选择，但也适用于在传输过程中不需要保护结构完整性或解释或操纵单个信道的结构化TDM传输。特别是，SAToP技术是可忽略分组丢失的PSN的首选技术，也适用于不需要信道间区分或TDM信令干预的应用。
As described in [RFC4553], when a single SAToP packet is lost, an "all ones" pattern is played out to the TDM interface. This pattern
如[RFC4553]中所述，当单个SAToP数据包丢失时，TDM接口将播放“所有”模式。这种模式
is interpreted by the TDM end equipment as an Alarm Indication Signal (AIS), which, according to TDM standards [G826], immediately triggers a "severely errored second" event. As such events are considered highly undesirable, the suitability of SAToP is limited to extremely reliable and underutilized PSNs.
由TDM终端设备解释为报警指示信号（AIS），根据TDM标准[G826]，该信号立即触发“严重错误秒”事件。由于此类事件被认为是极不可取的，因此SAToP的适用性仅限于极为可靠且未充分利用的PSN。
When structure-aware TDM transport is employed, it is possible to explicitly safeguard TDM structure during transport over the PSN, thus making possible to effectively conceal packet loss events. Structure-aware transport exploits at least some level of the TDM structure to enhance robustness to packet loss or other PSN shortcomings. Structure-aware TDM PWs are not required to transport structure overhead across the PSN; in particular, the FAS MAY be stripped by the PSN-bound IWF and MUST be regenerated by the TDM-bound IWF. However, structure overhead MAY be transported over the PSN, since it may contain information other than FAS.
当采用结构感知TDM传输时，可以在通过PSN的传输期间显式地保护TDM结构，从而使得能够有效地隐藏分组丢失事件。结构感知传输利用至少某种程度的TDM结构来增强对分组丢失或其他PSN缺点的鲁棒性。结构感知TDM PW无需跨PSN传输结构开销；特别是，FAS可以由PSN绑定的IWF剥离，并且必须由TDM绑定的IWF再生。然而，结构开销可能通过PSN传输，因为它可能包含FAS以外的信息。
In addition to guaranteeing maintenance of TDM synchronization, structure-aware TDM transport can also distinguish individual timeslots of channelized TDM, thus enabling sophisticated packet loss concealment at the channel level. TDM signaling also becomes visible, facilitating mechanisms that maintain or exploit this information. Finally, by taking advantage of TDM signaling and/or voice activity detection, structure-aware TDM transport makes bandwidth conservation possible.
除了保证TDM同步的维护外，结构感知TDM传输还可以区分信道化TDM的各个时隙，从而在信道级别实现复杂的丢包隐藏。TDM信号也变得可见，有助于维护或利用这些信息的机制。最后，通过利用TDM信令和/或语音活动检测，结构感知TDM传输使得带宽节约成为可能。
There are three conceptually distinct methods of ensuring TDM structure integrity -- namely, structure-locking, structure-indication, and structure-reassembly. Structure-locking requires each packet to commence at the start of a TDM structure, and to contain an entire structure or integral multiples thereof. Structure-indication allows packets to contain arbitrary fragments of basic structures, but employs pointers to indicate where each structure commences. Structure-reassembly is only defined for channelized TDM; the PSN-bound IWF extracts and buffers individual channels, and the original structure is reassembled from the received constituents by the TDM-bound IWF.
确保TDM结构完整性有三种概念上不同的方法，即结构锁定、结构指示和结构重组。结构锁定要求每个数据包从TDM结构的开始处开始，并包含整个结构或其整数倍。结构指示允许数据包包含基本结构的任意片段，但使用指针指示每个结构的起始位置。结构重组仅针对信道化TDM定义；PSN绑定的IWF提取和缓冲单个信道，TDM绑定的IWF从接收的成分重新组装原始结构。
All three methods of TDM structure preservation have their advantages. Structure-locking is described in [RFC5086], while the present document specifies both structure-indication (see Section 5.1) and structure-reassembly (see Section 5.2) approaches. Structure-indication is used when channels may be allocated statically, and/or when it is required to interwork with existing circuit emulation systems (CES) based on AAL1. Structure-reassembly is used when dynamic allocation of channels is desirable and/or when it is required to interwork with existing loop emulation systems (LES) based on AAL2.
三种TDM结构保存方法各有优点。[RFC5086]中描述了结构锁定，而本文件规定了结构指示（见第5.1节）和结构重新组装（见第5.2节）方法。当信道可以静态分配时，和/或当需要与基于AAL1的现有电路仿真系统（CES）互通时，使用结构指示。当需要动态分配信道和/或需要与基于AAL2的现有环路仿真系统（LES）互通时，使用结构重组。
Operation, administration, and maintenance (OAM) mechanisms are vital for proper TDM deployments. As aforementioned, structure-aware mechanisms may refrain from transporting structure overhead across the PSN, disrupting OAM functionality. It is beneficial to distinguish between two OAM cases, the "trail terminated" and the "trail extended" scenarios. A trail is defined to be the combination of data and associated OAM information transfer. When the TDM trail is terminated, OAM information such as error monitoring and defect indications are not transported over the PSN, and the TDM networks function as separate OAM domains. In the trail extended case, we transfer the OAM information over the PSN (although not necessarily in its native format). OAM will be discussed further in Section 6.
操作、管理和维护（OAM）机制对于正确的TDM部署至关重要。如上所述，结构感知机制可以避免跨PSN传输结构开销，从而中断OAM功能。区分两种OAM情况是有益的，“线索终止”和“线索扩展”场景。跟踪被定义为数据和相关OAM信息传输的组合。当TDM跟踪终止时，诸如错误监视和缺陷指示之类的OAM信息不会通过PSN传输，并且TDM网络充当单独的OAM域。在trail扩展的情况下，我们通过PSN传输OAM信息（尽管不一定是本机格式）。第6节将进一步讨论OAM。
The overall format of TDMoIP packets is shown in Figure 1.
TDMoIP数据包的整体格式如图1所示。
+---------------------+
| PSN Headers |
+---------------------+
| TDMoIP Control Word |
+---------------------+
| Adapted Payload |
+---------------------+
+---------------------+
| PSN Headers |
+---------------------+
| TDMoIP Control Word |
+---------------------+
| Adapted Payload |
+---------------------+
Figure 1. Basic TDMoIP Packet Format
图1。基本TDMoIP数据包格式
The PSN-specific headers are those of UDP/IP, L2TPv3/IP, MPLS or layer 2 Ethernet, and contain all information necessary for forwarding the packet from the PSN-bound IWF to the TDM-bound one. The PSN is assumed to be reliable enough and of sufficient bandwidth to enable transport of the required TDM data.
特定于PSN的报头是UDP/IP、L2TPv3/IP、MPLS或第2层以太网的报头，包含将数据包从绑定PSN的IWF转发到绑定TDM的IWF所需的所有信息。假定PSN足够可靠，并且具有足够的带宽，以便能够传输所需的TDM数据。
A TDMoIP IWF may simultaneously support multiple TDM PWs, and the TDMoIP IWF MUST maintain context information for each TDM PW. Distinct PWs are differentiated based on PW labels, which are carried in the PSN-specific layers. Since TDM is inherently bidirectional, the association of two PWs in opposite directions is required. The PW labels of the two directions MAY take different values.
TDMoIP IWF可以同时支持多个TDM PW，并且TDMoIP IWF必须维护每个TDM PW的上下文信息。不同的PW基于PW标签进行区分，PW标签位于PSN特定层中。由于TDM本质上是双向的，因此需要在相反方向上关联两个PW。两个方向的PW标签可能采用不同的值。
In addition to the aforementioned headers, an OPTIONAL 12-byte RTP header may appear in order to enable explicit transfer of timing information. This usage is a purely formal reuse of the header format of [RFC3550]. RTP mechanisms, such as header extensions, contributing source (CSRC) list, padding, RTP Control Protocol (RTCP), RTP header compression, Secure RTP (SRTP), etc., are not applicable.
除了上述报头之外，还可能出现可选的12字节RTP报头，以实现定时信息的显式传输。这种用法纯粹是对[RFC3550]头格式的正式重用。RTP机制，如报头扩展、贡献源（CSC）列表、填充、RTP控制协议（RTCP）、RTP报头压缩、安全RTP（SRTP）等不适用。
The RTP timestamp indicates the packet creation time in units of a common clock available to both communicating TDMoIP IWFs. When no common clock is available, or when the TDMoIP IWFs have sufficiently accurate local clocks or can derive sufficiently accurate timing without explicit timestamps, the RTP header SHOULD be omitted.
RTP时间戳以两个通信TDMoIP IWF可用的公共时钟为单位指示分组创建时间。当没有公共时钟可用时，或者当TDMoIP IWF具有足够精确的本地时钟或可以在没有显式时间戳的情况下导出足够精确的定时时，应省略RTP报头。
If RTP is used, the fixed RTP header described in [RFC3550] MUST immediately follow the control word for all PSN types except UDP/IP, for which it MUST precede the control word. The version number MUST be set to 2, the P (padding), X (header extension), CC (CSRC count), and M (marker) fields in the RTP header MUST be set to zero, and the payload type (PT) values MUST be allocated from the range of dynamic values. The RTP sequence number MUST be identical to the sequence number in the TDMoIP control word (see below). The RTP timestamp MUST be generated in accordance with the rules established in [RFC3550]; the clock frequency MUST be an integer multiple of 8 kHz, and MUST be chosen to enable timing recovery that conforms with the appropriate standards (see Section 7.2).
如果使用RTP，[RFC3550]中描述的固定RTP头必须紧跟所有PSN类型的控制字之后，UDP/IP除外，因为UDP/IP必须在控制字之前。版本号必须设置为2，RTP标头中的P（填充）、X（标头扩展）、CC（CSC计数）和M（标记）字段必须设置为零，并且必须从动态值范围中分配有效负载类型（PT）值。RTP序列号必须与TDMoIP控制字中的序列号相同（见下文）。RTP时间戳必须根据[RFC3550]中建立的规则生成；时钟频率必须是8 kHz的整数倍，并且必须选择以实现符合适当标准的定时恢复（见第7.2节）。
The 32-bit control word MUST appear in every TDMoIP packet. Its format, in conformity with [RFC4385], is depicted in Figure 2.
32位控制字必须出现在每个TDMoIP数据包中。其格式符合[RFC4385]，如图2所示。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RES |L|R| M |RES| Length | Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RES |L|R| M |RES| Length | Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2. Structure of the TDMoIP Control Word
图2。TDMoIP控制字的结构
RES (4 bits) The first nibble of the control word MUST be set to zero when the PSN is MPLS, in order to ensure that the packet does not alias an IP packet when forwarding devices perform deep packet inspection. For PSNs other than MPLS, the first nibble MAY be set to zero; however, in earlier versions of TDMoIP this field contained a format identifier that was optionally used to specify the payload format.
RES（4位）当PSN是MPLS时，控制字的第一个半字节必须设置为零，以确保在转发设备执行深度数据包检查时数据包不会与IP数据包别名。对于MPLS以外的psn，第一半字节可以设置为零；但是，在TDMoIP的早期版本中，此字段包含一个格式标识符，该标识符可选地用于指定有效负载格式。
L Local Failure (1 bit) The L flag is set when the IWF has detected or has been informed of a TDM physical layer fault impacting the TDM data being forwarded. In the "trail extended" OAM scenario the L flag MUST be set when the IWF detects loss of signal, loss of frame synchronization, or AIS. When the L flag is set the contents of the packet may not be meaningful, and the payload MAY be suppressed in order to conserve bandwidth. Once set, if the TDM fault is rectified the L flag MUST be cleared. Use of the L flag is further explained in Section 6.
L本地故障（1位）当IWF检测到或被告知TDM物理层故障影响正在转发的TDM数据时，设置L标志。在“trail extended”OAM场景中，当IWF检测到信号丢失、帧同步丢失或AIS时，必须设置L标志。当设置L标志时，分组的内容可能没有意义，并且可以抑制有效载荷以节省带宽。一旦设置，如果TDM故障已纠正，则必须清除L标志。第6节进一步解释了L标志的使用。
R Remote Failure (1 bit) The R flag is set when the IWF has detected or has been informed, that TDM data is not being received from the remote TDM network, indicating failure of the reverse direction of the bidirectional connection. An IWF SHOULD generate TDM Remote Defect Indicator (RDI) upon receipt of an R flag indication. In the "trail extended" OAM scenario the R flag MUST be set when the IWF detects RDI. Use of the R flag is further explained in Section 6.
R远程故障（1位）当IWF检测到或被告知没有从远程TDM网络接收TDM数据时，设置R标志，指示双向连接的反向故障。IWF应在收到R标志指示后生成TDM远程缺陷指示器（RDI）。在“trail extended”OAM场景中，当IWF检测到RDI时，必须设置R标志。第6节进一步解释了R标志的使用。
M Defect Modifier (2 bits) Use of the M field is optional; when used, it supplements the meaning of the L flag.
M缺陷修饰符（2位）M字段的使用是可选的；使用时，它补充了L标志的含义。
When L is cleared (indicating valid TDM data) the M field is used as follows:
清除L（表示有效的TDM数据）时，M字段使用如下：
0 0 indicates no local defect modification. 0 1 reserved. 1 0 reserved. 1 1 reserved.
0表示没有局部缺陷修改。0 1保留。保留10个。1保留。
When L is set (invalid TDM data) the M field is used as follows:
当设置L（无效TDM数据）时，M字段使用如下：
0 0 indicates a TDM defect that should trigger conditioning or AIS generation by the TDM-bound IWF. 0 1 indicates idle TDM data that should not trigger any alarm. If the payload has been suppressed then the preconfigured idle code should be generated at egress. 1 0 indicates corrupted but potentially recoverable TDM data. 1 1 reserved.
0 0表示TDM缺陷，该缺陷应通过TDM绑定的IWF触发调节或AIS生成。0 1表示不应触发任何警报的空闲TDM数据。如果有效负载已被抑制，则应在出口处生成预配置的空闲代码。1 0表示已损坏但可能可恢复的TDM数据。1保留。
Use of the M field is further explained in Section 6.
第6节进一步解释了M字段的使用。
RES (2 bits) These bits are reserved and MUST be set to zero.
RES（2位）这些位是保留的，必须设置为零。
Length (6 bits) is used to indicate the length of the TDMoIP packet (control word and payload), in case padding is employed to meet minimum transmission unit requirements of the PSN. It MUST be used if the total packet length (including PSN, optional RTP, control word, and payload) is less than 64 bytes, and MUST be set to zero when not used.
长度（6位）用于指示TDMoIP数据包（控制字和有效载荷）的长度，以防采用填充来满足PSN的最低传输单元要求。如果总数据包长度（包括PSN、可选RTP、控制字和有效负载）小于64字节，则必须使用它，并且在不使用时必须设置为零。
Sequence number (16 bits) The TDMoIP sequence number provides the common PW sequencing function described in [RFC3985], and enables detection of lost and misordered packets. The sequence number space is a 16-bit, unsigned circular space; the initial value of the sequence number SHOULD be random (unpredictable) for security
序列号（16位）TDMoIP序列号提供[RFC3985]中描述的公共PW排序功能，并能够检测丢失和错误排序的数据包。序列号空间是一个16位的无符号循环空间；为了安全起见，序列号的初始值应该是随机的（不可预测的）
purposes, and its value is incremented modulo 2^16 separately for each PW. Pseudocode for a sequence number processing algorithm that could be used by a TDM-bound IWF is provided in Appendix A.
对于每个PW，其值分别以2^16的模递增。附录a中提供了TDM绑定IWF可使用的序列号处理算法的伪代码。
In order to form the TDMoIP payload, the PSN-bound IWF extracts bytes from the continuous TDM stream, filling each byte from its most significant bit. The extracted bytes are then adapted using one of two adaptation algorithms (see Section 5), and the resulting adapted payload is placed into the packet.
为了形成TDMoIP有效载荷，绑定PSN的IWF从连续TDM流中提取字节，从其最高有效位填充每个字节。然后使用两种自适应算法中的一种对提取的字节进行自适应（参见第5节），并将得到的自适应有效载荷放入分组中。
TDMoIP PWs may exploit various PSNs, including UDP/IP (both IPv4 and IPv6), L2TPv3 over IP (with no intervening UDP), MPLS, and layer-2 Ethernet. In the following subsections, we depict the packet format for these cases.
TDMoIP PWs可以利用各种PSN，包括UDP/IP（IPv4和IPv6）、L2TPv3 over IP（无干预UDP）、MPLS和第二层以太网。在下面的小节中，我们描述了这些情况下的数据包格式。
For MPLS PSNs, the format is aligned with those specified in [Y1413] and [Y1414]. For UDP/IP PSNs, the format is aligned with those specified in [Y1453] and [Y1452]. For transport over layer 2 Ethernet the format is aligned with [MEF8].
对于MPLS PSN，格式与[Y1413]和[Y1414]中规定的格式一致。对于UDP/IP PSN，格式与[Y1453]和[Y1452]中指定的格式一致。对于第2层以太网传输，格式与[MEF8]一致。
ITU-T recommendation Y.1453 [Y1453] describes structure-agnostic and structure-aware mechanisms for transporting TDM over IP networks. Similarly, ITU-T recommendation Y.1452 [Y1452] defines structure-reassembly mechanisms for this purpose. Although the terminology used here differs slightly from that of the ITU, implementations of TDMoIP for UDP/IP PSNs as described herein will interoperate with implementations designed to comply with Y.1453 subclause 9.2.2 or Y.1452 clause 10.
ITU-T建议Y.1453[Y1453]描述了通过IP网络传输TDM的结构无关和结构感知机制。同样，ITU-T建议Y.1452[Y1452]为此定义了结构重组机制。尽管此处使用的术语与ITU的术语略有不同，但本文所述的UDP/IP PSN TDMoIP实现将与设计为符合Y.1453第9.2.2款或Y.1452第10条的实现进行互操作。
For UDP/IPv4, the headers as described in [RFC768] and [RFC791] are prefixed to the TDMoIP data. The format is similar for UDP/IPv6, except the IP header described in [RFC2460] is used. The TDMoIP packet structure is depicted in Figure 3.
对于UDP/IPv4，TDMoIP数据的前缀为[RFC768]和[RFC791]中所述的标头。该格式与UDP/IPv6类似，只是使用了[RFC2460]中描述的IP头。TDMoIP分组结构如图3所示。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPVER | IHL | IP TOS | Total Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Identification |Flags| Fragment Offset |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Time to Live | Protocol | IP Header Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source IP Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination IP Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Port Number | Destination Port Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| UDP Length | UDP Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
opt|RTV|P|X| CC |M| PT | RTP Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
opt| Timestamp |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
opt| SSRC identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RES |L|R| M |RES| Length | Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Adapted Payload |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPVER | IHL | IP TOS | Total Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Identification |Flags| Fragment Offset |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Time to Live | Protocol | IP Header Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source IP Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination IP Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Port Number | Destination Port Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| UDP Length | UDP Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
opt|RTV|P|X| CC |M| PT | RTP Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
opt| Timestamp |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
opt| SSRC identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RES |L|R| M |RES| Length | Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Adapted Payload |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3. TDMoIP Packet Format for UDP/IP
图3。UDP/IP的TDMoIP数据包格式
The first five rows are the IP header, the sixth and seventh rows are the UDP header. Rows 8 through 10 are the optional RTP header. Row 11 is the TDMoIP control word.
前五行是IP头，第六行和第七行是UDP头。第8行到第10行是可选的RTP标头。第11行是TDMoIP控制字。
IPVER (4 bits) is the IP version number, e.g., IPVER=4 for IPv4.
IPVER（4位）是IP版本号，例如，对于IPv4，IPVER=4。
IHL (4 bits) is the length in 32-bit words of the IP header, IHL=5.
IHL（4位）是IP头的32位字长度，IHL=5。
IP TOS (8 bits) is the IP type of service.
IP TOS（8位）是IP类型的服务。
Total Length (16 bits) is the length in bytes of header and data.
总长度（16位）是标头和数据的字节长度。
Identification (16 bits) is the IP fragmentation identification field.
标识（16位）是IP碎片标识字段。
Flags (3 bits) are the IP control flags and MUST be set to 2 in order to avoid fragmentation.
标志（3位）是IP控制标志，必须设置为2以避免碎片。
Fragment Offset (13 bits) indicates where in the datagram the fragment belongs and is not used for TDMoIP.
片段偏移量（13位）表示片段在数据报中的位置，不用于TDMoIP。
Time to Live (8 bits) is the IP time to live field. Datagrams with zero in this field are to be discarded.
生存时间（8位）是IP生存时间字段。此字段中为零的数据报将被丢弃。
Protocol (8 bits) MUST be set to 0x11 (17) to signify UDP.
协议（8位）必须设置为0x11（17）以表示UDP。
IP Header Checksum (16 bits) is a checksum for the IP header.
IP报头校验和（16位）是IP报头的校验和。
Source IP Address (32 bits) is the IP address of the source.
源IP地址（32位）是源的IP地址。
Destination IP Address (32 bits) is the IP address of the destination.
目标IP地址（32位）是目标的IP地址。
Source and Destination Port Numbers (16 bits each)
源和目标端口号（每个16位）
Either the source UDP port or destination UDP port MAY be used to multiplex and demultiplex individual PWs between nodes. Architecturally [RFC3985], this makes the UDP port act as the PW Label. PW endpoints MUST agree upon use of either the source UDP or destination UDP port as the PW Label.
源UDP端口或目标UDP端口可用于在节点之间多路复用和解多路复用单个PW。在体系结构上[RFC3985]，这使得UDP端口充当PW标签。PW端点必须同意使用源UDP或目标UDP端口作为PW标签。
UDP ports MUST be manually configured by both endpoints of the PW. The configured source or destination port (one or the other, but not both) together with both the source and destination IP addresses uniquely identify the PW. When the source UDP port is used as the PW label, the destination UDP port number MUST be set to the IANA assigned value of 0x085E (2142). All UDP port values that function as PW labels SHOULD be in the range of dynamically allocated UDP port numbers (0xC000 through 0xFFFF).
UDP端口必须由PW的两个端点手动配置。配置的源或目标端口（一个或另一个，但不是两个）以及源和目标IP地址共同唯一地标识PW。当源UDP端口用作PW标签时，目标UDP端口号必须设置为IANA分配的值0x085E（2142）。用作PW标签的所有UDP端口值应在动态分配的UDP端口号范围内（0xC000到0xFFFF）。
While many UDP-based protocols are able to traverse middleboxes without dire consequences, the use of UDP ports as PW labels makes middlebox traversal more difficult. Hence, it is NOT RECOMMENDED to use UDP-based PWs where port-translating middleboxes are present between PW endpoints.
虽然许多基于UDP的协议能够在不造成可怕后果的情况下遍历中间箱，但将UDP端口用作PW标签会使中间箱遍历更加困难。因此，如果PW端点之间存在端口转换中间盒，则不建议使用基于UDP的PW。
UDP Length (16 bits) is the length in bytes of UDP header and data.
UDP长度（16位）是UDP标头和数据的字节长度。
UDP Checksum (16 bits) is the checksum of UDP/IP header and data. If not computed it MUST be set to zero.
UDP校验和（16位）是UDP/IP报头和数据的校验和。如果未计算，则必须将其设置为零。
ITU-T recommendation Y.1413 [Y1413] describes structure-agnostic and structure-aware mechanisms for transporting TDM over MPLS networks. Similarly, ITU-T recommendation Y.1414 [Y1413] defines structure-reassembly mechanisms for this purpose. Although the terminology used here differs slightly from that of the ITU, implementations of TDMoIP for MPLS PSNs as described herein will interoperate with implementations designed to comply with Y.1413 subclause 9.2.2 or Y.1414 clause 10.
ITU-T建议Y.1413[Y1413]描述了通过MPLS网络传输TDM的结构无关和结构感知机制。类似地，ITU-T建议Y.1414[Y1413]为此定义了结构重组机制。尽管此处使用的术语与ITU的术语略有不同，但此处所述的MPLS PSN TDMoIP实现将与设计为符合Y.1413第9.2.2款或Y.1414第10条的实现进行互操作。
The MPLS header as described in [RFC3032] is prefixed to the control word and TDM payload. The packet structure is depicted in Figure 4.
[RFC3032]中所述的MPLS报头以控制字和TDM有效负载为前缀。数据包结构如图4所示。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tunnel Label | EXP |S| TTL |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PW label | EXP |1| TTL |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RES |L|R| M |RES| Length | Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
opt|RTV|P|X| CC |M| PT | RTP Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
opt| Timestamp |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
opt| SSRC identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Adapted Payload |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tunnel Label | EXP |S| TTL |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PW label | EXP |1| TTL |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RES |L|R| M |RES| Length | Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
opt|RTV|P|X| CC |M| PT | RTP Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
opt| Timestamp |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
opt| SSRC identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Adapted Payload |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4. TDMoIP Packet Format for MPLS
图4。MPLS的TDMoIP数据包格式
The first two rows depicted above are the MPLS header; the third is the TDMoIP control word. Fields not previously described will now be explained.
上面描述的前两行是MPLS报头；第三个是TDMoIP控制字。现在将解释之前未描述的字段。
Tunnel Label (20 bits) is the MPLS label that identifies the MPLS LSP used to tunnel the TDM packets through the MPLS network. The label can be assigned either by manual provisioning or via an MPLS control protocol. While transiting the MPLS network there may be zero, one, or several tunnel label rows. For label stack usage see [RFC3032].
隧道标签（20位）是MPLS标签，标识用于通过MPLS网络隧道TDM数据包的MPLS LSP。标签可以通过手动设置或通过MPLS控制协议进行分配。在传输MPLS网络时，可能有零行、一行或多行隧道标签。有关标签堆栈的用法，请参见[RFC3032]。
EXP (3 bits) experimental field, may be used to carry Diffserv classification for tunnel labels.
EXP（3位）实验场，可用于对隧道标签进行区分服务分类。
S (1 bit) the stacking bit indicates MPLS stack bottom. S=0 for all tunnel labels, and S=1 for the PW label.
堆叠位表示MPLS堆栈底部。所有隧道标签S=0，PW标签S=1。
TTL (8 bits) MPLS Time to live.
TTL（8位）MPLS生存时间。
PW Label (20 bits) This label MUST be a valid MPLS label, and MAY be configured or signaled.
PW标签（20位）此标签必须是有效的MPLS标签，并且可以配置或发送信号。
The L2TPv3 header defined in [RFC3931] is prefixed to the TDMoIP data. The packet structure is depicted in Figure 5.
[RFC3931]中定义的L2TPv3报头以TDMoIP数据为前缀。数据包结构如图5所示。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPVER | IHL | IP TOS | Total Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Identification |Flags| Fragment Offset |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Time to Live | Protocol | IP Header Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source IP Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination IP Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Session ID = PW label |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| cookie 1 (optional) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| cookie 2 (optional) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RES |L|R| M |RES| Length | Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
opt|RTV|P|X| CC |M| PT | RTP Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
opt| Timestamp |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
opt| SSRC identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Adapted Payload |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPVER | IHL | IP TOS | Total Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Identification |Flags| Fragment Offset |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Time to Live | Protocol | IP Header Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source IP Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination IP Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Session ID = PW label |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| cookie 1 (optional) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| cookie 2 (optional) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RES |L|R| M |RES| Length | Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
opt|RTV|P|X| CC |M| PT | RTP Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
opt| Timestamp |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
opt| SSRC identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Adapted Payload |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5. TDMoIP Packet Format for L2TPv3
图5。L2TPv3的TDMoIP数据包格式
Rows 6 through 8 are the L2TPv3 header. Fields not previously described will now be explained.
第6行到第8行是L2TPv3标头。现在将解释之前未描述的字段。
Protocol (8 bits) is the IP protocol field. It must be set to 0x73 (115), the user port number that has been assigned to L2TP by IANA.
协议（8位）是IP协议字段。它必须设置为0x73（115），即IANA分配给L2TP的用户端口号。
Session ID (32 bits) is the locally significant L2TP session identifier, and contains the PW label. The value 0 is reserved.
会话ID（32位）是本地有效的L2TP会话标识符，包含PW标签。值0是保留的。
Cookie (32 or 64 bits) is an optional field that contains a randomly selected value that can be used to validate association of the received frame with the expected PW.
Cookie（32或64位）是一个可选字段，其中包含一个随机选择的值，可用于验证接收帧与预期PW的关联。
Metro Ethernet Forum Implementation Agreement 8 [MEF8] describes structure-agnostic and structure-aware mechanisms for transporting TDM over Ethernet networks. Implementations of structure-indicated TDMoIP as described herein will interoperate with implementations designed to comply with MEF 8 Section 6.3.3.
Metro Ethernet Forum实施协议8[MEF8]描述了通过以太网传输TDM的结构无关和结构感知机制。本文所述的TDMoIP结构的实现将与设计为符合MEF 8第6.3.3节的实现互操作。
The TDMoIP payload is encapsulated in an Ethernet frame by prefixing the Ethernet destination and source MAC addresses, optional VLAN header, and Ethertype, and suffixing the four-byte frame check sequence. TDMoIP implementations MUST be able to receive both industry standard (DIX) Ethernet and IEEE 802.3 [IEEE802.3] frames and SHOULD transmit Ethernet frames.
TDMoIP有效负载通过在以太网目标和源MAC地址、可选VLAN头和EthertType前面加前缀，并在四字节帧检查序列后面加后缀，封装在以太网帧中。TDMoIP实现必须能够接收行业标准（DIX）以太网和IEEE 802.3[IEEE802.3]帧，并应传输以太网帧。
Ethernet encapsulation introduces restrictions on both minimum and maximum packet size. Whenever the entire TDMoIP packet is less than 64 bytes, padding is introduced and the true length indicated by using the Length field in the control word. In order to avoid fragmentation, the TDMoIP packet MUST be restricted to the maximum payload size. For example, the length of the Ethernet payload for a UDP/IP encapsulation of AAL1 format payload with 30 PDUs per packet is 1472 bytes, which falls below the maximal permitted payload size of 1500 bytes.
以太网封装引入了对最小和最大数据包大小的限制。每当整个TDMoIP数据包小于64字节时，就会引入填充，并使用控制字中的长度字段指示真实长度。为了避免碎片，必须将TDMoIP数据包限制为最大有效负载大小。例如，AAL1格式有效负载的UDP/IP封装（每个数据包30个PDU）的以太网有效负载长度为1472字节，低于1500字节的最大允许有效负载大小。
Ethernet frames MAY be used for TDMoIP transport without intervening IP or MPLS layers, however, an MPLS-style label MUST always be present. In this four-byte header S=1, and all other non-label bits are reserved (set to zero in the PSN-bound direction and ignored in the TDM-bound direction). The Ethertype SHOULD be set to 0x88D8 (35032), the value allocated for this purpose by the IEEE, but MAY be set to 0x8847 (34887), the Ethertype of MPLS. The overall frame structure is as follows:
以太网帧可用于TDMoIP传输，无需干预IP或MPLS层，但是，MPLS样式的标签必须始终存在。在这个四字节头中，S=1，所有其他非标签位被保留（在PSN绑定方向设置为零，在TDM绑定方向被忽略）。Ethertype应设置为0x88D8（35032），IEEE为此目的分配的值，但也可以设置为0x8847（34887），即MPLS的Ethertype。总体框架结构如下：
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination MAC Address
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Destination MAC Address (cont) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source MAC Address
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Source MAC Address (cont) | VLAN Ethertype (opt) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|VLP|C| VLAN ID (opt) | Ethertype |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PW label | RES |1| RES |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RES |L|R| M |RES| Length | Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
opt|RTV|P|X| CC |M| PT | RTP Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
opt| Timestamp |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
opt| SSRC identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Adapted Payload |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Frame Check Sequence |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination MAC Address
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Destination MAC Address (cont) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source MAC Address
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Source MAC Address (cont) | VLAN Ethertype (opt) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|VLP|C| VLAN ID (opt) | Ethertype |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PW label | RES |1| RES |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RES |L|R| M |RES| Length | Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
opt|RTV|P|X| CC |M| PT | RTP Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
opt| Timestamp |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
opt| SSRC identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Adapted Payload |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Frame Check Sequence |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6. TDMoIP Packet Format for Ethernet
图6。以太网的TDMoIP数据包格式
Rows 1 through 6 are the (DIX) Ethernet header; for 802.3 there may be additional fields, depending on the value of the length field, see [IEEE802.3]. Fields not previously described will now be explained.
第1行到第6行是（DIX）以太网报头；对于802.3，根据长度字段的值，可能会有其他字段，请参见[IEEE802.3]。现在将解释之前未描述的字段。
Destination MAC Address (48 bits) is the globally unique address of a single station that is to receive the packet. The format is defined in [IEEE802.3].
目标MAC地址（48位）是要接收数据包的单个站点的全局唯一地址。该格式在[IEEE802.3]中定义。
Source MAC Address (48 bits) is the globally unique address of the station that originated the packet. The format is defined in [IEEE802.3].
源MAC地址（48位）是发起数据包的站点的全局唯一地址。该格式在[IEEE802.3]中定义。
VLAN Ethertype (16 bits) 0x8100 in this position indicates that optional VLAN tagging specified in [IEEE802.1Q] is employed, and that the next two bytes contain the VLP, C, and VLAN ID fields. VLAN tags may be stacked, in which case the two-byte field following the VLAN ID is once again a VLAN Ethertype.
此位置的VLAN Ethertype（16位）0x8100表示使用了[IEEE802.1Q]中指定的可选VLAN标记，并且接下来的两个字节包含VLP、C和VLAN ID字段。VLAN标记可以堆叠，在这种情况下，VLAN ID后面的两字节字段再次是VLAN以太网类型。
VLP (3 bits) is the VLAN priority, see [IEEE802.1Q].
VLP（3位）是VLAN优先级，请参见[IEEE802.1Q]。
C (1 bit) the "canonical format indicator" being set, indicates that route descriptors appear; see [IEEE802.1Q].
C（1位）设置的“规范格式指示器”表示出现路由描述符；参见[IEEE802.1Q]。
VLAN ID (12 bits) the VLAN identifier uniquely identifies the VLAN to which the frame belongs. If zero, only the VLP information is meaningful. Values 1 and FFF are reserved. The other 4093 values are valid VLAN identifiers.
VLAN ID（12位）：VLAN标识符唯一标识帧所属的VLAN。如果为零，则只有VLP信息有意义。保留值1和FFF。其他4093个值是有效的VLAN标识符。
Ethertype (16 bits) is the protocol identifier, as allocated by the IEEE. The Ethertype SHOULD be set to 0x88D8 (35032), but MAY be set to 0x8847 (34887).
Ethertype（16位）是由IEEE分配的协议标识符。Ethertype应设置为0x88D8（35032），但也可以设置为0x8847（34887）。
PW Label (20 bits) This label MUST be manually configured. The remainder of this row is formatted to resemble an MPLS label.
PW标签（20位）此标签必须手动配置。此行的其余部分格式化为类似MPLS标签。
Frame Check Sequence (32 bits) is a Cyclic Redundancy Check (CRC) error detection field, calculated per [IEEE802.3].
帧检查序列（32位）是循环冗余校验（CRC）错误检测字段，根据[IEEE802.3]计算。
As discussed at the end of Section 3, TDMoIP transports real-time streams by first extracting bytes from the stream, and then adapting these bytes. TDMoIP offers two different adaptation algorithms, one for constant-rate real-time traffic, and one for variable-rate real-time traffic.
如第3节末尾所述，TDMoIP通过首先从流中提取字节，然后调整这些字节来传输实时流。TDMoIP提供两种不同的自适应算法，一种用于固定速率实时流量，另一种用于可变速率实时流量。
For unstructured TDM, or structured but unchannelized TDM, or structured channelized TDM with all channels active all the time, a constant-rate adaptation is needed. In such cases TDMoIP uses structure-indication to emulate the native TDM circuit, and the adaptation is known as "circuit emulation". However, for channelized TDM wherein the individual channels (corresponding to "loops" in telephony terminology) are frequently inactive, bandwidth may be conserved by transporting only active channels. This results in variable-rate real-time traffic, for which TDMoIP uses structure-reassembly to emulate the individual loops, and the adaptation is known as "loop emulation".
对于非结构化TDM，或结构化但未退火的TDM，或所有信道始终处于活动状态的结构化信道化TDM，需要恒定速率自适应。在这种情况下，TDMoIP使用结构指示来模拟本机TDM电路，这种自适应称为“电路模拟”。然而，对于信道化TDM，其中各个信道（对应于电话术语中的“环路”）经常是非活动的，可以通过仅传输活动信道来节省带宽。这会产生变速率实时流量，TDMoIP使用结构重组来模拟各个环路，这种自适应称为“环路模拟”。
TDMoIP uses constant-rate AAL1 [AAL1,CES] for circuit emulation, while variable-rate AAL2 [AAL2] is employed for loop emulation. The AAL1 mode MUST be used for structured transport of unchannelized data and SHOULD be used for circuits with relatively constant usage. In addition, AAL1 MUST be used when the TDM-bound IWF is required to maintain a high timing accuracy (e.g., when its timing is further distributed) and SHOULD be used when high reliability is required. AAL2 SHOULD be used for channelized TDM when bandwidth needs to be conserved, and MAY be used whenever usage of voice-carrying channels is expected to be highly variable.
TDMoIP使用恒定速率AAL1[AAL1，CES]进行电路仿真，而可变速率AAL2[AAL2]用于环路仿真。AAL1模式必须用于非退火数据的结构化传输，并且应用于使用相对稳定的电路。此外，当需要TDM绑定的IWF保持高定时精度（例如，当其定时进一步分布时）时，必须使用AAL1，并且当需要高可靠性时，应使用AAL1。当需要节省带宽时，AAL2应用于信道化TDM，并且当预计语音承载信道的使用高度可变时，可使用AAL2。
Additionally, a third mode is defined specifically for efficient transport of High-Level Data Link Control (HDLC)-based Common Channel Signaling (CCS) carried in TDM channels.
另外，第三模式被专门定义用于在TDM信道中承载的基于高电平数据链路控制（HDLC）的公共信道信令（CCS）的高效传输。
The AAL family of protocols is a natural choice for TDM emulation. Although originally developed to adapt various types of application data to the rigid format of ATM, the mechanisms are general solutions to the problem of transporting constant or variable-rate real-time streams over a packet network.
AAL协议系列是TDM仿真的自然选择。虽然最初是为了使各种类型的应用程序数据适应严格的ATM格式而开发的，但这些机制是通过分组网络传输恒定或可变速率实时流问题的一般解决方案。
Since the AAL mechanisms are extensively deployed within and on the edge of the public telephony system, they have been demonstrated to reliably transfer voice-grade channels, data and telephony signaling. These mechanisms are mature and well understood, and implementations are readily available.
由于AAL机制广泛部署在公共电话系统内部和边缘，它们已被证明能够可靠地传输语音级信道、数据和电话信令。这些机制已经成熟并得到了很好的理解，实现也很容易获得。
Finally, simplified service interworking with legacy networks is a major design goal of TDMoIP. Re-use of AAL technologies simplifies interworking with existing AAL1- and AAL2-based networks.
最后，简化与传统网络的业务互通是TDMoIP的主要设计目标。AAL技术的重复使用简化了与现有基于AAL1和AAL2的网络的互通。
For the prevalent cases of unchannelized TDM, or channelized TDM for which the channel allocation is static, the payload can be efficiently encoded using constant-rate AAL1 adaptation. The AAL1 format is described in [AAL1] and its use for circuit emulation over ATM in [CES]. We briefly review highlights of AAL1 technology in Appendix B. In this section we describe the use of AAL1 in the context of TDMoIP.
对于信道分配为静态的未退火TDM或信道化TDM的常见情况，可以使用恒定速率AAL1自适应有效地编码有效载荷。AAL1格式在[AAL1]中进行了描述，并在[CES]中用于ATM上的电路仿真。我们在附录B中简要回顾了AAL1技术的重点。在本节中，我们描述了AAL1在TDMoIP环境中的使用。
+-------------+----------------+
|control word | AAL1 PDU |
+-------------+----------------+
+-------------+----------------+
|control word | AAL1 PDU |
+-------------+----------------+
Figure 7a. Single AAL1 PDU per TDMoIP Packet
图7a。每个TDMoIP数据包的单个AAL1 PDU
+-------------+----------------+ +----------------+
|control word | AAL1 PDU |---| AAL1 PDU |
+-------------+----------------+ +----------------+
+-------------+----------------+ +----------------+
|control word | AAL1 PDU |---| AAL1 PDU |
+-------------+----------------+ +----------------+
Figure 7b. Multiple AAL1 PDUs per TDMoIP Packet
图7b。每个TDMoIP数据包有多个AAL1 PDU
In AAL1 mode the TDMoIP payload consists of at least one, and perhaps many, 48-byte "AAL1 PDUs", see Figures 7a and 7b. The number of PDUs MUST be pre-configured and MUST be chosen such that the overall packet size does not exceed the maximum allowed by the PSN (e.g., 30 for UDP/IP over Ethernet). The precise number of PDUs per packet is typically chosen taking latency and bandwidth constraints into account. Using a single PDU delivers minimal latency, but incurs the highest overhead. All TDMoIP implementations MUST support between 1 and 8 PDUs per packet for E1 and T1 circuits, and between 5 and 15 PDUs per packet for E3 and T3 circuits.
在AAL1模式下，TDMoIP有效载荷由至少一个，也许是多个48字节的“AAL1 PDU”组成，见图7a和7b。必须预先配置PDU的数量，并且必须选择这样的数量，即总数据包大小不超过PSN允许的最大值（例如，对于以太网UDP/IP，为30）。每个数据包的PDU的精确数量通常是在考虑延迟和带宽限制的情况下选择的。使用单个PDU可以提供最小的延迟，但会产生最高的开销。对于E1和T1电路，所有TDMoIP实现必须支持每个数据包1到8个PDU，对于E3和T3电路，每个数据包必须支持5到15个PDU。
AAL1 differentiates between unstructured and structured data transfer, which correspond to structure-agnostic and structure-aware transport. For structure-agnostic transport, AAL1 provides no inherent advantage as compared to SAToP; however, there may be scenarios for which its use is desirable. For example, when it is necessary to interwork with an existing AAL1 ATM circuit emulation system, or when clock recovery based on AAL1-specific mechanisms is favored.
AAL1区分了非结构化和结构化数据传输，它们对应于结构无关和结构感知传输。对于结构不可知的传输，AAL1与SAToP相比没有固有的优势；然而，在某些情况下，可能需要使用它。例如，当需要与现有AAL1 ATM电路仿真系统互通时，或当基于AAL1特定机制的时钟恢复受到青睐时。
For structure-aware transport, [CES] defines two modes, structured and structured with Channel Associated Signaling (CAS). Structured AAL1 maintains TDM frame synchronization by embedding a pointer to the beginning of the next frame in the AAL1 PDU header. Similarly, structured AAL1 with CAS maintains TDM frame and multiframe synchronization by embedding a pointer to the beginning of the next multiframe. Furthermore, structured AAL1 with CAS contains a substructure including the CAS signaling bits.
对于结构感知传输，[CES]定义了两种模式，结构化和与信道相关信令（CAS）结构化。结构化AAL1通过在AAL1 PDU报头中嵌入指向下一帧开头的指针来维护TDM帧同步。类似地，带有CAS的结构化AAL1通过嵌入指向下一个多帧开始的指针来维护TDM帧和多帧同步。此外，具有CAS的结构化AAL1包含包括CAS信令位的子结构。
Although AAL1 may be configured to transport fractional E1 or T1 circuits, the allocation of channels to be transported must be static due to the fact that AAL1 transports constant-rate bit-streams. It is often the case that not all the channels in a TDM circuit are simultaneously active ("off-hook"), and activity status may be determined by observation of the TDM signaling channel. Moreover, even during active calls, about half the time is silence that can be identified using voice activity detection (VAD). Using the variable-rate AAL2 mode, we may dynamically allocate channels to be transported, thus conserving bandwidth.
尽管AAL1可配置为传输分数E1或T1电路，但由于AAL1传输恒定速率比特流的事实，要传输的信道的分配必须是静态的。通常情况下，并非TDM电路中的所有信道都同时激活（“摘机”），并且可以通过观察TDM信令信道来确定活动状态。此外，即使在主动呼叫期间，也有一半的时间是沉默，可以通过语音活动检测（VAD）识别。使用可变速率AAL2模式，我们可以动态分配要传输的信道，从而节省带宽。
The AAL2 format is described in [AAL2] and its use for loop emulation over ATM is explained in [SSCS,LES]. We briefly review highlights of AAL2 technology in Appendix C. In this section, we describe the use of AAL2 in the context of TDMoIP.
AAL2格式在[AAL2]中描述，其在ATM上的环路仿真中的使用在[SSC，LES]中解释。我们在附录C中简要回顾了AAL2技术的重点。在本节中，我们描述了AAL2在TDMoIP环境中的使用。
+-------------+----------------+ +----------------+
|control word | AAL2 PDU |---| AAL2 PDU |
+-------------+----------------+ +----------------+
+-------------+----------------+ +----------------+
|control word | AAL2 PDU |---| AAL2 PDU |
+-------------+----------------+ +----------------+
Figure 8. Concatenation of AAL2 PDUs in a TDMoIP Packet
图8。TDMoIP数据包中AAL2 PDU的级联
In AAL2 mode the TDMoIP payload consists of one or more variable-length "AAL2 PDUs", see Figure 8. Each AAL2 PDU contains 3 bytes of overhead and between 1 and 64 bytes of payload. A packet may be constructed by inserting PDUs corresponding to all active channels, by appending PDUs ready at a certain time, or by any other means. Hence, more than one PDU belonging to a single channel may appear in a packet.
在AAL2模式下，TDMoIP有效载荷由一个或多个可变长度“AAL2 PDU”组成，见图8。每个AAL2 PDU包含3字节的开销和1到64字节的有效负载。可以通过插入对应于所有活动信道的pdu、通过在特定时间附加准备就绪的pdu或通过任何其他方式来构造分组。因此，属于单个信道的多个PDU可以出现在分组中。
[RFC3985] denotes as Native Service Processing (NSP) functions all processing of the TDM data before its use as payload. Since AAL2 is inherently variable rate, arbitrary NSP functions MAY be performed before the channel is placed in the AAL2 loop emulation payload. These include testing for on-hook/off-hook status, voice activity detection, speech compression, fax/modem/tone relay, etc.
[RFC3985]表示本机服务处理（NSP）功能在TDM数据用作有效负载之前对其进行所有处理。由于AAL2本质上是可变速率的，因此在将信道置于AAL2环路仿真有效负载中之前，可以执行任意NSP功能。这些包括测试挂机/摘机状态、语音活动检测、语音压缩、传真/调制解调器/音频中继等。
All mechanisms described in [AAL2,SSCS,LES] may be used for TDMoIP. In particular, channel identifier (CID) encoding and use of PAD octets according to [AAL2], encoding formats defined in [SSCS], and transport of CAS and CCS signaling as described in [LES] MAY all be used in the PSN-bound direction, and MUST be supported in the TDM-bound direction. The overlap functionality and AAL-CU timer and related functionalities may not be required, and the STF (start field) is NOT used. Computation of error detection codes -- namely, the Header Error Check (HEC) in the AAL2 PDU header and the CRC in the CAS packet -- is superfluous if an appropriate error detection mechanism is provided by the PSN. In such cases, these fields MAY be set to zero.
[AAL2、SSC、LES]中描述的所有机制均可用于TDMoIP。特别是，根据[AAL2]的信道标识符（CID）编码和PAD八位字节的使用、[SSCS]中定义的编码格式以及[LES]中描述的CAS和CCS信令传输都可以在PSN绑定方向上使用，并且必须在TDM绑定方向上得到支持。可能不需要重叠功能和AAL-CU定时器及相关功能，也不使用STF（启动字段）。如果PSN提供了适当的错误检测机制，则错误检测码的计算——即AAL2 PDU报头中的报头错误检查（HEC）和CAS数据包中的CRC——是多余的。在这种情况下，这些字段可以设置为零。
The motivation for handling HDLC in TDMoIP is to efficiently transport common channel signaling (CCS) such as SS7 [SS7] or ISDN PRI signaling [ISDN-PRI], embedded in the TDM stream. This mechanism is not intended for general HDLC payloads, and assumes that the HDLC messages are always shorter than the maximum packet size.
在TDMoIP中处理HDLC的动机是有效地传输公共信道信令（CCS），例如嵌入在TDM流中的SS7[SS7]或ISDN PRI信令[ISDN-PRI]。此机制不适用于一般HDLC有效负载，并假设HDLC消息始终小于最大数据包大小。
The HDLC mode should only be used when the majority of the bandwidth of the input HDLC stream is expected to be occupied by idle flags. Otherwise, the CCS channel should be treated as an ordinary channel.
只有当输入HDLC流的大部分带宽预计被空闲标志占用时，才应使用HDLC模式。否则，CCS信道应视为普通信道。
The HDLC format is intended to operate in port mode, transparently passing all HDLC data and control messages over a separate PW. The encapsulation is compatible with that of [RFC4618], however the sequence number generation and processing SHOULD be performed according to Section 3 above.
HDLC格式旨在以端口模式运行，通过单独的PW透明地传递所有HDLC数据和控制消息。封装与[RFC4618]兼容，但序列号的生成和处理应根据上述第3节进行。
The PSN-bound IWF monitors flags until a frame is detected. The contents of the frame are collected and the Frame Check Sequence (FCS) tested. If the FCS is incorrect, the frame is discarded; otherwise, the frame is sent after initial or final flags and FCS have been discarded and zero removal has been performed. When a TDMoIP-HDLC frame is received, its FCS is recalculated, and the original HDLC frame reconstituted.
绑定PSN的IWF监视标志，直到检测到帧。收集帧内容并测试帧检查序列（FCS）。如果FCS不正确，则丢弃该帧；否则，在丢弃初始或最终标志和FCS并执行零删除后发送帧。当接收到TDMoIP HDLC帧时，重新计算其FCS，并重构原始HDLC帧。
Native TDM networks signify network faults by carrying indications of forward defects (AIS) and reverse defects (RDI) in the TDM bit stream. Structure-agnostic TDM transport transparently carries all such indications; however, for structure-aware mechanisms where the PSN-bound IWF may remove TDM structure overhead carrying defect indications, explicit signaling of TDM defect conditions is required.
本机TDM网络通过在TDM比特流中携带正向缺陷（AIS）和反向缺陷（RDI）的指示来表示网络故障。结构不可知的TDM传输透明地携带所有这些指示；然而，对于PSN绑定的IWF可移除携带缺陷指示的TDM结构开销的结构感知机制，需要TDM缺陷条件的明确信令。
We saw in Section 3 that defects can be indicated by setting flags in the control word. This insertion of defect reporting into the packet rather than in a separate stream mimics the behavior of native TDM OAM mechanisms that carry such indications as bit patterns embedded in the TDM stream. The flags are designed to address the urgent messaging, i.e., messages whose contents must not be significantly delayed with respect to the TDM data that they potentially impact. Mechanisms for slow OAM messaging are discussed in Appendix D.
我们在第3节中看到，可以通过在控制字中设置标志来指示缺陷。这种将缺陷报告插入到包中而不是在单独的流中的做法模拟了本地TDM OAM机制的行为，该机制携带诸如嵌入TDM流中的位模式之类的指示。这些标志设计用于处理紧急消息，即其内容不得相对于可能影响的TDM数据显著延迟的消息。慢速OAM消息传递的机制在附录D中讨论。
+---+ +-----+ +------+ +-----+ +------+ +-----+ +---+
|TDM|->-| |->-|TDMoIP|->-| |->-|TDMoIP|->-| |->-|TDM|
| | |TDM 1| | | | PSN | | | |TDM 2| | |
|ES1|-<-| |-<-| IWF1 |-<-| |-<-| IWF2 |-<-| |-<-|ES2|
+---+ +-----+ +------+ +-----+ +------+ +-----+ +---+
+---+ +-----+ +------+ +-----+ +------+ +-----+ +---+
|TDM|->-| |->-|TDMoIP|->-| |->-|TDMoIP|->-| |->-|TDM|
| | |TDM 1| | | | PSN | | | |TDM 2| | |
|ES1|-<-| |-<-| IWF1 |-<-| |-<-| IWF2 |-<-| |-<-|ES2|
+---+ +-----+ +------+ +-----+ +------+ +-----+ +---+
Figure 9. Typical TDMoIP Network Configuration
图9。典型的TDMoIP网络配置
The operation of TDMoIP defect handling is best understood by considering the downstream TDM flow from TDM end system 1 (ES1) through TDM network 1, through TDMoIP IWF 1 (IWF1), through the PSN, through TDMoIP IWF 2 (IWF2), through TDM network 2, towards TDM end
通过考虑从TDM端系统1（ES1）、TDM网络1、TDMoIP IWF 1（IWF1）、PSN、TDMoIP IWF 2（IWF2）、TDM网络2到TDM端的下游TDM流，可以更好地理解TDMoIP缺陷处理的操作
system 2 (ES2), as depicted in the figure. We wish not only to detect defects in TDM network 1, the PSN, and TDM network 2, but to localize such defects in order to raise alarms only in the appropriate network.
系统2（ES2），如图所示。我们不仅希望检测TDM网络1、PSN和TDM网络2中的缺陷，而且希望定位此类缺陷，以便仅在适当的网络中发出警报。
In the "trail terminated" OAM scenario, only user data is exchanged between TDM network 1 and TDM network 2. The IWF functions as a TDM trail termination function, and defects detected in TDM network 1 are not relayed to network 2, or vice versa.
在“trail-terminated”OAM场景中，只有用户数据在TDM网络1和TDM网络2之间交换。IWF用作TDM跟踪终止功能，TDM网络1中检测到的缺陷不会中继到网络2，反之亦然。
In the "trail extended" OAM scenario, if there is a defect (e.g., loss of signal or loss of frame synchronization) anywhere in TDM network 1 before the ultimate link, the following TDM node will generate AIS downstream (towards TDMoIP IWF1). If a break occurs in the ultimate link, the IWF itself will detect the loss of signal. In either case, IWF1 having directly detected lack of validity of the TDM signal, or having been informed of an earlier problem, raises the local ("L") defect flag in the control word of the packets it sends across the PSN. In this way the trail is extended to TDM network 2 across the PSN.
在“跟踪扩展”OAM场景中，如果在最终链路之前TDM网络1中的任何位置存在缺陷（例如，信号丢失或帧同步丢失），则以下TDM节点将在下游（朝向TDMoIP IWF1）生成AIS。如果最终链路发生中断，IWF本身将检测到信号丢失。在任一情况下，已经直接检测到TDM信号的无效性的IWF1，或者已经被告知先前的问题的IWF1，在其通过PSN发送的分组的控制字中提升本地（“L”）缺陷标志。通过这种方式，该跟踪通过PSN扩展到TDM网络2。
Unlike forward defect indications that are generated by all network elements, reverse defect indications are only generated by trail termination functions. In the trail terminated scenario, IWF1 serves as a trail termination function for TDM network 1, and thus when IWF1 directly detects lack of validity of the TDM signal, or is informed of an earlier problem, it MAY generate TDM RDI towards TDM ES1. In the trail extended scenario IWF1 is not a trail termination, and hence MUST NOT generate TDM RDI, but rather, as we have seen, sets the L defect flag. As we shall see, this will cause the AIS indication to reach ES2, which is the trail termination, and which MAY generate TDM RDI.
与所有网元生成的正向缺陷指示不同，反向缺陷指示仅由跟踪终止功能生成。在跟踪终止场景中，IWF1用作TDM网络1的跟踪终止功能，因此，当IWF1直接检测到TDM信号的有效性不足，或被告知先前的问题时，它可能会向TDM ES1生成TDM RDI。在跟踪扩展场景中，IWF1不是跟踪终止，因此不能生成TDM RDI，而是如我们所见，设置L缺陷标志。正如我们将看到的，这将导致AIS指示到达ES2，这是跟踪终止，并可能产生TDM RDI。
When the L flag is set there are four possibilities for treatment of payload content. The default is for IWF1 to fill the payload with the appropriate amount of AIS (usually all-ones) data. If the AIS has been generated before the IWF this can be accomplished by copying the received TDM data; if the penultimate TDM link fails and the IWF needs to generate the AIS itself. Alternatively, with structure-aware transport of channelized TDM one SHOULD fill the payload with "trunk conditioning"; this involves placing a preconfigured "out of service" code in each individual channel (the "out of service" code may differ between voice and data channels). Trunk conditioning MUST be used when channels taken from several TDM PWs are combined by the TDM-bound IWF into a single TDM circuit. The third possibility is to suppress the payload altogether. Finally, if IWF1 believes that the TDM defect is minor or correctable (e.g., loss of multiframe synchronization, or initial phases of detection of incorrect frame
设置L标志时，有四种处理有效负载内容的可能性。默认情况下，IWF1使用适当数量的AIS（通常是所有AIS）数据填充有效负载。如果AIS是在IWF之前生成的，则可以通过复制接收到的TDM数据来实现；如果倒数第二个TDM链路出现故障，IWF需要自行生成AIS。或者，对于信道化TDM的结构感知传输，应使用“中继调节”填充有效载荷；这涉及在每个通道中放置预配置的“停止服务”代码（语音通道和数据通道之间的“停止服务”代码可能不同）。当来自多个TDM PW的信道由TDM绑定IWF组合到单个TDM电路中时，必须使用中继调节。第三种可能性是完全抑制有效载荷。最后，如果IWF1认为TDM缺陷较小或可纠正（例如，多帧同步丢失，或检测不正确帧的初始阶段
sync), it MAY place the TDM data it has received into the payload field, and specify in the defect modification field ("M") that the TDM data is corrupted, but potentially recoverable.
同步），它可以将接收到的TDM数据放入有效载荷字段，并在缺陷修改字段（“M”）中指定TDM数据已损坏，但可能可恢复。
When IWF2 receives a local defect indication without M field modification, it forwards (or generates if the payload has been suppressed) AIS or trunk conditioning towards ES2 (the choice between AIS and conditioning being preconfigured). Thus AIS has been properly delivered to ES2 emulating the TDM scenario from the TDM end system's point of view. In addition, IWF2 receiving the L flag uniquely specifies that the defect was in TDM network 1 and not in TDM network 2, thus suppressing alarms in the correctly functioning network.
当IWF2接收到没有M字段修改的局部缺陷指示时，它向ES2转发（或在有效负载被抑制的情况下生成）AIS或中继条件（AIS和预配置条件之间的选择）。因此，从TDM终端系统的角度来看，AIS已经正确地交付给ES2，模拟TDM场景。此外，接收L标志的IWF2唯一指定缺陷在TDM网络1中，而不是在TDM网络2中，从而抑制正常运行网络中的报警。
If the M field indicates that the TDM has been marked as potentially recoverable, then implementation specific algorithms (not herein specified) may optionally be utilized to minimize the impact of transient defects on the overall network performance. If the M field indicates that the TDM is "idle", no alarms should be raised and IWF2 treats the payload contents as regular TDM data. If the payload has been suppressed, trunk conditioning and not AIS MUST be generated by IWF2.
如果M字段指示TDM已被标记为潜在可恢复的，则可任选地使用特定于实现的算法（本文未指定）来最小化瞬态缺陷对整体网络性能的影响。如果M字段指示TDM为“空闲”，则不应发出警报，IWF2将有效负载内容视为常规TDM数据。如果有效载荷已被抑制，则必须由IWF2生成行李箱调节而非AIS。
The second case is when the defect is in TDM network 2. Such defects cause AIS generation towards ES2, which may respond by sending TDM RDI in the reverse direction. In the trail terminated scenario this RDI is restricted to network 2. In the trail extended scenario, IWF2 upon observing this RDI inserted into valid TDM data, MUST indicate this by setting the "R" flag in packets sent back across the PSN towards IWF1. IWF1, upon receiving this indication, generates RDI towards ES1, thus emulating a single conventional TDM network.
第二种情况是，缺陷位于TDM网络2中。此类缺陷导致AIS向ES2生成，ES2可能通过反向发送TDM RDI进行响应。在跟踪终止场景中，此RDI仅限于网络2。在跟踪扩展场景中，IWF2在观察到该RDI插入有效TDM数据时，必须通过在通过PSN发送回IWF1的数据包中设置“R”标志来指示这一点。IWF1在接收到该指示后，向ES1生成RDI，从而模拟单个传统TDM网络。
The final possibility is that of a unidirectional defect in the PSN. In such a case, TDMoIP IWF1 sends packets toward IWF2, but these are not received. IWF2 MUST inform the PSN's management system of this problem, and furthermore generate TDM AIS towards ES2. ES2 may respond with TDM RDI, and as before, in the trail extended scenario, when IWF2 detects RDI it MUST raise the "R" flag indication. When IWF1 receives packets with the "R" flag set it has been informed of a reverse defect, and MUST generate TDM RDI towards ES1.
最后一种可能性是PSN中存在单向缺陷。在这种情况下，TDMoIP IWF1向IWF2发送数据包，但不接收这些数据包。IWF2必须将此问题通知PSN的管理系统，并进一步生成针对ES2的TDM AIS。ES2可以使用TDM RDI进行响应，与之前一样，在跟踪扩展场景中，当IWF2检测到RDI时，它必须提升“R”标志指示。当IWF1接收到设置了“R”标志的数据包时，它已被告知存在反向缺陷，并且必须向ES1生成TDM RDI。
In all cases, if any of the above defects persist for a preconfigured period (default value of 2.5 seconds) a service failure is declared. Since TDM PWs are inherently bidirectional, a persistent defect in either directional results in a bidirectional service failure. In addition, if signaling is sent over a distinct PW as per Section 5.3, both PWs are considered to have failed when persistent defects are detected in either.
在所有情况下，如果上述任何缺陷持续预配置的时间（默认值为2.5秒），则宣布服务失败。由于TDM PW本质上是双向的，因此任一方向上的持续缺陷都会导致双向服务故障。此外，如果根据第5.3节通过不同的PW发送信号，则当检测到两个PW中的持续缺陷时，两个PW均被视为失败。
When failure is declared the PW MUST be withdrawn, and both TDMoIP IWFs commence sending AIS (and not trunk conditioning) to their respective TDM networks. The IWFs then engage in connectivity testing using native methods or TDMoIP OAM as described in Appendix D until connectivity is restored.
当宣布故障时，必须撤回PW，两个TDMoIP IWF开始向各自的TDM网络发送AIS（而不是中继调节）。然后，IWF使用本机方法或TDMoIP OAM进行连接测试，如附录D所述，直到连接恢复。
General requirements for transport of TDM over pseudo-wires are detailed in [RFC4197]. In the following subsections we review additional aspects essential to successful TDMoIP implementation.
[RFC4197]中详细说明了通过伪线传输TDM的一般要求。在以下小节中，我们将回顾成功实施TDMoIP所必需的其他方面。
In order to compensate for packet delay variation that exists in any PSN, a jitter buffer MUST be provided. A jitter buffer is a block of memory into which the data from the PSN is written at its variable arrival rate, and data is read out and sent to the destination TDM equipment at a constant rate. Use of a jitter buffer partially hides the fact that a PSN has been traversed rather than a conventional synchronous TDM network, except for the additional latency. Customary practice is to operate with the jitter buffer approximately half full, thus minimizing the probability of its overflow or underflow. Hence, the additional delay equals half the jitter buffer size. The length of the jitter buffer SHOULD be configurable and MAY be dynamic (i.e., grow and shrink in length according to the statistics of the Packet Delay Variation (PDV)).
为了补偿任何PSN中存在的数据包延迟变化，必须提供抖动缓冲器。抖动缓冲器是一块存储器，PSN的数据以其可变到达率写入其中，数据以恒定速率读出并发送到目标TDM设备。抖动缓冲区的使用部分隐藏了这样一个事实：除了额外的延迟外，PSN已经被穿越，而不是传统的同步TDM网络。习惯做法是在抖动缓冲区大约半满的情况下运行，从而将其溢出或下溢的可能性降至最低。因此，额外的延迟等于抖动缓冲区大小的一半。抖动缓冲器的长度应该是可配置的，并且可以是动态的（即，根据分组延迟变化（PDV）的统计数据在长度上增长和收缩）。
In order to handle (infrequent) packet loss and misordering, a packet sequence integrity mechanism MUST be provided. This mechanism MUST track the serial numbers of arriving packets and MUST take appropriate action when anomalies are detected. When lost packet(s) are detected, the mechanism MUST output filler data in order to retain TDM timing. Packets arriving in incorrect order SHOULD be reordered. Lost packet processing SHOULD ensure that proper FAS is sent to the TDM network. An example sequence number processing algorithm is provided in Appendix A.
为了处理（罕见的）数据包丢失和错误排序，必须提供数据包序列完整性机制。该机制必须跟踪到达数据包的序列号，并且在检测到异常时必须采取适当的措施。当检测到丢失的数据包时，该机制必须输出填充数据以保持TDM定时。以错误顺序到达的数据包应重新排序。丢失数据包处理应确保向TDM网络发送正确的FAS。附录A中提供了一个序列号处理算法示例。
While the insertion of arbitrary filler data may be sufficient to maintain the TDM timing, for telephony traffic it may lead to audio gaps or artifacts that result in choppy, annoying or even unintelligible audio. An implementation MAY blindly insert a preconfigured constant value in place of any lost samples, and this value SHOULD be chosen to minimize the perceptual effect. Alternatively one MAY replay the previously received packet. When computational resources are available, implementations SHOULD conceal the packet loss event by properly estimating missing sample values in such fashion as to minimize the perceptual error.
尽管插入任意填充数据可能足以维持TDM定时，但对于电话业务而言，它可能导致音频间隙或伪影，从而导致杂音、烦人甚至不可理解的音频。一个实现可能会盲目地插入一个预配置的常量值来代替任何丢失的样本，并且应该选择该值以最小化感知效果。或者，可以重播先前接收的分组。当计算资源可用时，实现应该通过以最小化感知错误的方式正确估计丢失的样本值来隐藏丢包事件。
TDM networks are inherently synchronous; somewhere in the network there will always be at least one extremely accurate primary reference clock, with long-term accuracy of one part in 1E-11. This node provides reference timing to secondary nodes with somewhat lower accuracy, and these in turn distribute timing information further. This hierarchy of time synchronization is essential for the proper functioning of the network as a whole; for details see [G823][G824].
TDM网络本质上是同步的；在网络中的某个地方，总有至少一个极其精确的主参考时钟，长期精度为1E-11中的一个部分。该节点以较低的精度向次节点提供参考定时，而次节点又进一步分发定时信息。这种时间同步层次对于整个网络的正常运行至关重要；详情请参阅[G823][G824]。
Packets in PSNs reach their destination with delay that has a random component, known as packet delay variation (PDV). When emulating TDM on a PSN, extracting data from the jitter buffer at a constant rate overcomes much of the high frequency component of this randomness ("jitter"). The rate at which we extract data from the jitter buffer is determined by the destination clock, and were this to be precisely matched to the source clock proper timing would be maintained. Unfortunately, the source clock information is not disseminated through a PSN, and the destination clock frequency will only nominally equal the source clock frequency, leading to low frequency ("wander") timing inaccuracies.
PSN中的数据包到达目的地的延迟具有随机成分，称为数据包延迟变化（PDV）。在PSN上模拟TDM时，以恒定速率从抖动缓冲区提取数据可以克服这种随机性的大部分高频成分（“抖动”）。我们从抖动缓冲区提取数据的速率由目标时钟决定，如果目标时钟与源时钟精确匹配，将保持适当的定时。不幸的是，源时钟信息没有通过PSN传播，并且目标时钟频率将仅名义上等于源时钟频率，从而导致低频（“漂移”）定时不准确。
In broadest terms, there are four methods of overcoming this difficulty. In the first and second methods timing information is provided by some means independent of the PSN. This timing may be provided to the TDM end systems (method 1) or to the IWFs (method 2). In a third method, a common clock is assumed available to both IWFs, and the relationship between the TDM source clock and this clock is encoded in the packet. This encoding may take the form of RTP timestamps or may utilize the synchronous residual timestamp (SRTS) bits in the AAL1 overhead. In the final method (adaptive clock recovery) the timing must be deduced solely based on the packet arrival times. Example scenarios are detailed in [RFC4197] and in [Y1413].
广义地说，有四种方法可以克服这一困难。在第一和第二方法中，通过一些独立于PSN的方式提供定时信息。该定时可以提供给TDM终端系统（方法1）或IWFs（方法2）。在第三种方法中，假设公共时钟对两个iwf都可用，并且TDM源时钟和该时钟之间的关系被编码在分组中。该编码可以采取RTP时间戳的形式，或者可以利用AAL1开销中的同步剩余时间戳（SRTS）比特。在最后一种方法（自适应时钟恢复）中，必须仅根据数据包到达时间推断定时。[RFC4197]和[Y1413]中详细介绍了示例场景。
Adaptive clock recovery utilizes only observable characteristics of the packets arriving from the PSN, such as the precise time of arrival of the packet at the TDM-bound IWF, or the fill-level of the jitter buffer as a function of time. Due to the packet delay variation in the PSN, filtering processes that combat the statistical nature of the observable characteristics must be employed. Frequency Locked Loops (FLL) and Phase Locked Loops (PLL) are well suited for this task.
自适应时钟恢复仅利用从PSN到达的分组的可观察特性，例如分组到达TDM绑定IWF的精确时间，或者抖动缓冲器的填充水平作为时间的函数。由于PSN中的数据包延迟变化，必须采用与可观测特性的统计特性相对抗的过滤过程。频率锁定环路（FLL）和相位锁定环路（PLL）非常适合此任务。
Whatever timing recovery mechanism is employed, the output of the TDM-bound IWF MUST conform to the jitter and wander specifications of TDM traffic interfaces, as defined in [G823][G824]. For some applications, more stringent jitter and wander tolerances MAY be imposed.
无论采用何种定时恢复机制，TDM绑定IWF的输出必须符合[G823][G824]中定义的TDM业务接口的抖动和漂移规范。对于某些应用，可能会施加更严格的抖动和漂移公差。
As explained in [RFC3985], the underlying PSN may be subject to congestion. Unless appropriate precautions are taken, undiminished demand of bandwidth by TDMoIP can contribute to network congestion that may impact network control protocols.
如[RFC3985]所述，基础PSN可能会出现拥塞。除非采取适当的预防措施，否则TDMoIP对带宽的需求不减可能导致网络拥塞，从而影响网络控制协议。
The AAL1 mode of TDMoIP is an inelastic constant bit-rate (CBR) flow and cannot respond to congestion in a TCP-friendly manner prescribed by [RFC2914], although the percentage of total bandwidth they consume remains constant. The AAL2 mode of TDMoIP is variable bit-rate (VBR), and it is often possible to reduce the bandwidth consumed by employing mechanisms that are beyond the scope of this document.
TDMoIP的AAL1模式是非弹性恒定比特率（CBR）流，不能以[RFC2914]规定的TCP友好方式响应拥塞，尽管它们消耗的总带宽百分比保持不变。TDMoIP的AAL2模式是可变比特率（VBR），通常可以通过采用超出本文档范围的机制来减少带宽消耗。
Whenever possible, TDMoIP SHOULD be carried across traffic-engineered PSNs that provide either bandwidth reservation and admission control or forwarding prioritization and boundary traffic conditioning mechanisms. IntServ-enabled domains supporting Guaranteed Service (GS) [RFC2212] and Diffserv-enabled domains [RFC2475] supporting Expedited Forwarding (EF) [RFC3246] provide examples of such PSNs. Such mechanisms will negate, to some degree, the effect of TDMoIP on neighboring streams. In order to facilitate boundary traffic conditioning of TDMoIP traffic over IP PSNs, the TDMoIP packets SHOULD NOT use the Diffserv Code Point (DSCP) value reserved for the Default Per-Hop Behavior (PHB) [RFC2474].
只要有可能，TDMoIP应跨提供带宽预留和准入控制或转发优先级和边界流量调节机制的流量工程PSN进行。支持保证服务（GS）[RFC2212]的支持IntServ的域[RFC2475]和支持快速转发（EF）[RFC3246]的支持区分服务的域[RFC2475]提供了此类PSN的示例。这种机制将在某种程度上抵消TDMoIP对相邻流的影响。为了促进IP PSN上TDMoIP流量的边界流量调节，TDMoIP数据包不应使用为默认每跳行为（PHB）保留的Diffserv码点（DSCP）值[RFC2474]。
When TDMoIP is run over a PSN providing best-effort service, packet loss SHOULD be monitored in order to detect congestion. If congestion is detected and bandwidth reduction is possible, then such reduction SHOULD be enacted. If bandwidth reduction is not possible, then the TDMoIP PW SHOULD shut down bi-directionally for some period of time as described in Section 6.5 of [RFC3985].
当TDMoIP在提供尽力而为服务的PSN上运行时，应监控数据包丢失以检测拥塞。如果检测到拥塞并且带宽减少是可能的，那么应该实施这种减少。如果无法降低带宽，则TDMoIP PW应双向关闭一段时间，如[RFC3985]第6.5节所述。
Note that:
请注意：
1. In AAL1 mode TDMoIP can inherently provide packet loss measurement since the expected rate of packet arrival is fixed and known.
1. 在AAL1模式下，TDMoIP固有地提供分组丢失测量，因为分组到达的预期速率是固定的和已知的。
2. The results of the packet loss measurement may not be a reliable indication of presence or absence of severe congestion if the PSN provides enhanced delivery. For example, if TDMoIP traffic takes precedence over other traffic, severe congestion may not significantly affect TDMoIP packet loss.
2. 如果PSN提供增强的传送，则分组丢失测量的结果可能不是存在或不存在严重拥塞的可靠指示。例如，如果TDMoIP流量优先于其他流量，严重拥塞可能不会显著影响TDMoIP数据包丢失。
3. The TDM services emulated by TDMoIP have high availability objectives (see [G826]) that MUST be taken into account when deciding on temporary shutdown.
3. TDMoIP模拟的TDM服务具有高可用性目标（见[G826]），在决定临时关闭时必须将其考虑在内。
This specification does not define exact criteria for detecting severe congestion or specific methods for TDMoIP shutdown or subsequent re-start. However, the following considerations may be used as guidelines for implementing the shutdown mechanism:
本规范未定义检测严重拥堵的准确标准或TDMoIP关闭或随后重新启动的具体方法。但是，以下注意事项可用作实施停机机制的指南：
1. If the TDMoIP PW has been set up using the PWE3 control protocol [RFC4447], the regular PW teardown procedures of these protocols SHOULD be used.
1. 如果已使用PWE3控制协议[RFC4447]设置TDMoIP PW，则应使用这些协议的常规PW拆卸程序。
2. If one of the TDMoIP IWFs stops transmission of packets for a sufficiently long period, its peer (observing 100% packet loss) will necessarily detect "severe congestion" and also stop transmission, thus achieving bi-directional PW shutdown.
2. 如果其中一个TDMoIP IWF在足够长的时间内停止数据包的传输，则其对等方（观察到100%的数据包丢失）将必然检测到“严重拥塞”并停止传输，从而实现双向PW关闭。
TDMoIP does not provide mechanisms to ensure timely delivery or provide other quality-of-service guarantees; hence it is required that the lower-layer services do so. Layer 2 priority can be bestowed upon a TDMoIP stream by using the VLAN priority field, MPLS priority can be provided by using EXP bits, and layer 3 priority is controllable by using TOS. Switches and routers which the TDMoIP stream must traverse should be configured to respect these priorities.
TDMoIP未提供确保及时交付或提供其他服务质量保证的机制；因此，需要较低层的服务这样做。第2层优先级可以通过使用VLAN优先级字段赋予TDMoIP流，MPLS优先级可以通过使用EXP位提供，第3层优先级可以通过使用TOS进行控制。TDMoIP流必须穿越的交换机和路由器应配置为尊重这些优先级。
TDMoIP does not enhance or detract from the security performance of the underlying PSN, rather it relies upon the PSN's mechanisms for encryption, integrity, and authentication whenever required. The level of security provided may be less than that of a native TDM service.
TDMoIP不会增强或降低基础PSN的安全性能，而是在需要时依赖PSN的加密、完整性和身份验证机制。提供的安全级别可能低于本机TDM服务的安全级别。
When the PSN is MPLS, PW-specific security mechanisms MAY be required, while for IP-based PSNs, IPsec [RFC4301] MAY be used. TDMoIP using L2TPv3 is subject to the security considerations discussed in Section 8 of [RFC3931].
当PSN是MPLS时，可能需要特定于PW的安全机制，而对于基于IP的PSN，可能使用IPsec[RFC4301]。使用L2TPv3的TDMoIP应遵守[RFC3931]第8节中讨论的安全注意事项。
TDMoIP shares susceptibility to a number of pseudowire-layer attacks (see [RFC3985]) and implementations SHOULD use whatever mechanisms for confidentiality, integrity, and authentication are developed for general PWs. These methods are beyond the scope of this document.
TDMoIP易受多种伪线层攻击（请参见[RFC3985]），实现应使用为通用PWs开发的保密性、完整性和身份验证机制。这些方法超出了本文件的范围。
Random initialization of sequence numbers, in both the control word and the optional RTP header, makes known-plaintext attacks on encrypted TDMoIP more difficult. Encryption of PWs is beyond the scope of this document.
控制字和可选RTP报头中序列号的随机初始化使得对加密TDMoIP的已知明文攻击更加困难。PWs的加密超出了本文件的范围。
PW labels SHOULD be selected in an unpredictable manner rather than sequentially or otherwise in order to deter session hijacking. When using L2TPv3, a cryptographically random [RFC4086] Cookie SHOULD be used to protect against off-path packet insertion attacks, and a 64- bit Cookie is RECOMMENDED for protection against brute-force, blind, insertion attacks.
PW标签应以不可预测的方式选择，而不是按顺序或以其他方式选择，以阻止会话劫持。当使用L2TPv3时，应使用加密随机[RFC4086]Cookie来防止路径外数据包插入攻击，建议使用64位Cookie来防止暴力、盲插入攻击。
Although TDMoIP MAY employ an RTP header when explicit transfer of timing information is required, SRTP (see [RFC3711]) mechanisms are not applicable.
尽管TDMoIP在需要显式传输定时信息时可采用RTP报头，但SRTP（参见[RFC3711]）机制不适用。
For MPLS PSNs, PW Types for TDMoIP PWs are allocated in [RFC4446].
对于MPLS PSN，TDMoIP PW的PW类型在[RFC4446]中分配。
For UDP/IP PSNs, when the source port is used as PW label, the destination port number MUST be set to 0x085E (2142), the user port number assigned by IANA to TDMoIP.
对于UDP/IP PSN，当源端口用作PW标签时，目标端口号必须设置为0x085E（2142），即IANA分配给TDMoIP的用户端口号。
It must be recognized that the emulation provided by TDMoIP may be imperfect, and the service may differ from the native TDM circuit in the following ways.
必须认识到，TDMoIP提供的仿真可能不完善，并且该服务可能在以下方面不同于本机TDM电路。
The end-to-end delay of a TDM circuit emulated using TDMoIP may exceed that of a native TDM circuit.
使用TDMoIP仿真的TDM电路的端到端延迟可能超过本机TDM电路的端到端延迟。
When using adaptive clock recovery, the timing performance of the emulated TDM circuit depends on characteristics of the PSN, and thus may be inferior to that of a native TDM circuit.
当使用自适应时钟恢复时，仿真TDM电路的定时性能取决于PSN的特性，因此可能低于本机TDM电路的定时性能。
If the TDM structure overhead is not transported over the PSN, then non-FAS data in the overhead will be lost.
如果TDM结构开销未通过PSN传输，则开销中的非FAS数据将丢失。
When packets are lost in the PSN, TDMoIP mechanisms ensure that frame synchronization will be maintained. When packet loss events are properly concealed, the effect on telephony channels will be perceptually minimized. However, the bit error rate will be degraded as compared to the native service.
当数据包在PSN中丢失时，TDMoIP机制确保帧同步将得以保持。当包丢失事件被适当地隐藏时，对电话信道的影响将被感知地最小化。但是，与本机服务相比，误码率将降低。
Data in inactive channels is not transported in AAL2 mode, and thus this data will differ from that of the native service.
非活动通道中的数据不会以AAL2模式传输，因此此数据将不同于本机服务的数据。
Native TDM connections are point-to-point, while PSNs are shared infrastructures. Hence, the level of security of the emulated service may be less than that of the native service.
本机TDM连接是点对点连接，而PSN是共享基础设施。因此，模拟服务的安全级别可能低于本机服务的安全级别。
The authors would like to thank Hugo Silberman, Shimon HaLevy, Tuvia Segal, and Eitan Schwartz of RAD Data Communications for their invaluable contributions to the technology described herein.
作者要感谢RAD数据通信公司的Hugo Silberman、Shimon HaLevy、Tuvia Segal和Eitan Schwartz对本文所述技术的宝贵贡献。
Appendix A. Sequence Number Processing (Informative)
附录A.序列号处理（资料性）
The sequence number field in the control word enables detection of lost and misordered packets. Here we give pseudocode for an example algorithm in order to clarify the issues involved. These issues are implementation specific and no single explanation can capture all the possibilities.
控制字中的序列号字段可以检测丢失和错误排列的数据包。在这里，我们给出了一个示例算法的伪代码，以澄清所涉及的问题。这些问题是特定于实现的，没有任何一种解释能够抓住所有的可能性。
In order to simplify the description, modulo arithmetic is consistently used in lieu of ad-hoc treatment of the cyclicity. All differences between indexes are explicitly converted to the range [-2^15 ... +2^15 - 1] to ensure that simple checking of the difference's sign correctly predicts the packet arrival order.
为了简化描述，通常使用模运算来代替周期性的特殊处理。索引之间的所有差异都显式转换为范围[-2^15…+2^15-1]，以确保对差异符号的简单检查能够正确预测数据包到达顺序。
Furthermore, we introduce the notion of a playout buffer in order to unambiguously define packet lateness. When a packet arrives after previously having been assumed lost, the TDM-bound IWF may discard it, and continue to treat it as lost. Alternatively, if the filler data that had been inserted in its place has not yet been played out, the option remains to insert the true data into the playout buffer. Of course, the filler data may be generated upon initial detection of a missing packet or upon playout. This description is stated in terms of a packet-oriented playout buffer rather than a TDM byte oriented one; however, this is not a true requirement for re-ordering implementations since the latter could be used along with pointers to packet commencement points.
此外，为了明确定义数据包延迟，我们引入了播放缓冲区的概念。当数据包在先前假定丢失后到达时，TDM绑定的IWF可以丢弃它，并继续将其视为丢失。或者，如果插入到其位置的填充数据尚未播放，则仍可以选择将真实数据插入播放缓冲区。当然，填充数据可以在初始检测到丢失的分组或播放时生成。该描述是根据面向分组的播放缓冲区而不是面向TDM字节的缓冲区来描述的；然而，这不是重新排序实现的真正要求，因为后者可以与指向数据包起始点的指针一起使用。
Having introduced the playout buffer we explicitly treat over-run and under-run of this buffer. Over-run occurs when packets arrive so quickly that they can not be stored for playout. This is usually an indication of gross timing inaccuracy or misconfiguration, and we can do little but discard such early packets. Under-run is usually a sign of network starvation, resulting from congestion or network failure.
引入播放缓冲区后，我们显式地处理该缓冲区的过度运行和不足运行。当数据包到达得太快以至于无法存储以供播放时，就会发生溢出。这通常表示严重的定时不准确性或配置错误，我们只能丢弃这些早期数据包。运行不足通常是由于拥塞或网络故障导致的网络饥饿的迹象。
The external variables used by the pseudocode are:
伪代码使用的外部变量为：
received: sequence number of packet received played: sequence number of the packet being played out (Note 1) over-run: is the playout buffer full? (Note 3) under-run: has the playout buffer been exhausted? (Note 3)
接收：接收到的数据包序列号播放：正在播放的数据包序列号（注1）在运行期间：播放缓冲区是否已满？（注3）运行不足：播放缓冲区是否已耗尽？（注3）
The internal variables used by the pseudocode are:
伪代码使用的内部变量为：
expected: sequence number we expect to receive next D: difference between expected and received (Note 2) L: difference between sequence numbers of packet being played out and that just received (Notes 1 and 2)
预期：我们预期下一次接收的序列号D：预期和接收之间的差异（注2）L：正在播放的数据包序列号和刚刚接收的数据包序列号之间的差异（注1和2）
In addition, the algorithm requires one parameter:
此外，该算法需要一个参数：
R: maximum lateness for a packet to be recoverable (Note 1).
R：数据包可恢复的最大延迟时间（注1）。
Note 1: this is only required for the optional re-ordering
Note 2: this number is always in the range -2^15 ... +2^15 - 1
Note 3: the playout buffer is emptied by the TDM playout process,
which runs asynchronously to the packet arrival processing,
and which is not herein specified
Note 1: this is only required for the optional re-ordering
Note 2: this number is always in the range -2^15 ... +2^15 - 1
Note 3: the playout buffer is emptied by the TDM playout process,
which runs asynchronously to the packet arrival processing,
and which is not herein specified
Sequence Number Processing Algorithm
序列号处理算法
Upon receipt of a packet
if received = expected
{ treat packet as in-order }
if not over-run then
place packet contents into playout buffer
else
discard packet contents
set expected = (received + 1) mod 2^16
else
calculate D = ( (expected-received) mod 2^16 ) - 2^15
if D > 0 then
{ packets expected, expected+1, ... received-1 are lost }
while not over-run
place filler (all-ones or interpolation) into playout buffer
if not over-run then
place packet contents into playout buffer
else
discard packet contents
set expected = (received + 1) mod 2^16
else { late packet arrived }
declare "received" to be a late packet
do NOT update "expected"
either
discard packet
or
if not under-run then
calculate L = ( (played-received) mod 2^16 ) - 2^15
if 0 < L <= R then
replace data from packet previously marked as lost
else
discard packet
Note: by choosing R=0 we always discard the late packet
Upon receipt of a packet
if received = expected
{ treat packet as in-order }
if not over-run then
place packet contents into playout buffer
else
discard packet contents
set expected = (received + 1) mod 2^16
else
calculate D = ( (expected-received) mod 2^16 ) - 2^15
if D > 0 then
{ packets expected, expected+1, ... received-1 are lost }
while not over-run
place filler (all-ones or interpolation) into playout buffer
if not over-run then
place packet contents into playout buffer
else
discard packet contents
set expected = (received + 1) mod 2^16
else { late packet arrived }
declare "received" to be a late packet
do NOT update "expected"
either
discard packet
or
if not under-run then
calculate L = ( (played-received) mod 2^16 ) - 2^15
if 0 < L <= R then
replace data from packet previously marked as lost
else
discard packet
Note: by choosing R=0 we always discard the late packet
Appendix B. AAL1 Review (Informative)
附录B.AAL1审查（资料性）
The first byte of the 48-byte AAL1 PDU always contains an error-protected 3-bit sequence number.
48字节AAL1 PDU的第一个字节始终包含错误保护的3位序列号。
1 2 3 4 5 6 7 8
+-+-+-+-+-+-+-+-+-----------------------
|C| SN | CRC |P| 47 bytes of payload
+-+-+-+-+-+-+-+-+-----------------------
1 2 3 4 5 6 7 8
+-+-+-+-+-+-+-+-+-----------------------
|C| SN | CRC |P| 47 bytes of payload
+-+-+-+-+-+-+-+-+-----------------------
C (1 bit) convergence sublayer indication, its use here is limited to indication of the existence of a pointer (see below); C=0 means no pointer, C=1 means a pointer is present.
C（1位）收敛子层指示，其在此处的使用仅限于指示存在指针（见下文）；C=0表示没有指针，C=1表示存在指针。
SN (3 bits) The AAL1 sequence number increments from PDU to PDU.
SN（3位）AAL1序列号从PDU到PDU递增。
CRC (3 bits) is a 3-bit error cyclic redundancy code on C and SN.
CRC（3位）是C和SN上的3位错误循环冗余码。
P (1 bit) even byte parity.
P（1位）偶数字节奇偶校验。
As can be readily inferred, incrementing the sequence number forms an eight-PDU sequence number cycle, the importance of which will become clear shortly.
可以很容易地推断，增加序列号形成一个8个PDU序列号循环，其重要性很快就会清楚。
The structure of the remaining 47 bytes in the AAL1 PDU depends on the PDU type, of which there are three, corresponding to the three types of AAL1 circuit emulation service defined in [CES]. These are known as unstructured circuit emulation, structured circuit emulation, and structured circuit emulation with CAS.
AAL1 PDU中剩余47个字节的结构取决于PDU类型，其中有三个，对应于[CES]中定义的三种AAL1电路仿真服务。这些被称为非结构化电路仿真、结构化电路仿真和使用CAS的结构化电路仿真。
The simplest PDU is the unstructured one, which is used for transparent transfer of whole circuits (T1,E1,T3,E3). Although AAL1 provides no inherent advantage as compared to SAToP for unstructured transport, in certain cases AAL1 may be required or desirable. For example, when it is necessary to interwork with an existing AAL1- based network, or when clock recovery based on AAL1-specific mechanisms is favored.
最简单的PDU是非结构化PDU，用于整个电路（T1、E1、T3、E3）的透明传输。尽管与非结构化传输的SAToP相比，AAL1没有提供任何固有优势，但在某些情况下，AAL1可能是必需的或可取的。例如，当需要与现有的基于AAL1的网络互通时，或者当基于AAL1特定机制的时钟恢复受到青睐时。
For unstructured AAL1, the 47 bytes after the sequence number byte contain the full 376 bits from the TDM bit stream. No frame synchronization is supplied or implied, and framing is the sole responsibility of the end-user equipment. Hence, the unstructured mode can be used to carry data, and for circuits with nonstandard frame synchronization. For the T1 case the raw frame consists of 193 bits, and hence 1 183/193 T1 frames fit into each AAL1 PDU. The E1 frame consists of 256 bits, and so 1 15/32 E1 frames fit into each PDU.
对于非结构化AAL1，序列号字节后的47个字节包含TDM位流中的全部376位。没有提供或暗示帧同步，并且帧是最终用户设备的唯一责任。因此，非结构化模式可用于传输数据，也可用于具有非标准帧同步的电路。对于T1情况，原始帧由193位组成，因此每个AAL1 PDU中适合1 183/193 T1帧。E1帧由256位组成，因此每个PDU适合1个15/32 E1帧。
When the TDM circuit is channelized according to [G704], and in particular when it is desired to fractional E1 or T1, it is advantageous to use one of the structured AAL1 circuit emulation services. Structured AAL1 views the data not merely as a bit stream, but as a bundle of channels. Furthermore, when CAS signaling is used it can be formatted so that it can be readily detected and manipulated.
当根据[G704]对TDM电路进行信道化时，特别是当需要分数E1或T1时，使用结构化AAL1电路仿真服务之一是有利的。结构化AAL1不仅将数据视为比特流，还将其视为一组通道。此外，当使用CAS信令时，可以对其进行格式化，以便易于检测和操作。
In the structured circuit emulation mode without CAS, N bytes from the N channels to be transported are first arranged in order of channel number. Thus if channels 2, 3, 5, 7 and 11 are to be transported, the corresponding five bytes are placed in the PDU immediately after the sequence number byte. This placement is repeated until all 47 bytes in the PDU are filled.
在无CAS的结构化电路仿真模式中，要传输的N个通道中的N个字节首先按照通道数的顺序排列。因此，如果要传输通道2、3、5、7和11，则相应的五个字节将立即放置在序列号字节之后的PDU中。重复此放置，直到PDU中的所有47个字节都已填满。
byte 1 2 3 4 5 6 7 8 9 10 --- 41 42 43 44 45 46 47
channel 2 3 5 7 11 2 3 5 7 11 --- 2 3 5 7 11 2 3
byte 1 2 3 4 5 6 7 8 9 10 --- 41 42 43 44 45 46 47
channel 2 3 5 7 11 2 3 5 7 11 --- 2 3 5 7 11 2 3
The next PDU commences where the present PDU left off.
下一个PDU从当前PDU停止的位置开始。
byte 1 2 3 4 5 6 7 8 9 10 --- 41 42 43 44 45 46 47
channel 5 7 11 2 3 5 7 11 2 3 --- 5 7 11 2 3 5 7
byte 1 2 3 4 5 6 7 8 9 10 --- 41 42 43 44 45 46 47
channel 5 7 11 2 3 5 7 11 2 3 --- 5 7 11 2 3 5 7
And so forth. The set of channels 2,3,5,7,11 is the basic structure and the point where one structure ends and the next commences is the structure boundary.
等等通道2、3、5、7、11是基本结构，一个结构结束和下一个结构开始的点是结构边界。
The problem with this arrangement is the lack of explicit indication of the byte identities. As can be seen in the above example, each AAL1 PDU starts with a different channel, so a single lost packet will result in misidentifying channels from that point onwards, without possibility of recovery. The solution to this deficiency is the periodic introduction of a pointer to the next structure boundary. This pointer need not be used too frequently, as the channel identifications are uniquely inferable unless packets are lost.
这种安排的问题是缺少字节标识的明确指示。从上述示例中可以看出，每个AAL1 PDU从不同的信道开始，因此单个丢失的数据包将导致从该点开始错误识别信道，而不可能恢复。解决这一缺陷的办法是定期引入指向下一个结构边界的指针。该指针不需要太频繁地使用，因为除非数据包丢失，否则信道标识是唯一可推断的。
The particular method used in AAL1 is to insert a pointer once every sequence number cycle of eight PDUs. The pointer is seven bits and protected by an even parity MSB (most significant bit), and so occupies a single byte. Since seven bits are sufficient to represent offsets larger than 47, we can limit the placement of the pointer byte to PDUs with even sequence numbers. Unlike most AAL1 PDUs that contain 47 TDM bytes, PDUs that contain a pointer (P-format PDUs) have the following format.
AAL1中使用的特定方法是在八个PDU的每个序列号周期插入一个指针。指针为七位，受偶校验MSB（最高有效位）保护，因此占用一个字节。由于7位足以表示大于47的偏移量，我们可以将指针字节的位置限制为偶数序列号的PDU。与大多数包含47个TDM字节的AAL1 PDU不同，包含指针的PDU（P格式PDU）具有以下格式。
0 1
1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-----------------------
|C| SN | CRC |P|E| pointer | 46 bytes of payload
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-----------------------
0 1
1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-----------------------
|C| SN | CRC |P|E| pointer | 46 bytes of payload
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-----------------------
where
哪里
C (1 bit) convergence sublayer indication, C=1 for P-format PDUs.
C（1位）收敛子层指示，对于P格式PDU，C=1。
SN (3 bits) is an even AAL1 sequence number.
SN（3位）是偶数AAL1序列号。
CRC (3 bits) is a 3-bit error cyclic redundancy code on C and SN.
CRC（3位）是C和SN上的3位错误循环冗余码。
P (1 bit) even byte parity LSB (least significant bit) for sequence number byte.
序列号字节的P（1位）偶数字节奇偶校验LSB（最低有效位）。
E (1 bit) even byte parity MSB for pointer byte.
指针字节的E（1位）偶数字节奇偶校验MSB。
pointer (7 bits) pointer to next structure boundary.
指针（7位）指向下一个结构边界的指针。
Since P-format PDUs have 46 bytes of payload and the next PDU has 47 bytes, viewed as a single entity the pointer needs to indicate one of 93 bytes. If P=0 it is understood that the structure commences with the following byte (i.e., the first byte in the payload belongs to the lowest numbered channel). P=93 means that the last byte of the second PDU is the final byte of the structure, and the following PDU commences with a new structure. The special value P=127 indicates that there is no structure boundary to be indicated (needed when extremely large structures are being transported).
由于P格式PDU有46个字节的有效负载，而下一个PDU有47个字节，因此作为单个实体来看，指针需要指示93个字节中的一个。如果P＝0，则可以理解结构从以下字节开始（即，有效载荷中的第一个字节属于编号最低的信道）。P=93表示第二个PDU的最后一个字节是结构的最后一个字节，接下来的PDU从一个新结构开始。特殊值P=127表示无需指示结构边界（运输超大结构时需要）。
The P-format PDU is always placed at the first possible position in the sequence number cycle that a structure boundary occurs, and can only occur once per cycle.
P格式PDU始终位于结构边界出现的序列号循环中的第一个可能位置，并且每个循环只能出现一次。
The only difference between the structured circuit emulation format and structured circuit emulation with CAS is the definition of the structure. Whereas in structured circuit emulation the structure is composed of the N channels, in structured circuit emulation with CAS the structure encompasses the superframe consisting of multiple repetitions of the N channels and then the CAS signaling bits. The CAS bits are tightly packed into bytes and the final byte is padded with zeros if required.
结构化电路仿真格式与使用CAS的结构化电路仿真之间的唯一区别在于结构的定义。然而，在结构化电路仿真中，该结构由N个信道组成，而在具有CAS的结构化电路仿真中，该结构包含由N个信道的多次重复以及随后的CAS信令位组成的超帧。CAS位被紧密地压缩到字节中，如果需要，最后一个字节用零填充。
For example, for E1 circuits the CAS signaling bits are updated once per superframe of 16 frames. Hence, the structure for N*64 derived from an E1 with CAS signaling consists of 16 repetitions of N bytes,
例如，对于E1电路，CAS信令位每16帧的超帧更新一次。因此，从具有CAS信令的E1导出的N*64的结构由N字节的16个重复组成，
followed by N sets of the four ABCD bits, and finally four zero bits if N is odd. For example, the structure for channels 2,3 and 5 will be as follows:
然后是N组四个ABCD位，若N为奇数，最后是四个零位。例如，通道2、3和5的结构如下：
2 3 5 2 3 5 2 3 5 2 3 5 2 3 5 2 3 5 2 3 5 2 3 5 2 3 5 2 3 5 2 3 5 2 3 5 2 3 5 2 3 5 2 3 5 2 3 5 [ABCD2 ABCD3] [ABCD5 0000]
2 3 5 2 3 5 2 3 5 2 3 5 2 3 5 2 3 5 2 3 5 2 3 5 2 3 5 2 3 5 2 3 5 2 5 2 5 2 3 5 2 3 3 3 5 5 5 5 5 5[ABCD2 ABCD3][ABCD5 0000]
Similarly for T1 ESF circuits the superframe is 24 frames, and the structure consists of 24 repetitions of N bytes, followed by the ABCD bits as before. For the T1 case the signaling bits will in general appear twice, in their regular (bit-robbed) positions and at the end of the structure.
类似地，对于T1 ESF电路，超帧是24帧，结构由24个重复的N字节组成，后面跟前面一样是ABCD位。对于T1情况，信令位通常会出现两次，在其常规（位被抢）位置和结构的末尾。
Appendix C. AAL2 Review (Informative)
附录C.AAL2审查（资料性）
The basic AAL2 PDU is:
基本的AAL2 PDU是：
| Byte 1 | Byte 2 | Byte 3 |
0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+------------
| CID | LI | UUI | HEC | PAYLOAD
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+------------
| Byte 1 | Byte 2 | Byte 3 |
0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+------------
| CID | LI | UUI | HEC | PAYLOAD
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+------------
CID (8 bits) channel identifier is an identifier that must be unique for the PW. The values 0-7 are reserved for special purposes, (and if interworking with VoDSL is required, so are values 8 through 15 as specified in [LES]), thus leaving 248 (240) CIDs per PW. The mapping of CID values to channels MAY be manually configured manually or signaled.
CID（8位）通道标识符是PW必须唯一的标识符。数值0-7保留用于特殊目的，（如果需要与VoDSL互通，则数值8至15也保留在[LES]中规定的数值），因此每个PW保留248（240）个CID。CID值到通道的映射可以手动配置或发出信号。
LI (6 bits) length indicator is one less than the length of the payload in bytes. Note that the payload is limited to 64 bytes.
LI（6位）长度指示符比有效负载的长度（字节）小一个。请注意，有效负载限制为64字节。
UUI (5 bits) user-to-user indication is the higher layer (application) identifier and counter. For voice data, the UUI will always be in the range 0-15, and SHOULD be incremented modulo 16 each time a channel buffer is sent. The receiver MAY monitor this sequence. UUI is set to 24 for CAS signaling packets.
UUI（5位）用户对用户指示是更高层（应用程序）标识符和计数器。对于语音数据，UUI将始终在0-15范围内，并且应在每次发送信道缓冲器时以16模递增。接收机可以监视该序列。对于CAS信令分组，UUI设置为24。
HEC (5 bits) the header error control
HEC（5位）报头错误控制
Payload - voice A block of length indicated by LI of voice samples are placed as-is into the AAL2 packet.
有效载荷-语音一个由LI表示的长度块，语音样本按原样放入AAL2数据包中。
Payload - CAS signaling For CAS signaling the payload is formatted as an AAL2 "fully protected" (type 3) packet (see [AAL2]) in order to ensure error protection. The signaling is sent with the same CID as the corresponding voice channel. Signaling MUST be sent whenever the state of the ABCD bits changes, and SHOULD be sent with triple redundancy, i.e., sent three times spaced 5 milliseconds apart. In addition, the entire set of the signaling bits SHOULD be sent periodically to ensure reliability.
有效负载-CAS信令用于CAS信令有效负载被格式化为AAL2“完全保护”（类型3）数据包（参见[AAL2]），以确保错误保护。该信令使用与相应语音信道相同的CID发送。每当ABCD位的状态发生变化时，必须发送信号，并且应以三重冗余发送，即间隔5毫秒发送三次。此外，应定期发送整套信令位，以确保可靠性。
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|RED| timestamp |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RES | ABCD | type | CRC
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
CRC (cont) |
+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|RED| timestamp |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RES | ABCD | type | CRC
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
CRC (cont) |
+-+-+-+-+-+-+-+-+
RED (2 bits) is the triple redundancy counter. For the first packet it takes the value 00, for the second 01 and for the third 10. RED=11 means non-redundant information, and is used when triple redundancy is not employed, and for periodic refresh messages.
红色（2位）是三重冗余计数器。对于第一个数据包，它取值00；对于第二个数据包，取值01；对于第三个数据包，取值10。红色=11表示非冗余信息，在未使用三重冗余时使用，并用于定期刷新消息。
Timestamp (14 bits) The timestamp is optional and in particular is not needed if RTP is employed. If not used, the timestamp MUST be set to zero. When used with triple redundancy, it MUST be the same for all three redundant transmissions.
时间戳（14位）时间戳是可选的，特别是如果采用RTP，则不需要时间戳。如果未使用，则时间戳必须设置为零。当与三重冗余一起使用时，所有三重冗余传输必须相同。
RES (4 bits) is reserved and MUST be set to zero.
RES（4位）是保留的，必须设置为零。
ABCD (4 bits) are the CAS signaling bits.
ABCD（4位）是CAS信令位。
type (6 bits) for CAS signaling this is 000011.
CAS信令的类型（6位）为000011。
CRC-10 (10 bits) is a 10-bit CRC error detection code.
CRC-10（10位）是10位CRC错误检测码。
Appendix D. Performance Monitoring Mechanisms (Informative)
附录D.绩效监测机制（资料性）
PWs require OAM mechanisms to monitor performance measures that impact the emulated service. Performance measures, such as packet loss ratio and packet delay variation, may be used to set various parameters and thresholds; for TDMoIP PWs adaptive timing recovery and packet loss concealment algorithms may benefit from such information. In addition, OAM mechanisms may be used to collect statistics relating to the underlying PSN [RFC2330], and its suitability for carrying TDM services.
PWs需要OAM机制来监视影响模拟服务的性能度量。性能度量，例如分组丢失率和分组延迟变化，可用于设置各种参数和阈值；对于TDMoIP-PWs，自适应定时恢复和分组丢失隐藏算法可受益于此类信息。此外，OAM机制可用于收集与底层PSN[RFC2330]及其承载TDM服务的适用性相关的统计信息。
TDMoIP IWFs may benefit from knowledge of PSN performance metrics, such as round trip time (RTT), packet delay variation (PDV) and packet loss ratio (PLR). These measurements are conventionally performed by a separate flow of packets designed for this purpose, e.g., ICMP packets [RFC792] or MPLS LSP ping packets [RFC4379] with multiple timestamps. For AAL1 mode, TDMoIP sends packets across the PSN at a constant rate, and hence no additional OAM flow is required for measurement of PDV or PLR. However, separate OAM flows are required for RTT measurement, for AAL2 mode PWs, for measurement of parameters at setup, for monitoring of inactive backup PWs, and for low-rate monitoring of PSNs after PWs have been withdrawn due to service failures.
TDMoIP IWF可受益于PSN性能指标的知识，例如往返时间（RTT）、分组延迟变化（PDV）和分组丢失率（PLR）。这些测量通常由为此目的而设计的分组的单独流来执行，例如，具有多个时间戳的ICMP分组[RFC792]或MPLS LSP ping分组[RFC4379]。对于AAL1模式，TDMoIP以恒定速率通过PSN发送数据包，因此测量PDV或PLR不需要额外的OAM流。但是，RTT测量、AAL2模式PWs测量、设置时参数测量、非活动备份PWs监控以及PWs因服务故障退出后PSN的低速率监控需要单独的OAM流。
If the underlying PSN has appropriate maintenance mechanisms that provide connectivity verification, RTT, PDV, and PLR measurements that correlate well with those of the PW, then these mechanisms SHOULD be used. If such mechanisms are not available, either of two similar OAM signaling mechanisms may be used. The first is internal to the PW and based on inband VCCV [RFC5085], and the second is defined only for UDP/IP PSNs, and is based on a separate PW. The latter is particularly efficient for a large number of fate-sharing TDM PWs.
如果基础PSN具有适当的维护机制，提供与PW相关的连通性验证、RTT、PDV和PLR测量，则应使用这些机制。如果这种机制不可用，则可以使用两种类似的OAM信令机制中的任何一种。第一个是PW内部的，基于带内VCCV[RFC5085]，第二个仅针对UDP/IP PSN定义，并基于单独的PW。后者对于大量命运共享TDM PW特别有效。
In most conventional IP applications a server sends some finite amount of information over the network after explicit request from a client. With TDMoIP PWs the PSN-bound IWF could send a continuous stream of packets towards the destination without knowing whether the TDM-bound IWF is ready to accept them. For layer-2 networks, this may lead to flooding of the PSN with stray packets.
在大多数传统的IP应用程序中，服务器在客户机明确请求后通过网络发送一些有限数量的信息。使用TDMoIP PWs，绑定PSN的IWF可以向目的地发送连续的数据包流，而不知道绑定TDM的IWF是否准备好接受它们。对于第二层网络，这可能会导致PSN充斥着杂散数据包。
This problem may occur when a TDMoIP IWF is first brought up, when the TDM-bound IWF fails or is disconnected from the PSN, or the PW is broken. After an aging time the destination IWF becomes unknown, and intermediate switches may flood the network with the TDMoIP packets in an attempt to find a new path.
当TDMoIP IWF首次启动时，当TDM绑定IWF发生故障或与PSN断开，或PW断开时，可能会出现此问题。在老化时间之后，目的地IWF变得未知，并且中间交换机可以用TDMoIP分组淹没网络以试图找到新路径。
The solution to this problem is to significantly reduce the number of TDMoIP packets transmitted per second when PW failure is detected, and to return to full rate only when the PW is available. The detection of failure and restoration is made possible by the periodic exchange of one-way connectivity-verification messages.
该问题的解决方案是，当检测到PW故障时，显著减少每秒传输的TDMoIP数据包的数量，并且仅当PW可用时才返回全速率。通过定期交换单向连接验证消息，可以检测故障和恢复。
Connectivity is tested by periodically sending OAM messages from the source IWF to the destination IWF, and having the destination reply to each message. The connectivity verification mechanism SHOULD be used during setup and configuration. Without OAM signaling, one must ensure that the destination IWF is ready to receive packets before starting to send them. Since TDMoIP IWFs operate full-duplex, both would need to be set up and properly configured simultaneously if flooding is to be avoided. When using connectivity verification, a configured IWF may wait until it detects its peer before transmitting at full rate. In addition, configuration errors may be readily discovered by using the service specific field of the OAM PW packets.
通过定期将OAM消息从源IWF发送到目标IWF，并让目标回复每条消息来测试连接性。在设置和配置期间应使用连接验证机制。在没有OAM信令的情况下，必须确保目的地IWF在开始发送数据包之前准备好接收数据包。由于TDMoIP IWF操作全双工，如果要避免泛洪，则需要同时设置和正确配置这两种设备。使用连接性验证时，配置的IWF可能会等到检测到其对等方后再以全速传输。此外，通过使用OAM PW分组的服务特定字段，可以容易地发现配置错误。
In addition to one-way connectivity, OAM signaling mechanisms can be used to request and report on various PSN metrics, such as one-way delay, round trip delay, packet delay variation, etc. They may also be used for remote diagnostics, and for unsolicited reporting of potential problems (e.g., dying gasp messages).
除了单向连接之外，OAM信令机制还可用于请求和报告各种PSN度量，例如单向延迟、往返延迟、数据包延迟变化等。它们还可用于远程诊断，并用于主动报告潜在问题（例如，死亡gasp消息）。
When using inband performance monitoring, additional packets are sent using the same PW label. These packets are identified by having their first nibble equal to 0001, and must be separated from TDM data packets before further processing of the control word.
使用带内性能监视时，使用相同的PW标签发送其他数据包。这些数据包通过其第一个半字节等于0001来识别，并且在进一步处理控制字之前必须与TDM数据包分离。
When using a separate OAM PW, all OAM messages MUST use the PW label preconfigured to indicate OAM. All PSN layer parameters MUST remain those of the PW being monitored.
当使用单独的OAM PW时，所有OAM消息必须使用预配置的PW标签来指示OAM。所有PSN层参数必须保持受监控PW的参数。
The format of an inband OAM PW message packet for UDP/IP PSNs is based on [RFC2679]. The PSN-specific layers are identical to those defined in Section 4.1 with the PW label set to the value preconfigured or assigned for PW OAM.
UDP/IP PSN的带内OAM PW消息包的格式基于[RFC2679]。PSN特定层与第4.1节中定义的层相同，PW标签设置为PW OAM预配置或分配的值。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PSN-specific layers (with preconfigured PW label) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0|L|R| M |RES| Length | OAM Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OAM Msg Type | OAM Msg Code | Service specific information |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Forward PW label | Reverse PW label |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Transmit Timestamp |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination Receive Timestamp |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination Transmit Timestamp |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PSN-specific layers (with preconfigured PW label) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0|L|R| M |RES| Length | OAM Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OAM Msg Type | OAM Msg Code | Service specific information |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Forward PW label | Reverse PW label |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Transmit Timestamp |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination Receive Timestamp |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination Transmit Timestamp |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
L, R, and M are identical to those of the PW being tested.
五十、 R和M与被测PW的相同。
Length is the length in bytes of the OAM message packet.
Length是OAM消息包的长度（以字节为单位）。
OAM Sequence Number (16 bits) is used to uniquely identify the message. Its value is unrelated to the sequence number of the TDMoIP data packets for the PW in question. It is incremented in query messages, and replicated without change in replies.
OAM序列号（16位）用于唯一标识消息。其值与所述PW的TDMoIP数据包的序列号无关。它在查询消息中递增，并在答复中复制而不更改。
OAM Msg Type (8 bits) indicates the function of the message. At present the following are defined:
OAM消息类型（8位）表示消息的功能。目前定义如下：
0 for one-way connectivity query message 8 for one-way connectivity reply message.
0表示单向连接查询消息8表示单向连接回复消息。
OAM Msg Code (8 bits) is used to carry information related to the message, and its interpretation depends on the message type. For type 0 (connectivity query) messages the following codes are defined:
OAM消息代码（8位）用于携带与消息相关的信息，其解释取决于消息类型。对于类型0（连接查询）消息，定义了以下代码：
0 validate connection. 1 do not validate connection
0验证连接。1不验证连接
for type 8 (connectivity reply) messages the available codes are:
对于类型8（连接回复）消息，可用代码为：
0 acknowledge valid query 1 invalid query (configuration mismatch).
0确认有效查询1无效查询（配置不匹配）。
Service specific information (16 bits) is a field that can be used to exchange configuration information between IWFs. If it is not used, this field MUST contain zero. Its interpretation depends on the payload type. At present, the following is defined for AAL1 payloads.
服务特定信息（16位）是可用于在IWF之间交换配置信息的字段。如果未使用，则此字段必须包含零。其解释取决于有效载荷类型。目前，AAL1有效载荷定义如下。
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Number of TSs | Number of SFs |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Number of TSs | Number of SFs |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Number of TSs (8 bits) is the number of channels being transported, e.g., 24 for full T1.
TSs数量（8位）是正在传输的信道数量，例如，对于完整T1为24。
Number of SFs (8 bits) is the number of 48-byte AAL1 PDUs per packet, e.g., 8 when packing 8 PDUs per packet.
SFs数量（8位）是每个数据包48字节AAL1 PDU的数量，例如，每个数据包打包8个PDU时为8。
Forward PW label (16 bits) is the PW label used for TDMoIP traffic from the source to destination IWF.
前向PW标签（16位）是用于从源到目标IWF的TDMoIP流量的PW标签。
Reverse PW label (16 bits) is the PW label used for TDMoIP traffic from the destination to source IWF.
反向PW标签（16位）是用于从目的地到源IWF的TDMoIP流量的PW标签。
Source Transmit Timestamp (32 bits) represents the time the PSN-bound IWF transmitted the query message. This field and the following ones only appear if delay is being measured. All time units are derived from a clock of preconfigured frequency, the default being 100 microseconds.
源传输时间戳（32位）表示绑定PSN的IWF传输查询消息的时间。此字段和以下字段仅在测量延迟时出现。所有时间单位均源自预先配置频率的时钟，默认为100微秒。
Destination Receive Timestamp (32 bits) represents the time the destination IWF received the query message.
目标接收时间戳（32位）表示目标IWF接收查询消息的时间。
Destination Transmit Timestamp (32 bits) represents the time the destination IWF transmitted the reply message.
目标发送时间戳（32位）表示目标IWF发送回复消息的时间。
Appendix E. Capabilities, Configuration and Statistics (Informative)
附录E.能力、配置和统计（资料性）
Every TDMoIP IWF will support some number of physical TDM connections, certain types of PSN, and some subset of the modes defined above. The following capabilities SHOULD be able to be queried by the management system:
每个TDMoIP IWF将支持一定数量的物理TDM连接、某些类型的PSN和上述定义的某些模式子集。管理系统应能够查询以下功能：
AAL1 capable
AAL1能力
AAL2 capable (and AAL2 parameters, e.g., support for VAD and compression)
支持AAL2（以及AAL2参数，例如，支持VAD和压缩）
HDLC capable
支持HDLC的
Supported PSN types (UDP/IPv4, UDP/IPv6, L2TPv3/IPv4, L2TPv3/IPv6,
MPLS, Ethernet)
Supported PSN types (UDP/IPv4, UDP/IPv6, L2TPv3/IPv4, L2TPv3/IPv6,
MPLS, Ethernet)
OAM support (none, separate PW, VCCV) and capabilities (CV, delay measurement, etc.)
OAM支持（无、单独PW、VCCV）和功能（CV、延迟测量等）
maximum packet size supported.
支持的最大数据包大小。
For every TDM PW the following parameters MUST be provisioned or signaled:
对于每个TDM PW，必须提供或发送以下参数：
PW label (for UDP and Ethernet the label MUST be manually configured)
PW标签（对于UDP和以太网，必须手动配置标签）
TDM type (E1, T1, E3, T3, fractional E1, fractional T1)
TDM类型（E1、T1、E3、T3、分数E1、分数T1）
for fractional links: number of timeslots
对于分数链路：时隙数
TDMoIP mode (AAL1, AAL2, HDLC)
TDMoIP模式（AAL1、AAL2、HDLC）
for AAL1 mode:
对于AAL1模式：
AAL1 type (unstructured, structured, structured with CAS)
AAL1类型（非结构化、结构化、带CAS的结构化）
number of AAL1 PDUs per packet
每个数据包的AAL1 PDU数
for AAL2 mode:
对于AAL2模式：
CID mapping
CID映射
creation time of full minicell (units of 125 microsecond)
完整微型单元的创建时间（单位为125微秒）
size of jitter buffer (in 32-bit words)
抖动缓冲区的大小（32位字）
clock recovery method (local, loop-back timing, adaptive, common clock)
时钟恢复方法（本地、环回定时、自适应、公共时钟）
use of RTP (if used: frequency of common clock, PT and SSRC values).
使用RTP（如果使用：公共时钟频率、PT和SSRC值）。
During operation, the following statistics and impairment indications SHOULD be collected for each TDM PW, and can be queried by the management system.
在运行期间，应收集每个TDM PW的以下统计数据和减值指示，并可由管理系统查询。
average round-trip delay
平均往返延误
packet delay variation (maximum delay - minimum delay)
数据包延迟变化（最大延迟-最小延迟）
number of potentially lost packets
可能丢失的数据包数
indication of misordered packets (successfully reordered or dropped)
指示错误排序的数据包（成功重新排序或丢弃）
for AAL1 mode PWs:
对于AAL1模式PWs：
indication of malformed PDUs (incorrect CRC, bad C, P or E)
显示格式错误的PDU（错误的CRC、错误的C、P或E）
indication of cells with pointer mismatch
指针不匹配单元格的指示
number of seconds with jitter buffer over-run events
抖动缓冲区溢出运行事件的秒数
number of seconds with jitter buffer under-run events
运行事件下具有抖动缓冲区的秒数
for AAL2 mode PWs:
对于AAL2模式PWs：
number of malformed minicells (incorrect HEC)
格式错误的微型单元数（HEC不正确）
indication of misordered minicells (unexpected UUI)
指示排列错误的微型单元（意外UUI）
indication of stray minicells (CID unknown, illegal UUI)
杂散小单元指示（CID未知，非法UUI）
indication of mis-sized minicells (unexpected LI)
显示尺寸不正确的微型电池（意外LI）
for each CID: number of seconds with jitter buffer over-run events
对于每个CID：抖动缓冲区溢出运行事件的秒数
for HDLC mode PWs:
对于HDLC模式PWs：
number of discarded frames from TDM (e.g., CRC error, illegal packet size)
来自TDM的丢弃帧数（例如，CRC错误、非法数据包大小）
number of seconds with jitter buffer over-run events.
抖动缓冲区超过运行事件的秒数。
During operation, the following statistics MAY be collected for each TDM PW.
在运行期间，可为每个TDM PW收集以下统计信息。
number of packets sent to PSN
发送到PSN的数据包数
number of packets received from PSN
从PSN接收的数据包数
number of seconds during which packets were received with L flag set
设置L标志接收数据包的秒数
number of seconds during which packets were received with R flag set.
设置R标志接收数据包的秒数。
References
工具书类
Normative References
规范性引用文件
[AAL1] ITU-T Recommendation I.363.1 (08/96) - B-ISDN ATM Adaptation Layer (AAL) specification: Type 1
[AAL1]ITU-T建议I.363.1（08/96）-B-ISDN ATM适配层（AAL）规范：类型1
[AAL2] ITU-T Recommendation I.363.2 (11/00) - B-ISDN ATM Adaptation Layer (AAL) specification: Type 2
[AAL2]ITU-T建议I.363.2（11/00）-B-ISDN ATM适配层（AAL）规范：类型2
[CES] ATM forum specification atm-vtoa-0078 (CES 2.0) Circuit Emulation Service Interoperability Specification Ver. 2.0
[CES]ATM论坛规范ATM-vtoa-0078（CES 2.0）电路仿真服务互操作性规范版本。2
[G704] ITU-T Recommendation G.704 (10/98) - Synchronous frame structures used at 1544, 6312, 2048, 8448 and 44736 kbit/s hierarchical levels
[G704]ITU-T建议G.704（10/98）-在1544631204884448和44736kbit/s分层级别上使用的同步帧结构
[G751] ITU-T Recommendation G.751 (11/88) - Digital multiplex equipments operating at the third order bit rate of 34368 kbit/s and the fourth order bit rate of 139264 kbit/s and using positive justification
[G751]ITU-T建议G.751（11/88）-以34368 kbit/s的三阶比特率和139264 kbit/s的四阶比特率运行的数字多路复用设备，并使用正对齐
[G823] ITU-T Recommendation G.823 (03/00) - The control of jitter and wander within digital networks which are based on the 2048 Kbit/s hierarchy
[G823]ITU-T建议G.823（03/00）-基于2048 Kbit/s层次结构的数字网络中的抖动和漂移控制
[G824] ITU-T Recommendation G.824 (03/00) - The control of jitter and wander within digital networks which are based on the 1544 Kbit/s hierarchy
[G824]ITU-T建议G.824（03/00）-基于1544 Kbit/s层次结构的数字网络中的抖动和漂移控制
[G826] ITU-T Recommendation G.826 (12/02) - End-to-end error performance parameters and objectives for international, constant bit-rate digital paths and connections
[G826]ITU-T建议G.826（12/02）-国际恒定比特率数字路径和连接的端到端错误性能参数和目标
[IEEE802.1Q] IEEE 802.1Q, IEEE Standards for Local and Metropolitan Area Networks -- Virtual Bridged Local Area Networks (2003)
[IEEE802.1Q]IEEE 802.1Q，局域网和城域网的IEEE标准——虚拟桥接局域网（2003）
[IEEE802.3] IEEE 802.3, IEEE Standard Local and Metropolitan Area Networks - Carrier Sense Multiple Access with Collision Detection (CSMA/CD) Access Method and Physical Layer Specifications (2002)
[IEEE802.3]IEEE 802.3，IEEE标准局域网和城域网-带冲突检测的载波侦听多址接入（CSMA/CD）接入方法和物理层规范（2002）
[LES] ATM forum specification atm-vmoa-0145 (LES) Voice and Multimedia over ATM - Loop Emulation Service Using AAL2
[LES]ATM论坛规范ATM-vmoa-0145（LES）ATM上的语音和多媒体-使用AAL2的环路仿真服务
[MEF8] Metro Ethernet Forum, "Implementation Agreement for the Emulation of PDH Circuits over Metro Ethernet Networks", October 2004.
[MEF8]城域以太网论坛，“城域以太网上PDH电路仿真实施协议”，2004年10月。
[RFC768] Postel, J., "User Datagram Protocol (UDP)", STD 6, RFC 768, August 1980.
[RFC768]Postel，J.，“用户数据报协议（UDP）”，STD 6，RFC 768，1980年8月。
[RFC791] Postel, J., "Internet Protocol (IP)", STD 5, RFC 791, September 1981.
[RFC791]Postel，J.，“互联网协议（IP）”，标准5，RFC7911981年9月。
[RFC2119] Bradner, S., "Key Words in RFCs to Indicate Requirement Levels", RFC 2119, March 1997.
[RFC2119]Bradner，S.，“RFC中表示需求水平的关键词”，RFC 211997年3月。
[RFC3032] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y., Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack Encoding", RFC 3032, January 2001.
[RFC3032]Rosen，E.，Tappan，D.，Fedorkow，G.，Rekhter，Y.，Farinaci，D.，Li，T.，和A.Conta，“MPLS标签堆栈编码”，RFC 3032，2001年1月。
[RFC3931] Lau, J., Townsley, M., Goyret, I., "Layer Two Tunneling Protocol - Version 3 (L2TPv3)", RFC 3931, March 2005.
[RFC3931]Lau，J.，Townsley，M.，Goyret，I.，“第二层隧道协议-版本3（L2TPv3）”，RFC 39312005年3月。
[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and Jacobson, V., "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, July 2003.
[RFC3550]Schulzrinne，H.，Casner，S.，Frederick，R.，和Jacobson，V.，“RTP：实时应用的传输协议”，STD 64，RFC 35502003年7月。
[RFC4446] Martini, L., "IANA Allocations for Pseudowire Edge to Edge Emulation (PWE3)", BCP 116, RFC 4446, April 2006.
[RFC4446]Martini，L.，“伪线边到边仿真（PWE3）的IANA分配”，BCP 116，RFC 4446，2006年4月。
[RFC4447] Martini, L., Rosen, E., El-Aawar, N., Smith, T., and G. Heron, "Pseudowire Setup and Maintenance Using the Label Distribution Protocol (LDP)", RFC 4447, April 2006.
[RFC4447]Martini，L.，Rosen，E.，El Aawar，N.，Smith，T.，和G.Heron，“使用标签分发协议（LDP）的伪线设置和维护”，RFC 4447，2006年4月。
[RFC4553] Vainshtein A., and Stein YJ., "Structure-Agnostic TDM over Packet (SAToP)", RFC 4553, June 2006.
[RFC4553]Vainstein A.和Stein YJ.，“数据包上的结构不可知TDM（SAToP）”，RFC 45532006年6月。
[RFC4618] Martini L., Rosen E., Heron G., and Malis A., "Encapsulation Methods for Transport of PPP/High-Level Data Link Control (HDLC) over MPLS Networks", RFC 4618, September 2006.
[RFC4618]Martini L.，Rosen E.，Heron G.，和Malis A.，“通过MPLS网络传输PPP/高级数据链路控制（HDLC）的封装方法”，RFC 4618，2006年9月。
[RFC5085] Nadeau, T., Ed., and C. Pignataro, Ed., "Pseudowire Virtual Circuit Connectivity Verification: A Control Channel for Pseudowires", RFC 5085, December 2007.
[RFC5085]Nadeau，T.，Ed.，和C.Pignataro，Ed.，“伪线虚拟电路连接验证：伪线的控制通道”，RFC 5085，2007年12月。
[SSCS] ITU-T Recommendation I.366.2 (11/00) - AAL type 2 service specific convergence sublayer for narrow-band services.
[SSCS]ITU-T建议I.366.2（11/00）——窄带业务AAL 2类业务专用汇聚子层。
[Y1413] ITU-T Recommendation Y.1413 (03/04) - TDM-MPLS network interworking - User plane interworking
[Y1413]ITU-T建议Y.1413（03/04）-TDM-MPLS网络互通-用户平面互通
[Y1414] ITU-T Recommendation Y.1414 (07/04) - Voice services - MPLS network interworking.
[Y1414]ITU-T建议Y.1414（07/04）-语音服务-MPLS网络互通。
[Y1452] ITU-T Recommendation Y.1452 (03/06) - Voice trunking over IP networks.
[Y1452]ITU-T建议Y.1452（03/06）-IP网络上的语音中继。
[Y1453] ITU-T Recommendation Y.1453 (03/06) - TDM-IP interworking - User plane interworking.
[Y1453]ITU-T建议Y.1453（03/06）-TDM-IP互通-用户平面互通。
Informative References
资料性引用
[ISDN-PRI] ITU-T Recommendation Q.931 (05/98) - ISDN user-network interface layer 3 specification for basic call control.
[ISDN-PRI]ITU-T建议Q.931（05/98）——基本呼叫控制的ISDN用户网络接口第3层规范。
[RFC792] Postel J., "Internet Control Message Protocol", STD 5, RFC 792, September 1981.
[RFC792]Postel J.，“互联网控制消息协议”，STD 5，RFC 792，1981年9月。
[RFC2212] Shenker, S., Partridge, C., and R. Guerin, "Specification of Guaranteed Quality of Service", RFC 2212, September 1997.
[RFC2212]Shenker，S.，Partridge，C.和R.Guerin，“保证服务质量规范”，RFC 2212，1997年9月。
[RFC2330] Paxson, V., Almes, G., Mahdavi, J., Mathis M., "Framework for IP Performance Metrics", RFC 2330, May 1998.
[RFC2330]Paxson，V.，Almes，G.，Mahdavi，J.，Mathis M.，“IP性能度量框架”，RFC 2330，1998年5月。
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998.
[RFC2460]Deering，S.和R.Hinden，“互联网协议，第6版（IPv6）规范”，RFC 2460，1998年12月。
[RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, "Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers", RFC 2474, December 1998.
[RFC2474]Nichols，K.，Blake，S.，Baker，F.，和D.Black，“IPv4和IPv6头中区分服务字段（DS字段）的定义”，RFC 2474，1998年12月。
[RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., and W. Weiss, "An Architecture for Differentiated Service", RFC 2475, December 1998.
[RFC2475]Blake，S.，Black，D.，Carlson，M.，Davies，E.，Wang，Z.，和W.Weiss，“差异化服务架构”，RFC 24751998年12月。
[RFC2679] Almes, G., Kalidindi, S., and M. Zekauskas, "A One-way Delay Metric for IPPM", RFC 2679, September 1999.
[RFC2679]Almes，G.，Kalidini，S.，和M.Zekauskas，“IPPM的单向延迟度量”，RFC 2679，1999年9月。
[RFC2914] Floyd, S., "Congestion Control Principles", BCP 41, RFC 2914, September 2000.
[RFC2914]Floyd，S.，“拥塞控制原则”，BCP 41，RFC 2914，2000年9月。
[RFC3246] Davie, B., Charny, A., Bennet, J.C., Benson, K., Le Boudec, J., Courtney, W., Davari, S., Firoiu, V., and D. Stiliadis, "An Expedited Forwarding PHB (Per-Hop Behavior)", RFC 3246, March 2002.
[RFC3246]Davie，B.，Charny，A.，Bennet，J.C.，Benson，K.，Le Boudec，J.，Courtney，W.，Davari，S.，Firoiu，V.，和D.Stiliadis，“快速转发PHB（每跳行为）”，RFC 32462002年3月。
[RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. Norrman, "The Secure Real-time Transport Protocol (SRTP)", RFC 3711, March 2004.
[RFC3711]Baugher，M.，McGrew，D.，Naslund，M.，Carrara，E.，和K.Norrman，“安全实时传输协议（SRTP）”，RFC 37112004年3月。
[RFC3985] Bryant, S. and P. Pate, "Pseudo Wire Emulation Edge-to-Edge (PWE3) Architecture", RFC 3985, March 2005.
[RFC3985]Bryant，S.和P.Pate，“伪线仿真边到边（PWE3）架构”，RFC 39852005年3月。
[RFC4086] Eastlake, D., 3rd, Schiller, J., and S. Crocker, "Randomness Requirements for Security", BCP 106, RFC 4086, June 2005.
[RFC4086]伊斯特莱克，D.，3，席勒，J.和S.克罗克，“安全的随机性要求”，BCP 106，RFC 4086，2005年6月。
[RFC4197] Riegel, M., "Requirements for Edge-to-Edge Emulation of Time Division Multiplexed (TDM) Circuits over Packet Switching Networks", RFC 4197, October 2005.
[RFC4197]Riegel，M.，“分组交换网络上时分多路复用（TDM）电路的边到边仿真要求”，RFC 4197，2005年10月。
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005.
[RFC4301]Kent，S.和K.Seo，“互联网协议的安全架构”，RFC 43012005年12月。
[RFC4379] Kompella, K. and Swallow, G., "Detecting Multi-Protocol Label Switched (MPLS) Data Plane Failures", RFC 4379, February 2006.
[RFC4379]Kompella，K.和Swallow，G.，“检测多协议标签交换（MPLS）数据平面故障”，RFC 4379，2006年2月。
[RFC4385] Bryant, S., Swallow, G., Martini, L., and D. McPherson, "Pseudowire Emulation Edge-to-Edge (PWE3) Control Word for Use over an MPLS PSN", RFC 4385, February 2006.
[RFC4385]Bryant，S.，Swallow，G.，Martini，L.，和D.McPherson，“用于MPLS PSN的伪线仿真边到边（PWE3）控制字”，RFC 43852006年2月。
[RFC5086] Vainshtein, A., Ed., Sasson, I., Metz, E., Frost, T., and P. Pate, "Structure-Aware Time Division Multiplexed (TDM) Circuit Emulation Service over Packet Switched Network (CESoPSN)", RFC 5086, December 2007.
[RFC5086]Vainstein，A.，Ed.，Sasson，I.，Metz，E.，Frost，T.，和P.Pate，“分组交换网络上的结构感知时分多路复用（TDM）电路仿真服务（CESoPSN）”，RFC 5086，2007年12月。
[SS7] ITU-T Recommendation Q.700 (03/93) - Introduction to CCITT Signalling System No. 7.
[SS7]ITU-T建议Q.700（03/93）-CCITT第7号信令系统介绍。
[TDM-CONTROL] Vainshtein, A. and Y(J) Stein, "Control Protocol Extensions for Setup of TDM Pseudowires in MPLS Networks", Work in Progress, November 2007.
[TDM-CONTROL]Vainstein，A.和Y（J）Stein，“用于在MPLS网络中设置TDM伪线的控制协议扩展”，正在进行的工作，2007年11月。
[TRAU] GSM 08.60 (10/01) - Digital cellular telecommunications system (Phase 2+); Inband control of remote transcoders and rate adaptors for Enhanced Full Rate (EFR) and full rate traffic channels.
[TRAU]GSM 08.60（10/01）-数字蜂窝通信系统（第2+阶段）；带内控制用于增强全速率（EFR）和全速率业务信道的远程转码器和速率适配器。
Authors' Addresses
作者地址
Yaakov (Jonathan) Stein RAD Data Communications 24 Raoul Wallenberg St., Bldg C Tel Aviv 69719 ISRAEL
以色列特拉维夫C栋拉乌尔沃伦堡大街24号雅科夫（乔纳森）斯坦无线电数据通信公司，邮编69719
Phone: +972 3 645-5389
EMail: yaakov_s@rad.com
Phone: +972 3 645-5389
EMail: yaakov_s@rad.com
Ronen Shashoua RAD Data Communications 24 Raoul Wallenberg St., Bldg C Tel Aviv 69719 ISRAEL
以色列特拉维夫拉乌尔瓦伦堡街24号C栋Ronen Shashoua无线电数据通信公司，邮编：69719
Phone: +972 3 645-5447
EMail: ronen_s@rad.com
Phone: +972 3 645-5447
EMail: ronen_s@rad.com
Ron Insler RAD Data Communications 24 Raoul Wallenberg St., Bldg C Tel Aviv 69719 ISRAEL
以色列特拉维夫拉乌尔沃伦堡街24号C栋Ron Insler无线电数据通信69719
Phone: +972 3 645-5445
EMail: ron_i@rad.com
Phone: +972 3 645-5445
EMail: ron_i@rad.com
Motty (Mordechai) Anavi RAD Data Communications 900 Corporate Drive Mahwah, NJ 07430 USA
美国新泽西州马华市公司大道900号莫蒂（莫尔德凯）阿纳维无线电数据通信公司07430
Phone: +1 201 529-1100 Ext. 213
EMail: motty@radusa.com
Phone: +1 201 529-1100 Ext. 213
EMail: motty@radusa.com
Full Copyright Statement
完整版权声明
Copyright (C) The IETF Trust (2007).
版权所有（C）IETF信托基金（2007年）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
本文件受BCP 78中包含的权利、许可和限制的约束，除其中规定外，作者保留其所有权利。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
本文件及其包含的信息以“原样”为基础提供，贡献者、他/她所代表或赞助的组织（如有）、互联网协会、IETF信托基金和互联网工程任务组不承担任何明示或暗示的担保，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Intellectual Property
知识产权
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETF对可能声称与本文件所述技术的实施或使用有关的任何知识产权或其他权利的有效性或范围，或此类权利下的任何许可可能或可能不可用的程度，不采取任何立场；它也不表示它已作出任何独立努力来确定任何此类权利。有关RFC文件中权利的程序信息，请参见BCP 78和BCP 79。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
向IETF秘书处披露的知识产权副本和任何许可证保证，或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果，可从IETF在线知识产权存储库获取，网址为http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETF邀请任何相关方提请其注意任何版权、专利或专利申请，或其他可能涵盖实施本标准所需技术的专有权利。请将信息发送至IETF的IETF-ipr@ietf.org.