Network Working Group C. Bormann
Request for Comments: 2686 Universitaet Bremen TZI
Category: Standards Track September 1999
Network Working Group C. Bormann
Request for Comments: 2686 Universitaet Bremen TZI
Category: Standards Track September 1999
The Multi-Class Extension to Multi-Link PPP
多链路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 fragment-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 provide a small number of extensions to add functionality and reduce the overhead.
本文档针对体系结构的实时封装格式部分提出了面向片段的解决方案。一般的方法是从PPP多链路分段协议[2]开始，并提供少量扩展以添加功能并减少开销。
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 fragment-oriented solution for the real-time encapsulation format part of the architecture, i.e. for the queues-of-fragments type sender [1]. As described in more detail in the architecture document, a real-time encapsulation format is
本文档为体系结构的实时封装格式部分定义了面向片段的解决方案，即针对片段类型发送者的队列[1]。如架构（architecture）文档中更详细地描述的，实时封装格式是
required as, e.g., 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. The PPP extensions defined in this document allow a sender to fragment the packets of various priorities into multiple classes of fragments, allowing high-priority packets to be sent between fragments of lower priorities.
例如，28.8 kbit/s调制解调器链路上的1500字节数据包使该链路在大约400 ms的时间内无法传输实时信息。这增加了最坏情况下的延迟，导致实时应用程序在往返延迟至少为一秒的情况下运行，这对于实时对话来说是不可接受的。本文档中定义的PPP扩展允许发送方将不同优先级的数据包分割成多个片段类，从而允许在较低优先级的片段之间发送高优先级数据包。
A companion document based on these extensions [5] defines a suspend/resume-oriented solution for those cases where the best possible delay is required and the senders are of type 1 [1].
基于这些扩展的附带文档[5]定义了一个面向暂停/恢复的解决方案，用于需要尽可能好的延迟且发送方为类型1[1]的情况。
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 main design goal for the components of 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, every attempt should obviously be undertaken to maximize the bandwidth actually available to media data; overheads must be minimized.
此外，显然应尽一切努力最大化媒体数据的实际可用带宽；必须尽量减少管理费用。
The solution should not place unnecessary burdens on the non-real-time flows. In particular, the usual MTU should be available to these flows.
解决方案不应给非实时流带来不必要的负担。特别是，通常的MTU应可用于这些流。
The most general approach would provide the ability to suspend any packet (real-time or not) for a more urgent real-time packet, up to an infinite number of levels of nesting. On the other hand, it is likely that there would rarely be a requirement for a real-time packet to suspend another real-time packet that is not at least about twice as long. Typically, the largest packet size to be expected on a PPP link is the default MTU of 1500 bytes. The smallest high-priority packets are likely to have on the order of 22 bytes (compressed RTP/G.723.1 packets). In the 1:72 range of packet sizes to be expected, this translates to a maximum requirement of about
最通用的方法是为更紧急的实时数据包提供挂起任何数据包（实时或非实时）的能力，最多可挂起无限多个嵌套级别。另一方面，可能很少需要实时数据包挂起另一个长度至少不超过两倍的实时数据包。通常，PPP链路上预期的最大数据包大小是1500字节的默认MTU。最小的高优先级数据包可能有22个字节（压缩的RTP/G.723.1数据包）。在预期的数据包大小为1:72的范围内，这意味着最大需求约为
eight levels of suspension (including one level where long real-time packets suspend long non-real-time packets). On 28.8kbit/s modems, there seems to be a practical requirement for at least two levels of suspension (i.e., audio suspends any longer packet including video, video suspends other very long packets).
八级暂停（包括长实时数据包暂停长非实时数据包的一级）。在28.8kbit/s调制解调器上，似乎实际需要至少两级暂停（即，音频暂停任何更长的数据包，包括视频，视频暂停其他很长的数据包）。
On an architectural level, there are several additional requirements for the fragmentation scheme:
在体系结构级别上，碎片方案还有几个附加要求：
a) The scheme must be predictable enough that admission control can make decisions based on its characteristics. As is argued in [1], this will often only be the case when additional hints about the characteristics of the flow itself are available (application hints).
a) 该方案必须具有足够的可预测性，以使接纳控制能够根据其特点做出决策。正如[1]中所述，这通常仅在关于流本身特征的附加提示可用时（应用程序提示）才会出现。
b) The scheme must be robust against errors, at least with the same level of error detection as PPP.
b) 该方案必须对错误具有鲁棒性，至少具有与PPP相同的错误检测水平。
c) The scheme must in general cooperate nicely with PPP. In particular, it should be as compatible to existing PPP standards as possible. On a link that (based on PPP negotiation) makes use of the scheme, it should always be possible to fall back to standard LCP (PPP Link Control Protocol [6, 7]) without ambiguity.
c) 总体而言，该计划必须与PPP密切合作。特别是，它应尽可能与现有PPP标准兼容。在（基于PPP协商）使用该方案的链路上，应始终能够返回到标准LCP（PPP链路控制协议[6,7]），而不会产生歧义。
d) The scheme must work well with existing chips and router systems. (See [1] for a more extensive discussion of implementation models.) For synchronous links this means using HDLC framing; with much existing hardware, it is also hard to switch off the HDLC per-frame CRC. For asynchronous links, there is much more freedom in design; on the other hand, a design that treats them much different from synchronous links would lose a number of desirable properties of PPP.
d) 该方案必须与现有芯片和路由器系统配合良好。（有关实现模型的更广泛讨论，请参见[1]）对于同步链路，这意味着使用HDLC帧；对于许多现有硬件，也很难关闭HDLC每帧CRC。对于异步链路，在设计上有更多的自由度；另一方面，与同步链路有很大区别的设计将失去PPP的许多理想特性。
e) The scheme must be future proof. In particular, the emergence of V.80 based modems may significantly change the way PPP is used with modems.
e) 该计划必须是经得起未来考验的。特别是，基于V.80的调制解调器的出现可能会极大地改变PPP与调制解调器一起使用的方式。
This document does not address additional requirements that may be relevant in conjunction with Frame Relay; however, there seems to be little problem in applying the principles of this document to "PPP in Frame Relay" [3].
本文件不涉及与帧中继相关的附加要求；然而，将本文件的原则应用于“PPP帧内中继”似乎没有什么问题[3]。
Transmitting only part of a packet to allow higher-priority traffic to intervene and resuming its transmission later on is a kind of fragmentation. The existing PPP Multilink Protocol (MP, [2]) provides for sequence numbering and begin/end bits, allowing packets to be split into fragments (Figure 1).
仅传输数据包的一部分以允许更高优先级的通信进行干预，并在稍后恢复其传输是一种碎片。现有的PPP多链路协议（MP，[2]）提供序列编号和开始/结束位，允许将数据包拆分为片段（图1）。
Figure 1: Multilink Short Sequence Number Fragment Format [2]
图1：多链路短序列号片段格式[2]
+---------------+---------------+
PPP Header: | Address 0xff | Control 0x03 |
+---------------+---------------+
| PID(H) 0x00 | PID(L) 0x3d |
+-+-+-+-+-------+---------------+
MP Header: |B|E|0|0| sequence number |
+-+-+-+-+-------+---------------+
| fragment data |
| . |
| . |
| . |
+---------------+---------------+
PPP FCS: | FCS |
+---------------+---------------+
+---------------+---------------+
PPP Header: | Address 0xff | Control 0x03 |
+---------------+---------------+
| PID(H) 0x00 | PID(L) 0x3d |
+-+-+-+-+-------+---------------+
MP Header: |B|E|0|0| sequence number |
+-+-+-+-+-------+---------------+
| fragment data |
| . |
| . |
| . |
+---------------+---------------+
PPP FCS: | FCS |
+---------------+---------------+
(Note that the address, control, and most significant PID bytes are often negotiated to be compressed away.)
（请注意，地址、控件和最重要的PID字节通常经过协商以压缩掉。）
MP's monotonically increasing sequence numbering (contiguous numbers are needed for all fragments of a packet) does not allow suspension of the sending of a sequence of fragments of one packet in order to send another packet. It is, however, possible to send intervening packets that are not encapsulated in multilink headers; thus, MP supports two levels of priority.
MP的单调递增序列编号（一个数据包的所有片段都需要连续编号）不允许为了发送另一个数据包而暂停发送一个数据包的片段序列。然而，可以发送未封装在多链路报头中的中间包；因此，MP支持两级优先级。
The multilink-as-is approach can be built using existing standards; multilink capability is now widely deployed and only the sending side needs to be aware that they are using this for giving priority to real-time packets.
可以使用现有标准构建多链路原样方法；现在已经广泛部署了多链路功能，只有发送端需要知道他们正在使用它来优先处理实时数据包。
Multilink-as-is is not the complete solution for a number of reasons. First, because of the single monotonically increasing serial number, there is only one level of suspension: "Big" packets that are sent via multilink can be suspended by "small" packets sent outside of multilink; the latter are not fragmentable (and therefore, the content of one packet cannot be sent in parallel on multiple links;
由于许多原因，Multilink as is不是完整的解决方案。首先，由于单一的单调递增序列号，因此只有一个暂停级别：通过多链路发送的“大”数据包可以被多链路外部发送的“小”数据包暂停；后者是不可分割的（因此，一个数据包的内容不能在多个链路上并行发送；
if the packets are sent in rounds on multiple links, the order they are processed at the receiver may differ from the order they were sent).
如果数据包在多个链路上以轮次发送，则它们在接收器处的处理顺序可能不同于它们的发送顺序）。
A problem not solved by this specification is that the multi-link header is relatively large; as delay bounds become small (for queues-of-fragments type implementations) the overhead may become significant.
本规范未解决的一个问题是多链路报头相对较大；随着延迟边界变小（对于片段类型实现的队列），开销可能会变得很大。
The obvious approach to providing more than one level of suspension with PPP Multilink is to run Multilink multiple times over one link. Multilink as it is defined provides no way for more than one instance to be active. Fortunately, a number of bits are unused in the Multilink header: two bits in the short sequence number format (as can be seen in Figure 1), six in the long sequence number format.
使用PPP Multilink提供多个级别的暂停的明显方法是在一条链路上多次运行Multilink。定义的Multilink不能使多个实例处于活动状态。幸运的是，在Multilink头中有许多位是未使用的：两位是短序列号格式（如图1所示），六位是长序列号格式。
This document defines (some of the) previously unused bits as a class number:
本文档将（部分）以前未使用的位定义为类号：
Figure 2: Short Sequence Number Fragment Format With Classes
图2：带有类的短序列号片段格式
+---------------+---------------+
PPP Header: | Address 0xff | Control 0x03 |
+---------------+---------------+
| PID(H) 0x00 | PID(L) 0x3d |
+-+-+-+-+-------+---------------+
MP Header: |B|E|cls| sequence number |
+-+-+-+-+-------+---------------+
| fragment data |
| . |
| . |
| . |
+---------------+---------------+
PPP FCS: | FCS |
+---------------+---------------+
+---------------+---------------+
PPP Header: | Address 0xff | Control 0x03 |
+---------------+---------------+
| PID(H) 0x00 | PID(L) 0x3d |
+-+-+-+-+-------+---------------+
MP Header: |B|E|cls| sequence number |
+-+-+-+-+-------+---------------+
| fragment data |
| . |
| . |
| . |
+---------------+---------------+
PPP FCS: | FCS |
+---------------+---------------+
Each class runs a separate copy of the mechanism defined in [2], i.e. uses a separate sequence number space and reassembly buffer.
每个类运行[2]中定义的机制的单独副本，即使用单独的序列号空间和重组缓冲区。
Similarly, for the long sequence number format:
同样，对于长序列号格式：
Figure 3: Long Sequence Number Fragment Format With Classes
图3：带有类的长序列号片段格式
+---------------+---------------+
PPP Header: | Address 0xff | Control 0x03 |
+---------------+---------------+
| PID(H) 0x00 | PID(L) 0x3d |
+-+-+-+-+-+-+-+-+---------------+
MP Header: |B|E| class |0|0|sequence number|
+-+-+-+-+-+-+-+-+---------------+
| sequence number (L) |
+---------------+---------------+
| fragment data |
| . |
| . |
| . |
+---------------+---------------+
PPP FCS: | FCS |
+---------------+---------------+
+---------------+---------------+
PPP Header: | Address 0xff | Control 0x03 |
+---------------+---------------+
| PID(H) 0x00 | PID(L) 0x3d |
+-+-+-+-+-+-+-+-+---------------+
MP Header: |B|E| class |0|0|sequence number|
+-+-+-+-+-+-+-+-+---------------+
| sequence number (L) |
+---------------+---------------+
| fragment data |
| . |
| . |
| . |
+---------------+---------------+
PPP FCS: | FCS |
+---------------+---------------+
Together with the ability to send packets without a multilink header, this provides four levels of suspension with 12-bit headers (probably sufficient for many practical applications) and sixteen levels with 24-bit headers (only four of the six free bits are used in this case -- based on the rationale given above, sixteen levels should generally be more than sufficient).
再加上在不使用多链路报头的情况下发送数据包的能力，这提供了四个级别的暂停，12位报头（可能足以满足许多实际应用）和16个级别的24位报头（在这种情况下，仅使用六个空闲位中的四个——基于上述原理，十六个级别通常应该足够了）。
For some applications, all packets of a certain class will have a common protocol identifier (or even more than one common prefix byte). In this case, the following optimization is possible: the class number can be associated with a prefix of bytes that are removed from each packet before transmission and that are implicitly prepended to the reassembled packet after reception.
对于某些应用程序，某个类的所有数据包都将有一个公共协议标识符（甚至不止一个公共前缀字节）。在这种情况下，以下优化是可能的：类号可以与字节前缀相关联，这些字节在传输之前从每个分组中移除，并且在接收之后隐式地预先添加到重新组装的分组中。
Note that if only some of the packets to be transmitted at a certain level of priority have the common prefix, it may still be possible to utilize this method by allocating two class numbers and only associating one of them with the prefix. (This is the reason why four of the unused bits in the long sequence number format have been allocated to the class number instead of the three that generally should suffice.)
注意，如果要以特定优先级发送的分组中只有一些具有公共前缀，则仍然可以通过分配两个类号并仅将其中一个与前缀相关联来利用该方法。（这就是为什么长序列号格式中的四个未使用位被分配给了类号，而不是通常应该足够的三个。）
Prefix elision is not a replacement for header compression or data compression: it allows implementations to compress away prefixes that often are not reachable by header or data compression methods.
前缀省略并不能替代头压缩或数据压缩：它允许实现压缩掉头或数据压缩方法通常无法访问的前缀。
The following PPP LCP options are already defined by MP:
MP已经定义了以下PPP LCP选项：
o Multilink Maximum Received Reconstructed Unit
o 多链路最大接收重构单元
o Multilink Short Sequence Number Header Format
o 多链路短序列号标头格式
o Endpoint Discriminator
o 端点鉴别器
This document defines two new LCP options:
本文件定义了两个新的LCP选项：
o Multilink Header Format
o 多链接头格式
o Prefix Elision
o 前缀省略
A summary of the Multilink Header Format Option format is shown below. The fields are transmitted from left to right.
多链接标题格式选项格式的摘要如下所示。字段从左向右传输。
Figure 4:
图4：
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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.
此LCP选项通知对等方，实现希望接收由代码号给定格式的片段，并给出最大可挂起类数（见下文）。
When this option is negotiated, the accepting implementation MUST either transmit all subsequent multilink packets on all links of the bundle with the multilink header format given or Configure-Nak or Configure-Reject the option. (Note that an implementation MAY continue to send packets outside of multilink in any case.) If this option is offered on a link which is intended to join an existing bundle, a system MUST offer the same multilink header format option value previously negotiated for the bundle, or none if none was negotiated previously.
协商此选项时，接受实现必须使用给定的多链路头格式在捆绑包的所有链路上传输所有后续多链路数据包，或者配置Nak或配置拒绝该选项。（请注意，在任何情况下，实现都可以继续在多链路之外发送数据包。）如果此选项是在打算加入现有捆绑包的链路上提供的，则系统必须提供与先前为捆绑包协商的多链路头格式选项值相同的值，或者如果之前没有协商，则必须提供“无”。
The values defined in this document for the use of this option are:
本文件中定义的使用此选项的值为：
- Code = 2: long sequence number fragment format with classes
- 代码=2：带类的长序列号片段格式
- Code = 6: short sequence number fragment format with classes
- 代码=6：带类的短序列号片段格式
The Multilink Header Format option MUST NOT occur more than once in a Configure-Request or Configure-Ack, and, if it is present, the Short Sequence Number Header Format option ([2]) MUST NOT also be present. If no instance of this option or the Short Sequence Number Header Format option is present, but an MRRU option [2] is present, then by default, long sequence number multilink headers with class 0 only are used; this is equivalent to code equals 2 and number of suspendable classes equals 1. An instance of the Short Sequence Number Header Format Option is equivalent to an instance of this option with code equals 6 and number of suspendable classes equal to 1.
多链路标头格式选项在配置请求或配置确认中不得出现多次，如果存在，则短序列号标头格式选项（[2]）也不得出现。如果不存在此选项或短序列号标题格式选项的实例，但存在MRRU选项[2]，则默认情况下，仅使用类别为0的长序列号多行标题；这相当于代码等于2，可挂起类的数量等于1。“短序列号标头格式”选项的实例相当于此选项的实例，代码为6，可挂起的类数为1。
The number of suspendable classes bounds the allowable class numbers: only class numbers numerically lower than this limit can be used for suspendable classes. Implementations MAY want to negotiate a number smaller than made possible by the packet format to limit their reassembly buffer space requirements. Implementations SHOULD at least support the value 4 for the short sequence number fragment format, and the value 8 for the long sequence number fragment format, unless configured differently. Bit combinations that would indicate class numbers outside the negotiated range MAY be used for other semantics if negotiated by other means outside the scope of this document (e.g., [6]).
可挂起类的数量限制了允许的类数量：只有数值低于此限制的类数量才能用于可挂起类。实现可能希望协商一个小于数据包格式所允许的数量，以限制其重新组装缓冲区空间需求。除非配置不同，否则实现应至少支持短序列号片段格式的值4，以及长序列号片段格式的值8。如果通过本文件范围之外的其他方式协商（例如，[6]），则表示协商范围之外的类别号的位组合可用于其他语义。
This LCP option advises the peer that, in each of the given classes, the implementation expects to receive only packets with a certain prefix; this prefix is not to be sent as part of the information in the fragment(s) of this class. By default, this common prefix is empty for all classes. When this option is negotiated, the accepting implementation MUST either transmit all subsequent multilink packets of each of the given classes with the given prefix removed from the start of the packet or Configure-Nak or Configure-Reject the option. If none of the formats with classes has been negotiated, class number 0 may be used to indicate a common prefix for all packets sent within multilink fragments.
此LCP选项通知对等方，在每个给定类中，实现只希望接收具有特定前缀的数据包；此前缀不能作为此类片段中信息的一部分发送。默认情况下，对于所有类，此公共前缀为空。协商此选项时，接受实现必须传输每个给定类的所有后续多链路数据包，并从数据包的开头移除给定前缀，或者配置Nak或配置拒绝该选项。如果没有协商任何带有类的格式，则类编号0可用于指示在多链路片段内发送的所有数据包的公共前缀。
Apart from the type and length octets common to all LCP options, the option contains a sequence of zero or more sequences of a single-octet class number, a single-octet length of the prefix for that class, and the octets in that prefix:
除了所有LCP选项共有的八位字节类型和长度外，该选项还包含一个八位字节类编号的零或多个序列、该类前缀的一个八位字节长度以及该前缀中的八位字节：
Figure 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 = 26 | Option Length | Class | Prefix Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Prefix... | Class |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Prefix Length | Prefix...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 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 = 26 | Option Length | Class | Prefix Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Prefix... | Class |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Prefix Length | Prefix...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Prefix Elision option MUST NOT occur more than once in a Configure-Request or Configure-Nak. If this option is offered on a link which is intended to join an existing multilink bundle, a system MUST offer the same prefix elision option value previously negotiated for the bundle, or none if none was negotiated previously.
前缀省略选项在配置请求或配置Nak中不得出现多次。如果此选项是在打算加入现有多链路捆绑包的链接上提供的，则系统必须提供与先前为捆绑包协商的前缀省略选项值相同的前缀省略选项值，或者如果先前未协商前缀省略选项值，则系统必须提供无前缀省略选项值。
IMPLEMENTATION NOTE: as with most PPP options that indicate capabilities of the receiver to the sender, the sense of this option is an indication from the receiver to the sender of the packets concerned. Often, only the senders will have sufficient control over their usage of classes to be able to supply useful values for this option. A receiver willing to accept prefix-elided packets SHOULD request this option with empty content; the sender then can use Configure-Nak to propose the class-to-prefix mapping desired.
实施说明：与大多数向发送方指示接收方能力的PPP选项一样，此选项的含义是从接收方向发送方指示相关数据包。通常，只有发送方能够充分控制类的使用，从而能够为该选项提供有用的值。愿意接受前缀省略的数据包的接收者应使用空内容请求该选项；然后，发送方可以使用configurenak来建议类到所需的前缀映射。
Operation of this protocol is believed to be no more and no less secure than operation of the PPP multilink protocol [2].
该协议的操作被认为不比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., "PPP in a Real-time Oriented HDLC-like Framing", RFC 2687, September 1999.
[5] Bormann，C.“实时定向HDLC样帧中的PPP”，RFC 2687，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
David Oran suggested using PPP Multilink for real-time framing and reminded the author of his earlier attempts of making Multilink more useful for this purpose. The participants in a lunch BOF at the 1996 Montreal IETF gave useful input on the design tradeoffs in various environments. The members of the ISSLL subgroup on low bitrate links (ISSLOW) have helped reducing the large set of options that initial versions of this specification had.
David Oran建议使用PPP Multilink进行实时成帧，并提醒作者，他以前曾尝试使Multilink更有用。1996年蒙特利尔IETF午餐BOF的参与者就各种环境中的设计权衡提供了有用的信息。低比特率链路（ISSLOW）上ISSLL子组的成员帮助减少了本规范初始版本所拥有的大量选项。
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编辑功能的资金目前由互联网协会提供。