RFC3153 日本語訳
3153 PPP Multiplexing. R. Pazhyannur, I. Ali, C. Fox. August 2001. (Format: TXT=19244 bytes) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
Network Working Group R. Pazhyannur
Request for Comments: 3153 I. Ali
Category: Standards Track Motorola
C. Fox
Cisco Systems
August 2001
Pazhyannurがコメントのために要求するワーキンググループR.をネットワークでつないでください: 3153年のI.アリカテゴリ: 標準化過程モトローラC.フォックスシスコシステムズ2001年8月
PPP Multiplexing
pppマルチプレクシング
Status of this Memo
この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.
このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (2001). All Rights Reserved.
Copyright(C)インターネット協会(2001)。 All rights reserved。
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(指すポイントプロトコル)を減少させる方法を説明します。
1. Description
1. 記述
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 Multiplexing)は単一のPPPフレームの要約のパケットを複数のPPPに送ります。 その結果、1パケットあたりのPPPオーバーヘッドは下げられます。 PPPカプセル化(例えば、HDLC縁どりにおけるPPPと)は数バイトのオーバーヘッドを加えます: HDLC旗(少なくともパケットに隣接して切り離す1つ)、Address(0xFF)、およびControl(0×03)はバイト、2バイトのPPP Protocol ID、および2バイトのCRC分野をさばきます。 交渉されたフィールズとProtocol IDが圧縮したPPP、各PPPが要約したAddressとControlと共にさえ、フレームは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への要約のフレームがそれぞれのフレームの始まりの前にデリミタを挿入することによってフレームを多重送信したということです。 デリミタの記述をSubsection1.1に提供します。 デリミタは、多重送信されたフレームの中にPPPフレームを分離するのに「反-マルチプレクサー」によって使用されます。 PPPがフレームを要約した多重送信が縁どるそれぞれがPPP subframeと呼ばれます。
Pazhyannur, et al. Standards Track [Page 1] RFC 3153 PPP Multiplexing August 2001
Pazhyannur、他 2001年8月に多重送信される標準化過程[1ページ]RFC3153ppp
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 Controlプロトコル(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.
どんな連結計画のようにも、多重送信されたフレームの長さが増加するのに従って、implementerはマルチプレクシング/逆多重化のための増加する遅れと減少しているパケットオーバーヘッドの間の見返りを考えなければなりません。
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"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTはRFC2119[7]で説明されるように本書では解釈されることであるべきですか?
1.1. Payload Format
1.1. 有効搭載量形式
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フレームの書式は図1に示されます。 個々のビットが伝えられる注文にかかわらずすなわち、LSB1番目かMSB1番目、PFFビットがPFFと「副-フレーム」長さの分野の両方を含む1バイトの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| | ヘッダー+| | + 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 Multiplexed Frame(0×0059)のためのPPPプロトコルFieldを含んでいます。 PPPヘッダー圧縮オプション(ACFCとPFC)は、LCPの間、交渉されて、その結果、このヘッダーの形式に影響するかもしれません。
Pazhyannur, et al. Standards Track [Page 2] RFC 3153 PPP Multiplexing August 2001
Pazhyannur、他 2001年8月に多重送信される標準化過程[2ページ]RFC3153ppp
Length Field:
長さの分野:
The length field consists of three subfields:
長さの分野は3つの部分体から成ります:
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はそれぞれの「副-フレーム」の最初のバイトの最も重要なビットについて言及します。 この1ビットの分野は、「副-フレーム」のPPP Protocol IDが「副-フレーム」長さの野原に続くかどうかを示します。 最初の「副-フレーム」において、最初の「副-フレーム」のPPPプロトコルIDがPPPMuxCPで交渉されたデフォルトPID価値と等しいなら、PFFビットはゼロに設定されるかもしれません。 PFF=1は、プロトコル分野がこの「副-フレーム」のために存在しているのを(そして、長さの野原に続きます)示します。 PFF=0は、この「副-フレーム」において、プロトコル分野に欠けているのを示します。 PFF=0であるなら、PPP Protocol IDがPFF=1で前の「副-フレーム」のものと同じであるか、または最初の「副-フレーム」に、それはPPPMuxCP OptionのデフォルトPID価値と等しいです。 送信機がどんな「副-フレーム」のためにもPPP Protocol 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).
この1ビットの分野は、長さの分野が1バイトかそれとも2バイト長であるかを示します。 LXTビットが設定されるなら、長さの分野は2バイト長(PFFビット、長さの拡大ビット、およびサブフレームの長さの14ビット)です。 LXTビットがきれいにされるなら、長さの分野は長さ1バイトです(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.
これは長さの分野を含まないバイトで表現される「副-フレーム」の長さです。 しかしながら、存在しているなら(すなわち、PFF=1であるなら)、それはPPP Protocol IDを含んでいます。 「副-フレーム」の長さが64バイト(63バイト以下)未満であるなら、LXTはゼロに用意ができています、そして、長さの分野の最後の6ビットは「副-フレーム」の長さです。 「副-フレーム」の長さが63バイト以上であるなら、LXTは1つに用意ができています、そして、長さの分野の最後の14ビットは「副-フレーム」の長さです。 「副-フレーム」の最大の長さは1万6383バイトです。 1万6383バイトより大きいPPPパケットは、それら自身のPPPフレームで送られる必要があるでしょう。 送信機は、1万6383バイトより小さくすべてのフレームを多重送信するのに必要ではありません。 それは選ぶかもしれません。PPPへの構成可能なサイズがフレームを多重送信したより小さいフレームを多重送信するだけであるのを選びました。
Pazhyannur, et al. Standards Track [Page 3] RFC 3153 PPP Multiplexing August 2001
Pazhyannur、他 2001年8月に多重送信される標準化過程[3ページ]RFC3153ppp
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.
この分野は「副-フレーム」のためのプロトコルField価値を含んでいます。 この分野は任意です。 プロトコル分野が「副-フレーム」のための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)1かtwoバイト長を支持しなければなりません。 送信機SHOULDはこの分野のゼロ(すなわち、0xFDを通した0×21からのプロトコルID)の上側のバイトを持っているPPPプロトコルIDを圧縮します。 各PPP subframeのこのプロトコルField CompressionはPPP Multiplexed Frame Protocol 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.
この分野はカプセルに入れられる実際のパケットを含んでいます。 LCP Configure Request、ACK、NAK、Rejectフレーム、およびPPP Multiplexedフレームを除いて、どんなフレームもここに含まれるかもしれません。 LCPが再交渉されるなら、PPP Mux Controlプロトコルが交渉されるまで、PPP Multiplexingを無効にしなければなりません。
1.2 Transmitter procedure
1.2送信機手順
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フレームの最大サイズを測定するのに使用されます。 以下MRU-2(長さの分野の最大サイズ)と1万6383(14ビット)の最小限にはMAX_SF_LENの値があるべきです。
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 Multiplexed Frame(0×59)に対応するプロトコル分野価値から多重送信されたPPPフレームをコンパイルし始めます。 各「副-フレーム」に関しては、「副-フレーム」へのプロトコル分野についてprependに決めるためのテストは「副-フレーム」のプロトコル分野価値をLast_PIDと比較することです。 それらが等しいなら、PFFは0に用意ができています、そして、プロトコル分野は削除されます。 そうでなければ、PFFは1に用意ができています、そして、プロトコル分野はPFCの後に「副-フレーム」に含まれています、そして、Last_PIDは用意ができています。
Pazhyannur, et al. Standards Track [Page 4] RFC 3153 PPP Multiplexing August 2001
Pazhyannur、他 2001年8月に多重送信される標準化過程[4ページ]RFC3153ppp
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) 次の「副-フレーム」の長さが新しい「副-フレーム」を含んでいるのによる全体のPPPフレームの長さのMAX_SF_LENバイトか(ii)が最大を超えているより大きいときに、LCP[4]の間に交渉されたユニット(MRU)パラメタを受け取るか、またはいいえが以上が連結するように「副-縁ど」るあるという(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.
Implementersは、使用タイマを実行するのをさらに、選ぶかもしれません。 マルチプレクシングの停止評価基準が処理されるとき、上に述べられた状態に加えたこのような場合にはタイムアウトは使用されています。 そのうえ、マルチプレクシング潜在の理由によるMRUとパケット誤り問題よりかなり小さくなるように多重送信されたパケットの最大サイズを制限するのは望ましいかもしれません。
1.3 Receiver procedure
1.3受信機手順
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 Multiplexed Frame(0×0059)と等しいプロトコル分野価値があるフレーム)が受け取られているなら、フレームは、以下の入力逆多重化論理を使用することで整然とした状態で反多重送信されます。 送信機と同様です、受信機には、Last_rcvd_PIDと呼ばれる州の変数があります。(それは、最も最近のPFF=1とdemultiplexed subframeのプロトコル分野の値です)。 最後に、_rcvd_PIDはPPPMuxCPによって交渉されたデフォルトPID価値に初期化されます。 「副-フレーム」のためのPFF=0であるなら、「副-フレーム」を手渡す前に「副-フレーム」の始まりまでLast_rcvd_PIDを追加します、長さの分野で決定するように、PPP論理に。 「副-フレーム」のためのPFF=1、Last_rcvd_PIDがこの値に用意ができて、長さの分野で決定する「副-フレーム」がPPP論理に渡されるなら。 フレームの残りは「反-マルチプレクサー」に返されます。 続く各「副-フレーム」は同様に処理されます。 フレームの残りが空であるか、または「副-フレーム」のサイズ分野がパケットに残っているデータ量を超えているとき、この処理は完全です。 後者の場合には、誤りが最後の「副-フレーム」の長さの分野か前の「副-フレーム」の1つの長さの分野にあります。 どちらの場合ではも、逆多重化論理で最後の「副-フレーム」を落とさなければなりません。
It is illegal to put a multiplexed frame within a multiplexed frame.
多重送信されたフレームの中に多重送信されたフレームを置くのは不法です。
2. PPP Network Control Protocol for PPP Multiplexing (PPPMuxCP)
2. pppマルチプレクシングのためのpppネットワーク制御プロトコル(PPPMuxCP)
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.
PPPMuxCP、受信機はPPPマルチプレクシングのためにNCPを交渉することによって、容認された多重送信されたフレームに性能を提供するでしょう。 PPPMuxCPフレームへのプロトコル分野価値は0×8059です。 PPPMuxCPはIPCP[6]などの他のNCPと同様です。 同輩が、多重送信されたフレームを受け取ると申し出ていない場合、送信機は多重送信されたフレームを送らないかもしれません。 多重送信されたフレームレセプションのサポートは独自に各方向と交渉されます。 PPPMuxCPのうまくいっている交渉は、同輩が多重送信されたフレームを伝えるのを義務付けません。
Pazhyannur, et al. Standards Track [Page 5] RFC 3153 PPP Multiplexing August 2001
Pazhyannur、他 2001年8月に多重送信される標準化過程[5ページ]RFC3153ppp
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)を縁どっていて、その結果、1バイトか2バイトの節約をもたらしながら多重送信された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
MultiplexedフレームでLCPフレームを送ってはいけません。 PPPMuxCPにおける唯一のオプションが、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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | =1をタイプしてください。| 長さ=4| デフォルトPID| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2. Default PID option for PPPMuxCP
図2。 PPPMuxCPのためのデフォルトPIDオプション
3. Interaction with PPP Multilink (MP) Protocol
3. pppマルチリンク(MP)プロトコルとの相互作用
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ヘッダーの外にあって、(現在。)でなければなりません。 Multiplexedフレームでマルチリンクフレームを送ってはいけません。
4. Interaction with CCP and ECP
4. CCPとECPとの相互作用
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.
どんな1リンクあたりの実行された以下の(after)がどんなバンドルレベルCCP、そして/または、ECPであったに違いないならも多重送信して、(before)MPの上でそうするPPPとCCP、そして/または、ECP。 そして、その結果、仮言命題を交渉するために、経路系列CCP->PPPMux->ECPを伝えてください、CCP(80fd)のバンドルレベルバージョン、-、ECP(8055)のリンクバージョンはPPPMux Optionと共に交渉されます。
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の上のPPPMuxを実行できない実現かECP MUSTがCCPとECPの1リンクあたりのフォームのためにプロトコル廃棄物を発行します。
Pazhyannur, et al. Standards Track [Page 6] RFC 3153 PPP Multiplexing August 2001
Pazhyannur、他 2001年8月に多重送信される標準化過程[6ページ]RFC3153ppp
5. Security Considerations
5. セキュリティ問題
This document does not impose additional security considerations beyond those that apply to PPP and header-compression schemes over PPP.
このドキュメントはPPPの上でPPPに適用されるものとヘッダー圧縮技術を超えて追加担保問題を課しません。
6. Acknowledgements
6. 承認
The authors would like to thank contributors on the PPPext mailing list, especially James Carlson, for valuable inputs to this document.
作者はPPPextメーリングリストで貢献者に感謝したがっています、特にジェームス・カールソン、このドキュメントへの貴重な入力のために。
7. References
7. 参照
[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.はあしらわれます、「層Twoはプロトコル"L2TP"にトンネルを堀っ」て、RFC2661、1999年8月。
[2] Simpson, W., Ed., "PPP LCP extensions", RFC 1570, January, 1994.
[2] シンプソン、W.、エド、「PPP LCP拡張子」、RFC1570 1月、1994
[3] Simpson, W., Ed., "PPP in HDLC-like Framing", STD 51, RFC 1662,
July 1994.
[3] エドシンプソン、W.、STD51、RFC1662、「HDLCのようのpppは縁どっている」7月1994日
[4] Simpson, W., Ed., "The Point-To-Point Protocol (PPP)", STD 51,
RFC 1661, July 1994.
[4] シンプソン、W.、エド、「二地点間プロトコル(ppp)」、STD51、RFC1661、7月1994日
[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)について議定書の中で述べます」、RFC1990、1996年8月。
[6] McGregor, G., "The PPP Internet Protocol Control Protocol
(IPCP)", RFC 1332, May 1992.
[6] マクレガー(G.、「pppインターネットプロトコル制御プロトコル(IPCP)」RFC1332)は1992がそうするかもしれません。
[7] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[7] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。
Pazhyannur, et al. Standards Track [Page 7] RFC 3153 PPP Multiplexing August 2001
Pazhyannur、他 2001年8月に多重送信される標準化過程[7ページ]RFC3153ppp
8. Author's Addresses
8. 作者のアドレス
Rajesh Pazhyannur Motorola, Network Solutions Sector 1501, W. Shure Drive Arlington Heights, IL 60004
シュアー・Driveアーリントンハイツ、イリノイ ラジェッシュ・Pazhyannurモトローラ、ネットワークソリューションセクター1501、W.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
シュアー・Driveアーリントンハイツ、イリノイ Irfanアリ・モトローラ、ネットワークソリューションセクター1501、W.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
クレイグ・フォックスシスコシステムズ170w.タスマン・通りサンノゼ、カリフォルニア 95134
Phone: (408) 526-6296 EMail: fox@cisco.com
以下に電話をしてください。 (408) 526-6296 メールしてください: fox@cisco.com
Pazhyannur, et al. Standards Track [Page 8] RFC 3153 PPP Multiplexing August 2001
Pazhyannur、他 2001年8月に多重送信される標準化過程[8ページ]RFC3153ppp
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (2001). All Rights Reserved.
Copyright(C)インターネット協会(2001)。 All rights reserved。
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.
それに関するこのドキュメントと翻訳は、コピーして、それが批評するか、またはそうでなければわかる他のもの、および派生している作品に提供するか、または準備されているかもしれなくて、コピーされて、発行されて、全体か一部広げられた実現を助けるかもしれません、どんな種類の制限なしでも、上の版権情報とこのパラグラフがそのようなすべてのコピーと派生している作品の上に含まれていれば。 しかしながら、このドキュメント自体は何らかの方法で変更されないかもしれません、インターネット協会か他のインターネット組織の版権情報か参照を取り除くのなどように、それを英語以外の言語に翻訳するのが著作権のための手順がインターネットStandardsの過程で定義したどのケースに従わなければならないか、必要に応じてさもなければ、インターネット標準を開発する目的に必要であるのを除いて。
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機能のための基金は現在、インターネット協会によって提供されます。
Pazhyannur, et al. Standards Track [Page 9]
Pazhyannur、他 標準化過程[9ページ]
一覧
スポンサーリンク
