Network Working Group C. Bormann
Request for Comments: 2687 Universitaet Bremen TZI
Category: Standards Track September 1999
Network Working Group C. Bormann
Request for Comments: 2687 Universitaet Bremen TZI
Category: Standards Track September 1999
PPP in a Real-time Oriented HDLC-like Framing
面向实时的类HDLC帧中的PPP
Status of this Memo
本备忘录的状况
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
本文件规定了互联网社区的互联网标准跟踪协议，并要求进行讨论和提出改进建议。有关本协议的标准化状态和状态，请参考当前版本的“互联网官方协议标准”（STD 1）。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The Internet Society (1999). All Rights Reserved.
版权所有（C）互联网协会（1999年）。版权所有。
Abstract
摘要
A companion document describes an architecture for providing integrated services over low-bitrate links, such as modem lines, ISDN B-channels, and sub-T1 links [1]. 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链路）提供综合业务的体系结构[1]。该体系结构的主要组成部分包括：异步和同步低比特率链路的实时封装格式、针对实时流优化的报头压缩体系结构、路由器之间（或主机与路由器之间）使用的协商协议元素，以及应用程序用于允许进行此协商的公告协议。
This document proposes the suspend/resume-oriented solution for the real-time encapsulation format part of the architecture. The general approach is to start from the PPP Multilink fragmentation protocol [2] and its multi-class extension [5] and add suspend/resume in a way that is as compatible to existing hard- and firmware as possible.
本文档针对体系结构的实时封装格式部分提出了面向暂停/恢复的解决方案。一般方法是从PPP多链路分段协议[2]及其多类扩展[5]开始，以尽可能兼容现有硬件和固件的方式添加挂起/恢复。
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.
作为互联网“尽力而为”服务的延伸，支持实时多媒体信息传输的其他类型的服务（“综合服务”）正在为互联网开发和部署。
The present document defines the suspend/resume-oriented solution for the real-time encapsulation format part of the architecture. As described in more detail in the architecture document, a real-time encapsulation format is required as, e.g., a 1500 byte packet on a
本文档为体系结构的实时封装格式部分定义了面向暂停/恢复的解决方案。如架构（architecture）文档中更详细地描述的，实时封装格式是必需的，例如，网络上的1500字节数据包
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.
28.8 kbit/s调制解调器链路使该链路在大约400 ms的时间内无法传输实时信息。这增加了最坏情况下的延迟，导致实时应用程序在往返延迟至少为1秒的情况下运行，这对于实时对话来说是不可接受的。
A true suspend/resume-oriented approach can only be implemented on a type-1 sender [1], but provides the best possible delay performance to this type of senders. The format defined in this document may also be of interest to certain type-2-senders that want to exploit the better bit-efficiency of this format as compared to [5]. The format was designed so that it can be implemented by both type-1 and type-2 receivers.
真正的面向挂起/恢复的方法只能在类型1发送方[1]上实现，但可以为此类发送方提供最佳的延迟性能。与[5]相比，本文件中定义的格式可能对某些想要利用此格式更好比特效率的2型发送方也感兴趣。该格式的设计使其可由1型和2型接收机实现。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [8].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照RFC 2119[8]中所述进行解释。
The requirements for this document are similar to those listed in [5].
本文件的要求与[5]中列出的要求类似。
A suspend/resume-oriented solution can provide better worst-case latency than the pre-fragmenting-oriented solution defined in [5]. Also, as this solution requires a new encapsulation scheme, there is an opportunity to provide a slightly more efficient format.
与[5]中定义的面向预碎片化的解决方案相比，面向挂起/恢复的解决方案可以提供更好的最坏情况延迟。此外，由于此解决方案需要新的封装方案，因此有机会提供稍微更有效的格式。
Predictability, robustness, and cooperation with PPP and existing hard- and firmware installations are as important with suspend/resume as with pre-fragmenting. A good suspend/resume solution achieves good performance even with type-2 receivers [1] and is able to work with PPP hardware such as async-to-sync converters.
可预测性、健壮性以及与PPP和现有硬件和固件安装的合作对于挂起/恢复和预碎片化同样重要。良好的挂起/恢复解决方案即使使用2型接收机也能获得良好的性能[1]，并且能够使用PPP硬件，如异步到同步转换器。
Finally, a partial non-requirement: While the format defined in this draft is based on the PPP multilink protocol ([2], also abbreviated as MP), operation over multiple links is in many cases not required.
最后，部分非要求：虽然本草案中定义的格式基于PPP多链路协议（[2]，也缩写为MP），但在许多情况下不需要在多个链路上进行操作。
As in [5], the general approach is to start out from PPP multilink and add multiple classes to obtain multiple levels of suspension. However, in contrast to [5], more significant changes are required to be able to suspend the transmission of a packet at any point and inject a higher priority packet.
如[5]中所述，一般方法是从PPP multilink开始，添加多个类以获得多个级别的暂停。然而，与[5]相比，为了能够在任何点暂停数据包的传输并注入更高优先级的数据包，需要进行更重要的更改。
The applicability of the multilink header for suspend/resume type implementations is limited, as the "end" bit is in the multilink header, which is the wrong place for suspend/resume operation. To make a big packet suspendable, it must be sent with the "end" bit off, and (unless the packet was suspended a small number of bytes before its end) an empty fragment has to be sent afterwards to "close" the packet. The minimum overhead for sending a suspendable packet thus is twice the multilink header size (six bytes, including a compressed multilink protocol field) plus one PPP framing (three bytes). Each suspension costs another six bytes (not counting the overhead of the framing for the intervening packet).
多链接头对于挂起/恢复类型实现的适用性是有限的，因为“结束”位位于多链接头中，这是挂起/恢复操作的错误位置。要使大数据包可挂起，必须在“结束”位关闭的情况下发送它，并且（除非数据包在结束前挂起了少量字节），之后必须发送一个空片段以“关闭”数据包。因此，发送可挂起数据包的最小开销是多链路报头大小的两倍（六个字节，包括压缩的多链路协议字段）加上一个PPP帧（三个字节）。每个暂停需要另外六个字节（不包括中间数据包的帧开销）。
Also, the existing multi-link header is relatively large; as the frequency of small high-priority packets increases, the overhead becomes significant.
而且，现有的多链路报头相对较大；随着小的高优先级分组的频率增加，开销变得显著。
The general approach of this document is to start from PPP Multilink with classes and provide a number of extensions to add functionality and reduce the overhead of using PPP Multilink for real-time transmission.
本文档的一般方法是从具有类的PPP多链路开始，并提供大量扩展，以添加功能并减少使用PPP多链路进行实时传输的开销。
This document introduces two new features:
本文档介绍了两个新功能：
1) A compact fragment format and header, and
1) 紧凑的片段格式和标题，以及
2) a real-time frame format.
2) 实时帧格式。
This section describes an optional multilink fragment format that is more optimized towards single-link operation and frequent suspension (type 1 senders)/a small fragment size (type 2 senders), with optional support for multiple links.
本节介绍一种可选的多链路片段格式，该格式针对单链路操作和频繁挂起（类型1发送方）/小片段大小（类型2发送方）进行了优化，并可选支持多链路。
When operating over a single link, the Multilink sequence number is used only for loss detection. Even a 12-bit sequence number clearly is larger than required for this application on most kinds of links. We therefore define the following compact multilink header format option with a three-bit sequence number.
在单个链路上运行时，多链路序列号仅用于丢失检测。在大多数链路上，即使是12位序列号也明显大于此应用程序所需的序列号。因此，我们使用三位序列号定义以下压缩多行标题格式选项。
As, with a compact header, there is little need for sending packets outside the multilink, we can provide an additional compression mechanism for this format: the MP protocol identifier is not sent with the compact fragment header. This obviously requires prior negotiation (similar to the way address and control field compression are negotiated), as well as a method for avoiding the bit combination
由于使用压缩头，几乎不需要在多链路之外发送数据包，因此我们可以为这种格式提供额外的压缩机制：MP协议标识符不随压缩段头一起发送。这显然需要事先协商（类似于协商地址和控制字段压缩的方式），以及避免位组合的方法
0xFF (the first octet in an LCP frame before any LCP options have been negotiated), as the start of a new LCP negotiation could otherwise not be reliably detected.
0xFF（协商任何LCP选项之前LCP帧中的第一个八位字节），否则无法可靠地检测到新LCP协商的开始。
Figure 1: Compact Fragment Format
图1：紧凑片段格式
0 1 2 3 4 5 6 7
+---+---+---+---+---+---+---+---+
| R | sequence | class | 1 |
+---+---+---+---+---+---+---+---+
| data |
: :
+---+---+---+---+---+---+---+---+
0 1 2 3 4 5 6 7
+---+---+---+---+---+---+---+---+
| R | sequence | class | 1 |
+---+---+---+---+---+---+---+---+
| data |
: :
+---+---+---+---+---+---+---+---+
Having the least significant bit always be 1 helps with HDLC chips that operate specially on least significant bits in HDLC addresses. (Initial bytes with the least significant bit set to zero are used for the extended compact fragment format, see next section.)
使最低有效位始终为1有助于HDLC芯片在HDLC地址中的最低有效位上进行特殊操作。（最低有效位设置为零的初始字节用于扩展紧凑片段格式，请参阅下一节。）
The R bit is the inverted equivalent of the B bit in the other multilink fragment formats, i.e. R = 1 means that this fragment resumes a packet previous fragments of which have been sent already.
R位与其他多链路片段格式中的B位相反，即R=1表示该片段恢复先前已发送片段的数据包。
The following trick avoids the case of a header byte of 0xFF (which would mean R=1, sequence=7, and class=7): If the class field is set to 7, the R bit MUST never be set to one. I.e., class 7 frames by design cannot be suspended/resumed. (This is also the reason the sense of the B bit is inverted to an R bit in the compact fragment format -- class 7 would be useless otherwise, as a new packet could never be begun.)
下面的技巧避免了头字节为0xFF的情况（这意味着R=1，sequence=7，class=7）：如果class字段设置为7，则R位决不能设置为1。即，根据设计，7级框架不能暂停/恢复。（这也是为什么在紧凑的片段格式中，B位的意义被反转为R位的原因——否则类7将毫无用处，因为新的数据包永远无法开始。）
As the sequence number is not particularly useful with the class field set to 7, it is used to distinguish eight more classes -- for some minor additional complexity, the applicability of prefix elision is significantly increased by providing more classes with possibly different elided prefixes.
由于序列号在类字段设置为7时并不特别有用，因此它用于区分另外八个类——对于一些较小的额外复杂性，通过提供更多具有可能不同的省略前缀的类，前缀省略的适用性显著提高。
For purposes of prefix elision, the actual class number of a fragment is computed as follows:
出于前缀省略的目的，片段的实际类号计算如下：
- If the class field is 0 to 6, the class number is 0 to 6,
- 如果类别字段为0到6，则类别编号为0到6，
- if the class field is 7 and the sequence field is 0 to 7, the class number is 7 to 14.
- 如果类别字段为7，序列字段为0到7，则类别编号为7到14。
As a result of this scheme, the classes 0 to 6 can be used for suspendable packets, and classes 7 to 14 (where the class field is 7 and the R bit must always be off) can be used for non-suspendable high-priority classes, e.g., eight highly compressed voice streams.
作为该方案的结果，类0至6可用于可挂起的分组，类7至14（其中类字段为7且R位必须始终为off）可用于不可挂起的高优先级类，例如八个高度压缩的语音流。
For operation over multiple links, a three-bit sequence number will rarely be sufficient. Therefore, we define an optional extended compact fragment format. The option, when negotiated, allows both the basic compact fragment format and the extended compact fragment format to be used; each fragment indicates which format it is in.
对于多链路上的操作，三位序列号很少足够。因此，我们定义了一种可选的扩展紧凑片段格式。当协商时，该选项允许使用基本紧凑片段格式和扩展紧凑片段格式；每个片段都指示它的格式。
Figure 1: Extended Compact Fragment Format
图1：扩展紧凑片段格式
0 1 2 3 4 5 6 7
+---+---+---+---+---+---+---+---+
| R | seq LSB | class | 0 |
+---+---+---+---+---+---+---+---+
| sequence -- MSB | 1 |
+---+---+---+---+---+---+---+---+
| data |
: :
+---+---+---+---+---+---+---+---+
0 1 2 3 4 5 6 7
+---+---+---+---+---+---+---+---+
| R | seq LSB | class | 0 |
+---+---+---+---+---+---+---+---+
| sequence -- MSB | 1 |
+---+---+---+---+---+---+---+---+
| data |
: :
+---+---+---+---+---+---+---+---+
In the extended compact fragment format, the sequence number is composed of three least significant bits from the first octet of the fragment header and seven most significant bits from the second octet. (Again, the least significant bit of the second octet is always set to one for compatibility with certain HDLC chips.)
在扩展紧凑片段格式中，序列号由片段头的第一个八位字节的三个最低有效位和第二个八位字节的七个最高有效位组成。（同样，为了与某些HDLC芯片兼容，第二个八位字节的最低有效位始终设置为1。）
For prefix elision purposes, fragments with a class field of 7 can use the basic format to indicate classes 7 to 14 and the extended format to indicate classes 7 to 1030. Different classes may use different formats concurrently without problems. (This allows some classes to be spread over a multi-link and other classes to be confined to a single link with greater efficiency.) For class fields 0 to 6, i.e. suspendable classes, one of the two compact fragment formats SHOULD be used consistently within each class.
出于前缀省略的目的，类字段为7的片段可以使用基本格式表示类7到14，使用扩展格式表示类7到1030。不同的类可以同时使用不同的格式，而不会出现问题。（这允许一些类分布在多链接上，而其他类被限制在单个链接上，效率更高。）对于类字段0到6，即可挂起的类，应在每个类中一致使用两种紧凑片段格式中的一种。
If the use of the extended compact fragment format has been negotiated, receivers MAY keep 10-bit sequence numbers for all classes to facilitate senders switching formats in a class. When a sender starts sending basic format fragments in a class that was using extended format fragments, the 3-bit sequence number can be taken as a modulo-8 version of the 10-bit sequence number, and no discontinuity need result. In the inverse case, if a 10-bit sequence number has been kept throughout by the receiver (and no major slips
如果已协商使用扩展紧凑片段格式，则接收器可为所有类别保留10位序列号，以便于发送者在类别中切换格式。当发送方开始在使用扩展格式片段的类中发送基本格式片段时，3位序列号可以作为10位序列号的模8版本，并且不需要出现中断。在相反的情况下，如果接收器始终保持10位序列号（且无重大滑动
of the sequence number have occurred), no discontinuity will result, although this cannot be guaranteed in the presence of errors. (Discontinuity, in this context, means that a receiver has to resynchronize sequence numbers by discarding fragments until a fragment with R=0 has been seen.)
虽然在存在错误的情况下无法保证这一点，但不会导致不连续。（在这种情况下，不连续性意味着接收器必须通过丢弃片段重新同步序列号，直到看到R=0的片段。）
This section defines how fragments with compact fragment headers are mapped into real-time frames. This format has been designed to retain the overall HDLC based format of frames, so that existing synchronous HDLC chips and async to sync converters can be used on the link. Note that if the design could be optimized for async only operation, more design alternatives would be available [4]; with the advent of V.80 style modems, asynchronous communications is likely to decrease in importance, though.
本节定义了如何将具有紧凑片段头的片段映射到实时帧中。该格式旨在保留基于HDLC的整体帧格式，以便在链路上使用现有的同步HDLC芯片和异步到同步转换器。请注意，如果设计可以针对仅异步操作进行优化，则会有更多的设计备选方案[4]；然而，随着V.80型调制解调器的出现，异步通信的重要性可能会降低。
The compact fragment format provides a compact rendition of the PPP multilink header with classes and a reduced sequence number space. However, it does not encode the E-bit of the PPP multilink header, which indicates whether the fragment at hand is the last fragment of a packet.
紧凑片段格式提供了PPP多链接头的紧凑格式副本，其中包含类和减少的序列号空间。但是，它不会对PPP多链路头的E位进行编码，这表明手头的片段是否是数据包的最后一个片段。
For a solution where packets can be suspended at any point in time, the E-bit needs to be encoded near the end of each fragment. The real-time frame format, to ensure maximum compatibility with type 2 receivers, encodes the E-bit in the following way: Any normal frame ending also ends the current fragment with E implicitly set to one. This ensures that packets that are ready for delivery to the upper layers immediately trigger a receive interrupt even at type-2 receivers.
对于可以在任何时间点暂停数据包的解决方案，需要在每个片段的末尾附近对E位进行编码。实时帧格式，为了确保与类型2接收机的最大兼容性，以以下方式对E位进行编码：任何正常帧结尾也以E隐式设置为1的当前片段结尾。这确保准备好传送到上层的数据包立即触发接收中断，即使在2型接收机上也是如此。
Fragments of packets that are to be suspended are terminated within the HDLC frame by a special "fragment suspend escape" byte (FSE). The overall structure of the HDLC frame does not change; the detection and handling of FSE bytes is done at a layer above HDLC framing.
要挂起的数据包片段在HDLC帧内通过一个特殊的“片段挂起转义”字节（FSE）终止。HDLC帧的整体结构没有改变；FSE字节的检测和处理在HDLC帧之上的一层完成。
The suspend/resume format with FSE detection is an alternative to address/control field compression (ACFC, LCP option 8). It does not apply to frames that start with 0xFF, the standard PPP-in-HDLC address field; these frames are handled as defined in [6] and [7]. (This provision ensures that attempts to renegotiate LCP do not cause ambiguities.)
带有FSE检测的挂起/恢复格式是地址/控制字段压缩（ACFC、LCP选项8）的替代方案。它不适用于以0xFF（HDLC地址字段中的标准PPP）开头的帧；这些帧按照[6]和[7]中的定义进行处理。（该条款确保重新协商LCP的尝试不会造成歧义。）
For frames that do not start with 0xFF, suspend/resume processing performs a scan of every HDLC frame received. The FCS of the HDLC frame is checked and stripped. Compact fragment format headers (both basic and extended) are handled without further FSE processing. (Note that, as the FSE byte was chosen such that it never occurs in compact fragment format headers, this does not require any specific code.)
对于不以0xFF开头的帧，挂起/恢复处理对接收到的每个HDLC帧执行扫描。检查并剥离HDLC帧的FCS。压缩片段格式头（基本和扩展）不需要进一步的FSE处理。（注意，由于选择了FSE字节，因此它不会出现在紧凑片段格式的头中，因此不需要任何特定代码。）
Within the remaining bytes of the HDLC frame ("data part"), an FSE byte is used to indicate the end of the current fragment, with an E bit implicitly cleared. All fragments up to the last FSE are considered suspended (E = 0); the final fragment is terminated (E = 1), or, if it is empty, ignored (i.e., the data part of an HDLC frame can end in an FSE to indicate that the last fragment has E = 0).
在HDLC帧（“数据部分”）的剩余字节中，FSE字节用于指示当前片段的结束，隐式清除E位。直至最后一次FSE的所有碎片均被视为暂停（E=0）；最后一个片段被终止（E=1），或者，如果它是空的，则被忽略（即，HDLC帧的数据部分可以在FSE中结束，以指示最后一个片段具有E=0）。
Each fragment begins with a normal header, so the structure of a frame could be:
每个片段都以一个普通标题开头，因此帧的结构可以是：
Figure 2: Example frame with FSE delimiter
图2：带有FSE分隔符的示例帧
0 1 2 3 4 5 6 7
+---+---+---+---+---+---+---+---+
| R | sequence | class | 1 |
+---+---+---+---+---+---+---+---+
| data |
: :
+---+---+---+---+---+---+---+---+
+ FSE + previous fragment implicitly E = 0
+---+---+---+---+---+---+---+---+
| R | sequence | class | 1 |
+---+---+---+---+---+---+---+---+
| data |
: :
+---+---+---+---+---+---+---+---+
| Frame | previous fragment implicitly E = 1
| CRC |
+---+---+---+---+---+---+---+---+
0 1 2 3 4 5 6 7
+---+---+---+---+---+---+---+---+
| R | sequence | class | 1 |
+---+---+---+---+---+---+---+---+
| data |
: :
+---+---+---+---+---+---+---+---+
+ FSE + previous fragment implicitly E = 0
+---+---+---+---+---+---+---+---+
| R | sequence | class | 1 |
+---+---+---+---+---+---+---+---+
| data |
: :
+---+---+---+---+---+---+---+---+
| Frame | previous fragment implicitly E = 1
| CRC |
+---+---+---+---+---+---+---+---+
The value chosen for FSE is 0xDE (this is a relatively unlikely byte to occur in today's data streams, it does not trigger octet stuffing and triggers bit stuffing only for 1/8 of the possible preceding bytes).
为FSE选择的值为0xDE（这是当今数据流中不太可能出现的字节，它不会触发八位字节填充，并且只会触发前面可能字节的1/8的位填充）。
The remaining problem is that of data transparency. In the scheme described so far, an FSE is always followed by a compact fragment header. In these headers, the combination of a class field set to 7
剩下的问题是数据的透明度。在目前描述的方案中，FSE后面总是紧跟着一个紧凑的片段头。在这些标头中，类字段的组合设置为7
with R=1 is reserved. Data transparency is achieved by making the occurrence of an FSE byte followed by one of 0x8F, 0x9F, ... to 0xFF special.
保留R=1的值。通过使FSE字节后跟0x8F、0x9F、。。。到0xFF特价。
Figure 3: Data transparency with FSE bytes present
图3：存在FSE字节时的数据透明度
0 1 2 3 4 5 6 7
+---+---+---+---+---+---+---+---+
| R | sequence | class | 1 |
+---+---+---+---+---+---+---+---+
| data |
: :
+---+---+---+---+---+---+---+---+
+ FSE + fragment NOT terminated
+---+---+---+---+---+---+---+---+
| R | S | T | U | 1 | 1 | 1 | 1 | R always is 1
+---+---+---+---+---+---+---+---+
| data | fragment continues
: :
0 1 2 3 4 5 6 7
+---+---+---+---+---+---+---+---+
| R | sequence | class | 1 |
+---+---+---+---+---+---+---+---+
| data |
: :
+---+---+---+---+---+---+---+---+
+ FSE + fragment NOT terminated
+---+---+---+---+---+---+---+---+
| R | S | T | U | 1 | 1 | 1 | 1 | R always is 1
+---+---+---+---+---+---+---+---+
| data | fragment continues
: :
In a combination of FSE/0xnF (where n is the first four-bit field in the second byte, RSTU in Figure 3), the n field gives a sequence of four bits indicating where in the received data stream FSE bytes, which cannot simply be transmitted in the data stream, are to be added by the receiver:
在FSE/0xnF的组合中（其中n是第二个字节中的第一个四位字段，图3中的RSTU），n字段给出一个四位序列，指示接收到的数据流中的何处FSE字节（不能简单地在数据流中传输）将由接收器添加：
0x8F: insert one FSE, back to data 0x9F: insert one FSE, copy two data bytes, insert one FSE, back to data 0xAF: insert one FSE, copy one data byte, insert one FSE, back to data 0xBF: insert one FSE, copy one data byte, insert two FSE bytes, back to data 0xCF: insert two FSE bytes, back to data 0xDF: insert two FSE bytes, copy one data byte, insert one FSE, back to data 0xEF: insert three FSE bytes, back to data 0xFF: insert four FSE bytes, back to data
0x8F：插入一个FSE，返回数据0x9F：插入一个FSE，复制两个数据字节，插入一个FSE，返回数据0xAF：插入一个FSE，复制一个数据字节，插入一个FSE，返回数据0xBF：插入一个FSE，复制一个数据字节，插入两个FSE字节，返回数据0xCF：插入两个FSE字节，返回数据0xDF：插入两个FSE字节，复制一个数据字节，插入一个FSE，返回数据0xEF：插入三个FSE字节，返回数据0xFF：插入四个FSE字节，返回数据
The data bytes following the FSE/0xnF combinations and corresponding to the zero bits in the N field may not be FSE bytes.
在FSE/0xnF组合之后并与N字段中的零位相对应的数据字节可能不是FSE字节。
This scheme limits the worst case expansion factor by FSE processing to about 25 %. Also, it is designed such that a single data stream can either trigger worst-case expansion by octet stuffing (or by bit stuffing) or worst-case FSE processing, but never both. Figure 4 illustrates the scheme in a few examples; FSE/0xnF pairs are written in lower case.
该方案将FSE处理的最坏情况扩展因子限制在25%左右。此外，它的设计使得单个数据流可以通过八位字节填充（或位填充）或最坏情况下的FSE处理触发最坏情况下的扩展，但决不能同时触发二者。图4以几个例子说明了该方案；FSE/0xnF对以小写形式写入。
Figure 4: Data transparency examples
图4：数据透明度示例
Data stream FSE-stuffed stream
数据流
DD DE DF E0 DD de 8f DF E0 01 DE 02 DE 03 01 de af 02 03 DE DA DE DE DB de bf DA DB DE DE DE DE DE DA de ff de 8f DA
DF E0 DD DE 8f DF E0 01 DE 02 DE 03 DE af 02 03 DE DE DE DE DB DE DE DE DE DE DE DE DE DE DE DE DE DE ff DE 8f DA
In summary, the real-time frame format is a HDLC-like frame delimited by flags and containing a final FCS as defined in [7], but without address and control fields, containing as data a sequence of FSE-stuffed fragments in compact fragment format, delimited by FSE bytes. As a special case, the final FSE may occur as the last byte of the data content (i.e. immediately before the FCS bytes) of the HDLC-like frame, to indicate that the last fragment in the frame is suspended and no final fragment is in the frame (e.g., because the desirable maximum size of the frame has been reached).
总之，实时帧格式是一种类似HDLC的帧，由标志分隔，包含[7]中定义的最终FCS，但没有地址和控制字段，包含一系列紧凑片段格式的FSE填充片段作为数据，由FSE字节分隔。作为一种特殊情况，最终FSE可能作为类似HDLC的帧的数据内容的最后一个字节（即，在FCS字节之前）出现，以指示帧中的最后一个片段被挂起，并且帧中没有最终片段（例如，因为已达到帧的期望最大大小）。
The LCP parameter MRU defines the maximum size of the packets sent on the link. Async-to-sync converters that are monitoring the LCP negotiations on the link may interpret the MRU value as the maximum HDLC frame size to be expected.
LCP参数MRU定义链路上发送的数据包的最大大小。监控链路上LCP协商的异步到同步转换器可能会将MRU值解释为预期的最大HDLC帧大小。
Implementations of this specification should preferably negotiate a sufficiently large MRU to cover the worst-case 25 % increase in frame size plus the increase caused by suspended fragments. If that is not possible, the HDLC frame size should be limited by monitoring the HDLC frame sizes and possibly suspending the current fragment by sending an FSE with an empty final fragment (FSE immediately followed by the end of the information field, i.e. by CRC bytes and a flag) to be able to continue in a new HDLC frame. This strategy also helps minimizing the impact of lengthening the HDLC frame on the safety of the 16-bit FCS at the end of the HDLC frame.
本规范的实现最好协商一个足够大的MRU，以覆盖最坏情况下帧大小增加25%加上由挂起的片段引起的增加。如果不可能，则应通过监视HDLC帧大小并可能通过发送带有空最终片段（紧跟在信息字段末尾的FSE，即CRC字节和标志）的FSE来暂停当前片段来限制HDLC帧大小，以便能够在新HDLC帧中继续。该策略还有助于将HDLC帧延长对HDLC帧末端16位FCS安全性的影响降至最低。
The simplest way to add real-time framing to an implementation may be to perform HDLC processing as usual and then, on the result, to perform FSE processing. A more advanced implementation may want to combine the two levels of escape character processing. Note, however, that FSE processing needs to wait until two bytes from the HDLC frame are available and followed by a third to ensure that the bytes are not the final HDLC FCS bytes, which are not subject to FSE
向实现添加实时帧的最简单方法可能是像往常一样执行HDLC处理，然后根据结果执行FSE处理。更高级的实现可能需要将转义字符处理的两个级别结合起来。但是，请注意，FSE处理需要等待HDLC帧中的两个字节可用，然后是第三个字节，以确保这些字节不是最终的HDLC FCS字节，不受FSE的约束
processing. I.e., on the reception of normal data byte, look for an FSE in the second-to-previous byte, and, on the reception of a frame-end, look for an FSE as the last data byte.
处理。即，在接收正常数据字节时，在第二个字节到前一个字节中查找FSE，在接收帧结束时，查找FSE作为最后一个数据字节。
The following options are already defined by MP [2]:
MP[2]已经定义了以下选项：
o Multilink Maximum Received Reconstructed Unit
o 多链路最大接收重构单元
o Multilink Short Sequence Number Header Format
o 多链路短序列号标头格式
o Endpoint Discriminator
o 端点鉴别器
The following options are already defined by MCML [5]:
MCML[5]已经定义了以下选项：
o Multilink Header Format
o 多链接头格式
o Prefix Elision
o 前缀省略
This document defines two new code points for the Multilink Header Format option.
本文档为“多行标题格式”选项定义了两个新的代码点。
The multilink header format option is defined in [5]. A summary of the Multilink Header Format Option format is shown below. The fields are transmitted from left to right.
多链接标题格式选项在[5]中定义。多链接标题格式选项格式的摘要如下所示。字段从左向右传输。
Figure 5: Multilink header format option
图5：多链接标题格式选项
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 27 | Length = 4 | Code | # Susp Clses |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 27 | Length = 4 | Code | # Susp Clses |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
As defined in [5], this LCP option advises the peer that the implementation wishes to receive fragments with a format given by the code number, with the maximum number of suspendable classes (see below) given. This specification defines two additional values for Code, in addition to those defined in [5]:
如[5]中所定义的，此LCP选项通知对等方，实现希望接收代码编号给定格式的片段，并给出最大可挂起类数（见下文）。除了[5]中定义的值外，本规范还为代码定义了两个附加值：
- Code = 11: basic and extended compact real-time fragment format with classes, in FSE-encoded HDLC frame
- Code=11：基本和扩展的紧凑型实时片段格式，带有类，采用FSE编码的HDLC帧
- Code = 15: basic compact real-time fragment format with classes, in FSE-encoded HDLC frame
- Code=15：基本压缩实时片段格式，带类，采用FSE编码的HDLC帧
An implementation MUST NOT request a combination of both LCP Address-and-Control-Field-Compression (ACFC) and the code values 11 or 15 for this option.
实现不得同时请求LCP地址和控制字段压缩（ACFC）以及此选项的代码值11或15。
The number of suspendable classes negotiated for the compact real-time fragment format only limits the use of class numbers that allow suspending. As class numbers of 7 and higher do not require additional reassembly space, they are not subject to the class number limit negotiated.
为紧凑实时片段格式协商的可挂起类的数量仅限制允许挂起的类编号的使用。由于7级及以上的级别不需要额外的重新组装空间，因此不受协商的级别限制。
Operation of this protocol is believed to be no more and no less secure than operation of the PPP multilink protocol [2]. Operation with a small sequence number range increases the likelihood that fragments from different packets could be incorrectly reassembled into one packet. While most such packets will be discarded by the receiver because of higher-layer checksum failures or other inconsistencies, there is an increase in likelihood that contents of packets destined for one host could be delivered to another host. Links that carry packets where this raises security considerations SHOULD use the extended sequence number range for multi-fragment packets.
该协议的操作被认为不比PPP多链路协议的操作更安全[2]。使用小序列号范围的操作会增加不同数据包的片段被错误地重新组合到一个数据包中的可能性。虽然由于高层校验和失败或其他不一致性，大多数此类数据包将被接收器丢弃，但发送到一个主机的数据包的内容可能会被发送到另一个主机的可能性增加。对于携带数据包的链路，如果这会引起安全考虑，则应使用扩展序列号范围来表示多片段数据包。
[1] Bormann, C., "Providing Integrated Services over Low-bitrate Links", RFC 2689, September 1999.
[1] Bormann，C.，“通过低比特率链路提供综合服务”，RFC 2689，1999年9月。
[2] Sklower, K., Lloyd, B., McGregor, G., Carr, D. and T. Coradetti, "The PPP Multilink Protocol (MP)", RFC 1990, August 1996.
[2] K.Sklower、Lloyd、B.McGregor、G.Carr、D.和T.Coradetti，“PPP多链路协议（MP）”，RFC 1990，1996年8月。
[3] Simpson, W., "PPP in Frame Relay", RFC 1973, June 1996.
[3] 辛普森，W.，“PPP帧内中继”，RFC 1973，1996年6月。
[4] Andrades, R. and F. Burg, "QOSPPP Framing Extensions to PPP", Work in Progress.
[4] Andrades，R.和F.Burg，“PPP的QOSPP帧扩展”，正在进行中。
[5] Bormann, C., "The Multi-Class Extension to Multi-Link PPP", RFC 2686, September 1999.
[5] Bormann，C.，“多链路PPP的多类扩展”，RFC 2686，1999年9月。
[6] Simpson, W., Editor, "The Point-to-Point Protocol (PPP)", STD 51, RFC 1661, July 1994.
[6] 辛普森，W.，编辑，“点对点协议（PPP）”，STD 51，RFC 1661994年7月。
[7] Simpson, W., Editor, "PPP in HDLC-like Framing", STD 51, RFC 1662, July 1994.
[7] 辛普森，W.，编辑，“HDLC类框架中的PPP”，STD 51，RFC 16621994年7月。
[8] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[8] Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年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
致谢
The participants in a lunch BOF at the Montreal IETF 1996 gave useful input on the design tradeoffs in various environments. Richard Andrades, Fred Burg, and Murali Aravamudan insisted that there should be a suspend/resume solution in addition to the pre-fragmenting one defined in [5]. The members of the ISSLL subgroup on low bitrate links (ISSLOW) have helped in coming up with a set of requirements that shaped this solution.
1996年蒙特利尔IETF午餐BOF的参与者就各种环境中的设计权衡提供了有用的信息。Richard Andrades、Fred Burg和Murali Aravamudan坚持认为，除了[5]中定义的预碎片化解决方案外，还应该有一个暂停/恢复解决方案。低比特率链路（ISSLOW）ISSLL子组的成员帮助提出了一组形成此解决方案的要求。
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编辑功能的资金目前由互联网协会提供。