Network Working Group R. Pazhyannur
Request for Comments: 3153 I. Ali
Category: Standards Track Motorola
C. Fox
Cisco Systems
August 2001
PPP Multiplexing
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フラグ（隣接パケットを分離する少なくとも1つの）アドレス（0xFFで）および対照（0×03）フィールドのバイト、2バイトPPPプロトコルID、そして2バイトのCRCフィールド。アドレスおよび制御フィールドがオフにネゴシエートし、PPPプロトコルIDは、圧縮も用いて、各PPPカプセル化されたフレームは、オーバーヘッドの4つのバイトを含むであろう。 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ネゴシエーションフェーズの間、受信機はPPPMuxCPがネゴシエートされた後、送信機は、PPPを多重化するためにどのフレームを選択することができる第2節で説明したように、PPPマルチプレクサ制御プロトコル（PPPMuxCP）を使用して、多重化されたフレームを受信するために提供することができます。フレームは関係なく、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].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はあります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.
HDLC様のフレーミング[3]におけるPPPのために複数のサブフレームと一緒に完全なPPPフレームのフォーマットは、個々のビットが、すなわち、LSBファーストまたはMSBファースト、PFF、送信される順序と関係なく、図1（注）に示します。ビットは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) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1. Multiplexing subframes in a PPP frame.
PPPフレーム1に多重化サブフレームを図。
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:
長さフィールドは3つのサブフィールドで構成されています。
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は、各サブフレームの最初のバイトの最上位ビットを指します。この1ビットフィールドは、サブフレームのPPPプロトコルIDは、サブフレーム長フィールドに続くかどうかを示します。最初のサブフレームのPPPプロトコルIDはPPPMuxCPで交渉、デフォルトのPID値に等しい場合最初のサブフレームのために、PFFビットがゼロに設定することができます。 PFF = 1は、プロトコルフィールドが存在することを示す（および長さフィールドの後に続く）このサブフレーム。 PFF = 0は、プロトコルフィールドは、このサブフレームのために存在しないことを示しています。 PFF = 0次いで、PPPプロトコルID = 1 PFFと先行サブフレームと同じである、または最初のサブフレームのPPPMuxCPオプションのPID値をデフォルト値に等しい場合。送信機は、任意のサブフレームのためのPPPプロトコルIDを削除する義務はありません。
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).
この1ビットフィールドは、長さフィールドは1バイトまたは2バイトの長さであるか否かを示します。 LXTビットが設定されている場合、長さフィールドは、2バイト長（PFFビット長拡張ビット、サブフレーム長の14ビット）です。 LXTビットがクリアされた場合、長さフィールドは1バイト長（PFFビット長拡張ビット、及びサブフレームの長さの6ビット）です。
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の場合）。サブフレームの長さが64バイト未満（より少ないまたは63バイトに等しい）である場合、LXTはゼロに設定され、長さフィールドの最後の6ビットはサブフレーム長です。サブフレームの長さが63のバイトよりも大きい場合、LXTが1に設定され、長さフィールドの最後の14ビットは、サブフレームの長さです。サブフレームの最大長は16,383バイトです。 16,383バイトを超えるPPPパケットは、独自のPPPフレームで送信される必要があります。送信機は、16,383バイトより小さいすべてのフレームを多重化する必要はありません。これは、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.
受信機は、1つのまたは2つのバイト長プロトコルフィールド圧縮（PFC）をサポートしなければなりません。送信機は、ゼロの上位バイトを有し、このフィールドにPPPプロトコルIDを圧縮するべきである（すなわち、0xFDではスルー0x21でのプロトコルIDを）。各PPPサブフレームにおけるこのプロトコルフィールド圧縮は、PPP多重フレームプロトコルIDの長さに影響LCPネゴシエーション中PFCの交渉とは関係ありません。
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.
このフィールドは、カプセル化されている実際のパケットが含まれています。任意のフレームはNAKは、LCP設定要求、ACKを除いて、ここに含まれており、フレームとPPP多重化されたフレームを拒否することができます。 LCPを再交渉されている場合はPPPのMux制御プロトコルがネゴシエートされるまで、PPP多重化を無効にする必要があります。
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フレームの送信中に、送信機は、PFF = 1とサブフレームのプロトコルフィールドの最新の値を保持するために使用される状態変数、Last_PIDを有しています。多重化処理の開始時に、Last_PIDはPPPMuxCPで交渉デフォルトPID値に等しく設定されます。また、ユーザ設定パラメータ、最大サブフレーム長（MAX_SF_LEN）は、多重化することができるPPPフレームの最大サイズを決定するために使用されます。 MAX_SF_LENの値が小さいかMRU-2（最大長さフィールドのサイズ）及び16,383（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 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.
チャネル上で（多重化またはしない）PPPフレームを送信した後、PPP多重化ロジックは、PPPフレームが送信されるように保持するバッファで見えます。バッファの最初のフレームの長さはMAX_SF_LENバイト以下である場合場合に、複数のフレーム、PPP多重化論理チェックがあります。そうである場合、送信機は、PPP多重化フレーム（0x59）に対応するプロトコルフィールド値を有する多重PPPフレームをコンパイルを開始します。各サブフレームは、サブフレームにプロトコルフィールドを付加することを決定するための試験はLast_PIDに、サブフレームのプロトコルフィールド値を比較することです。それらが等しい場合、PFFは0に設定され、プロトコルフィールドが削除されます。 、PFFが1に設定されていない場合は、プロトコルフィールドが含まれ、PFC後、サブフレーム内及びLast_PIDは、現在のサブフレームのプロトコルフィールド値に設定されています。次のサブフレームの長さはMAX_SF_LENバイトよりも大きいか、（ii）の新しいサブフレームを含むことによって全体のPPPフレームの長さが最大値を超えたときに、連結プロセスにおける停止基準は、（i）である時にネゴシエートユニット（MRU）パラメータを受け取りますLCP [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）に等しいプロトコルフィールド値を有する、すなわち、フレームは、受信された場合、フレームは、論理を逆多重化以下の入力を使用して、順番に分離されます。送信機と同様に、受信機は、PFF = 1で最も最近デマルチプレクスサブフレーム内のプロトコルフィールドの値であるLast_rcvd_PIDと呼ばれる状態変数を有します。 Last_rcvd_PIDはPPPMuxCPによって交渉PID値をデフォルト値に初期化されます。 PFFは、サブフレーム= 0場合PPPロジックに、長さフィールドによって決定されるように、Last_rcvd_PIDは、サブフレームを渡す前に、サブフレームの先頭に付加されています。 PFFは、サブフレーム= 1の場合、Last_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多重化、PPPMuxCPためにNCPをネゴシエートすることにより、多重化フレームを受信する能力を提供します。 PPPMuxCPフレームのプロトコルフィールドの値が0x8059です。 PPPMuxCPは、IPCP [6]のような他のNCPと同様です。ピアが多重化されたフレームを受信するために提供していない限り、送信機は、多重化フレームを送信しなくてもよいです。多重化フレームの受信のサポートは、独立して、それぞれの方向に交渉されます。 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」オプションが常にネゴシエートされます。これは、このように1または2バイトの節約をもたらす、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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2. Default PID option for PPPMuxCP
PPPMuxCP図2.デフォルトの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はなく、唯一のバンドルについて、個々のリンクのために交渉することはできません。
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されなければなりません。 > PPPMux - - > ECP、CCP（80fd）の束レベルバージョンとECPのリンクごとのバージョン（8055）PPPMuxオプションと一緒に交渉されしたがって、仮定の送信パスシーケンスCCPを交渉します。
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.
CCPまたはECP上PPPMuxを実行することはできません実装は、プロトコル拒否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メーリングリスト、特にジェームズ・カールソンに貢献に感謝したいと思います。
[1] Townsley, W., Valencia, A., Rubens, A., Pall, G., Zorn, G. and B. Palter, "Layer Two Tunneling Protocol "L2TP"", RFC 2661, August 1999.
[1] Townsley、W.、バレンシア、A.、ルーベンス、A.、ポール、G.、ソーン、G、BのPalter、 "レイヤ2トンネリングプロトコル "L2TP""、RFC 2661、1999年8月。
[2] Simpson, W., Ed., "PPP LCP extensions", RFC 1570, January, 1994.
[2]シンプソン、W.、エド。、 "PPP LCP拡張"、RFC 1570、1994年1月。
[3] Simpson, W., Ed., "PPP in HDLC-like Framing", STD 51, RFC 1662, July 1994.
[3]シンプソン、W.、編、 "HDLC様のフレーミングにおけるPPP"、STD 51、RFC 1662、1994年7月。
[4] Simpson, W., Ed., "The Point-To-Point Protocol (PPP)", STD 51, RFC 1661, July 1994.
[4]シンプソン、W.、編、 "ポイントツーポイントプロトコル（PPP）"、STD 51、RFC 1661、1994年7月。
[5] Sklower, K., Lloyd, B., McGregor, G., Carr, D., and T. Coradetti, "The PPP Multilink Protocol (MP)", RFC 1990, August 1996.
[5] Sklower、K.、ロイド、B.、マクレガー、G.、カー、D.、およびT. Coradetti、 "PPPマルチリンクプロトコル（MP）"、RFC 1990、1996年8月。
[6] McGregor, G., "The PPP Internet Protocol Control Protocol (IPCP)", RFC 1332, May 1992.
[6]マクレガー、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]ブラドナーのは、S.は、BCP 14、RFC 2119、1997年3月の "RFCsにおける使用のためのレベルを示すために"。
Rajesh Pazhyannur Motorola, Network Solutions Sector 1501, W. Shure Drive Arlington Heights, IL 60004
ラジェッシュPazhyannurモトローラ、ネットワークソリューション部門1501、W.シュアードライブアーリントンハイツ、IL 60004
Phone: (847) 632-4524 EMail: pazhynnr@cig.mot.com
電話：（847）632-4524 Eメール：pazhynnr@cig.mot.com
Irfan Ali Motorola, Network Solutions Sector 1501, W. Shure Drive Arlington Heights, IL 60004
イルファン・アリモトローラ、ネットワークソリューション部門1501、W.シュアードライブアーリントンハイツ、IL 60004
Phone: (847) 632-3281 EMail: fia225@email.mot.com
電話：（847）632-3281 Eメール：fia225@email.mot.com
Craig Fox Cisco Systems 170 W. Tasman Street San Jose, CA 95134
クレイグ・フォックスシスコシステムズ170 W.タスマンストリートサンノゼ、CA 95134
Phone: (408) 526-6296 EMail: fox@cisco.com
電話：（408）526-6296 Eメール：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 Editor機能のための基金は現在、インターネット協会によって提供されます。