【RFC7657 差分服务和实时通信】（翻译）

原文 rfc7657 (ietf.org) Differentiated Services (Diffserv) and Real-Time Communication 差分服务 (Diffserv) 和实时通信

概述

本文描述了差分服务 (Diffserv) 网络服务质量 (QoS) 功能和实时网络通信之间的交互，包括基于实时传输协议 (RTP) 的通信。 差分服务基于网络节点对 IP 头部标有不同的差分服务代码点 (DSCP) 的数据包应用不同的转发处理。
WebRTC 应用程序以及一些会议应用程序已经开始使用会话描述协议 (SDP) 捆绑协商机制，使用相同的网络 5 元组发送具有不同 QoS 要求的多个流量流。在单个网络 5 元组内使用多个 DSCP 获得不同 QoS 处理的结果具有传输协议交互，特别是拥塞控制功能（例如，重新排序）。此外，可能会更改或删除流量源和目的地之间的 DSCP 标记。本文涵盖了这些差分服务方面对实时网络通信（包括 WebRTC）的影响。

目录

   1. 简介
   2. 实时通讯
     2.1. RTP背景
     2.2. RTP复用
   3. 差分服务（Diffserv）
     3.1. 差分服务每跳行为 (PHB)
     3.2. 流量分类器和 DSCP 注释
   4. 案例
   5. 差分服务交互
     5.1. 差分服务、重新排序和传输协议
     5.2. 差分服务、重新排序和实时通信
     5.3. 丢弃优先级和传输协议
     5.4. 差分服务和 RTCP
   6. 指引
   7. 安全考虑
   8. 参考文献
     8.1. 规范参考
     8.2. 参考资料
   致谢
   作者地址

1. 简介

本文描述了差分服务 (Diffserv) 网络服务质量 (QoS) 功能 [RFC2475] 和实时网络通信之间的交互，包括基于实时传输协议 (RTP) [RFC3550] 的通信。 差分服务基于网络节点对 IP 头部标记有不同差分服务代码点 (DSCP) [RFC2474] 的数据包应用不同的转发处理。过去，不同的 RTP 流通过不同的传输级流发送，有时与 RTP 控制协议 (RTCP) 复用。 WebRTC 应用程序以及一些会议应用程序现在使用会话描述协议 (SDP) [RFC4566] 捆绑协商机制 [SDP-BUNDLE] 使用相同的网络 5 元组发送具有不同 QoS 要求的多个流量流。在单个网络 5 元组内使用多个 DSCP 获得不同 QoS 处理的结果具有传输协议交互，特别是拥塞控制功能（例如，重新排序）。此外，可能会更改或删除流量源和目的地之间的 DSCP 标记。本文涵盖了这些差分服务方面对实时网络通信的影响，包括 WebRTC 流量 [WEBRTC-OVERVIEW].

本文组织如下。背景在关于实时通信的第 2 节和关于差分服务的第 3 节中提供。第 4 节描述了在实时通信中使用差分服务的一些示例。第 5 节解释了使用差分服务功能如何与传输和实时通信协议交互，第 6 节提供有关使用差分服务功能以控制不需要的交互的指导。安全注意事项在第 7 节中讨论。

2. 实时通讯

实时通信是通过IP网络使用语音、视频、文本、内容共享等方式进行实时通信。可以同时使用一种以上的模式，提供丰富的通信体验。

实时通信的一个简单示例是通过 Internet 进行的语音呼叫，其中音频流在两个用户之间的每个方向上传输。一个更复杂的例子是沉浸式视频会议系统，它有多个视频屏幕、多个摄像头、多个麦克风和一些共享内容的方式。对于这种复杂的系统，可能有多个媒体和非媒体流通过单个 IP 地址和端口或通过多个 IP 地址和端口传输。

2.1. RTP 背景

用于实时媒体的最常见协议是 RTP [RFC3550]。 RTP 为通过 Internet 传输的实时数据定义了通用的封装格式和处理规则。不幸的是，RTP 术语的使用一直不一致。例如，关于 RTP 术语的 RFC 7656 [RFC7656] 观察到：

      RTP [RFC3550] 交替使用媒体流、音频流、视频流和（RTP）数据包流，它们都是 RTP 流。

本文中的术语基于该 RTP 术语文件，其中以下术语特别重要（请参阅该术语文件以获取完整定义）：

源流：参考时钟同步，时间推进，数字媒体流。

RTP Stream：包含媒体数据的 RTP 数据包流，媒体数据可能是源数据或冗余数据。 RTP 流由属于特定 RTP 会话的 RTP 同步源 (SSRC) 标识。当使用基于 RTP 的安全性时，RTP 流可以是安全的 RTP 流。

此外，本文遵循 [RFC3550] 使用术语“SSRC”来指定 RTP 流的标识符和发送该 RTP 流的实体。

源流的媒体编码和打包导致源 RTP 流加上零个或多个冗余 RTP 流，这些 RTP 流提供了对来自源 RTP 流的数据包丢失的弹性[RFC7656]。冗余信息也可以在与编码源流相同的 RTP 流中携带，例如，参见 [RFC5109] 的第 7.2 节。对于大多数应用程序，在单个 RTP 会话中传输单个媒体类型（例如，音频）。然而，可以在同一个 RTP 会话上传输多个不同的源流作为一个或多个单独的 RTP 流。这称为 RTP 多路复用。此外，一个 RTP 流可以包含多个源流，例如 MPEG 传输流 [H.221] 中的组件或程序。

整体实时交互中的源流和 RTP 流的数量可能非常大。除了语音源流和视频源流之外，视频会议系统上的每个摄像头或麦克风可能有单独的源流。如上所述，也可能存在单独的冗余 RTP 流，它们使用诸如前向纠错之类的技术为源 RTP 流提供保护。另一个例子是联播传输，其中视频源流可以同时作为高分辨率和低分辨率 RTP 流传输。在这种情况下，媒体处理功能可能会根据带宽可用性或多点会议中的当前发言者是谁，选择将一个或两个 RTP 流向前发送到接收器。最后，发送器可能会使用不同的编码（例如，视频编码为 VP8 [RFC6386] 与 H.264 [H.264] 并行）作为两个 RTP 流同时发送相同的媒体内容，以允许媒体处理功能选择媒体最匹配接收器能力的编码。

对于 WebRTC 协议套件 [WEBRTC-TRANSPORTS]，单个源流是一个 MediaStreamTrack，一个 MediaStream 包含一个或多个 MediaStreamTracks [W3C.WD-mediacapture-streams-20130903]。 MediaStreamTrack 作为源 RTP 流加零个或多个冗余 RTP 流传输，因此由一个 MediaStreamTrack 组成的 MediaStream 作为单个源 RTP 流加零个或多个冗余 RTP 流传输。有关在 WebRTC 中使用 RTP 的更多信息，请参阅 [RTP-USAGE]。

RTP通常承载在数据报协议上，例如UDP[RFC768]、UDP-Lite[RFC3828]或数据报拥塞控制协议(DCCP)[RFC4340]； UDP 是最常用的，但也可以使用非数据报协议（例如 TCP [RFC793]）。 UDP 或 UDP-Lite 之外的传输协议也可用于传输实时数据或近实时数据。例如，流控制传输协议 (SCTP) [RFC4960] 可用于承载应用程序共享或白板信息，作为包括实时媒体在内的整体交互的一部分。这些额外的传输协议可以通过 UDP 封装与 RTP 会话复用，从而使用一对 UDP 端口。

WebRTC 协议套件包含