[要約] RFC 2687は、リアルタイム指向のHDLCライクなフレーミングにおけるPPPに関する規格です。このRFCの目的は、リアルタイムアプリケーションにおける高いパフォーマンスと信頼性を提供するために、PPPフレーミングの改善を行うことです。
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
リアルタイム指向のHDLCのようなフレーミングの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 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.
このドキュメントでは、アーキテクチャのリアルタイムカプセル化フォーマット部分の一時停止/履歴書指向ソリューションを提案します。一般的なアプローチは、PPPマルチリンクフラグメンテーションプロトコル[2]とそのマルチクラス拡張[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 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 kbit/sモデムリンクの1500バイトパケットでリアルタイムのカプセル化形式が必要です。。これにより、最悪の遅延が追加され、リアルタイムの会話には、少なくとも1秒の順序で往復遅延が発生し、往復の遅延で動作します。
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.
真の一時停止/履歴書指向のアプローチは、Type-1 Sender [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].
「必須」、「そうしない」、「必須」、「必要」、「「しない」、「そうでない」、「そうではない」、「そうでない」、「推奨」、「5月」、および「オプション」は、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.
一時停止/履歴書指向のソリューションは、[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および既存のハードウェアおよびファームウェアのインストールとの予測可能性、堅牢性、および協力は、プリフラージャーと同様に、中断/履歴書と同様に重要です。良好な一時停止/履歴書ソリューションは、タイプ2レシーバー[1]でも優れたパフォーマンスを実現し、非同期コンバーターなどの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.
最後に、部分的な非追跡：このドラフトで定義されている形式は、PPPマルチリンクプロトコル（[2]、MPとしても省略）に基づいていますが、多くの場合、複数のリンクを介した動作は必要ありません。
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).
「終了」ビットはマルチリンクヘッダーにあるため、一時停止/履歴書タイプの実装のためのマルチリンクヘッダーの適用性は限られています。大きなパケットを一時停止できるようにするには、「終了」ビットをオフにして送信する必要があります（パケットが終了する前に少数のバイトが停止されていない限り）パケットを「閉じる」ために空のフラグメントをその後送信する必要があります。したがって、サスペンド可能なパケットを送信するための最小オーバーヘッドは、マルチリンクヘッダーサイズの2倍（圧縮マルチリンクプロトコルフィールドを含む6バイト）と1つの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.
単一のリンクで動作する場合、マルチリンクシーケンス番号は、損失検出にのみ使用されます。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 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.
コンパクトなヘッダーを使用して、マルチリンク外にパケットを送信する必要はほとんどないため、この形式に追加の圧縮メカニズムを提供できます。MPプロトコル識別子はコンパクトフラグメントヘッダーで送信されません。これには、明らかに事前の交渉が必要です（アドレスと制御のフィールド圧縮がネゴシエートされる方法と同様）、およびスタートのビット組み合わせ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.)
常に最小のビットを持つことは、HDLCアドレスの最小重要なビットで特別に動作するHDLCチップには、常に1に役立ちます。（ゼロに最小のビットセットを持つ初期バイトは、拡張コンパクトフラグメント形式に使用されます。次のセクションを参照してください。）
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、およびclass = 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は一時停止可能なパケットに使用でき、クラス7から14（クラスフィールドは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.)
拡張コンパクトフラグメント形式では、シーケンス番号は、フラグメントヘッダーの最初のオクテットから3つの最も有意なビットと、2番目のオクテットから7つの最も重要なビットで構成されています。（繰り返しますが、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から14、拡張形式を示してクラス7〜1030を示します。異なるクラスは、問題なく異なる形式を同時に使用できます。（これにより、いくつかのクラスをマルチリンクおよびその他のクラスに広げることができ、効率が向上した単一のリンクに限定されます。）クラスフィールド0〜6、つまり、2つのコンパクトフラグメント形式の1つを一貫して使用する必要があります。各クラス内。
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ビットシーケンス番号のModulo-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ベースのフレーム形式を保持するように設計されています。設計をAsyncのみの操作に最適化できる場合、より多くの設計の代替品が利用可能になることに注意してください[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.
Compact Fragmentフォーマットは、クラスを備えた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が暗黙的に1に設定された電流フラグメントを終了します。これにより、上層層への配達の準備ができているパケットが、タイプ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.) 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.)
FSE検出による一時停止/履歴書形式は、アドレス/制御フィールド圧縮に代わるものです（ACFC、LCPオプション8）。標準のPPP-in-HDLCアドレスフィールドである0xffから始まるフレームには適用されません。これらのフレームは、[6]および[7]で定義されているように処理されます。（この規定により、LCPを再交渉しようとする試みがあいまいさを引き起こさないことが保証されます。）0xffから始まらないフレームの場合、受信したすべてのHDLCフレームのスキャンを一時停止/履歴書処理を実行します。HDLCフレームのFCSがチェックされて剥がされます。コンパクトフラグメントフォーマットヘッダー（基本および拡張の両方）は、さらにFSE処理なしで処理されます。（FSEバイトがCompact Fragment形式のヘッダーで発生しないように選択されたため、特定のコードは必要ありません。）
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）。最終的なフラグメントは終了します（E = 1）、または空の場合、無視されます（つまり、HDLCフレームのデータ部分はFSEで終了して、最後のフラグメントにE = 0のことを示すことができます）。
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に選択された値は0xDEです（これは、今日のデータストリームで発生する比較的ありそうもないバイトであり、Octetの詰め物をトリガーせず、可能な前に可能な1/8のみをビットスタッピングをトリガーします）。
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に設定されたクラスフィールドの組み合わせが予約されています。データの透明性は、FSEバイトの発生に続いて0x8F、0x9F、...から0xffスペシャルの1つを行うことで達成されます。
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:
FSE/0xNF（nは2番目のバイトの最初の4ビットフィールド、図3のRSTU）の組み合わせで、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：1つのfseを挿入し、データに戻ります0x9f：1つのfseを挿入し、2つのデータバイトをコピーし、1つのfseを挿入し、データに戻します0xaf：1つのデータバイトを挿入し、1つのfseを挿入し、データに戻ります0xbf：1つのfseを挿入します、1つのデータバイトをコピーし、2つのfseバイトを挿入し、データ0xcfに戻します：2つのfseバイトを挿入し、データ0xdfに戻します。2つのfseバイトを挿入し、1つのデータバイトをコピーし、1つのfseを挿入し、データに戻ります0xef：3つの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.
このスキームは、FSE処理により最悪のケース拡張係数を約25％に制限します。また、単一のデータストリームが、オクテットの詰め物（またはビットスタッピング）または最悪のFSE処理による最悪のケースの拡張をトリガーできるように設計されていますが、両方とも決してありません。図4は、いくつかの例のスキームを示しています。FSE/0xNFペアは小文字で書かれています。
Figure 4: Data transparency examples
図4：データの透明性の例
Data stream FSE-stuffed stream
データストリームfse stuffedストリーム
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
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).
要約すると、リアルタイムフレーム形式は、フラグによって区切られ、[7]で定義されている最終FCを含むが、アドレスと制御フィールドを含む最終FCを含むHDLCのようなフレームですが、データとしてデータとしてコンパクトフラグメントの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交渉を監視している非同期コンバーターは、MRU値を予想される最大HDLCフレームサイズとして解釈する場合があります。
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フレームのサイズを監視し、空の最終フラグメントを使用してFSEを送信して現在のフラグメントを停止することにより、HDLCフレームサイズを制限する必要があります（すぐに情報フィールドの終わり、つまりCRCバイトが続く必要があります。旗）新しいHDLCフレームを継続できるようにする。この戦略は、HDLCフレームの終わりにある16ビットFCの安全性に対する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処理を実行することです。より高度な実装は、エスケープキャラクター処理の2つのレベルを組み合わせたい場合があります。ただし、FSE処理は、HDLCフレームから2バイトが利用可能になるまで待つ必要があり、3分の1が続くまで、バイトが最終的なHDLC FCSバイトではないことを確認する必要があります。つまり、通常のデータバイトの受信時に、2番目から高度なバイトの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.
このドキュメントでは、MultiLink Headerフォーマットオプションの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.
Multilink Header形式のオプションは[5]で定義されています。Multilink Headerフォーマットオプション形式の概要を以下に示します。フィールドは左から右に送信されます。
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
- Code = 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.
このプロトコルの動作は、PPPマルチリンクプロトコルの動作よりも安全ではなく、安全ではないと考えられています[2]。小さなシーケンス番号範囲で動作すると、異なるパケットからの断片が1つのパケットに誤って再組み立てされる可能性が高くなります。このようなパケットのほとんどは、より高い層のチェックサムの障害またはその他の矛盾のために受信機によって破棄されますが、あるホストに運命づけられたパケットの内容を別のホストに配信できる可能性が高くなります。これがセキュリティの考慮事項を上げる場所でパケットを運ぶリンクは、マルチフラグメントパケットの拡張シーケンス番号範囲を使用する必要があります。
[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., "The Multi-Class Extension to Multi-Link PPP", RFC 2686, September 1999.
[5] Bormann、C。、「マルチリンクPPPへのマルチクラス拡張」、RFC 2686、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
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.
1996年モントリオールIETFのランチBOFの参加者は、さまざまな環境でのデザイントレードオフに有用なインプットを与えました。リチャード・アンドラデス、フレッド・バーグ、ムラリ・アラバムダンは、[5]で定義されている事前に壊れたものに加えて、中断/履歴書の解決策があるべきだと主張した。低ビットレートリンク（ISSLOW）のISSLLサブグループのメンバーは、このソリューションを形作る一連の要件を考案するのに役立ちました。
Full Copyright Statement
完全な著作権声明
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エディター機能の資金は現在、インターネット協会によって提供されています。