Internet Engineering Task Force (IETF) D. Black, Ed.
Request for Comments: 7657 EMC
Category: Informational P. Jones
ISSN: 2070-1721 Cisco
November 2015
Internet Engineering Task Force (IETF) D. Black, Ed.
Request for Comments: 7657 EMC
Category: Informational P. Jones
ISSN: 2070-1721 Cisco
November 2015
Differentiated Services (Diffserv) and Real-Time Communication
区分服务（Diffserv）与实时通信
Abstract
摘要
This memo describes the interaction between Differentiated Services (Diffserv) network quality-of-service (QoS) functionality and real-time network communication, including communication based on the Real-time Transport Protocol (RTP). Diffserv is based on network nodes applying different forwarding treatments to packets whose IP headers are marked with different Diffserv Codepoints (DSCPs). WebRTC applications, as well as some conferencing applications, have begun using the Session Description Protocol (SDP) bundle negotiation mechanism to send multiple traffic streams with different QoS requirements using the same network 5-tuple. The results of using multiple DSCPs to obtain different QoS treatments within a single network 5-tuple have transport protocol interactions, particularly with congestion control functionality (e.g., reordering). In addition, DSCP markings may be changed or removed between the traffic source and destination. This memo covers the implications of these Diffserv aspects for real-time network communication, including WebRTC.
本备忘录描述了区分服务（Diffserv）网络服务质量（QoS）功能与实时网络通信（包括基于实时传输协议（RTP）的通信）之间的交互。区分服务是基于网络节点对IP头标记有不同区分服务码点（DSCP）的数据包应用不同的转发处理。WebRTC应用程序以及一些会议应用程序已经开始使用会话描述协议（SDP）捆绑协商机制，使用相同的网络5元组发送具有不同QoS要求的多个流量流。使用多个DSCP在单个网络5元组中获得不同QoS处理的结果具有传输协议交互，特别是具有拥塞控制功能（例如，重新排序）。此外，DSCP标记可以在交通源和目的地之间更改或删除。本备忘录涵盖了这些区分服务方面对实时网络通信（包括WebRTC）的影响。
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 5741.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。并非IESG批准的所有文件都适用于任何级别的互联网标准；见RFC 5741第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/rfc7657.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc7657.
Copyright Notice
版权公告
Copyright (c) 2015 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2015 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. Real-Time Communications . . . . . . . . . . . . . . . . . . 3
2.1. RTP Background . . . . . . . . . . . . . . . . . . . . . 4
2.2. RTP Multiplexing . . . . . . . . . . . . . . . . . . . . 6
3. Differentiated Services (Diffserv) . . . . . . . . . . . . . 7
3.1. Diffserv Per-Hop Behaviors (PHBs) . . . . . . . . . . . . 10
3.2. Traffic Classifiers and DSCP Remarking . . . . . . . . . 10
4. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 12
5. Diffserv Interactions . . . . . . . . . . . . . . . . . . . . 13
5.1. Diffserv, Reordering, and Transport Protocols . . . . . . 13
5.2. Diffserv, Reordering, and Real-Time Communication . . . . 15
5.3. Drop Precedence and Transport Protocols . . . . . . . . . 16
5.4. Diffserv and RTCP . . . . . . . . . . . . . . . . . . . . 17
6. Guidelines . . . . . . . . . . . . . . . . . . . . . . . . . 18
7. Security Considerations . . . . . . . . . . . . . . . . . . . 19
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 20
8.1. Normative References . . . . . . . . . . . . . . . . . . 20
8.2. Informative References . . . . . . . . . . . . . . . . . 22
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 26
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 26
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Real-Time Communications . . . . . . . . . . . . . . . . . . 3
2.1. RTP Background . . . . . . . . . . . . . . . . . . . . . 4
2.2. RTP Multiplexing . . . . . . . . . . . . . . . . . . . . 6
3. Differentiated Services (Diffserv) . . . . . . . . . . . . . 7
3.1. Diffserv Per-Hop Behaviors (PHBs) . . . . . . . . . . . . 10
3.2. Traffic Classifiers and DSCP Remarking . . . . . . . . . 10
4. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 12
5. Diffserv Interactions . . . . . . . . . . . . . . . . . . . . 13
5.1. Diffserv, Reordering, and Transport Protocols . . . . . . 13
5.2. Diffserv, Reordering, and Real-Time Communication . . . . 15
5.3. Drop Precedence and Transport Protocols . . . . . . . . . 16
5.4. Diffserv and RTCP . . . . . . . . . . . . . . . . . . . . 17
6. Guidelines . . . . . . . . . . . . . . . . . . . . . . . . . 18
7. Security Considerations . . . . . . . . . . . . . . . . . . . 19
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 20
8.1. Normative References . . . . . . . . . . . . . . . . . . 20
8.2. Informative References . . . . . . . . . . . . . . . . . 22
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 26
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 26
This memo describes the interactions between Differentiated Services (Diffserv) network quality-of-service (QoS) functionality [RFC2475] and real-time network communication, including communication based on the Real-time Transport Protocol (RTP) [RFC3550]. Diffserv is based on network nodes applying different forwarding treatments to packets whose IP headers are marked with different Diffserv Codepoints (DSCPs) [RFC2474]. In the past, distinct RTP streams have been sent over different transport-level flows, sometimes multiplexed with the RTP Control Protocol (RTCP). WebRTC applications, as well as some conferencing applications, are now using the Session Description Protocol (SDP) [RFC4566] bundle negotiation mechanism [SDP-BUNDLE] to send multiple traffic streams with different QoS requirements using the same network 5-tuple. The results of using multiple DSCPs to obtain different QoS treatments within a single network 5-tuple have transport protocol interactions, particularly with congestion control functionality (e.g., reordering). In addition, DSCP markings may be changed or removed between the traffic source and destination. This memo covers the implications of these Diffserv aspects for real-time network communication, including WebRTC traffic [WEBRTC-OVERVIEW].
本备忘录描述了区分服务（Diffserv）网络服务质量（QoS）功能[RFC2475]与实时网络通信（包括基于实时传输协议（RTP）[RFC3550]的通信）之间的交互。Diffserv基于网络节点对IP头标记有不同Diffserv码点（DSCP）的数据包应用不同的转发处理[RFC2474]。过去，不同的RTP流通过不同的传输级别流发送，有时与RTP控制协议（RTCP）进行多路复用。WebRTC应用程序以及一些会议应用程序现在正在使用会话描述协议（SDP）[RFC4566]捆绑协商机制[SDP-bundle]，使用相同的网络5元组发送具有不同QoS要求的多个流量流。使用多个DSCP在单个网络5元组中获得不同QoS处理的结果具有传输协议交互，特别是具有拥塞控制功能（例如，重新排序）。此外，DSCP标记可以在交通源和目的地之间更改或删除。本备忘录涵盖了这些区分服务方面对实时网络通信的影响，包括WebRTC流量[WebRTC-OVERVIEW]。
The memo is organized as follows. Background is provided in Section 2 on real-time communications and Section 3 on Differentiated Services. Section 4 describes some examples of Diffserv usage with real-time communications. Section 5 explains how use of Diffserv features interacts with both transport and real-time communications protocols and Section 6 provides guidance on Diffserv feature usage to control undesired interactions. Security considerations are discussed in Section 7.
备忘录的结构如下。第2节“实时通信”和第3节“差异化服务”提供了背景信息。第4节描述了使用实时通信的Diffserv的一些示例。第5节解释了区分服务功能的使用如何与传输和实时通信协议交互，第6节提供了关于区分服务功能使用的指导，以控制不希望的交互。第7节讨论了安全注意事项。
Real-time communications enables communication in real time over an IP network using voice, video, text, content sharing, etc. It is possible to use more than one of these modes concurrently to provide a rich communication experience.
实时通信允许通过IP网络使用语音、视频、文本、内容共享等进行实时通信。可以同时使用这些模式中的一种以上，以提供丰富的通信体验。
A simple example of real-time communications is a voice call placed over the Internet where an audio stream is transmitted in each direction between two users. A more complex example is an immersive videoconferencing system that has multiple video screens, multiple cameras, multiple microphones, and some means of sharing content. For such complex systems, there may be multiple media and non-media streams transmitted via a single IP address and port or via multiple IP addresses and ports.
实时通信的一个简单示例是通过互联网进行的语音呼叫，其中音频流在两个用户之间的每个方向上传输。一个更复杂的例子是一个沉浸式视频会议系统，它有多个视频屏幕、多个摄像头、多个麦克风和一些共享内容的方式。对于此类复杂系统，可能存在通过单个IP地址和端口或通过多个IP地址和端口传输的多个媒体和非媒体流。
The most common protocol used for real-time media is RTP [RFC3550]. RTP defines a common encapsulation format and handling rules for real-time data transmitted over the Internet. Unfortunately, RTP terminology usage has been inconsistent. For example, RFC 7656 [RFC7656] on RTP terminology observes that:
实时媒体最常用的协议是RTP[RFC3550]。RTP为通过Internet传输的实时数据定义了通用的封装格式和处理规则。不幸的是，RTP术语的使用一直不一致。例如，RTP术语中的RFC 7656[RFC7656]指出：
RTP [RFC3550] uses media stream, audio stream, video stream, and a stream of (RTP) packets interchangeably, which are all RTP streams.
RTP[RFC3550]可交换地使用媒体流、音频流、视频流和（RTP）包流，它们都是RTP流。
Terminology in this memo is based on that RTP terminology document with the following terms being of particular importance (see that terminology document for full definitions):
本备忘录中的术语以RTP术语文件为基础，以下术语特别重要（完整定义见术语文件）：
Source Stream: A reference clock synchronized, time progressing, digital media stream.
源流：同步的参考时钟、时间进程、数字媒体流。
RTP Stream: A stream of RTP packets containing media data, which may be source data or redundant data. The RTP stream is identified by an RTP synchronization source (SSRC) belonging to a particular RTP session. An RTP stream may be a secured RTP stream when RTP-based security is used.
RTP流：包含媒体数据的RTP数据包流，媒体数据可以是源数据或冗余数据。RTP流由属于特定RTP会话的RTP同步源（SSRC）标识。当使用基于RTP的安全性时，RTP流可以是安全的RTP流。
In addition, this memo follows [RFC3550] in using the term "SSRC" to designate both the identifier of an RTP stream and the entity that sends that RTP stream.
此外，本备忘录在[RFC3550]之后使用术语“SSRC”来指定RTP流的标识符和发送该RTP流的实体。
Media encoding and packetization of a source stream results in a source RTP stream plus zero or more redundancy RTP streams that provide resilience against loss of packets from the source RTP stream [RFC7656]. Redundancy information may also be carried in the same RTP stream as the encoded source stream, e.g., see Section 7.2 of [RFC5109]. With most applications, a single media type (e.g., audio) is transmitted within a single RTP session. However, it is possible to transmit multiple, distinct source streams over the same RTP session as one or more individual RTP streams. This is referred to as RTP multiplexing. In addition, an RTP stream may contain multiple source streams, e.g., components or programs in an MPEG Transport Stream [H.221].
源流的媒体编码和打包导致源RTP流加上零个或多个冗余RTP流，这些冗余RTP流提供了针对来自源RTP流的数据包丢失的恢复能力[RFC7656]。冗余信息也可在与编码源流相同的RTP流中携带，例如，参见[RFC5109]第7.2节。对于大多数应用程序，单个媒体类型（例如音频）在单个RTP会话中传输。然而，可以通过与一个或多个单独的RTP流相同的RTP会话来传输多个不同的源流。这被称为RTP多路复用。此外，RTP流可以包含多个源流，例如MPEG传输流中的组件或程序[H.221]。
The number of source streams and RTP streams in an overall real-time interaction can be surprisingly large. In addition to a voice source stream and a video source stream, there could be separate source streams for each of the cameras or microphones on a videoconferencing system. As noted above, there might also be separate redundancy RTP streams that provide protection to a source RTP stream, using
整个实时交互中的源流和RTP流的数量可能会惊人地大。除了语音源流和视频源流之外，视频会议系统上的每个摄像机或麦克风都可以有单独的源流。如上所述，还可能存在单独的冗余RTP流，它们使用
techniques such as forward error correction. Another example is simulcast transmission, where a video source stream can be transmitted as high resolution and low resolution RTP streams at the same time. In this case, a media processing function might choose to send one or both RTP streams onward to a receiver based on bandwidth availability or who the active speaker is in a multipoint conference. Lastly, a transmitter might send the same media content concurrently as two RTP streams using different encodings (e.g., video encoded as VP8 [RFC6386] in parallel with H.264 [H.264]) to allow a media processing function to select a media encoding that best matches the capabilities of the receiver.
前向纠错等技术。另一个例子是同播传输，其中视频源流可以同时作为高分辨率和低分辨率RTP流传输。在这种情况下，媒体处理功能可以基于带宽可用性或活动扬声器在多点会议中的身份选择将一个或两个RTP流向前发送到接收器。最后，发射机可以使用不同的编码（例如，与H.264[H.264]并行编码为VP8[RFC6386]的视频）作为两个RTP流同时发送相同的媒体内容，以允许媒体处理功能选择与接收机的能力最匹配的媒体编码。
For the WebRTC protocol suite [WEBRTC-TRANSPORTS], an individual source stream is a MediaStreamTrack, and a MediaStream contains one or more MediaStreamTracks [W3C.WD-mediacapture-streams-20130903]. A MediaStreamTrack is transmitted as a source RTP stream plus zero or more redundant RTP streams, so a MediaStream that consists of one MediaStreamTrack is transmitted as a single source RTP stream plus zero or more redundant RTP streams. For more information on use of RTP in WebRTC, see [RTP-USAGE].
对于WebRTC协议套件[WebRTC-TRANSPORTS]，单个源流是MediaStreamTrack，而MediaStream包含一个或多个MediaStreamTrack[W3C.WD-mediacapture-streams-20130903]。MediaStreamTrack作为源RTP流加上零个或多个冗余RTP流传输，因此由一个MediaStreamTrack组成的MediaStream作为单个源RTP流加上零个或多个冗余RTP流传输。有关在WebRTC中使用RTP的更多信息，请参阅[RTP-USAGE]。
RTP is usually carried over a datagram protocol, such as UDP [RFC768], UDP-Lite [RFC3828], or the Datagram Congestion Control Protocol (DCCP) [RFC4340]; UDP is most commonly used, but a non-datagram protocol (e.g., TCP [RFC793]) may also be used. Transport protocols other than UDP or UDP-Lite may also be used to transmit real-time data or near-real-time data. For example, the Stream Control Transmission Protocol (SCTP) [RFC4960] can be utilized to carry application-sharing or whiteboarding information as part of an overall interaction that includes real-time media. These additional transport protocols can be multiplexed with an RTP session via UDP encapsulation, thereby using a single pair of UDP ports.
RTP通常通过数据报协议进行传输，如UDP[RFC768]、UDP Lite[RFC3828]或数据报拥塞控制协议（DCCP）[RFC4340]；UDP是最常用的，但也可以使用非数据报协议（例如TCP[RFC793]）。UDP或UDP Lite以外的传输协议也可用于传输实时数据或近实时数据。例如，流控制传输协议（SCTP）[RFC4960]可用于承载应用程序共享或白板信息，作为包括实时媒体的整体交互的一部分。这些额外的传输协议可以通过UDP封装与RTP会话复用，从而使用一对UDP端口。
The WebRTC protocol suite encompasses a number of forms of multiplexing:
WebRTC协议套件包含多种形式的多路复用：
1. Individual source streams are carried in one or more individual RTP streams. These RTP streams can be multiplexed onto a single transport-layer flow or sent as separate transport-layer flows. This memo only considers the case where the RTP streams are to be multiplexed onto a single transport-layer flow, forming a single RTP session as described in [RFC3550];
1. 单个源流在一个或多个单个RTP流中承载。这些RTP流可以多路复用到单个传输层流上，或者作为单独的传输层流发送。本备忘录仅考虑RTP流被多路复用到单个传输层流上，形成单个RTP会话的情况，如[RFC3550]中所述；
2. RTCP (see [RFC3550]) may be multiplexed onto the same transport-layer flow as the RTP streams with which it is associated, as described in [RFC5761], or it may be sent on a separate transport-layer flow;
2. RTCP（参见[RFC3550]）可以被多路复用到与其关联的RTP流相同的传输层流上，如[RFC5761]中所述，或者可以在单独的传输层流上发送；
3. An RTP session could be multiplexed with a single SCTP association over Datagram Transport Layer Security (DTLS) and with both Session Traversal Utilities for NAT (STUN) [RFC5389] and TURN [RFC5766] traffic into a single transport-layer flow as described in [RFC5764] with the updates in [SRTP-DTLS]. The STUN [RFC5389] and Traversal Using Relays around NAT (TURN) [RFC5766] protocols provide NAT/FW (Network Address Translator / Firewall) traversal and port mapping.
3. RTP会话可以通过数据报传输层安全性（DTLS）和NAT（STUN）[RFC5389]的两个会话遍历实用程序与单个SCTP关联进行多路复用，并将[RFC5766]通信量转换为[RFC5764]中所述的单个传输层流，并在[SRTP-DTLS]中进行更新。STUN[RFC5389]和使用NAT（TURN）[RFC5766]协议周围的中继进行的遍历提供了NAT/FW（网络地址转换器/防火墙）遍历和端口映射。
The resulting transport-layer flow is identified by a network 5-tuple, i.e., a combination of two IP addresses (source and destination), two ports (source and destination), and the transport protocol used (e.g., UDP). SDP bundle negotiation restrictions [SDP-BUNDLE] limit WebRTC to using at most a single DTLS session per network 5-tuple. In contrast to WebRTC use of a single SCTP association with DTLS, multiple SCTP associations can be directly multiplexed over a single UDP 5-tuple as specified in [RFC6951].
由此产生的传输层流由网络5元组标识，即两个IP地址（源和目标）、两个端口（源和目标）和所使用的传输协议（例如UDP）的组合。SDP包协商限制[SDP-bundle]将WebRTC限制为每个网络5元组最多使用一个DTLS会话。与WebRTC使用单个SCTP关联和DTL不同，多个SCTP关联可以直接在单个UDP 5元组上多路复用，如[RFC6951]中所述。
The STUN and TURN protocols were originally designed to use UDP as a transport; however, TURN has been extended to use TCP as a transport for situations in which UDP does not work [RFC6062]. When TURN selects use of TCP, the entire real-time communications session is carried over a single TCP connection (i.e., 5-tuple).
STUN和TURN协议最初设计为使用UDP作为传输；但是，TURN已扩展为在UDP不工作的情况下使用TCP作为传输[RFC6062]。当TURN选择使用TCP时，整个实时通信会话通过单个TCP连接（即5元组）进行。
For IPv6, addition of the flow label [RFC6437] to network 5-tuples results in network 6-tuples (or 7-tuples for bidirectional flows), but in practice, use of a flow label is unlikely to result in a finer-grain traffic subset than the corresponding network 5-tuple (e.g., the flow label is likely to represent the combination of two ports with use of the UDP protocol). For that reason, discussion in this document focuses on UDP 5-tuples.
对于IPv6，向网络5元组添加流标签[RFC6437]会产生网络6元组（或双向流的7元组），但在实践中，使用流标签不太可能产生比相应网络5元组更细粒度的流量子集（例如，流标签可能表示使用UDP协议的两个端口的组合）。因此，本文档中的讨论重点是UDP 5元组。
Section 2.1 explains how source streams can be multiplexed in a single RTP session, which can in turn be multiplexed over UDP with packets generated by other transport protocols. This section provides background on why this level of multiplexing is desirable. The rationale in this section applies both to multiplexing of source streams in a single RTP session and multiplexing of an RTP session with traffic from other transport protocols via UDP encapsulation.
第2.1节解释了如何在单个RTP会话中复用源流，而RTP会话又可以通过UDP与其他传输协议生成的数据包进行复用。本节介绍了为什么需要这种级别的多路复用。本节中的基本原理既适用于单个RTP会话中源流的多路复用，也适用于RTP会话通过UDP封装与来自其他传输协议的流量进行多路复用。
Multiplexing reduces the number of ports utilized for real-time and related communication in an overall interaction. While a single endpoint might have plenty of ports available for communication, this traffic often traverses points in the network that are constrained on the number of available ports or whose performance degrades as the number of ports in use increases. A good example is a NAT/FW device
多路复用减少了在整体交互中用于实时和相关通信的端口数量。虽然单个端点可能有大量端口可用于通信，但此通信量通常会穿越网络中受可用端口数量限制的点，或者其性能会随着使用的端口数量的增加而降低。一个很好的例子是NAT/FW设备
sitting at the network edge. As the number of simultaneous protocol sessions increases, so does the burden placed on these devices to provide port mapping.
坐在网络边缘。随着同步协议会话数量的增加，这些设备在提供端口映射方面的负担也随之增加。
Another reason for multiplexing is to help reduce the time required to establish bidirectional communication. Since any two communicating users might be situated behind different NAT/FW devices, it is necessary to employ techniques like STUN and TURN along with Interactive Connectivity Establishment (ICE) [RFC5245] to get traffic to flow between the two devices [WEBRTC-TRANSPORTS]. Performing the tasks required by these protocols takes time, especially when multiple protocol sessions are involved. While tasks for different sessions can be performed in parallel, it is nonetheless necessary for applications to wait for all sessions to be opened before communication between two users can begin. Reducing the number of STUN/ICE/TURN steps reduces the likelihood of loss of a packet for one of these protocols; any such loss adds delay to setting up a communication session. Further, reducing the number of STUN/ICE/TURN tasks places a lower burden on the STUN and TURN servers.
多路复用的另一个原因是帮助减少建立双向通信所需的时间。由于任何两个通信用户可能位于不同的NAT/FW设备后面，因此有必要采用类似STUN和TURN以及交互式连接建立（ICE）[RFC5245]的技术，以使流量在两个设备之间流动[WEBRTC-TRANSPORTS]。执行这些协议要求的任务需要时间，特别是当涉及多个协议会话时。虽然不同会话的任务可以并行执行，但应用程序必须等待所有会话打开，然后才能开始两个用户之间的通信。减少STUN/ICE/TURN步骤的数量可降低这些协议之一的数据包丢失的可能性；任何此类丢失都会增加建立通信会话的延迟。此外，减少眩晕/冰上/转身任务的数量会降低眩晕和转身服务器的负担。
Multiplexing may reduce the complexity and resulting load on an endpoint. A single instance of STUN/ICE/TURN is simpler to execute and manage than multiple instances STUN/ICE/TURN operations happening in parallel, as the latter require synchronization and create more complex failure situations that have to be cleaned up by additional code.
多路复用可以降低复杂性和端点上产生的负载。STUN/ICE/TURN的单个实例比并行执行的多个实例STUN/ICE/TURN操作更易于执行和管理，因为后者需要同步，并产生更复杂的故障情况，必须通过附加代码来清除。
The Diffserv architecture [RFC2475][RFC4594] is intended to enable scalable service discrimination in the Internet without requiring each node in the network to store per-flow state and participate in per-flow signaling. The services may be end to end or within a network; they include both those that can satisfy quantitative performance requirements (e.g., peak bandwidth) and those based on relative performance (e.g., "class" differentiation). Services can be constructed by a combination of well-defined building blocks deployed in network nodes that:
Diffserv体系结构[RFC2475][RFC4594]旨在实现互联网中的可伸缩服务区分，而不需要网络中的每个节点存储每流状态并参与每流信令。服务可以是端到端或在网络内；它们包括能够满足定量性能要求（例如，峰值带宽）和基于相对性能的要求（例如，“等级”差异）。服务可以由部署在网络节点中的定义良好的构建块组合而成，这些构建块：
o classify traffic and set bits in an IP header field at network boundaries or hosts,
o 在网络边界或主机的IP报头字段中对流量进行分类并设置位，
o use those bits to determine how packets are forwarded by the nodes inside the network, and
o 使用这些位确定网络内节点如何转发数据包，以及
o condition the marked packets at network boundaries in accordance with the requirements or rules of each service.
o 根据每个服务的要求或规则，在网络边界处调整标记的数据包。
Traffic conditioning may include changing the DSCP in a packet (remarking it), delaying the packet (as a consequence of traffic shaping), or dropping the packet (as a consequence of traffic policing).
流量调节可包括改变分组中的DSCP（对其进行标记）、延迟分组（作为流量整形的结果）或丢弃分组（作为流量管理的结果）。
A network node that supports Diffserv includes a classifier that selects packets based on the value of the DS field in IP headers (the Diffserv codepoint or DSCP), along with buffer management and packet scheduling mechanisms capable of delivering the specific packet forwarding treatment indicated by the DS field value. Setting of the DS field and fine-grain conditioning of marked packets need only be performed at network boundaries; internal network nodes operate on traffic aggregates that share a DS field value, or in some cases, a small set of related values.
支持区分服务的网络节点包括分类器，该分类器基于IP报头中DS字段的值（区分服务码点或DSCP）选择分组，以及能够交付由DS字段值指示的特定分组转发处理的缓冲器管理和分组调度机制。仅需在网络边界处执行DS场的设置和标记分组的细粒度调节；内部网络节点在共享DS字段值或在某些情况下共享一小组相关值的流量聚合上运行。
The Diffserv architecture [RFC2475] maintains distinctions among:
Diffserv体系结构[RFC2475]保持了以下区别：
o the QoS service provided to a traffic aggregate,
o 向流量聚合提供的QoS服务，
o the conditioning functions and per-hop behaviors (PHBs) used to realize services,
o 用于实现服务的调节功能和每跳行为（PHB），
o the DSCP in the IP header used to mark packets to select a per-hop behavior, and
o IP报头中用于标记数据包以选择每跳行为的DSCP，以及
o the particular implementation mechanisms that realize a per-hop behavior.
o 实现每跳行为的特定实现机制。
This memo focuses on PHBs and the usage of DSCPs to obtain those behaviors. In a network node's forwarding path, the DSCP is used to map a packet to a particular forwarding treatment, or to a per-hop behavior (PHB) that specifies the forwarding treatment.
本备忘录重点关注PHB和DSCP的使用，以获得这些行为。在网络节点的转发路径中，DSCP用于将数据包映射到特定的转发处理，或映射到指定转发处理的每跳行为（PHB）。
The specification of a PHB describes the externally observable forwarding behavior of a network node for network traffic marked with a DSCP that selects that PHB. In this context, "forwarding behavior" is a general concept - for example, if only one DSCP is used for all traffic on a link, the observable forwarding behavior (e.g., loss, delay, jitter) will often depend only on the loading of the link. To obtain useful behavioral differentiation, multiple traffic subsets are marked with different DSCPs for different PHBs for which node resources such as buffer space and bandwidth are allocated. PHBs provide the framework for a Diffserv network node to allocate resources to traffic subsets, with network-scope Differentiated Services constructed on top of this basic hop-by-hop resource allocation mechanism.
PHB规范描述了网络节点的外部可观察转发行为，该网络节点的网络流量由选择该PHB的DSCP标记。在这种情况下，“转发行为”是一个一般概念——例如，如果一条链路上的所有流量只使用一个DSCP，则可观察到的转发行为（例如，丢失、延迟、抖动）通常仅取决于链路的负载。为了获得有用的行为差异，多个流量子集被标记为不同的DSCP，用于分配节点资源（如缓冲空间和带宽）的不同PHB。phb为Diffserv网络节点提供了向流量子集分配资源的框架，在这种基本的逐跳资源分配机制的基础上构建了网络范围区分服务。
The codepoints (DSCPs) may be chosen from a small set of fixed values (the class selector codepoints), from a set of recommended values defined in PHB specifications, or from values that have purely local meanings to a specific network that supports Diffserv; in general, packets may be forwarded across multiple such networks between source and destination.
代码点（DSCP）可以从一小组固定值（类选择器代码点）、从PHB规范中定义的一组推荐值或从对支持区分服务的特定网络具有纯本地意义的值中选择；通常，包可以在源和目的地之间跨多个这样的网络转发。
The mandatory DSCPs are the class selector codepoints as specified in [RFC2474]. The class selector codepoints (CS0-CS7) extend the deprecated concept of IP Precedence in the IPv4 header; three bits are added, so that the class selector DSCPs are of the form 'xxx000'. The all-zero DSCP ('000000' or CS0) is always assigned to a Default PHB that provides best-effort forwarding behavior, and the remaining class selector codepoints are intended to provide relatively better per-hop-forwarding behavior in increasing numerical order, but:
强制性DSCP是[RFC2474]中规定的类选择器代码点。类选择器代码点（CS0-CS7）扩展了IPv4报头中不推荐使用的IP优先级概念；添加三位，以便类选择器DSCP的形式为“xxx000”。全零DSCP（'000000'或CS0）始终分配给提供尽力而为转发行为的默认PHB，剩余的类选择器代码点旨在以递增的数字顺序提供相对更好的每跳转发行为，但：
o A network endpoint cannot rely upon different class selector codepoints providing Differentiated Services via assignment to different PHBs, as adjacent class selector codepoints may use the same pool of resources on each network node in some networks. This generalizes to ranges of class selector codepoints, but with limits -- for example, CS6 and CS7 are often used for network control (e.g., routing) traffic [RFC4594] and hence are likely to provide better forwarding behavior under network load to prioritize network recovery from disruptions. There is no effective way for a network endpoint to determine which PHBs are selected by the class selector codepoints on a specific network, let alone end to end.
o 网络端点不能依赖于通过分配给不同PHB来提供不同服务的不同类别选择器码点，因为在某些网络中，相邻类别选择器码点可能在每个网络节点上使用相同的资源池。这概括了类选择器代码点的范围，但有一些限制——例如，CS6和CS7通常用于网络控制（例如，路由）流量[RFC4594]，因此可能在网络负载下提供更好的转发行为，以优先考虑网络中断恢复。网络端点没有有效的方法来确定由特定网络上的类选择器代码点选择哪些PHB，更不用说端到端了。
o CS1 ('001000') was subsequently designated as the recommended codepoint for the Lower Effort (LE) PHB [RFC3662]. An LE service forwards traffic with "lower" priority than best effort and can be "starved" by best-effort and other "higher" priority traffic. Not all networks offer an LE service, hence traffic marked with the CS1 DSCP may not receive lower effort forwarding; such traffic may be forwarded with a different PHB (e.g., the Default PHB), remarked to another DSCP (e.g., CS0) and forwarded accordingly, or dropped. A network endpoint cannot rely upon the presence of an LE service that is selected by the CS1 DSCP on a specific network, let alone end to end. Packets marked with the CS1 DSCP may be forwarded with best-effort service or another "higher" priority service; see [RFC2474]. See [RFC3662] for further discussion of the LE PHB and service.
o CS1（“001000”）随后被指定为较低工作量（LE）PHB[RFC3662]的建议代码点。LE服务转发优先级比尽力而为“低”的流量，并且可能被尽力而为和其他“高”优先级流量“饿死”。并非所有的网络都提供LE服务，所以用CS1 DSCP标记的流量可能不会收到较低的转发工作量；此类流量可使用不同的PHB（例如，默认PHB）转发，标记到另一个DSCP（例如，CS0）并相应转发，或丢弃。网络端点不能依赖于CS1 DSCP在特定网络上选择的LE服务的存在，更不用说端到端了。标记有CS1 DSCP的分组可以用尽力而为服务或另一个“更高”优先级服务转发；见[RFC2474]。有关LE PHB和服务的进一步讨论，请参见[RFC3662]。
Although Differentiated Services is a general architecture that may be used to implement a variety of services, three fundamental forwarding behaviors (PHBs) have been defined and characterized for general use. These are:
尽管区分服务是一种可用于实现各种服务的通用体系结构，但已定义并描述了三种基本转发行为（PHB）以供通用。这些是：
1. Default Forwarding (DF) for elastic traffic [RFC2474]. The Default PHB is always selected by the all-zero DSCP and provides best-effort forwarding.
1. 弹性流量的默认转发（DF）[RFC2474]。默认PHB始终由全零DSCP选择，并提供尽力而为的转发。
2. Assured Forwarding (AF) [RFC2597] to provide Differentiated Service to elastic traffic. Each instance of the AF behavior consists of three PHBs that differ only in drop precedence, e.g., AF11, AF12, and AF13; such a set of three AF PHBs is referred to as an AF class, e.g., AF1x. There are four defined AF classes, AF1x through AF4x, with higher numbered classes intended to receive better forwarding treatment than lower numbered classes. Use of multiple PHBs from a single AF class (e.g., AF1x) does not enable network traffic reordering within a single network 5-tuple, although such reordering may occur for other transient reasons (e.g., routing changes or ECMP rebalancing).
2. 保证转发（AF）[RFC2597]为弹性流量提供差异化服务。AF行为的每个实例由三个仅在丢弃优先级上不同的PHB组成，例如AF11、AF12和AF13；这样一组三个AF phb被称为AF类，例如AF1x。有四个定义的AF类，从AF1x到AF4x，编号较高的类要比编号较低的类接受更好的转发处理。使用单个AF类（例如AF1x）中的多个PHB不会在单个网络5元组中启用网络流量重新排序，尽管这种重新排序可能由于其他瞬态原因（例如路由更改或ECMP重新平衡）而发生。
3. Expedited Forwarding (EF) [RFC3246] intended for inelastic traffic. Beyond the basic EF PHB, the VOICE-ADMIT PHB [RFC5865] is an admission-controlled variant of the EF PHB. Both of these PHBs are based on preconfigured limited forwarding capacity; traffic in excess of that capacity is expected to be dropped.
3. 用于非弹性流量的快速转发（EF）[RFC3246]。除了基本EF PHB之外，语音准入PHB[RFC5865]是EF PHB的准入控制变体。这两个PHB都基于预配置的有限转发容量；超过该容量的流量预计将减少。
DSCP markings are not end to end in general. Each network can make its own decisions about what PHBs to use and which DSCP maps to each PHB. While every PHB specification includes a recommended DSCP, and RFC 4594 [RFC4594] recommends their end-to-end usage, there is no requirement that every network support any PHBs (aside from the Default PHB for best-effort forwarding) or use any specific DSCPs, with the exception of the support requirements for the class selector codepoints (see RFC 2474 [RFC2474]). When Diffserv is used, the edge or boundary nodes of a network are responsible for ensuring that all traffic entering that network conforms to that network's policies for DSCP and PHB usage, and such nodes may change DSCP markings on traffic to achieve that result. As a result, DSCP remarking is possible at any network boundary, including the first network node that traffic sent by a host encounters. Remarking is also possible within a network, e.g., for traffic shaping.
DSCP标记通常不是端到端的。每个网络可以自行决定使用哪些PHB以及哪些DSCP映射到每个PHB。虽然每个PHB规范都包括一个推荐的DSCP，RFC 4594[RFC4594]推荐其端到端使用，但不要求每个网络支持任何PHB（除了用于尽力而为转发的默认PHB）或使用任何特定的DSCP，但类选择器代码点的支持要求除外（参见RFC 2474[RFC2474]）。使用Diffserv时，网络的边缘或边界节点负责确保进入该网络的所有流量符合该网络的DSCP和PHB使用策略，并且这些节点可以更改流量上的DSCP标记以实现该结果。因此，DSCP标记可以在任何网络边界上进行，包括first主机发送的流量遇到的网络节点。在网络中也可以进行注释，例如，用于流量整形。
DSCP remarking is part of traffic conditioning; the traffic conditioning functionality applied to packets at a network node is determined by a traffic classifier [RFC2475]. Edge nodes of a Diffserv network classify traffic based on selected packet header fields; typical implementations do not look beyond the traffic's network 5-tuple in the IP and transport protocol headers (e.g., for SCTP or RTP encapsulated in UDP, header-based classification is unlikely to look beyond the outer UDP header). As a result, when multiple DSCPs are used for traffic that shares a network 5-tuple, remarking at a network boundary may result in all of the traffic being forwarded with a single DSCP, thereby removing any differentiation within the network 5-tuple downstream of the remarking location. Network nodes within a Diffserv network generally classify traffic based solely on DSCPs, but may perform finer-grain traffic conditioning similar to that performed by edge nodes.
DSCP注释是交通调节的一部分；应用于网络节点处的分组的流量调节功能由流量分类器[RFC2475]确定。Diffserv网络的边缘节点基于选定的分组报头字段对业务进行分类；典型的实现不会在IP和传输协议头中查看流量的网络5元组之外（例如，对于封装在UDP中的SCTP或RTP，基于头的分类不太可能查看外部UDP头）。结果，当多个DSCP用于共享网络5元组的流量时，在网络边界处的标记可能导致所有流量与单个DSCP转发，从而消除标记位置下游网络5元组内的任何差异。Diffserv网络中的网络节点通常仅基于DSCP对流量进行分类，但可以执行与边缘节点执行的类似的更细粒度流量调节。
So, for two arbitrary network endpoints, there can be no assurance that the DSCP set at the source endpoint will be preserved and presented at the destination endpoint. Rather, it is quite likely that the DSCP will be set to zero (e.g., at the boundary of a network operator that distrusts or does not use the DSCP field) or to a value deemed suitable by an ingress classifier for whatever network 5-tuple it carries.
因此，对于两个任意网络端点，无法保证源端点处的DSCP集将保留并显示在目标端点处。相反，DSCP很可能被设置为零（例如，在不信任或不使用DSCP字段的网络运营商的边界处），或者被设置为入口分类器认为适合其承载的任何网络5元组的值。
In addition, remarking may remove application-level distinctions in forwarding behavior - e.g., if multiple PHBs within an AF class are used to distinguish different types of frames within a video RTP stream, token-bucket-based remarkers operating in color-blind mode (see [RFC2697] and [RFC2698] for examples) may remark solely based on flow rate and burst behavior, removing the drop precedence distinctions specified by the source.
此外，标记可以消除转发行为中的应用级区别-例如，如果AF类中的多个PHB用于区分视频RTP流中不同类型的帧，则基于令牌桶的标记可以在色盲模式下操作（例如，请参见[RFC2697]和[RFC2698]）可仅基于流速和爆破行为进行注释，消除源指定的跌落优先区分。
Backbone and other carrier networks may employ a small number of DSCPs (e.g., less than half a dozen) to manage a small number of traffic aggregates; hosts that use a larger number of DSCPs can expect to find that much of their intended differentiation is removed by such networks. Better results may be achieved when DSCPs are used to spread traffic among a smaller number of Diffserv-based traffic subsets or aggregates; see [DIFFSERV-INTERCON] for one proposal. This is of particular importance for MPLS-based networks due to the limited size of the Traffic Class (TC) field in an MPLS label [RFC5462] that is used to carry Diffserv information and the use of that TC field for other purposes, e.g., Explicit Congestion Notification (ECN) [RFC5129]. For further discussion on use of Diffserv with MPLS, see [RFC3270] and [RFC5127].
主干网和其他运营商网络可以使用少量DSCP（例如，少于六个）来管理少量的流量聚合；使用大量DSCP的主机可能会发现，它们的大部分预期差异都被此类网络消除了。当使用DSCP在数量较少的基于Diffserv的流量子集或聚合中传播流量时，可以获得更好的结果；请参见[DIFFSERV-INTERCON]了解一个建议。这对于基于MPLS的网络特别重要，因为MPLS标签[RFC5462]中用于承载区分服务信息的流量类别（TC）字段的大小有限，并且该TC字段用于其他目的，例如显式拥塞通知（ECN）[RFC5129]。有关区分服务与MPLS结合使用的进一步讨论，请参阅[RFC3270]和[RFC5127]。
For real-time communications, one might want to mark the audio packets using EF and the video packets as AF41. However, a video conference receiving the audio packets significantly ahead of the video is not useful because lip sync is necessary between audio and video. It may still be desirable to send audio with a PHB that provides better service, because more reliable arrival of audio helps assure smooth audio rendering, which is often more important than fully faithful video rendering. There are also limits, as some devices have difficulties in synchronizing voice and video when packets that need to be rendered together arrive at significantly different times. It makes more sense to use different PHBs when the audio and video source streams do not share a strict timing relationship. For example, video content may be shared within a video conference via playback, perhaps of an unedited video clip that is intended to become part of a television advertisement. Such content sharing video does not need precise synchronization with video conference audio, and could use a different PHB, as content sharing video is more tolerant to jitter, loss, and delay.
对于实时通信，可能需要使用EF将音频分组和视频分组标记为AF41。但是，视频会议在视频之前接收音频数据包并不有用，因为音频和视频之间需要唇形同步。可能仍然希望使用提供更好服务的PHB发送音频，因为更可靠的音频到达有助于确保平滑的音频渲染，这通常比完全忠实的视频渲染更重要。还有一些限制，因为当需要一起呈现的数据包到达明显不同的时间时，一些设备在同步语音和视频方面存在困难。当音频和视频源流不共享严格的定时关系时，使用不同的PHB更有意义。例如，视频内容可以通过回放在视频会议内共享，该回放可能是意图成为电视广告的一部分的未编辑视频剪辑的回放。这种内容共享视频不需要与视频会议音频精确同步，可以使用不同的PHB，因为内容共享视频更能容忍抖动、丢失和延迟。
Within a layered video RTP stream, ordering of frame communication is preferred, but importance of frame types varies, making use of PHBs with different drop precedences appropriate. For example, I-frames that contain an entire image are usually more important than P-frames that contain only changes from the previous image because loss of a P-frame (or part thereof) can be recovered (at the latest) via the next I-frame, whereas loss of an I-frame (or part thereof) may cause rendering problems for all of the P-frames that depend on the missing I-frame. For this reason, it is appropriate to mark I-frame packets with a PHB that has lower drop precedence than the PHB used for P-frames, as long as the PHBs preserve ordering among frames (e.g., are in a single AF class) - AF41 for I-frames and AF43 for P-frames is one possibility. Additional spatial and temporal layers beyond the base video layer could also be marked with higher drop precedence than the base video layer, as their loss reduces video quality, but does not disrupt video rendering.
在分层视频RTP流中，帧通信的顺序是优选的，但是帧类型的重要性不同，使得具有不同丢弃先例的phb的使用是合适的。例如，包含整个图像的I帧通常比仅包含来自前一图像的更改的P帧更重要，因为P帧（或其部分）的丢失可以（最晚）通过下一I帧恢复，而I帧（或其部分）的丢失可能会导致依赖于丢失的I帧的所有P帧的渲染问题。出于这个原因，只要PHB保持帧之间的顺序（例如，在单个AF类中），则使用具有比用于P帧的PHB更低的丢弃优先级的PHB来标记I帧分组是合适的-对于I帧的AF41和对于P帧的AF43是一种可能性。基本视频层之外的其他空间和时间层也可以标记为比基本视频层具有更高的丢弃优先级，因为它们的丢失会降低视频质量，但不会中断视频渲染。
Additional RTP streams in a real-time communication interaction could be marked with CS0 and carried as best-effort traffic. One example is real-time text transmitted as specified in RFC 4103 [RFC4103]. Best-effort forwarding suffices because such real-time text has loose timing requirements; RFC 4103 recommends sending text in chunks every 300 ms. Such text is technically real-time, but does not need a PHB promising better service than best effort, in contrast to audio or video.
实时通信交互中的附加RTP流可以用CS0标记，并作为尽力而为的流量进行传输。一个示例是按照RFC 4103[RFC4103]中的规定传输的实时文本。尽最大努力转发就足够了，因为这样的实时文本具有松散的时间要求；RFC 4103建议每300毫秒发送一次文本块。这种文本在技术上是实时的，但与音频或视频相比，不需要PHB承诺比尽力而为更好的服务。
A WebRTC application may use one or more RTP streams, as discussed above. In addition, it may use an SCTP-based data channel [DATA-CHAN] whose QoS treatment depends on the nature of the application. For example, best-effort treatment of data channels is likely to suffice for messaging, shared white board, and guided browsing applications, whereas latency-sensitive games might desire better QoS for their data channels.
如上所述，WebRTC应用程序可以使用一个或多个RTP流。此外，它可以使用基于SCTP的数据信道[data-CHAN]，其QoS处理取决于应用的性质。例如，尽最大努力处理数据通道可能足以满足消息传递、共享白板和引导浏览应用程序的需要，而对延迟敏感的游戏可能希望其数据通道具有更好的QoS。
Transport protocols provide data communication behaviors beyond those possible at the IP layer. An important example is that TCP [RFC793] provides reliable in-order delivery of data with congestion control. SCTP [RFC4960] provides additional properties such as preservation of message boundaries, and the ability to avoid head-of-line blocking that may occur with TCP.
传输协议提供的数据通信行为超出了IP层可能的行为。一个重要的例子是，TCP[RFC793]通过拥塞控制提供可靠的有序数据传输。SCTP[RFC4960]提供了额外的属性，例如保留消息边界，以及避免TCP可能出现的行首阻塞的能力。
In contrast, UDP [RFC768] is a basic unreliable datagram protocol that provides port-based multiplexing and demultiplexing on top of IP. Two other unreliable datagram protocols are UDP-Lite [RFC3828], a variant of UDP that may deliver partially corrupt payloads when errors occur, and DCCP [RFC4340], which provides a range of congestion control modes for its unreliable datagram service.
相反，UDP[RFC768]是一种基本的不可靠数据报协议，它在IP之上提供基于端口的多路复用和解多路复用。另外两个不可靠的数据报协议是UDP Lite[RFC3828]，这是UDP的一个变体，在发生错误时可能会交付部分损坏的有效负载，以及DCCP[RFC4340]，它为其不可靠的数据报服务提供一系列拥塞控制模式。
Transport protocols that provide reliable delivery (e.g., TCP, SCTP) are sensitive to network reordering of traffic. When a protocol that provides reliable delivery receives a packet other than the next expected packet, the protocol usually assumes that the expected packet has been lost and updates the peer, which often causes a retransmission. In addition, congestion control functionality in transport protocols (including DCCP) usually infers congestion when packets are lost. This creates additional sensitivity to significant network packet reordering, as such reordering may be (mis)interpreted as loss of the out-of-order packets, causing a congestion control response.
提供可靠传输的传输协议（如TCP、SCTP）对流量的网络重新排序非常敏感。当提供可靠传递的协议接收到下一个预期数据包以外的数据包时，该协议通常假定预期数据包已丢失并更新对等方，这通常会导致重传。此外，传输协议（包括DCCP）中的拥塞控制功能通常在数据包丢失时推断拥塞。这对重要的网络分组重新排序产生了额外的敏感性，因为这种重新排序可能（错误地）解释为无序分组的丢失，从而导致拥塞控制响应。
This sensitivity to reordering remains even when ECN [RFC3168] is in use, as ECN receivers are required to treat missing packets as potential indications of congestion, because:
即使在使用ECN[RFC3168]时，这种对重新排序的敏感性仍然存在，因为ECN接收器需要将丢失的数据包视为拥塞的潜在指示，因为：
o Severe congestion may cause ECN-capable network nodes to drop packets, and
o 严重拥塞可能导致支持ECN的网络节点丢弃数据包，以及
o ECN traffic may be forwarded by network nodes that do not support ECN and hence drop packets to indicate congestion.
o ECN流量可由不支持ECN的网络节点转发，因此丢弃数据包以指示拥塞。
Congestion control is an important aspect of the Internet architecture; see [RFC2914] for further discussion.
拥塞控制是互联网体系结构的一个重要方面；有关进一步的讨论，请参见[RFC2914]。
In general, marking packets with different DSCPs results in different PHBs being applied at nodes in the network, making reordering very likely due to use of different pools of forwarding resources for each PHB. This should not be done within a single network 5-tuple for current transport protocols, with the important exceptions of UDP and UDP-Lite.
通常，使用不同的DSCP标记数据包会导致在网络中的节点上应用不同的PHB，由于每个PHB使用不同的转发资源池，因此很可能会重新排序。对于当前的传输协议，这不应该在单个网络5元组内完成，UDP和UDP Lite除外。
When PHBs that enable reordering are mixed within a single network 5-tuple, the effect is to mix QoS-based traffic classes within the scope of a single transport protocol connection or association. As these QoS-based traffic classes receive different network QoS treatments, they use different pools of network resources and hence may exhibit different levels of congestion. The result for congestion-controlled protocols is that a separate instance of congestion control functionality is needed per QoS-based traffic class. Current transport protocols support only a single instance of congestion control functionality for an entire connection or association; extending that support to multiple instances would add significant protocol complexity. Traffic in different QoS-based classes may use different paths through the network; this complicates path integrity checking in connection- or association-based protocols, as those paths may fail independently.
当在单个网络5元组中混合启用重新排序的PHB时，其效果是在单个传输协议连接或关联的范围内混合基于QoS的流量类。由于这些基于QoS的流量类别接受不同的网络QoS处理，它们使用不同的网络资源池，因此可能表现出不同程度的拥塞。拥塞控制协议的结果是，每个基于QoS的流量类别需要一个单独的拥塞控制功能实例。当前的传输协议仅支持整个连接或关联的拥塞控制功能的单个实例；将这种支持扩展到多个实例将增加显著的协议复杂性。不同基于QoS的类中的业务可以通过网络使用不同的路径；这使得基于连接或关联的协议中的路径完整性检查变得复杂，因为这些路径可能会独立失败。
The primary example where usage of multiple PHBs does not enable reordering within a single network 5-tuple is use of PHBs from a single AF class (e.g., AF1x). Traffic reordering within the scope of a network 5-tuple that uses a single PHB or AF class may occur for other transient reasons (e.g., routing changes or ECMP rebalancing).
使用多个PHB不能在单个网络5元组内实现重新排序的主要示例是使用单个AF类（例如AF1x）中的PHB。使用单个PHB或AF类的网络5元组范围内的流量重新排序可能由于其他暂时原因（例如，路由更改或ECMP重新平衡）而发生。
Reordering also affects other forms of congestion control, such as techniques for RTP congestion control that were under development when this memo was published; see [RMCAT-CC] for requirements. These techniques prefer use of a common (coupled) congestion controller for RTP streams between the same endpoints to reduce packet loss and delay by reducing competition for resources at any shared bottleneck.
重新排序还影响其他形式的拥塞控制，如本备忘录发布时正在开发的RTP拥塞控制技术；有关要求，请参见[RMCAT-CC]。这些技术倾向于对相同端点之间的RTP流使用公共（耦合）拥塞控制器，通过减少任何共享瓶颈处的资源竞争来减少数据包丢失和延迟。
Shared bottlenecks can be detected via techniques such as correlation of one-way delay measurements across RTP streams. An alternate approach is to assume that the set of packets on a single network 5-tuple marked with DSCPs that do not enable reordering will utilize a common network path and common forwarding resources at each network node. Under that assumption, any bottleneck encountered by such packets is shared among all of them, making it safe to use a common (coupled) congestion controller (see [COUPLED-CC]). This is not a safe assumption when the packets involved are marked with DSCP values
共享瓶颈可以通过诸如跨RTP流的单向延迟测量的相关性等技术来检测。另一种方法是假设单个网络5元组上标记有DSCP且不允许重新排序的数据包集将在每个网络节点上利用公共网络路径和公共转发资源。在这种假设下，这些数据包遇到的任何瓶颈都会在所有这些数据包之间共享，从而可以安全地使用公共（耦合）拥塞控制器（请参见[coupled-CC]）。当所涉及的数据包被标记为DSCP值时，这不是一个安全的假设
that enable reordering because a bottleneck may not be shared among all such packets (e.g., when the DSCP values result in use of different queues at a network node, but only one queue is a bottleneck).
由于瓶颈可能不会在所有此类数据包之间共享（例如，当DSCP值导致在网络节点上使用不同队列，但只有一个队列是瓶颈时），因此启用重新排序。
UDP and UDP-Lite are not sensitive to reordering in the network, because they do not provide reliable delivery or congestion control. On the other hand, when used to encapsulate other protocols (e.g., as UDP is used by WebRTC; see Section 2.1), the reordering considerations for the encapsulated protocols apply. For the specific usage of UDP by WebRTC, every encapsulated protocol (i.e., RTP, SCTP, and TCP) is sensitive to reordering as further discussed in this memo. In addition, [RFC5405] provides general guidelines for use of UDP (and UDP-Lite); the congestion control guidelines in that document apply to protocols encapsulated in UDP (or UDP-Lite).
UDP和UDP Lite对网络中的重新排序不敏感，因为它们不提供可靠的传递或拥塞控制。另一方面，当用于封装其他协议时（例如，由于WebRTC使用UDP；请参见第2.1节），适用于封装协议的重新排序注意事项。对于WebRTC对UDP的特定使用，每个封装协议（即RTP、SCTP和TCP）都对重新排序非常敏感，本备忘录将对此进行进一步讨论。此外，[RFC5405]提供了使用UDP（和UDP Lite）的一般指南；该文档中的拥塞控制指南适用于UDP（或UDP Lite）中封装的协议。
Real-time communications are also sensitive to network reordering of packets. Such reordering may lead to unneeded retransmission and spurious retransmission control signals (such as NACK) in reliable delivery protocols (see Section 5.1). The degree of sensitivity depends on protocol or stream timers, in contrast to reliable delivery protocols that usually react to all reordering.
实时通信对数据包的网络重新排序也很敏感。在可靠传输协议中，这种重新排序可能导致不必要的重传和伪重传控制信号（如NACK）（见第5.1节）。敏感度取决于协议或流计时器，而可靠的交付协议通常对所有重新排序作出反应。
Receiver jitter buffers have important roles in the effect of reordering on real-time communications:
接收机抖动缓冲器在实时通信的重排序效应中起着重要作用：
o Minor packet reordering that is contained within a jitter buffer usually has no effect on rendering of the received RTP stream because packets that arrive out of order are retrieved in order from the jitter buffer for rendering.
o 抖动缓冲区中包含的次要数据包重新排序通常对所接收RTP流的呈现没有影响，因为无序到达的数据包是按顺序从抖动缓冲区检索以进行呈现的。
o Packet reordering that exceeds the capacity of a jitter buffer can cause user-perceptible quality problems (e.g., glitches, noise) for delay-sensitive communication, such as interactive conversations for which small jitter buffers are necessary to preserve human perceptions of real-time interaction. Interactive real-time communication implementations often discard data that is sufficiently late so that it cannot be rendered in source stream order, making retransmission counterproductive. For this reason, implementations of interactive real-time communication often do not use retransmission.
o 超过抖动缓冲区容量的数据包重新排序可能会导致用户可感知的延迟敏感通信质量问题（例如，小故障、噪声），例如交互式对话，其中需要小抖动缓冲区来保持人类对实时交互的感知。交互式实时通信实现通常会丢弃足够晚的数据，使其无法按源流顺序呈现，从而导致重传适得其反。因此，交互式实时通信的实现通常不使用重传。
o In contrast, replay of recorded media can tolerate significantly longer delays than interactive conversations, so replay is likely to use larger jitter buffers than interactive conversations. These larger jitter buffers increase the tolerance of replay to
o 相比之下，录制媒体的重播可以容忍比交互式对话更长的延迟，因此重播可能比交互式对话使用更大的抖动缓冲区。这些更大的抖动缓冲区增加了重播的容错性
reordering by comparison to interactive conversations. The size of the jitter buffer imposes an upper bound on replay tolerance to reordering but does enable retransmission to be used when the jitter buffer is significantly larger than the amount of data that can be expected to arrive during the round-trip latency for retransmission.
通过与交互式对话进行比较来重新排序。抖动缓冲区的大小对重播容忍度施加了一个上限，以便重新排序，但当抖动缓冲区明显大于在重发的往返延迟期间预期到达的数据量时，确实允许使用重发。
Network packet reordering has no effective upper bound and can exceed the size of any reasonable jitter buffer. In practice, the size of jitter buffers for replay is limited by external factors such as the amount of time that a human is willing to wait for replay to start.
网络数据包重新排序没有有效的上限，可以超过任何合理的抖动缓冲区的大小。实际上，回放抖动缓冲区的大小受到外部因素的限制，例如人类愿意等待回放开始的时间量。
Packets within the same network 5-tuple that use PHBs within a single AF class can be expected to draw upon the same forwarding resources on network nodes (e.g., use the same router queue), and hence use of multiple drop precedences within an AF class is not expected to cause latency variation. When PHBs within a single AF class are mixed within a flow, the resulting overall likelihood that packets will be dropped from that flow is a mix of the drop likelihoods of the PHBs involved.
在同一网络5元组中使用单个AF类中的phb的分组可以预期利用网络节点上相同的转发资源（例如，使用相同的路由器队列），因此在AF类中使用多个丢弃先例不会导致延迟变化。当单个AF类中的phb在一个流中混合时，从该流丢弃数据包的结果总体可能性是所涉及phb的丢弃可能性的混合。
There are situations in which drop precedences should not be mixed. A simple example is that there is little value in mixing drop precedences within a TCP connection, because TCP's ordered delivery behavior results in any drop requiring the receiver to wait for the dropped packet to be retransmitted. Any resulting delay depends on the RTT and not the packet that was dropped. Hence a single DSCP should be used for all packets in a TCP connection.
在某些情况下，放弃先例不应混为一谈。一个简单的例子是，在TCP连接中混合丢包先例没有什么价值，因为TCP的有序传递行为导致任何丢包都需要接收方等待丢包被重新传输。任何产生的延迟都取决于RTT，而不是丢弃的数据包。因此，TCP连接中的所有数据包都应使用单个DSCP。
As a consequence, when TCP is selected for NAT/FW traversal (e.g., by TURN), a single DSCP should be used for all traffic on that TCP connection. An additional reason for this recommendation is that packetization for STUN/ICE/TURN occurs before passing the resulting packets to TCP; TCP resegmentation may result in a different packetization on the wire, breaking any association between DSCPs and specific data to which they are intended to apply.
因此，当选择TCP进行NAT/FW遍历（例如，通过TURN）时，应为该TCP连接上的所有流量使用单个DSCP。该建议的另一个原因是，STUN/ICE/TURN的打包在将生成的数据包传递给TCP之前发生；TCP重新分段可能会导致导线上出现不同的分组，从而破坏DSCP与它们打算应用的特定数据之间的任何关联。
SCTP [RFC4960] differs from TCP in a number of ways, including the ability to deliver messages in an order that differs from the order in which they were sent and support for unreliable streams. However, SCTP performs congestion control and retransmission across the entire association, and not on a per-stream basis. Although there may be advantages to using multiple drop precedence across SCTP streams or within an SCTP stream that does not use reliable ordered delivery, there is no practical operational experience in doing so (e.g., the SCTP sockets API [RFC6458] does not support use of more than one DSCP
SCTP[RFC4960]在许多方面不同于TCP，包括以不同于消息发送顺序的顺序传递消息的能力，以及对不可靠流的支持。但是，SCTP在整个关联中执行拥塞控制和重传，而不是基于每个流。尽管在SCTP流之间或在不使用可靠有序传递的SCTP流中使用多个丢弃优先级可能有好处，但在这样做时没有实际操作经验（例如，SCTP套接字API[RFC6458]不支持使用多个DSCP）
for an SCTP association). As a consequence, the impacts on SCTP protocol and implementation behavior are unknown and difficult to predict. Hence a single DSCP should be used for all packets in an SCTP association, independent of the number or nature of streams in that association. Similar reasoning applies to a DCCP connection; a single DSCP should be used because the scope of congestion control is the connection and there is no operational experience with using more than one DSCP. This recommendation may be revised in the future if experiments, analysis, and operational experience provide compelling reasons to change it.
对于SCTP关联）。因此，对SCTP协议和实现行为的影响未知且难以预测。因此，单个DSCP应用于SCTP关联中的所有数据包，与该关联中流的数量或性质无关。类似的推理适用于DCCP连接；应使用单个DSCP，因为拥塞控制的范围是连接，并且没有使用多个DSCP的操作经验。如果实验、分析和操作经验提供了令人信服的理由来改变该建议，则该建议可能会在将来进行修订。
Guidance on transport protocol design and implementation to provide support for use of multiple PHBs and DSCPs in a transport protocol connection (e.g., DCCP) or transport protocol association (e.g., SCTP) is out of scope for this memo.
为在传输协议连接（如DCCP）或传输协议关联（如SCTP）中使用多个PHB和DSCP提供支持的传输协议设计和实施指南不在本备忘录的范围内。
RTCP [RFC3550] is used with RTP to monitor quality of service and convey information about RTP session participants. A sender of RTCP packets that also sends RTP packets (i.e., originates an RTP stream) should use the same DSCP marking for both types of packets. If an RTCP sender doesn't send any RTP packets, it should mark its RTCP packets with the DSCP that it would use if it did send RTP packets with media similar to the RTP traffic that it receives. If the RTCP sender uses or would use multiple DSCPs that differ only in drop precedence for RTP, then it should use the DSCP with the least likelihood of drop for RTCP to increase the likelihood of RTCP packet delivery.
RTCP[RFC3550]与RTP一起使用，以监控服务质量并传达有关RTP会话参与者的信息。同时发送RTP数据包（即，发起RTP流）的RTCP数据包的发送方应为这两种类型的数据包使用相同的DSCP标记。如果RTCP发送方未发送任何RTP数据包，则应使用DSCP标记其RTCP数据包，如果发送RTP数据包时使用的介质与其接收的RTP通信量类似，则将使用DSCP。如果RTCP发送方使用或将使用多个仅在RTP丢弃优先级上不同的DSCP，则应使用RTCP丢弃可能性最小的DSCP，以增加RTCP数据包传递的可能性。
If the SDP bundle extension [SDP-BUNDLE] is used to negotiate sending multiple types of media in a single RTP session, then receivers will send separate RTCP reports for each type of media, using a separate SSRC for each media type; each RTCP report should be marked with the DSCP corresponding to the type of media handled by the reporting SSRC.
如果SDP捆绑扩展[SDP-bundle]用于协商在单个RTP会话中发送多种类型的媒体，则接收方将为每种类型的媒体发送单独的RTCP报告，并为每种媒体类型使用单独的SSRC；每个RTCP报告应标有与报告SSRC处理的介质类型相对应的DSCP。
This guidance may result in different DSCP markings for RTP streams and RTCP receiver reports about those RTP streams. The resulting variation in network QoS treatment by traffic direction is necessary to obtain representative round-trip time (RTT) estimates that correspond to the media path RTT, which may differ from the transport protocol RTT. RTCP receiver reports may be relatively infrequent, and hence the resulting RTT estimates are of limited utility for transport protocol congestion control (although those RTT estimates have other important uses; see [RFC3550]). For this reason, it is important that RTCP receiver reports sent by an SSRC receive the same network QoS treatment as the RTP stream being sent by that SSRC.
本指南可能会导致RTP流的DSCP标记不同，并且RTCP接收器会报告这些RTP流。根据业务方向在网络QoS处理中产生的变化对于获得对应于媒体路径RTT的代表性往返时间（RTT）估计是必要的，其可能不同于传输协议RTT。RTCP接收器报告可能相对较少，因此产生的RTT估计对传输协议拥塞控制的效用有限（尽管这些RTT估计有其他重要用途；请参见[RFC3550]）。因此，重要的是，SSRC发送的RTCP接收器报告与该SSRC发送的RTP流接收相同的网络QoS处理。
The only use of multiple standardized PHBs and DSCPs that does not enable network reordering among packets marked with different DSCPs is use of PHBs within a single AF class. All other uses of multiple PHBs and/or the class selector DSCPs enable network reordering of packets that are marked with different DSCPs. Based on this and the foregoing discussion, the guidelines in this section apply to use of Diffserv with real-time communications.
多个标准化PHB和DSCP的唯一用途是在单个AF类中使用PHB，而这些PHB和DSCP不能在标记有不同DSCP的数据包之间实现网络重新排序。多个PHB和/或类选择器DSCP的所有其他用途允许对标记有不同DSCP的数据包进行网络重新排序。基于此和前面的讨论，本节中的指南适用于区分服务与实时通信的使用。
Applications and other traffic sources (including RTP SSRCs):
应用程序和其他流量源（包括RTP SSRC）：
o Should limit use of DSCPs within a single RTP stream to those whose corresponding PHBs do not enable packet reordering. If this is not done, significant network reordering may overwhelm implementation assumptions about reordering limits, e.g., jitter buffer size, causing poor user experiences (see Section 5.2). This guideline applies to all of the RTP streams that are within the scope of a common (coupled) congestion controller when that controller does not use per-RTP-stream measurements for bottleneck detection.
o 应将单个RTP流中DSCP的使用限制在其相应PHB不支持数据包重新排序的情况下。如果不这样做，重要的网络重新排序可能会压倒关于重新排序限制的实现假设，例如抖动缓冲区大小，导致用户体验差（见第5.2节）。本指南适用于公共（耦合）拥塞控制器范围内的所有RTP流，前提是该控制器不使用每个RTP流测量值进行瓶颈检测。
o Should use a single DSCP for RTCP packets, which should be a DSCP used for RTP packets that are or would be sent by that SSRC (see Section 5.4).
o RTCP数据包应使用一个DSCP，该DSCP应用于该SSRC正在或将要发送的RTP数据包（见第5.4节）。
o Should use a single DSCP for all packets within a reliable transport protocol session (e.g., TCP connection, SCTP association) or DCCP connection (see Sections 5.1 and 5.3). For SCTP, this requirement applies across the entire SCTP association, and not just to individual streams within an association. When TURN selects TCP for NAT/FW traversal, this guideline applies to all traffic multiplexed onto that TCP connection, in contrast to use of UDP for NAT/FW traversal.
o 对于可靠传输协议会话（如TCP连接、SCTP关联）或DCCP连接（见第5.1和5.3节）内的所有数据包，应使用单个DSCP。对于SCTP，此要求适用于整个SCTP关联，而不仅仅适用于关联中的单个流。当TURN选择TCP进行NAT/FW遍历时，此指南适用于多路传输到该TCP连接上的所有流量，而不是使用UDP进行NAT/FW遍历。
o May use different DSCPs whose corresponding PHBs enable reordering within a single UDP or UDP-Lite 5-tuple, subject to the above constraints. The service differentiation provided by such usage is unreliable, as it may be removed or changed by DSCP remarking at network boundaries as described in Section 3.2 above.
o 可以使用不同的DSCP，其对应的PHB允许在单个UDP或UDP Lite 5元组内重新排序，但需遵守上述约束。这种使用方式所提供的服务差异是不可靠的，因为它可能会被DSCP在上述第3.2节所述的网络边界上进行标记而删除或更改。
o Cannot rely on end-to-end preservation of DSCPs as network node remarking can change DSCPs and remove drop precedence distinctions (see Section 3.2). For example, if a source uses drop precedence distinctions within an AF class to identify different types of video frames, using those DSCP values at the receiver to identify frame type is inherently unreliable.
o 不能依赖于DSCP的端到端保留，因为网络节点标记可以更改DSCP并消除丢弃优先级差异（参见第3.2节）。例如，如果源在AF类中使用丢弃优先级区分来识别不同类型的视频帧，则在接收器处使用这些DSCP值来识别帧类型本质上是不可靠的。
o Should limit use of the CS1 codepoint to traffic for which best effort forwarding is acceptable, as network support for use of CS1 to select a "less than best-effort" PHB is inconsistent. Further, some networks may treat CS1 as providing "better than best-effort" forwarding behavior.
o 应将CS1码点的使用限制为可接受尽力而为转发的流量，因为使用CS1选择“低于尽力而为”PHB的网络支持不一致。此外，一些网络可能将CS1视为提供“比尽力更好”的转发行为。
There is no guidance in this memo on how network operators should differentiate traffic. Networks may support all of the PHBs discussed herein, classify EF and AFxx traffic identically, or even remark all traffic to best effort at some ingress points. Nonetheless, it is useful for applications and other traffic sources to provide finer granularity DSCP marking on packets for the benefit of networks that offer QoS service differentiation. A specific example is that traffic originating from a browser may benefit from QoS service differentiation in within-building and residential access networks, even if the DSCP marking is subsequently removed or simplified. This is because such networks and the boundaries between them are likely traffic bottleneck locations (e.g., due to customer aggregation onto common links and/or speed differences among links used by the same traffic).
本备忘录中没有关于网络运营商应如何区分流量的指导。网络可以支持本文讨论的所有PHB，对EF和AFxx流量进行相同的分类，甚至在一些入口点尽最大努力标记所有流量。尽管如此，对于应用程序和其他流量源来说，在数据包上提供更细粒度的DSCP标记对于提供QoS服务差异化的网络是有用的。一个具体的例子是，来自浏览器的流量可能受益于建筑物内和住宅接入网络中的QoS服务差异，即使随后删除或简化了DSCP标记。这是因为此类网络及其之间的边界可能是流量瓶颈位置（例如，由于客户聚集到公共链路和/或相同流量使用的链路之间的速度差异）。
The security considerations for all of the technologies discussed in this memo apply; in particular, see the security considerations for RTP in [RFC3550] and Diffserv in [RFC2474] and [RFC2475].
本备忘录中讨论的所有技术的安全注意事项均适用；具体请参见[RFC3550]中的RTP安全注意事项，以及[RFC2474]和[RFC2475]中的Diffserv安全注意事项。
Multiplexing of multiple protocols onto a single UDP 5-tuple via encapsulation has implications for network functionality that monitors or inspects individual protocol flows, e.g., firewalls and traffic monitoring systems. When implementations of such functionality lack visibility into encapsulated traffic (likely for many current implementations), it may be difficult or impossible to apply network security policy and associated controls at a finer granularity than the overall UDP 5-tuple.
通过封装将多个协议多路复用到单个UDP 5元组上会影响到监视或检查单个协议流（例如防火墙和流量监视系统）的网络功能。当此类功能的实现缺乏对封装流量的可见性时（可能对于当前的许多实现），可能难以或不可能以比整体UDP 5元组更精细的粒度应用网络安全策略和相关控制。
Use of multiple DSCPs that enable reordering within an overall real-time communication interaction enlarges the set of network forwarding resources used by that interaction, thereby increasing exposure to resource depletion or failure, independent of whether the underlying cause is benign or malicious. This represents an increase in the effective attack surface of the interaction and is a consideration in selecting an appropriate degree of QoS differentiation among the components of the real-time communication interaction. See Section 3.3.2.1 of [RFC6274] for related discussion of DSCP security considerations.
在整个实时通信交互中使用多个DSCP来实现重新排序，这会扩大该交互使用的网络转发资源集，从而增加资源耗尽或故障的风险，而与根本原因是良性还是恶意无关。这表示交互的有效攻击面增加，并且是在实时通信交互的组件之间选择适当程度的QoS区分时的一个考虑因素。有关DSCP安全注意事项的相关讨论，请参见[RFC6274]第3.3.2.1节。
Use of multiple DSCPs to provide differentiated QoS service may reveal information about the encrypted traffic to which different service levels are provided. For example, DSCP-based identification of RTP streams combined with packet frequency and packet size could reveal the type or nature of the encrypted source streams. The IP header used for forwarding has to be unencrypted for obvious reasons, and the DSCP likewise has to be unencrypted to enable different IP forwarding behaviors to be applied to different packets. The nature of encrypted traffic components can be disguised via encrypted dummy data padding and encrypted dummy packets, e.g., see the discussion of traffic flow confidentiality in [RFC4303]. Encrypted dummy packets could even be added in a fashion that an observer of the overall encrypted traffic might mistake for another encrypted RTP stream.
使用多个DSCP来提供区分的QoS服务可能会揭示有关加密流量的信息，这些加密流量提供了不同的服务级别。例如，结合分组频率和分组大小的基于DSCP的RTP流识别可以揭示加密源流的类型或性质。由于明显的原因，用于转发的IP报头必须是未加密的，并且DSCP同样必须是未加密的，以使不同的IP转发行为能够应用于不同的数据包。加密流量组件的性质可以通过加密虚拟数据填充和加密虚拟数据包来伪装，例如，参见[RFC4303]中对流量机密性的讨论。加密的虚拟数据包甚至可以以这样一种方式添加，即总体加密流量的观察者可能会误认为是另一个加密的RTP流。
[RFC768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, DOI 10.17487/RFC0768, August 1980, <http://www.rfc-editor.org/info/rfc768>.
[RFC768]Postel，J.，“用户数据报协议”，STD 6，RFC 768，DOI 10.17487/RFC0768，1980年8月<http://www.rfc-editor.org/info/rfc768>.
[RFC793] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, DOI 10.17487/RFC0793, September 1981, <http://www.rfc-editor.org/info/rfc793>.
[RFC793]Postel，J.，“传输控制协议”，标准7，RFC 793，DOI 10.17487/RFC0793，1981年9月<http://www.rfc-editor.org/info/rfc793>.
[RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, "Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers", RFC 2474, DOI 10.17487/RFC2474, December 1998, <http://www.rfc-editor.org/info/rfc2474>.
[RFC2474]Nichols，K.，Blake，S.，Baker，F.，和D.Black，“IPv4和IPv6报头中区分服务字段（DS字段）的定义”，RFC 2474，DOI 10.17487/RFC2474，1998年12月<http://www.rfc-editor.org/info/rfc2474>.
[RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., and W. Weiss, "An Architecture for Differentiated Services", RFC 2475, DOI 10.17487/RFC2475, December 1998, <http://www.rfc-editor.org/info/rfc2475>.
[RFC2475]Blake，S.，Black，D.，Carlson，M.，Davies，E.，Wang，Z.，和W.Weiss，“差异化服务架构”，RFC 2475，DOI 10.17487/RFC2475，1998年12月<http://www.rfc-editor.org/info/rfc2475>.
[RFC2597] Heinanen, J., Baker, F., Weiss, W., and J. Wroclawski, "Assured Forwarding PHB Group", RFC 2597, DOI 10.17487/RFC2597, June 1999, <http://www.rfc-editor.org/info/rfc2597>.
[RFC2597]Heinanen，J.，Baker，F.，Weiss，W.，和J.Wroclawski，“保付PHB集团”，RFC 2597，DOI 10.17487/RFC2597，1999年6月<http://www.rfc-editor.org/info/rfc2597>.
[RFC3246] Davie, B., Charny, A., Bennet, J., Benson, K., Le Boudec, J., Courtney, W., Davari, S., Firoiu, V., and D. Stiliadis, "An Expedited Forwarding PHB (Per-Hop Behavior)", RFC 3246, DOI 10.17487/RFC3246, March 2002, <http://www.rfc-editor.org/info/rfc3246>.
[RFC3246]Davie，B.，Charny，A.，Bennet，J.，Benson，K.，Le Boudec，J.，Courtney，W.，Davari，S.，Firoiu，V.，和D.Stiliadis，“快速转发PHB（每跳行为）”，RFC 3246，DOI 10.17487/RFC3246，2002年3月<http://www.rfc-editor.org/info/rfc3246>.
[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550, July 2003, <http://www.rfc-editor.org/info/rfc3550>.
[RFC3550]Schulzrinne，H.，Casner，S.，Frederick，R.，和V.Jacobson，“RTP：实时应用的传输协议”，STD 64，RFC 3550，DOI 10.17487/RFC3550，2003年7月<http://www.rfc-editor.org/info/rfc3550>.
[RFC3662] Bless, R., Nichols, K., and K. Wehrle, "A Lower Effort Per-Domain Behavior (PDB) for Differentiated Services", RFC 3662, DOI 10.17487/RFC3662, December 2003, <http://www.rfc-editor.org/info/rfc3662>.
[RFC3662]Bless，R.，Nichols，K.和K.Wehrle，“区分服务的低域行为（PDB）”，RFC 3662，DOI 10.17487/RFC3662，2003年12月<http://www.rfc-editor.org/info/rfc3662>.
[RFC3828] Larzon, L-A., Degermark, M., Pink, S., Jonsson, L-E., Ed., and G. Fairhurst, Ed., "The Lightweight User Datagram Protocol (UDP-Lite)", RFC 3828, DOI 10.17487/RFC3828, July 2004, <http://www.rfc-editor.org/info/rfc3828>.
[RFC3828]Larzon，L-A.，Degermark，M.，Pink，S.，Jonsson，L-E.，Ed.，和G.Fairhurst，Ed.，“轻量级用户数据报协议（UDP Lite）”，RFC 3828，DOI 10.17487/RFC3828，2004年7月<http://www.rfc-editor.org/info/rfc3828>.
[RFC4340] Kohler, E., Handley, M., and S. Floyd, "Datagram Congestion Control Protocol (DCCP)", RFC 4340, DOI 10.17487/RFC4340, March 2006, <http://www.rfc-editor.org/info/rfc4340>.
[RFC4340]Kohler，E.，Handley，M.和S.Floyd，“数据报拥塞控制协议（DCCP）”，RFC 4340，DOI 10.17487/RFC4340，2006年3月<http://www.rfc-editor.org/info/rfc4340>.
[RFC4960] Stewart, R., Ed., "Stream Control Transmission Protocol", RFC 4960, DOI 10.17487/RFC4960, September 2007, <http://www.rfc-editor.org/info/rfc4960>.
[RFC4960]Stewart，R.，Ed.“流控制传输协议”，RFC 4960，DOI 10.17487/RFC4960，2007年9月<http://www.rfc-editor.org/info/rfc4960>.
[RFC5405] Eggert, L. and G. Fairhurst, "Unicast UDP Usage Guidelines for Application Designers", BCP 145, RFC 5405, DOI 10.17487/RFC5405, November 2008, <http://www.rfc-editor.org/info/rfc5405>.
[RFC5405]Eggert，L.和G.Fairhurst，“应用程序设计者的单播UDP使用指南”，BCP 145，RFC 5405，DOI 10.17487/RFC5405，2008年11月<http://www.rfc-editor.org/info/rfc5405>.
[RFC5865] Baker, F., Polk, J., and M. Dolly, "A Differentiated Services Code Point (DSCP) for Capacity-Admitted Traffic", RFC 5865, DOI 10.17487/RFC5865, May 2010, <http://www.rfc-editor.org/info/rfc5865>.
[RFC5865]Baker，F.，Polk，J.，和M.Dolly，“容量允许流量的差异化服务代码点（DSCP）”，RFC 5865，DOI 10.17487/RFC5865，2010年5月<http://www.rfc-editor.org/info/rfc5865>.
[RFC6951] Tuexen, M. and R. Stewart, "UDP Encapsulation of Stream Control Transmission Protocol (SCTP) Packets for End-Host to End-Host Communication", RFC 6951, DOI 10.17487/RFC6951, May 2013, <http://www.rfc-editor.org/info/rfc6951>.
[RFC6951]Tuexen，M.和R.Stewart，“用于端主机到端主机通信的流控制传输协议（SCTP）数据包的UDP封装”，RFC 6951，DOI 10.17487/RFC6951，2013年5月<http://www.rfc-editor.org/info/rfc6951>.
[RFC7656] Lennox, J., Gross, K., Nandakumar, S., Salgueiro, G., and B. Burman, Ed., "A Taxonomy of Semantics and Mechanisms for the Real-Time Transport Protocol (RTP) Sources", RFC 7656, DOI 10.17487/RFC7656, November 2015, <http://www.rfc-editor.org/info/rfc7656>.
[RFC7656]Lennox，J.，Gross，K.，Nandakumar，S.，Salgueiro，G.，和B.Burman，Ed.，“实时传输协议（RTP）源的语义和机制分类”，RFC 7656，DOI 10.17487/RFC7656，2015年11月<http://www.rfc-editor.org/info/rfc7656>.
[COUPLED-CC] Welzl, M., Islam, S., and S. Gjessing, "Coupled congestion control for RTP media", Work in Progress, draft-welzl-rmcat-coupled-cc-05, June 2015.
[COUPLED-CC]Welzl，M.，Islam，S.，和S.Gjessing，“RTP媒体的耦合拥塞控制”，正在进行的工作，草稿-Welzl-rmcat-COUPLED-CC-052015年6月。
[DATA-CHAN] Jesup, R., Loreto, S., and M. Tuexen, "WebRTC Data Channels", Work in Progress, draft-ietf-rtcweb-data-channel-13, January 2015.
[DATA-CHAN]Jesup，R.，Loreto，S.，和M.Tuexen，“WebRTC数据通道”，正在进行的工作，草稿-ietf-rtcweb-DATA-channel-13，2015年1月。
[DIFFSERV-INTERCON] Geib, R., Ed. and D. Black, "Diffserv interconnection classes and practice", Work in Progress, draft-ietf-tsvwg-diffserv-intercon-03, October 2015.
[DIFFSERV-INTERCON]Geib，R.，Ed.和D.Black，“DIFFSERV互连类别和实践”，正在进行的工作，草稿-ietf-tsvwg-DIFFSERV-INTERCON-032015年10月。
[H.221] ITU-T, "Frame structure for a 64 to 1920 kbit/s channel in audiovisual teleservices", Recommendation H.221, March 2009.
[H.221]ITU-T，“视听电信业务中64至1920 kbit/s信道的帧结构”，建议H.221，2009年3月。
[H.264] ITU-T, "Advanced video coding for generic audiovisual services", Recommendation H.264, February 2014.
[H.264]ITU-T，“通用视听服务的高级视频编码”，建议H.264，2014年2月。
[RFC2697] Heinanen, J. and R. Guerin, "A Single Rate Three Color Marker", RFC 2697, DOI 10.17487/RFC2697, September 1999, <http://www.rfc-editor.org/info/rfc2697>.
[RFC2697]Heinanen，J.和R.Guerin，“单速率三色标记”，RFC 2697，DOI 10.17487/RFC2697，1999年9月<http://www.rfc-editor.org/info/rfc2697>.
[RFC2698] Heinanen, J. and R. Guerin, "A Two Rate Three Color Marker", RFC 2698, DOI 10.17487/RFC2698, September 1999, <http://www.rfc-editor.org/info/rfc2698>.
[RFC2698]Heinanen，J.和R.Guerin，“双速率三色标记”，RFC 2698，DOI 10.17487/RFC2698，1999年9月<http://www.rfc-editor.org/info/rfc2698>.
[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>.
[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>.
[RFC3270] Le Faucheur, F., Wu, L., Davie, B., Davari, S., Vaananen, P., Krishnan, R., Cheval, P., and J. Heinanen, "Multi-Protocol Label Switching (MPLS) Support of Differentiated Services", RFC 3270, DOI 10.17487/RFC3270, May 2002, <http://www.rfc-editor.org/info/rfc3270>.
[RFC3270]Le Faucheur，F.，Wu，L.，Davie，B.，Davari，S.，Vaananen，P.，Krishnan，R.，Cheval，P.，和J.Heinanen，“区分服务的多协议标签交换（MPLS）支持”，RFC 3270，DOI 10.17487/RFC3270，2002年5月<http://www.rfc-editor.org/info/rfc3270>.
[RFC4103] Hellstrom, G. and P. Jones, "RTP Payload for Text Conversation", RFC 4103, DOI 10.17487/RFC4103, June 2005, <http://www.rfc-editor.org/info/rfc4103>.
[RFC4103]Hellstrom，G.和P.Jones，“文本对话的RTP有效载荷”，RFC 4103，DOI 10.17487/RFC4103，2005年6月<http://www.rfc-editor.org/info/rfc4103>.
[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303, DOI 10.17487/RFC4303, December 2005, <http://www.rfc-editor.org/info/rfc4303>.
[RFC4303]Kent，S.，“IP封装安全有效载荷（ESP）”，RFC 4303，DOI 10.17487/RFC4303，2005年12月<http://www.rfc-editor.org/info/rfc4303>.
[RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session Description Protocol", RFC 4566, DOI 10.17487/RFC4566, July 2006, <http://www.rfc-editor.org/info/rfc4566>.
[RFC4566]Handley，M.，Jacobson，V.，和C.Perkins，“SDP：会话描述协议”，RFC 4566，DOI 10.17487/RFC4566，2006年7月<http://www.rfc-editor.org/info/rfc4566>.
[RFC4594] Babiarz, J., Chan, K., and F. Baker, "Configuration Guidelines for DiffServ Service Classes", RFC 4594, DOI 10.17487/RFC4594, August 2006, <http://www.rfc-editor.org/info/rfc4594>.
[RFC4594]Babiarz，J.，Chan，K.，和F.Baker，“区分服务服务类的配置指南”，RFC 4594，DOI 10.17487/RFC4594，2006年8月<http://www.rfc-editor.org/info/rfc4594>.
[RFC5109] Li, A., Ed., "RTP Payload Format for Generic Forward Error Correction", RFC 5109, DOI 10.17487/RFC5109, December 2007, <http://www.rfc-editor.org/info/rfc5109>.
[RFC5109]Li，A.，Ed.“通用前向纠错的RTP有效载荷格式”，RFC 5109，DOI 10.17487/RFC5109，2007年12月<http://www.rfc-editor.org/info/rfc5109>.
[RFC5127] Chan, K., Babiarz, J., and F. Baker, "Aggregation of Diffserv Service Classes", RFC 5127, DOI 10.17487/RFC5127, February 2008, <http://www.rfc-editor.org/info/rfc5127>.
[RFC5127]Chan，K.，Babiarz，J.和F.Baker，“区分服务类的聚合”，RFC 5127，DOI 10.17487/RFC5127，2008年2月<http://www.rfc-editor.org/info/rfc5127>.
[RFC5129] Davie, B., Briscoe, B., and J. Tay, "Explicit Congestion Marking in MPLS", RFC 5129, DOI 10.17487/RFC5129, January 2008, <http://www.rfc-editor.org/info/rfc5129>.
[RFC5129]Davie，B.，Briscoe，B.，和J.Tay，“MPLS中的显式拥塞标记”，RFC 5129，DOI 10.17487/RFC5129，2008年1月<http://www.rfc-editor.org/info/rfc5129>.
[RFC5245] Rosenberg, J., "Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Traversal for Offer/Answer Protocols", RFC 5245, DOI 10.17487/RFC5245, April 2010, <http://www.rfc-editor.org/info/rfc5245>.
[RFC5245]Rosenberg，J.，“交互式连接建立（ICE）：提供/应答协议的网络地址转换器（NAT）遍历协议”，RFC 5245，DOI 10.17487/RFC5245，2010年4月<http://www.rfc-editor.org/info/rfc5245>.
[RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, "Session Traversal Utilities for NAT (STUN)", RFC 5389, DOI 10.17487/RFC5389, October 2008, <http://www.rfc-editor.org/info/rfc5389>.
[RFC5389]Rosenberg，J.，Mahy，R.，Matthews，P.，和D.Wing，“NAT（STUN）的会话遍历实用程序”，RFC 5389，DOI 10.17487/RFC5389，2008年10月<http://www.rfc-editor.org/info/rfc5389>.
[RFC5462] Andersson, L. and R. Asati, "Multiprotocol Label Switching (MPLS) Label Stack Entry: "EXP" Field Renamed to "Traffic Class" Field", RFC 5462, DOI 10.17487/RFC5462, February 2009, <http://www.rfc-editor.org/info/rfc5462>.
[RFC5462]Andersson，L.和R.Asati，“多协议标签交换（MPLS）标签堆栈条目：“EXP”字段重命名为“流量类”字段”，RFC 5462，DOI 10.17487/RFC5462，2009年2月<http://www.rfc-editor.org/info/rfc5462>.
[RFC5761] Perkins, C. and M. Westerlund, "Multiplexing RTP Data and Control Packets on a Single Port", RFC 5761, DOI 10.17487/RFC5761, April 2010, <http://www.rfc-editor.org/info/rfc5761>.
[RFC5761]Perkins，C.和M.Westerlund，“在单个端口上多路复用RTP数据和控制数据包”，RFC 5761，DOI 10.17487/RFC5761，2010年4月<http://www.rfc-editor.org/info/rfc5761>.
[RFC5764] McGrew, D. and E. Rescorla, "Datagram Transport Layer Security (DTLS) Extension to Establish Keys for the Secure Real-time Transport Protocol (SRTP)", RFC 5764, DOI 10.17487/RFC5764, May 2010, <http://www.rfc-editor.org/info/rfc5764>.
[RFC5764]McGrew，D.和E.Rescorla，“为安全实时传输协议（SRTP）建立密钥的数据报传输层安全（DTLS）扩展”，RFC 5764，DOI 10.17487/RFC5764，2010年5月<http://www.rfc-editor.org/info/rfc5764>.
[RFC5766] Mahy, R., Matthews, P., and J. Rosenberg, "Traversal Using Relays around NAT (TURN): Relay Extensions to Session Traversal Utilities for NAT (STUN)", RFC 5766, DOI 10.17487/RFC5766, April 2010, <http://www.rfc-editor.org/info/rfc5766>.
[RFC5766]Mahy，R.，Matthews，P.，和J.Rosenberg，“使用NAT周围的中继进行遍历（TURN）：NAT（STUN）会话遍历实用程序的中继扩展”，RFC 5766，DOI 10.17487/RFC5766，2010年4月<http://www.rfc-editor.org/info/rfc5766>.
[RFC6062] Perreault, S., Ed. and J. Rosenberg, "Traversal Using Relays around NAT (TURN) Extensions for TCP Allocations", RFC 6062, DOI 10.17487/RFC6062, November 2010, <http://www.rfc-editor.org/info/rfc6062>.
[RFC6062]Perreault，S.，Ed.和J.Rosenberg，“围绕TCP分配的NAT（TURN）扩展使用中继进行遍历”，RFC 6062，DOI 10.17487/RFC6062，2010年11月<http://www.rfc-editor.org/info/rfc6062>.
[RFC6274] Gont, F., "Security Assessment of the Internet Protocol Version 4", RFC 6274, DOI 10.17487/RFC6274, July 2011, <http://www.rfc-editor.org/info/rfc6274>.
[RFC6274]Gont，F.，“互联网协议版本4的安全评估”，RFC 6274，DOI 10.17487/RFC6274，2011年7月<http://www.rfc-editor.org/info/rfc6274>.
[RFC6386] Bankoski, J., Koleszar, J., Quillio, L., Salonen, J., Wilkins, P., and Y. Xu, "VP8 Data Format and Decoding Guide", RFC 6386, DOI 10.17487/RFC6386, November 2011, <http://www.rfc-editor.org/info/rfc6386>.
[RFC6386]Bankoski，J.，Koleszar，J.，Quillio，L.，Salonen，J.，Wilkins，P.，和Y.Xu，“VP8数据格式和解码指南”，RFC 6386，DOI 10.17487/RFC6386，2011年11月<http://www.rfc-editor.org/info/rfc6386>.
[RFC6437] Amante, S., Carpenter, B., Jiang, S., and J. Rajahalme, "IPv6 Flow Label Specification", RFC 6437, DOI 10.17487/RFC6437, November 2011, <http://www.rfc-editor.org/info/rfc6437>.
[RFC6437]Amante，S.，Carpenter，B.，Jiang，S.，和J.Rajahalme，“IPv6流标签规范”，RFC 6437，DOI 10.17487/RFC6437，2011年11月<http://www.rfc-editor.org/info/rfc6437>.
[RFC6458] Stewart, R., Tuexen, M., Poon, K., Lei, P., and V. Yasevich, "Sockets API Extensions for the Stream Control Transmission Protocol (SCTP)", RFC 6458, DOI 10.17487/RFC6458, December 2011, <http://www.rfc-editor.org/info/rfc6458>.
[RFC6458]Stewart，R.，Tuexen，M.，Poon，K.，Lei，P.，和V.Yasevich，“流控制传输协议（SCTP）的套接字API扩展”，RFC 6458，DOI 10.17487/RFC6458，2011年12月<http://www.rfc-editor.org/info/rfc6458>.
[RMCAT-CC] Jesup, R. and Z. Sarker, "Congestion Control Requirements for Interactive Real-Time Media", Work in Progress, draft-ietf-rmcat-cc-requirements-09, December 2014.
[RMCAT-CC]Jesup，R.和Z.Sarker，“交互式实时媒体的拥塞控制要求”，正在进行的工作，草稿-ietf-RMCAT-CC-Requirements-092014年12月。
[RTP-USAGE] Perkins, C., Westerlund, M., and J. Ott, "Web Real-Time Communication (WebRTC): Media Transport and Use of RTP", Work in Progress, draft-ietf-rtcweb-rtp-usage-25, June 2015.
[RTP-USAGE]Perkins，C.，Westerlund，M.，和J.Ott，“网络实时通信（WebRTC）：媒体传输和RTP的使用”，在建工程，草稿-ietf-rtcweb-RTP-USAGE-252015年6月。
[SDP-BUNDLE] Holmberg, C., Alvestrand, H., and C. Jennings, "Negotiating Media Multiplexing Using the Session Description Protocol (SDP)", Work in Progress, draft-ietf-mmusic-sdp-bundle-negotiation-23, July 2015.
[SDP-BUNDLE]Holmberg，C.，Alvestrand，H.，和C.Jennings，“使用会话描述协议（SDP）协商媒体多路复用”，正在进行的工作，草稿-ietf-mmusic-SDP-BUNDLE-negotiation-232015年7月。
[SRTP-DTLS] Petit-Huguenin, M. and G. Salgueiro, "Multiplexing Scheme Updates for Secure Real-time Transport Protocol (SRTP) Extension for Datagram Transport Layer Security (DTLS)", Work in Progress, draft-petithuguenin-avtcore-rfc5764-mux-fixes-02, March 2015.
[SRTP-DTLS]Petit Huguenin，M.和G.Salgueiro，“数据报传输层安全性（DTLS）安全实时传输协议（SRTP）扩展的多路复用方案更新”，正在进行的工作，草稿-petithuguenin-avtcore-rfc5764-mux-FIXS-022015年3月。
[W3C.WD-mediacapture-streams-20130903] Burnett, D., Bergkvist, A., Jennings, C., and A. Narayanan, "Media Capture and Streams", World Wide Web Consortium Recommendation WD-mediacapture-streams-20130903, September 2013, <http://www.w3.org/TR/2013/ WD-mediacapture-streams-20130903>.
[W3C.WD-mediacapture-streams-20130903]Burnett，D.，Bergkvist，A.，Jennings，C.，和A.Narayanan，“媒体捕获和流”，万维网联盟建议WD-mediacapture-streams-20130903，2013年9月<http://www.w3.org/TR/2013/ WD-mediacapture-streams-20130903>。
[WEBRTC-OVERVIEW] Alvestrand, H., "Overview: Real Time Protocols for Browser-based Applications", Work in Progress, draft-ietf-rtcweb-overview-14, June 2015.
[WEBRTC-OVERVIEW]Alvestrand，H.，“概述：基于浏览器的应用程序的实时协议”，正在进行的工作，草稿-ietf-rtcweb-OVERVIEW-14，2015年6月。
[WEBRTC-TRANSPORTS] Alvestrand, H., "Transports for WebRTC", Work in Progress, draft-ietf-rtcweb-transports-10, October 2015.
[WEBRTC-TRANSPORTS]Alvestrand，H.，“WEBRTC的传输”，正在进行的工作，草案-ietf-rtcweb-TRANSPORTS-102015年10月。
Acknowledgements
致谢
This memo is the result of many conversations that have occurred within the DART working group and other working groups in the RAI and Transport areas. Many thanks to Aamer Akhter, Harald Alvestrand, Fred Baker, Richard Barnes, Erin Bournival, Ben Campbell, Brian Carpenter, Spencer Dawkins, Keith Drage, Gorry Fairhurst, Ruediger Geib, Cullen Jennings, Jonathan Lennox, Karen Nielsen, Colin Perkins, James Polk, Robert Sparks, Tina Tsou, Michael Welzl, Dan York, and the DART WG participants for their reviews and comments.
本备忘录是灾难援助反应队工作组和RAI和交通地区其他工作组多次对话的结果。非常感谢艾默尔·阿克特、哈拉尔·阿尔维斯特兰、弗雷德·贝克、理查德·巴恩斯、埃林·布尼瓦尔、本·坎贝尔、布赖恩·卡彭特、斯宾塞·道金斯、基思·德雷格、戈里·费尔赫斯特、鲁迪格·盖布、卡伦·詹宁斯、乔纳森·伦诺克斯、卡伦·尼尔森、科林·帕金斯、詹姆斯·波尔克、罗伯特·斯帕克斯、蒂娜·祖、迈克尔·韦尔茨、丹·约克、，以及DART工作组参与者的评论和意见。
Authors' Addresses
作者地址
David Black (editor) EMC 176 South Street Hopkinton, MA 01748 United States
David Black（编辑）美国马萨诸塞州霍普金顿南街176号EMC 01748
Phone: +1 508 293-7953
Email: david.black@emc.com
Phone: +1 508 293-7953
Email: david.black@emc.com
Paul Jones Cisco 7025 Kit Creek Road Research Triangle Park, NC 27502 United States
Paul Jones Cisco 7025 Kit Creek Road Research Triangle Park，美国北卡罗来纳州27502
Phone: +1 919 476 2048
Email: paulej@packetizer.com
Phone: +1 919 476 2048
Email: paulej@packetizer.com