Network Working Group C. Bormann
Request for Comments: 2689 Universitaet Bremen TZI
Category: Informational September 1999
Network Working Group C. Bormann
Request for Comments: 2689 Universitaet Bremen TZI
Category: Informational September 1999
Providing Integrated Services over Low-bitrate Links
通过低比特率链路提供集成服务
Status of this Memo
本备忘录的状况
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
本备忘录为互联网社区提供信息。它没有规定任何类型的互联网标准。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The Internet Society (1999). All Rights Reserved.
版权所有（C）互联网协会（1999年）。版权所有。
Abstract
摘要
This document describes an architecture for providing integrated services over low-bitrate links, such as modem lines, ISDN B-channels, and sub-T1 links. It covers only the lower parts of the Internet Multimedia Conferencing Architecture [1]; additional components required for application services such as Internet Telephony (e.g., a session initiation protocol) are outside the scope of this document. The main components of the architecture are: a real-time encapsulation format for asynchronous and synchronous low-bitrate links, a header compression architecture optimized for real-time flows, elements of negotiation protocols used between routers (or between hosts and routers), and announcement protocols used by applications to allow this negotiation to take place.
本文档描述了通过低比特率链路（如调制解调器线路、ISDN B通道和sub-T1链路）提供综合业务的体系结构。它仅涵盖Internet多媒体会议体系结构的较低部分[1]；应用程序服务所需的其他组件，如Internet电话（如会话启动协议），不在本文档的范围内。该体系结构的主要组成部分包括：异步和同步低比特率链路的实时封装格式、针对实时流优化的报头压缩体系结构、路由器之间（或主机与路由器之间）使用的协商协议元素，以及应用程序用于允许进行此协商的公告协议。
As an extension to the "best-effort" services the Internet is well-known for, additional types of services ("integrated services") that support the transport of real-time multimedia information are being developed for, and deployed in the Internet. Important elements of this development are:
作为互联网“尽力而为”服务的延伸，支持实时多媒体信息传输的其他类型的服务（“综合服务”）正在为互联网开发和部署。这一发展的重要内容包括：
- parameters for forwarding mechanisms that are appropriate for real-time information [11, 12],
- 适用于实时信息的转发机制的参数[11,12]，
- a setup protocol that allows establishing special forwarding treatment for real-time information flows (RSVP [4]),
- 允许为实时信息流（RSVP[4]）建立特殊转发处理的设置协议，
- a transport protocol for real-time information (RTP/RTCP [6]).
- 实时信息传输协议（RTP/RTCP[6]）。
In addition to these elements at the network and transport levels of the Internet Multimedia Conferencing Architecture [1], further components are required to define application services such as Internet Telephony, e.g., protocols for session initiation and control. These components are outside the scope of this document.
除了互联网多媒体会议体系结构[1]的网络和传输层的这些元素外，还需要其他组件来定义应用服务，如互联网电话，例如会话启动和控制协议。这些组件不在本文档的范围内。
Up to now, the newly developed services could not (or only very inefficiently) be used over forwarding paths that include low-bitrate links such as 14.4, 33.6, and 56 kbit/s modems, 56 and 64 kbit/s ISDN B-channels, or even sub-T1 links. The encapsulation formats used on these links are not appropriate for the simultaneous transport of arbitrary data and real-time information that has to meet stringent delay requirements. Transmission of a 1500 byte packet on a 28.8 kbit/s modem link makes this link unavailable for the transmission of real-time information for about 400 ms. This adds a worst-case delay that causes real-time applications to operate with round-trip delays on the order of at least a second -- unacceptable for real-time conversation. In addition, the header overhead associated with the protocol stacks used is prohibitive on low-bitrate links, where compression down to a few dozen bytes per real-time information packet is often desirable. E.g., the overhead of at least 44 (4+20+8+12) bytes for HDLC/PPP, IP, UDP, and RTP completely overshadows typical audio payloads such as the 19.75 bytes needed for a G.723.1 ACELP audio frame -- a 14.4 kbit/s link is completely consumed by this header overhead alone at 40 real-time frames per second total (i.e., at 25 ms packetization delay for one stream or 50 ms for two streams, with no space left for data, yet). While the header overhead can be reduced by combining several real-time information frames into one packet, this increases the delay incurred while filling that packet and further detracts from the goal of real-time transfer of multi-media information over the Internet.
到目前为止，新开发的业务无法（或只能非常低效地）在包括低比特率链路的转发路径上使用，例如14.4、33.6和56 kbit/s调制解调器、56和64 kbit/s ISDN B通道，甚至亚T1链路。这些链路上使用的封装格式不适合同时传输必须满足严格延迟要求的任意数据和实时信息。在28.8 kbit/s调制解调器链路上传输1500字节的数据包会使该链路在大约400 ms的时间内无法传输实时信息。这会增加最坏情况下的延迟，导致实时应用程序在往返延迟至少一秒的情况下运行，这对于实时对话来说是不可接受的。此外，与所使用的协议栈相关联的报头开销在低比特率链路上是禁止的，在低比特率链路上，通常需要将每个实时信息分组压缩到几十个字节。例如，HDLC/PPP、IP、UDP和RTP至少44（4+20+8+12）字节的开销完全掩盖了典型的音频有效负载，例如g.723.1 ACELP音频帧所需的19.75字节——14.4 kbit/s链路完全由该报头开销以每秒40个实时帧的速度消耗（即，一个流的打包延迟为25毫秒，两个流的打包延迟为50毫秒，尚未为数据留出空间）。虽然可以通过将多个实时信息帧组合成一个分组来减少报头开销，但这增加了填充该分组时产生的延迟，并进一步降低了通过因特网实时传输多媒体信息的目标。
This document describes an approach for addressing these problems. The main components of the architecture are:
本文档描述了解决这些问题的方法。该体系结构的主要组成部分包括：
- a real-time encapsulation format for asynchronous and synchronous low-bitrate links,
- 异步和同步低比特率链路的实时封装格式，
- a header compression architecture optimized for real-time flows,
- 针对实时流优化的报头压缩架构，
- elements of negotiation protocols used between routers (or between hosts and routers), and
- 路由器之间（或主机与路由器之间）使用的协商协议元素，以及
- announcement protocols used by applications to allow this negotiation to take place.
- 应用程序用于允许进行此协商的公告协议。
The main design goal for an architecture that addresses real-time multimedia flows over low-bitrate links is that of minimizing the end-to-end delay. More specifically, the worst case delay (after removing possible outliers, which are equivalent to packet losses from an application point of view) is what determines the playout points selected by the applications and thus the delay actually perceived by the user.
在低比特率链路上处理实时多媒体流的体系结构的主要设计目标是最小化端到端延迟。更具体地说，最坏情况下的延迟（在移除可能的异常值之后，从应用程序的角度来看，这相当于数据包丢失）决定了应用程序选择的播放点，从而决定了用户实际感知到的延迟。
In addition, any such architecture should obviously undertake every attempt to maximize the bandwidth actually available to media data; overheads must be minimized.
此外，任何这样的架构显然都应该尽一切努力最大化媒体数据的实际可用带宽；必须尽量减少管理费用。
An important component of the integrated services architecture is the provision of reservations for real-time flows. One of the problems that systems on low-bitrate links (routers or hosts) face when performing admission control for such reservations is that they must translate the bandwidth requested in the reservation to the one actually consumed on the link. Methods such as data compression and/or header compression can reduce the requirements on the link, but admission control can only make use of the reduced requirements in its calculations if it has enough information about the data stream to know how effective the compression will be. One goal of the architecture therefore is to provide the integrated services admission control with this information. A beneficial side effect may be to allow the systems to perform better compression than would be possible without this information. This may make it worthwhile to provide this information even when it is not intended to make a reservation for a real-time flow.
集成服务体系结构的一个重要组成部分是为实时流提供保留。低比特率链路（路由器或主机）上的系统在对此类预留执行准入控制时面临的问题之一是，它们必须将预留中请求的带宽转换为链路上实际消耗的带宽。诸如数据压缩和/或报头压缩之类的方法可以降低链路上的要求，但是如果许可控制具有足够的数据流信息来知道压缩将有多有效，则它只能在其计算中使用降低的要求。因此，该体系结构的一个目标是使用该信息提供集成服务准入控制。有益的副作用可能是允许系统执行比没有此信息时可能更好的压缩。这可能使提供此信息变得有价值，即使它不打算为实时流进行预订。
Many technical approaches come to mind for addressing these problems, in particular a new form of low-delay encapsulation to address delay and header compression methods to address overhead. This section shows that these techniques should be combined to solve the problem.
为了解决这些问题，人们想到了许多技术方法，特别是一种新形式的低延迟封装来解决延迟问题，以及头压缩方法来解决开销问题。本节说明应结合这些技术来解决问题。
The purpose of defining a real-time link-layer encapsulation protocol is to be able to introduce newly arrived real-time packets into the link-layer data stream without having to wait for the currently transmitted (possibly large) packet to end. Obviously, a real-time encapsulation must be part of any complete solution as the problem of delays induced by large frames on the link can only be solved on this layer.
定义实时链路层封装协议的目的是能够将新到达的实时分组引入链路层数据流，而不必等待当前发送的（可能较大的）分组结束。显然，实时封装必须是任何完整解决方案的一部分，因为链路上大帧引起的延迟问题只能在这一层上解决。
To be able to switch to a real-time packet quickly in an interface driver, it is first necessary to identify packets that belong to real-time flows. This can be done using a heuristic approach (e.g., favor the transmission of highly periodic flows of small packets transported in IP/UDP, or use the IP precedence fields in a specific way defined within an organization). Preferably, one also could make use of a protocol defined for identifying flows that require special treatment, i.e. RSVP. Of the two service types defined for use with RSVP now, the guaranteed service will only be available in certain environments; for this and various other reasons, the service type chosen for many adaptive audio/video applications will most likely be the controlled-load service. Controlled-load does not provide control parameters for target delay; thus it does not unambiguously identify those packet streams that would benefit most from being transported in a real-time encapsulation format. This calls for a way to provide additional parameters in integrated services flow setup protocols to control the real-time encapsulation.
为了能够在接口驱动程序中快速切换到实时数据包，首先需要识别属于实时流的数据包。这可以使用启发式方法实现（例如，支持以IP/UDP传输的小数据包的高周期流的传输，或者以组织内定义的特定方式使用IP优先级字段）。优选地，还可以使用为识别需要特殊处理的流（即RSVP）而定义的协议。在目前定义用于RSVP的两种服务类型中，保证服务仅在某些环境中可用；出于这一点和其他各种原因，许多自适应音频/视频应用程序选择的服务类型很可能是受控负载服务。受控负载不提供目标延迟的控制参数；因此，它不能明确地识别那些以实时封装格式传输的数据包流。这需要一种在集成服务流设置协议中提供额外参数的方法来控制实时封装。
Real-time encapsulation is not sufficient on its own, however: Even if the relevant flows can be appropriately identified for real-time treatment, most applications simply cannot operate properly on low-bitrate links with the header overhead implied by the combination of HDLC/PPP, IP, UDP, and RTP, i.e. they absolutely require header compression.
然而，实时封装本身是不够的：即使可以适当地识别相关流进行实时处理，大多数应用程序也无法在低比特率链路上正常运行，而HDLC/PPP、IP、UDP和RTP的组合意味着报头开销，即它们绝对需要报头压缩。
Header compression can be performed in a variety of elements and at a variety of levels in the protocol architecture. As many vendors of Internet Telephony products for PCs ship applications, the approach that is most obvious to them is to reduce overhead by performing header compression at the application level, i.e. above transport protocols such as UDP (or actually by using a non-standard, efficiently coded header in the first place).
报头压缩可以在协议体系结构中的各种元素和不同级别上执行。由于许多用于PC的Internet电话产品供应商都提供应用程序，他们最明显的方法是通过在应用程序级别执行报头压缩来减少开销，即在UDP等传输协议之上（或者实际上首先使用非标准、高效编码的报头）。
Generally, header compression operates by installing state at both ends of a path that allows the receiving end to reconstruct information omitted at the sending end. Many good techniques for header compression (RFC 1144, [2]) operate on the assumption that the path will not reorder the frames generated. This assumption does not hold for end-to-end compression; therefore additional overhead is required for resequencing state changes and for compressed packets making use of these state changes.
通常，报头压缩通过在允许接收端重构在发送端省略的信息的路径的两端安装状态来操作。许多好的报头压缩技术（RFC 1144[2]）都假设路径不会对生成的帧重新排序。这种假设不适用于端到端压缩；因此，对状态更改重新排序和利用这些状态更改的压缩数据包需要额外的开销。
Assume that a very good application level header compression solution for RTP flows could be able to save 11 out of the 12 bytes of an RTP header [3]. Even this perfect solution only reduces the total header overhead by 1/4. It would have to be deployed in all applications,
假设一个非常好的RTP流应用程序级报头压缩解决方案能够在RTP报头的12个字节中保存11个[3]。即使是这个完美的解决方案，也只能将总头开销减少1/4。它必须部署在所有应用程序中，
even those that operate on systems that are attached to higher-bitrate links.
即使是那些在连接到更高比特率链路的系统上运行的系统。
Because of this limited effectiveness, the AVT group that is responsible for RTP within the IETF has decided to not further pursue application level header compression.
由于这种有限的有效性，在IETF内负责RTP的AVT小组决定不再进一步追求应用级报头压缩。
For router and IP stack vendors, the obvious approach is to define header compression that can be negotiated between peer routers.
对于路由器和IP堆栈供应商来说，最明显的方法是定义可以在对等路由器之间协商的报头压缩。
Advanced header compression techniques now being defined in the IETF [2] certainly can relieve the link from significant parts of the IP/UDP overhead (i.e., most of 28 of the 44 bytes mentioned above).
IETF[2]中现在定义的高级报头压缩技术当然可以从IP/UDP开销的重要部分（即上述44个字节中的大部分28个字节）中释放链路。
One of the design principles of the new IP header compression developed in conjunction with IPv6 is that it stops at layers the semantics of which cannot be inferred from information in lower layer (outer) headers. Therefore, this header compression technique alone cannot compress the data that is contained within UDP packets.
与IPv6一起开发的新IP报头压缩的设计原则之一是，它停止在无法从较低层（外部）报头中的信息推断其语义的层。因此，仅此报头压缩技术无法压缩UDP数据包中包含的数据。
Any additional header compression technique runs into a problem: If it assumes specific application semantics (i.e., those of RTP and a payload data format) based on heuristics, it runs the risk of being triggered falsely and (e.g. in case of packet loss) reconstructing packets that are catastrophically incorrect for the application actually being used. A header compression technique that can be operated based on heuristics but does not cause incorrect decompression even if the heuristics failed is described in [7]; a companion document describes the mapping of this technique to PPP [10].
任何附加的报头压缩技术都会遇到问题：如果它采用基于启发式的特定应用程序语义（即RTP和有效负载数据格式的语义），那么它就有被错误触发的风险（例如，在数据包丢失的情况下）重建对于实际使用的应用程序来说极不正确的数据包。[7]中描述了一种头部压缩技术，该技术可以基于启发式操作，但即使启发式失败也不会导致错误的解压缩；配套文件描述了该技术与PPP的映射[10]。
With all of these techniques, the total IP/UDP/RTP header overhead for an audio stream can be reduced to two bytes per packet. This technology need only be deployed at bottleneck links; high-speed links can transfer the real-time streams without routers or switches expending CPU cycles to perform header compression.
使用所有这些技术，音频流的总IP/UDP/RTP报头开销可以减少到每个数据包两个字节。这项技术只需要部署在瓶颈环节；高速链路可以传输实时流，而无需路由器或交换机花费CPU周期来执行报头压缩。
The main design goal for a real-time encapsulation is to minimize the delay incurred by real-time packets that become available for sending while a long data packet is being sent. To achieve this, the encapsulation must be able to either abort or suspend the transfer of the long data packet. As an additional goal is to minimize the overhead required for the transmission of packets from periodic flows, this strongly argues for being able to suspend a packet, i.e. segment it into parts between which the real-time packets can be transferred.
实时封装的主要设计目标是最小化在发送长数据包时可用于发送的实时数据包所产生的延迟。为了实现这一点，封装必须能够中止或暂停长数据包的传输。由于另一个目标是最小化从周期流传输数据包所需的开销，因此这强烈要求能够暂停数据包，即将其分割为可在其之间传输实时数据包的部分。
Transmitting only part of a packet, to allow higher-priority traffic to intervene and then resuming its transmission later on, is a kind of fragmentation. Fragmentation is an existing functionality of the IP layer: An IPv4 header already contains fields that allow a large IP datagram to be fragmented into small parts. A sender's "real-time PPP" implementation might simply indicate a small MTU to its IP stack and thus cause all larger datagrams to be fragmented down to a size that allows the access delay goals to be met (this assumes that the IP stack is able to priority-tag fragments, or that the PPP implementation is able to correlate the fragments to the initial one that carries the information relevant for prioritizing, or that only initial fragments can be high-priority). (Also, a PPP implementation can negotiate down the MTU of its peer, causing the peer to fragment to a small size, which might be considered a crude form of negotiating an access delay goal with the peer system -- if that system supports priority queueing at the fragment level.)
仅传输数据包的一部分，以允许更高优先级的流量进行干预，然后在稍后恢复其传输，这是一种碎片。分段是IP层的现有功能：IPv4报头已经包含允许将大型IP数据报分段为小部分的字段。发送方的“实时PPP”实现可能只是向其IP堆栈指示一个小的MTU，从而导致所有较大的数据报被分割到允许满足访问延迟目标的大小（这假设IP堆栈能够对片段进行优先级标记，或者PPP实现能够将片段与携带与优先级相关信息的初始片段相关联，或者只有初始片段可以具有高优先级）。（此外，PPP实现可以向下协商对等机的MTU，导致对等机碎片较小，这可能被视为与对等机系统协商访问延迟目标的粗糙形式——如果该系统支持碎片级别的优先级排队。）
Unfortunately, a full, 20 byte IP header is needed for each fragment (larger when IP options are used). This limits the minimum size of fragments that can be used without too much overhead. (Also, the size of non-final fragments must be a multiple of 8 bytes, further limiting the choice.) With path MTU discovery, IP level fragmentation causes TCP implementations to use small MSSs -- this further increases the per-packet overhead to 40 bytes per fragment.
不幸的是，每个片段都需要一个完整的、20字节的IP报头（使用IP选项时会更大）。这限制了可以在没有太多开销的情况下使用的最小片段大小。（另外，非最终片段的大小必须是8字节的倍数，这进一步限制了选择。）通过路径MTU发现，IP级碎片导致TCP实现使用小型MSS——这进一步将每个数据包的开销增加到每个片段40字节。
In any case, fragmentation at the IP level persists on the path further down to the datagram receiver, increasing the transmission overheads and router load throughout the network. With its high overhead and the adverse effect on the Internet, IP level fragmentation can only be a stop-gap mechanism when no other fragmentation protocol is available in the peer implementation.
在任何情况下，IP级别的碎片都会继续存在于数据报接收器下方的路径上，从而增加整个网络的传输开销和路由器负载。由于其高开销和对Internet的不利影响，IP级别的碎片化只能在对等实现中没有其他可用的碎片化协议时作为权宜之计。
Cell-oriented multiplexing techniques such as ATM that introduce regular points where cells from a different packet can be interpolated are too inefficient for low-bitrate links; also, they are not supported by chips used to support the link layer in low-bitrate routers and host interfaces.
面向信元的多路复用技术（如ATM）引入了规则点，来自不同分组的信元可以在该点内插，对于低比特率链路来说效率太低；此外，在低比特率路由器和主机接口中用于支持链路层的芯片也不支持它们。
Instead, the real-time encapsulation should as far as possible make use of the capabilities of the chips that have been deployed. On synchronous lines, these chips support HDLC framing; on asynchronous lines, an asynchronous variant of HDLC that usually is implemented in software is being used. Both variants of HDLC provide a delimiting mechanism to indicate the end of a frame over the link. The obvious solution to the segmentation problem is to combine this mechanism with an indication of whether the delimiter terminates or suspends the current packet.
相反，实时封装应尽可能利用已部署芯片的功能。在同步线路上，这些芯片支持HDLC帧；在异步线路上，正在使用通常在软件中实现的HDLC的异步变体。HDLC的两种变体都提供了一种定界机制来指示链路上帧的结束。分割问题的明显解决方案是将此机制与分隔符是否终止或挂起当前数据包的指示相结合。
This indication could be in an octet appended to each frame information field; however, seven out of eight bits of the octet would be wasted. Instead, the bit could be carried at the start of the next frame in conjunction with multiplexing information (PPP protocol identifier etc.) that will be required here anyway. Since the real-time flows will in general be periodic, this multiplexing information could convey (part of) the compressed form of the header for the packet. If packets from the real-time flow generally are of constant length (or have a defined maximum length that is often used), the continuation of the suspended packet could be immediately attached to it, without expending a further frame delimiter, i.e., the interpolation of the real-time packet would then have zero overhead. Since packets from low-delay real-time flows generally will not require the ability to be further suspended, the continuation bit could be reserved for the non-real-time packet stream.
该指示可以是附加到每个帧信息字段的八位字节；然而，八位元中的七位元会被浪费掉。相反，该位可以在下一帧的开始处与多路复用信息（PPP协议标识符等）一起携带，这在这里无论如何都是必需的。由于实时流通常是周期性的，因此该多路复用信息可以传送（部分）分组的报头的压缩形式。如果来自实时流的分组通常具有恒定长度（或具有经常使用的定义的最大长度），则可以立即将挂起分组的延续附加到其上，而无需花费进一步的帧定界符，即，实时分组的内插随后将具有零开销。由于来自低延迟实时流的分组通常不需要进一步暂停的能力，因此可以为非实时分组流保留延续比特。
One real-time encapsulation format with these (and other) functions is described in ITU-T H.223 [13], the multiplex used by the H.324 modem-based videophone standard [14]. It was investigated whether compatibility could be achieved with this specification, which will be used in future videophone-enabled (H.324 capable) modems. However, since the multiplexing capabilities of H.223 are limited to 15 schedules (definitions of sequences of packet types that can be identified in a multiplex header), for general Internet usage a superset or a more general encapsulation would have been required. Also, a PPP-style negotiation protocol was needed instead of using (and necessarily extending) ITU-T H.245 [15] for setting the parameters of the multiplex. In the PPP context, the interactions with the encapsulations for data compression and link layer encryption needed to be defined (including operation in the presence of padding). But most important, H.223 requires synchronous HDLC chips that can be configured to send frames without an attached CRC, which is not possible with all chips deployed in commercially available routers; so complete compatibility was unachievable.
ITU-T H.223[13]中描述了一种具有这些（和其他）功能的实时封装格式，该格式由基于H.324调制解调器的可视电话标准[14]使用。研究了该规范是否能够实现兼容性，该规范将用于未来支持可视电话（支持H.324）的调制解调器。然而，由于H.223的多路复用能力限于15个调度（可在多路复用报头中识别的分组类型序列的定义），对于一般因特网使用，将需要超集或更一般的封装。此外，还需要一个PPP风格的协商协议，而不是使用（并必须扩展）ITU-T H.245[15]来设置多路复用的参数。在PPP上下文中，需要定义与数据压缩和链路层加密封装的交互（包括存在填充的操作）。但最重要的是，H.223需要同步HDLC芯片，该芯片可以配置为在没有附加CRC的情况下发送帧，这在商用路由器中部署的所有芯片中是不可能的；所以完全兼容是不可能实现的。
Instead of adopting H.223, it was decided to pursue an approach that is oriented towards compatibility both with existing hardware and existing software (in particular PPP) implementations. The next subsection groups these implementations according to their capabilities.
与采用H.223不同的是，决定采用一种与现有硬件和现有软件（特别是PPP）实现兼容的方法。下一小节将根据这些实现的功能对它们进行分组。
This section introduces a number of terms for types of implementations that are likely to emerge. It is important to have these different implementation models in mind as there is no single approach that fits all models best.
本节介绍了一些可能出现的实现类型的术语。记住这些不同的实现模型很重要，因为没有一种方法最适合所有模型。
There are two fundamental approaches to real-time transmission on low-bitrate links:
在低比特率链路上实时传输有两种基本方法：
Sender type 1 The PPP real-time framing implementation is able to control the transmission of each byte being transmitted with some known, bounded delay (e.g., due to FIFOs). For example, this is generally true of PC host implementations, which directly access serial interface chips byte by byte or by filling a very small FIFO. For type 1 senders, a suspend/resume type approach will be typically used: When a long frame is to be sent, the attempt is to send it undivided; only if higher priority packets come up during the transmission will the lower-priority long frame be suspended and later resumed. This approach allows the minimum variation in access delay for high-priority packets; also, fragmentation overhead is only incurred when actually needed.
发送方类型1 PPP实时成帧实现能够以某种已知的有界延迟（例如，由于FIFO）控制每个字节的传输。例如，这通常适用于PC主机实现，它直接逐字节访问串行接口芯片或通过填充非常小的FIFO。对于类型1发送方，通常使用挂起/恢复类型方法：当要发送长帧时，尝试不分割地发送；只有在传输过程中出现较高优先级的数据包时，较低优先级的长帧才会暂停，并在稍后恢复。该方法允许高优先级分组的访问延迟的最小变化；此外，碎片开销仅在实际需要时产生。
Sender type 2 With type 2 senders, the interface between the PPP real-time framing implementation and the transmission hardware is not in terms of streams of bytes, but in terms of frames, e.g., in the form of multiple (prioritized) send queues directly supported by hardware. This is often true of router systems for synchronous links, in particular those that have to support a large number of low-bitrate links. As type 2 senders have no way to suspend a frame once it has been handed down for transmission, they typically will use a queues-of-fragments approach, where long packets are always split into units that are small enough to maintain the access delay goals for higher-priority traffic. There is a trade-off between the variation in access delay resulting from a large fragment size and the overhead that is incurred for every long packet by choosing a small fragment size.
发送方类型2对于类型2发送方，PPP实时帧实现和传输硬件之间的接口不是字节流，而是帧，例如，以硬件直接支持的多个（优先）发送队列的形式。这通常适用于同步链路的路由器系统，尤其是那些必须支持大量低比特率链路的路由器系统。由于类型2发送方无法在帧被传递以进行传输后挂起帧，因此它们通常会使用片段队列方法，其中长数据包总是被分割成足够小的单元，以维持较高优先级流量的访问延迟目标。在由大片段大小引起的访问延迟变化与通过选择小片段大小为每个长分组产生的开销之间存在权衡。
Although the actual work of formulating transmission streams for real-time applications is performed at the sender, the ability of the receiver to immediately make use of the information received depends on its characteristics:
尽管为实时应用制定传输流的实际工作是在发送方执行的，但接收方立即利用接收到的信息的能力取决于其特性：
Receiver type 1 Type 1 receivers have full control over the stream of bytes received within PPP frames, i.e., bytes received are available immediately to the PPP real-time framing implementation (with some known, bounded delay e.g. due to FIFOs etc.).
接收器类型1类型1接收器对PPP帧内接收的字节流具有完全控制权，即接收的字节可立即用于PPP实时帧实现（具有一些已知的有界延迟，例如由于FIFO等）。
Receiver type 2 With type 2 receivers, the PPP real-time framing implementation only gets hold of a frame when it has been received completely, i.e., the final flag has been processed (typically by some HDLC chip that directly fills a memory buffer).
接收器类型2对于类型2接收器，PPP实时成帧实现仅在完全接收到帧时获得帧，即，最终标志已被处理（通常由直接填充内存缓冲区的某个HDLC芯片处理）。
As a result of the diversity in capabilities of current implementations, there are now two specifications for real-time encapsulation: One, the multi-class extension to the PPP multi-link protocol, is providing the solution for the queues-of-fragments approach by extending the single-stream PPP multi-link protocol by multiple classes [8]. The other encapsulation, PPP in a real-time oriented HDLC-like framing, builds on this specification end extends it by a way to dynamically delimit multiple fragments within one HDLC frame [9], providing the solution for the suspend/resume type approach.
由于当前实现能力的多样性，现在有两种实时封装规范：一种是PPP多链路协议的多类扩展，通过将单流PPP多链路协议扩展到多个类来提供碎片队列方法的解决方案[8]。另一种封装，类似于HDLC的实时帧中的PPP，建立在该规范的基础上，通过在一个HDLC帧中动态划分多个片段[9]的方式对其进行扩展，为挂起/恢复类型方法提供了解决方案。
A good baseline for a discussion about header compression is in the new IP header compression specification that was designed in conjunction with the development of IPv6 [2]. The techniques used there can reduce the 28 bytes of IPv4/UDP header to about 6 bytes (depending on the number of concurrent streams); with the remaining 4 bytes of HDLC/PPP overhead and 12 bytes for RTP the total header overhead can be about halved but still exceeds the size of a G.723.1 ACELP frame. Note that, in contrast to IP header compression, the environment discussed here assumes the existence of a full-duplex PPP link and thus can rely on negotiation where IP header compression requires repeated transmission of the same information. (The use of the architecture of the present document with link layer multicasting has not yet been examined.)
关于报头压缩的讨论的一个很好的基线是新的IP报头压缩规范，该规范是与IPv6的开发一起设计的[2]。那里使用的技术可以将IPv4/UDP报头的28个字节减少到大约6个字节（取决于并发流的数量）；在剩下的4字节HDLC/PPP开销和12字节RTP开销的情况下，总报头开销可以减少一半，但仍然超过G.723.1 ACELP帧的大小。注意，与IP报头压缩相反，这里讨论的环境假设存在全双工PPP链路，因此可以依赖于协商，其中IP报头压缩需要重复传输相同的信息。（本文件的体系结构与链路层多播的使用尚未得到研究。）
Additional design effort was required for RTP header compression. Applying the concepts of IP header compression, of the (at least) 12 bytes in an RTP header, 7 bytes (timestamp, sequence, and marker bit) would qualify as RANDOM; DELTA encoding cannot generally be used without further information since the lower layer header does not unambiguously identify the semantics and there is no TCP checksum that can be relied on to detect incorrect decompression. Only a more semantics-oriented approach can provide better compression (just as RFC 1144 can provide very good compression of TCP headers by making use of semantic knowledge of TCP and its checksumming method).
RTP标头压缩需要额外的设计工作。应用IP报头压缩的概念，在RTP报头中（至少）12个字节中，7个字节（时间戳、序列和标记位）将符合随机条件；如果没有进一步的信息，通常不能使用增量编码，因为较低的层头不能明确地标识语义，并且没有可以用来检测错误解压缩的TCP校验和。只有更加面向语义的方法才能提供更好的压缩（正如RFC1144可以利用TCP的语义知识及其校验和方法提供非常好的TCP头压缩）。
For RTP packets, differential encoding of the sequence number and timestamps is an efficient approach for certain cases of payload data formats. E.g., speech flows generally have sequence numbers and timestamp fields that increase by 1 and by the frame size in timestamp units, resp.; the CRTP (compressed RTP) specification makes use of this relationship by encoding these fields only when the second order difference is non-zero [7].
对于RTP数据包，序列号和时间戳的差分编码对于负载数据格式的某些情况是一种有效的方法。例如，语音流通常具有序列号和时间戳字段，它们分别以时间戳单位增加1和帧大小。；CRTP（compressed RTP）规范仅在二阶差非零时对这些字段进行编码，从而利用了这种关系[7]。
As argued, the compressor can operate best if it can make use of information that clearly identifies real-time streams and provides information about the payload data format in use.
如前所述，如果压缩机能够利用清楚识别实时流的信息，并提供有关所使用的有效负载数据格式的信息，则压缩机可以运行得最好。
If these systems are routers, this consent must be installed as router state; if these systems are hosts, it must be known to their networking kernels. Sources of real-time information flows are already describing characteristics of these flows to their kernels and to the routers in the form of TSpecs in RSVP PATH messages [4]. Since these messages make use of the router alert option, they are seen by all routers on the path; path state about the packet stream is normally installed at each of these routers that implement RSVP. Additional RSVP objects could be defined that are included in PATH messages by those applications that desire good performance over low-bitrate links; these objects would be coded to be ignored by routers that are not interested in them (class number 11bbbbbb as defined in [4], section 3.10).
如果这些系统是路由器，则必须以路由器状态安装此许可；如果这些系统是主机，那么它们的网络内核必须知道它。实时信息流的来源已经在RSVP PATH消息中以TSPEC的形式描述这些流到内核和路由器的特征[4]。由于这些消息使用路由器警报选项，因此路径上的所有路由器都可以看到这些消息；包流的路径状态通常安装在每个实现RSVP的路由器上。可以定义附加的RSVP对象，这些对象由那些希望在低比特率链路上获得良好性能的应用程序包含在路径消息中；这些对象将被编码为对它们不感兴趣的路由器忽略（第3.10节[4]中定义的类别号11bbbbbb）。
Note that the path state is available in the routers even when no reservation is made; this allows informed compression of best-effort traffic. It is not quite clear, though, how path state could be torn down quickly when a source ceases to transmit.
请注意，即使没有预订，路由器中的路径状态也是可用的；这允许对尽力而为的流量进行知情压缩。然而，当一个源停止传输时，路径状态如何能被迅速破坏还不太清楚。
The IP header compression specification attempts to account for simplex and multicast links by providing information about the compressed streams only in the forward direction. E.g., a full IP/UDP header must be sent after F_MAX_TIME (currently 3 seconds), which is a negligible total overhead (e.g. one full header every 150 G.723.1 packets), but must be considered carefully in scheduling the real-time transmissions. Both simplex and multicast links are not prevailing in the low-bitrate environment (although multicast functionality may become more important with wireless systems); in this document, we therefore assume full-duplex capability.
IP报头压缩规范试图通过仅在前进方向上提供有关压缩流的信息来说明单工链路和多播链路。例如，完整IP/UDP报头必须在F_MAX_TIME（当前为3秒）之后发送，这是一个可忽略的总开销（例如，每150个g.723.1数据包发送一个完整报头），但在调度实时传输时必须仔细考虑。单工链路和多播链路在低比特率环境中并不普遍（尽管多播功能在无线系统中可能变得更加重要）；因此，在本文档中，我们假设具有全双工功能。
As compression techniques will improve, a negotiation between the two peers on the link would provide the best flexibility in implementation complexity and potential for extensibility. The peer routers/hosts can decide which real-time packet streams are to be compressed, which header fields are not to be sent at all, which multiplexing information should be used on the link, and how the remaining header fields should be encoded. PPP, a well-tried suite of negotiation protocols, is already used on most of the low-bitrate links and seems to provide the obvious approach. Cooperation from PPP is also needed to negotiate the use of real-time encapsulations between systems that are not configured to automatically do so. Therefore, PPP options that can be negotiated at the link setup (LCP) phase are included in [8], [9], and [10].
随着压缩技术的改进，链路上的两个对等方之间的协商将在实现复杂性和可扩展性方面提供最佳的灵活性。对等路由器/主机可以决定要压缩哪些实时分组流、根本不发送哪些报头字段、应该在链路上使用哪些多路复用信息以及应该如何对剩余报头字段进行编码。PPP是一套久经考验的协商协议，已经在大多数低比特率链路上使用，似乎提供了显而易见的方法。还需要PPP的合作来协商在未配置为自动进行实时封装的系统之间使用实时封装。因此，可在链路设置（LCP）阶段协商的PPP选项包括在[8]、[9]和[10]中。
Header compression protocols that make use of assumptions about application protocols need to be carefully analyzed whether it is possible to subvert other applications by maliciously or inadvertently enabling their use.
需要仔细分析利用应用程序协议假设的报头压缩协议是否可能通过恶意或无意地启用其他应用程序来破坏它们。
It is generally not possible to do significant hop-by-hop header compression on encrypted streams. With certain security policies, it may be possible to run an encrypted tunnel to a network access server that does header compression on the decapsulated packets and sends them over an encrypted link encapsulation; see also the short mention of interactions between real-time encapsulation and encryption in section 4 above. If the security requirements permit, a special RTP payload data format that encrypts only the data may preferably be used.
通常不可能对加密流进行有效的逐跳标头压缩。使用某些安全策略，可以运行到网络访问服务器的加密隧道，该网络访问服务器对解除封装的分组进行报头压缩，并通过加密链路封装发送它们；另请参见上文第4节中对实时封装和加密之间交互的简短介绍。如果安全要求允许，可优选使用仅加密数据的特殊RTP有效载荷数据格式。
[1] Handley, M., Crowcroft, J., Bormann, C. and J. Ott, "The Internet Multimedia Conferencing Architecture", Work in Progress.
[1] Handley，M.，Crowcroft，J.，Bormann，C.和J.Ott，“互联网多媒体会议架构”，正在进行中。
[2] Degermark, M., Nordgren, B. and S. Pink, "IP Header Compression", RFC 2507, February 1999.
[2] Degermark，M.，Nordgren，B.和S.Pink，“IP头压缩”，RFC 2507，1999年2月。
[3] Scott Petrack, Ed Ellesson, "Framework for C/RTP: Compressed RTP Using Adaptive Differential Header Compression", contribution to the mailing list rem-conf@es.net, February 1996.
[3] Scott Petrack，Ed Ellsson，“C/RTP框架：使用自适应差分头压缩的压缩RTP”，对邮件列表rem的贡献-conf@es.net，1996年2月。
[4] Braden, R., Zhang, L., Berson, S., Herzog, S. and S. Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification", RFC 2205, September 1997.
[4] Braden，R.，Zhang，L.，Berson，S.，Herzog，S.和S.Jamin，“资源预留协议（RSVP）——第1版功能规范”，RFC 22052997年9月。
[5] Sklower, K., Lloyd, B., McGregor, G., Carr, D. and T. Coradetti, "The PPP Multilink Protocol (MP)", RFC 1990, August 1996.
[5] K.Sklower、Lloyd、B.McGregor、G.Carr、D.和T.Coradetti，“PPP多链路协议（MP）”，RFC 1990，1996年8月。
[6] Schulzrinne, H., Casner, S., Frederick, R. and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", RFC 1889, January 1996.
[6] Schulzrinne，H.，Casner，S.，Frederick，R.和V.Jacobson，“RTP：实时应用的传输协议”，RFC 1889，1996年1月。
[7] Casner, S. and V. Jacobson, "Compressing IP/UDP/RTP Headers for Low-Speed Serial Links", RFC 2508, February 1999.
[7] Casner，S.和V.Jacobson，“压缩低速串行链路的IP/UDP/RTP报头”，RFC 2508，1999年2月。
[8] Bormann, C., "The Multi-Class Extension to Multi-Link PPP", RFC 2686, September 1999.
[8] Bormann，C.，“多链路PPP的多类扩展”，RFC 2686，1999年9月。
[9] Bormann, C., "PPP in a Real-time Oriented HDLC-like Framing", RFC 2687, September 1999.
[9] Bormann，C.“实时定向HDLC样帧中的PPP”，RFC 2687，1999年9月。
[10] Engan, M., Casner, S. and C. Bormann, "IP Header Compression over PPP", RFC 2509, February 1999.
[10] Engan，M.，Casner，S.和C.Bormann，“PPP上的IP报头压缩”，RFC 2509，1999年2月。
[11] Wroclawski, J., "Specification of the Controlled-Load Network Element Service", RFC 2211, September 1997.
[11] Wroclawski，J.，“受控负荷网元服务规范”，RFC2211，1997年9月。
[12] Shenker, S., Partridge, C. and R. Guerin. "Specification of Guaranteed Quality of Service", RFC 2212, September 1997.
[12] 申克、帕特里奇、C.和R.盖林。“保证服务质量规范”，RFC2212，1997年9月。
[13] ITU-T Recommendation H.223, "Multiplexing protocol for low bit rate multimedia communication", International Telecommunication Union, Telecommunication Standardization Sector (ITU-T), March 1996.
[13] ITU-T建议H.223，“低比特率多媒体通信的多路复用协议”，国际电信联盟，电信标准化部门（ITU-T），1996年3月。
[14] ITU-T Recommendation H.324, "Terminal for low bit rate multimedia communication", International Telecommunication Union, Telecommunication Standardization Sector (ITU-T), March 1996.
[14] ITU-T建议H.324，“低比特率多媒体通信终端”，国际电信联盟，电信标准化部门（ITU-T），1996年3月。
[15] ITU-T Recommendation H.245, "Control protocol for multimedia communication", International Telecommunication Union, Telecommunication Standardization Sector (ITU-T), March 1996.
[15] ITU-T建议H.245，“多媒体通信控制协议”，国际电信联盟，电信标准化部门（ITU-T），1996年3月。
Carsten Bormann Universitaet Bremen FB3 TZI Postfach 330440 D-28334 Bremen, GERMANY
德国不来梅卡斯滕·鲍曼大学FB3 TZI Postfach 330440 D-28334
Phone: +49.421.218-7024
Fax: +49.421.218-7000
EMail: cabo@tzi.org
Phone: +49.421.218-7024
Fax: +49.421.218-7000
EMail: cabo@tzi.org
Acknowledgements
致谢
Much of the early discussion that led to this document was done with Scott Petrack and Cary Fitzgerald. Steve Casner, Mikael Degermark, Steve Jackowski, Dave Oran, the other members of the ISSLL subgroup on low bitrate links (ISSLOW), and in particular the ISSLL WG co-chairs Eric Crawley and John Wroclawski have helped in making this architecture a reality.
本文件的大部分早期讨论都是由斯科特·彼得拉克和卡里·菲茨杰拉德完成的。Steve Casner、Mikael Degermark、Steve Jackowski、Dave Oran、ISSLL低比特率链路分组（ISSLOW）的其他成员，特别是ISSLL工作组的联合主席Eric Crawley和John Wroclawski，帮助实现了该体系结构。
Full Copyright Statement
完整版权声明
Copyright (C) The Internet Society (1999). All Rights Reserved.
版权所有（C）互联网协会（1999年）。版权所有。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
本文件及其译本可复制并提供给他人，对其进行评论或解释或协助其实施的衍生作品可全部或部分编制、复制、出版和分发，不受任何限制，前提是上述版权声明和本段包含在所有此类副本和衍生作品中。但是，不得以任何方式修改本文件本身，例如删除版权通知或对互联网协会或其他互联网组织的引用，除非出于制定互联网标准的需要，在这种情况下，必须遵循互联网标准过程中定义的版权程序，或根据需要将其翻译成英语以外的其他语言。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上述授予的有限许可是永久性的，互联网协会或其继承人或受让人不会撤销。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
本文件和其中包含的信息是按“原样”提供的，互联网协会和互联网工程任务组否认所有明示或暗示的保证，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Acknowledgement
确认
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。