Network Working Group R. Pazhyannur
Request for Comments: 3153 I. Ali
Category: Standards Track Motorola
C. Fox
Cisco Systems
August 2001
Network Working Group R. Pazhyannur
Request for Comments: 3153 I. Ali
Category: Standards Track Motorola
C. Fox
Cisco Systems
August 2001
PPP Multiplexing
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 (2001). All Rights Reserved.
版权所有（C）互联网协会（2001年）。版权所有。
Abstract
摘要
This document describes a method to reduce the PPP (Point-to-Point Protocol) framing overhead used to transport small packets over slow links.
本文档描述了一种减少PPP（点对点协议）帧开销的方法，用于在慢速链路上传输小数据包。
The method, PPP Multiplexing, sends multiple PPP encapsulated packets in a single PPP frame. As a result, the PPP overhead per packet is reduced. PPP encapsulation (for example with PPP in HDLC framing) adds several bytes of overhead: a HDLC flag (at least one to separate adjacent packets), the Address (0xFF) and Control (0x03) field bytes, a two byte PPP Protocol ID, and the two byte CRC field. Even with the Address and Control Fields negotiated off and the PPP Protocol ID compressed, each PPP encapsulated frame will include four bytes of overhead. When PPP frames are tunneled, as in L2TP [1], the L2TP overhead per PPP frame is significant.
PPP多路复用方法在单个PPP帧中发送多个PPP封装包。结果，每个分组的PPP开销减少。PPP封装（例如，在HDLC帧中使用PPP）增加了几个字节的开销：HDLC标志（至少一个用于分隔相邻数据包）、地址（0xFF）和控制（0x03）字段字节、两字节PPP协议ID和两字节CRC字段。即使协商关闭了地址和控制字段并压缩了PPP协议ID，每个PPP封装的帧也将包含四个字节的开销。当PPP帧被隧道化时，如L2TP[1]中所述，每个PPP帧的L2TP开销非常大。
The key idea is to concatenate multiple PPP encapsulated frames into a single PPP multiplexed frame by inserting a delimiter before the beginning of each frame. The description of the delimiters is provided in Subsection 1.1. The delimiters are used by the demultiplexor to separate the PPP frames within the multiplexed frame. Each PPP encapsulated frame within the multiplexed frame is called a PPP subframe.
关键思想是通过在每个帧的开头插入分隔符，将多个PPP封装帧连接到单个PPP多路复用帧中。第1.1小节提供了分隔符的说明。分隔符由解复用器用于分离复用帧内的PPP帧。复用帧内的每个PPP封装帧称为PPP子帧。
During the NCP negotiation phase of PPP, a receiver can offer to receive multiplexed frames using the PPP Mux Control Protocol (PPPMuxCP), as described in Section 2. Once PPPMuxCP has been negotiated, the transmitter may choose which PPP frames to multiplex. Frames should not be re-ordered by either the transmitter or receiver regardless of whether they arrive as part of the PPP multiplexed frame or by themselves.
在PPP的NCP协商阶段，接收机可以使用PPP Mux控制协议（PPPMuxCP）提供接收复用帧，如第2节所述。一旦协商了PPPMuxCP，发射机可以选择要复用的PPP帧。无论帧是作为PPP多路复用帧的一部分到达的，还是由帧自身到达的，发射机或接收机都不应重新排序帧。
The scheme proposed is similar to the concatenated framing option [2]. The key differences are that PPP multiplexing is more efficient and that it allows concatenation of variable sized frames. This is unlike concatenated framing which restricts all frames to be of fixed length.
提出的方案类似于级联帧选项[2]。关键区别在于PPP多路复用更有效，并且它允许可变大小帧的级联。这与将所有帧限制为固定长度的串联帧不同。
As with any concatenation scheme, the implementer has to consider the tradeoff between increased delay for multiplexing/demultiplexing and reduced packet overhead as the length of the multiplexed frame increases.
与任何级联方案一样，实现器必须考虑复用/解复用的增加的延迟和复用帧的长度增加时减少的分组开销之间的折衷。
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 [7].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照RFC 2119[7]中所述进行解释。
The format of the complete PPP frame along with multiple subframes for PPP in HDLC-like framing [3] is shown in Figure 1. Note that regardless of the order in which individual bits are transmitted, i.e., LSB first or MSB first, the PFF bit will be seen to be the MSB of a byte that contains both the PFF and the subframe length field.
图1显示了完整PPP帧的格式以及类似HDLC的帧[3]中PPP的多个子帧。请注意，无论单个位的传输顺序如何，即LSB优先或MSB优先，PFF位将被视为包含PFF和子帧长度字段的字节的MSB。
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| +P|L| + + + +P|L| + + + |
| PPP/ +F|X|Len1 + PPP + + +F|X|LenN + PPP + + |
| HDLC +F|T| + Prot. +Info1+ ~ +F|T| + Prot. +InfoN+ CRC |
| Header+ | | + Field1+ + + | | +FieldN + + |
| (2-5) + (1-2 ) + (0-2) + + + (1-2) + (0-2) + + (2) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| +P|L| + + + +P|L| + + + |
| PPP/ +F|X|Len1 + PPP + + +F|X|LenN + PPP + + |
| HDLC +F|T| + Prot. +Info1+ ~ +F|T| + Prot. +InfoN+ CRC |
| Header+ | | + Field1+ + + | | +FieldN + + |
| (2-5) + (1-2 ) + (0-2) + + + (1-2) + (0-2) + + (2) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1. Multiplexing subframes in a PPP frame.
图1。在PPP帧中复用子帧。
PPP Header: The PPP header contains the PPP Protocol Field for a PPP Multiplexed Frame (0x0059). The PPP header compression options (ACFC and PFC) may be negotiated during LCP and could thus affect the format of this header.
PPP头：PPP头包含PPP多路复用帧（0x0059）的PPP协议字段。PPP报头压缩选项（ACFC和PFC）可能在LCP期间协商，因此可能会影响该报头的格式。
Length Field:
长度字段：
The length field consists of three subfields:
长度字段由三个子字段组成：
1. Protocol Field Flag (PFF):
1. 协议字段标志（PFF）：
The PFF refers to the most significant bit of the first byte of each subframe. This one bit field indicates whether the PPP Protocol ID of the subframe follows the subframe length field. For the first subframe, the PFF bit could be set to zero if the PPP protocol ID of the first subframe is equal to the default PID value negotiated in PPPMuxCP. PFF = 1 indicates that the protocol field is present (and follows the length field) for this subframe. PFF = 0 indicates that the protocol field is absent for this subframe. If PFF = 0 then the PPP Protocol ID is the same as that of the preceding subframe with PFF = 1, or it is equal to default PID value of the PPPMuxCP Option for the first subframe. The transmitter is not obligated to remove the PPP Protocol ID for any subframe.
PFF指每个子帧的第一字节的最高有效位。此一位字段指示子帧的PPP协议ID是否遵循子帧长度字段。对于第一个子帧，如果第一个子帧的PPP协议ID等于PPPMuxCP中协商的默认PID值，则PFF位可以设置为零。PFF=1表示此子帧存在协议字段（并在长度字段之后）。PFF=0表示此子帧不存在协议字段。如果PFF=0，则PPP协议ID与PFF=1的前一子帧的相同，或者等于第一个子帧的PPPMuxCP选项的默认PID值。发射机没有义务删除任何子帧的PPP协议ID。
2. Length Extension (LXT)
2. 长度延伸（LXT）
This one bit field indicates whether the length field is one byte or two bytes long. If the LXT bit is set, then the length field is two bytes long (a PFF bit, a length extension bit, and 14 bits of sub-frame length). If the LXT bit is cleared, then the length field is one byte long (a PFF bit, a length extension bit, and 6 bits of sub-frame length).
此一位字段指示长度字段的长度是一个字节还是两个字节。如果设置了LXT位，则长度字段的长度为两个字节（一个PFF位、一个长度扩展位和14位子帧长度）。如果清除LXT位，则长度字段为一个字节长（PFF位、长度扩展位和子帧长度的6位）。
3. Sub-frame Length (LEN):
3. 子帧长度（LEN）：
This is the length of the subframe in bytes not including the length field. However, it does include the PPP Protocol ID if present (i.e., if PFF = 1). If the length of the subframe is less than 64 bytes (less than or equal to 63 bytes), LXT is set to zero and the last six bits of the length field is the subframe length. If the length of the subframe is greater than 63 bytes, LXT is set to one and the last 14 bits of the length field is the length of the subframe. The maximum length of a subframe is 16,383 bytes. PPP packets larger than 16,383 bytes will need to be sent in their own PPP frame. A transmitter is not required to multiplex all frames smaller than 16,383 bytes. It may chose to only multiplex frames smaller than a configurable size into a PPP multiplexed frame.
这是以字节为单位的子帧长度，不包括长度字段。但是，如果存在PPP协议ID（即，如果PFF=1），则它确实包括PPP协议ID。如果子帧的长度小于64字节（小于或等于63字节），则LXT设置为零，长度字段的最后六位为子帧长度。如果子帧的长度大于63字节，则LXT设置为1，长度字段的最后14位为子帧的长度。子帧的最大长度为16383字节。大于16383字节的PPP数据包需要在自己的PPP帧中发送。发射机无需多路传输所有小于16383字节的帧。它可以选择仅将小于可配置大小的帧多路复用到PPP多路复用帧中。
Protocol Field:
协议字段：
This field contains the Protocol Field value for the subframe. This field is optional. If PFF = 1 for a subframe, the protocol field is present in the subframe, otherwise it is inferred at the receiver.
此字段包含子帧的协议字段值。此字段是可选的。如果子帧的PFF＝1，则协议字段存在于子帧中，否则在接收机处推断。
The receiver MUST support Protocol-Field-Compression (PFC) one or two bytes long. The transmitter SHOULD compress PPP Protocol IDs in this field that have an upper byte of zero (i.e., Protocol IDs from 0x21 thru 0xFD). This Protocol Field Compression in each PPP subframe is not related to the negotiation of PFC during LCP negotiation which affects the length of PPP Multiplexed Frame Protocol ID.
接收器必须支持一个或两个字节长的协议字段压缩（PFC）。变送器应压缩此字段中的PPP协议ID，其上限字节为零（即从0x21到0xFD的协议ID）。每个PPP子帧中的协议字段压缩与LCP协商期间的PFC协商无关，这会影响PPP复用帧协议ID的长度。
Information Field:
信息字段：
This field contains the actual packet being encapsulated. Any frame may be included here with the exception of LCP Configure Request, ACK, NAK and Reject frames and PPP Multiplexed frames. If LCP is renegotiated then PPP Multiplexing MUST be disabled until the PPP Mux Control Protocol is negotiated.
此字段包含要封装的实际数据包。除了LCP配置请求、ACK、NAK和Reject帧以及PPP多路复用帧之外，这里可以包括任何帧。如果重新协商LCP，则必须禁用PPP多路复用，直到协商PPP Mux控制协议。
A simple implementation of the transmitter is provided. During the transmission of a multiplexed PPP frame, the transmitter has a state variable, Last_PID, which is used to hold the most recent value of protocol field in a subframe with PFF=1. At the start of the multiplexing process, Last_PID is set equal to the default PID value negotiated in PPPMuxCP. Also, a user configurable parameter, maximum subframe length (MAX_SF_LEN), is used to determine the maximum size of a PPP frame which can be multiplexed. The value of MAX_SF_LEN should be less or equal to the minimum of MRU-2(maximum size of length field) and 16,383 (14 bits).
本发明提供了发射机的简单实现。在多路复用PPP帧的传输期间，发射机具有状态变量Last_PID，其用于保持PFF＝1的子帧中协议字段的最新值。在多路复用过程开始时，Last_PID设置为PPPMuxCP中协商的默认PID值。此外，用户可配置参数maximum subframe length（MAX_SF_LEN）用于确定可复用的PPP帧的最大大小。MAX_SF_LEN的值应小于或等于MRU-2（长度字段的最大大小）和16383（14位）中的最小值。
After transmitting a PPP frame (multiplexed or not) on the channel, the PPP multiplexing logic looks at the buffers that hold the PPP frames to be transmitted. In case there are multiple frames, the PPP multiplexing logic checks if the length of the first frame in the buffer is less than or equal to MAX_SF_LEN bytes. If so, the transmitter starts compiling a multiplexed PPP frame with the protocol field value corresponding to PPP Multiplexed Frame (0x59). For each subframe, the test for deciding to prepend the protocol field to a subframe is to compare the protocol field value of the subframe to Last_PID. If they are equal, PFF is set to 0 and the protocol field is deleted. If not, PFF is set to 1, the protocol field is included, after PFC, in the subframe and Last_PID is set to
在信道上传输PPP帧（复用或非复用）后，PPP复用逻辑查看保存要传输的PPP帧的缓冲器。如果存在多个帧，PPP多路复用逻辑将检查缓冲区中第一个帧的长度是否小于或等于MAX_SF_LEN字节。如果是，则发射机开始编译具有与PPP多路复用帧（0x59）对应的协议字段值的多路复用PPP帧。对于每个子帧，决定将协议字段前置到子帧的测试是将该子帧的协议字段值与最后的_PID进行比较。如果它们相等，则PFF设置为0，并删除协议字段。如果不是，则PFF设置为1，协议字段包括在PFC之后的子帧中，最后一个PID设置为
the protocol field value of the current subframe. The stopping criteria in the concatenation process are (i) when the length of the next subframe is greater than MAX_SF_LEN bytes or (ii) the length of the entire PPP frame by including the new subframe exceeds the maximum receive unit (MRU) parameter negotiated during LCP [4], or (iii) there are no more subframes to concatenate.
当前子帧的协议字段值。连接过程中的停止标准是（i）当下一个子帧的长度大于MAX_SF_LEN字节时，或者（ii）通过包括新子帧而使整个PPP帧的长度超过在LCP期间协商的最大接收单元（MRU）参数[4]，或者（iii）没有更多的子帧要连接。
Implementers may choose additionally to implement using timers. In such a case a timeout in addition to the conditions stated above is used as a stopping criteria of the multiplexing process. Moreover, it may be desirable to limit the maximum size of a multiplexed packet to be considerably smaller than MRU for reasons of multiplexing latency and packet error considerations.
实现者还可以选择使用定时器来实现。在这种情况下，除了上述条件之外的超时被用作多路复用处理的停止标准。此外，出于复用延迟和分组错误的考虑，可能希望将复用分组的最大大小限制为大大小于MRU。
If a multiplexed frame, i.e., a frame with Protocol field value equal to PPP Multiplexed Frame (0x0059), is received, the frame is demultiplexed in order using the following input demultiplexing logic. Similar to a transmitter, the receiver has a state variable called Last_rcvd_PID, which is the value of the protocol field in the most recently demultiplexed subframe with PFF=1. Last_rcvd_PID is initialized to default PID value negotiated by PPPMuxCP. If PFF=0 for a subframe, Last_rcvd_PID is appended to the beginning of the subframe before handing the subframe, as determined by the length field, to the PPP logic. If PFF=1 for a subframe, Last_rcvd_PID is set to this value and the subframe, as determined by the length field, is passed to PPP logic. The remainder of the frame is returned to the demultiplexor. Each succeeding subframe is processed similarly. This processing is complete when the remainder of the frame is empty, or when the size field of a subframe exceeds the amount of data remaining in a packet. In the latter case, there is an error either in the length field of the last subframe or in the length field of one of the previous subframes. In either case the last subframe must be dropped by the demultiplexing logic.
如果接收到复用帧，即协议字段值等于PPP复用帧（0x0059）的帧，则使用以下输入解复用逻辑按顺序解复用该帧。与发射机类似，接收机具有称为Last_rcvd_PID的状态变量，它是PFF＝1的最近解复用子帧中的协议字段的值。最后一个\u rcvd \u PID初始化为PPPMuxCP协商的默认PID值。如果子帧的PFF=0，则在将由长度字段确定的子帧传递到PPP逻辑之前，最后一个_rcvd _PID被附加到子帧的开头。如果子帧的PFF=1，则最后一个_rcvd _PID设置为该值，并且由长度字段确定的子帧被传递给PPP逻辑。帧的其余部分返回到解复用器。对每个后续子帧进行类似的处理。当帧的剩余部分为空时，或者当子帧的大小字段超过数据包中剩余的数据量时，该处理完成。在后一种情况下，在最后一个子帧的长度字段中或在前一个子帧之一的长度字段中存在错误。在任何一种情况下，解复用逻辑都必须丢弃最后一个子帧。
It is illegal to put a multiplexed frame within a multiplexed frame.
在复用帧内放置复用帧是非法的。
A receiver will offer its ability to received multiplexed frames by negotiating NCP for PPP multiplexing, PPPMuxCP. The protocol field value for a PPPMuxCP frames is 0x8059. PPPMuxCP is similar to other NCPs such as IPCP [6]. A transmitter may not send a multiplexed frame unless the peer has offered to receive multiplexed frames. Support of multiplexed frame reception is negotiated in each direction independently. Successful negotiation of PPPMuxCP does not obligate a peer to transmit multiplexed frames.
接收机将通过协商用于PPP多路复用的NCP PPPMuxCP来提供接收多路复用帧的能力。PPPMuxCP帧的协议字段值为0x8059。PPPMuxCP与IPCP等其他NCP类似[6]。除非对等方已提供接收多路复用帧，否则发射机不能发送多路复用帧。多路复用帧接收的支持在每个方向上独立协商。PPPMuxCP的成功协商并不要求对等方传输多路复用帧。
As part of the PPPMuxCP negotiation, a 'default PID' option is always negotiated. This enables the transmitter to transmit the first subframe of a PPP multiplexed frame without a PID (PFF=0), thus resulting in a saving of one or two bytes. Note that the negotiation of default PID does not require the transmitter to send the first subframe with PFF=0 even if doing so would optimize the transmission. And, as always, the option (and thus the default PID) is negotiated by the receiver, i.e., the receiver will interpret a received PPPmux packet using the default PID it offered.
作为PPPMuxCP协商的一部分，始终协商“默认PID”选项。这使得发射机能够在没有PID（PFF＝0）的情况下发送PPP复用帧的第一子帧，从而导致节省一个或两个字节。注意，默认PID的协商不要求发射机发送PFF=0的第一个子帧，即使这样做会优化传输。并且，与往常一样，该选项（以及默认PID）由接收器协商，即，接收器将使用其提供的默认PID解释接收到的PPPmux数据包。
LCP frames MUST NOT be sent in Multiplexed frames. The only option in PPPMuxCP is the negotiation of Default PID and is shown below
LCP帧不得在多路复用帧中发送。PPPMuxCP中的唯一选项是协商默认PID，如下所示
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 = 1 | Length = 4 | Default PID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 = 1 | Length = 4 | Default PID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2. Default PID option for PPPMuxCP
图2。PPPMuxCP的默认PID选项
PPP multiplexed frame option is negotiated by an NCP. LCP is negotiated over each member link of a multilink bundle and not on the bundle itself [5]. Thus in case of MP, PPPmux cannot be negotiated for individual links, but only for the bundle.
PPP多路复用帧选项由NCP协商。LCP是在多链路捆绑包的每个成员链接上协商的，而不是在捆绑包本身上协商的[5]。因此，在MP的情况下，不能为单个链接协商PPPmux，而只能为捆绑包协商PPPmux。
Hence, on the transmitter side PPP multiplexing always occurs before multilink PPP encapsulation. On a link, an MP header (if present) MUST be outside of a PPPmux header (if present). Multilink frames must not be sent in Multiplexed frames.
因此，在发射机端，PPP多路复用总是在多链路PPP封装之前发生。在链接上，MP头（如果存在）必须位于PPPmux头（如果存在）之外。多链路帧不得在多路复用帧中发送。
PPP multiplexing must be performed below (after) any bundle-level CCP and/or ECP, and above (before) MP and any per-link CCP and/or ECP. Thus, to negotiate the hypothetical transmit path sequence CCP -> PPPMux -> ECP, the bundle-level version of CCP (80fd) and the per-link version of ECP (8055) are negotiated along with the PPPMux Option.
PPP多路复用必须在任何捆绑级CCP和/或ECP以下（之后）和MP及任何每链路CCP和/或ECP以上（之前）执行。因此，为了协商假设的传输路径序列CCP->PPPMux->ECP，CCP（80fd）的束级版本和ECP（8055）的每链路版本与PPPMux选项一起协商。
An implementation that cannot perform PPPMux above CCP or ECP MUST issue Protocol-Reject for the per-link forms of CCP and ECP if PPPMux has been negotiated.
如果已协商PPPMux，则无法在CCP或ECP之上执行PPPMux的实现必须为CCP和ECP的每链路形式发出协议拒绝。
This document does not impose additional security considerations beyond those that apply to PPP and header-compression schemes over PPP.
除了适用于PPP和PPP上的报头压缩方案的安全考虑之外，本文件不施加其他安全考虑。
The authors would like to thank contributors on the PPPext mailing list, especially James Carlson, for valuable inputs to this document.
作者要感谢PPPext邮件列表上的贡献者，特别是James Carlson，为本文件提供了宝贵的投入。
[1] Townsley, W., Valencia, A., Rubens, A., Pall, G., Zorn, G. and B. Palter, "Layer Two Tunneling Protocol "L2TP"", RFC 2661, August 1999.
[1] 汤斯利，W.，巴伦西亚，A.，鲁本斯，A.，帕尔，G.，佐恩，G.和B.帕尔特，“第二层隧道协议“L2TP”，RFC 26611999年8月。
[2] Simpson, W., Ed., "PPP LCP extensions", RFC 1570, January, 1994.
[2] 辛普森，W.，编辑，“PPP LCP扩展”，RFC 15701994年1月。
[3] Simpson, W., Ed., "PPP in HDLC-like Framing", STD 51, RFC 1662, July 1994.
[3] 辛普森，W.，编辑，“HDLC类框架中的PPP”，STD 51，RFC 16621994年7月。
[4] Simpson, W., Ed., "The Point-To-Point Protocol (PPP)", STD 51, RFC 1661, July 1994.
[4] 辛普森，W.，编辑，“点对点协议（PPP）”，STD 51，RFC 1661994年7月。
[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] McGregor, G., "The PPP Internet Protocol Control Protocol (IPCP)", RFC 1332, May 1992.
[6] McGregor，G.“PPP互联网协议控制协议（IPCP）”，RFC 1332，1992年5月。
[7] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[7] Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
Rajesh Pazhyannur Motorola, Network Solutions Sector 1501, W. Shure Drive Arlington Heights, IL 60004
Rajesh Pazhyannur摩托罗拉，伊利诺伊州阿灵顿高地舒尔大道西1501号网络解决方案区，邮编60004
Phone: (847) 632-4524 EMail: pazhynnr@cig.mot.com
电话：（847）632-4524电子邮件：pazhynnr@cig.mot.com
Irfan Ali Motorola, Network Solutions Sector 1501, W. Shure Drive Arlington Heights, IL 60004
伊利诺伊州阿灵顿高地舒尔大道西1501号网络解决方案区Irfan Ali Motorola 60004
Phone: (847) 632-3281 EMail: fia225@email.mot.com
电话：（847）632-3281电子邮件：fia225@email.mot.com
Craig Fox Cisco Systems 170 W. Tasman Street San Jose, CA 95134
克雷格·福克斯思科系统公司加利福尼亚州圣何塞塔斯曼街西170号，邮编95134
Phone: (408) 526-6296 EMail: fox@cisco.com
电话：（408）526-6296电子邮件：fox@cisco.com
Full Copyright Statement
完整版权声明
Copyright (C) The Internet Society (2001). All Rights Reserved.
版权所有（C）互联网协会（2001年）。版权所有。
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编辑功能的资金目前由互联网协会提供。