RFC1967 日本語訳
1967 PPP LZS-DCP Compression Protocol (LZS-DCP). K. Schneider, R.Friend. August 1996. (Format: TXT=40039 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group K. Schneider
Request for Comments: 1967 ADTRAN, Inc.
Category: Informational R. Friend
Stac Technology
August 1996
コメントを求めるワーキンググループK.シュナイダーの要求をネットワークでつないでください: 1967年のADTRAN Inc.カテゴリ: 情報のR.友人Stac技術1996年8月
PPP LZS-DCP Compression Protocol (LZS-DCP)
ppp LZS-DCP圧縮プロトコル(LZS-DCP)
Status of This Memo
このメモの状態
This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのための情報を提供します。 このメモはどんな種類のインターネット標準も指定しません。 このメモの分配は無制限です。
Abstract
要約
The Point-to-Point Protocol (PPP) [1] provides a standard method for transporting multi-protocol datagrams over point-to-point links.
Pointからポイントへのプロトコル(PPP)[1]はポイントツーポイント接続の上でマルチプロトコルデータグラムを輸送するための標準方法を提供します。
The PPP Compression Control Protocol [2] provides a method to negotiate and utilize compression protocols over PPP encapsulated links.
PPP Compression Controlプロトコル[2]はリンクであるとカプセル化されたPPPの上で圧縮プロトコルを交渉して、利用するメソッドを提供します。
This document describes the use of the Stac LZS data compression algorithm for compressing PPP encapsulated packets, using a DCP header [6]. This protocol is an enhanced version of the non-DCP (Option 17) PPP Stac LZS compression protocol [5], and will be referred to as the LZS-DCP Compression Protocol.
このドキュメントはStac LZSデータ圧縮アルゴリズムのパケットであるとカプセル化されたPPPを圧縮する使用について説明します、DCPヘッダー[6]を使用して。 このプロトコルは、非DCP(オプション17)PPP Stac LZS圧縮プロトコル[5]の高められたバージョンであり、LZS-DCP Compressionプロトコルと呼ばれるでしょう。
Table of Contents
目次
1. Introduction .......................................... 2
1.1 Licensing ....................................... 3
1.2 Specification of Requirements ................... 3
1.3 Terminology ..................................... 3
2. LZS-DCP Packets ....................................... 4
2.1 Example LZS-DCP Packets ......................... 5
2.2 Padding ......................................... 6
2.3 Reliabliity and Squencing ....................... 6
2.4 Data Expansion .................................. 6
2.5 Packet Format ................................... 7
2.5.1 PPP Protocol .................................... 7
2.5.2 DCP-Header ...................................... 8
2.5.3 History Number .................................. 9
2.5.4 Sequence Number ................................. 9
2.5.5 Data ............................................ 10
2.5.6 Longitudinal Check Byte ......................... 10
1. 序論… 2 1.1 認可します。 3 1.2 要件の仕様… 3 1.3用語… 3 2. LZS-DCPパケット… 4 2.1 例のLZS-DCPパケット… 5 2.2 そっと歩きます… 6 2.3のReliabliityとSquencing… 6 2.4 データ拡張… 6 2.5 パケット形式… 7 2.5 .1 pppプロトコル… 7 2.5 .2DCP-ヘッダー… 8 2.5 .3 歴史番号… 9 2.5 .4一連番号… 9 2.5 .5のデータ… 10 2.5 縦の.6チェックバイト… 10
Schneider & Friend Informational [Page 1] RFC 1967 LZS-DCP August 1996
シュナイダーと[1ページ]友人の情報のRFC1967LZS-DCP1996年8月
2.5.7 Compressed Data ................................. 11
3. Sending Compressed Datagrams ..................... 11
3.1 Transmitter Process ............................. 11
3.2 Receiver Process ................................ 12
3.3 History Maintenance ............................. 13
3.4 Anti-Expansion Mechanism ........................ 14
3.5 History Resynchronization Mechanism ............. 14
4. Configuration Option Format ........................... 15
SECURITY CONSIDERATIONS ...................................... 16
REFERENCES ................................................... 17
CHAIR'S ADDRESS .............................................. 17
AUTHORS' ADDRESSES ........................................... 18
2.5.7 圧縮されたデータ… 11 3. 発信はデータグラムを圧縮しました… 11 3.1送信機プロセス… 11 3.2受信機プロセス… 12 3.3 歴史メインテナンス… 13 3.4反拡張メカニズム… 14 3.5歴史Resynchronizationメカニズム… 14 4. 設定オプション形式… 15 セキュリティ問題… 16の参照箇所… 17 議長のアドレス… 17人の作者のアドレス… 18
1. Introduction
1. 序論
Starting with a sliding window compression history, similar to LZ1 [3], Stac Electronics developed a compression algorithm identified as Stac LZS. A PPP Compression Protocol for this compression algorithm was developed and published [5]. That protocol was taken as a basis for data compression work done in TIA for DSU/CSUs. As a part of that standardization process, the concept of a portable Data Compression Protocol (DCP) was introduced [6]. The resulting (pending) TIA/EIA-655 standard uses this LZS-DCP protocol, which ncorporates DCP into a PPP compression protocol for Stac LZS. A very similar protocol is currently out for ballot in the Frame Relay Forum. (It is identical except for the size of the history number field.)
引窓圧縮歴史からの始め、LZ1[3]と同様です、Stac ElectronicsはStac LZSとして特定された圧縮アルゴリズムを開発しました。 この圧縮アルゴリズムのためのPPP Compressionプロトコルは、開発されて、[5]を発行しました。 そのプロトコルはDSU/CSUsのためにTIAで行われたデータ圧縮仕事の基礎としてみなされました。 その標準化過程の一部として、携帯用のData Compressionプロトコル(DCP)の概念は紹介されました。[6]。 結果として起こる(未定の)TIA/EIA-655規格はこのLZS-DCPプロトコルを使用して、PPPへのどのncorporates DCPがStac LZSのための圧縮プロトコルであるか。 非常に同様のプロトコルは現在、投票のためにFrame Relay Forumにあります。 (歴史ナンバーフィールドのサイズを除いて、それは同じです。)
This publication of the LZS-DCP compression protocol is in the interest of providing a common compression protocol for Stac-LZS, and to provide features that are not available with the LZS compression protocol [5]. Some of the differences between the LZS-DCP and LZS (compression type 17) protocols are as follows:
LZS-DCP圧縮プロトコルのこの公表は、一般的な圧縮プロトコルをStac-LZSに供給することのために、LZS圧縮プロトコル[5]を利用可能でない特徴に提供することです。 LZS-DCPとLZS(圧縮タイプ17)プロトコルの違いのいくつかは以下の通りです:
1) LZS-DCP provides an option which allows packets containing
uncompressible data to be transferred without requiring the
compression history to be cleared, potentially allowing a
higher compression ratio. A bit is included in the DCP
header to indicate whether the packet contains compressed or
uncompressed data.
1) LZS-DCPは圧縮歴史がクリアされる必要でないuncompressibleデータを含むパケットが移されるのを許容するオプションを提供します、潜在的により高い圧縮比を許容して。 パケットが圧縮されたか解凍されたデータを含むかどうかを示すためにDCPヘッダーに少し含まれています。
2) LZS-DCP uses reset request and acknowledgment bits in the DCP
header that is included on each packet rather than using
CCP's reset request and acknowledge packets, which may result
in fewer discarded data packets during the REQ/ACK handshake.
2) LZS-DCP用途は要求をリセットしました、そして、CCPのものが要求をリセットして、結果として生じるかもしれないパケットを承認する使用よりむしろ各パケットの上に含まれているDCPヘッダーの承認ビットはREQ/ACK握手の間、データ・パケットを捨てませんでした。
3) LZS-DCP allows simultaneous use of both sequence numbers and
the LCB for compression error detection.
3) LZS-DCPは一連番号とLCBの両方の圧縮誤り検出の同時の使用を許します。
Schneider & Friend Informational [Page 2] RFC 1967 LZS-DCP August 1996
シュナイダーと[2ページ]友人の情報のRFC1967LZS-DCP1996年8月
The Stac LZS compression algorithm supports both single and multiple compression histories. A single compression history will require the minimum amount of memory to implement, but may not provide as much compression as a multiple history implementation.
Stac LZS圧縮アルゴリズムは、ともに単一で複数の圧縮が歴史であるとサポートします。 ただ一つの圧縮歴史は、実装するメモリの最小の量を必要としますが、複数の歴史実装と同じくらい多くの圧縮を提供しないかもしれません。
Often, many streams of information are interleaved over the same physical link. Each virtual connection will transmit data that is independent of other virtual connections. Using multiple compression histories can improve the compression ratio of a communication link by associating separate compression histories with separate virtual links of communication.
しばしば、情報の多くのストリームが同じ物理的なリンクの上にはさみ込まれます。 各仮想接続は他の仮想接続から独立しているデータを送るでしょう。 複数の圧縮歴史を費やすと、コミュニケーションの別々の仮想のリンクに別々の圧縮歴史を関連づけることによって、通信リンクの圧縮比を改良できます。
1.1. Licensing
1.1. 認可
Source and object licenses are available on a non-discriminatory basis. Hardware implementations are also available. Contact Stac Electronics (hardware.sales@stac.com) for further information.
ソースとオブジェクトライセンスは非差別しているベースで手があいています。 また、ハードウェア実装も利用可能です。 詳細のために、Stac Electronics( hardware.sales@stac.com )に連絡してください。
1.2. Specification of Requirements
1.2. 要件の仕様
In this document, several words are used to signify the requirements of the specification. These words are often capitalized.
本書では、いくつかの単語が、仕様の要件を意味するのに使用されます。 これらの単語はしばしば大文字で書かれます。
MUST This word, or the adjective "required", means that the
definition is an absolute requirement of the specification.
「必要である」というThis単語、または形容詞が、定義が仕様に関する絶対条件であることを意味しなければなりません。
MUST NOT This phrase means that the definition is an absolute
prohibition of the specification.
Thisは定義がある手段を言葉で表してはいけません。仕様の絶対禁止。
SHOULD This word, or the adjective "recommended", means that there
may exist valid reasons in particular circumstances to
ignore this item, but the full implications MUST be
understood and carefully weighed before choosing a
different course.
「推薦される」というSHOULD This単語、または形容詞が、この項目を無視する特定の事情の正当な理由が存在するかもしれないことを意味しますが、完全な含意を理解されて、異なったコースを選ぶ前に、慎重に熟慮しなければなりません。
MAY This word, or the adjective "optional", means that this
item is one of an allowed set of alternatives. An
implementation which does not include this option MUST be
prepared to interoperate with another implementation which
does include the option.
5月のThis単語、または「任意である」という形容詞が、この項目が許容セットの代替手段の1つであることを意味します。 オプションを含んでいる別の実装で共同利用するようにこのオプションを含んでいない実装を準備しなければなりません。
1.3. Terminology
1.3. 用語
This document frequently uses the following terms:
このドキュメントは頻繁に次の用語を使用します:
datagram The unit of transmission in the network layer (such as IP).
A datagram may be encapsulated in one or more packets
passed to the data link layer.
データグラム、ネットワーク層(IPなどの)における、トランスミッションのユニット。 データグラムはデータ・リンク層に通過された1つ以上のパケットでカプセル化されるかもしれません。
Schneider & Friend Informational [Page 3] RFC 1967 LZS-DCP August 1996
シュナイダーと[3ページ]友人の情報のRFC1967LZS-DCP1996年8月
frame The unit of transmission at the data link layer. A frame
may include a header and/or a trailer, along with some
number of units of data.
データ・リンク層でトランスミッションのユニットを縁どってください。 フレームは何らかの数のユニットのデータに伴うヘッダー、そして/または、トレーラを含むかもしれません。
packet The basic unit of encapsulation, which is passed across the
interface between the network layer and the data link
layer. A packet is usually mapped to a frame; the
exceptions are when data link layer fragmentation is being
performed, or when multiple packets are incorporated into a
single frame.
パケットはカプセル化(ネットワーク層とデータ・リンク層とのインタフェースの向こう側に通過されるもの)の原単位です。 通常、パケットはフレームに写像されます。 例外はデータ・リンク層断片化がいつ実行されているか、そして、または複数のパケットがいつシングルフレームに法人組織であるかということです。
peer The other end of the point-to-point link.
他が終わらせるポイントツーポイント接続の同輩。
silently discard
静かに捨ててください。
This means the implementation discards the packet without
further processing. The implementation SHOULD provide the
capability of logging the error, including the contents of
the silently discarded packet, and SHOULD record the event
in a statistics counter.
これは、実装がさらなる処理なしでパケットを捨てることを意味します。 実装SHOULDは静かに捨てられたパケットのコンテンツを含む誤りを登録する能力を提供します、そして、SHOULDは統計カウンタに出来事を記録に残します。
2. LZS-DCP Packets
2. LZS-DCPパケット
Before any LZS-DCP packets are communicated, PPP MUST reach the Network-Layer Protocol phase, and the CCP Control Protocol MUST reach the Opened state.
どんなLZS-DCPパケットも伝えられる前に、PPP MUSTはNetwork-層のプロトコルフェーズに達します、そして、CCP ControlプロトコルはOpened状態に達しなければなりません。
Exactly one LZS-DCP datagram is encapsulated in the PPP Information field, where the PPP Protocol field indicates type hex 00FD (compressed datagram) or type hex 00FB (Individual link compressed datagram). Type hex 00FD is used when compression is negotiated over a single physical link or when compression is negotiated over a single bundle consisting of multiple physical links. Type hex 00FB is used when compression is negotiated separately over individual physical links to the same destination. For more information, please refer to PPP Compression Control Protocol.
ちょうど1個のLZS-DCPデータグラムがPPP情報分野でカプセル化されます。そこで、PPPプロトコル分野はタイプ十六進法00FD(圧縮されたデータグラム)かタイプ十六進法00FBを示します(個々のリンクはデータグラムを圧縮しました)。 圧縮が単一の物理的なリンクの上に交渉されるか、または圧縮が複数の物理的なリンクから成りながらただ一つのバンドルの上で交渉されるとき、タイプ十六進法00FDは使用されています。 圧縮が別々に同じ目的地への個々の物理的なリンクの上に交渉されるとき、タイプ十六進法00FBは使用されています。 詳しくは、PPP Compression Controlプロトコルを参照してください。
The maximum length of the LZS-DCP datagram transmitted over a PPP link is the same as the maximum length of the Information field of a PPP encapsulated packet.
PPPリンクの上に送られたLZS-DCPデータグラムの最大の長さはPPPの情報分野の最大の長さがパケットをカプセルに入れったのと同じです。
Prior to compression, the uncompressed data begins with the PPP Protocol ID Field. Protocol-Field-Compression MAY be used on this value, if has been successfully negotiated for the link.
圧縮の前に、解凍されたデータはPPPプロトコルID Fieldと共に始まります。 プロトコル分野圧縮がこの値で使用されるかもしれない、首尾よくリンクと交渉されました。
The PPP Protocol ID Field is followed by the original Information field. The length of the uncompressed data field is limited only by the allowed size of the compressed data field and the higher protocol
元の情報分野はPPPプロトコルID Fieldのあとに続いています。 解凍されたデータ・フィールドの長さは圧縮されたデータ・フィールドと、より高いプロトコルの許容サイズだけによって制限されます。
Schneider & Friend Informational [Page 4] RFC 1967 LZS-DCP August 1996
シュナイダーと[4ページ]友人の情報のRFC1967LZS-DCP1996年8月
layers.
層。
PPP Link Control Protocol packets MUST NOT be sent within LZS-DCP packets. PPP Network Control Protocol packets MUST NOT be sent within LZS-DCP packets.
LZS-DCPパケットの中でPPP Link Controlプロトコルパケットを送ってはいけません。 LZS-DCPパケットの中でPPP Network Controlプロトコルパケットを送ってはいけません。
2.1. Example LZS-DCP packets (shown using PPP in HDLC-like framing,
using Address-and-Control-Field-Compression and Protocol-Field-
Compression. - RFC 1662 )
2.1. 例のLZS-DCPパケット(HDLCのような縁どり、Addressとコントロール分野圧縮を使用して、およびプロトコル分野圧縮にPPPを使用するのが示されます。 - RFC1662)
Compressed Packet:
パケットを圧縮します:
PPP | | PPP
PID | HDR SEQ DATA LCB | FCS
+-----+-----+-----+---................---+-----+-----+
| F D | C 0 | n n | Compressed Data | y y | z z |
+-----+-----+-----+---................---+-----+-----+
/ \
/ Compression \
/ Transformation \
/ \
/PPP \
/ PID PPP Information Field \
+-----+----....................----+
| x x | upper layer protocol data |
+-----+----....................----+
ppp| | ppp PID| HDR SEQデータLCB| FCS+-----+-----+-----+---................---+-----+-----+ | F D| C0| n n| 圧縮されたデータ| y y| z z| +-----+-----+-----+---................---+-----+-----+/\/圧縮\/変換\/\/ppp\/PID ppp情報フィールド\+-----+----....................----+ | x x| 上側の層のプロトコルデータ| +-----+----....................----+
Uncompressed Packet
解凍されたパケット
PPP | | PPP
PID | HDR SEQ DATA | FCS
+-----+-----+-----+---................---+-----+
| F D | 8 0 | n n | Un-compressed Data | z z |
+-----+-----+-----+---................---+-----+
/ \
/ \
/ \
/ \
/PPP \
/ PID PPP Information Field \
+-----+----....................----+
| x x | upper layer protocol data |
+-----+----....................----+
ppp| | ppp PID| HDR SEQデータ| FCS+-----+-----+-----+---................---+-----+ | F D| 8 0 | n n| 解凍されたデータ| z z| +-----+-----+-----+---................---+-----+/\/\/\/\/ppp\/PID ppp情報フィールド\+-----+----....................----+ | x x| 上側の層のプロトコルデータ| +-----+----....................----+
where: C0 and 80 are representative LZS-DCP headers; nn, xx, yy,
and zz are values determined by the packet's context.
どこ: C0と80は代表しているLZS-DCPヘッダーです。 nn、xx、yy、およびzzはパケットの文脈で決定している値です。
Schneider & Friend Informational [Page 5] RFC 1967 LZS-DCP August 1996
シュナイダーと[5ページ]友人の情報のRFC1967LZS-DCP1996年8月
2.2. Padding
2.2. 詰め物
PPP padding is not allowed in a LZS-DCP packet. However, on
compressed packets, padding may be accomplished by extending the
data field with zeros following the last compressed data octet
(see Section 2.1.1). This is referred to as LZS Padding. The
LCB, if present, MUST be the octet preceding the frame CRC.
PPP詰め物はLZS-DCPパケットに許容されていません。 しかしながら、圧縮されたパケットの上でそっと歩くのは、最後に圧縮されたデータ八重奏に続いて、ゼロでデータ・フィールドを広げることによって、達成されるかもしれません(セクション2.1.1を見てください)。 これはLZS Paddingと呼ばれます。 存在しているなら、LCBはフレームCRCに先行する八重奏であるに違いありません。
2.3. Reliability and Sequencing
2.3. 信頼性と配列
When no Compression History is kept, the algorithm does not depend
on a reliable link, and does not require that packets be delivered
in sequence. However, per packet compression results in a lower
compression ratio than it could be on a stream.
Compression歴史が全く保管されないとき、アルゴリズムは、信頼できるリンクによらないで、またパケットが連続して提供されるのを必要としません。 しかしながら、パケット圧縮に従って、それより低圧縮比における結果がストリームにあるかもしれません。
Some reasons for clearing the history on a per packet basis
include:
パケット基礎あたりのaに関する歴史をクリアするいくつかの理由は:
- The link has a high error rate.
- The resources of the transmitter or receiver limit the ability
to maintain a compression history between packets.
- リンクには、高い誤り率があります。 - 送信機か受信機に関するリソースはパケットの間の圧縮歴史を維持する能力を制限します。
When one or more compression Histories are negotiated, the packet
sequence MUST be preserved within specific History Numbers. There
is no sequence requirement between different History Numbers.
1つ以上の圧縮歴史が交渉されるとき、特定の歴史民数記の中にパケット系列を保存しなければなりません。 異なった歴史民数記の間には、系列要件が全くありません。
When using one or more compression histories, the implementation
MUST rely on either a lower layer reliable link protocol (RFC
1663), use a technique to keep the compressor and decompressor
histories in synchronization, or both. The LZS-DCP protocol
provides the Request-Req and Request-Ack bits in the DCP header
for this purpose. Since this synchronization is done on a per
history basis, the history number fields are required to be the
same size in both directions of the link. Any data contained in
the packet is processed after the signaling bits are processed.
1つ以上の圧縮歴史を費やすとき、実装は下層の信頼できるリンク・プロトコル(RFC1663)を当てにしなければならなくて、使用は同期、または両方にコンプレッサーと減圧装置が歴史であることを保つテクニックです。 LZS-DCPプロトコルはこのためにDCPヘッダーのビットをRequest-ReqとRequest-Ackに供給します。 歴史基礎あたりのaでこの同期をするので、歴史ナンバーフィールドがリンクの両方の方向への同じサイズになるのに必要です。 シグナリングビットが処理された後にパケットに含まれたどんなデータも処理されます。
The transmitter MAY clear a Compression History at any time.
送信機はいつでも、Compression歴史をクリアするかもしれません。
The transmitter MUST clear a history after a receiving a Reset-
Request for a given History Number.
送信機はResetが与えられた歴史Numberのために要求する受信の後に歴史をクリアしなければなりません。
2.4. Data Expansion
2.4. データ展開
The maximum expansion of Stac LZS is 12.5%.
Stac LZSの最大の拡張は12.5%です。
A Maximum Receive Unit (MRU) MAY be negotiated that is 12.5%
larger than the size of a normal packet. Then, packets can always
be sent compressed regardless of expansion.
Maximum Receive Unit(MRU)による交渉されて、それが正常なパケットのサイズより12.5%大きいということであるかもしれません。 そして、いつも拡張にかかわらず圧縮されていた状態でパケットを送ることができます。
Schneider & Friend Informational [Page 6] RFC 1967 LZS-DCP August 1996
シュナイダーと[6ページ]友人の情報のRFC1967LZS-DCP1996年8月
The transmitter MAY send an uncompressed LZS-DCP packet at any
time, although the typical use of uncompressed LZS-DCP packets is
as an anti-expansion mechanism.
送信機はいつでも解凍されたLZS-DCPパケットを送るかもしれません、反拡張メカニズムとして解凍されたLZS-DCPパケットの典型的な使用がありますが。
When the expansion plus compression header exceeds the size of the
peer's MRU for the link, the data MUST be sent as an uncompressed
LZS-DCP packet.
拡張プラス圧縮ヘッダーが同輩のMRUのサイズをリンクに超えているとき、解凍されたLZS-DCPパケットとしてデータを送らなければなりません。
An uncompressed LZS-DCP packet is transmitted according to the
format shown in Section 2.1, with the C/U bit set to 0
(Uncompressed-Data). If the Configuration Option Field 'Process
Mode', is set to a value of 1 (Process-Uncompressed), uncompressed
LZS-DCP packets are processed by both the compressor and the
decompressor, updating the histories of each. If the Process Mode
Field is set to a value of 0 (None), and the compressor has
modified its history before sending the uncompressed packet, the
compressor history MUST be clear.
セクション2.1に示された書式に従って、解凍されたLZS-DCPパケットは伝えられます、0(解凍されたデータ)に設定されたC/Uビットで。 Configuration Option Field'プロセスMode'が1(プロセスで解凍された)の値に設定されるなら、解凍されたLZS-DCPパケットはコンプレッサーと減圧装置の両方によって処理されます、それぞれの歴史をアップデートして。 Process Mode Fieldが0(なにも)の値に用意ができて、解凍されたパケットを送る前にコンプレッサーが歴史を変更したなら、コンプレッサー歴史は明確であるに違いありません。
2.5. Packet Format
2.5. パケット・フォーマット
A summary of the LZS-DCP packet format is shown below. The fields are transmitted from left to right.
LZS-DCPパケット・フォーマットの概要は以下に示されます。 野原は左から右まで伝えられます。
0 1 2
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PPP Protocol | DCP-Header |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| (History Number) | (Seq Num) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Data ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| (LCB) |
+-+-+-+-+-+-+-+-+
0 1 2 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | pppプロトコル| DCP-ヘッダー| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | (歴史番号) | (Seqヌム) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | データ… +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | (LCB) | +-+-+-+-+-+-+-+-+
2.5.1. PPP Protocol
2.5.1. pppプロトコル
The PPP Protocol field is described in the Point-to-Point Protocol
Encapsulation [1].
PPPプロトコル分野はPointからポイントへのプロトコルEncapsulation[1]で説明されます。
When the LZS-DCP compression protocol is successfully negotiated
by the PPP Compression Control Protocol [2], the value is 00FD or
00FB hex. This value MAY be compressed when Protocol-Field-
Compression is negotiated.
LZS-DCP圧縮プロトコルがPPP Compression Controlプロトコル[2]によって首尾よく交渉されるとき、値は、00FDか00FB十六進法です。 プロトコル分野圧縮が交渉されるとき、この値は圧縮されるかもしれません。
Schneider & Friend Informational [Page 7] RFC 1967 LZS-DCP August 1996
シュナイダーと[7ページ]友人の情報のRFC1967LZS-DCP1996年8月
2.5.2. DCP-Header
2.5.2. DCP-ヘッダー
The DCP-Header is nominally one octet in length, but may be
extended through the use of the extension bit.
DCP-ヘッダーは名目上はそうです。拡大ビットの使用で広げられるかもしれないのを除いた長さにおける1つの八重奏。
The format of the DCP-Header is as follows:
DCP-ヘッダーの形式は以下の通りです:
0 1 2 3 4 5 6 7
+-----+-----+-----+-----+-----+-----+-----+-----+
| E | C/U | R-A | R-R | Res | Res | Res | C/D |
+-----+-----+-----+-----+-----+-----+-----+-----+
0 1 2 3 4 5 6 7 +-----+-----+-----+-----+-----+-----+-----+-----+ | E| C/U| R-A| R-R| Res| Res| Res| C/D| +-----+-----+-----+-----+-----+-----+-----+-----+
E - Extension Bit
E--拡大に噛み付きました。
The E bit is the extension bit. If set to 0, it indicates that
another octet of the DCP-Header is present. Currently, this
bit is always set to 1, since the DCP-Header field is only one
octet long.
Eビットは拡大ビットです。 0に設定されるなら、それは、DCP-ヘッダーの別の八重奏が存在しているのを示します。 現在、このビットは、長い間DCP-ヘッダーフィールドが1つの八重奏にすぎないので、いつも1に設定されます。
C/U - Compressed/Uncompressed Bit
C/U--圧縮されたか解凍されたビット
The C/U indicates whether the data field contains compressed or
uncompressed data. A value of 1 indicates compressed data
(often referred to as a compressed packet), and a value of 0
indicates uncompressed data (or an uncompressed packet).
C/Uは、データ・フィールドが圧縮されたか解凍されたデータを含むかどうかを示します。 1の値は圧縮されたデータ(しばしば圧縮されたパケットと呼ばれる)を示します、そして、0の値は解凍されたデータ(または、解凍されたパケット)を示します。
R-A - Reset-Ack
R-A--リセット-Ack
The R-A bit is used to inform the decompressing peer that
the history buffer specified by the history number in the
packet was in the cleared state just before the data contained
in the packet was processed by the compression transformation
(see section 3., Sending Compressed Datagrams). This bit MUST
be set to a value of "1" to indicate a Reset-Ack, and to
acknowledge a receive failure (R-R) (see section 3., Sending
Compressed Datagrams). This bit is specific to the history
number of the packet containing it.
少しRは、パケットの歴史番号によって指定された歴史バッファがクリアされた状態のパケットに含まれたデータがまさしく圧縮変換によって処理された(セクション3.を見てください、Sending Compressedデータグラム)前であったことを減圧している同輩に知らせるのに使用されます。 「リセット-Ackを示して、aが失敗(R-R)を受ける(セクション3.を見てください、圧縮されたデータグラムを送って)と認める1インチ」の値にこのビットを設定しなければなりません。 このビットはそれを含むパケットの歴史番号に特定です。
R-R - Reset-Request
R-R--リセット要求
The R-R bit is used to request that the compressing peer
clear the history buffer specified by the history number in the
packet. This bit MUST be set to a value of "1" to indicate a
Reset-Request, and to respond to a receive failure (R-R) (see
section 3., Sending Compressed Datagrams). This bit is
specific to the history number of the packet containing it.
R-Rビットは、圧縮している同輩がパケットの歴史番号によって指定された歴史バッファをきれいにするよう要求するのに使用されます。 「リセット要求を示して、aに応じる1インチは失敗(R-R)を受け(セクション3.を見てください、圧縮されたデータグラムを送って)」値にこのビットを設定しなければなりません。 このビットはそれを含むパケットの歴史番号に特定です。
Schneider & Friend Informational [Page 8] RFC 1967 LZS-DCP August 1996
シュナイダーと[8ページ]友人の情報のRFC1967LZS-DCP1996年8月
Res - Reserved
Res--予約されます。
These bits are reserved and MUST be set to 0
これらのビットを予約されていて、0に設定しなければなりません。
C/D - Control/Data
C/D--コントロール/データ
This bit is used by DCP to provide in-band negotiation in
applications where out-of-band negotiation methods are not
provided (i.e. Frame Relay). Since CCP provides an out of band
negotiating mechanism, this feature is not used in this
application. All packets MUST set this bit to a value of 0,
which signifies that the packet is a data packet. (Packets
containing only Reset- Requests are classified as data
packets.)
このビットは、バンドにおけるバンドの外に、交渉メソッドが提供されないアプリケーション(すなわち、Frame Relay)における交渉を提供するのにDCPによって使用されます。 以来CCPが提供する、バンド交渉メカニズムから、この特徴はこのアプリケーションで使用されません。 すべてのパケットが0の値にこのビットを設定しなければなりません。(それは、パケットがデータ・パケットであることを意味します)。 (Reset要求だけを含むパケットがデータ・パケットとして分類されます。)
2.5.3. History Number
2.5.3. 歴史番号
The number of the compression history which was used, ranging from
1 to the negotiated value in the History Count field.
歴史Count分野で1〜交渉された値まで及んで、費やされた圧縮歴史の数。
If the negotiated History Count is less than 2, this field is
removed. If the negotiated History Count is 2 or more, but less
than 256, this field is 1 octet. If 256 or more histories are
negotiated, this field is 2 octets, most significant octet first.
交渉された歴史Countが2歳未満であるなら、この野原を取り除きます。 交渉された歴史Countが2歳以上ですが、この分野が256よりそれほど1つの八重奏であるなら。 256以上の歴史が交渉されるなら、最初に、この分野は2つの八重奏、最も重要な八重奏です。
If multiple histories are used in one direction on a link, the
history number field MUST be present on all packets in both
directions, and sized according to the largest number of histories
in either direction.
複数の歴史がリンクの上に一方向に費やされるなら、歴史ナンバーフィールドは、両方の方向にすべてのパケットで現在であって、歴史の最多数に従って、どちらの方向にも大きさで分けなければなりません。
If multiple histories are used, this field MUST be present in
uncompressed as well as compressed packets.
複数の歴史が使用されているなら、この分野は解凍されて圧縮されたパケットに存在していなければなりません。
2.5.4. Sequence Number
2.5.4. 一連番号
The sequence number field is one octet in length. When the check
mode field is set to the "Sequence Number" or "Sequence Number +
LCB" options, the sequence number field MUST be present in all
data compression packets that contain a data field.
一連番号分野は長さが1つの八重奏です。 チェックモード分野が「一連番号」か「一連番号+LCB」オプションに設定されるとき、一連番号分野はデータ・フィールドを含むすべてのデータ圧縮パケットに存在していなければなりません。
The value of the sequence number field (the sequence number of the
packet) MUST begin with "1" and increment modulo 256 on successive
packets that contain data fields. This number is relative to the
history number used.
一連番号分野(パケットの一連番号)の値は「データ・フィールドを含む連続したパケットの上の1インチと増分の法256」で始まらなければなりません。 この数は数が費やした歴史に比例しています。
On receipt of a packet with the R-A bit set to "0", if the
sequence number of the packet is any number other than (N+1) mod
256, where N is the sequence number of the last packet received
少し「0インチ、パケットの一連番号が(N+1)モッズ256以外のあらゆる数であるなら、Nが最終一連番号であるところでは、パケットは受信したこと」に設定されたRがあるパケットを受け取り次第
Schneider & Friend Informational [Page 9] RFC 1967 LZS-DCP August 1996
シュナイダーと[9ページ]友人の情報のRFC1967LZS-DCP1996年8月
for the same history, or an initial value of "0", a receive
failure for that history has occurred. The receive failure MUST
be handled according to the synchronization procedure in section
3.5.
同じ歴史、または「その歴史が現れたので、0インチ、aは失敗を受ける」初期の値のために。 失敗を受けてください。同期手順によると、セクション3.5で扱わなければなりません。
The sequence number MUST NOT be reset by the transmitter when a
packet containing a Reset-Ack is sent. The decompressor MUST
resynchronize its sequence number reference for the indicated
history when a packet containing a Reset-Ack is received.
Reset-Ackを含むパケットを送るとき、送信機は一連番号をリセットしてはいけません。 Reset-Ackを含むパケットが受け取られているとき、減圧装置は示された歴史の一連番号参照を再連動させなければなりません。
2.5.5. Data
2.5.5. データ
The data field MUST contain a single datagram in either compressed
or uncompressed form, depending on the state of the C/U bit in the
Header. This length of this field is always be an integer number
of octets. This field is required in all packets that do not have
the R-R bit set to "1".
データ・フィールドは圧縮されたか解凍されたフォームに単一のデータグラムを含まなければなりません、HeaderでC/Uビットの状態によって。 この分野のこの長さはいつも八重奏の整数であることです。 この分野が「1インチ」にR-Rビットを設定しないすべてのパケットで必要です。
If the C/U bit is set to "0", the data field contains the
uncompressed form of the datagram.
C/Uビットが「何0インチも、データ・フィールドはデータグラムの解凍されたフォームを含んでいること」に設定されるなら。
If the C/U bit is set to "1", the form of the data field is one
block of compressed data as defined in 3.2 of X3.241-1994, with
the following exceptions: 1) the end marker may be followed with
additional octets containing only zeros; 2) if the final octet in
the block of compressed data has a value of "0", then it MAY be
removed from the data field.
C/Uビットがそうなら、「1インチ、データ・フィールドのフォームは3.2X3.241-1994で定義されるように1ブロックの圧縮されたデータです、以下の例外で」セットしてください。 1) 追加八重奏がゼロだけを含んでいて、エンドマーカーはたどられるかもしれません。 2) 圧縮されたデータのブロックでの最終的な八重奏に「0インチ、そして、データ・フィールドからそれを取り除くかもしれない」値があるなら。
There is only one end marker per block of compressed data.
圧縮されたデータのブロックあたりの片端マーカーしかありません。
2.5.6. Longitudinal Check Byte
2.5.6. 縦のチェックバイト
The LCB field is one octet in length, and if present MUST be the
last octet in the data compression packet. When the check-mode
field is set to "LCB" or "Sequence Number + LCB", this field MUST
be present in all packets where the data field contains compressed
data. This field MUST NOT be present in data compression packets
where the data field contains uncompressed data. This field
contains the result of the LCB calculation, in accordance with the
following paragraph.
LCB分野は長さとプレゼントがデータ圧縮パケットの最後の八重奏であるに違いないかどうかで1つの八重奏です。 チェックモード分野が"LCB"か「一連番号+LCB」に設定されるとき、データ・フィールドが圧縮されたデータを含んでいるところにこの分野はすべてのパケットに存在していなければなりません。 データ・フィールドが解凍されたデータを含んでいるところにこの分野はデータ圧縮パケットに存在しているはずがありません。 以下のパラグラフによると、この分野はLCB計算の結果を含んでいます。
The LCB octet is the Exclusive-OR of FF(hex) and each octet of the
uncompressed datagram (prior to the compression transformation).
On receipt, the receiver computes the Exclusive-OR of FF(hex) and
each octet of the decompressed packet. If this value does not
match the received LCB, then a receive failure for that history
has occurred. The receive failure is handled according to the
history synchronization procedure in section 3.5.
LCB八重奏は、FF(十六進法)のExclusive-ORと解凍されたデータグラム(圧縮変換の前の)の各八重奏です。 領収書の上では、受信機はFF(十六進法)のExclusive-ORと減圧されたパケットの各八重奏を計算します。 この値が合っていないなら、その歴史が現れたので、容認されたLCB、当時のaは失敗を受けます。 失敗を受けてください。歴史同期手順によると、セクション3.5で扱われます。
Schneider & Friend Informational [Page 10] RFC 1967 LZS-DCP August 1996
シュナイダーと[10ページ]友人の情報のRFC1967LZS-DCP1996年8月
2.5.7. Compressed Data
2.5.7. 圧縮されたデータ
The Stac LZS compression algorithm is Defined in ANSI X3.241-1994 [7]. The format of the compressed data is repeated here for informational purposes ONLY.
Stac LZS圧縮アルゴリズムはANSI X3.241-1994[7]のDefinedです。 圧縮されたデータの形式は情報の目的だけのためにここで繰り返されます。
<Compressed Stream> := [<Compressed String>] <End Marker> <Compressed String> := 0 <Raw Byte> | 1 <Compressed Bytes>
<圧縮されたストリーム>:=[<はストリング>を圧縮した]<エンドマーカー><はストリング>:=生の0<バイト>を圧縮しました。| 1 <はバイト>を圧縮しました。
<Raw Byte> := <b><b><b><b><b><b><b><b> (8-bit byte) <Compressed Bytes> := <Offset> <Length>
生の<の<b><b Byte>:=<b><b><b><b><b><b>>(8ビットのバイト)<Compressed Bytes>:=<Offset><Length>。
<Offset> := 1 <b><b><b><b><b><b><b> | (7-bit offset)
0 <b><b><b><b><b><b><b><b><b><b><b> (11-bit offset)
<End Marker> := 110000000
<b> := 1 | 0
<は1<bの>:=><b><b><b><b><b><b>を相殺しました。| (7ビットのオフセット) 0 <b><b><b><b><b><b><b><b><b><b><b>(11ビットのオフセット)<End Marker>:=110000000<b>:=1| 0
<Length> := 00 = 2 1111 0110 = 14 01 = 3 1111 0111 = 15 10 = 4 1111 1000 = 16 1100 = 5 1111 1001 = 17 1101 = 6 1111 1010 = 18 1110 = 7 1111 1011 = 19 1111 0000 = 8 1111 1100 = 20 1111 0001 = 9 1111 1101 = 21 1111 0010 = 10 1111 1110 = 22 1111 0011 = 11 1111 1111 0000 = 23 1111 0100 = 12 1111 1111 0001 = 24 1111 0101 = 13 ...
<長さの>:=00 = 2 1111 0110 = 14 01 = 3 1111 0111 = 15 10 = 4 1111 1000 = 16 1100 = 5 1111 1001 = 17 1101 = 6 1111 1010 = 18 1110 = 7 1111 1011 = 19 1111 0000 = 8 1111 1100 = 20 1111 0001 = 9 1111 1101 = 21 1111 0010 = 10 1111 1110 = 22 1111 0011 = 11 1111 1111 0000 = 23 1111 0100 = 12 1111 1111 0001 = 24 1111 0101 = 13…
3. Sending Compressed Datagrams
3. 送付の圧縮されたデータグラム
The reliable and efficient transport of datagrams on the data link depends on the following processes.
データ・リンクにおけるデータグラムの信頼できて効率的な輸送は以下のプロセスによります。
3.1. Transmitter Process
3.1. 送信機プロセス
The compression operation results in either compressed or
uncompressed data. When a network datagram is received, it is
assigned to a particular history buffer and processed according to
ANSI X3.241-1994 to form compressed data or used as is to form
uncompressed data. Prior to the compression operation, if a
Reset-Request is outstanding for the history buffer to be used,
the buffer is cleared. In performing the compression operation,
if the process mode field is set to the value None ("0"), the
history MUST only be updated if the result is compressed data. If
process mode field is set to the value Process-Uncompressed ("1"),
操作がもたらす圧縮は、データを圧縮したか、または解凍しました。 ネットワークデータグラムが受け取られているとき、それは、特定の歴史バッファに割り当てられて、ANSI X3.241-1994によると、圧縮されたデータを形成するために処理されるか、または解凍されたデータを形成するのにそのままで使用されます。 圧縮操作の前に、Reset-要求が歴史バッファが使用されるために傑出しているなら、バッファはきれいにされます。 プロセスモード分野が値のNoneに設定されるなら圧縮操作を実行する、(「0インチ)、結果が圧縮されたデータであるなら歴史をアップデートするだけでよい、」 Processによって解凍されていた状態でプロセスモード分野が値に設定される、(「1インチ)」
Schneider & Friend Informational [Page 11] RFC 1967 LZS-DCP August 1996
シュナイダーと[11ページ]友人の情報のRFC1967LZS-DCP1996年8月
the history MUST be updated when either compressed data or
uncompressed data is produced. Uncompressed data MAY be sent at
any time. Uncompressed data MUST be sent if compression causes
enough expansion to cause the data compression datagram size to
exceed the Information field's MRU.
圧縮されたデータか解凍されたデータのどちらかを作り出すとき、歴史をアップデートしなければなりません。 いつでも、解凍されたデータを送るかもしれません。 データ圧縮データグラムサイズが拡張で情報フィールドのMRUを十分超えているなら、圧縮で解凍されたデータを送らなければなりません。
If the Process Mode field is set to the value None ("0") and the
compressor has modified the history buffer before sending an
uncompressed datagram, the history buffer MUST be cleared before
the next datagram is processed.
Process Mode分野が値のNoneに設定される、(「0インチ)、解凍されたデータグラムを送って、次のデータグラムが処理される前に歴史バッファをきれいにしなければならない前にコンプレッサーが歴史バッファを変更した、」
The output of the compression operation is placed in the
information field of the datagram. The C/U bit is set according
to whether the data field contains compressed or uncompressed
data. If the sequence number field is present according the value
of the check mode field, the sequence number counter for the
applicable history number MUST be incremented and its value placed
in the sequence number field. If the data field contains
compressed data, and Check Mode field is set accordingly, the LCB
field is present and its value is computed as specified in section
2.2.6.
圧縮操作の出力はデータグラムの情報フィールドに置かれます。 データ・フィールドが圧縮されたか解凍されたデータを含んでいるかどうかに従って、C/Uビットは設定されます。 一連番号分野がチェックモード分野の値存在しているなら、適切な歴史番号のための一連番号カウンタは増加していなければならなくて、値は一連番号分野に置かれます。 データ・フィールドが圧縮されたデータを含んでいて、Check Mode分野がそれに従って、設定されるなら、LCB分野は存在しています、そして、値はセクション2.2.6で指定されるように計算されます。
Upon reception of a packet containing a Reset-Request, the
transmitting compressor MUST be cleared to an initial state, which
includes clearing the history buffer. If the data field of the
packet containing the Reset-Request contains data, it is delivered
to the local receiver as a normal data packet. In addition to the
reset of the compressor, a packet MUST be transmitted with Reset-
Ack bit set to 1. The data field of this packet MUST be filled
with data. If no data is ready for transmission, the transmitter
MUST wait until data is ready before sending the Reset-Ack.
Reset-要求を含むパケットのレセプションでは、伝えるコンプレッサーを初期状態にきれいにしなければなりません。(それは、歴史バッファをきれいにするのを含んでいます)。 Reset-要求を含むパケットのデータ・フィールドがデータを含んでいるなら、それは正常なデータ・パケットとして地方の受信機に提供されます。 コンプレッサーのリセットに加えて、1に設定されたReset- Ackビットでパケットを伝えなければなりません。 データでこのパケットのデータ・フィールドを満たさなければなりません。 どんなデータもトランスミッションの準備ができていないなら、Reset-Ackを送る前にデータが準備ができるまで、送信機は待たなければなりません。
If the history buffer is in the clear state (the history buffer
contains no data bytes) prior to performing the compression
operation, the resulting compressed or uncompressed packet MUST be
sent with the R-A bit set to "1".
圧縮操作を実行する前に、歴史バッファが明確な状態(歴史バッファはデータ・バイトを全く含んでいない)にあるなら、少しRセットで結果として起こる圧縮されたか解凍されたパケットを「1インチ」に送らなければなりません。
3.2. Receiver Process
3.2. 受信機プロセス
When a data compression datagram is received from the peer, the
R-R and R-A bits MUST be checked. If the R-R bit is set, the
local compression engine MUST be signaled that a Reset-Request has
been received for the history specified by the history number
field. If the R-A bit is set, any outstanding receive failure for
the specified history MUST be cleared. If no receive failure is
outstanding, and the sequence number field is present, its value
checked. If a receive failure has occurred, it MUST be handled
according to the history resynchronization mechanism described
同輩からデータ圧縮データグラムを受け取るとき、R-RとR-Aビットをチェックしなければなりません。 R-Rビットが設定されるなら、Reset-要求が歴史ナンバーフィールドによって指定された歴史のために受け取られたと地方の圧縮エンジンに合図しなければなりません。 少しRが設定されるなら、未払いのいずれも、指定された歴史をクリアしなければならないので、失敗を受けます。 値はいいえが受信されるなら失敗が傑出していて、一連番号分野が存在しているのをチェックしました。 aが受信されるなら、失敗は起こって、再同期メカニズムが説明した歴史によると、それを扱わなければなりません。
Schneider & Friend Informational [Page 12] RFC 1967 LZS-DCP August 1996
シュナイダーと[12ページ]友人の情報のRFC1967LZS-DCP1996年8月
below, and the remainder of the datagram is discarded. If no
receive failure is detected, the data is assigned to the indicated
decompression history buffer and processed according to process
mode field and C/U bit.
下、および捨てられたデータグラムの残り。 いいえが受信されるなら失敗が検出されて、データは、示された減圧歴史バッファに割り当てられて、プロセスモード分野とC/Uビットに従って、処理されます。
If the C/U bit is set to "1", a single octet containing the value
0x00 MUST be appended to the data field and the resulting
compressed data block MUST be decompressed according to ANSI
X3.241-1994. If the LCB field is present on the received
datagram, an LCB for the uncompressed data MUST be computed and
checked against the received LCB according to section 2.1. If a
receive failure has occurred, it MUST be handled according to the
History Resynchronization Mechanism described below.
C/Uビットが「1インチ、値0x00を含むただ一つの八重奏をデータ・フィールドに追加しなければなりません、そして、ANSI X3.241-1994によると、結果として起こる圧縮されたデータ・ブロックを減圧しなければならないこと」に設定されるなら。 LCB分野が容認されたデータグラムに存在しているなら、セクション2.1によると、容認されたLCBに対して解凍されたデータのためのLCBを計算されて、チェックしなければなりません。 aが受信されるなら、失敗は起こって、以下で説明された歴史Resynchronization Mechanismによると、それを扱わなければなりません。
If the C/U bit is set to "0" and the process mode field is set to
the value Process-Uncompressed ("1"), the specified decompression
history buffer MUST be updated with the received uncompressed
data.
C/Uビットが設定される、「0インチと加工処理したモード分野が値にプロセスによって解凍されていた状態で設定される、(「1インチ)、受信された解凍されたデータで指定された減圧歴史バッファをアップデートしなければならない、」
If the C/U bit is set to "0" and process mode field is set to the
value None ("0"), the specified decompression history buffer MUST
NOT be modified.
C/Uビットが設定される、「0インチとプロセスモード分野がなにもに値に設定される、(「0インチ)、指定された減圧歴史バッファを変更してはいけない、」
If the R-A bit is set to "1", the receiving decompressor MAY be
reset to an initial state. (However, due to the characteristics
of the Stac LZS algorithm, a decompressor reset is not required).
After reset, any compressed or uncompressed data contained in the
packet is processed.
少しRが「何1インチも、受信減圧装置は初期状態にリセットされるかもしれないこと」に設定されるなら。 (しかしながら、Stac LZSアルゴリズムの特性のため、減圧装置リセットは必要ではありません。) リセットされた後に、パケットに含まれたどんな圧縮されたか解凍されたデータも処理されます。
On the occurrence of a receive failure, an implementation MUST
transmit a packet with the R-R bit set to "1" (a Reset-Request)
and with the history number matching the history that had the
failure. The data field may be present if data is waiting to be
transported for that history, or the R-R bit may be set in a
packet transmitted without sequence number, data, or LCB fields.
Once a receive failure has occurred, the data in any subsequent
packets received for that history MUST be discarded until a packet
containing a Reset-Ack is received. It is the responsibility of
the receiver to ensure the reliability of the reset request-
acknowledge mechanism. This may require the transmission of an
additional Reset-Request before a Reset-Ack will be received.
aの発生では、失敗を受けてください、そして、実装は「1インチ(リセット要求)と失敗を持っていた歴史に合っている歴史番号」に設定されたR-Rビットでパケットを伝えなければなりません。 データが、その歴史のために輸送されるのを待っているなら、データ・フィールドが存在しているかもしれませんか、またはR-Rビットは一連番号も、データも、またはLCB分野なしで伝えられたパケットに設定されるかもしれません。 aがいったん受信されると、失敗は起こって、Reset-Ackを含むパケットが受け取られているまで、その歴史のために受け取られたどんなその後のパケットのデータも捨てなければなりません。 リセット要求の信頼性がメカニズムを承認するのを保証するのは、受信機の責任です。 Reset-Ackを受け取る前にこれは追加Reset-要求の伝達を必要とするかもしれません。
3.3. History Maintenance
3.3. 歴史メインテナンス
The History Count field determines the number of history buffers
to be maintained for the compression protocol. For example, each
history buffer could represent a separate logical connection
between the data compression peers. When maintaining a history,
歴史Count分野は、歴史バッファの数が圧縮プロトコルのために維持されることを決定します。 例えば、それぞれの歴史バッファはデータ圧縮同輩の間の別々の論理的な接続の代理をするかもしれません。 歴史を維持するとき
Schneider & Friend Informational [Page 13] RFC 1967 LZS-DCP August 1996
シュナイダーと[13ページ]友人の情報のRFC1967LZS-DCP1996年8月
the peers MUST use link error detection and signaling to ensure
that both the compressor and decompressor copies of each history
buffer are always identical.
同輩は、コンプレッサーとそれぞれの歴史バッファの減圧装置コピーの両方が確実にいつも同じになるようにするのにリンク誤り検出とシグナリングを使用しなければなりません。
Setting the History Count field to the value "0" indicates that
the compression is to be on a connectionless basis. In this case,
a single history buffer is used and MUST be cleared at the
beginning of every datagram. The compressing entity MUST set the
R-A bit on all outgoing datagrams.
歴史Count分野を値に設定して、「0インチは、圧縮がコネクションレスベースにあることであることを示します」。 この場合、ただ一つの歴史バッファを使用されていて、あらゆるデータグラムの始めにきれいにしなければなりません。 圧縮実体はすべての発信データグラムの上に少しRを設定しなければなりません。
When the History Count field is set to the value "1", a single
history buffer is maintained by each of the data compression
peers. (A single logical connection.)
歴史Count分野が値に設定されるとき、「何1インチも、ただ一つの歴史バッファはデータ圧縮同輩各人によって維持されます」。 (単独の論理的な接続。)
When the History Count field is set to a value greater than "1",
separate history buffers, error detection states, and signaling
states are maintained by the decompressing entity for each
history. The compressing peer may transmit data on any number of
separate histories, up to the value of the History Count field.
歴史Count分野が「1インチ、別々の歴史バッファ、誤り検出州、およびシグナリング州は各歴史のために減圧実体によって維持される」より大きい値に設定されるとき。 圧縮している同輩はいろいろな別々の歴史に関するデータを送るかもしれません、歴史Count分野の値まで。
3.4. Anti-Expansion Mechanism
3.4. 反拡張メカニズム
When one or more histories are negotiated and the Process Mode
field is set to None ("0"), there are 2 options on how to handle
packets that expand:
1つ以上の歴史が交渉されて、Process Mode分野がNoneに設定される、(「0インチ)、どう以下を広げるパケットを扱うかに関する2つのオプションがある、」
1) Send the expanded data and keep the history, thus allowing
loss of current bandwidth but preserving future bandwidth on
the link.
2) Send the uncompressed data and clear the history, thus
conserving current bandwidth, but allowing possible loss of
future bandwidth on the link.
1) 拡張データを送ってください、そして、歴史を保管してください、その結果、現在の帯域幅の損失を許容しますが、リンクにおける将来の帯域幅を保持して。 2) 解凍されたデータを送ってください、そして、歴史をクリアしてください、その結果、現在の帯域幅を保存しますが、リンクにおける将来の帯域幅の可能な損失を許容して。
When 1 or more histories are negotiated and the Process Mode field
is set to Process-Uncompressed ("1"), there is an additional
option:
1以上歴史が交渉されて、Process Mode分野がProcessによって解凍されるのに設定される、(「1インチ)、追加オプションがあります:、」
3) Send the uncompressed data and do not clear the compression
history; the decompressor will update its history, thus
conserving the current bandwidth and future bandwidth on the
link.
3) 解凍されたデータを送ってください、そして、圧縮歴史をクリアしないでください。 減圧装置は歴史をアップデートして、その結果、リンクにおける現在の帯域幅と将来の帯域幅を保存するでしょう。
3.5. History Resynchronization Mechanism
3.5. 歴史Resynchronizationメカニズム
The DCP-Header includes R-R (Reset-Request) and R-A (Reset-Ack)
bits in order to provide a mechanism for indicating a receiver
failure in one direction of a compressed link without affecting
traffic in the other direction. A receive failure is determined
DCP-ヘッダーは、もう片方の方向にトラフィックに影響しないで圧縮されたリンクの一方向に受信機の故障を示すのにメカニズムを提供するためにR-R(リセット要求)とR-A(リセット-Ack)ビットを入れます。 Aが受信される、失敗は決定しています。
Schneider & Friend Informational [Page 14] RFC 1967 LZS-DCP August 1996
シュナイダーと[14ページ]友人の情報のRFC1967LZS-DCP1996年8月
using the sequence number and/or LCB mechanism, according to the
value of the check mode field.
チェックモード分野の値に従って、一連番号、そして/または、LCBメカニズムを使用します。
Reset-Requests and Reset-Acks are specific to the history number
of the packet containing them.
リセット要求とReset-Acksは彼らを含むパケットの歴史番号に特定です。
Reset-Request/Reset-Ack history synchronization signaling is
provided to recover from a loss of synchronization between peers,
especially in unreliable transport layers. As with all
compression algorithms, the decompressor can not recover from
dropped, erroneous, or mis-ordered datagrams, and will propagate
errors catastrophically until both peers are reset to an initial
state.
特に頼り無いトランスポート層の同輩の間の同期の損失から回復するためにリセットリセット要求/Ack歴史同期シグナリングを提供します。 すべての圧縮アルゴリズムの場合、減圧装置は、下げられたか、誤ったか、誤命令されたデータグラムから回復できないで、両方の同輩が初期状態にリセットされるまで、誤りを不運に伝播するでしょう。
The LZS-DCP protocol provides a means to detect these error
conditions: LCB for erroneous datagrams, and sequence number for
dropped or mis-ordered datagrams. There is a means for correcting
a loss of synchronization: clear both the failing compression and
decompression histories, and follow the transmitter and receiver
processes in sections 3.1. and 3.2.
LZS-DCPプロトコルはこれらのエラー条件を検出する手段を提供します: 誤ったデータグラム、および一連番号のためのLCB、下げられたか誤命令されたデータグラム同期の損失を修正するための手段があります: 失敗圧縮と減圧歴史の両方をクリアしてください、そして、セクション3.1と3.2で送信機と受信機プロセスに続いてください。
4. Configuration Option Format
4. 設定オプション形式
The LZS-DCP Configuration Option negotiates the use of LZS-DCP on the link. By default or ultimate disagreement, no compression is used. This Configuration Option is used in CCP, and can be used in other negotiation mechanisms [2].
LZS-DCP Configuration OptionはリンクにおけるLZS-DCPの使用を交渉します。 または、デフォルトで、究極の不一致、どんな圧縮も使用されていません。 このConfiguration OptionをCCPで使用して、他の交渉メカニズム[2]で使用できます。
All implementations MUST support the default values.
すべての実装が、デフォルトが値であるとサポートしなければなりません。
A summary of the LZS-DCP Configuration Option format is shown below. The fields are transmitted from left to right.
LZS-DCP Configuration Option形式の概要は以下に示されます。 野原は左から右まで伝えられます。
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 | Length | History Count |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Check Mode | Process Mode |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
タイプ
23
23
Length
長さ
6
6
Schneider & Friend Informational [Page 15] RFC 1967 LZS-DCP August 1996
シュナイダーと[15ページ]友人の情報のRFC1967LZS-DCP1996年8月
History Count
歴史カウント
The History Count field is two octets, most significant octet
first, and specifies the maximum number of Compression Histories.
歴史Count分野は、2つの八重奏、最初に最も重要な八重奏であり、Compression歴史の最大数を指定します。
The value 0 indicates that the implementation expects the peer to
clear the Compression History at the beginning of every packet.
If this value is selected, the transmitter MUST set the Reset-Ack
bit of every packet that contains compressed data.
値0は、実装が、同輩が始めのCompression歴史からあらゆるパケットを取り除くと予想するのを示します。 この値が選択されるなら、送信機は圧縮されたデータを含むあらゆるパケットのReset-Ackビットを設定しなければなりません。
The value 1 is the default value and is used to indicate that only
one history is maintained.
値1は、デフォルト値であり、1つの歴史だけが維持されるのを示すのに使用されます。
Other valid values range from 2 to 65535. The peer is not
required to send as many histories as the implementation indicates
that it can accept. However, it should be noted that resources
are allocated in each peer to support the number of negotiated
histories in this field.
他の有効値は2〜65535まで及びます。 実装が、それが受け入れることができるのを示すとき、同輩は同じくらい多くの歴史を送る必要はありません。 しかしながら、リソースがこの分野の交渉された歴史の数をサポートするために各同輩に割り当てられることに注意されるべきです。
Check Mode
モードをチェックしてください。
The Check Mode indicates support of LCB and/or Sequence checking.
The use of check mode None (0) MUST NOT be used for history counts
greater than zero.
Check ModeはLCB、そして/または、Sequenceの照合のサポートを示します。 ゼロより大きい歴史カウントにチェックモードNone(0)の使用を使用してはいけません。
0 None
1 LCB
2 Sequence Number
3 Sequence Number + LCB (default)
0、なにも、1LCB2の一連番号3一連番号+LCB(デフォルト)
Process Mode
プロセスモード
The Process Mode specifies how uncompressed packets are handled.
A value of None (0) indicates that uncompressed packets are not
processed by the decompressor. A value of Process-Uncompressed
Process Modeは解凍されたパケットがどう扱われるかを指定します。 None(0)の値は、解凍されたパケットが減圧装置によって処理されないのを示します。 Processによって解凍されることの値
(1) indicates that uncompressed packets are processed by the
decompressor to update the history.
(1)は解凍されたパケットが減圧装置によって処理されて、歴史をアップデートするのを示します。
0 None (default)
1 Process-Uncompressed
0 1がプロセスで解凍しなかったなにも(デフォルト)
Security Considerations
セキュリティ問題
Security issues are not discussed in this memo.
このメモで安全保障問題について議論しません。
Schneider & Friend Informational [Page 16] RFC 1967 LZS-DCP August 1996
シュナイダーと[16ページ]友人の情報のRFC1967LZS-DCP1996年8月
Acknowledgments
承認
This document is based on, and uses much of the text of [5].
このドキュメントは、[5]のテキストの多くをに基礎づけていて、使用します。
References
参照
[1] Simpson, W., Editor, "The Point-to-Point Protocol (PPP)", STD
51, RFC 1661, Daydreamer, July 1994.
[1] シンプソン、W.、エディタ、「二地点間プロトコル(ppp)」、STD51、RFC1661、空想家、1994年7月。
[2] Rand, D., "The PPP Compression Control Protocol (CCP)", RFC
1962, June 1996.
D.、「ppp圧縮制御プロトコル(CCP)」、RFC1962 1996年6月の[2]底ならし革。
[3] Lempel, A., and J. Ziv, "A Universal Algorithm for Sequential
Data Compression", IEEE Transactions On Information Theory,
Vol. IT-23, No. 3, May 1977.
情報理論に関する[3] Lempel、A.とJ.Ziv、「連続したデータ圧縮のための普遍的なアルゴリズム」IEEEトランザクション、Vol.IT-23(No.3)は1977がそうするかもしれません。
[4] Rand, D., "PPP Reliable Transmission", RFC 1663, Novell, July
1994.
[4] 底ならし革、D.、「pppの信頼できる送信」、RFC1663、ノベル、1994年7月。
[5] Friend, R., and W. Simpson, "PPP Stac LZS Compression
Protocol", RFC 1974, August 1996.
[5] 友人、R.とW.シンプソン、「ppp Stac LZS圧縮プロトコル」、RFC1974、1996年8月。
[6] Motorola Information Systems Group, "Data Compression Protocol
(DCP) Proposal", TR-30.1 ad hoc contribution (email
reflector), September 21, 1995.
[6]モトローラ情報システムGroup、「データ圧縮プロトコル(DCP)提案」、TR-30.1の臨時の貢献(メール反射鏡)、1995年9月21日。
[7] ANSI X3.241-1994, "American National Standard Data Compression
Method, Adaptive Coding with Sliding Window of Information
Interchange".
[7]ANSI X3.241-1994、「米国標準規格データ圧縮メソッド、情報交換の引窓との適応型のコード化」。
Chair's Address
議長のアドレス
The working group can be contacted via the current chair:
現在のいすを通してワーキンググループに連絡できます:
Karl Fox Ascend Communications 3518 Riverside Drive, Suite 101 Columbus, Ohio 43221
カールフォックスはオハイオ コミュニケーション3518リバーサイド・ドライブ、Suite101コロンブス、43221を昇ります。
EMail: karl@ascend.com
メール: karl@ascend.com
Schneider & Friend Informational [Page 17] RFC 1967 LZS-DCP August 1996
シュナイダーと[17ページ]友人の情報のRFC1967LZS-DCP1996年8月
Authors' Addresses
作者のアドレス
Questions about this memo can also be directed to:
また、このメモに関する質問による以下のことよう指示できます。
Kevin Schneider Adtran, Inc. 901 Explorer Blvd. Huntsville, AL 25806
ケビンシュナイダーAdtran Inc.901エクスプローラーBlvd. ハンツビル、AL 25806
Phone: (205) 971-8024 EMail: kschneider@adtran.com
以下に電話をしてください。 (205) 971-8024 メールしてください: kschneider@adtran.com
Robert Friend Stac Technology 12636 High Bluff Drive San Diego, CA 92130-2093
高い切り立っているDriveサンディエゴ、ロバート友人Stac Technology12636カリフォルニア92130-2093
Phone: (619) 794-4542 EMail: rfriend@stac.com
以下に電話をしてください。 (619) 794-4542 メールしてください: rfriend@stac.com
Schneider & Friend Informational [Page 18]
シュナイダーと友人情報です。[18ページ]
一覧
スポンサーリンク
