Network Working Group C. Bormann
Request for Comments: 2687 Universitaet Bremen TZI
Category: Standards Track September 1999
PPP in a Real-time Oriented HDLC-like Framing
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 suspend/resume-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 its multi-class extension [5] and add suspend/resume in a way that is as compatible to existing hard- and firmware as possible.
この文書では、アーキテクチャのリアルタイムのカプセル化形式部分のサスペンド/レジューム志向のソリューションを提案しています。一般的なアプローチは、[2] PPPマルチリンクフラグメンテーションプロトコルから開始して、そのマルチクラス拡張することである[5]と可能な限り既存のハードおよびファームウェアのような互換性のある方法で、サスペンド/レジューム加えます。
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 suspend/resume-oriented solution for the real-time encapsulation format part of the architecture. 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
本書は、アーキテクチャのリアルタイムのカプセル化形式部分のサスペンド/レジューム志向のソリューションを定義します。アーキテクチャ文書に詳細に記載されているように、リアルタイムのカプセル化フォーマットは、例えば、上の1500バイトのパケットとして必要とされます
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.
28.8キロビット/秒のモデムリンクは、約400ミリ秒のリアルタイム情報の伝送のため、このリンクが使用できなくなります。リアルタイムの会話のために許容できない - これは、少なくとも第二のオーダーの往復遅延で動作するリアルタイムアプリケーションを引き起こし、最悪の場合の遅延が追加されます。
A true suspend/resume-oriented approach can only be implemented on a type-1 sender [1], but provides the best possible delay performance to this type of senders. The format defined in this document may also be of interest to certain type-2-senders that want to exploit the better bit-efficiency of this format as compared to [5]. The format was designed so that it can be implemented by both type-1 and type-2 receivers.
真のサスペンド/レジューム指向のアプローチは、1型送信者[1]に実装されますが、送信者のこのタイプに可能な限り最高の遅延性能を提供することができます。この文書で定義されたフォーマットは、[5]と比較して、この形式のより良好なビット効率を利用する特定の種類-2-送信者に関心のものであってもよいです。それはタイプ1とタイプ2の受信機の両方によって実現することができるようにフォーマットを設計しました。
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 requirements for this document are similar to those listed in [5].
このドキュメントのための要件は、[5]に記載されたものと同様です。
A suspend/resume-oriented solution can provide better worst-case latency than the pre-fragmenting-oriented solution defined in [5]. Also, as this solution requires a new encapsulation scheme, there is an opportunity to provide a slightly more efficient format.
A、サスペンド/レジューム志向のソリューションは、[5]で定義された前の断片化指向のソリューションよりも優れて最悪の場合のレイテンシーを提供することができます。このソリューションは、新しいカプセル化スキームを必要としても、もう少し効率的なフォーマットを提供する機会があります。
Predictability, robustness, and cooperation with PPP and existing hard- and firmware installations are as important with suspend/resume as with pre-fragmenting. A good suspend/resume solution achieves good performance even with type-2 receivers [1] and is able to work with PPP hardware such as async-to-sync converters.
予測可能性、堅牢性、およびPPPと協力し、既存のハードおよびファームウェアのインストールは、事前に断片化と同様に、サスペンド/レジュームと同様に重要です。良好なサスペンド/レジューム溶液[1] 2型受信機であっても良好な性能を達成し、このような非同期に同期コンバータとしてPPPのハードウェアで動作することが可能です。
Finally, a partial non-requirement: While the format defined in this draft is based on the PPP multilink protocol ([2], also abbreviated as MP), operation over multiple links is in many cases not required.
最後に、部分的非要件：この草案で定義されたフォーマットは、（[2]、また、MPと略す）PPPマルチリンクプロトコルに基づいているが、複数のリンクの上の操作は必要としない場合が多いです。
As in [5], the general approach is to start out from PPP multilink and add multiple classes to obtain multiple levels of suspension. However, in contrast to [5], more significant changes are required to be able to suspend the transmission of a packet at any point and inject a higher priority packet.
[5]のように、一般的なアプローチは、PPPマルチリンクから開始し、サスペンションの複数のレベルを得るために、複数のクラスを追加することです。しかし、[5]とは対照的に、より多くの有意な変化は任意の時点でのパケットの送信を一時停止し、優先度の高いパケットを注入することができるように要求されています。
The applicability of the multilink header for suspend/resume type implementations is limited, as the "end" bit is in the multilink header, which is the wrong place for suspend/resume operation. To make a big packet suspendable, it must be sent with the "end" bit off, and (unless the packet was suspended a small number of bytes before its end) an empty fragment has to be sent afterwards to "close" the packet. The minimum overhead for sending a suspendable packet thus is twice the multilink header size (six bytes, including a compressed multilink protocol field) plus one PPP framing (three bytes). Each suspension costs another six bytes (not counting the overhead of the framing for the intervening packet).
ビットは、サスペンド/レジューム動作のために間違った場所でマルチリンクヘッダにある「終了」のようにサスペンド/レジュームタイプの実装のためのマルチリンクヘッダの適用は、制限されています。大きなパケットは、休止にするためには、（パケットがその終了前に少数のバイトを中断した場合を除く）、空のフラグメントを少しオフ、との「終了」を送信しなければならない「クローズ」に後で送信するパケットを持っています。こうして懸濁パケットを送信するための最小のオーバーヘッドは二倍マルチヘッダサイズ（圧縮されたマルチプロトコル・フィールドを含む6バイト）プラスワンPPPフレーミング（3バイト）です。各懸濁液（介在パケットのフレーミングのオーバーヘッドをカウントしない）別の6つのバイトがかかり。
Also, the existing multi-link header is relatively large; as the frequency of small high-priority packets increases, the overhead becomes significant.
また、既存のマルチリンクヘッダは比較的大きいです。小さな高優先度パケットの周波数が高くなるように、オーバーヘッドが大きくなります。
The general approach of this document is to start from PPP Multilink with classes and provide a number of extensions to add functionality and reduce the overhead of using PPP Multilink for real-time transmission.
このドキュメントの一般的なアプローチは、クラスでPPPマルチリンクから開始し、機能を追加し、リアルタイム伝送のためのPPPマルチリンクを使用してのオーバーヘッドを削減するための拡張機能の数を提供することです。
This document introduces two new features:
このドキュメントでは、2つの新機能が導入されています。
1) A compact fragment format and header, and
1）コンパクトな断片形式とヘッダ、および
2) a real-time frame format.
2）リアルタイム・フレーム・フォーマット。
This section describes an optional multilink fragment format that is more optimized towards single-link operation and frequent suspension (type 1 senders)/a small fragment size (type 2 senders), with optional support for multiple links.
このセクションでは、より多くのシングルリンク動作と複数のリンクのための任意のサポートと頻繁懸濁液（タイプ1送信者）/小フラグメントサイズ（タイプ2送信者）に向けて最適化されているオプションのマルチフラグメントフォーマットを記述する。
When operating over a single link, the Multilink sequence number is used only for loss detection. Even a 12-bit sequence number clearly is larger than required for this application on most kinds of links. We therefore define the following compact multilink header format option with a three-bit sequence number.
1つのリンクを介して動作している場合、マルチリンクシーケンス番号は唯一の損失の検出に使用されます。でも、12ビットのシーケンス番号は明らかにリンクのほとんどの種類でこのアプリケーションに必要なよりも大きくなっています。したがって、我々は、3ビットのシーケンス番号を有する次のコンパクトなマルチリンクヘッダフォーマットオプションを定義します。
As, with a compact header, there is little need for sending packets outside the multilink, we can provide an additional compression mechanism for this format: the MP protocol identifier is not sent with the compact fragment header. This obviously requires prior negotiation (similar to the way address and control field compression are negotiated), as well as a method for avoiding the bit combination
、コンパクトヘッダと、マルチリンク外のパケットを送信するためのほとんど必要性があるとして、我々は、このフォーマットのための追加の圧縮機構を提供することができる：MPプロトコル識別子が小型フラグメントヘッダで送信されません。これは明らかに、先行（アドレスおよび制御フィールド圧縮がネゴシエートされている方法に類似）ネゴシエーション、ならびにビットの組み合わせを回避する方法が必要
0xFF (the first octet in an LCP frame before any LCP options have been negotiated), as the start of a new LCP negotiation could otherwise not be reliably detected.
0xFFの（任意のLCPオプションがネゴシエートされる前にLCPフレームの最初のオクテット）、新しいLCPネゴシエーションを開始するようにそうでなければ確実に検出することができませんでした。
Figure 1: Compact Fragment Format
図1：コンパクトな断片形式
0 1 2 3 4 5 6 7
+---+---+---+---+---+---+---+---+
| R | sequence | class | 1 |
+---+---+---+---+---+---+---+---+
| data |
: :
+---+---+---+---+---+---+---+---+
Having the least significant bit always be 1 helps with HDLC chips that operate specially on least significant bits in HDLC addresses. (Initial bytes with the least significant bit set to zero are used for the extended compact fragment format, see next section.)
最下位ビットを有することは常に1であるHDLCアドレスの最下位ビットに特別動作HDLCチップを助けます。 （ゼロに設定最下位ビットと最初のバイトは、次のセクションを参照して、拡張コンパクトな断片形式のために使用されます。）
The R bit is the inverted equivalent of the B bit in the other multilink fragment formats, i.e. R = 1 means that this fragment resumes a packet previous fragments of which have been sent already.
Rビットは、他のマルチフラグメント形式のBビットの反転と等価である、すなわちR = 1は、このフラグメントが既に送信されたパケットの以前のフラグメントを再開することを意味します。
The following trick avoids the case of a header byte of 0xFF (which would mean R=1, sequence=7, and class=7): If the class field is set to 7, the R bit MUST never be set to one. I.e., class 7 frames by design cannot be suspended/resumed. (This is also the reason the sense of the B bit is inverted to an R bit in the compact fragment format -- class 7 would be useless otherwise, as a new packet could never be begun.)
以下のトリックが0xFFのヘッダバイトの場合回避（意味し、R = 1、配列= 7、およびクラス= 7）：クラスフィールドは7に設定されている場合、Rビットが1に設定されてはなりません。すなわち、設計によってクラス7フレームは/中断することができない再開。 （これはまた、Bビットのセンスは、コンパクトな断片形式でRビットに反転される理由である - クラス7新たなパケットが開始されることはありませんでしたように、そうでなければ役に立たないであろう）
As the sequence number is not particularly useful with the class field set to 7, it is used to distinguish eight more classes -- for some minor additional complexity, the applicability of prefix elision is significantly increased by providing more classes with possibly different elided prefixes.
シーケンス番号は7に設定されたクラスのフィールドで特に有効ではないので、8つの以上のクラスを区別するために使用されている - いくつかのマイナーな追加の複雑さのために、接頭辞エリジオンの適用可能性は大幅に異なる可能性が省略さプレフィックスで複数のクラスを提供することにより、増加しています。
For purposes of prefix elision, the actual class number of a fragment is computed as follows:
次のようにプレフィックスエリジオンの目的のために、断片の実際のクラスの数が計算されます。
- If the class field is 0 to 6, the class number is 0 to 6,
- クラスフィールドが0~6である場合、クラス数は、0~6であります
- if the class field is 7 and the sequence field is 0 to 7, the class number is 7 to 14.
- クラスフィールドは7とシーケンスフィールド0〜7である場合は、クラス数が7〜14です。
As a result of this scheme, the classes 0 to 6 can be used for suspendable packets, and classes 7 to 14 (where the class field is 7 and the R bit must always be off) can be used for non-suspendable high-priority classes, e.g., eight highly compressed voice streams.
このスキームの結果として、0〜6は、休止パケットのために使用することができるクラス、および14へのクラス7（クラスフィールドは7であり、Rビットは常にオフしなければならない場合）、非懸濁高優先度のために使用することができますクラス、例えば、8つの高圧縮の音声ストリーム。
For operation over multiple links, a three-bit sequence number will rarely be sufficient. Therefore, we define an optional extended compact fragment format. The option, when negotiated, allows both the basic compact fragment format and the extended compact fragment format to be used; each fragment indicates which format it is in.
複数のリンク上で動作させるには、3ビットのシーケンス番号はめったに十分ではないでしょう。したがって、我々は、オプションの拡張コンパクトな断片形式を定義します。ネゴシエートされたオプションは、基本的なコンパクトな断片形式と使用する拡張コンパクトな断片形式の両方を可能にします。各断片は、それがどのフォーマットを示しています。
Figure 1: Extended Compact Fragment Format
図1：拡張コンパクトな断片形式
0 1 2 3 4 5 6 7
+---+---+---+---+---+---+---+---+
| R | seq LSB | class | 0 |
+---+---+---+---+---+---+---+---+
| sequence -- MSB | 1 |
+---+---+---+---+---+---+---+---+
| data |
: :
+---+---+---+---+---+---+---+---+
In the extended compact fragment format, the sequence number is composed of three least significant bits from the first octet of the fragment header and seven most significant bits from the second octet. (Again, the least significant bit of the second octet is always set to one for compatibility with certain HDLC chips.)
拡張コンパクトな断片形式で、シーケンス番号は、フラグメントヘッダの最初のオクテットと第2オクテットの7つの最上位ビットから最下位3ビットで構成されています。 （ここでも、第2オクテットの最下位ビットは、常に一定のHDLCチップとの互換性のための1つに設定されています。）
For prefix elision purposes, fragments with a class field of 7 can use the basic format to indicate classes 7 to 14 and the extended format to indicate classes 7 to 1030. Different classes may use different formats concurrently without problems. (This allows some classes to be spread over a multi-link and other classes to be confined to a single link with greater efficiency.) For class fields 0 to 6, i.e. suspendable classes, one of the two compact fragment formats SHOULD be used consistently within each class.
プレフィックスエリジオン目的のために、7のクラスフィールドを有する断片は、クラス7 14及び7 1030に対して異なるクラスは問題なく、同時に異なるフォーマットを使用することができるクラスを示すために拡張フォーマットを示すための基本的な形式を使用することができます。 （これはいくつかのクラスは、より高い効率を有する単一のリンクに限定されるマルチリンクと他のクラスの上に広がることを可能にする。）クラスフィールドの場合0〜6、すなわち懸濁クラス二コンパクト断片形式のいずれかを一貫して使用されてください各クラス内。
If the use of the extended compact fragment format has been negotiated, receivers MAY keep 10-bit sequence numbers for all classes to facilitate senders switching formats in a class. When a sender starts sending basic format fragments in a class that was using extended format fragments, the 3-bit sequence number can be taken as a modulo-8 version of the 10-bit sequence number, and no discontinuity need result. In the inverse case, if a 10-bit sequence number has been kept throughout by the receiver (and no major slips of the sequence number have occurred), no discontinuity will result, although this cannot be guaranteed in the presence of errors. (Discontinuity, in this context, means that a receiver has to resynchronize sequence numbers by discarding fragments until a fragment with R=0 has been seen.)
拡張コンパクトな断片形式の使用がネゴシエートされている場合、受信機は、クラスのフォーマットを切り替える送信者を容易にするために、すべてのクラスのための10ビットのシーケンス番号を保持することができます。送信者が拡張フォーマットの断片を用いたクラスの基本的な形式のフラグメントの送信を開始するとき、3ビットのシーケンス番号は10ビットのシーケンス番号のモジュロ8バージョンとすることができる、及び不連続が生じる必要はありません。逆の場合には、10ビットのシーケンス番号が受信機によってを通して維持された場合（シーケンス番号の重大なスリップが発生していない）、これはエラーの存在下では保証できないが、不連続が生じないであろう。 （不連続は、この文脈では、受信機は、R = 0の断片が見されるまでのフラグメントを廃棄することによってシーケンス番号を再同期しなければならないことを意味します。）
This section defines how fragments with compact fragment headers are mapped into real-time frames. This format has been designed to retain the overall HDLC based format of frames, so that existing synchronous HDLC chips and async to sync converters can be used on the link. Note that if the design could be optimized for async only operation, more design alternatives would be available [4]; with the advent of V.80 style modems, asynchronous communications is likely to decrease in importance, though.
このセクションでは、コンパクトな断片ヘッダーとフラグメントはリアルタイムフレームにマッピングされる方法を定義します。コンバータを同期する同期HDLCチップと非同期の既存のリンクを使用することができるように、このフォーマットは、フレームの全体的なHDLCベースのフォーマットを保持するように設計されています。 [4]デザインは非同期動作のみのために最適化することができれば、より多くの設計選択肢が利用可能となることに注意してください。 V.80スタイルのモデムの出現で、非同期通信はしかし、重要性が低下する可能性があります。
The compact fragment format provides a compact rendition of the PPP multilink header with classes and a reduced sequence number space. However, it does not encode the E-bit of the PPP multilink header, which indicates whether the fragment at hand is the last fragment of a packet.
コンパクトな断片形式はクラスとPPPマルチリンクヘッダと縮小シーケンス番号スペースのコンパクトな表現を提供します。しかし、手元フラグメントがパケットの最後のフラグメントであるかどうかを示すPPPマルチリンクヘッダのEビットをコードしません。
For a solution where packets can be suspended at any point in time, the E-bit needs to be encoded near the end of each fragment. The real-time frame format, to ensure maximum compatibility with type 2 receivers, encodes the E-bit in the following way: Any normal frame ending also ends the current fragment with E implicitly set to one. This ensures that packets that are ready for delivery to the upper layers immediately trigger a receive interrupt even at type-2 receivers.
パケットが任意の時点で中断することができるソリューションを、Eビットは、各フラグメントの末端付近に符号化される必要があります。リアルタイムフレームフォーマット、タイプ2の受信機との最大の互換性を確保するために、以下のようにEビットをコードする：任意通常のフレーム終了はまた、暗黙いずれかに設定Eと現行断片を終了します。これは、上位層への送達のために準備ができているパケットは、直ちに2型受信機でも受信割り込みをトリガすることを保証します。
Fragments of packets that are to be suspended are terminated within the HDLC frame by a special "fragment suspend escape" byte (FSE). The overall structure of the HDLC frame does not change; the detection and handling of FSE bytes is done at a layer above HDLC framing.
中断されるパケットのフラグメントは、バイト（FSE）「エスケープを中断フラグメント」特別なことでHDLCフレーム内で終端されています。 HDLCフレームの全体的な構造は変更されません。 FSEバイトの検出と処理は、HDLCフレーミング上の層で行われます。
The suspend/resume format with FSE detection is an alternative to address/control field compression (ACFC, LCP option 8). It does not apply to frames that start with 0xFF, the standard PPP-in-HDLC address field; these frames are handled as defined in [6] and [7]. (This provision ensures that attempts to renegotiate LCP do not cause ambiguities.)
FSE検出とサスペンド/レジューム形式は/制御フィールド圧縮（ACFC、LCPオプション8）に対処するための代替手段です。それは0xFFを、標準のPPP・イン・HDLCアドレスフィールドで始まるフレームには適用されません。で定義されるように、これらのフレームが処理され[6]、[7]。 （この規定は、LCPを再交渉しようとする試みは、あいまいさを引き起こさないことを保証します。）
For frames that do not start with 0xFF, suspend/resume processing performs a scan of every HDLC frame received. The FCS of the HDLC frame is checked and stripped. Compact fragment format headers (both basic and extended) are handled without further FSE processing. (Note that, as the FSE byte was chosen such that it never occurs in compact fragment format headers, this does not require any specific code.)
0xFFで始まらないフレームの場合、サスペンド/レジューム処理は、フレームを受信したすべてのHDLCのスキャンを実行します。 HDLCフレームのFCSをチェックし、削除されます。 （基本および拡張の両方）コンパクト断片形式ヘッダーはさらにFSE処理なしで処理されます。 （FSEバイトが、それはコンパクトな断片形式ヘッダーに発生しない、これは任意の特定のコードを必要としないように選択されたように、ことに注意してください。）
Within the remaining bytes of the HDLC frame ("data part"), an FSE byte is used to indicate the end of the current fragment, with an E bit implicitly cleared. All fragments up to the last FSE are considered suspended (E = 0); the final fragment is terminated (E = 1), or, if it is empty, ignored (i.e., the data part of an HDLC frame can end in an FSE to indicate that the last fragment has E = 0).
HDLCフレーム（「データ部分」）の残りのバイト内に、FSEバイトが暗黙的にクリアEビットと、現行断片の終わりを示すために使用されます。最後FSEへのすべてのフラグメントアップが中断と考えられている（E = 0）;最終的な断片は、それが空である場合、無視され（即ち、HDLCフレームのデータ部分が最後のフラグメントは、E = 0としたことを示すためにFSEに終了することができる）、（E = 1）終了、またはれます。
Each fragment begins with a normal header, so the structure of a frame could be:
各断片は、通常のヘッダで始まるので、フレームの構造は次のようになります。
Figure 2: Example frame with FSE delimiter
図2：FSEデリミタ付き例枠
0 1 2 3 4 5 6 7
+---+---+---+---+---+---+---+---+
| R | sequence | class | 1 |
+---+---+---+---+---+---+---+---+
| data |
: :
+---+---+---+---+---+---+---+---+
+ FSE + previous fragment implicitly E = 0
+---+---+---+---+---+---+---+---+
| R | sequence | class | 1 |
+---+---+---+---+---+---+---+---+
| data |
: :
+---+---+---+---+---+---+---+---+
| Frame | previous fragment implicitly E = 1
| CRC |
+---+---+---+---+---+---+---+---+
The value chosen for FSE is 0xDE (this is a relatively unlikely byte to occur in today's data streams, it does not trigger octet stuffing and triggers bit stuffing only for 1/8 of the possible preceding bytes).
FSEのために選択された値（これは、今日のデータストリームで発生する比較的低いバイトであり、それはオクテットスタッフィングをトリガし、可能な先行バイトの1/8だけスタッフィングビットをトリガしない）0xDEあります。
The remaining problem is that of data transparency. In the scheme described so far, an FSE is always followed by a compact fragment header. In these headers, the combination of a class field set to 7 with R=1 is reserved. Data transparency is achieved by making the occurrence of an FSE byte followed by one of 0x8F, 0x9F, ... to 0xFF special.
残りの問題は、データの透明性の点です。これまでに説明した方式では、FSEは常に小型フラグメントヘッダが続きます。これらのヘッダは、R = 1〜7クラスフィールドセットの組み合わせが予約されています。データの透明性は0x8F、0x9F、...特別の0xFFまでのいずれかが続くFSEバイトの発生を作ることによって達成されます。
Figure 3: Data transparency with FSE bytes present
図3：本FSEバイトとデータの透明性
0 1 2 3 4 5 6 7
+---+---+---+---+---+---+---+---+
| R | sequence | class | 1 |
+---+---+---+---+---+---+---+---+
| data |
: :
+---+---+---+---+---+---+---+---+
+ FSE + fragment NOT terminated
+---+---+---+---+---+---+---+---+
| R | S | T | U | 1 | 1 | 1 | 1 | R always is 1
+---+---+---+---+---+---+---+---+
| data | fragment continues
: :
In a combination of FSE/0xnF (where n is the first four-bit field in the second byte, RSTU in Figure 3), the n field gives a sequence of four bits indicating where in the received data stream FSE bytes, which cannot simply be transmitted in the data stream, are to be added by the receiver:
（nは第二のバイトの最初の4ビットフィールド、図3にRSTUある）FSE / 0xnFの組合せにおいて、N個のフィールドは、FSEバイトをストリーム受信データの示す4ビットのシーケンスを、与えることができない単にデータストリームで送信され、受信機で追加されます。
0x8F: insert one FSE, back to data 0x9F: insert one FSE, copy two data bytes, insert one FSE, back to data 0xAF: insert one FSE, copy one data byte, insert one FSE, back to data 0xBF: insert one FSE, copy one data byte, insert two FSE bytes, back to data 0xCF: insert two FSE bytes, back to data 0xDF: insert two FSE bytes, copy one data byte, insert one FSE, back to data 0xEF: insert three FSE bytes, back to data 0xFF: insert four FSE bytes, back to data
0x8F：バックデータ0x9Fに、1 FSEを挿入します。バックデータ0xAFに、1 FSEを挿入する二つのデータバイトをコピーし、1 FSEを挿入します。バックデータ0xbfのに、1 FSEを挿入1つのデータバイトをコピーし、1 FSEを挿入：1 FSEを挿入、1バイトのデータコピー、データバック0xCFに、2つのFSEバイトを挿入します。バックデータ0xDFに、2つのFSEバイトを挿入します、3つのFSEバイトを挿入します、2つのFSEバイトを挿入する1バイトのデータをコピーし、バックデータ0xEFというに、1 FSEを挿入バックデータは0xFFへ：データに戻し、4つのFSEバイトを挿入
The data bytes following the FSE/0xnF combinations and corresponding to the zero bits in the N field may not be FSE bytes.
FSE / 0xnFの組み合わせを、以下およびNフィールドのゼロ・ビットに対応するデータバイトは、FSEバイトでなくてもよいです。
This scheme limits the worst case expansion factor by FSE processing to about 25 %. Also, it is designed such that a single data stream can either trigger worst-case expansion by octet stuffing (or by bit stuffing) or worst-case FSE processing, but never both. Figure 4 illustrates the scheme in a few examples; FSE/0xnF pairs are written in lower case.
この方式は約25％にFSE処理による最悪の場合の拡張係数を制限します。また、それは、単一のデータストリームはオクテットスタッフィング（またはビットスタッフィングによって）最悪の場合の拡張または最悪の場合のFSE処理をトリガしないが、決して両方ができるいずれかのように設計されています。図4は、いくつかの例でスキームを示す図です。 FSE / 0xnF対は小文字で書かれています。
Figure 4: Data transparency examples
図4：データの透明例
Data stream FSE-stuffed stream
データ・ストリーム・FSE-詰めストリーム
DD DE DF E0 DD de 8f DF E0 01 DE 02 DE 03 01 de af 02 03 DE DA DE DE DB de bf DA DB DE DE DE DE DE DA de ff de 8f DA
DD DD 8F DF DF E0 E0 01 02 03 01 AF 2：03 DA DE DA DB DBのBF DE DE DE DA DA FF 8F
In summary, the real-time frame format is a HDLC-like frame delimited by flags and containing a final FCS as defined in [7], but without address and control fields, containing as data a sequence of FSE-stuffed fragments in compact fragment format, delimited by FSE bytes. As a special case, the final FSE may occur as the last byte of the data content (i.e. immediately before the FCS bytes) of the HDLC-like frame, to indicate that the last fragment in the frame is suspended and no final fragment is in the frame (e.g., because the desirable maximum size of the frame has been reached).
要約すると、リアルタイム・フレーム・フォーマットは、フラグで区切らHDLC状のフレームであり、で定義されるように、最終FCSを含有する[7]が、アドレスおよび制御フィールドせず、データとしてコンパクト断片でFSE-詰め断片の配列を含みますFSEバイトで区切られた形式で、。特殊なケースとして、最終的なFSEは、フレーム内の最後のフラグメントを懸濁しない最終の断片が入っているれていないことを示すために、HDLC様のフレームのデータ内容（すなわち、直ちにFCSバイト前）の最後のバイトとして生じますフレーム（例えば、フレームの望ましい最大サイズに達したため）。
The LCP parameter MRU defines the maximum size of the packets sent on the link. Async-to-sync converters that are monitoring the LCP negotiations on the link may interpret the MRU value as the maximum HDLC frame size to be expected.
LCPパラメータMRUは、リンク上で送信されるパケットの最大サイズを定義します。リンク上でLCPネゴシエーションを監視している非同期に同期変換器は、予想される最大のHDLCフレームサイズとしてMRU値を解釈することができます。
Implementations of this specification should preferably negotiate a sufficiently large MRU to cover the worst-case 25 % increase in frame size plus the increase caused by suspended fragments. If that is not possible, the HDLC frame size should be limited by monitoring the HDLC frame sizes and possibly suspending the current fragment by sending an FSE with an empty final fragment (FSE immediately followed by the end of the information field, i.e. by CRC bytes and a flag) to be able to continue in a new HDLC frame. This strategy also helps minimizing the impact of lengthening the HDLC frame on the safety of the 16-bit FCS at the end of the HDLC frame.
この仕様の実装は、好ましくは、フレームサイズの最悪の場合の25％の増加に加えて懸濁断片によって引き起こされる増加をカバーするために十分に大きなMRUを交渉しなければなりません。それが不可能な場合、HDLCフレームサイズは、HDLCフレームのサイズを監視し、空の場合も、最終的な断片とFSEを送信することによって、現行断片を懸濁することによって限定されるべきである（FSE直ちに情報フィールドの終了に続いて、CRCのバイト、すなわちそして、新たなHDLCフレームに続けることができるようにするためのフラグ）。この戦略はまた、HDLCフレームの終了時に16ビットのFCSの安全上のHDLCフレームを長くの影響を最小限に抑えるのに役立ちます。
The simplest way to add real-time framing to an implementation may be to perform HDLC processing as usual and then, on the result, to perform FSE processing. A more advanced implementation may want to combine the two levels of escape character processing. Note, however, that FSE processing needs to wait until two bytes from the HDLC frame are available and followed by a third to ensure that the bytes are not the final HDLC FCS bytes, which are not subject to FSE processing. I.e., on the reception of normal data byte, look for an FSE in the second-to-previous byte, and, on the reception of a frame-end, look for an FSE as the last data byte.
実装にリアルタイムフレーミングを追加する最も簡単な方法は、いつものようにHDLC処理を実行するために、次に、その結果に、FSEの処理を実行することであってもよいです。より高度な実装では、エスケープ文字の処理の二つのレベルを結合することもできます。 FSE処理はHDLCフレームから2つのバイトが使用可能であり、バイトFSE処理の対象とならない最終HDLC FCSバイト、されないことを保証するために、第三の続くされるまで待機する必要があること、しかし、注意してください。すなわち、通常のデータバイトの受信時に、第二の対前バイトにFSEを探し、そして、フレームエンドの受信時に、最後のデータ・バイトとしてFSEを探し。
The following options are already defined by MP [2]:
次のオプションは、すでにMP [2]で定義されています。
o Multilink Maximum Received Reconstructed Unit
Oマルチリンクの最大は、再構成ユニットを受信します
o Multilink Short Sequence Number Header Format
Oマルチショートシーケンス番号ヘッダー形式
o Endpoint Discriminator
Oエンドポイント識別子
The following options are already defined by MCML [5]:
次のオプションは、すでにMCML [5]で定義されています。
o Multilink Header Format
Oマルチリンクヘッダー形式
o Prefix Elision
Oプレフィックスエリジオン
This document defines two new code points for the Multilink Header Format option.
この文書では、マルチリンクヘッダー形式オプションのための2つの新しいコード・ポイントを定義します。
The multilink header format option is defined in [5]. A summary of the Multilink Header Format Option format is shown below. The fields are transmitted from left to right.
マルチリンクヘッダフォーマットオプションが[5]で定義されています。マルチリンクヘッダーフォーマットオプションフォーマットの概要は以下の通りです。フィールドは左から右に送信されます。
Figure 5: Multilink header format option
図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 = 27 | Length = 4 | Code | # Susp Clses |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
As defined in [5], 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. This specification defines two additional values for Code, in addition to those defined in [5]:
で定義されている[5]、このLCPオプションが与えられた（下記参照）の実装は、懸濁クラスの最大数と、コード番号によって指定された形式でフラグメントを受信することを望むピアに助言します。この仕様は、[5]で定義されたものに加えて、コードのための2つの追加の値を定義します。
- Code = 11: basic and extended compact real-time fragment format with classes, in FSE-encoded HDLC frame
- コード= 11：FSEエンコードHDLCフレームのクラスと基本および拡張コンパクトリアルタイム断片形式
- Code = 15: basic compact real-time fragment format with classes, in FSE-encoded HDLC frame
- コード= 15：FSEエンコードHDLCフレームのクラスの基本的なコンパクトなリアルタイム断片形式
An implementation MUST NOT request a combination of both LCP Address-and-Control-Field-Compression (ACFC) and the code values 11 or 15 for this option.
実装はLCPアドレス・アンド・コントロール・フィールド圧縮（ACFC）の両方の組み合わせを要求してはいけません、コードは、このオプションに11又は15値。
The number of suspendable classes negotiated for the compact real-time fragment format only limits the use of class numbers that allow suspending. As class numbers of 7 and higher do not require additional reassembly space, they are not subject to the class number limit negotiated.
コンパクトなリアルタイムフラグメント形式のために交渉懸濁クラスの数は、懸濁可能クラス番号の使用を制限します。 7以上のクラス番号は、追加の再組み立てスペースを必要としないので、彼らが交渉されたクラス数の制限の対象にはなりません。
Operation of this protocol is believed to be no more and no less secure than operation of the PPP multilink protocol [2]. Operation with a small sequence number range increases the likelihood that fragments from different packets could be incorrectly reassembled into one packet. While most such packets will be discarded by the receiver because of higher-layer checksum failures or other inconsistencies, there is an increase in likelihood that contents of packets destined for one host could be delivered to another host. Links that carry packets where this raises security considerations SHOULD use the extended sequence number range for multi-fragment packets.
このプロトコルの動作は、[2]のそれ以上とPPPマルチリンクプロトコルの動作を下回らない安全でないと考えられています。小さいシーケンス番号範囲の動作が異なるパケットからフラグメントが誤って1つのパケットに再組み立てすることができる可能性を高めます。もっとも、このようなパケットがあるため、より高い層のチェックサム障害または他の不整合の受信機によって廃棄されるが、一つのホスト宛てのパケットの内容が別のホストに配信することができる可能性が増大します。これはセキュリティ問題を提起したパケットを運ぶリンクはマルチフラグメントパケットの拡張シーケンス番号の範囲を使用すべきです。
[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., "The Multi-Class Extension to Multi-Link PPP", RFC 2686, September 1999.
[5]ボルマン、C.、RFC 2686 "マルチリンクPPPへのマルチクラス拡張"、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
Acknowledgements
謝辞
The participants in a lunch BOF at the Montreal IETF 1996 gave useful input on the design tradeoffs in various environments. Richard Andrades, Fred Burg, and Murali Aravamudan insisted that there should be a suspend/resume solution in addition to the pre-fragmenting one defined in [5]. The members of the ISSLL subgroup on low bitrate links (ISSLOW) have helped in coming up with a set of requirements that shaped this solution.
モントリオールIETF 1996で昼食のBOFの参加者は、様々な環境での設計上のトレードオフに便利な入力を与えました。リチャードAndrades、フレッド・ブルグ、及びミュラリ・アラバムーダン[5]で定義されたプリ断片ものに加えて、サスペンド/レジューム溶液が存在すべきであると主張しました。低ビットレートのリンク（ISSLOW）のISSLLサブグループのメンバーは、このソリューションを形要件のセットを考え出すに役立っています。
Full Copyright Statement
完全な著作権声明
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機能のための基金は現在、インターネット協会によって提供されます。