Internet Engineering Task Force (IETF) Y(J) Stein
Request for Comments: 7893 RAD Data Communications
Category: Informational D. Black
ISSN: 2070-1721 EMC Corporation
B. Briscoe
BT
June 2016
Internet Engineering Task Force (IETF) Y(J) Stein
Request for Comments: 7893 RAD Data Communications
Category: Informational D. Black
ISSN: 2070-1721 EMC Corporation
B. Briscoe
BT
June 2016
Pseudowire Congestion Considerations
伪线拥塞考虑
Abstract
摘要
Pseudowires (PWs) have become a common mechanism for tunneling traffic and may be found in unmanaged scenarios competing for network resources both with other PWs and with non-PW traffic, such as TCP/IP flows. Thus, it is worthwhile specifying under what conditions such competition is acceptable, i.e., the PW traffic does not significantly harm other traffic or contribute more than it should to congestion. We conclude that PWs transporting responsive traffic behave as desired without the need for additional mechanisms. For inelastic PWs (such as Time Division Multiplexing (TDM) PWs), we derive a bound under which such PWs consume no more network capacity than a TCP flow. For TDM PWs, we find that the level of congestion at which the PW can no longer deliver acceptable TDM service is never significantly greater, and is typically much lower, than this bound. Therefore, as long as the PW is shut down when it can no longer deliver acceptable TDM service, it will never do significantly more harm than even a single TCP flow. If the TDM service does not automatically shut down, a mechanism to block persistently unacceptable TDM pseudowires is required.
伪线（PW）已成为隧道流量的常见机制，在与其他PW和非PW流量（如TCP/IP流）争夺网络资源的非托管场景中可能会发现。因此，有必要具体说明在何种条件下这种竞争是可接受的，即PW交通不会对其他交通造成重大损害，也不会对拥堵造成过大的影响。我们得出结论，PWs传输响应性流量的行为符合预期，无需额外的机制。对于非弹性PWs（如时分复用（TDM）PWs），我们推导出一个界限，在此界限下，此类PWs消耗的网络容量不超过TCP流。对于TDM PWs，我们发现PW无法再提供可接受的TDM服务的拥塞水平从来没有显著高于该界限，并且通常要低得多。因此，只要PW在无法提供可接受的TDM服务时关闭，它就不会比单个TCP流造成更大的危害。如果TDM服务未自动关闭，则需要一种机制来阻止持续不可接受的TDM伪线。
Status of This Memo
关于下段备忘
This document is not an Internet Standards Track specification; it is published for informational purposes.
本文件不是互联网标准跟踪规范；它是为了提供信息而发布的。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 7841.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。并非IESG批准的所有文件都适用于任何级别的互联网标准；见RFC 7841第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc7893.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc7893.
Copyright Notice
版权公告
Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2016 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. PWs Comprising Elastic Flows . . . . . . . . . . . . . . . . 6
4. PWs Comprising Inelastic Flows . . . . . . . . . . . . . . . 7
5. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 19
6. Security Considerations . . . . . . . . . . . . . . . . . . . 19
7. Informative References . . . . . . . . . . . . . . . . . . . 19
Appendix A. Loss Probabilities for TDM PWs . . . . . . . . . . . 22
Appendix B. Effect of Packet Loss on Voice Quality for
Structure-Aware TDM PWs . . . . . . . . . . . . . . 23
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 27
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. PWs Comprising Elastic Flows . . . . . . . . . . . . . . . . 6
4. PWs Comprising Inelastic Flows . . . . . . . . . . . . . . . 7
5. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 19
6. Security Considerations . . . . . . . . . . . . . . . . . . . 19
7. Informative References . . . . . . . . . . . . . . . . . . . 19
Appendix A. Loss Probabilities for TDM PWs . . . . . . . . . . . 22
Appendix B. Effect of Packet Loss on Voice Quality for
Structure-Aware TDM PWs . . . . . . . . . . . . . . 23
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 27
A pseudowire (PW) (see [RFC3985]) is a construct for tunneling a native service, such as Ethernet or TDM, over a Packet Switched Network (PSN), such as IPv4, IPv6, or MPLS. The PW packet encapsulates a unit of native service information by prepending the headers required for transport in the particular PSN (which must include a demultiplexer field to distinguish the different PWs) and preferably the 4-byte Pseudowire Emulation Edge-to-Edge (PWE3) control word.
伪线（PW）（参见[RFC3985]）是一种用于通过分组交换网络（PSN）（如IPv4、IPv6或MPLS）对本机服务（如以太网或TDM）进行隧道传输的结构。PW分组通过在特定PSN（其必须包括用于区分不同PW的解复用器字段）和优选的4字节伪线仿真边到边（PWE3）控制字中预加传输所需的报头来封装本机服务信息的单元。
PWs have no bandwidth reservation or control mechanisms, meaning that when multiple PWs are transported in parallel, and/or in parallel with other flows, there is no defined means for allocating resources for any particular PW, or for preventing the negative impact of a particular PW on neighboring flows. The case where the service provider network provisions a PW with sufficient capacity is well understood and will not be discussed further here. Concerns arise when PWs share network capacity with elastic or congestion-responsive traffic, whether that capacity sharing was planned by a service provider or results from PW deployment by an end user.
PW没有带宽保留或控制机制，这意味着当多个PW并行传输和/或与其他流并行传输时，没有为任何特定PW分配资源或防止特定PW对相邻流产生负面影响的定义方法。服务提供商网络提供具有足够容量的PW的情况已得到充分理解，此处不再进一步讨论。当PWs与弹性或拥塞响应流量共享网络容量时，会出现问题，无论该容量共享是由服务提供商计划的，还是由最终用户部署PW的结果。
PWs are most often placed in MPLS tunnels, but we herein restrict ourselves to PWs in IPv4 or IPv6 PSNs; MPLS PSNs are beyond the scope of this document. There are several mechanisms that enable transporting PWs over an IP infrastructure, including:
PW通常放置在MPLS隧道中，但我们在此仅限于IPv4或IPv6 PSN中的PW；MPLS PSN超出了本文档的范围。有几种机制可以通过IP基础设施传输PWs，包括：
o UDP/IP encapsulations as defined for TDM PWs [RFC4553] [RFC5086] [RFC5087],
o TDM PWs定义的UDP/IP封装[RFC4553][RFC5086][RFC5087]，
o PWs based on Layer 2 Tunneling Protocol (L2TPv3) [RFC3931],
o 基于第二层隧道协议（L2TPv3）[RFC3931]的PWs，
o MPLS PWs directly over IP according to RFC 4023 [RFC4023], and
o 根据RFC 4023[RFC4023]，直接通过IP的MPLS PWs，以及
o MPLS PWs over Generic Routing Encapsulation (GRE) over IP according to RFC 4023 [RFC4023].
o 根据RFC 4023[RFC4023]，基于IP的通用路由封装（GRE）的MPLS PWs。
Whenever PWs are transported over IP, they may compete for network resources with neighboring congestion-responsive flows (e.g., TCP flows). In this document, we study the effect of PWs on such neighboring flows, and discover that the negative impact of PW traffic is generally no worse than that of congestion-responsive flows [RFC2914] [RFC5033].
只要PW通过IP传输，它们就可能与相邻的拥塞响应流（例如TCP流）争夺网络资源。在本文中，我们研究了PWs对此类相邻流的影响，并发现PW流量的负面影响通常不比拥塞响应流的负面影响差[RFC2914][RFC5033]。
At first glance, one may consider a PW transported over IP to be considered as a single flow, on par with a single TCP flow. Were we to accept this tenet, we would require a PW to back off under congestion to consume no more bandwidth than a single TCP flow under
乍一看，人们可以考虑在IP上传输的PW被视为单个流，与单个TCP流相称。如果我们接受这一原则，我们将要求PW在拥塞情况下后退，以消耗的带宽不超过拥塞情况下的单个TCP流
such conditions (see [RFC5348]). However, since PWs may carry traffic from many users, it makes more sense to consider each PW to be equivalent to multiple TCP flows.
此类条件（见[RFC5348]）。然而，由于PWS可以承载来自许多用户的业务，所以考虑每个PW相当于多个TCP流更有意义。
The following two sections consider PWs of two types:
以下两个部分考虑了PWs的两种类型：
Elastic Flows: Section 3 concludes that the response to congestion of a PW carrying elastic (e.g., TCP) flows is no different from the aggregated behaviors of the individual elastic flows, had they not been encapsulated within a PW.
弹性流：第3节得出结论，如果单个弹性流未封装在PW中，则承载弹性（例如TCP）流的PW对拥塞的响应与单个弹性流的聚合行为没有区别。
Inelastic Flows: Section 4 considers the case of inelastic constant bit rate (CBR) TDM PWs [RFC4553] [RFC5086] [RFC5087] competing with TCP flows. Such PWs require a preset amount of bandwidth, that may be lower or higher than that consumed by an otherwise unconstrained TCP flow under the same network conditions. In any case, such a PW is unable to respond to congestion in a TCP-like manner; although admittedly the total bandwidth it consumes remains constant and does not increase to consume additional bandwidth as TCP rates back off. For TDM services, we will show that TDM service quality degradation generally occurs before the TDM PW becomes TCP-unfriendly. For TDM services that do not automatically shut down when they persistently fail to comply with acceptable TDM service criteria, a transport circuit breaker [CIRCUIT-BREAKER] may be employed as a last resort to shut down a TDM pseudowire that can no longer deliver acceptable service.
非弹性流：第4节考虑非弹性恒定比特率（CBR）TDM PWs[RFC4553][RFC5086][RFC5087]与TCP流竞争的情况。此类PW需要预设的带宽量，该带宽量可能低于或高于在相同网络条件下由其他无约束TCP流消耗的带宽量。在任何情况下，这样的PW都无法以类似TCP的方式响应拥塞；尽管不可否认，它消耗的总带宽保持不变，并且不会随着TCP速率的降低而增加以消耗额外的带宽。对于TDM服务，我们将说明TDM服务质量下降通常发生在TDM PW变得不友好TCP之前。对于在持续不符合可接受的TDM服务标准时不会自动关闭的TDM服务，可使用传输断路器[断路器]作为关闭无法再提供可接受服务的TDM伪线的最后手段。
Thus, in both cases, pseudowires will not inflict significant harm on neighboring TCP flows, as in one case they respond adequately to congestion, and in the other they would be shut down due to being unable to deliver acceptable service before harming neighboring flows.
因此，在这两种情况下，伪线不会对相邻TCP流造成重大损害，因为在一种情况下，伪线会对拥塞做出充分响应，而在另一种情况下，伪线会因无法在损害相邻流之前提供可接受的服务而关闭。
Note: This document contains a large number of graphs that are necessary for its understanding, but could not be rendered in ASCII. It is strongly suggested that the PDF version be consulted.
注意：本文档包含大量理解所必需的图形，但无法以ASCII格式呈现。强烈建议参考PDF版本。
The following acronyms are used in this document:
本文件中使用了以下首字母缩略词：
AIS Alarm Indication Signal (see [G775])
AIS报警指示信号（见[G775]）
BER Bit Error Rate [G826]
误比特率[G826]
BW Bandwidth
带宽
CBR Constant Bit Rate
恒定比特率
ES Errored Second [G826]
ES错误秒[G826]
ESR Errored Second Rate [G826]
ESR错误二流[G826]
GRE Generic Routing Encapsulation [RFC2784]
GRE通用路由封装[RFC2784]
L2TPv3 Layer 2 Tunneling Protocol Version 3 [RFC3931]
L2TPv3第2层隧道协议版本3[RFC3931]
MOS Mean Opinion Score [P800]
MOS平均意见得分[P800]
MPLS Multiprotocol Label Switching [RFC3031]
MPLS多协议标签交换[RFC3031]
NSP Native Service Processing [RFC3985]
NSP本机服务处理[RFC3985]
PLR Packet Loss Ratio
丢包率
PSN Packet Switched Network [RFC3985]
PSN分组交换网络[RFC3985]
PW Pseudowire [RFC3985]
PW伪线[RFC3985]
SAToP Structure-Agnostic TDM over Packet [RFC4553]
数据包上的SAToP结构不可知TDM[RFC4553]
SES Severely Errored Seconds [G826]
SES严重错误秒[G826]
SESR Severely Errored Seconds Ratio [G826]
SESR严重错误秒数比[G826]
TCP Transmission Control Protocol
TCP传输控制协议
TDM Time Division Multiplexing [G703]
时分多路复用[G703]
UDP User Datagram Protocol
UDP用户数据报协议
In this section, we consider Ethernet PWs that primarily carry congestion-responsive traffic. We expand on the remark in Section 8 (Congestion Control) of [RFC4553], and show that the desired congestion avoidance behavior is automatically obtained and additional mechanisms are not needed.
在本节中，我们考虑Ethernet PWs主要携带拥塞响应流量。我们对[RFC4553]第8节（拥塞控制）中的注释进行了扩展，并表明所需的拥塞避免行为是自动获得的，并且不需要额外的机制。
Let us assume that an Ethernet PW aggregating several TCP flows is flowing alongside several TCP/IP flows. Each Ethernet PW packet carries a single Ethernet frame that carries a single IP packet that carries a single TCP segment. Thus, if congestion is signaled by an intermediate router dropping a packet, a single end-user TCP/IP packet is dropped, whether or not that packet is encapsulated in the PW.
让我们假设一个聚合了多个TCP流的以太网PW沿着多个TCP/IP流流动。每个以太网PW数据包携带一个以太网帧，该以太网帧携带一个IP数据包，该IP数据包携带一个TCP段。因此，如果中间路由器丢弃数据包发出拥塞信号，则丢弃单个最终用户TCP/IP数据包，而不管该数据包是否封装在PW中。
The result is that the individual TCP flows inside the PW experience the same drop probability as the non-PW TCP flows. Thus, the behavior of a TCP sender (retransmitting the packet and appropriately reducing its sending rate) is the same for flows directly over IP and for flows inside the PW. In other words, individual TCP flows are neither rewarded nor penalized for being carried over the PW. An elastic PW does not behave as a single TCP flow, as it will consume the aggregated bandwidth of its component flows; yet if its component TCP flows backs off by some percentage, the bandwidth of the PW as a whole will be reduced by the very same percentage, purely due to the combined effect of its component flows.
结果是，PW内的各个TCP流与非PW TCP流的丢弃概率相同。因此，对于直接通过IP的流和PW内部的流，TCP发送方的行为（重新传输数据包并适当降低其发送速率）是相同的。换句话说，单个TCP流在PW上的传输既不会受到奖励也不会受到惩罚。弹性PW不会表现为单个TCP流，因为它将消耗其组件流的聚合带宽；然而，如果其组件TCP流后退了一定百分比，那么PW作为一个整体的带宽将减少相同的百分比，这纯粹是由于其组件流的综合效应。
This is, of course, precisely the desired behavior. Were individual TCP flows rewarded for being carried over a PW, this would create an incentive to create PWs for no operational reason. Were individual flows penalized, there would be a deterrence that could impede pseudowire deployment.
当然，这正是我们想要的行为。如果单个TCP流因通过PW而获得奖励，这将产生一种无需操作原因而创建PW的激励。如果单个流量受到惩罚，则会产生阻碍伪线部署的威慑。
There have been proposals to add additional TCP-friendly mechanisms to PWs, for example by carrying PWs over DCCP. In light of the above arguments, it is clear that this would force the PW down to the bandwidth of a single flow, rather than N flows, and penalize the constituent TCP flows. In addition, the individual TCP flows would still back off due to their endpoints being oblivious to the fact that they are carried over a PW. This would further degrade the flow's throughput as compared to a non-PW-encapsulated flow, in contradiction to desirable behavior.
有人提议在PWs中添加额外的TCP友好机制，例如通过DCCP承载PWs。根据上述论点，很明显，这将迫使PW降低到单个流的带宽，而不是N个流，并惩罚组成TCP流。此外，单个TCP流仍然会后退，因为它们的端点忽略了它们通过PW传输的事实。与非PW封装流相比，这将进一步降低流的吞吐量，这与期望的行为相矛盾。
We have limited our treatment to the case of TCP traffic carried by Ethernet PWs (which are by far the most commonly deployed packet-carrying pseudowires), but it is not overly difficult to show that our result is equally valid for other PW types, such as ATM or frame-relay pseudowires.
我们将我们的处理局限于以太网PW承载的TCP流量的情况（到目前为止，以太网PW是最常用的包承载伪线），但要证明我们的结果对其他PW类型（如ATM或帧中继伪线）同样有效并不太困难。
Inelastic PWs, such as TDM PWs [RFC4553] [RFC5086] [RFC5087], are potentially more problematic than the elastic PWs of the previous section. As mentioned in Section 8 (Congestion Control) of [RFC4553], being constant bit rate (CBR), TDM PWs can't incrementally respond to congestion in a TCP-like fashion. On the other hand, being CBR, TDM PWs do not make things worse by attempting to capture additional bandwidth when neighboring TCP flows back off.
非弹性PWs，如TDM PWs[RFC4553][RFC5086][RFC5087]，可能比上一节中的弹性PWs问题更大。如[RFC4553]第8节（拥塞控制）所述，作为恒定比特率（CBR），TDM PWs不能以类似TCP的方式增量响应拥塞。另一方面，作为CBR，TDM PWs不会在相邻TCP流回退时试图捕获额外带宽，从而使情况变得更糟。
Since a TDM PW consumes a constant amount of bandwidth, if the bandwidth occupied by a TDM PW endangers the network as a whole, it might seem that the only recourse is to shut it down, denying service to all customers of the TDM native service. Nonetheless, under certain conditions it may be possible to reduce the bandwidth consumption of an emulated TDM service. A prevalent case is that of a TDM native service that carries voice channels that may not all be active. The ATM Adaptation Layer 2 (AAL2) mode of [RFC5087] (perhaps along with connection admission control) can enable bandwidth adaptation, at the expense of more sophisticated native service processing (NSP).
由于TDM PW消耗恒定数量的带宽，如果TDM PW占用的带宽危及整个网络，那么似乎唯一的办法是关闭它，拒绝向TDM本机服务的所有客户提供服务。然而，在某些条件下，可以减少模拟TDM服务的带宽消耗。一种常见的情况是TDM本机服务，它承载的语音信道可能并非全部处于活动状态。[RFC5087]的ATM适配层2（AAL2）模式（可能与连接许可控制一起）可以启用带宽适配，但代价是更复杂的本机服务处理（NSP）。
In the following, we will focus on structure-agnostic TDM PWs [RFC4553] although similar analysis can be readily applied to structure-aware PWs (see Appendix B). We will show that, for many cases of interest, a TDM PW, even when treated as a single flow, will behave in a reasonable manner without any additional mechanisms. We also show that, at the level of congestion when a TDM PW can no longer deliver acceptable TDM service, a single unconstrained TCP flow would typically still consume more capacity than a whole TDM PW. Therefore, to ensure that a TDM PW does not inflict significantly more harm than a TCP flow, it suffices to shut down a TDM PW that is persistently unable to deliver acceptable TDM service. This shutting down could be accomplished by employing a managed transport circuit breaker, by which we mean an automatic mechanism for terminating an unresponsive flow during persistently high levels of congestion [CIRCUIT-BREAKER]. Note that a transport circuit breaker is intended as a protection mechanism of last resort, just as an electrical circuit breaker is only triggered when absolutely necessary.
在下文中，我们将重点关注与结构无关的TDM PWs[RFC4553]，尽管类似的分析可以很容易地应用于结构感知PWs（见附录B）。我们将证明，对于许多感兴趣的情况，TDM PW，即使被视为单个流，也将以合理的方式运行，而不需要任何额外的机制。我们还表明，当TDM PW不再能够提供可接受的TDM服务时，在拥塞水平上，单个无约束TCP流通常仍会比整个TDM PW消耗更多的容量。因此，为了确保TDM PW不会造成比TCP流更大的伤害，关闭始终无法提供可接受TDM服务的TDM PW就足够了。这种关闭可以通过使用受管理的传输断路器来完成，我们的意思是在持续高水平的拥塞期间终止无响应流的自动机制[断路器]。请注意，运输断路器是作为最后手段的保护机制，正如只有在绝对必要时才会触发电气断路器一样。
For the avoidance of doubt, the above does not say that a TDM PW should be shut down when it becomes TCP-unfriendly. It merely says that the act of shutting down a TDM PW that can no longer deliver acceptable TDM service ensures that the PW does not contribute to congestion significantly more than a TCP flow would. Also, note that being unable to deliver acceptable TDM service for a short amount of time is insufficient justification for shutting down a TDM PW. While TCP flows react within a round-trip time, service commissioning and decommissioning are generally time-consuming processes that should only be undertaken when it becomes clear that the congestion is not transient.
为免生疑问，上面并没有说当TDM PW变得对TCP不友好时应该关闭。它只是说，关闭无法再提供可接受的TDM服务的TDM PW的行为确保了PW不会比TCP流对拥塞的贡献更大。此外，请注意，短时间内无法提供可接受的TDM服务不足以作为关闭TDM PW的理由。虽然TCP流在往返时间内作出反应，但服务调试和停用通常是耗时的过程，只有在明确拥塞不是暂时的情况下才应进行。
In order to quantitatively compare TDM PWs to TCP flows, we will compare the effect of TDM PW traffic with that of TCP traffic having the same packet size and delay. This is potentially an overly pessimistic comparison, as TDM PW packets are frequently configured to be short in order to minimize latency, while TCP packets are free to be much larger.
为了定量比较TDM PWs和TCP流，我们将比较TDM PW流量与具有相同数据包大小和延迟的TCP流量的影响。这可能是一个过于悲观的比较，因为TDM PW数据包经常被配置为短数据包以最小化延迟，而TCP数据包可以自由地大得多。
There are two network parameters relevant to our discussion, namely the one-way delay (D) and the packet loss ratio (PLR). The one-way delay of a native TDM service consists of the physical time-of-flight plus 125 microseconds for each TDM switch traversed, and is thus very small as compared to typical PSN network-crossing latencies. Since TDM services are designed with this low latency in mind, emulated TDM services are usually required to have similar low end-to-end delay. In our comparisons, we will only consider one-way delays of a few milliseconds.
有两个网络参数与我们的讨论相关，即单向延迟（D）和丢包率（PLR）。本机TDM服务的单向延迟由物理飞行时间加上每个经过的TDM交换机125微秒组成，因此与典型的PSN网络穿越延迟相比非常小。由于TDM服务的设计考虑到了这种低延迟，因此仿真TDM服务通常需要具有类似的低端到端延迟。在我们的比较中，我们只考虑几毫秒的单向延迟。
Regarding packet loss, the relevant RFCs specify actions to be carried out upon detecting a lost packet. Structure-agnostic transport has no alternative to outputting an "all-ones" Alarm Indication Signal (AIS) pattern towards the TDM circuit, which, when long enough in duration, is recognized by the receiving TDM device as a fault indication (see Appendix A). TDM standards (such as [G826]) place stringent limits on the number of such faults tolerated. Calculations presented in Appendix A show that only loss probabilities in the realm of fractions of a percent are relevant for structure-agnostic transport. Structure-aware transport regenerates frame alignment signals, thus avoiding AIS indications resulting from infrequent packet loss. Furthermore, for TDM circuits carrying voice channels, the use of packet loss concealment algorithms is possible (such algorithms have been previously described for TDM PWs). However, even structure-aware transport ceases to provide a useful service at about 2 percent loss probability. Hence, in our comparisons we will only consider PLRs of 1 or 2 percent.
关于分组丢失，相关rfc指定在检测到丢失分组时要执行的动作。结构不可知传输无法替代向TDM电路输出“全一”报警指示信号（AIS）模式，当持续时间足够长时，接收TDM设备将其识别为故障指示（见附录a）。TDM标准（如[G826]）对允许的此类故障数量进行了严格限制。附录A中给出的计算表明，只有百分之几的损失概率与结构不可知输运相关。结构感知传输重新生成帧对齐信号，从而避免因不频繁的数据包丢失而导致的AIS指示。此外，对于承载语音信道的TDM电路，分组丢失隐藏算法的使用是可能的（此类算法先前已针对TDM PWs描述）。然而，即使结构感知传输也会以大约2%的损失概率停止提供有用的服务。因此，在我们的比较中，我们只考虑PLR为1或2%。
TCP Friendly Rate Control (TFRC) [RFC5348] provides a simplified formula for TCP throughput as a function of round-trip delay and packet loss ratio.
TCP友好速率控制（TFRC）[RFC5348]提供了TCP吞吐量作为往返延迟和丢包率函数的简化公式。
S
X = ------------------------------------------------
R ( sqrt(2p/3) + 12 sqrt(3p/8) p (1+32p^2) )
S
X = ------------------------------------------------
R ( sqrt(2p/3) + 12 sqrt(3p/8) p (1+32p^2) )
where:
哪里：
X is the average sending rate in bytes per second,
X是平均发送速率，以字节/秒为单位，
S is the segment (packet payload) size in bytes,
S是以字节为单位的段（数据包有效负载）大小，
R is the round-trip time in seconds,
R是以秒为单位的往返时间，
p is the packet loss probability (i.e., PLR/100).
p是分组丢失概率（即，PLR/100）。
We can now compare the bandwidth consumed by TDM pseudowires with that of a TCP flow for a given packet loss ratio and one-way end-to-end delay (taken to be half the round-trip delay R). The results are depicted in the accompanying figures (available only in the PDF version of this document). In Figures 1 and 2, we see the conventional rate vs. packet loss plot for low-rate TDM (both T1 and E1) traffic, as well as TCP traffic with the same payload size (64 or 256 bytes respectively). Since the TDM rates are constant (T1 and E1 having payload throughputs of 1.544 Mbps and 2.048 Mbps respectively), and Structure-Agnostic TDM over packet (SAToP) can only faithfully emulate a TDM service up to a PLR of about half a percent, the T1 and E1 pseudowires occupy line segments on the graph. On the other hand, the TCP rate equation produces rate curves dependent on both one-way delay and packet loss.
我们现在可以比较TDM伪线与TCP流在给定丢包率和单向端到端延迟（取往返延迟R的一半）下消耗的带宽。结果如附图所示（仅在本文件的PDF版本中提供）。在图1和图2中，我们看到了低速TDM（T1和E1）流量以及具有相同负载大小（分别为64或256字节）的TCP流量的传统速率与丢包图。由于TDM速率是恒定的（T1和E1的有效负载吞吐量分别为1.544 Mbps和2.048 Mbps），并且结构不可知的分组TDM（SAToP）只能忠实地模拟高达约半个百分点PLR的TDM服务，T1和E1伪线占据图上的线段。另一方面，TCP速率方程产生的速率曲线依赖于单向延迟和数据包丢失。
For large packet sizes, short one-way delays, and low packet loss ratios, the TDM pseudowires typically consume much less bandwidth than TCP would under identical conditions. For small packets, long one-way delays, and high packet loss ratios, TDM PWs potentially consume more bandwidth, but only marginally. Furthermore, our "apples to apples" comparison forced the TCP traffic to use packets of sizes smaller than would be typical.
对于大数据包大小、短单向延迟和低数据包丢失率，TDM伪线通常比TCP在相同条件下消耗更少的带宽。对于小数据包、长单向延迟和高数据包丢失率，TDM PW可能会消耗更多带宽，但只消耗很少的带宽。此外，我们的“苹果对苹果”比较迫使TCP流量使用比通常更小的数据包。
Similarly, in Figures 3 and 4 we repeat the exercise for higher rate E3 and T3 (rates 34.368 and 44.736 Mbps respectively) pseudowires, allowing delays and PLRs suitable for these signals. We see that the TDM pseudowires consume much less bandwidth than TCP, for all reasonable parameter combinations.
类似地，在图3和图4中，我们对更高速率的E3和T3（速率分别为34.368和44.736 Mbps）伪线重复该练习，允许适合这些信号的延迟和PLR。我们发现，对于所有合理的参数组合，TDM伪线消耗的带宽比TCP少得多。
--------------------------------------------------------------------
I I
I I
I I
I I
I E1/T1 PWs vs. TCP for segment size 64B I
I I
I I
I I
I I
I (only in PDF version) I
I I
I I
I I
I I
I I
--------------------------------------------------------------------
--------------------------------------------------------------------
I I
I I
I I
I I
I E1/T1 PWs vs. TCP for segment size 64B I
I I
I I
I I
I I
I (only in PDF version) I
I I
I I
I I
I I
I I
--------------------------------------------------------------------
Figure 1: E1/T1 PWs vs. TCP for Segment Size 64B
图1:64B段大小的E1/T1 PWs与TCP
--------------------------------------------------------------------
I I
I I
I I
I I
I E1/T1 PWs vs. TCP for segment size 256B I
I I
I I
I I
I I
I (only in PDF version) I
I I
I I
I I
I I
I I
--------------------------------------------------------------------
--------------------------------------------------------------------
I I
I I
I I
I I
I E1/T1 PWs vs. TCP for segment size 256B I
I I
I I
I I
I I
I (only in PDF version) I
I I
I I
I I
I I
I I
--------------------------------------------------------------------
Figure 2: E1/T1 PWs vs. TCP for Segment Size 256B
图2:256B段大小的E1/T1 PWs与TCP
--------------------------------------------------------------------
I I
I I
I I
I I
I E3/T3 PWs vs. TCP for segment size 536B I
I I
I I
I I
I I
I (only in PDF version) I
I I
I I
I I
I I
I I
--------------------------------------------------------------------
--------------------------------------------------------------------
I I
I I
I I
I I
I E3/T3 PWs vs. TCP for segment size 536B I
I I
I I
I I
I I
I (only in PDF version) I
I I
I I
I I
I I
I I
--------------------------------------------------------------------
Figure 3: E3/T3 PWs vs. TCP for Segment Size 536B
图3:E3/T3 PWs与536B段大小的TCP
--------------------------------------------------------------------
I I
I I
I I
I I
I E3/T3 PWs vs. TCP for segment size 1024B I
I I
I I
I I
I I
I (only in PDF version) I
I I
I I
I I
I I
I I
--------------------------------------------------------------------
--------------------------------------------------------------------
I I
I I
I I
I I
I E3/T3 PWs vs. TCP for segment size 1024B I
I I
I I
I I
I I
I (only in PDF version) I
I I
I I
I I
I I
I I
--------------------------------------------------------------------
Figure 4: E3/T3 PWs vs. TCP for Segment Size 1024B
图4:E3/T3 PWs与段大小1024B的TCP
We can use the TCP rate equation to determine the precise conditions under which a TDM PW consumes no more bandwidth than a TCP flow between the same endpoints under identical conditions. Replacing the round-trip delay with twice the one-way delay D, setting the bandwidth to that of the TDM service BW, and the segment size to be the TDM fragment (taking into account the PWE3 control word), we obtain the following condition for a TDM PW:
我们可以使用TCP速率方程来确定TDM PW在相同条件下消耗的带宽不超过相同端点之间的TCP流的精确条件。将往返延迟替换为单向延迟D的两倍，将带宽设置为TDM服务BW的带宽，并将段大小设置为TDM片段（考虑PWE3控制字），我们获得TDM PW的以下条件：
4 S
D < -----------
BW f(p)
4 S
D < -----------
BW f(p)
where:
哪里：
D is the one-way delay,
D是单向延迟，
S is the TDM segment size (packet excluding overhead) in bytes,
S是TDM段大小（数据包不包括开销），单位为字节，
BW is the TDM service bandwidth in bits per second,
BW是TDM服务带宽，单位为比特/秒，
f(p) = sqrt(2p/3) + 12 sqrt(3p/8) p (1+32p^2).
f（p）=sqrt（2p/3）+12 sqrt（3p/8）p（1+32p^2）。
One may view this condition as defining a "friendly" operating envelope for a TDM PW, as a TDM PW that occupies no more bandwidth than a TCP flow causes no more congestion than that TCP flow. Under this condition, it is acceptable to place the TDM PW alongside congestion-responsive traffic such as TCP. On the other hand, were the TDM PW to consume significantly more bandwidth than a TCP flow, it could contribute disproportionately to congestion, and its mixture with congestion-responsive traffic might be inappropriate. Note that we are sidestepping any debate over the validity of the TCP-friendliness concept and merely saying that there can be no question that a TDM PW is acceptable if it causes no more congestion than a single TCP flow.
有人可能会认为这种情况定义了TDM PW的“友好”操作包络，即占用带宽不超过TCP流的TDM PW不会造成比TCP流更多的拥塞。在这种情况下，可以将TDM PW放置在拥塞响应流量（如TCP）旁边。另一方面，如果TDM PW比TCP流消耗更多的带宽，它可能会对拥塞产生不成比例的影响，并且它与拥塞响应流量的混合可能是不合适的。请注意，我们回避了关于TCP友好性概念有效性的任何辩论，只是说，如果TDM PW不会造成比单个TCP流更多的拥塞，那么它毫无疑问是可以接受的。
We derived this condition assuming steady-state conditions, and thus two caveats are in order. First, the condition does not specify how to treat a TDM PW that initially satisfies the condition, but is then faced with a deteriorating network environment. In such cases, one additionally needs to analyze the reaction times of the responsive flows to congestion events. Second, the derivation assumed that the TDM PW was competing with long-lived TCP flows, because under this assumption it was straightforward to obtain a quantitative comparison with something widely considered to offer a safe response to congestion. Short-lived TCP flows may find themselves disadvantaged as compared to a long-lived TDM PW satisfying the above condition.
我们在假设稳态条件的情况下导出了这个条件，因此有两个注意事项。首先，该条件没有规定如何处理最初满足该条件但随后面临恶化的网络环境的TDM PW。在这种情况下，还需要分析响应流对拥塞事件的反应时间。其次，该推导假设TDM PW与长寿命TCP流竞争，因为在该假设下，可以直接获得与广泛认为可提供安全拥塞响应的内容的定量比较。与满足上述条件的长寿命TDM PW相比，短命TCP流可能会发现自己处于不利地位。
We see in Figures 5 and 6 that TDM pseudowires carrying T1 or E1 native services satisfy the condition for all parameters of interest for large packet sizes (e.g., S=512 bytes of TDM data). For the SAToP default of 256 bytes, as long as the one-way delay is less than 10 milliseconds, the loss probability can exceed 0.3 or 0.6 percent. For packets containing 128 or 64 bytes, the constraints are more troublesome, but there are still parameter ranges where the TDM PW consumes less than a TCP flow under similar conditions. Similarly, Figures 7 and 8 demonstrate that E3 and T3 native services with the SAToP default of 1024 bytes of TDM per packet satisfy the condition for a broad spectrum of delays and PLRs.
我们在图5和图6中看到，承载T1或E1本机服务的TDM伪线满足大数据包大小的所有相关参数的条件（例如，S=512字节的TDM数据）。对于256字节的SAToP默认值，只要单向延迟小于10毫秒，丢失概率就可能超过0.3%或0.6%。对于包含128或64字节的数据包，约束更麻烦，但仍有参数范围，在类似条件下，TDM PW消耗的数据量小于TCP流。类似地，图7和图8表明，SAToP默认值为每个数据包1024字节TDM的E3和T3本机服务满足广谱延迟和PLR的条件。
--------------------------------------------------------------------
I I
I I
I I
I I
I T1 compatibility regions I
I I
I I
I I
I I
I (only in PDF version) I
I I
I I
I I
I I
I I
--------------------------------------------------------------------
--------------------------------------------------------------------
I I
I I
I I
I I
I T1 compatibility regions I
I I
I I
I I
I I
I (only in PDF version) I
I I
I I
I I
I I
I I
--------------------------------------------------------------------
Figure 5: TCP Compatibility Areas for T1 SAToP
图5:T1 SAToP的TCP兼容性区域
--------------------------------------------------------------------
I I
I I
I I
I I
I E1 compatibility regions I
I I
I I
I I
I I
I (only in PDF version) I
I I
I I
I I
I I
I I
--------------------------------------------------------------------
--------------------------------------------------------------------
I I
I I
I I
I I
I E1 compatibility regions I
I I
I I
I I
I I
I (only in PDF version) I
I I
I I
I I
I I
I I
--------------------------------------------------------------------
Figure 6: TCP Compatibility Areas for E1 SAToP
图6:E1 SAToP的TCP兼容性区域
--------------------------------------------------------------------
I I
I I
I I
I I
I E3 compatibility regions I
I I
I I
I I
I I
I (only in PDF version) I
I I
I I
I I
I I
I I
--------------------------------------------------------------------
--------------------------------------------------------------------
I I
I I
I I
I I
I E3 compatibility regions I
I I
I I
I I
I I
I (only in PDF version) I
I I
I I
I I
I I
I I
--------------------------------------------------------------------
Figure 7: TCP Compatibility Areas for E3 SAToP
图7:E3 SAToP的TCP兼容性区域
--------------------------------------------------------------------
I I
I I
I I
I I
I T3 compatibility regions I
I I
I I
I I
I I
I (only in PDF version) I
I I
I I
I I
I I
I I
--------------------------------------------------------------------
--------------------------------------------------------------------
I I
I I
I I
I I
I T3 compatibility regions I
I I
I I
I I
I I
I (only in PDF version) I
I I
I I
I I
I I
I I
--------------------------------------------------------------------
Figure 8: TCP Compatibility Areas for T3 SAToP
图8:T3 SAToP的TCP兼容性区域
The figures presented in the previous section demonstrate that TDM service quality degradation generally occurs before the TDM PW would consume more bandwidth than a comparable TCP flow. Thus, while TDM PWs are unable to respond to congestion in a TCP-like fashion, TDM PWs that are able to deliver acceptable TDM service do not contribute to congestion significantly more than a TCP flow.
上一节中给出的数字表明，TDM服务质量下降通常发生在TDM PW消耗比可比TCP流更多带宽之前。因此，虽然TDM PW无法以类似TCP的方式响应拥塞，但能够提供可接受的TDM服务的TDM PW对拥塞的影响并不比TCP流大得多。
Combined with our earlier determination that Ethernet PWs automatically respond in a TCP-like fashion (see Section 3), our final conclusion is that PW-specific congestion-avoidance mechanisms are generally not required. This is true even for TDM PWs, assuming that the TDM management plane initiates service shutdown when service parameters are persistently below levels required by the relevant TDM standards. If the TDM service does not automatically shut down, a mechanism to block persistently unacceptable TDM pseudowires is required, or a transport circuit breaker [CIRCUIT-BREAKER] may be triggered as a last resort.
结合我们先前确定的以太网PWs以类似TCP的方式自动响应（见第3节），我们的最终结论是，通常不需要特定于PW的拥塞避免机制。即使对于TDM PWs也是如此，假设当服务参数持续低于相关TDM标准要求的水平时，TDM管理平面启动服务关闭。如果TDM服务未自动关闭，则需要一种机制来阻止持续不可接受的TDM伪线，或者作为最后手段触发传输断路器[断路器]。
This document does not introduce any new congestion-specific mechanisms and thus does not introduce any new security considerations above those present for PWs in general.
本文件未引入任何新的拥塞特定机制，因此未引入任何新的安全注意事项，而不是PWs的一般安全注意事项。
[CIRCUIT-BREAKER] Fairhurst, G., "Network Transport Circuit Breakers", Work in Progress, draft-ietf-tsvwg-circuit-breaker-15, April 2016.
[CIRCUIT-BREAKER]Fairhurst，G.，“网络传输断路器”，正在进行的工作，草稿-ietf-tsvwg-CIRCUIT-BREAKER-15，2016年4月。
[G703] ITU-T, "Physical/electrical characteristics of hierarchical digital interfaces", ITU Recommendation G.703, April 2016.
[G703]ITU-T，“分层数字接口的物理/电气特性”，ITU建议G.703，2016年4月。
[G775] ITU-T, "Loss of Signal (LOS), Alarm Indication Signal (AIS) and Remote Defect Indication (RDI) defect detection and clearance criteria for PDH signals", ITU Recommendation G.775, October 1998.
[G775]ITU-T，“PDH信号的信号丢失（LOS）、报警指示信号（AIS）和远程缺陷指示（RDI）缺陷检测和清除标准”，ITU建议G.775，1998年10月。
[G826] ITU-T, "Error Performance Parameters and Objectives for International Constant Bit Rate Digital Paths at or above Primary Rate", ITU Recommendation G.826, December 2002.
[G826]ITU-T，“基本速率或以上国际恒定比特率数字路径的错误性能参数和目标”，ITU建议G.826，2002年12月。
[P50App1] ITU-T, "Telephone Transmission Quality, Telephone Installations, Local Line Networks: Appendix 1", ITU-T Recommendation P.50, February 1998.
[P50App1]ITU-T，“电话传输质量、电话安装、本地线路网络：附录1”，ITU-T建议第50页，1998年2月。
[P800] ITU-T, "Methods for subjective determination of transmission quality", ITU Recommendation P.800, June 1998.
[P800]ITU-T，“主观确定传输质量的方法”，ITU建议P.800，1998年6月。
[P862] ITU-T, "Perceptual evaluation of speech quality (PESQ): An objective method for end-to-end speech quality assessment of narrow-band telephone networks and speech codecs", ITU Recommendation P.826, February 2001.
[P862]ITU-T，“语音质量感知评估（PESQ）：窄带电话网络和语音编解码器端到端语音质量评估的客观方法”，ITU建议P.826，2001年2月。
[PACKET-LOSS] Stein, J(Y). and I. Druker, "The Effect of Packet Loss on Voice Quality for TDM over Pseudowires", Work in Progress, draft-stein-pwe3-tdm-packetloss-01, December 2003.
[分组丢失]Stein，J（Y）。和I.Druker，“包丢失对伪线TDM语音质量的影响”，正在进行的工作，draft-stein-pwe3-TDM-packetloss-01，2003年12月。
[RFC2784] Farinacci, D., Li, T., Hanks, S., Meyer, D., and P. Traina, "Generic Routing Encapsulation (GRE)", RFC 2784, DOI 10.17487/RFC2784, March 2000, <http://www.rfc-editor.org/info/rfc2784>.
[RFC2784]Farinaci，D.，Li，T.，Hanks，S.，Meyer，D.，和P.Traina，“通用路由封装（GRE）”，RFC 2784，DOI 10.17487/RFC27842000年3月<http://www.rfc-editor.org/info/rfc2784>.
[RFC2914] Floyd, S., "Congestion Control Principles", BCP 41, RFC 2914, DOI 10.17487/RFC2914, September 2000, <http://www.rfc-editor.org/info/rfc2914>.
[RFC2914]Floyd，S.，“拥塞控制原则”，BCP 41，RFC 2914，DOI 10.17487/RFC2914，2000年9月<http://www.rfc-editor.org/info/rfc2914>.
[RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol Label Switching Architecture", RFC 3031, DOI 10.17487/RFC3031, January 2001, <http://www.rfc-editor.org/info/rfc3031>.
[RFC3031]Rosen，E.，Viswanathan，A.，和R.Callon，“多协议标签交换体系结构”，RFC 3031，DOI 10.17487/RFC3031，2001年1月<http://www.rfc-editor.org/info/rfc3031>.
[RFC3931] Lau, J., Ed., Townsley, M., Ed., and I. Goyret, Ed., "Layer Two Tunneling Protocol - Version 3 (L2TPv3)", RFC 3931, DOI 10.17487/RFC3931, March 2005, <http://www.rfc-editor.org/info/rfc3931>.
[RFC3931]Lau，J.，Ed.，Townsley，M.，Ed.，和I.Goyret，Ed.，“第二层隧道协议-版本3（L2TPv3）”，RFC 3931，DOI 10.17487/RFC3931，2005年3月<http://www.rfc-editor.org/info/rfc3931>.
[RFC3985] Bryant, S., Ed. and P. Pate, Ed., "Pseudo Wire Emulation Edge-to-Edge (PWE3) Architecture", RFC 3985, DOI 10.17487/RFC3985, March 2005, <http://www.rfc-editor.org/info/rfc3985>.
[RFC3985]Bryant，S.，Ed.和P.Pate，Ed.，“伪线仿真边到边（PWE3）架构”，RFC 3985，DOI 10.17487/RFC3985，2005年3月<http://www.rfc-editor.org/info/rfc3985>.
[RFC4023] Worster, T., Rekhter, Y., and E. Rosen, Ed., "Encapsulating MPLS in IP or Generic Routing Encapsulation (GRE)", RFC 4023, DOI 10.17487/RFC4023, March 2005, <http://www.rfc-editor.org/info/rfc4023>.
[RFC4023]Worster，T.，Rekhter，Y.，和E.Rosen，编辑，“在IP或通用路由封装（GRE）中封装MPLS”，RFC 4023，DOI 10.17487/RFC4023，2005年3月<http://www.rfc-editor.org/info/rfc4023>.
[RFC4553] Vainshtein, A., Ed. and YJ. Stein, Ed., "Structure-Agnostic Time Division Multiplexing (TDM) over Packet (SAToP)", RFC 4553, DOI 10.17487/RFC4553, June 2006, <http://www.rfc-editor.org/info/rfc4553>.
[RFC4553]Vainstein，A.，Ed.和YJ。Stein，Ed.“数据包上的结构不可知时分复用（TDM）（SAToP）”，RFC 4553，DOI 10.17487/RFC4553，2006年6月<http://www.rfc-editor.org/info/rfc4553>.
[RFC5033] Floyd, S. and M. Allman, "Specifying New Congestion Control Algorithms", BCP 133, RFC 5033, DOI 10.17487/RFC5033, August 2007, <http://www.rfc-editor.org/info/rfc5033>.
[RFC5033]Floyd，S.和M.Allman，“指定新的拥塞控制算法”，BCP 133，RFC 5033，DOI 10.17487/RFC5033，2007年8月<http://www.rfc-editor.org/info/rfc5033>.
[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, DOI 10.17487/RFC5086, December 2007, <http://www.rfc-editor.org/info/rfc5086>.
[RFC5086]Vainstein，A.，Ed.，Sasson，I.，Metz，E.，Frost，T.，和P.Pate，“分组交换网络上的结构感知时分多路复用（TDM）电路仿真服务（CESoPSN）”，RFC 5086，DOI 10.17487/RFC5086，2007年12月<http://www.rfc-editor.org/info/rfc5086>.
[RFC5087] Stein, Y(J)., Shashoua, R., Insler, R., and M. Anavi, "Time Division Multiplexing over IP (TDMoIP)", RFC 5087, DOI 10.17487/RFC5087, December 2007, <http://www.rfc-editor.org/info/rfc5087>.
[RFC5087]Stein，Y（J.），Shashoua，R.，Insler，R.，和M.Anavi，“IP时分多路复用（TDMoIP）”，RFC 5087，DOI 10.17487/RFC5087，2007年12月<http://www.rfc-editor.org/info/rfc5087>.
[RFC5348] Floyd, S., Handley, M., Padhye, J., and J. Widmer, "TCP Friendly Rate Control (TFRC): Protocol Specification", RFC 5348, DOI 10.17487/RFC5348, September 2008, <http://www.rfc-editor.org/info/rfc5348>.
[RFC5348]Floyd，S.，Handley，M.，Padhye，J.，和J.Widmer，“TCP友好速率控制（TFRC）：协议规范”，RFC 5348，DOI 10.17487/RFC5348，2008年9月<http://www.rfc-editor.org/info/rfc5348>.
ITU-T Recommendation G.826 [G826] specifies limits on the Errored Second Ratio (ESR) and the Severely Errored Second Ratio (SESR). For our purposes, we will simplify the definitions and understand an Errored Second (ES) to be a second of time during which a TDM bit error occurred or a defect indication was detected. A Severely Errored Second (SES) is an ES second during which the Bit Error Rate (BER) exceeded one in one thousand (10^-3). Note that if the error condition AIS was detected according to the criteria of ITU-T Recommendation G.775 [G775], an SES was considered to have occurred. The respective ratios are the fraction of ES or SES to the total number of seconds in the measurement interval.
ITU-T建议G.826[G826]规定了错误二次比率（ESR）和严重错误二次比率（SESR）的限制。出于我们的目的，我们将简化定义，并将出错秒理解为发生TDM位错误或检测到缺陷指示的时间秒。严重错误秒（SES）是指误码率（BER）超过千分之一（10^-3）的ES秒。注意，如果根据ITU-T建议G.775[G775]的标准检测到错误条件AIS，则认为已发生SES。各自的比率是ES或SE与测量间隔内总秒数的分数。
All TDM signals run at 8000 frames per second (higher rate TDM signals have longer frames). So, assuming an integer number of TDM frames per TDM PW packet, the number of packets per second is given by packets per second = 8000 / (frames per packet). Prevalent cases are 1, 2, 4, and 8 frames per packet, translating to 8000, 4000, 2000, and 1000 packets per second, respectively.
所有TDM信号以每秒8000帧的速度运行（高速TDM信号具有更长的帧）。因此，假设每个TDM PW数据包的TDM帧数为整数，则每秒数据包数由每秒数据包数=8000/（每个数据包的帧数）给出。普遍的情况是每包1、2、4和8帧，分别转换为每秒8000、4000、2000和1000个包。
For both E1 and T1 TDM circuits, G.826 allows an ESR of 4% (0.04), and an SESR of 0.2% (0.002). For E3 and T3, the ESR must be no more than 7.5% (0.075), while the SESR is unchanged. Focusing on E1 circuits, the ESR of 4% translates (assuming the worst case of isolated exactly periodic packet loss) to a packet loss event no more than every 25 seconds. However, once a packet is lost, another packet lost in the same second doesn't change the ESR, although it may contribute to the ES becoming an SES. Thus for 1, 2, 4, and 8 frames per packet, the maximum allowed packet loss probability is 0.0005%, 0.001%, 0.002%, and 0.004% respectively.
对于E1和T1 TDM电路，G.826允许ESR为4%（0.04），SESR为0.2%（0.002）。对于E3和T3，ESR不得超过7.5%（0.075），而SESR不变。以E1电路为重点，4%的ESR转化为不超过每25秒一次的丢包事件（假设最坏的情况是完全周期性的孤立丢包）。然而，一旦一个数据包丢失，在同一秒内丢失的另一个数据包不会改变ESR，尽管它可能导致ES成为SES。因此，对于每个分组1、2、4和8帧，最大允许分组丢失概率分别为0.0005%、0.001%、0.002%和0.004%。
These extremely low allowed packet loss probabilities are only for the worst case scenario. With tail-drop buffers, when packet loss is above 0.001%, it is likely that loss bursts will occur. If the lost packets are sufficiently close together (we ignore the precise details here), then the permitted packet loss ratio increases by the appropriate factor, without G.826 being cognizant of any change. Hence, the worst-case analysis is expected to be extremely pessimistic for real networks. Next, we will consider the opposite extreme and assume that all packet loss events are in periodic loss bursts. In order to minimize the ESR, we will assume that the burst lasts no more than one second, and so we can afford to lose in each burst no more than the number of packets transmitted in one second. As long as such one-second bursts do not exceed four percent of the time, we still maintain the allowable ESR. Hence, the maximum
这些极低的允许丢包概率仅适用于最坏情况。对于尾部丢弃缓冲区，当数据包丢失超过0.001%时，很可能会发生丢失突发。如果丢失的数据包足够接近（我们忽略了此处的精确细节），则允许的数据包丢失率将以适当的系数增加，而G.826未意识到任何变化。因此，对于实际网络，最坏情况分析预计是极其悲观的。接下来，我们将考虑相反的极端，并假设所有分组丢失事件都是周期性的突发突发。为了最小化ESR，我们将假设突发持续时间不超过1秒，因此我们可以承受在每个突发中丢失的数据包数不超过1秒内传输的数据包数。只要这种1秒的爆发时间不超过4%，我们仍然保持允许的ESR。因此，最大
permissible packet loss ratio is 4%. Of course, this estimate is extremely optimistic, and furthermore does not take into consideration the SESR criteria.
允许的数据包丢失率为4%。当然，这一估计非常乐观，而且没有考虑SESR标准。
As previously explained, an SES is declared whenever AIS is detected. There is a major difference between structure-aware and structure-agnostic transport in this regards. When a packet is lost, SAToP outputs an "all-ones" pattern to the TDM circuit, which is interpreted as AIS according to G.775 [G775]. For E1 circuits, G.775 specifies that AIS is detected when four consecutive TDM frames have no more than 2 alternations. This means that if a PW packet or consecutive packets containing at least four frames are lost, and four or more frames of "all-ones" output to the TDM circuit, an SES will be declared. Thus burst packet loss, or packets containing a large number of TDM frames, lead SAToP to cause high SESR, which is 20 times more restricted than ESR. On the other hand, since structure-aware transport regenerates the correct frame alignment pattern, even when the corresponding packet has been lost, packet loss will not cause declaration of SES. This is the main reason that SAToP is much more vulnerable to packet loss than the structure-aware methods.
如前所述，只要检测到AIS，就会声明SES。在这方面，结构感知和结构不可知传输之间有一个主要区别。当数据包丢失时，SAToP向TDM电路输出“全一”模式，根据G.775[G775]将其解释为AIS。对于E1电路，G.775规定，当四个连续TDM帧的交替次数不超过2次时，检测AIS。这意味着，如果包含至少四个帧的PW分组或连续分组丢失，并且输出到TDM电路的四个或更多“全一”帧，则将声明SES。因此，突发数据包丢失或包含大量TDM帧的数据包导致SAToP导致高SESR，其限制比ESR高20倍。另一方面，由于结构感知传输重新生成正确的帧对齐模式，即使相应的分组丢失，分组丢失也不会导致SES声明。这是SAToP比结构感知方法更容易丢失数据包的主要原因。
For realistic networks, the maximum allowed packet loss for SAToP will be intermediate between the extremely pessimistic estimates and the extremely optimistic ones. In order to numerically gauge the situation, we have modeled the network as a four-state Markov model, (corresponding to a successfully received packet, a packet received within a loss burst, a packet lost within a burst, and a packet lost when not within a burst). This model is an extension of the widely used Gilbert model. We set the transition probabilities in order to roughly correspond to anecdotal evidence, namely low background isolated packet loss, and infrequent bursts wherein most packets are lost. Such simulation shows that up to 0.5% average packet loss may occur and the recovered TDM still conforms to the G.826 ESR and SESR criteria.
对于现实网络，SAToP允许的最大数据包丢失将介于极端悲观估计和极端乐观估计之间。为了从数值上衡量这种情况，我们将网络建模为四状态马尔可夫模型（对应于成功接收的数据包、丢失突发内接收的数据包、突发内丢失的数据包以及非突发内丢失的数据包）。该模型是广泛使用的吉尔伯特模型的扩展。我们设置了转移概率，以便大致对应于轶事证据，即低背景孤立数据包丢失，以及大多数数据包丢失的不频繁突发。这样的模拟表明，可能发生高达0.5%的平均分组丢失，并且恢复的TDM仍然符合G.826 ESR和SESR标准。
Appendix B. Effect of Packet Loss on Voice Quality for Structure-Aware TDM PWs
附录B.包丢失对结构感知TDM PWs语音质量的影响
Packet loss in voice traffic causes audio artifacts such as choppy, annoying, or even unintelligible speech. The precise effect of packet loss on voice quality has been the subject of detailed study in the Voice over IP (VoIP) community, but VoIP results are not directly applicable to TDM PWs. This is because VoIP packets typically contain over 10 milliseconds of the speech signal, while multichannel TDM packets may contain only a single sample, or perhaps a very small number of samples.
语音通信中的数据包丢失会导致音频伪影，如断断续续、烦人甚至无法理解的语音。分组丢失对语音质量的精确影响一直是IP语音（VoIP）社区详细研究的主题，但VoIP结果并不直接适用于TDM PWs。这是因为VoIP数据包通常包含超过10毫秒的语音信号，而多信道TDM数据包可能只包含一个样本，或者可能包含非常少的样本。
The effect of packet loss on TDM PWs has been previously reported [PACKET-LOSS]. In that study, it was assumed that each packet carried a single sample of each TDM timeslot (although the extension to multiple samples is relatively straightforward and does not drastically change the results). Four sample replacement algorithms were compared, differing in the value used to replace the lost sample:
先前已经报告了分组丢失对TDM PWs的影响[分组丢失]。在该研究中，假设每个数据包携带每个TDM时隙的单个样本（尽管扩展到多个样本相对简单，并且不会显著改变结果）。比较了四种样本替换算法，用于替换丢失样本的值不同：
1. Replacing every lost sample by a preselected constant (e.g., zero or "AIS" insertion).
1. 用预选常量（例如，零或“AIS”插入）替换每个丢失的样本。
2. Replacing a lost sample by the previous sample.
2. 用以前的样本替换丢失的样本。
3. Replacing a lost sample by linear interpolation between the previous and following samples.
3. 用前一个和后一个样本之间的线性插值替换丢失的样本。
4. Replacing the lost sample by STatistically Enhanced INterpolation (STEIN).
4. 通过统计增强插值（STEIN）替换丢失的样本。
Only the first method is applicable to SAToP transport, as structure awareness is required in order to identify the individual voice channels. For structure-aware transport, the loss of a packet is typically identified by the receipt of the following packet, and thus the following sample is usually available. The last algorithm posits the Linear-Predictive Coding (LPC) speech generation model and derives lost samples based on available samples both before and after each lost sample.
只有第一种方法适用于SAToP传输，因为识别单个语音信道需要结构感知。对于结构感知传输，数据包的丢失通常通过接收下一个数据包来识别，因此下一个样本通常可用。最后一种算法假定线性预测编码（LPC）语音生成模型，并根据每个丢失样本之前和之后的可用样本推导丢失样本。
The four algorithms were compared in a controlled experiment in which speech data was selected from English and American English subsets of the ITU-T P.50 Appendix 1 corpus [P50App1] and consisted of 16 speakers, eight male and eight female. Each speaker spoke either three or four sentences, for a total of between seven and 15 seconds. The selected files were filtered to telephony quality using modified IRS filtering and down-sampled to 8 kHz. Packet loss of 0, 0.25, 0.5, 0.75, 1, 2, 3, 4, and 5 percent were simulated using a uniform random number generator (bursty packet loss was also simulated but is not reported here). For each file, the four methods of lost sample replacement were applied and the Mean Opinion Score (MOS) was estimated using PESQ [P862]. Figure 9 depicts the PESQ-derived MOS for each of the four replacement methods for packet drop probabilities up to 5%.
这四种算法在一个对照实验中进行了比较，实验中的语音数据来自ITU-T P.50附录1语料库[P50App1]的英语和美语子集，由16名发言者组成，其中8名男性和8名女性。每个发言者讲了三句或四句话，总共7至15秒。使用改进的IRS过滤将所选文件过滤至电话质量，并向下采样至8 kHz。使用均匀随机数发生器模拟0、0.25、0.5、0.75、1、2、3、4和5%的数据包丢失（也模拟了突发数据包丢失，但此处未报告）。对于每个文件，采用四种丢失样本替换方法，并使用PESQ估算平均意见得分（MOS）[P862]。图9描述了四种替换方法中每种方法的PESQ衍生MOS，丢包概率高达5%。
--------------------------------------------------------------------
I I
I I
I I
I I
I I
I I
I PESQ-MOS as a function of packet drop probability I
I I
I I
I I
I I
I (only in PDF version) I
I I
I I
I I
I I
I I
I I
I I
--------------------------------------------------------------------
--------------------------------------------------------------------
I I
I I
I I
I I
I I
I I
I PESQ-MOS as a function of packet drop probability I
I I
I I
I I
I I
I (only in PDF version) I
I I
I I
I I
I I
I I
I I
I I
--------------------------------------------------------------------
Figure 9: PESQ-Derived MOS as a Function of Packet-Drop Probability
图9:PESQ导出的MOS作为丢包概率的函数
For all cases, the MOS resulting from the use of zero insertion is less than that obtained by replacing with the previous sample, which in turn is less than that of linear interpolation, which is slightly less than that obtained by statistical interpolation.
在所有情况下，使用零插入产生的MOS小于通过替换前一个样本获得的MOS，后者又小于线性插值，后者略小于通过统计插值获得的MOS。
Unlike the artifacts that speech compression methods may produce when subject to buffer loss, packet loss here effectively produces additive white impulse noise. The subjective impression is that of static noise on AM radio stations or crackling on old phonograph records. For a given PESQ-derived MOS, this type of degradation is more acceptable to listeners than choppiness or tones common in VoIP.
与语音压缩方法在缓冲区丢失时可能产生的伪影不同，这里的分组丢失有效地产生加性白脉冲噪声。主观印象是调幅电台上的静态噪音或旧唱片上的噼啪声。对于给定的PESQ派生MOS，这种类型的降级比VoIP中常见的断断续续或音调更容易被听众接受。
If MOS>4 (full toll quality) is required, then the following packet drop probabilities are allowable:
如果需要MOS>4（全长途质量），则允许以下分组丢弃概率：
zero insertion - 0.05%
零插入-0.05%
previous sample - 0.25%
以前的样本-0.25%
linear interpolation - 0.75%
线性插值-0.75%
STEIN - 2%
斯坦因-2%
If MOS>3.75 (barely perceptible quality degradation) is acceptable, then the following packet drop probabilities are allowable:
如果MOS>3.75（几乎感觉不到质量下降）是可接受的，则允许以下分组丢弃概率：
zero insertion - 0.1%
零插入-0.1%
previous sample - 0.75%
以前的样本-0.75%
linear interpolation - 3%
线性插值-3%
STEIN - 6.5%
斯坦-6.5%
If MOS>3.5 (cell phone quality) is tolerable, then the following packet drop probabilities are allowable:
如果MOS>3.5（手机质量）是可容忍的，则允许以下丢包概率：
zero insertion - 0.4%
零插入-0.4%
previous sample - 2%
以前的样本-2%
linear interpolation - 8%
线性插值-8%
STEIN - 14%
斯坦因-14%
Authors' Addresses
作者地址
Yaakov (Jonathan) Stein RAD Data Communications 24 Raoul Wallenberg St., Bldg C Tel Aviv 69719 Israel
以色列特拉维夫C栋拉乌尔沃伦堡大街24号雅科夫（乔纳森）斯坦无线电数据通信公司，邮编69719
Phone: +972 (0)3 645-5389
Email: yaakov_s@rad.com
Phone: +972 (0)3 645-5389
Email: yaakov_s@rad.com
David L. Black EMC Corporation 176 South St. Hopkinton, MA 69719 United States
David L.Black EMC公司美国马萨诸塞州霍普金顿南大街176号，邮编69719
Phone: +1 (508) 293-7953
Email: david.black@emc.com
Phone: +1 (508) 293-7953
Email: david.black@emc.com
Bob Briscoe BT
鲍勃·布里斯科英国电信
Email: ietf@bobbriscoe.net
URI: http://bobbriscoe.net/
Email: ietf@bobbriscoe.net
URI: http://bobbriscoe.net/