[要約] RFC 2686は、Multi-Link PPPのマルチクラス拡張に関する規格です。このRFCの目的は、複数のクラスタイプをサポートすることで、異なるトラフィックの要件に対応することです。
Network Working Group C. Bormann
Request for Comments: 2686 Universitaet Bremen TZI
Category: Standards Track September 1999
The Multi-Class Extension to Multi-Link PPP
マルチリンクPPPへのマルチクラス拡張機能
Status of this Memo
本文書の位置付け
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このドキュメントは、インターネットコミュニティのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態とステータスについては、「インターネット公式プロトコル標準」（STD 1）の現在のエディションを参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (1999). All Rights Reserved.
Copyright（c）The Internet Society（1999）。無断転載を禁じます。
Abstract
概要
A companion document describes an architecture for providing integrated services over low-bitrate links, such as modem lines, ISDN B-channels, and sub-T1 links [1]. The main components of the architecture are: a real-time encapsulation format for asynchronous and synchronous low-bitrate links, a header compression architecture optimized for real-time flows, elements of negotiation protocols used between routers (or between hosts and routers), and announcement protocols used by applications to allow this negotiation to take place.
コンパニオンドキュメントでは、モデムライン、ISDN Bチャネル、およびSUB-T1リンクなどの低ビトレートリンクを介して統合サービスを提供するためのアーキテクチャを説明しています[1]。アーキテクチャの主なコンポーネントは次のとおりです。非同期および同期性低ビトレートリンクのリアルタイムカプセル化形式、リアルタイムフロー用に最適化されたヘッダー圧縮アーキテクチャ、ルーター（またはホストとルーター間）の間で使用されるネゴシエーションプロトコルの要素、およびこの交渉を行うためにアプリケーションで使用される発表プロトコル。
This document proposes the fragment-oriented solution for the real-time encapsulation format part of the architecture. The general approach is to start from the PPP Multilink fragmentation protocol [2] and provide a small number of extensions to add functionality and reduce the overhead.
このドキュメントでは、アーキテクチャのリアルタイムカプセル化形式の部分のフラグメント指向ソリューションを提案します。一般的なアプローチは、PPPマルチリンク断片化プロトコル[2]から開始し、機能を追加してオーバーヘッドを減らすための少数の拡張機能を提供することです。
As an extension to the "best-effort" services the Internet is well-known for, additional types of services ("integrated services") that support the transport of real-time multimedia information are being developed for, and deployed in the Internet.
「ベストエフォルト」サービスの拡張として、インターネットは有名であるため、リアルタイムのマルチメディア情報の輸送をサポートする追加の種類のサービス（「統合サービス」）が開発され、インターネットに展開されています。
The present document defines the fragment-oriented solution for the real-time encapsulation format part of the architecture, i.e. for the queues-of-fragments type sender [1]. As described in more detail in the architecture document, a real-time encapsulation format is 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.
現在のドキュメントでは、アーキテクチャのリアルタイムカプセル化形式の部分、つまりfragments of-fragmentsタイプ送信者の断片指向ソリューションを定義しています[1]。アーキテクチャドキュメントで詳細に説明したように、たとえば28.8 kbit/sモデムリンクの1500バイトパケットでリアルタイムのカプセル化形式が必要です。。これにより、最悪の遅延が追加され、リアルタイムの会話には、少なくとも1秒の順序で往復遅延が発生し、往復の遅延で動作します。このドキュメントで定義されている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].
「必須」、「そうしない」、「必須」、「必要」、「「しない」、「そうでない」、「そうではない」、「そうでない」、「推奨」、「5月」、および「オプション」は、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レベルのサスペンションの最大要件につながります（長いリアルタイムパケットが長い非リアルタイムパケットを懸濁する1つのレベルを含む）。28.8kbit/sモデムでは、少なくとも2つのレベルのサスペンションには実用的な要件があるようです（つまり、オーディオはビデオを含むパケットを一時停止し、ビデオは他の非常に長いパケットを一時停止します）。
On an architectural level, there are several additional requirements for the fragmentation scheme:
建築レベルでは、断片化スキームにはいくつかの追加要件があります。
a) The scheme must be predictable enough that admission control can make decisions based on its characteristics. As is argued in [1], this will often only be the case when additional hints about the characteristics of the flow itself are available (application hints).
a) スキームは、入学制御がその特性に基づいて決定を下すことができるように十分に予測可能でなければなりません。[1]で議論されているように、これはしばしば、流れ自体の特性に関する追加のヒントが利用可能である場合にのみ当てはまります（アプリケーションのヒント）。
b) The scheme must be robust against errors, at least with the same level of error detection as PPP.
b) スキームは、少なくともPPPと同じレベルのエラー検出で、エラーに対して堅牢でなければなりません。
c) The scheme must in general cooperate nicely with PPP. In particular, it should be as compatible to existing PPP standards as possible. On a link that (based on PPP negotiation) makes use of the scheme, it should always be possible to fall back to standard LCP (PPP Link Control Protocol [6, 7]) without ambiguity.
c) スキームは、一般的にPPPとうまく協力しなければなりません。特に、既存のPPP標準と可能な限り互換性があるはずです。（PPP交渉に基づいて）スキームを利用しているリンクでは、あいまいさなく標準のLCP（PPPリンク制御プロトコル[6、7]）に戻ることが常に可能になるはずです。
d) The scheme must work well with existing chips and router systems. (See [1] for a more extensive discussion of implementation models.) For synchronous links this means using HDLC framing; with much existing hardware, it is also hard to switch off the HDLC per-frame CRC. For asynchronous links, there is much more freedom in design; on the other hand, a design that treats them much different from synchronous links would lose a number of desirable properties of PPP.
d) スキームは、既存のチップとルーターシステムでうまく機能する必要があります。（実装モデルのより広範な議論については[1]を参照してください。）同期リンクについては、HDLCフレーミングを使用することを意味します。多くの既存のハードウェアを使用すると、HDLCごとのCRCをオフにすることも困難です。非同期リンクの場合、設計にはさらに多くの自由があります。一方、同期リンクとは大きく異なるデザインは、PPPの多くの望ましい特性を失います。
e) The scheme must be future proof. In particular, the emergence of V.80 based modems may significantly change the way PPP is used with modems.
e) スキームは将来の証拠でなければなりません。特に、V.80ベースのモデムの出現は、PPPのモデムで使用する方法を大幅に変える可能性があります。
This document does not address additional requirements that may be relevant in conjunction with Frame Relay; however, there seems to be little problem in applying the principles of this document to "PPP in Frame Relay" [3].
このドキュメントは、フレームリレーと併せて関連する可能性のある追加の要件に対処していません。ただし、このドキュメントの原則を「フレームリレーのPPP」に適用することにはほとんど問題がないようです[3]。
Transmitting only part of a packet to allow higher-priority traffic to intervene and resuming its transmission later on is a kind of fragmentation. The existing PPP Multilink Protocol (MP, [2]) provides for sequence numbering and begin/end bits, allowing packets to be split into fragments (Figure 1).
パケットの一部のみを送信して、より優先順位のトラフィックが介入し、その後の送信を再開できるようにすることは、一種の断片化です。既存のPPPマルチリンクプロトコル（MP、[2]）は、シーケンスの番号付けと開始/終了ビットを提供し、パケットをフラグメントに分割できるようにします（図1）。
Figure 1: Multilink Short Sequence Number Fragment Format [2]
図1：マルチリンクショートシーケンス番号フラグメント形式[2]
+---------------+---------------+
PPP Header: | Address 0xff | Control 0x03 |
+---------------+---------------+
| PID(H) 0x00 | PID(L) 0x3d |
+-+-+-+-+-------+---------------+
MP Header: |B|E|0|0| sequence number |
+-+-+-+-+-------+---------------+
| fragment data |
| . |
| . |
| . |
+---------------+---------------+
PPP FCS: | FCS |
+---------------+---------------+
(Note that the address, control, and most significant PID bytes are often negotiated to be compressed away.)
（アドレス、制御、および最も重要なPIDバイトは、しばしば圧縮されるように交渉されることに注意してください。）
MP's monotonically increasing sequence numbering (contiguous numbers are needed for all fragments of a packet) does not allow suspension of the sending of a sequence of fragments of one packet in order to send another packet. It is, however, possible to send intervening packets that are not encapsulated in multilink headers; thus, MP supports two levels of priority.
MPの単調に増加するシーケンス番号（パケットのすべてのフラグメントに連続的な数値が必要です）では、別のパケットを送信するために、あるパケットのフラグメントのシーケンスの送信を停止することはできません。ただし、マルチリンクヘッダーにカプセル化されていない介在するパケットを送信することは可能です。したがって、MPは2つのレベルの優先度をサポートします。
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アプローチは、既存の標準を使用して構築できます。マルチリンク機能は広く展開されており、送信側のみが、リアルタイムパケットを優先するためにこれを使用していることに注意する必要があります。
Multilink-as-is is not the complete solution for a number of reasons. First, because of the single monotonically increasing serial number, there is only one level of suspension: "Big" packets that are sent via multilink can be suspended by "small" packets sent outside of multilink; the latter are not fragmentable (and therefore, the content of one packet cannot be sent in parallel on multiple links;
Multilink-As-Asは、いくつかの理由で完全なソリューションではありません。第一に、単一のシリアル番号が単一で増加しているため、サスペンションのレベルは1つしかありません。マルチリンクを介して送信される「大きな」パケットは、マルチリンクの外部で送信される「小さな」パケットで一時停止できます。後者は断片化できません（したがって、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.
この仕様では解決しない問題は、マルチリンクヘッダーが比較的大きいことです。遅延範囲が小さくなると（Queues-of-Fragmentsタイプの実装の場合）、オーバーヘッドが大幅になる可能性があります。
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つのリンクで複数回マルチリンクを実行することです。Multilinkが定義されているため、複数のインスタンスがアクティブになる方法はありません。幸いなことに、マルチリンクヘッダーでは多くのビットが使用されていません。短いシーケンス番号形式の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).
マルチリンクヘッダーなしでパケットを送信する機能とともに、12ビットヘッダーを備えた4つのレベルのサスペンション（おそらく多くの実用的なアプリケーションで十分）と24ビットヘッダーの16レベル（6つのフリービットのうち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.) 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.
特定のレベルの優先度で送信されるパケットの一部のみが共通のプレフィックスを持っている場合、2つのクラス番号を割り当て、それらの1つを接頭辞に関連付けることでこの方法を利用することができる場合があることに注意してください。（これが、長いシーケンス番号形式の4つの未使用のビットが、一般的に十分にすべき3つではなくクラス番号に割り当てられた理由です。）プレフィックスエリジョンは、ヘッダー圧縮またはデータ圧縮の代替ではありません。多くの場合、ヘッダーまたはデータ圧縮方法で到達できないプレフィックスを圧縮する。
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.
Multilink Headerフォーマットオプション形式の概要を以下に示します。フィールドは左から右に送信されます。
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.
このオプションがネゴシエートされた場合、受け入れた実装は、バンドルのすべてのリンクでその後のすべてのマルチリンクパケットを、指定されたマルチリンクヘッダー形式で送信するか、nakを構成するか、オプションを構成するか、構成する必要があります。（実装は、いずれにしてもマルチリンクの外にパケットを送信し続ける場合があることに注意してください。）このオプションが既存のバンドルを結合することを目的としたリンクで提供される場合、システムは以前にネゴシエートされた同じマルチリンクヘッダー形式のオプション値を提供する必要があります。バンドル、または以前に交渉されていない場合はなし。
The values defined in this document for the use of this option are:
このオプションを使用するためにこのドキュメントで定義されている値は次のとおりです。
- Code = 2: long sequence number fragment format with classes
- コード= 2：クラス付きの長いシーケンス番号フラグメント形式
- Code = 6: short sequence number fragment format with classes
- コード= 6：クラス付きの短いシーケンス番号フラグメント形式
The Multilink Header Format option MUST NOT occur more than once in a Configure-Request or Configure-Ack, and, if it is present, the Short Sequence Number Header Format option ([2]) MUST NOT also be present. If no instance of this option or the Short Sequence Number Header Format option is present, but an MRRU option [2] is present, then by default, long sequence number multilink headers with class 0 only are used; this is equivalent to code equals 2 and number of suspendable classes equals 1. An instance of the Short Sequence Number Header Format Option is equivalent to an instance of this option with code equals 6 and number of suspendable classes equal to 1.
MultiLink Headerフォーマットオプションは、configure-requestまたはconfigure-ackで1回以上発生してはなりません。存在する場合は、短いシーケンス番号ヘッダー形式（[2]）も存在してはなりません。このオプションのインスタンスまたは短いシーケンス番号ヘッダー形式のフォーマットオプションが存在しないが、MRRUオプション[2]が存在する場合、デフォルトでは、クラス0の長いシーケンス番号マルチリンクヘッダーのみが使用されます。これは、コード2に相当し、一時停止可能なクラスの数に相当します。短いシーケンス番号ヘッダー形式のインスタンスは、このオプションのインスタンスに相当し、コードは6と1に等しい中断可能なクラスの数に相当します。
The number of suspendable classes bounds the allowable class numbers: only class numbers numerically lower than this limit can be used for suspendable classes. Implementations MAY want to negotiate a number smaller than made possible by the packet format to limit their reassembly buffer space requirements. Implementations SHOULD at least support the value 4 for the short sequence number fragment format, and the value 8 for the long sequence number fragment format, unless configured differently. Bit combinations that would indicate class numbers outside the negotiated range MAY be used for other semantics if negotiated by other means outside the scope of this document (e.g., [6]).
中断可能なクラスの数は、許容クラス数を境界します。この制限よりも数値的に低いクラス数のみを一時停止可能なクラスに使用できます。実装は、再組み立てバッファースペース要件を制限するために、パケット形式で可能になったよりも小さい数を交渉することをお勧めします。実装は、少なくとも短いシーケンス番号フラグメント形式の値4と、異なる方法で構成されていない限り、長いシーケンス番号フラグメント形式の値8をサポートする必要があります。交渉範囲外のクラス番号を示すビットの組み合わせは、このドキュメントの範囲外の他の手段によって交渉された場合、他のセマンティクスに使用できます（例：[6]）。
This LCP option advises the peer that, in each of the given classes, the implementation expects to receive only packets with a certain prefix; this prefix is not to be sent as part of the information in the fragment(s) of this class. By default, this common prefix is empty for all classes. When this option is negotiated, the accepting implementation MUST either transmit all subsequent multilink packets of each of the given classes with the given prefix removed from the start of the packet or Configure-Nak or Configure-Reject the option. If none of the formats with classes has been negotiated, class number 0 may be used to indicate a common prefix for all packets sent within multilink fragments.
このLCPオプションは、特定のクラスのそれぞれで、実装が特定のプレフィックスを持つパケットのみを受信することを期待することをピアにアドバイスします。このプレフィックスは、このクラスのフラグメントの情報の一部として送信されません。デフォルトでは、この共通の接頭辞はすべてのクラスに空です。このオプションがネゴシエートされた場合、受け入れた実装は、特定のプレフィックスがパケットの開始から削除された状態で、指定された各クラスのすべての後続のマルチリンクパケットをすべて送信するか、nakを構成するか、オプションを構成します。クラスのある形式が交渉されていない場合、クラス番号0を使用して、マルチリンクフラグメント内で送信されるすべてのパケットの共通のプレフィックスを示すことができます。
Apart from the type and length octets common to all LCP options, the option contains a sequence of zero or more sequences of a single-octet class number, a single-octet length of the prefix for that class, and the octets in that prefix:
すべてのLCPオプションに共通するタイプと長さのオクテットとは別に、オプションには、シングルオクテットクラス番号のゼロ以上のシーケンス、そのクラスのプレフィックスのシングルオクテットの長さ、およびそのプレフィックスのオクテットが含まれます。
Figure 5:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 26 | Option Length | Class | Prefix Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Prefix... | Class |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Prefix Length | Prefix...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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.
接頭辞elisionオプションは、configure-requestまたはconfigure-nakで1回以上発生してはなりません。このオプションが既存のマルチリンクバンドルを結合することを目的としたリンクで提供されている場合、システムは以前にバンドルと交渉された同じプレフィックスエリジョンオプション値を提供する必要があります。
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オプションと同様に、このオプションの感覚は、レシーバーから関係するパケットの送信者への兆候です。多くの場合、このオプションに有用な値を提供できるように、クラスの使用を十分に制御できるのは、送信者だけです。プレフィックスに及ぶパケットを受け入れる意思のある受信者は、空のコンテンツでこのオプションを要求する必要があります。送信者は、Configure-Nakを使用して、希望するクラス間マッピングを提案できます。
Operation of this protocol is believed to be no more and no less secure than operation of the PPP multilink protocol [2].
このプロトコルの動作は、PPPマルチリンクプロトコルの動作よりも安全ではなく、安全ではないと考えられています[2]。
[1] Bormann, C., "Providing Integrated Services over Low-bitrate Links", RFC 2689, September 1999.
[1] Bormann、C。、「低ビトレートリンクを介して統合サービスを提供する」、RFC 2689、1999年9月。
[2] Sklower, K., Lloyd, B., McGregor, G., Carr, D. and T. Coradetti, "The PPP Multilink Protocol (MP)", RFC 1990, August 1996.
[2] Sklower、K.、Lloyd、B.、McGregor、G.、Carr、D。、およびT. Coradetti、「The PPP Multilink Protocol（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。and F. Burg、「Qosppp framing ExtensionsへのPPP」、進行中の作業。
[5] Bormann, C., "PPP in a Real-time Oriented HDLC-like Framing", RFC 2687, September 1999.
[5] Bormann、C。、「リアルタイム指向のHDLCのようなフレーミングのPPP」、RFC 2687、1999年9月。
[6] Simpson, W., Editor, "The Point-to-Point Protocol (PPP)", STD 51, RFC 1661, July 1994.
[6] シンプソン、W。、編集者、「ポイントツーポイントプロトコル（PPP）」、STD 51、RFC 1661、1994年7月。
[7] Simpson, W., Editor, "PPP in HDLC-like Framing", STD 51, RFC 1662, July 1994.
[7] シンプソン、W。、編集者、「HDLCのようなフレーミングのPPP」、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] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
Carsten Bormann Universitaet Bremen FB3 TZI Postfach 330440 D-28334 Bremen, GERMANY
Carsten Bormann Universitaet Bremen FB3 TZI POSTFACH 330440 D-28334ブレーメン、ドイツ
Phone: +49.421.218-7024
Fax: +49.421.218-7000
EMail: cabo@tzi.org
David Oran suggested using PPP Multilink for real-time framing and reminded the author of his earlier attempts of making Multilink more useful for this purpose. The participants in a lunch BOF at the 1996 Montreal IETF gave useful input on the design tradeoffs in various environments. The members of the ISSLL subgroup on low bitrate links (ISSLOW) have helped reducing the large set of options that initial versions of this specification had.
デビッド・オランは、リアルタイムフレーミングにPPPマルチリンクを使用することを提案し、この目的でマルチリンクをより有用にするという彼の以前の試みを著者に思い出させました。1996年のモントリオールIETFのランチBOFの参加者は、さまざまな環境でのデザイントレードオフに関する有用なインプットを提供しました。Low Bitrateリンク（ISSLOW）のISSLLサブグループのメンバーは、この仕様の初期バージョンが持っていたオプションの大規模なセットを減らすのに役立ちました。
Copyright (C) The Internet Society (1999). All Rights Reserved.
Copyright（c）The Internet Society（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エディター機能の資金は現在、インターネット協会によって提供されています。