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
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チャネル、サブ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.
この文書では、アーキテクチャのリアルタイムのカプセル化形式部分のフラグメント指向のソリューションを提案しています。一般的なアプローチは、[2] PPPマルチリンクフラグメンテーションプロトコルから開始し、機能を追加するとオーバーヘッドを低減するための拡張の少数を提供することです。
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 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.
本文書は、キュー・オブ・フラグメント型送信者[1]のためのアーキテクチャ、すなわちのリアルタイムのカプセル化フォーマット部分の断片指向ソリューションを定義します。アーキテクチャの文書でより詳細に説明するように、リアルタイムのカプセル化形式は、例えば、として必要とされ、28.8キロビット/秒のモデムリンク上の1500バイトのパケットは約400ミリ秒のリアルタイム情報の伝送のため、このリンクが使用できなくなります。リアルタイムの会話のために許容できない - これは、少なくとも第二のオーダーの往復遅延で動作するリアルタイムアプリケーションを引き起こし、最悪の場合の遅延が追加されます。この文書で定義された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].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はあります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 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).
最も一般的なアプローチは、ネストのレベルの無限の数まで、より緊急のリアルタイムパケットのための任意のパケットを一時停止する機能（リアルタイムまたはしない）を提供します。一方で、ほとんど、少なくとも約2倍の長ではありません別のリアルタイムパケットを一時停止するリアルタイムパケットのための要件はないだろうと思われます。一般的に、PPPリンク上で予想される最大パケットサイズが1500バイトのデフォルトMTUです。最小の高優先度パケットは、22バイト（圧縮されたRTP / G.723.1パケット）の順に有している可能性があります。予想されるパケットサイズの1:72の範囲で、これは（長いリアルタイムパケットは長い非リアルタイムパケットをサスペンドあるレベルを含む）、懸濁液の約8レベルの最大要求に変換します。 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].
この文書では、フレームリレーと一緒に関連する可能性がある追加の要件に対処しません。ただし、[3]この文書に「フレームリレーにおけるPPP」の原則を適用するには少し問題があるように思われます。
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 |
+---------------+---------------+
(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の単調に増加するシーケンス番号は、（連続した数字は、パケットのすべてのフラグメントのために必要とされる）別のパケットを送信するために、1つのパケットのフラグメントのシーケンスの送信の停止を許可していません。マルチリンクヘッダでカプセル化されていないパケットを送信するために介入することは可能です。したがって、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;
マルチリンク-AS-では、いくつかの理由のための完全なソリューションではありません。まず、単一の単調増加シリアル番号、サスペンションの唯一のレベルがあるので：マルチリンクの外側に送ら「小」パケットによって懸濁させることができるマルチリンクを介して送信される「ビッグ」パケット。後者は、フラグメント化（したがって、1つのパケットのコンテンツが複数のリンク上で並列に送信することができないではありません。
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マルチリンクサスペンションとの複数のレベルを提供するための明白なアプローチは、1つのリンク上でマルチリンクを複数回実行することです。それが定義されているように、マルチリンクは、複数のインスタンスをアクティブにするための方法を提供しません。幸いなことに、ビットの数は、マルチリンクヘッダに使用されていない：ショートシーケンス番号の形式で2つのビット（図1に見られるように）、長いシーケンス番号の形式で6。
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 |
+---------------+---------------+
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 |
+---------------+---------------+
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).
一緒にマルチリンクヘッダなしでパケットを送信する機能と、これはわずか6自由ビットの4つで使用される24ビットのヘッダ（と（多くの実用的な用途のために、おそらく十分な）12ビットのヘッダと16レベルとサスペンションの4つのレベルを提供しますこの場合、 - 上記の原理に基づいて、16のレベルは、一般的に十分以上であるべきです）。
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.)
唯一のいくつかのパケットの優先度の一定のレベルで送信されるように、共通の接頭辞を持っている場合、まだ2つのクラス番号を割り当てるだけプレフィックスでそれらのいずれかを関連付けることによって、この方法を利用することが可能であってもよいことに留意されたいです。 （これは、長いシーケンス番号の形式における未使用ビットの4の代わりに、一般的に十分である3のクラス番号に割り当てられている理由です。）
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:
以下PPP LCPオプションは、すでにMPによって定義されています。
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:
この文書では、2つの新しい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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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.
このオプションがネゴシエートされると、受付実装は、所定または設定否定応答またはオプションを設定は拒否マルチリンクヘッダフォーマットでバンドルのすべてのリンク上のすべての後続のマルチリンクパケットを送信する必要があります。 （実装がどのような場合にマルチリンクの外にパケットを送信し続けることに留意されたい。）このオプションは既存のバンドルに加入することを意図しているリンク上で提供されている場合、システムは、以前のために交渉同じマルチリンクヘッダフォーマットオプション値を提供しなければなりませんバンドル、またはnone何も以前に交渉されなかった場合。
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]）も存在してはなりません。このオプションまたはショートシーケンス番号ヘッダー形式オプションのインスタンスが存在しないが、[2] MRRUオプションは、デフォルトで、存在する場合、クラス0の長いシーケンス番号マルチヘッダのみ使用されます。これは、コードと等価である2に等しく、懸濁クラスの数は、コード6及び1に等しい休止クラスの数に等しいとショートシーケンス番号ヘッダー形式オプションの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オプションは、所与のクラスのそれぞれに、実装は特定の接頭辞を持つパケットのみを受信することを期待する、ピアに通知します。このプレフィックスは、このクラスの断片（単数または複数）内の情報の一部として送信されるべきではありません。デフォルトでは、この共通のプレフィックスは、すべてのクラスのために空になっています。このオプションがネゴシエートされると、受付実装は、パケットまたは設定否定応答またはオプションを設定するには、拒否の開始から削除指定された接頭辞で指定されたクラスの各々の後続のすべてのマルチリンクパケットを送信する必要があります。クラスと形式のどれもが交渉されていない場合は、クラス番号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...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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.
プレフィックスエリジオンオプションは、設定要求または設定否定応答で複数回発生してはなりません。このオプションは、既存のマルチリンクバンドルに参加することを目的としているリンク上で提供されている場合は何も以前に交渉されなかった場合、システムは同じプレフィックスエリジオンオプションの前にバンドルのために交渉値、またはnoneを提供しなければなりません。
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オプションと同様に、このオプションの意味は、当該パケットの受信側から送信側への指示です。多くの場合、唯一の送信者は、このオプションのための有用な値を供給できるようにするには、クラスのその使用方法を十分にコントロールされます。プレフィックス省略されたパケットを受け入れるように喜んで受信機は、空のコンテンツでは、このオプションを要求する必要があります。送信者は、その後、目的のクラス・ツー・プレフィックスのマッピングを提案する設定否定応答を使用することができます。
Operation of this protocol is believed to be no more and no less secure than operation of the PPP multilink protocol [2].
このプロトコルの動作は、[2]のそれ以上とPPPマルチリンクプロトコルの動作を下回らない安全でないと考えられています。
[1] Bormann, C., "Providing Integrated Services over Low-bitrate Links", RFC 2689, September 1999.
[1]ボルマン、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] Sklower、K.、ロイド、B.、マクレガー、G.、カー、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.ブルグ、 "PPPにQOSPPPフレーミング拡張"、ProgressのWork。
[5] Bormann, C., "PPP in a Real-time Oriented HDLC-like Framing", RFC 2687, September 1999.
[5]ボルマン、C.、 "リアルタイムでのPPP指向HDLCのようなフレーミング"、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 1661、1994年7月。
[7] Simpson, W., Editor, "PPP in HDLC-like Framing", STD 51, RFC 1662, July 1994.
[7]シンプソン、W.、エディタ、 "PPP HDLC様のフレーミングに" STD 51、RFC 1662、1994年7月。
[8] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[8]ブラドナーのは、S.は、BCP 14、RFC 2119、1997年3月の "RFCsにおける使用のためのレベルを示すために"。
Carsten Bormann Universitaet Bremen FB3 TZI Postfach 330440 D-28334 Bremen, GERMANY
カールステンボルマンUniversitaetブレーメンTZI FB3 POSTFACH 330440 D-28334ブレーメン、ドイツ
Phone: +49.421.218-7024 Fax: +49.421.218-7000 EMail: cabo@tzi.org
電話：+ 49.421.218-7024ファックス：+ 49.421.218-7000 Eメール：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.
デビッド・オランは、リアルタイムフレーミングPPPマルチリンクを使うことを提案し、この目的のためのマルチリンクは、より有用なものの彼の以前の試みの作者に思い出させました。 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 Editor機能のための基金は現在、インターネット協会によって提供されます。