Internet Engineering Task Force (IETF) G. Fairhurst
Request for Comments: 8084 University of Aberdeen
BCP: 208 March 2017
Category: Best Current Practice
ISSN: 2070-1721
Internet Engineering Task Force (IETF) G. Fairhurst
Request for Comments: 8084 University of Aberdeen
BCP: 208 March 2017
Category: Best Current Practice
ISSN: 2070-1721
Network Transport Circuit Breakers
网络传输断路器
Abstract
摘要
This document explains what is meant by the term "network transport Circuit Breaker". It describes the need for Circuit Breakers (CBs) for network tunnels and applications when using non-congestion-controlled traffic and explains where CBs are, and are not, needed. It also defines requirements for building a CB and the expected outcomes of using a CB within the Internet.
本文件解释了术语“网络传输断路器”的含义。它描述了使用非拥塞控制流量时网络隧道和应用程序对断路器（CBs）的需求，并解释了哪里需要CBs，哪里不需要CBs。它还定义了构建CB的要求以及在互联网中使用CB的预期结果。
Status of This Memo
关于下段备忘
This memo documents an Internet Best Current Practice.
本备忘录记录了互联网最佳实践。
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). Further information on BCPs is available in Section 2 of RFC 7841.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。有关BCP的更多信息，请参见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/rfc8084.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc8084.
Copyright Notice
版权公告
Copyright (c) 2017 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2017 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 ....................................................2
1.1. Types of CBs ...............................................5
2. Terminology .....................................................6
3. Design of a CB (What makes a good CB?) ..........................6
3.1. Functional Components ......................................6
3.2. Other Network Topologies ...................................9
3.2.1. Use with a Multicast Control/Routing Protocol ......10
3.2.2. Use with Control Protocols Supporting
Pre-provisioned Capacity ...........................11
3.2.3. Unidirectional CBs over Controlled Paths ...........11
4. Requirements for a Network Transport CB ........................12
5. Examples of CBs ................................................15
5.1. A Fast-Trip CB ............................................15
5.1.1. A Fast-Trip CB for RTP .............................16
5.2. A Slow-Trip CB ............................................16
5.3. A Managed CB ..............................................17
5.3.1. A Managed CB for SAToP Pseudowires .................17
5.3.2. A Managed CB for Pseudowires (PWs) .................18
6. Examples in Which CBs May Not Be Needed ........................19
6.1. CBs over Pre-provisioned Capacity .........................19
6.2. CBs with Tunnels Carrying Congestion-Controlled Traffic ...19
6.3. CBs with Unidirectional Traffic and No Control Path .......20
7. Security Considerations ........................................20
8. References .....................................................22
8.1. Normative References ......................................22
8.2. Informative References ....................................22
Acknowledgments ...................................................24
Author's Address ..................................................24
1. Introduction ....................................................2
1.1. Types of CBs ...............................................5
2. Terminology .....................................................6
3. Design of a CB (What makes a good CB?) ..........................6
3.1. Functional Components ......................................6
3.2. Other Network Topologies ...................................9
3.2.1. Use with a Multicast Control/Routing Protocol ......10
3.2.2. Use with Control Protocols Supporting
Pre-provisioned Capacity ...........................11
3.2.3. Unidirectional CBs over Controlled Paths ...........11
4. Requirements for a Network Transport CB ........................12
5. Examples of CBs ................................................15
5.1. A Fast-Trip CB ............................................15
5.1.1. A Fast-Trip CB for RTP .............................16
5.2. A Slow-Trip CB ............................................16
5.3. A Managed CB ..............................................17
5.3.1. A Managed CB for SAToP Pseudowires .................17
5.3.2. A Managed CB for Pseudowires (PWs) .................18
6. Examples in Which CBs May Not Be Needed ........................19
6.1. CBs over Pre-provisioned Capacity .........................19
6.2. CBs with Tunnels Carrying Congestion-Controlled Traffic ...19
6.3. CBs with Unidirectional Traffic and No Control Path .......20
7. Security Considerations ........................................20
8. References .....................................................22
8.1. Normative References ......................................22
8.2. Informative References ....................................22
Acknowledgments ...................................................24
Author's Address ..................................................24
The term "Circuit Breaker" originates in electricity supply, and has nothing to do with network circuits or virtual circuits. In electricity supply, a Circuit Breaker (CB) is intended as a protection mechanism of last resort. Under normal circumstances, a CB ought not to be triggered; it is designed to protect the supply network and attached equipment when there is overload. People do not expect an electrical CB (or fuse) in their home to be triggered, except when there is a wiring fault or a problem with an electrical appliance.
“断路器”一词起源于电力供应，与网络电路或虚拟电路无关。在电力供应中，断路器（CB）是作为最后手段的保护机制。在正常情况下，不应触发CB；设计用于过载时保护供电网络和附属设备。人们不希望家里的电路断路器（或保险丝）被触发，除非是在线路故障或电器出现问题时。
In networking, the CB principle can be used as a protection mechanism of last resort to avoid persistent excessive congestion impacting other flows that share network capacity. Persistent congestion was a feature of the early Internet of the 1980s. This resulted in excess traffic starving other connections from access to the Internet. It
在网络中，CB原则可用作最后的保护机制，以避免持续过度拥塞影响共享网络容量的其他流。持续的拥塞是20世纪80年代早期互联网的一个特点。这导致过多的流量导致其他连接无法访问Internet。信息技术
was countered by the requirement to use congestion control (CC) in the Transmission Control Protocol (TCP) [Jacobson88]. These mechanisms operate in Internet hosts to cause TCP connections to "back off" during congestion. The addition of a congestion control to TCP (currently documented in [RFC5681]) ensured the stability of the Internet, because it was able to detect congestion and promptly react. This was effective in an Internet where most TCP flows were long lived (ensuring that they could detect and respond to congestion before the flows terminated). Although TCP was, by far, the dominant traffic, this is no longer the always the case, and non-congestion-controlled traffic, including many applications using the User Datagram Protocol (UDP), can form a significant proportion of the total traffic traversing a link. To avoid persistent excessive congestion, the current Internet therefore requires consideration of the way that non-congestion-controlled traffic is forwarded.
在传输控制协议（TCP）中使用拥塞控制（CC）[Jacobson88]的要求与此相反。这些机制在Internet主机中运行，导致TCP连接在拥塞期间“后退”。将拥塞控制添加到TCP（目前记录在[RFC5681]中）确保了互联网的稳定性，因为它能够检测到拥塞并迅速做出反应。这在大多数TCP流都是长寿命的Internet中是有效的（确保它们能够在流终止之前检测并响应拥塞）。尽管到目前为止，TCP是主要流量，但情况已不再总是这样，非拥塞控制流量（包括许多使用用户数据报协议（UDP）的应用程序）可以在通过链路的总流量中占很大比例。为了避免持续的过度拥塞，当前的互联网需要考虑非拥塞控制流量的转发方式。
A network transport CB is an automatic mechanism that is used to continuously monitor a flow or aggregate set of flows. The mechanism seeks to detect when the flow(s) experience persistent excessive congestion. When this is detected, a CB terminates (or significantly reduces the rate of) the flow(s). This is a safety measure to prevent starvation of network resources denying other flows from access to the Internet. Such measures are essential for an Internet that is heterogeneous and for traffic that is hard to predict in advance. Avoiding persistent excessive congestion is important to reduce the potential for "Congestion Collapse" [RFC2914].
网络传输CB是一种自动机制，用于连续监视流或流集合。该机制试图检测流何时经历持续过度拥塞。当检测到这种情况时，CB终止（或显著降低）流量。这是一种安全措施，用于防止网络资源不足，从而阻止其他流量访问Internet。这些措施对于异构的互联网和难以提前预测的流量至关重要。避免持续过度拥塞对于降低“拥塞崩溃”的可能性非常重要[RFC2914]。
There are important differences between a transport CB and a congestion control method. Congestion control (as implemented in TCP, Stream Control Transmission Protocol (SCTP), and Datagram Congestion Control Protocol (DCCP)) operates on a timescale on the order of a packet Round-Trip Time (RTT): the time from sender to destination and return. Congestion at a network link can also be detected using Explicit Congestion Notification (ECN) [RFC3168], which allows the network to signal congestion by marking ECN-capable packets with a Congestion Experienced (CE) mark. Both loss and reception of CE-marked packets are treated as congestion events. Congestion control methods are able to react to a congestion event by continuously adapting to reduce their transmission rate. The goal is usually to limit the transmission rate to a maximum rate that reflects a fair use of the available capacity across a network path. These methods typically operate on individual traffic flows (e.g., a 5-tuple that includes the IP addresses, protocol, and ports).
传输CB和拥塞控制方法之间存在着重要的区别。拥塞控制（在TCP、流控制传输协议（SCTP）和数据报拥塞控制协议（DCCP）中实现）在时间尺度上以数据包往返时间（RTT）的顺序运行：从发送方到目的地和返回的时间。还可以使用显式拥塞通知（ECN）[RFC3168]来检测网络链路上的拥塞，该通知允许网络通过使用拥塞经历（CE）标记来标记支持ECN的数据包来发出拥塞信号。CE标记数据包的丢失和接收都被视为拥塞事件。拥塞控制方法能够对拥塞事件做出反应，通过不断调整来降低传输速率。目标通常是将传输速率限制在最大速率，以反映网络路径上可用容量的合理使用。这些方法通常对单个流量（例如，包括IP地址、协议和端口的5元组）进行操作。
In contrast, CBs are recommended for non-congestion-controlled Internet flows and for traffic aggregates, e.g., traffic sent using a network tunnel. They operate on timescales much longer than the packet RTT, and trigger under situations of abnormal (excessive)
相反，对于非拥塞控制的互联网流和流量聚合（例如，使用网络隧道发送的流量），建议使用CBs。它们在比分组RTT更长的时间尺度上运行，并在异常（过度）情况下触发
congestion. People have been implementing what this document characterizes as CBs on an ad hoc basis to protect Internet traffic. This document therefore provides guidance on how to deploy and use these mechanisms. Later sections provide examples of cases where CBs may or may not be desirable.
拥塞人们已经在临时基础上实施了本文件所描述的CBs，以保护互联网流量。因此，本文件就如何部署和使用这些机制提供了指导。后面的章节提供了CBs可能可取或不可取的案例示例。
A CB needs to measure (meter) some portion of the traffic to determine if the network is experiencing congestion and needs to be designed to trigger robustly when there is persistent excessive congestion.
CB需要测量（计量）部分流量，以确定网络是否遇到拥塞，并且需要设计为在持续过度拥塞时可靠触发。
A CB trigger will often utilize a series of successive sample measurements metered at an ingress point and an egress point (either of which could be a transport endpoint). The trigger needs to operate on a timescale much longer than the path RTT (e.g., seconds to possibly many tens of seconds). This longer period is needed to provide sufficient time for transport congestion control or applications to adjust their rate following congestion, and for the network load to stabilize after any adjustment. Congestion events can be common when a congestion-controlled transport is used over a network link operating near capacity. Each event results in reduction in the rate of the transport flow experiencing congestion. The longer period seeks to ensure that a CB is not accidentally triggered following a single (or even successive) congestion event(s).
CB触发器通常会利用在入口点和出口点（其中任何一个都可能是传输端点）测量的一系列连续样本测量。触发器需要在比路径RTT长得多的时间尺度上运行（例如，秒到几十秒）。这段较长的时间需要为交通拥塞控制或应用程序提供充足的时间，以便在拥塞后调整其速率，并在任何调整后使网络负载稳定下来。当在接近容量的网络链路上使用拥塞控制传输时，拥塞事件可能很常见。每一个事件都会导致交通拥堵率的降低。较长的周期旨在确保CB不会在单个（甚至连续）拥塞事件后意外触发。
Once triggered, the CB needs to provide a control function (called the "reaction"). This removes traffic from the network, either by disabling the flow or by significantly reducing the level of traffic. This reaction provides the required protection to prevent persistent excessive congestion being experienced by other flows that share the congested part of the network path.
一旦触发，CB需要提供控制功能（称为“反应”）。这将通过禁用流量或显著降低流量级别从网络中删除流量。此反应提供所需的保护，以防止共享网络路径拥塞部分的其他流经历持续过度拥塞。
Section 4 defines requirements for building a CB.
第4节定义了建造CB的要求。
The operational conditions that cause a CB to trigger ought to be regarded as abnormal. Examples of situations that could trigger a CB include:
导致CB触发的操作条件应视为异常。可能触发CB的情况示例包括：
o anomalous traffic that exceeds the provisioned capacity (or whose traffic characteristics exceed the threshold configured for the CB);
o 超出配置容量的异常流量（或其流量特性超过为CB配置的阈值）；
o traffic generated by an application at a time when the provisioned network capacity is being utilized for other purposes;
o 当所提供的网络容量正被用于其他目的时由应用程序生成的业务量；
o routing changes that cause additional traffic to start using the path monitored by the CB;
o 导致额外流量开始使用CB监控的路径的路由更改；
o misconfiguration of a service/network device where the capacity available is insufficient to support the current traffic aggregate;
o 服务/网络设备配置错误，可用容量不足以支持当前流量聚合；
o misconfiguration of an admission controller or traffic policer that allows more traffic than expected across the path monitored by the CB.
o 准入控制器或交通警察配置错误，允许超过CB监控路径预期的交通量。
Other mechanisms could also be available to network operators to detect excessive congestion (e.g., an observation of excessive utilization for a port on a network device). Utilizing such information, operational mechanisms could react to reduce network load over a shorter timescale than those of a network transport CB. The role of the CB over such paths remains as a method of last resort. Because it acts over a longer timescale, the CB ought to be triggered only when other reactions did not succeed in reducing persistent excessive congestion.
网络运营商也可以使用其他机制来检测过度拥塞（例如，观察网络设备上端口的过度利用）。利用这些信息，操作机制可以在比网络传输机制更短的时间尺度上作出反应以减少网络负载。CB在这些路径上的作用仍然是最后手段。由于CB的作用时间较长，因此只有在其他反应未能成功减少持续过度拥塞时，才应触发CB。
In many cases, the reason for triggering a CB will not be evident to the source of the traffic (user, application, endpoint, etc.). A CB can be used to limit traffic from applications that are unable, or choose not, to use congestion control or in cases in which the congestion control properties of the traffic cannot be relied upon (e.g., traffic carried over a network tunnel). In such circumstances, it is all but impossible for the CB to signal back to the impacted applications. In some cases, applications could therefore have difficulty in determining that a CB has been triggered and where in the network this happened.
在许多情况下，触发CB的原因对于通信源（用户、应用程序、端点等）来说并不明显。CB可用于限制来自无法或选择不使用拥塞控制的应用程序的流量，或在无法依赖流量的拥塞控制属性的情况下（例如，通过网络隧道传输的流量）。在这种情况下，CB几乎不可能向受影响的应用程序发回信号。因此，在某些情况下，应用程序可能难以确定CB是否已被触发以及在网络中的何处发生。
Application developers are therefore advised, where possible, to deploy appropriate congestion control mechanisms. An application that uses congestion control will be aware of congestion events in the network. This allows it to regulate the network load under congestion, and it is expected to avoid triggering a network CB. For applications that can generate elastic traffic, this will often be a preferred solution.
因此，建议应用程序开发人员在可能的情况下部署适当的拥塞控制机制。使用拥塞控制的应用程序将了解网络中的拥塞事件。这使得它能够在拥塞情况下调节网络负载，并有望避免触发网络CB。对于能够生成弹性流量的应用程序，这通常是首选解决方案。
There are various forms of network transport CBs. These are differentiated mainly on the timescale over which they are triggered, but also in the intended protection they offer:
有各种形式的网络传输CBs。它们的区别主要在于触发它们的时间尺度，但也在于它们提供的预期保护：
o Fast-Trip CBs: The relatively short timescale used by this form of CB is intended to provide protection for network traffic from a single flow or related group of flows.
o 快速行程CBs：这种CB形式使用的相对较短的时间尺度旨在为来自单个流或相关流组的网络流量提供保护。
o Slow-Trip CBs: This CB utilizes a longer timescale and is designed to protect network traffic from congestion by traffic aggregates.
o 慢行程CBs：该CBs利用更长的时间尺度，旨在保护网络流量不受流量聚集造成的拥塞影响。
o Managed CBs: Utilize the operations and management functions that might be present in a managed service to implement a CB.
o 托管CB：利用托管服务中可能存在的操作和管理功能来实现CB。
Examples of each type of CB are provided in Section 4.
第4节提供了每种类型CB的示例。
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 CBs have been talked about in the IETF for many years, there has not yet been guidance on the cases where CBs are needed or upon the design of CB mechanisms. This document seeks to offer advice on these two topics.
尽管IETF多年来一直在讨论CBs，但尚未就需要CBs的情况或CB机制的设计提供指导。本文件旨在就这两个主题提供建议。
CBs are RECOMMENDED for IETF protocols and tunnels that carry non-congestion-controlled Internet flows and for traffic aggregates. This includes traffic sent using a network tunnel. Designers of other protocols and tunnel encapsulations also ought to consider the use of these techniques as a last resort to protect traffic that shares the network path being used.
建议将CBs用于承载非拥塞控制互联网流的IETF协议和隧道以及流量聚合。这包括使用网络隧道发送的流量。其他协议和隧道封装的设计者也应该考虑使用这些技术作为保护共享网络路径的流量的最后手段。
This document defines the requirements for the design of a CB and provides examples of how a CB can be constructed. The specifications of individual protocols and tunnel encapsulations need to detail the protocol mechanisms needed to implement a CB.
本文件规定了断路器的设计要求，并提供了如何建造断路器的示例。各个协议和隧道封装的规范需要详细说明实现CB所需的协议机制。
Section 3.1 describes the functional components of a CB and Section 3.2 defines requirements for implementing a CB.
第3.1节描述了CB的功能组件，第3.2节定义了实施CB的要求。
The basic design of a CB involves communication between an ingress point (a sender) and an egress point (a receiver) of a network flow or set of flows. A simple picture of operation is provided in Figure 1. This shows a set of routers (each labeled R) connecting a set of endpoints.
CB的基本设计涉及网络流或一组流的入口点（发送方）和出口点（接收方）之间的通信。图1提供了操作的简单图片。这显示了连接一组端点的一组路由器（每个路由器都标有R）。
A CB is used to control traffic passing through a subset of these routers, acting between the ingress and a egress point network devices. The path between the ingress and egress could be provided by a tunnel or other network-layer technique. One expected use would
CB用于控制通过这些路由器子集的流量，在入口和出口点网络设备之间起作用。入口和出口之间的路径可以由隧道或其他网络层技术提供。一个预期用途是
be at the ingress and egress of a service, where all traffic being considered terminates beyond the egress point; hence, the ingress and egress carry the same set of flows.
处于服务的入口和出口处，其中所有被认为的流量终止于出口点之外；因此，入口和出口携带相同的一组流。
+--------+ +--------+
|Endpoint| |Endpoint|
+--+-----+ >>> circuit breaker traffic >>> +--+-----+
| |
| +-+ +-+ +---------+ +-+ +-+ +-+ +--------+ +-+ +-+ |
+-+R+--+R+->+ Ingress +--+R+--+R+--+R+--+ Egress |--+R+--+R+-+
+++ +-+ +------+--+ +-+ +-+ +-+ +-----+--+ +++ +-+
| ^ | | |
| | +--+------+ +------+--+ |
| | | Ingress | | Egress | |
| | | Meter | | Meter | |
| | +----+----+ +----+----+ |
| | | | |
+-+ | | +----+----+ | | +-+
|R+--+ | | Measure +<----------------+ +--+R|
+++ | +----+----+ Reported +++
| | | Egress |
| | +----+----+ Measurement |
+--+-----+ | | Trigger + +--+-----+
|Endpoint| | +----+----+ |Endpoint|
+--------+ | | +--------+
+---<---+
Reaction
+--------+ +--------+
|Endpoint| |Endpoint|
+--+-----+ >>> circuit breaker traffic >>> +--+-----+
| |
| +-+ +-+ +---------+ +-+ +-+ +-+ +--------+ +-+ +-+ |
+-+R+--+R+->+ Ingress +--+R+--+R+--+R+--+ Egress |--+R+--+R+-+
+++ +-+ +------+--+ +-+ +-+ +-+ +-----+--+ +++ +-+
| ^ | | |
| | +--+------+ +------+--+ |
| | | Ingress | | Egress | |
| | | Meter | | Meter | |
| | +----+----+ +----+----+ |
| | | | |
+-+ | | +----+----+ | | +-+
|R+--+ | | Measure +<----------------+ +--+R|
+++ | +----+----+ Reported +++
| | | Egress |
| | +----+----+ Measurement |
+--+-----+ | | Trigger + +--+-----+
|Endpoint| | +----+----+ |Endpoint|
+--------+ | | +--------+
+---<---+
Reaction
Figure 1: A CB controlling the part of the end-to-end path between an ingress point and an egress point. Note in some cases, the trigger and measurement functions could alternatively be located at other locations (e.g., at a network operations center).
图1：控制入口点和出口点之间端到端路径部分的CB。注：在某些情况下，触发和测量功能也可位于其他位置（例如，网络运营中心）。
In the context of a CB, the ingress and egress functions could be implemented in different places. For example, they could be located in network devices at a tunnel ingress and at the tunnel egress. In some cases, they could be located at one or both network endpoints (see Figure 2), implemented as components within a transport protocol.
在CB的上下文中，入口和出口功能可以在不同的地方实现。例如，它们可以位于隧道入口和隧道出口处的网络设备中。在某些情况下，它们可能位于一个或两个网络端点（见图2），作为传输协议中的组件实现。
+----------+ +----------+
| Ingress | +-+ +-+ +-+ | Egress |
| Endpoint +->+R+--+R+--+R+--+ Endpoint |
+--+----+--+ +-+ +-+ +-+ +----+-----+
^ | |
| +--+------+ +----+----+
| | Ingress | | Egress |
| | Meter | | Meter |
| +----+----+ +----+----+
| | |
| +--- +----+ |
| | Measure +<-----------------+
| +----+----+ Reported
| | Egress
| +----+----+ Measurement
| | Trigger |
| +----+----+
| |
+---<--+
Reaction
+----------+ +----------+
| Ingress | +-+ +-+ +-+ | Egress |
| Endpoint +->+R+--+R+--+R+--+ Endpoint |
+--+----+--+ +-+ +-+ +-+ +----+-----+
^ | |
| +--+------+ +----+----+
| | Ingress | | Egress |
| | Meter | | Meter |
| +----+----+ +----+----+
| | |
| +--- +----+ |
| | Measure +<-----------------+
| +----+----+ Reported
| | Egress
| +----+----+ Measurement
| | Trigger |
| +----+----+
| |
+---<--+
Reaction
Figure 2: An endpoint CB implemented at the sender (ingress) and receiver (egress).
图2：在发送方（入口）和接收方（出口）实现的端点CB。
The set of components needed to implement a CB are:
实现CB所需的组件集包括：
1. An ingress meter (at the sender or tunnel ingress) that records the number of packets/bytes sent in each measurement interval. This measures the offered network load for a flow or set of flows. For example, the measurement interval could be many seconds (or every few tens of seconds or a series of successive shorter measurements that are combined by the CB Measurement function).
1. 入口计（位于发送方或隧道入口），记录每个测量间隔内发送的数据包/字节数。这将测量一个流或一组流所提供的网络负载。例如，测量间隔可以是许多秒（或每隔几十秒或由CB测量功能组合的一系列连续较短的测量）。
2. An egress meter (at the receiver or tunnel egress) that records the number/bytes received in each measurement interval. This measures the supported load for the flow or set of flows, and it could utilize other signals to detect the effect of congestion (e.g., loss/congestion marking [RFC3168] experienced over the path). The measurements at the egress could be synchronized (including an offset for the time of flight of the data, or referencing the measurements to a particular packet) to ensure any counters refer to the same span of packets.
2. 一个出口仪表（位于接收器或隧道出口处），用于记录每个测量间隔内接收的数量/字节。这可测量流或流组的支持负载，并可利用其他信号检测拥塞的影响（例如，路径上经历的丢失/拥塞标记[RFC3168]）。出口处的测量可以同步（包括数据飞行时间的偏移，或将测量引用到特定分组），以确保任何计数器引用相同的分组跨度。
3. A method that communicates the measured values at the ingress and egress to the CB Measurement function. This could use several methods including sending return measurement packets (or control messages) from a receiver to a trigger function at the sender; an implementation using Operations, Administration and Management (OAM); or sending an in-band signaling datagram to the trigger function. This could also be implemented purely as a control-plane function, e.g., using a software-defined network controller.
3. 将入口和出口处的测量值传达给CB测量功能的方法。这可以使用几种方法，包括从接收方向发送方的触发函数发送返回测量数据包（或控制消息）；使用运营、行政和管理（OAM）的实施；或向触发功能发送带内信令数据报。这也可以纯粹作为控制平面功能来实现，例如，使用软件定义的网络控制器。
4. A measurement function that combines the ingress and egress measurements to assess the present level of network congestion. (For example, the loss rate for each measurement interval could be deduced from calculating the difference between ingress and egress counter values.) Note the method does not require high accuracy for the period of the measurement interval (or therefore the measured value, since isolated and/or infrequent loss events need to be disregarded).
4. 一种结合入口和出口测量的测量功能，用于评估当前的网络拥塞水平。（例如，每个测量间隔的损失率可以通过计算入口和出口计数器值之间的差值来推断。）注意，该方法不需要测量间隔期间的高精度（或因此测量值，因为需要忽略孤立和/或不频繁的损失事件）。
5. A trigger function that determines whether the measurements indicate persistent excessive congestion. This function defines an appropriate threshold for determining that there is persistent excessive congestion between the ingress and egress. This preferably considers a rate or ratio, rather than an absolute value (e.g., more than 10% loss, but other methods could also be based on the rate of transmission as well as the loss rate). The CB is triggered when the threshold is exceeded in multiple measurement intervals (e.g., three successive measurements). Designs need to be robust so that single or spurious events do not trigger a reaction.
5. 一种触发函数，用于确定测量值是否指示持续过度拥塞。此函数定义一个适当的阈值，用于确定入口和出口之间是否存在持续过度拥塞。这优选地考虑速率或比率，而不是绝对值（例如，超过10%的损耗，但是其他方法也可以基于传输速率以及损耗率）。当在多个测量间隔（例如，三次连续测量）中超过阈值时，触发CB。设计需要稳健，以便单个或虚假事件不会触发反应。
6. A reaction that is applied at the ingress when the CB is triggered. This seeks to automatically remove the traffic causing persistent excessive congestion.
6. 当CB被触发时，在入口施加的反应。这旨在自动消除导致持续过度拥挤的流量。
7. A feedback control mechanism that triggers when either the ingress and egress measurements are not available, since this also could indicate a loss of control packets (also a symptom of heavy congestion or inability to control the load).
7. 一种反馈控制机制，当入口和出口测量不可用时触发，因为这也可能表示控制数据包丢失（也是严重拥塞或无法控制负载的症状）。
A CB can be deployed in networks with topologies different from that presented in Figures 1 and 2. This section describes examples of such usage and possible places where functions can be implemented.
CB可以部署在不同于图1和图2中所示拓扑的网络中。本节描述了此类用法的示例以及可以实现功能的可能位置。
+----------+ +--------+ +----------+
| Ingress | +-+ +-+ +-+ | Egress | | Egress |
| Endpoint +->+R+--+R+--+R+--+ Router |--+ Endpoint +->+
+----+-----+ +-+ +-+ +-+ +---+--+-+ +----+-----+ |
^ ^ ^ ^ | ^ | |
| | | | | | | |
+----+----+ + - - - < - - - - + | +----+----+ | Reported
| Ingress | multicast Prune | | Egress | | Ingress
| Meter | | | Meter | | Measurement
+---------+ | +----+----+ |
| | |
| +----+----+ |
| | Measure +<--+
| +----+----+
| |
| +----+----+
multicast | | Trigger |
Leave | +----+----+
Message | |
+----<----+
+----------+ +--------+ +----------+
| Ingress | +-+ +-+ +-+ | Egress | | Egress |
| Endpoint +->+R+--+R+--+R+--+ Router |--+ Endpoint +->+
+----+-----+ +-+ +-+ +-+ +---+--+-+ +----+-----+ |
^ ^ ^ ^ | ^ | |
| | | | | | | |
+----+----+ + - - - < - - - - + | +----+----+ | Reported
| Ingress | multicast Prune | | Egress | | Ingress
| Meter | | | Meter | | Measurement
+---------+ | +----+----+ |
| | |
| +----+----+ |
| | Measure +<--+
| +----+----+
| |
| +----+----+
multicast | | Trigger |
Leave | +----+----+
Message | |
+----<----+
Figure 3: An example of a multicast CB controlling the end-to-end path between an ingress endpoint and an egress endpoint.
图3：多播CB控制入口端点和出口端点之间的端到端路径的示例。
Figure 3 shows one example of how a multicast CB could be implemented at a pair of multicast endpoints (e.g., to implement a Fast-Trip CB, Section 5.1). The ingress endpoint (the sender that sources the multicast traffic) meters the ingress load, generating an ingress measurement (e.g., recording timestamped packet counts), and it sends this measurement to the multicast group together with the traffic it has measured.
图3显示了如何在一对多播端点上实现多播CB的一个示例（例如，实现快速跳闸CB，第5.1节）。入口端点（产生多播流量的发送方）测量入口负载，生成入口测量值（例如，记录时间戳数据包计数），并将该测量值与其测量的流量一起发送到多播组。
Routers along a multicast path forward the multicast traffic (including the ingress measurement) to all active endpoint receivers. Each last hop (egress) router forwards the traffic to one or more egress endpoints.
多播路径上的路由器将多播流量（包括入口测量）转发给所有活动端点接收器。每个最后一跳（出口）路由器将流量转发到一个或多个出口端点。
In Figure 3, each endpoint includes a meter that performs a local egress load measurement. An endpoint also extracts the received ingress measurement from the traffic and compares the ingress and egress measurements to determine if the CB ought to be triggered. This measurement has to be robust to loss (see the previous section). If the CB is triggered, it generates a multicast leave message for the egress (e.g., an IGMP or MLD message sent to the last-hop router), which causes the upstream router to cease forwarding traffic to the egress endpoint [RFC1112].
在图3中，每个端点包括一个执行局部出口负载测量的仪表。端点还从业务中提取接收到的入口测量值，并比较入口和出口测量值，以确定是否应该触发CB。该测量必须对损失具有鲁棒性（见上一节）。如果CB被触发，它将为出口生成多播离开消息（例如，发送到最后一跳路由器的IGMP或MLD消息），这将导致上游路由器停止向出口端点转发流量[RFC1112]。
Any multicast router that has no active receivers for a particular multicast group will prune traffic for that group, sending a prune message to its upstream router. This starts the process of releasing the capacity used by the traffic and is a standard multicast routing function (e.g., using Protocol Independent Multicast - Sparse Mode (PIM-SM) routing protocol [RFC7761]). Each egress operates autonomously, and the CB "reaction" is executed by the multicast control plane (e.g., by PIM) requiring no explicit signaling by the CB along the communication path used for the control messages. Note there is no direct communication with the ingress; hence, a triggered CB only controls traffic downstream of the first-hop multicast router. It does not stop traffic flowing from the sender to the first-hop router; this is common practice for multicast deployment.
任何没有特定多播组活动接收器的多播路由器都将修剪该组的通信量，并向其上游路由器发送修剪消息。这将启动释放流量使用的容量的过程，并且是标准的多播路由功能（例如，使用协议独立多播-稀疏模式（PIM-SM）路由协议[RFC7761]）。每个出口自主地操作，并且CB“反应”由多播控制平面（例如，通过PIM）执行，不需要CB沿着用于控制消息的通信路径发出明确的信令。注：与入口无直接通信；因此，触发的CB仅控制第一跳多播路由器下游的流量。它不会阻止从发送方到第一跳路由器的流量；这是多播部署的常见做法。
The method could also be used with a multicast tunnel or subnetwork (e.g., Section 5.2, Section 5.3), where a meter at the ingress generates additional control messages to carry the measurement data towards the egress where the egress metering is implemented.
该方法也可用于多播隧道或子网络（例如，第5.2节、第5.3节），其中入口处的仪表生成额外的控制消息，以将测量数据传送到实施出口计量的出口。
Some paths are provisioned using a control protocol, e.g., flows provisioned using the Multiprotocol Label Switching (MPLS) services, paths provisioned using the Resource Reservation Protocol (RSVP), networks utilizing Software-Defined Network (SDN) functions, or admission-controlled Differentiated Services. Figure 1 shows one expected use case, where in this usage a separate device could be used to perform the measurement and trigger functions. The reaction generated by the trigger could take the form of a network-control message sent to the ingress and/or other network elements causing these elements to react to the CB. Examples of this type of use are provided in Section 5.3.
一些路径是使用控制协议提供的，例如，使用多协议标签交换（MPLS）服务提供的流、使用资源预留协议（RSVP）提供的路径、使用软件定义网络（SDN）功能的网络或许可控制的区分服务。图1显示了一个预期的用例，在这种情况下，可以使用一个单独的设备来执行测量和触发功能。触发器产生的反应可以采取网络控制消息的形式发送到入口和/或其他网络元件，导致这些元件对CB作出反应。第5.3节提供了此类使用的示例。
A CB can be used to control unidirectional UDP traffic, providing that there is a communication path that can be used for control messages to connect the functional components at the ingress and egress. This communication path for the control messages can exist in networks for which the traffic flow is purely unidirectional. For example, a multicast stream that sends packets across an Internet path and can use multicast routing to prune flows to shed network load. Some other types of subnetwork also utilize control protocols that can be used to control traffic flows.
CB可用于控制单向UDP通信，前提是存在可用于控制消息的通信路径，以连接入口和出口处的功能组件。控制消息的通信路径可以存在于通信流完全单向的网络中。例如，多播流通过Internet路径发送数据包，并可以使用多播路由来修剪流以减轻网络负载。一些其他类型的子网也利用可用于控制流量的控制协议。
The requirements for implementing a CB are:
实施CB的要求包括：
1. There needs to be a communication path for control messages to carry measurement data from the ingress meter and from the egress meter to the point of measurement. (Requirements 16-18 relate to the transmission of control messages.)
1. 控制信息需要有一个通信路径，以便将测量数据从入口仪表和出口仪表传送到测量点。（要求16-18与控制信息的传输有关。）
2. A CB is REQUIRED to define a measurement period over which the CB Measurement function measures the level of congestion or loss. This method does not have to detect individual packet loss, but it MUST have a way to know that packets have been lost/marked from the traffic flow.
2. CB需要定义一个测量周期，在此期间，CB测量功能测量拥塞或损耗水平。此方法不必检测单个数据包丢失，但它必须有一种方法可以知道数据包已从流量中丢失/标记。
3. An egress meter can also count ECN [RFC3168] Congestion Experienced (CE) marks as a part of measurement of congestion, but in this case, loss MUST also be measured to provide a complete view of the level of congestion. For tunnels, [CONGESTION-FEEDBACK] describes a way to measure both loss and ECN-marking; these measurements could be used on a relatively short timescale to drive a congestion control response and/or aggregated over a longer timescale with a higher trigger threshold to drive a CB. Subsequent bullet items in this section discuss the necessity of using a longer timescale and a higher trigger threshold.
3. 出口流量计还可以计算ECN[RFC3168]拥堵经历（CE）标记，作为拥堵测量的一部分，但在这种情况下，还必须测量损失，以提供拥堵水平的完整视图。对于隧道，[拥塞反馈]描述了测量损耗和ECN标记的方法；这些测量可以在相对较短的时间尺度上用于驱动拥塞控制响应，和/或在较长的时间尺度上使用较高的触发阈值来聚合以驱动CB。本节后面的项目讨论了使用更长时间刻度和更高触发阈值的必要性。
4. The measurement period used by a CB Measurement function MUST be longer than the time that current Congestion Control algorithms need to reduce their rate following detection of congestion. This is important because end-to-end Congestion Control algorithms require at least one RTT to notify and adjust the traffic when congestion is experienced, and congestion bottlenecks can share traffic with a diverse range of end-to-end RTTs. The measurement period is therefore expected to be significantly longer than the RTT experienced by the CB itself.
4. CB测量功能使用的测量周期必须大于当前拥塞控制算法在检测到拥塞后降低速率所需的时间。这一点很重要，因为端到端拥塞控制算法需要至少一个RTT在遇到拥塞时通知和调整流量，并且拥塞瓶颈可以与不同范围的端到端RTT共享流量。因此，预计测量周期将明显长于CB自身经历的RTT。
5. If necessary, a CB MAY combine successive individual meter samples from the ingress and egress to ensure observation of an average measurement over a sufficiently long interval. (Note when meter samples need to be combined, the combination needs to reflect the sum of the individual sample counts divided by the total time/volume over which the samples were measured. Individual samples over different intervals cannot be directly combined to generate an average value.)
5. 如有必要，CB可结合入口和出口的连续单个仪表样品，以确保在足够长的间隔内观察平均测量值。（注意：当需要组合仪表样品时，组合需要反映单个样品计数的总和除以测量样品的总时间/体积。不同间隔的单个样品不能直接组合生成平均值。）
6. A CB MUST be constructed so that it does not trigger under light or intermittent congestion (see requirements 7-9).
6. CB的构造必须确保其不会在轻度或间歇性拥堵情况下触发（见要求7-9）。
7. A CB is REQUIRED to define a threshold to determine whether the measured congestion is considered excessive.
7. CB需要定义一个阈值，以确定所测量的拥塞是否被视为过度。
8. A CB is REQUIRED to define the triggering interval, defining the period over which the trigger uses the collected measurements. CBs need to trigger over a sufficiently long period to avoid additionally penalizing flows with a long path RTT (e.g., many path RTTs).
8. CB需要定义触发间隔，定义触发器使用收集的测量值的时间段。CBs需要在足够长的时间内触发，以避免使用长路径RTT（例如，多路径RTT）额外惩罚流。
9. A CB MUST be robust to multiple congestion events. This usually will define a number of measured persistent congestion events per triggering period. For example, a CB MAY combine the results of several measurement periods to determine if the CB is triggered (e.g., it is triggered when persistent excessive congestion is detected in three of the measurements within the triggering interval when more than three measurements were collected).
9. CB必须对多个拥塞事件具有鲁棒性。这通常会定义每个触发周期内测量的持续拥塞事件的数量。例如，CB可组合多个测量周期的结果以确定是否触发CB（例如，当收集到三个以上测量时，在触发间隔内的三个测量中检测到持续过度拥塞时触发CB）。
10. The normal reaction to a trigger SHOULD disable all traffic that contributed to congestion (otherwise, see requirements 11 and 12).
10. 对触发器的正常反应应该禁用导致拥塞的所有通信量（否则，请参见要求11和12）。
11. The reaction MUST be much more severe than that of a Congestion Control algorithm (such as TCP's congestion control [RFC5681] or TCP-Friendly Rate Control, TFRC [RFC5348]), because the CB reacts to more persistent congestion and operates over longer timescales (i.e., the overload condition will have persisted for a longer time before the CB is triggered).
11. 这种反应必须比拥塞控制算法（如TCP的拥塞控制[RFC5681]或TCP友好速率控制[RFC5348]）的反应严重得多，因为CB会对更持久的拥塞作出反应，并在更长的时间尺度上运行（即，在触发CB之前，过载条件将持续更长时间）。
12. A reaction that results in a reduction SHOULD result in reducing the traffic by at least an order of magnitude. A response that achieves the reduction by terminating flows, rather than randomly dropping packets, will often be more desirable to users of the service. A CB that reduces the rate of a flow, MUST continue to monitor the level of congestion and MUST further react to reduce the rate if the CB is again triggered.
12. 导致交通量减少的反应应导致交通量至少减少一个数量级。服务用户通常更希望通过终止流而不是随机丢弃数据包来实现减少的响应。降低流量的CB必须继续监控拥堵水平，并且如果CB再次触发，必须进一步做出反应以降低流量。
13. The reaction to a triggered CB MUST continue for a period that is at least the triggering interval. Operator intervention will usually be required to restore a flow. If an automated response is needed to reset the trigger, then this needs to not be immediate. The design of an automated reset mechanism needs to be sufficiently conservative that it does not adversely interact with other mechanisms (including other CB algorithms that control traffic over a common path). It SHOULD NOT perform an automated reset when there is evidence of continued congestion.
13. 对触发CB的反应必须持续至少一段触发间隔时间。恢复流量通常需要操作员干预。如果需要自动响应来重置触发器，则不需要立即进行。自动重置机制的设计需要足够保守，以免与其他机制（包括控制公共路径上流量的其他CB算法）产生不利影响。当有证据表明持续拥塞时，不应执行自动重置。
14. A CB trigger SHOULD be regarded as an abnormal network event. As such, this event SHOULD be logged. The measurements that lead to triggering of the CB SHOULD also be logged.
14. CB触发器应视为异常网络事件。因此，应记录此事件。还应记录导致CB触发的测量值。
15. The control communication needs to carry measurements (requirement 1) and, in some uses, also needs to transmit trigger messages to the ingress. This control communication may be in or out of band. The use of in-band communication is RECOMMENDED when either design would be possible. The preferred CB design is one that triggers when it fails to receive measurement reports that indicate an absence of congestion, in contrast to relying on the successful transmission of a "congested" signal back to the sender. (The feedback signal could itself be lost under congestion).
15. 控制通信需要进行测量（要求1），并且在某些用途中，还需要向入口发送触发消息。此控制通信可能在带内或带外。当两种设计都可行时，建议使用带内通信。首选的CB设计是当它无法接收到指示没有拥塞的测量报告时触发的设计，而不是依赖成功地将“拥塞”信号传输回发送方。（反馈信号本身可能在拥塞情况下丢失）。
In Band: An in-band control method SHOULD assume that loss of control messages is an indication of potential congestion on the path, and repeated loss ought to cause the CB to be triggered. This design has the advantage that it provides fate-sharing of the traffic flow(s) and the control communications. This fate-sharing property is weaker when some or all of the measured traffic is sent using a path that differs from the path taken by the control traffic (e.g., where traffic and control messages follow a different path due to use of equal-cost multipath routing, traffic engineering, or tunnels for specific types of traffic).
带内：带内控制方法应假设控制消息丢失是路径上潜在拥塞的指示，重复丢失应导致触发CB。这种设计的优点是它提供了交通流和控制通信的命运共享。当使用与控制流量所采用的路径不同的路径发送部分或全部测量流量时（例如，由于使用相同成本的多路径路由、流量工程或特定类型流量的隧道，流量和控制消息遵循不同的路径），此命运共享属性较弱。
Out of Band: An out-of-band control method SHOULD NOT trigger a CB reaction when there is loss of control messages (e.g., a loss of measurements). This avoids failure amplification/ propagation when the measurement and data paths fail independently. A failure of an out-of-band communication path SHOULD be regarded as an abnormal network event and be handled as appropriate for the network; for example, this event SHOULD be logged, and additional network operator action might be appropriate, depending on the network and the traffic involved.
带外：当控制信息丢失（例如，测量丢失）时，带外控制方法不应触发CB反应。这避免了测量和数据路径独立失效时的故障放大/传播。带外通信路径故障应视为异常网络事件，并根据网络情况进行适当处理；例如，应记录此事件，根据所涉及的网络和流量，可能需要额外的网络运营商操作。
16. The control communication MUST be designed to be robust to packet loss. A control message can be lost if there is a failure of the communication path used for the control messages, loss is likely also to be experienced during congestion/ overload. This does not imply that it is desirable to provide reliable delivery (e.g., over TCP), since this can incur additional delay in responding to congestion. Appropriate mechanisms could be to duplicate control messages to provide increased robustness to loss and/or to regard a lack of control traffic as an indication that excessive congestion could be
16. 控制通信必须设计为对数据包丢失具有鲁棒性。如果用于控制消息的通信路径出现故障，则控制消息可能会丢失，在拥塞/过载期间也可能会发生丢失。这并不意味着需要提供可靠的传输（例如，通过TCP），因为这会导致响应拥塞的额外延迟。适当的机制可以是复制控制消息，以提高对丢失的鲁棒性和/或将缺乏控制流量视为可能导致过度拥塞的指示
being experienced [RFC8085]. If control message traffic is sent over a shared path, it is RECOMMENDED that this control traffic is prioritized to reduce the probability of loss under congestion. Control traffic also needs to be considered when provisioning a network that uses a CB.
有经验[RFC8085]。如果通过共享路径发送控制消息通信量，建议对该控制通信量进行优先排序，以降低拥塞情况下的丢失概率。在配置使用CB的网络时，还需要考虑控制流量。
17. There are security requirements for the control communication between endpoints and/or network devices (Section 7). The authenticity of the source and integrity of the control messages (measurements and triggers) MUST be protected from off-path attacks. When there is a risk of an on-path attack, a cryptographic authentication mechanism for all control/ measurement messages is RECOMMENDED.
17. 端点和/或网络设备之间的控制通信有安全要求（第7节）。必须保护源的真实性和控制消息（测量值和触发器）的完整性，使其免受非路径攻击。当存在路径攻击风险时，建议对所有控制/测量消息使用加密身份验证机制。
There are multiple types of CB that could be defined for use in different deployment cases. There could be cases where a flow becomes controlled by multiple CBs (e.g., when the traffic of an end-to-end flow is carried in a tunnel within the network). This section provides examples of different types of CB.
有多种类型的CB可定义用于不同的部署情况。可能存在流由多个cb控制的情况（例如，当端到端流的流量在网络内的隧道中传输时）。本节提供了不同类型CB的示例。
[RFC2309] discusses the dangers of congestion unresponsive flows and states that "all UDP-based streaming applications should incorporate effective congestion avoidance mechanisms." Some applications do not use a full-featured transport (TCP, SCTP, DCCP). These applications (e.g., using UDP and its UDP-Lite variant) need to provide appropriate congestion avoidance. Guidance for applications that do not use congestion-controlled transports is provided in [RFC8085]. Such mechanisms can be designed to react on much shorter timescales than a CB, that only observes a traffic envelope. Congestion control methods can also interact with an application to more effectively control its sending rate.
[RFC2309]讨论了拥塞无响应流的危险，并指出“所有基于UDP的流媒体应用程序都应包含有效的拥塞避免机制。”有些应用程序不使用全功能传输（TCP、SCTP、DCCP）。这些应用程序（例如，使用UDP及其UDP Lite变体）需要提供适当的拥塞避免。[RFC8085]中提供了不使用拥塞控制传输的应用程序指南。这种机制可以设计成比只观察流量包络线的CB在更短的时间尺度上做出反应。拥塞控制方法还可以与应用程序交互，以更有效地控制其发送速率。
A Fast-trip CB is the most responsive form of CB. It has a response time that is only slightly larger than that of the traffic that it controls. It is suited to traffic with well-understood characteristics (and could include one or more trigger functions specifically tailored the type of traffic for which it is designed). It is not suited to arbitrary network traffic and could be unsuitable for traffic aggregates, since it could prematurely trigger (e.g., when the combined traffic from multiple congestion-controlled flows leads to short-term overload).
快速跳闸断路器是断路器最灵敏的形式。它的响应时间仅略大于它控制的流量的响应时间。它适用于具有众所周知的特性的流量（可以包括一个或多个专门针对其设计的流量类型定制的触发功能）。它不适用于任意网络流量，也不适用于流量聚合，因为它可能会过早触发（例如，当来自多个拥塞控制流的组合流量导致短期过载时）。
Although the mechanisms can be implemented in RTP-aware network devices, these mechanisms are also suitable for implementation in endpoints (e.g., as a part of the transport system) where they can also complement end-to-end congestion control methods. A shorter response time enables these mechanisms to triggers before other forms of CB (e.g., CBs operating on traffic aggregates at a point along the network path).
尽管这些机制可以在感知RTP的网络设备中实现，但这些机制也适用于在端点（例如，作为传输系统的一部分）中实现，其中它们还可以补充端到端拥塞控制方法。更短的响应时间使这些机制能够在其他形式的CB（例如，在网络路径上的某一点上对流量聚合进行操作的CB）之前触发。
A set of Fast-Trip CB methods have been specified for use together by a Real-time Transport Protocol (RTP) flow using the RTP/AVP Profile [RFC8083]. It is expected that, in the absence of severe congestion, all RTP applications running on best-effort IP networks will be able to run without triggering these CBs. An RTP Fast-Trip CB is therefore implemented as a fail-safe that, when triggered, will terminate RTP traffic.
使用RTP/AVP配置文件[RFC8083]的实时传输协议（RTP）流指定了一组快速跳闸CB方法一起使用。预计在没有严重拥塞的情况下，所有在尽力而为IP网络上运行的RTP应用程序都将能够在不触发这些CBs的情况下运行。因此，RTP快速跳闸CB被实现为故障保护，当触发时，将终止RTP通信。
The sending endpoint monitors reception of in-band RTP Control Protocol (RTCP) reception report blocks, as contained in sender report (SR) or receiver report (RR) packets, that convey reception quality feedback information. This is used to measure (congestion) loss, possibly in combination with ECN [RFC6679].
发送端点监视传送接收质量反馈信息的发送方报告（SR）或接收方报告（RR）包中包含的带内RTP控制协议（RTCP）接收报告块的接收。这用于测量（拥塞）损失，可能与ECN[RFC6679]结合使用。
The CB action (shutdown of the flow) triggers when any of the following trigger conditions are true:
当以下任何触发条件为真时，CB动作（流量关闭）触发：
1. An RTP CB triggers on reported lack of progress.
1. 报告缺乏进展时触发RTP CB。
2. An RTP CB triggers when no receiver reports messages are received.
2. 当没有接收到接收方报告消息时，RTP CB触发。
3. An RTP CB triggers when the long-term RTP throughput (over many RTTs) exceeds a hard upper limit determined by a method that resembles TCP-Friendly Rate Control (TFRC).
3. 当长期RTP吞吐量（在许多RTT上）超过由类似于TCP友好速率控制（TFRC）的方法确定的硬上限时，RTP CB触发。
4. An RTP CB includes the notion of Media Usability. This CB is triggered when the quality of the transported media falls below some required minimum acceptable quality.
4. RTP CB包含媒体可用性的概念。当传输介质的质量低于所需的最低可接受质量时，会触发此CB。
A Slow-Trip CB could be implemented in an endpoint or network device. This type of CB is much slower at responding to congestion than a Fast-Trip CB. This is expected to be more common.
可以在端点或网络设备中实现慢行程CB。这种类型的CB在响应拥塞时比快速跳闸CB慢得多。预计这种情况会更加普遍。
One example where a Slow-Trip CB is needed is where flows or traffic-aggregates use a tunnel or encapsulation and the flows within the tunnel do not all support TCP-style congestion control (e.g., TCP, SCTP, TFRC), see [RFC8085], Section 3.1.3. A use case is where tunnels are deployed in the general Internet (rather than "controlled environments" within an Internet service provider or enterprise network), especially when the tunnel could need to cross a customer access router.
需要慢行程CB的一个示例是，流量或流量聚合使用隧道或封装，且隧道内的流量不都支持TCP类型的拥塞控制（例如TCP、SCTP、TFRC），请参见[RFC8085]，第3.1.3节。一个用例是隧道部署在通用Internet中（而不是Internet服务提供商或企业网络中的“受控环境”），特别是当隧道可能需要穿越客户访问路由器时。
A managed CB is implemented in the signaling protocol or management plane that relates to the traffic aggregate being controlled. This type of CB is typically applicable when the deployment is within a "controlled environment".
在与被控制的业务聚合相关的信令协议或管理平面中实现受管CB。当部署在“受控环境”中时，这种类型的CB通常适用。
A CB requires more than the ability to determine that a network path is forwarding data or to measure the rate of a path -- which are often normal network operational functions. There is an additional need to determine a metric for congestion on the path and to trigger a reaction when a threshold is crossed that indicates persistent excessive congestion.
CB需要的不仅仅是确定网络路径正在转发数据或测量路径速率的能力，这通常是正常的网络操作功能。另外还需要确定路径上拥塞的度量，并在超过指示持续过度拥塞的阈值时触发反应。
The control messages can use either in-band or out-of-band communications.
控制消息可以使用带内或带外通信。
Section 8 of [RFC4553], SAToP Pseudowire Emulation Edge-to-Edge (PWE3), describes an example of a managed CB for isochronous flows.
[RFC4553]的第8节，SAToP伪线仿真边到边（PWE3），描述了用于等时流的受管CB的示例。
If such flows were to run over a pre-provisioned (e.g., Multiprotocol Label Switching, MPLS) infrastructure, then it could be expected that the PW would not experience congestion, because a flow is not expected to either increase (or decrease) their rate. If, instead, PW traffic is multiplexed with other traffic over the general Internet, it could experience congestion. [RFC4553] states: "If SAToP PWs run over a PSN providing best-effort service, they SHOULD monitor packet loss in order to detect 'severe congestion'." The currently recommended measurement period is 1 second, and the trigger operates when there are more than three measured Severely Errored Seconds (SES) within a period. [RFC4553] goes on to state that "If such a condition is detected, a SAToP PW ought to shut down bi-directionally for some period of time...".
如果这些流在预先配置的（例如，多协议标签交换，MPLS）基础设施上运行，那么可以预期PW不会经历拥塞，因为预计流不会增加（或降低）它们的速率。相反，如果PW流量与普通Internet上的其他流量多路复用，它可能会遇到拥塞。[RFC4553]指出：“如果SAToP PW在提供尽力而为服务的PSN上运行，则它们应监控数据包丢失，以检测‘严重拥塞’。”当前建议的测量周期为1秒，并且当一个周期内测量到的严重错误秒数（SES）超过三秒时，触发器工作。[RFC4553]接着指出，“如果检测到这种情况，SAToP PW应该双向关闭一段时间……”。
The concept was that when the packet-loss ratio (congestion) level increased above a threshold, the PW was, by default, disabled. This use case considered fixed-rate transmission, where the PW had no reasonable way to shed load.
其概念是，当数据包丢失率（拥塞）水平增加到阈值以上时，PW在默认情况下被禁用。该用例考虑了固定速率传输，其中PW没有合理的方式来甩负荷。
The trigger needs to be set at a rate at which the PW is likely to experience a serious problem, possibly making the service noncompliant. At this point, triggering the CB would remove the traffic preventing undue impact on congestion-responsive traffic (e.g., TCP). Part of the rationale was that high-loss ratios typically indicated that something was "broken" and ought to have already resulted in operator intervention and therefore now need to trigger this intervention.
触发器需要设置为PW可能遇到严重问题的速率，可能导致服务不符合要求。在这一点上，触发CB将移除流量，以防止对拥塞响应流量（例如TCP）产生不当影响。部分理由是，高损失率通常表明某些东西“坏了”，应该已经导致运营商干预，因此现在需要触发这种干预。
An operator-based response to the triggering of a CB provides an opportunity for other action to restore the service quality (e.g., by shedding other loads or assigning additional capacity) or to consciously avoid reacting to the trigger while engineering a solution to the problem. This could require the trigger function to send a control message to a third location (e.g., a network operations center, NOC) that is responsible for operation of the tunnel ingress, rather than the tunnel ingress itself.
基于操作员对CB触发的响应为其他行动提供了机会，以恢复服务质量（例如，通过卸载其他负载或分配额外容量），或在设计问题解决方案时有意识地避免对触发作出反应。这可能需要触发功能向负责隧道入口操作的第三位置（例如，网络运营中心，NOC）发送控制消息，而不是隧道入口本身。
Pseudowires (PWs) [RFC3985] have become a common mechanism for tunneling traffic, and they could compete for network resources both with other PWs and with non-PW traffic, such as TCP/IP flows.
伪线（PW）[RFC3985]已成为隧道流量的常见机制，它们可以与其他PW和非PW流量（如TCP/IP流）竞争网络资源。
[RFC7893] discusses congestion conditions that can arise when PWs compete with elastic (i.e., congestion responsive) network traffic (e.g., TCP traffic). Elastic PWs carrying IP traffic (see [RFC4448]) do not raise major concerns because all of the traffic involved responds, reducing the transmission rate when network congestion is detected.
[RFC7893]讨论了PWs与弹性（即拥塞响应）网络流量（例如TCP流量）竞争时可能出现的拥塞情况。承载IP流量的弹性PWs（参见[RFC4448]）不会引起重大关注，因为所有涉及的流量都会响应，从而在检测到网络拥塞时降低传输速率。
In contrast, inelastic PWs (e.g., a fixed-bandwidth Time Division Multiplex, TDM [RFC4553] [RFC5086] [RFC5087]) have the potential to harm congestion-responsive traffic or to contribute to excessive congestion because inelastic PWs do not adjust their transmission rate in response to congestion. [RFC7893] analyses TDM PWs, with an initial conclusion that a TDM PW operating with a degree of loss that could result in congestion-related problems is also operating with a degree of loss that results in an unacceptable TDM service. For that reason, the document suggests that a managed CB that shuts down a PW when it persistently fails to deliver acceptable TDM service is a useful means for addressing these congestion concerns. (See Appendix A of [RFC7893] for further discussion.)
相反，非弹性PW（例如，固定带宽时分多路复用，TDM[RFC4553][RFC5086][RFC5087]）有可能损害响应拥塞的流量或导致过度拥塞，因为非弹性PW不会根据拥塞调整其传输速率。[RFC7893]分析了TDM PW，初步结论是，TDM PW在运行时的损失程度可能导致拥堵相关问题，同时也在运行时的损失程度可能导致不可接受的TDM服务。因此，该文件建议，当PW持续无法提供可接受的TDM服务时，关闭PW的受管CB是解决这些拥塞问题的有用手段。（进一步讨论请参见[RFC7893]的附录A。）
A CB is not required for a single congestion-controlled flow using TCP, SCTP, TFRC, etc. In these cases, the congestion control methods are already designed to prevent persistent excessive congestion.
使用TCP、SCTP、TFRC等的单个拥塞控制流不需要CB。在这些情况下，拥塞控制方法已经设计为防止持续过度拥塞。
One common question is whether a CB is needed when a tunnel is deployed in a private network with pre-provisioned capacity.
一个常见的问题是，当隧道部署在具有预配置容量的专用网络中时，是否需要CB。
In this case, compliant traffic that does not exceed the provisioned capacity ought not to result in persistent congestion. A CB will hence only be triggered when there is noncompliant traffic. It could be argued that this event ought never to happen -- but it could also be argued that the CB equally ought never to be triggered. If a CB were to be implemented, it will provide an appropriate response, if persistent congestion occurs in an operational network.
在这种情况下，不超过规定容量的兼容流量不应导致持续拥塞。因此，只有当存在不符合要求的流量时，才会触发CB。可以说，这一事件不应该发生——但也可以说，CB同样不应该被触发。如果要实施CB，则在运行网络中出现持续拥塞时，它将提供适当的响应。
Implementing a CB will not reduce the performance of the flows, but in the event that persistent excessive congestion occurs, it protects network traffic that shares network capacity with these flows. It also protects network traffic from a failure when CB traffic is (re)routed to cause additional network load on a non-pre-provisioned path.
实施CB不会降低流的性能，但在持续过度拥塞发生的情况下，它会保护与这些流共享网络容量的网络流量。当CB流量（重新）路由以在非预配置路径上造成额外的网络负载时，它还可以防止网络流量发生故障。
IP-based traffic is generally assumed to be congestion controlled, i.e., it is assumed that the transport protocols generating IP-based traffic at the sender already employ mechanisms that are sufficient to address congestion on the path. Therefore, a question arises when people deploy a tunnel that is thought to carry only an aggregate of TCP traffic (or traffic using some other congestion control method): Is there an advantage in this case in using a CB?
基于IP的流量通常被假定为拥塞控制，即，假定在发送方处生成基于IP的流量的传输协议已经采用足以解决路径上的拥塞的机制。因此，当人们部署一个被认为只承载TCP流量（或使用其他拥塞控制方法的流量）集合的隧道时，就会出现一个问题：在这种情况下，使用CB是否有优势？
TCP (and SCTP) traffic in a tunnel is expected to reduce the transmission rate when network congestion is detected. Other transports (e.g., using UDP) can employ mechanisms that are sufficient to address congestion on the path [RFC8085]. However, even if the individual flows sharing a tunnel each implement a congestion control mechanism, and individually reduce their transmission rate when network congestion is detected, the overall traffic resulting from the aggregate of the flows does not necessarily avoid persistent congestion. For instance, most congestion control mechanisms require long-lived flows to react to reduce the rate of a flow. An aggregate of many short flows could result in many flows terminating before they experience congestion.
当检测到网络拥塞时，隧道中的TCP（和SCTP）流量有望降低传输速率。其他传输（例如，使用UDP）可以采用足以解决路径拥塞的机制[RFC8085]。然而，即使共享隧道的各个流都实现了拥塞控制机制，并且在检测到网络拥塞时分别降低了它们的传输速率，但是由流的集合产生的总流量不一定能够避免持续拥塞。例如，大多数拥塞控制机制需要长寿命的流作出反应以降低流的速率。许多短流的聚合可能导致许多流在遇到拥塞之前终止。
It is also often impossible for a tunnel service provider to know that the tunnel only contains congestion-controlled traffic (e.g., Inspecting packet headers might not be possible). Some IP-based applications might not implement adequate mechanisms to address congestion. The important thing to note is that if the aggregate of the traffic does not result in persistent excessive congestion (impacting other flows), then the CB will not trigger. This is the expected case in this context -- so implementing a CB ought not to reduce performance of the tunnel, but in the event that persistent excessive congestion occurs, the CB protects other network traffic that shares capacity with the tunnel traffic.
隧道服务提供商通常也不可能知道隧道仅包含拥塞控制流量（例如，可能无法检查数据包头）。一些基于IP的应用程序可能无法实现足够的机制来解决拥塞问题。需要注意的重要一点是，如果总流量不会导致持续过度拥塞（影响其他流量），那么CB将不会触发。这是本文中的预期情况——因此，实现CB不应降低隧道的性能，但如果发生持续过度拥塞，CB将保护与隧道流量共享容量的其他网络流量。
A one-way forwarding path could have no associated communication path for sending control messages; therefore, it cannot be controlled using a CB (compare with Section 3.2.3).
单向转发路径可能没有用于发送控制消息的关联通信路径；因此，不能使用CB进行控制（与第3.2.3节相比）。
A one-way service could be provided using a path with dedicated pre-provisioned capacity that is not shared with other elastic Internet flows (i.e., flows that vary their rate). A forwarding path could also be shared with other flows. One way to mitigate the impact of traffic on the other flows is to manage the traffic envelope by using ingress policing. Supporting this type of traffic in the general Internet requires operator monitoring to detect and respond to persistent excessive congestion.
可以使用具有专用预配置容量的路径提供单向服务，该路径不与其他弹性互联网流（即，改变其速率的流）共享。转发路径也可以与其他流共享。缓解流量对其他流的影响的一种方法是通过使用入口策略来管理流量包线。在通用互联网上支持这种类型的流量需要运营商监控，以检测并响应持续的过度拥塞。
All CB mechanisms rely upon coordination between the ingress and egress meters and communication with the trigger function. This is usually achieved by passing network-control information (or protocol messages) across the network. Timely operation of a CB depends on the choice of measurement period. If the receiver has an interval that is overly long, then the responsiveness of the CB decreases. This impacts the ability of the CB to detect and react to congestion. If the interval is too short, the CB could trigger prematurely resulting in insufficient time for other mechanisms to act and potentially resulting in unnecessary disruption to the service.
所有CB机制依赖于入口和出口仪表之间的协调以及与触发功能的通信。这通常通过在网络上传递网络控制信息（或协议消息）来实现。CB的及时运行取决于测量周期的选择。如果接收器的间隔过长，则CB的响应性降低。这会影响CB检测拥塞并作出反应的能力。如果间隔太短，CB可能会过早触发，导致其他机制没有足够的时间采取行动，并可能导致不必要的服务中断。
A CB could potentially be exploited by an attacker to mount a Denial-of-Service (DoS) attack against the traffic being controlled by the CB. Therefore, mechanisms need to be implemented to prevent attacks on the network-control information that would result in DoS.
攻击者可能利用CB对CB控制的流量发起拒绝服务（DoS）攻击。因此，需要实施机制来防止对网络控制信息的攻击，从而导致拒绝服务。
The authenticity of the source and integrity of the control messages (measurements and triggers) MUST be protected from off-path attacks. Without protection, it could be trivial for an attacker to inject
必须保护源的真实性和控制消息（测量值和触发器）的完整性，使其免受非路径攻击。在没有保护的情况下，攻击者进行注入可能是微不足道的
fake or modified control/measurement messages (e.g., indicating high packet loss rates) causing a CB to trigger and therefore to mount a DoS attack that disrupts a flow.
伪造或修改的控制/测量消息（例如，指示高丢包率），导致CB触发，从而发起破坏流的DoS攻击。
Simple protection can be provided by using a randomized source port, or equivalent field in the packet header (such as the RTP SSRC value and the RTP sequence number) expected not to be known to an off-path attacker. Stronger protection can be achieved using a secure authentication protocol to mitigate this concern.
通过使用随机源端口或数据包头中的等效字段（如RTP SSRC值和RTP序列号），可以提供简单的保护，这些数据包头预计不会为非路径攻击者所知。使用安全身份验证协议可以实现更强大的保护，以缓解此问题。
An attack on the control messages is relatively easy for an attacker on the control path when the messages are neither encrypted nor authenticated. Use of a cryptographic authentication mechanism for all control/measurement messages is RECOMMENDED to mitigate this concern, and would also provide protection from off-path attacks. There is a design trade-off between the cost of introducing cryptographic security for control messages and the desire to protect control communication. For some deployment scenarios, the value of additional protection from DoS attacks will therefore lead to a requirement to authenticate all control messages.
当消息既没有加密也没有经过身份验证时，控制路径上的攻击者相对容易攻击控制消息。建议对所有控制/测量消息使用加密身份验证机制，以缓解此问题，并提供防止路径外攻击的保护。在为控制消息引入密码安全性的成本和保护控制通信的愿望之间存在设计权衡。对于某些部署场景，额外的DoS攻击保护的价值将导致需要对所有控制消息进行身份验证。
Transmission of network-control messages consumes network capacity. This control traffic needs to be considered in the design of a CB and could potentially add to network congestion. If this traffic is sent over a shared path, it is RECOMMENDED that this control traffic be prioritized to reduce the probability of loss under congestion. Control traffic also needs to be considered when provisioning a network that uses a CB.
网络控制消息的传输消耗网络容量。这种控制流量需要在CB的设计中加以考虑，可能会增加网络拥塞。如果此流量通过共享路径发送，建议对此控制流量进行优先排序，以降低拥塞情况下的丢失概率。在配置使用CB的网络时，还需要考虑控制流量。
The CB MUST be designed to be robust to packet loss that can also be experienced during congestion/overload. Loss of control messages could be a side-effect of a congested network, but it also could arise from other causes Section 4.
CB必须设计为对拥塞/过载期间可能发生的数据包丢失具有鲁棒性。失去控制信息可能是拥塞网络的副作用，但也可能由第4节中的其他原因引起。
The security implications depend on the design of the mechanisms, the type of traffic being controlled and the intended deployment scenario. Each design of a CB MUST therefore evaluate whether the particular CB mechanism has new security implications.
安全影响取决于机制的设计、被控制的流量类型和预期的部署场景。因此，CB的每个设计都必须评估特定CB机制是否具有新的安全含义。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，DOI 10.17487/RFC2119，1997年3月<http://www.rfc-editor.org/info/rfc2119>.
[RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition of Explicit Congestion Notification (ECN) to IP", RFC 3168, DOI 10.17487/RFC3168, September 2001, <http://www.rfc-editor.org/info/rfc3168>.
[RFC3168]Ramakrishnan，K.，Floyd，S.，和D.Black，“向IP添加显式拥塞通知（ECN）”，RFC 3168，DOI 10.17487/RFC3168，2001年9月<http://www.rfc-editor.org/info/rfc3168>.
[RFC8085] Eggert, L., Fairhurst, G., and G. Shepherd, "UDP Usage Guidelines", BCP 145, RFC 8085, DOI 10.17487/RFC8085, March 2017, <http://www.rfc-editor.org/info/rfc8085>.
[RFC8085]Eggert，L.，Fairhurst，G.和G.Shepherd，“UDP使用指南”，BCP 145，RFC 8085，DOI 10.17487/RFC8085，2017年3月<http://www.rfc-editor.org/info/rfc8085>.
[CONGESTION-FEEDBACK] Wei, X., Zhu, L., and L. Deng, "Tunnel Congestion Feedback", Work in Progress, draft-ietf-tsvwg-tunnel-congestion-feedback-04, January 2017.
[拥堵反馈]魏，X.，朱，L.，和邓L，“隧道拥堵反馈”，正在进行的工作，草案-ietf-tsvwg-Tunnel-拥堵反馈-042017年1月。
[Jacobson88] Jacobson, V., "Congestion Avoidance and Control", SIGCOMM Symposium proceedings on Communications architectures and protocols, August 1988.
[Jacobson88]Jacobson，V.，“拥塞避免和控制”，SIGCOMM通信体系结构和协议研讨会论文集，1988年8月。
[RFC1112] Deering, S., "Host extensions for IP multicasting", STD 5, RFC 1112, DOI 10.17487/RFC1112, August 1989, <http://www.rfc-editor.org/info/rfc1112>.
[RFC1112]Deering，S.，“IP多播的主机扩展”，STD 5，RFC 1112，DOI 10.17487/RFC1112，1989年8月<http://www.rfc-editor.org/info/rfc1112>.
[RFC2309] Braden, B., Clark, D., Crowcroft, J., Davie, B., Deering, S., Estrin, D., Floyd, S., Jacobson, V., Minshall, G., Partridge, C., Peterson, L., Ramakrishnan, K., Shenker, S., Wroclawski, J., and L. Zhang, "Recommendations on Queue Management and Congestion Avoidance in the Internet", RFC 2309, DOI 10.17487/RFC2309, April 1998, <http://www.rfc-editor.org/info/rfc2309>.
[RFC2309]Braden，B.，Clark，D.，Crowcroft，J.，Davie，B.，Deering，S.，Estrin，D.，Floyd，S.，Jacobson，V.，Minshall，G.，Partridge，C.，Peterson，L.，Ramakrishnan，K.，Shenker，S.，Wroclawski，J.，and L.Zhang，“关于互联网中队列管理和拥塞避免的建议”，RFC 2309，DOI 10.17487/RFC2309，1998年4月， <http://www.rfc-editor.org/info/rfc2309>.
[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>.
[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>.
[RFC4448] Martini, L., Ed., Rosen, E., El-Aawar, N., and G. Heron, "Encapsulation Methods for Transport of Ethernet over MPLS Networks", RFC 4448, DOI 10.17487/RFC4448, April 2006, <http://www.rfc-editor.org/info/rfc4448>.
[RFC4448]Martini，L.，Ed.，Rosen，E.，El Aawar，N.，和G.Heron，“通过MPLS网络传输以太网的封装方法”，RFC 4448，DOI 10.17487/RFC4448，2006年4月<http://www.rfc-editor.org/info/rfc4448>.
[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>.
[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>.
[RFC5681] Allman, M., Paxson, V., and E. Blanton, "TCP Congestion Control", RFC 5681, DOI 10.17487/RFC5681, September 2009, <http://www.rfc-editor.org/info/rfc5681>.
[RFC5681]Allman，M.，Paxson，V.和E.Blanton，“TCP拥塞控制”，RFC 5681，DOI 10.17487/RFC56812009年9月<http://www.rfc-editor.org/info/rfc5681>.
[RFC6679] Westerlund, M., Johansson, I., Perkins, C., O'Hanlon, P., and K. Carlberg, "Explicit Congestion Notification (ECN) for RTP over UDP", RFC 6679, DOI 10.17487/RFC6679, August 2012, <http://www.rfc-editor.org/info/rfc6679>.
[RFC6679]Westerlund，M.，Johansson，I.，Perkins，C.，O'Hanlon，P.，和K.Carlberg，“UDP上RTP的显式拥塞通知（ECN）”，RFC 6679，DOI 10.17487/RFC66792012年8月<http://www.rfc-editor.org/info/rfc6679>.
[RFC7761] Fenner, B., Handley, M., Holbrook, H., Kouvelas, I., Parekh, R., Zhang, Z., and L. Zheng, "Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol Specification (Revised)", STD 83, RFC 7761, DOI 10.17487/RFC7761, March 2016, <http://www.rfc-editor.org/info/rfc7761>.
[RFC7761]Fenner，B.，Handley，M.，Holbrook，H.，Kouvelas，I.，Parekh，R.，Zhang，Z.，和L.Zheng，“协议独立多播-稀疏模式（PIM-SM）：协议规范（修订版）”，STD 83，RFC 7761，DOI 10.17487/RFC7761，2016年3月<http://www.rfc-editor.org/info/rfc7761>.
[RFC7893] Stein, Y(J)., Black, D., and B. Briscoe, "Pseudowire Congestion Considerations", RFC 7893, DOI 10.17487/RFC7893, June 2016, <http://www.rfc-editor.org/info/rfc7893>.
[RFC7893]Stein，Y（J.），Black，D.和B.Briscoe，“伪线路拥塞考虑”，RFC 7893，DOI 10.17487/RFC7893，2016年6月<http://www.rfc-editor.org/info/rfc7893>.
[RFC8083] Perkins, C. and V. Singh, "Multimedia Congestion Control: Circuit Breakers for Unicast RTP Sessions", RFC 8083, DOI 10.17487/RFC8083, March 2017, <http://www.rfc-editor.org/info/rfc8083>.
[RFC8083]Perkins，C.和V.Singh，“多媒体拥塞控制：单播RTP会话的断路器”，RFC 8083，DOI 10.17487/RFC8083，2017年3月<http://www.rfc-editor.org/info/rfc8083>.
Acknowledgments
致谢
There are many people who have discussed and described the issues that have motivated this document. Contributions and comments included: Lars Eggert, Colin Perkins, David Black, Matt Mathis, Andrew McGregor, Bob Briscoe, and Eliot Lear. This work was partly funded by the European Community under its Seventh Framework Programme through the Reducing Internet Transport Latency (RITE) project (ICT-317700).
许多人讨论并描述了推动本文件的问题。贡献和评论包括：拉尔斯·艾格特、科林·珀金斯、大卫·布莱克、马特·马蒂斯、安德鲁·麦格雷戈、鲍勃·布里斯科和艾略特·李尔。这项工作部分由欧洲共同体第七个框架方案通过减少互联网传输延迟（RITE）项目（ICT-317700）提供资金。
Author's Address
作者地址
Godred Fairhurst University of Aberdeen School of Engineering Fraser Noble Building Aberdeen, Scotland AB24 3UE United Kingdom
GoRead FelHurt阿伯丁大学工程学院弗雷泽贵族建筑苏格兰阿伯丁英国AB24 3UE英国
Email: gorry@erg.abdn.ac.uk
URI: http://www.erg.abdn.ac.uk
Email: gorry@erg.abdn.ac.uk
URI: http://www.erg.abdn.ac.uk